LLM-қосымшада артық тәуекелсіз нені логтау керек

Лог қай жерде көмектеседі, қай жерде зиян келтіреді

Логсыз команда тек пайдаланушының шағымын және қате фактісін ғана көреді. Модель неге біртүрлі жауап бергенін, неге шығын өскенін немесе неге сұраулар түнде құлай бастағанын түсіну керек болса, бұл аздық етеді.

LLM-қосымшаларда логтар «жай ғана болсын» деп емес, нақты міндеттер үшін керек. Солар арқылы промпт шаблондарындағы ақауларды, кідірістің күрт өсуін, модельдер арасындағы маршрутизация қателерін, лимиттен асуды және провайдер жағындағы бас тартуларды табады. Егер қолданба мен модельдердің арасында бірыңғай OpenAI-үйлесімді шлюз тұрса, логсыз мәселенің дәл қай жерде екенін тез түсіну қиын: қолданбада ма, таңдалған модельде ме, әлде кілт бойынша қатынау саясатында ма.

Бірақ әзірлеушіге ең ыңғайлы лог көбіне бизнес үшін ең қауіптісі болады. Шикі промпттар мен толық жауаптар тез арада артық деректер қоймасына айналады: клиент аттары, келісімшарт нөмірлері, хат алмасу үзінділері, медициналық мәліметтер, ішкі нұсқаулықтар, API-кілттер, құжаттардың бөліктері. Бүгін мұндай лог инцидентті талдауға көмектеседі, ал бір айдан кейін өзі тәуекел көзіне айналады.

Сондықтан мақсаттарды бірден бөліп алған дұрыс. Дебаг үшін әдетте техникалық із жеткілікті: сұрау қашан келді, қай модель жұмыс істеді, жауап қанша уақыт алды және қате қай жерде шықты. Қауіпсіздік үшін тәуекел белгілері маңызды: құпия жіберу әрекеті, трафиктің күрт өсуі, әдеттен тыс IP, бір кілт бойынша жиі бас тарту. Аудит үшін әрекет фактісі керек: жүйені кім шақырды, сұрау қандай маршруттан өтті, қандай ереже іске қосылды және міндетті із сақталды ма.

Осы міндеттер араласса, логтау пайдасыз үлкейіп кетеді. Команда «керек болып қалар» деп бәрін сақтай береді. Шын мәнінде, қажеті аз бөлігі ғана, ал жауапкершілігі бүкіл көлемге түседі.

Қарапайым қағида мынау: шешім қабылдауға көмектесетін нәрсені ғана сақтаңыз. Егер жазба ақауды түзетуге, инцидентті тексеруге, аудит үшін әрекетті растауға немесе заң талабын орындауға көмектеспесе, оны мүлде жазбаған дұрыс. Қандай да бір сезімтал дерек үшін алдымен екі сұрақ қойыңыз: мұны кім оқиды және оны қанша күн сақтау шын мәнінде керек.

Минималды лог құрамы

LLM-қосымшада нені логтау керегін шешсеңіз, мәтіннің өзінен емес, метадеректерден бастаңыз. Дебаг, қауіпсіздік және аудит үшін көбіне қысқа өрістер жиыны жеткілікті: сұрауда не болғаны, қашан болғаны және қай маршрутпен өткенін солар көрсетеді.

Алдымен идентификаторлар керек: request_id, trace_id, tenant_id және сұраудың нақты уақыты. request_id нақты шақыруды табуға көмектеседі, trace_id бірнеше сервистен тұратын тізбекті байланыстырады, ал tenant_id бір клиентті немесе бөлімшені екіншісінен бөледі. Сағат 14:03-та қате саны кенет өссе, бұл өрістерсіз журнал тез арада шуға айналады.

Келесі топ модель шақыруын сипаттайды: модель атауы, провайдер, таңдалған маршрут және промпт нұсқасы. Бұл әсіресе қолданба бірнеше модель арасында ауыса алса немесе бір шлюз арқылы жұмыс істесе маңызды. Маршрут пен промпт нұсқасы болмаса, кеше жауап қалыпты, ал бүгін неге нашар не қымбат болғанын түсіну қиын.

