Trace және eval арқылы нашар жауапты қалай қайталап шығаруға болады

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

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

Eval нақты бір іске қосуға сілтеме жасауы керек

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

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

Әр бағалауда екі сілтеме болуы керек:

• пайдаланушы сұрауының түбір трассасына апаратын trace_id;
• бағаланған қадамға апаратын target_span_id: соңғы жауап, іздеу, құрал шақыруы немесе классификация.

Түбір трасса «сұрауды өңдеу кезінде не болды?» деген сұраққа жауап береді. Мақсатты span басқа сұраққа жауап береді: «дәл не бағаланды?» Бір пайдаланушы сессиясында бірнеше генерация болуы мүмкін. Мысалы, агент алдымен әрекеттерді жоспарлайды, кейін ішкі каталогқа сұрау жібереді, содан соң клиентке жауап жазады. Соңғы жауаптың сапа белгісін модельдің жоспарлау шақыруына тіркеуге болмайды.

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

Phoenix құжаттамасы пайдалы бөліністі дәл сипаттайды: трассалар іске қосу кезінде не болғанын көрсетеді, ал eval сапа туралы қайталанатын сигнал қосады. Бұл дұрыс, бірақ практикада тағы бір қадам қажет: бағалау іске қосуға әсер еткен себептік артефактілердің толық жиынтығына сілтеме жасауы керек. Әйтпесе ол сапа графигіне жарайды, бірақ инженерлік жұмысқа нашар көмектеседі.

Талдау бірлігі диалог емес, run

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

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

Мысалы, пайдаланушы: «Депозитті пайыздан айырылмай мерзімінен бұрын жабуға бола ма?» деп сұрайды. Қолданба сұрауды қалыпқа келтіреді, ережені іздейді, өнімді тексеру құралын шақырады және жауап жасайды. Жауап қате болса, талдауға «бір күндегі чат хабарламалары» емес, барлық еншілес операциялары бар бір run керек.

Қайталап жіберілген әрекетті сол run деп санамаңыз. Модельге сұрау жіберілгеннен кейін желі үзіліп, клиент сұрауды қайта жіберсе, жаңа run_id жасаңыз, бірақ parent_run_id немесе retry_of_run_id мәнін сақтаңыз. Әйтпесе статистика техникалық ақауды тәуелсіз пайдаланушы сұрауымен араластырады, ал eval екі әрекетті бір бақылау ретінде есептей бастайды.

Идентификаторлардың пайдалы минималды жиынтығы:

• бизнес операциясына арналған run_id;
• телеметрия ағашына арналған trace_id;
• жеке әрекетке арналған span_id;
• сыртқы HTTP шақыруына арналған request_id;
• тарих жауапқа әсер етсе, сессияға арналған conversation_id.

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

Схема әзірлеушінің ниетін емес, нақты кірістерді сақтауы керек

Әзірлеушінің ниеті былай көрінеді: «біз қолдау промптын, X моделін, білім базасы бойынша іздеуді және 0,2 температурасын қолданамыз». Нақты іске қосу мүлде басқаша болуы мүмкін. Роутер қолжетімді басқа модельді таңдады, промпт өзекті белгі бойынша қойылды, іздеу бөлім сүзгісін қолданды, ал SDK max_tokens параметрін орта айнымалысынан алды.

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

Төменде соңғы генерацияға арналған минималды пакет берілген. Өрістерді трассалар қоймасы, артефактілер каталогы және eval базасы арасында бөлуге болады, бірақ олардың байланысы тікелей болуы керек.

{
  "run_id": "run_01JQ8K7C4V",
  "trace_id": "4bf92f3577b34da6a3ce929d0e0e4736",
  "span_id": "00f067aa0ba902b7",
  "started_at": "2026-07-23T14:18:09Z",
  "application": {
    "name": "deposit-assistant",
    "release": "2026.07.23.4",
    "environment": "production"
  },
  "prompt": {
    "name": "deposit-answer",
    "version_id": "prv_8d7f5a",
    "template_sha256": "2d3a...91c4",
    "rendered_messages_ref": "artifact://runs/run_01JQ8K7C4V/messages.json"
  },
  "generation": {
    "requested_model": "reasoning-model",
    "resolved_model": "provider/model-revision",
    "provider": "provider-name",
    "temperature": 0.2,
    "top_p": 1.0,
    "max_output_tokens": 700,
    "seed": 18421,
    "response_format": "text"
  },
  "retrieval_ref": "artifact://runs/run_01JQ8K7C4V/retrieval.json",
  "tool_calls_ref": "artifact://runs/run_01JQ8K7C4V/tools.json",
  "output_ref": "artifact://runs/run_01JQ8K7C4V/output.json"
}

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