Тағы бір өрістер тобы эксплуатация мен шығын үшін керек: latency, status_code, кіріс және шығыс токен саны, шақыру құны. Бұл деректер қолданба қай жерде баяулайтынын, модель қай жерде тым ұзақ жауап беретінін және қай сценарий бюджетті жеп жатқанын тез көрсетеді.

Операция түрін де бірден белгілеп отырған пайдалы: chat, embeddings, tool_call, moderation. Әйтпесе кейін диалогтағы ақауды білім базасын іздеу немесе құрал шақыруындағы ақаудан ажырату қиын болады.

Тұрақсыздық белгілерін бөлек тіркеңіз: retry болды ма, timeout шықты ма, сұрау rate_limit-ке тірелді ме. Мұндай бір флаг көбіне қате туралы ұзын мәтіннен пайдалырақ. Одан бір реттік желі ақауы ма, әлде лимиттерге қатысты жүйелік мәселе ме, бірден көрінеді.

Минималды лог құрамы әдетте бес топқа сыйып кетеді:

• сұрауды кім және қашан жіберді: tenant_id, request_id, trace_id, timestamp
• ол қайда кетті: модель, провайдер, маршрут, промпт нұсқасы
• не болды: операция түрі және status_code
• қанша уақыт алды: latency, токендер, құн
• ақау болды ма: retry, timeout, rate_limit

Егер бұл өрістер тұрақты жазылса, команда инциденттерді тексеріп, шығынды есептеп, сезімтал деректерді артық сақтамай-ақ аудиттен өте алады.

Нені сақтамаған дұрыс

Негізгі қателік қарапайым: логқа бәрі кіріп кетеді. Дебаг үшін бұл алғашқы бірнеше күнде ыңғайлы көрінеді. Кейін дәл сол логтардың өзі проблемаға айналады.

Шикі промпттарды, егер пайдаланушы оған аты-жөнін, ИИН, карта нөмірін, мекенжайды, диагнозды, келісімшартты немесе компанияның ішкі деректерін жаза алса, логқа түсірмеген дұрыс. Инцидентті талдау үшін көбіне промпт шаблоны, қосымша нұсқасы, сұрау уақыты және бірнеше техникалық белгі жеткілікті. Егер мәтін үлгісі керек болса, түгел кірісті емес, маскаланғаннан кейінгі қысқа фрагментті сақтаңыз.

Модельдің толық жауаптарымен де солай. Модель жиі кіріс деректерінен құпияны қайталайды, құжаттардың үзінділерін қайта айтып береді немесе tool_call нәтижесін сол күйі шығарады. Әзірлеушіге мұндай жауапты оқу ыңғайлы, бірақ оны айлар бойы сақтау дұрыс емес. Көбіне жауап статусы, ұзындығы, тапсырма түрі, модерация бағасы және жауаптың пайдаланушыға жіберілгені туралы белгі жеткілікті.

Логтардан тікелей қол жеткізу беретін нәрсенің бәрін алып тастаған жөн:

• API-кілттер
• access token
• cookie
• session id
• файлдарға уақытша сілтемелер

Тіпті осындай бір ғана үзінді ортақ журналда қалып қойса, тестшіге, мердігерге немесе оқуға құқығы бар кез келген қызметкерге артық қолжетімділік ашуы мүмкін.

Тіркемелер мен құжаттарды да «керек болып қалар» деп сақтамаңыз. PDF, төлқұжат скандары, анықтамалар, медициналық карталар және ішкі есептер тез жиналады, ал олардың логтағы пайдасы аз. Егер файл тергеу үшін маңызды болса, оны қысқа мерзімі бар бөлек қорғалған объект ретінде сақтап, инцидентке сілтеме қалдырған дұрыс, ал логқа тек файл түрін, көлемін және хешін жазу керек.

Тағы бір тәуекел аймағы жиі еленбей қалады: tool_call нәтижелері. Қосымша CRM, банк жүйесі, ERP немесе медтізілімге барып, ИИН, шот нөмірі, қалдық, диагноз немесе операциялар тарихын қайтара алады. Мұндай деректерді кәдімгі логқа тартудың қажеті жоқ. Құрал атауын, шақыру уақытын, нәтиже кодын және мәндері жоқ өрістер тізімін сақтау жеткілікті.

Банк ботына арналған ереже өте қарапайым көрінеді. Ол request_id, модель, кідіріс, токен саны және қате фактісін жаза алады. Бірақ оған құжаттың фотосын, жеке деректері бар шағымның толық мәтінін және карта нөмірі бар backend жауабын сақтаудың қажеті жоқ.

Логтарды мақсатқа қарай бөліңіз

Ең жиі кездесетін қателердің бірі - бәрін бір ағынға жинау. Онда диалог мәтіндері, қателер, пайдаланушы әрекеттері, ережелердің іске қосылуы және өнім метрикалары араласып кетеді. Бір айдан кейін мұндай журналды оқу қиын, ал ағып кету тәуекелі себепсіз өседі.

Логтарды сіз жауап бергіңіз келетін сұраққа қарай бөлу жақсы. Сұрақ бөлек болса, ағын да бөлек болуы керек.

Дебагтау

Дебаг логтары сәтсіздікті қайта құрып, не дұрыс болмағанын түсіну үшін керек. Әдетте оларға request_id, уақыт, модель, промпт нұсқасы, қате коды, кідіріс, токен саны және маскалау статусы жеткілікті. Мұндай жазбаларды ұзақ сақтамаған дұрыс.

Инцидент талданғаннан кейін шикі сұраудың ұзын тарихы көбіне керек болмай қалады. Практикада жиі промпт хеші, шаблон идентификаторы, модель параметрлері және маскаланған бірнеше қауіпсіз фрагмент жеткілікті.

Аудит

Аудит ағыны қатаң әрі болжамды болуы керек. Онда оқиғалар тізбегі, уақыт, actor_id, policy_id, outcome және trace_id маңызды. Егер сіз деректерді ел ішінде сақтау және аудит-логтарға қойылатын талаптары бар ортада жұмыс істесеңіз, мұндай ағынды бөлек ұстап, техникалық журналдардан ұзағырақ сақтаған дұрыс.

Қауіпсіздік

Қауіпсіздік логтары басқа сұраққа жауап береді: біреу жүйені теріс пайдалануға тырысып жатқан жоқ па. Мұнда сәтсіз кіру әрекеттері, сұраулардың күрт өсуі, rate_limit-ті айналып өту, фильтрлердің іске қосылуы, PII жіберу әрекеттері және кілттер немесе IP бойынша әдеттен тыс үлгілер маңызды. Мұны өнімдік аналитикамен араластырмаңыз.

Аналитика

Аналитика үшін көбіне агрегаттар жеткілікті. Орташа кідіріс, бас тарту үлесі, 1000 сұрауға шаққандағы баға және адамға эскалация жиілігі бөгде диалогтардың архивінен әлдеқайда пайдалы. Шикі мәтіндер мұнда әдетте артық.

Қолдау қызметі үшін де тек ақауды қайта құруға көмектесетін нәрсені қалдырған дұрыс. Банк бот операторы клиенттің бүкіл әңгімесін сирек қажет етеді. Оған request_id, сценарий түрі, қате коды және жүйе карта нөмірін жасырғаны туралы факт маңыздырақ.

Логтауды қалай енгізу керек

Командалар жиі қате жолды таңдайды: бәрін егжей-тегжейлі логтайды да, кейін түсініп алармыз деп үміттенеді. Жұмыс істейтін тәсіл қарапайымырақ. Алдымен шағын лог схемасын жинаңыз, кейін оны нақты инцидентте тексеріңіз.

1. Команда қате себебін таба алмайтын 5-10 оқиғаны жазып шығыңыз. Әдетте мыналар жеткілікті: кіріс сұрау, модель шақыруы, модель жауабы, провайдер қатесі, rate_limit бойынша бас тарту, әкімші әрекеті, маршрутизацияны өзгерту.

2. Әр өріс үшін екі сұрақ қойыңыз: ол не үшін керек және оны кім қарайды. request_id инженерге трассировка үшін керек, timestamp дерлік бәріне қажет, model мен provider шығын мен ақауды талдайтын командаға керек. Егер іздеу үшін жеткілікті болса, user_id-ті хеш түрінде сақтаған дұрыс.

3. Логқа жазар алдында PII-ді маскалауды қосыңыз. Телефон, пошта, ИИН, карта нөмірі, мекенжай және жеке деректері бар еркін мәтін қолданбаның өзінде-ақ кесіліп немесе токенмен ауыстырылғаны дұрыс. Кейінгі тазалау көбіне ақау береді, өйткені шикі жол бірнеше жүйеге үлгеріп түсіп қояды.