Артефакт сілтемесін мәтіннің өзінен бөлек сақтаңыз. Шағын әрі қауіпсіз метадеректерді тікелей трассадан іздеу ыңғайлы. Толық prompt, табылған құжаттар және құрал жауаптары көлемді әрі сезімтал болуы мүмкін. Оларды қолжетімділікті басқару, бақылау қосындысы және жою мерзімі бар қорғалған қоймада сақтаған дұрыс. Трасса артефактіні тауып, оның өзгермегенін тексеруге жеткілікті ақпаратты қамтуы керек.

OpenTelemetry-дің GenAI semantic conventions құжатында дәл осындай санаттар сипатталған: кіріс және шығыс хабарламалары, провайдер атауы, сұралған және қайтарылған модель, токен лимиттері, іздеу құжаттары, құрал шақыруларының аргументтері мен нәтижелері. Стандарт ортақ сөздік ретінде пайдалы. Оған барлық домендік мәліметті сыйғызуға тырыспаңыз. Индекс нұсқасы, қолжетімділік саясаты, шаблон идентификаторы және бағыттау себебі үшін жеке атрибуттар қосыңыз.

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

Промпт атауы оны қайталап шығаруға мүмкіндік бермейді. production белгісі де промптты қайталамайды. Тіпті Git коммиты да әрдайым жеткіліксіз, себебі шаблон бөлек сервистен жүктеліп, айнымалылар бірнеше конфигурациядан жиналуы мүмкін.

Кемінде үш нәрсені сақтаңыз: логикалық атау, өзгермейтін version_id және дәл шаблоннан есептелген бақылау қосындысы. Талдау үшін айнымалылар қойылғаннан кейінгі рендерленген хабарламаларды да сақтаңыз. Нұсқа қай шаблонның қолданылғанын түсіндіреді. Рендерленген хабарламалар модельдің нақты не көргенін түсіндіреді.

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

«Тыныш» өзгерістер аса қауіпті. Команда әкімшілік панель арқылы жүйелік нұсқау мәтінін өзгертіп, промпт атауын сол күйі қалдырады және нұсқаны жаңартпайды. Бір аптадан кейін eval сапаның төмендегенін көрсетеді, бірақ жақсы және нашар жауаптарды салыстыру мүмкін болмайды. Олардың бәрі ресми түрде бір промптқа жатады.

Төреші промптына да осындай тәртіп керек. Егер LLM-as-a-judge жауаптың толықтығын бағаласа, оның рубрикасы, моделі және параметрлері өлшеу әдістемесінің бір бөлігі болады. Рубриканы үнсіз өзгертіп, кейін шкала өзгермегендей, өзгеріске дейінгі және одан кейінгі бір графикті салуға болмайды. Бұл өнім сапасының жақсаруы емес, өлшеу құралын ауыстыру.

Іздеу құжаттарын ранжирлеуден кейін бекіту керек

RAG жүйесі іздеу өзекті емес құжатты қайтарғандықтан ғана істен шықпайды. Ол құжат өзекті болғанымен ескі болса; қажетті үзінді алтыншы орында тұрып, prompt-қа алғашқы төртеуі кірсе; қолжетімділік сүзгісі өзекті саясатты алып тастаса; жүйе маңызды ерекшелікке дейінгі чанкты кесіп тастаса да істен шығады.

Сондықтан іздеу жазбасы векторлық базаға жіберілген сұрауды ғана емес, контекстің соңғы жиынтығын көрсетуі керек. Іздеу сұрауының бастапқы мәтінін, индекс атауы мен ревизиясын, сүзгілерді, ранжирлеу алгоритмін, rerank-тен кейінгі реттелген кандидаттар тізімін және prompt-қа нақты енгізілген чанктар тізімін сақтаңыз.

Әр енгізілген чанк үшін мыналар қажет:

• тұрақты document_id және chunk_id;
• мәтін нұсқасы немесе бақылау қосындысы;
• алғашқы іздеу бағасы және болса, rerank бағасы;
• соңғы контекстегі орны;
• кандидат модельге жетпесе, оның шығарылу себебі.

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

Eval-ды жиі бұзатын тағы бір айырмашылық бар. Құжаттың өзектілігі мен соңғы жауаптың дұрыстығы екі түрлі нәрсені өлшейді. Құжат тақырып жағынан жақын болғанымен, жауапқа қажет шартты қамтымауы мүмкін. Керісінше, жақсы құжаттар жиынтығы модельдің дұрыс ережеге сілтеме жасайтынына кепілдік бермейді. Phoenix құжаттамасы чанктар бойынша retrieval eval мен жүйелік Q&A бағалауын бөлек көрсетеді. Бұл бағалауларды бөлек ұстаңыз және екеуін де бір run-мен байланыстырыңыз.

Соңғы жауап қате болса, «Модель тек берілген контекстке сүйеніп дұрыс жауап бере алар ма еді?» деген сұрақтан бастаңыз. Егер жауап жоқ болса, жүйелік нұсқауды қайта жазуға бір күн жұмсамаңыз. Индексті, сүзгілерді, бөлуді, rerank-ті немесе білім базасының қамтуын түзетіңіз.

Құралдарға тек нәтиже емес, себептер журналы да керек

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

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

Типтік ақауды қарастырайық. Агент get_deposit_terms құралын өнім кодымен шақыруы керек. Модель кодты тарихтан алып, DP-018 мәнін жібереді. Құрал ескі өнім шарттарын қайтарады, себебі сервис ескірген алиасты қабылдаған. Агенттің жауабы ұқыпты көрінгенімен, онда қате ереже бар. Трассада тек «құрал сәтті орындалды» деген жазба болса, талдау тығылады. Аргумент, қалыпқа келтірілген жауап және анықтамалық нұсқасы сақталса, себеп бірден көрінеді.

Құпияларды жөндеу үшін төленетін «баға» ретінде сақтамаңыз. Құрал шақыруларында токендер, шот нөмірлері және жеке деректер жиі болады. Жазбас бұрын өрістер бойынша бүркемелеу схемасын қолданыңыз. account_number өрісін тұзы бар тұрақты хешке ауыстыруға болады, сонда нөмірді ашпай, жүгінулерді салыстыру мүмкін болады. authorization өрісі трассаға мүлде түспеуі керек.

Агент жоспарлаған, бірақ орындамаған шақыру да дерек болып саналады. Әрекетті таңдау үшін span немесе оқиға қосыңыз: қолжетімді құралдар, таңдалған құрал, бас тарту себебі және итерациялар лимиті. Бұл «құрал қате жауап қайтарды» дегенді «модель құрал қажет емес деп шешті» дегеннен ажыратуға көмектеседі.

Қайталап шығару пакеті продакшннан тыс іске қосылуы керек

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

Трассадан іске қосу манифесі мен тәуелділіктер снимогы бар пакет жинаңыз. Пакетке бүкіл observability қоймасын көшірудің қажеті жоқ. Жауаптың мағынасы өзгермеуі үшін қажет артефактілер ғана керек.

{
  "replay_version": 1,
  "source_run_id": "run_01JQ8K7C4V",
  "mode": "offline",
  "messages": "artifacts/messages.json",
  "retrieval": "artifacts/retrieval-final.json",
  "tool_transcript": "artifacts/tool-transcript.json",
  "generation": {
    "model": "provider/model-revision",
    "temperature": 0.2,
    "top_p": 1.0,
    "max_output_tokens": 700,
    "seed": 18421
  },
  "side_effect_policy": "deny",
  "expected": {
    "evals": ["groundedness=fail", "answer_correctness=fail"],
    "output_sha256": "optional"
  }
}