4. Әр лог түріне сақтау мерзімін қойыңыз. Дебаг үшін техникалық журналдар жиі 7-14 күн өмір сүреді, қауіпсіздік журналдары ұзағырақ сақталады, ал аудит ішкі саясат пен реттеуші талабына сай ұсталады. Бір мерзімнің бәріне бірдей болуы әдетте қолайсыз.

5. Қысқа тест жасаңыз. Мысалы, бір клиентте қателер күрт өскен инцидентті алып, шикі диалог мәтінінсіз себеп табуға тырысыңыз. Егер сізге request_id, жауап статусы, уақыт, модель маршруты, токен есептегіштері, пайдаланушы хеші және фильтрдің іске қосылғаны туралы белгі жеткілікті болса, схема дұрыс жұмыс істеп тұр.

Егер қолданба мен модель арасында бірыңғай API-шлюз тұрса, барлық кезеңде бірдей request_id ұстаңыз. Сонда команда қолданба, қауіпсіздік және провайдер логтарын бір тізбекке тез біріктіріп, кәдімгі дебаг үшін артық дерек ашпайды.

Мысал: банк қолдау боты

Банк қолдау боты әдетте қарапайым сұрақтарға жауап береді: өтінім мәртебесін қайдан көруге болады, картаны қалай қайта шығару керек, неге төлем өтпеді. Жауап беру үшін ол клиент деректері үшін CRM-ге және ережелер мен нұсқаулықтар үшін білім базасына жүгінеді. Мұндай схемаға лог керек, бірақ толық әңгімені сақтаудың қажеті жоқ.

Минималды лог құрамын жинаған тиімдірек. Ол бот қателессе, тұрып қалса немесе күмәнді жауап берсе не болғанын түсінуге көмектеседі, әрі журналға артық жеке деректерді сүйремейді.

Бір сұрауға арналған жазбада мыналар болуы мүмкін:

• оқиғалар тізбегін құрау үшін request_id
• модель маршруты: қай модель жауап берді және фолбэк болды ма
• latency: жалпы жауап уақыты және қажет болса CRM немесе білім базасын іздеу уақыты
• tool_call статусы: success, error, timeout, blocked
• бастапқы мәтіннің орнына қысқа интент белгісі немесе қалыпқа келтірілген сұрақтың хеші

Егер клиент: «Кіре алмай тұрмын, менің нөмірім 8 777 123 45 67, ИИН 990101300123» деп жазса, қолданба алдымен бұл деректерді маскалайды. Логқа бастапқы жол емес, мысалы, intent=login_problem, phone=8 777 *** ** 67, iin=990101****** сияқты нәрсе түседі. Тіпті жақсысы — егер олар инцидентті талдауға керек болмаса, нөмір мен ИИН-ді мүлде жазбаған дұрыс.

Сол ереже бот жауабына да қатысты. Әңгіме бір күні керек болып қалар деп, толық переписканы сақтаудың мәні жоқ. Аудит үшін әдетте оқиғалар тізбегі жеткілікті: бот сұрауды алды, модель таңдады, CRM-ге жүгінді, timeout алды, білім базасына өтті және қауіпсіз запас жауап берді.

Жауапқа талас туғанда команда request_id арқылы көтеріп, бүкіл чатқа емес, шешім маршрутына қарайды. Көбіне бұл себепті тез табуға жеткілікті. Мысалы, бот лимиттер туралы жалпы жауап берді, өйткені модель бірдеңе ойлап тапқан жоқ, CRM клиент профилін 2,4 секундта қайтара алмады да, жүйе запас сценарийге өтті.

Тәуекелді одан әрі азайтқыңыз келсе, табылған мақаланың мәтінін емес, оның ID-сі мен нұсқасын логтаңыз. Сонда инженер журналда мазмұн көшірмесінсіз-ақ бот қандай материалға сүйенгенін көре алады.

Жиі кездесетін қателер

Ең кең таралған қате — толық промпт пен модельдің толық жауабын логқа жазу. Басында бұл ыңғайлы сияқты көрінеді. Кейін логта келісімшарт нөмірлері, хат алмасу үзінділері, мекенжайлар, диагноздар, ішкі нұсқаулар және құжат бөліктері жиналып қалады. Дебаг үшін әр сұраудың толық мәтіні дерлік ешқашан керек емес. Әдетте промпт нұсқасы, модель атауы, кіріс көлемі, статус, жауап уақыты және бірнеше қауіпсіз флаг жеткілікті.

Екінші мәселе баяу пайда болады. Әзірлеуші сирек кездесетін ақауды ұстау үшін продакшнда debug режимін қосып жібереді де, кейін оны ешкім өшірмейді. Қолмен дебагтау қалыпты жұмыс логтарымен араласып кетеді, шу көбейеді, ал сезімтал деректерге қажеті жоқ адамдар да қол жеткізіп қояды. Екі режимді бөлек ұстаған әлдеқайда дұрыс: әдепкіде қысқа продакшн-логтар және өшірілетін күні анық жазылған уақытша кеңейтілген жинақ.

Тағы бір тұзақ — оқиғалардың ортақ тізбегінің болмауы. Сұрау келді, tool_call CRM-ге барды, кейін модель жауап берді, бірақ ортақ trace_id жоқ. Бір күннен кейін ақау қай жерде болғаны белгісіз болып қалады: оркестрацияда ма, модельде ме, сыртқы сервисте ме, әлде клиент кодында ма. Бір trace_id көбіне сағаттар үнемдейді.

Логтарды мерзімсіз сақтау да проблема тудырады. Команда артық жазба ешкімге кедергі емес деп ойлайды, ішкі аудит немесе деректерді өшіру сұрауы келгенше. Егер debug жеті күн керек болса, оны жарты жыл ұстамаңыз. Егер аудит бір өрістер жиынтығын талап етсе, жанынан қалғанының бәрін тықпаңыз.

Тағы бір жиі қателік: логқа чат мәтіні ғана емес, tool_call параметрлері, ERP-ден келген жауаптың JSON-ы, файл атауы, тіркемеден алынған OCR мәтіні немесе PDF үзіндісі түседі. Шлюз PII-ді маскалап, аудит-логтарды жүргізсе де, қолданбаның өзі өз журналдары арқылы артық дерек шығара береді.

Жылдам өзін-өзі тексеру былай көрінеді:

• кез келген әзірлеуші пайдаланушының толық промптын көреді
• PDF немесе сурет тұтас күйінде логқа жазылады
• debug логтарының өшіру мерзімі жоқ
• бір пайдаланушы сұрауын барлық сервистен қадағалау мүмкін емес
• tool_call CRM немесе биллингтің шикі өрістерін жазады

Егер кемінде екі тармақ сәйкес келсе, логтау жүйесі енді тек көмектесіп тұрған жоқ, тәуекел де тудырып тұр.

Іске қоспас бұрын тексеру

Релизге бір сағат қалғанда лог көлеміне емес, олардың нақты бір сұраумен не болғанын тез жауап беруге көмектесетініне қараңыз. Жақсы логтар бір request_id бойынша анық картинаны береді, жаманы тек тәуекелді жинайды.

Қысқа сынақ жасаңыз. Бір тест сұрауын алып, оның API-ға кіргеннен бастап пайдаланушыға жауап болғанға дейінгі жолы көріне ме, тексеріңіз. Егер сұрау бірнеше қадамнан өтсе, мысалы, деректерді маскалау, модель таңдау және қателерден кейін қайта әрекет жасау, бұл біртұтас әңгіме ретінде оқылуы керек, бір-бірімен байланыссыз жазбалар жиыны ретінде емес.

Іске қоспас бұрын қысқа тізімнен өту пайдалы:

• бір request_id арқылы команда сұраудың бүкіл маршрутын көреді: кіріс, өңдеу, модель шақыруы, жауап және болса, ақау
• логта модель, кідіріс, токен шығыны, шамамен құн және түсінікті қате себебі бар, тек 500 коды ғана емес
• логтарда PII, құпиялар, access token-дар, карта нөмірлері, құпиясөздер және құжаттар мен хат алмасудың толық мәтіні жоқ
• әр лог түріне иесі тағайындалған: кім қарайды, кім қолжетімділікті мақұлдайды және жазбаны қашан жою керек
• команда инцидент кезінде кеңейтілген логтарды қосып, кейін қайтадан қалыпты режимге тез орала алады