offline режимінде іздеу ағымдағы индекске жүгінбей, retrieval-final.json файлын оқиды. Құралдар продакшн сервистерін шақырмай, tool-transcript.json ішіндегі сақталған жауаптарды қайтарады. Бұл продакшнды әдемі көрсету үшін жасалған имитация емес. Бұл бұрын қабылданған шешімді деректердің қазіргі күйінен оқшаулау тәсілі.

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

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

Мәтіннің сәйкес келуі жалғыз өлшем емес

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

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

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

Seed көмектеседі, бірақ бірдейлікке кепілдік бермейді. Ол модельдің жаңартылуын, провайдердің жүйелік қабатын өзгертуін, батчинг ретіндегі айырмашылықты және іске асыру ерекшеліктерін жоймайды. seed өрісін бәрібір сақтаңыз: ол айнымалылар санын азайтып, айырмашылықтарды анық көруге мүмкіндік береді.

Егер дәл replay нәтижесі өзгеше болса, талдауды «модель детерминирленбейді» деген сөзбен жаппаңыз. Алдымен манифесттерді салыстырыңыз. Айырмашылық көбіне бір өрісте жасырынады: жаңа max_output_tokens, басқа жауап схемасы, өзгертілген құралдар тізімі, қосылған тарих немесе үйлесімді сұрауды қабылдағанымен, оны модельдің басқа ревизиясына жіберген провайдер.

Eval түзету бағытын көрсетуі керек

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

Мысалы, RAG жүйесінің жауабы үшін бес санаттан бастау жеткілікті:

• retrieval_missing: контексте жауапқа қажет материал жоқ;
• retrieval_wrong: контексте жарамсыз немесе ескірген материал бар;
• tool_failure: құрал қате, ескірген дерек қайтарды немесе аргументті қате түсіндірді;
• generation_ungrounded: қажетті фактілер контексте болды, бірақ модель оларды бұрмалады немесе елемеді;
• policy_failure: жауап формат, қауіпсіздік немесе рұқсат етілген әрекеттер ережесін бұзды.

Бір run бірнеше белгі алуы мүмкін. Бұл қалыпты жағдай. Іздеудегі қате құжат негізсіз генерацияға да әкелуі мүмкін. Трассада себептер тізбегі көрініп тұрса, белгілеушіні бір ғана «негізгі» себепті таңдауға мәжбүрлемеңіз.

Санаттарды әрекеттермен байланыстырыңыз. retrieval_missing мысалды білім базасын толықтыру кезегіне немесе іздеуді жақсартуға арналған сұраулар жиынына жібереді. tool_failure аргументтер мен жауап снимогымен бірге интеграция иесіне барады. generation_ungrounded промпт, модель және декодтау нұсқалары үшін тест жағдайына айналады. Осылайша eval метрикалар витринасы болудан қалып, инженерлік циклдің кірісіне айналады.

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

Сақтау мерзімі мен бүркемелеу трассаның құндылығын анықтайды

LLM қолданбасының толық трассасы сезімтал контенттің архивіне тез айналады. Онда пайдаланушы сұрағы, хабарламалар тарихы, табылған құжаттар, функция аргументтері және жауап болады. Мұның бәрін қолжетімділік пен жою ережесінсіз жинау қауіпті. Ал ештеңе жинамау командаға инциденттерді талдау мүмкіндігін бермейді.

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

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

Деректерді Қазақстанда сақтауы маңызды командалар үшін AI Router модель шақырулары мен телеметрияны бақылау архитектурасының бөлігі бола алады, бірақ қайталап шығару схемасы қолданбаның өз міндеті болып қалады. Нақты провайдерді, модельді және бағытты нашар жауаппен байланыстыруға болмайтын бөлек биллинг есебінде емес, run жанында сақтаңыз.

Команда бір сағат ішінде түсіндіре алмаған бір нақты ақаудан бастаңыз. Оның trace-ын алыңыз, жетіспейтін өрістерді қосыңыз, offline replay жинаңыз және оған бір адам бағасын және бір автоматты eval-ды байланыстырыңыз. Осыдан кейін қазір қандай деректерді жоғалтып жатқаныңыз және келесі инцидентте қай өрістер бірнеше күндік жұмысты үнемдейтіні анық көрінеді.