Егер тармақтардың бірі орындалмаса, іске қосуды тоқтата тұрған дұрыс. Көбіне мәселе детальда жатады: request_id кірісте бар, бірақ ретрайдан кейін жоғалады; құн бөлек жүйеде есептеледі; қате провайдер мәтінінсіз жазылады; PII-ді маскалау қолданбада жұмыс істейді, бірақ инфрақұрылым логтарында істемейді.

Тағы бір қолмен тексеру жасаған пайдалы. Настройкаға қатыспаған инженер соңғы тәуліктегі бір сәтсіз сұрауды логтар арқылы талдап көрсін. Егер ол 5-10 минутта қай модель жауап бергенін, шақыру қанша уақыт алғанын, неге сәтсіздік болғанын және жүйе қандай деректерді сақтағанын түсінсе, лог жинағы дұрыс құрылған.

Және соңғысы: кеңейтілген логтауды «керек болып қалар» деп қосулы қалдыруға болмайды. Инциденттен кейін команда оны түсінікті процедура бойынша өшіруі керек. Әйтпесе уақытша шара тез арада тұрақты тәуекелге айналады.

Келесі қадам

Жүйені баптаудан бастамаңыз, қарапайым кестеден бастаңыз. Ол LLM-қосымшада нені логтау керегін, қай жерде маскалау керек екенін және нені журналға мүлде жазбаған дұрыс екенін тез көрсетеді. Мұндай кестесіз командалар көбіне артық нәрсе жинайды да, кейін сақтау орнын тазалап, қауіпсіздікпен ұзақ дауласады.

Кестеде әдетте төрт баған жеткілікті:

• өріс немесе оқиға
• оны не үшін сақтау керек
• сақтау мерзімі
• статус: сақтау, маскалау, сақтамау

Оған тек сұрау мен жауап мәтіндерін ғана емес, қызметтік деректерді де қосыңыз: сұрау ID-сі, модель, промпт нұсқасы, жауап уақыты, қате коды, құрал атауы, фильтрдің іске қосылғаны, пайдаланушы немесе сессия хеші. Ал толық құжат нөмірлері, телефондар, карталар, медициналық деректер және жеке деректері бар шикі кіріс көбіне не маскалануы, не мүлде сақталмауы керек.

Содан кейін осы кесте арқылы барлық нақты сценарийді өткізіңіз. Тек чат емес. Құжаттар бойынша іздеуді, агенттік тізбектерді және tool_call-ды бөлек тексеріңіз. Дәл сол жерлерде лог құрамы күткеннен қаттырақ өзгереді.

Мысалы, іздеуде табылған құжаттардың ID-сін және релеванттылық бағасын сақтау пайдалы, бірақ үзінділердің толық мәтінін емес. Агентте құрал шақыруларының тәртібін, таймауттарды және бас тарту себебін көру пайдалы, бірақ CRM құпияларын және ішкі токендердің мазмұнын емес. Мұндай тексеріс артық өрістерді тез табады.

Квартал сайын кестені қайта қарап шығыңыз. Ең жақсы уақыт — инциденттен, ішкі тексеруден немесе аудиттен кейін. Егер қате талдауда бір өріс жетпесе, оны саналы түрде қосыңыз. Егер қандай да бір өріс бірде-бір рет көмектеспесе, алып тастаңыз. Логтар әдет бойынша үлкеймеуі керек.

Егер сізде бірнеше модель мен провайдер болса, логтау мен аудит ережелері бірдей қолданылатын ортақ қабат ұстаған пайдалы. Қазақстан мен Орталық Азиядағы командалар үшін бұл рөлді AI Router атқара алады: бірыңғай OpenAI-үйлесімді эндпоинт, аудит-логтар, PII маскалауы және деректерді ел ішінде сақтау. Бұл провайдерді SDK-ны, кодты және промпттарды қайта жазбай ауыстыру керек болғанда, әрі журналдарды бақылауды жоғалтпау үшін ыңғайлы.

Осы кестеге жауапты адамды тағайындап, бірінші қайта қарау күнін бірден белгілеңіз. Әйтпесе жақсы өрістер тізімі де бірнеше айдан кейін ескіреді.