Eval үшін трассалар экспорты қайталанатын болуы керек

Eval үшін трассалар экспорты қайталанатын болуы керек. Егер аналитик бүгін баяу әрі қымбат сұрауларды іріктеп, ал инженер ертең сол trace_id жиынтығын қайта ала алмаса, бұл бағалауға арналған датасет емес. Мұндай бір реттік топтама арқылы модельдерді, промпттарды және маршруттарды сенімді салыстыру мүмкін емес.

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

Іріктеу контракты қажет. Ол eval-ге қандай аяқталған пайдаланушы трассалары кіретінін, іріктеуді қандай өрістер түсіндіретінін және экспорт жиынтықты алмастырмағанын қалай тексеру керегін белгілейді. Мұндай контракт жаңа модельдің басқа датасетте неге «жақсарғаны» туралы алғашқы дау туғанға дейін ғана қызықсыз көрінеді.

Іріктеу бірлігі пайдаланушы трассасы болуы керек

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

Бір LLM тапсырмасы әдетте ағаш қалдырады: кіріс HTTP сұрауы, жіктеу, retrieval, бір немесе бірнеше модель шақыруы, tool calls, қайталама әрекеттер, кейінгі өңдеу және жауап жіберу. Егер еншілес спандарды алсаңыз, бір сәтсіз тапсырма бес жолға айналады. Жиынтық техникалық жағынан күрделі сұрауларға қарай ауытқиды, ал бағалаушы пайдаланушы көрген нәтижені емес, жеке бөліктердің сапасын есептей бастайды.

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

Түбір спанға тұтас тапсырмаға қатысты ең аз өрістер жиынтығын қосыңыз:

• app.scenario, мысалы support_rag, document_extract немесе agent_action;
• қолданбалы контурда бұрыннан бар болса, app.request_id;
• gen_ai.operation.name немесе операцияның жеке өрісі;
• мағынасына қарай кейбір сұрауларды бағалауға қолдануға болмайтын болса, app.eval.eligible;
• қолданба немесе промпт нұсқасының идентификаторы, бірақ оны сценарий түрінің орнына қолданбаңыз.

app.scenario өрісіне модельдің, провайдердің немесе нақты маршрут URL-інің атын жазбаңыз. Сценарий пайдаланушының не істеуге тырысқанын сипаттайды. Модель мен маршрут жүйенің мұны қалай орындағанын сипаттайды. Оларды араластырсаңыз, модель ауысқаннан кейін бір сценарий ішіндегі ескі және жаңа деректерді салыстыру мүмкіндігін жоғалтасыз.

Тағы бір жиі кездесетін қате - асинхронды жұмысты HTTP трассасының жалғасы ретінде кез келген жағдайда көрсету. Егер кезек өңдеушіні кейін іске қосса, жеке трасса жасап, оны бастапқы трассамен span link немесе қолданбалы request_id арқылы байланыстырыңыз. Сонда HTTP сұрауының түбірлік уақыты мен фондық өңдеу уақыты бір кідіріс болып көрінбейді.

Сүзгі өзгермейтін контракт ретінде сипатталуы керек

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

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

selection_id: eval-support-rag-slow-errors-v3
source_window:
  started_at_gte: "2026-06-01T00:00:00Z"
  started_at_lt: "2026-06-08T00:00:00Z"
unit: root_trace
where:
  scenario_in:
    - support_rag
  completed: true
  environment: production
  latency_ms_gte: 8000
  total_cost_usd_gte: 0.02
  outcome_in:
    - success
    - terminal_error
exclude:
  - synthetic_traffic
  - deleted_user_data
  - missing_root_input
pricing_version: provider-rates-2026-06-01
schema_version: trace-eval-v2

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

«Қымбат трассалар» немесе «проблемалы жауаптар» сияқты анық емес тұжырымдарға жол бермеңіз. Әр шектің өлшем бірлігі мен қосу ережесі болуы керек. latency_ms_gte: 8000 кідірістің кемінде 8 000 миллисекунд екенін білдіреді. «Шамамен сегіз секунд» деген тіркес бір сұрау бір экспортқа кіріп, қайта іске қосқанда кірмей қалған жағдайда ештеңе білдірмейді.

Уақыт шекарасын бөлек бекітіңіз. «1-7 маусым аралығы, екі күн де қоса» дегеннен гөрі [started_at_gte, started_at_lt) жартылай ашық диапазонын қолданыңыз. Мұндай диапазон апталық экспорттарды біріктіргенде жазбаларды қайталамайды және нақты жүйенің тәулік соңын қалай түсіндіретініне тәуелді болмайды.

Құн бүкіл трассаға тиесілі болуы керек

Құн бойынша сүзгі пайдаланушы тапсырмасына жұмсалған ақша туралы сұраққа жауап бергенде пайдалы. Бір model span бағасы бұдан тар сұраққа жауап береді: нақты бір шақыру қанша тұрды. Бұл сандарды бір-бірімен алмастыруға болмайды.

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

Бірақ әр техникалық спанның құнын қоспаңыз. Бір шақыру HTTP client span, SDK спаны және орамадағы жеке спан ретінде көрінуі мүмкін. Бір канондық есеп қабаты қажет. Әдетте бұл model call ID, кіріс және шығыс токендерін, валютаны және есеп айырысу фактісін білетін қолданбалы спан. Қалған спандарды диагностикаға қалдырыңыз.

Өрістердің практикалық схемасы мынадай:

{
  "trace_id": "9df1...a02c",
  "app.scenario": "support_rag",
  "usage.input_tokens": 1842,
  "usage.output_tokens": 516,
  "cost.amount": 0.02384,
  "cost.currency": "USD",
  "cost.pricing_version": "provider-rates-2026-06-01",
  "billing.call_id": "call_01J..."
}

Тек бірегей billing.call_id мәндерін қосыңыз. Идентификатор жоқ болса, алдымен құралдардағы бақылауды түзетіңіз. Уақыт, модель және токен санының жұбы бойынша дедупликация ескі деректерді кейде құтқарады, бірақ бұл сенімді есеп емес: екі бірдей сұрау бір миллисекунд ішінде орындалуы мүмкін.

Нөлдік құн да түсіндіруді қажет етеді. Ол жергілікті open-weight модельді, кэштелген жауапты, тест маршрутын немесе жай ғана толтырылмаған өрісті білдіруі мүмкін. Бұл мәндерді араластырмаңыз. cost.accounting_state өрісіне billed, estimated, cached, local, unknown мәндерін енгізіңіз. Ақша бойынша шекті сүзгіге тек billed және команда ережелері рұқсат етсе, estimated кірсін. unknown мәні нөл ретінде байқатпай өтіп кетпеуі керек.

AI Router әртүрлі провайдерлерге OpenAI-мен үйлесімді бірыңғай жол ұсына алады, бірақ құнды біріктіру ережелері бәрібір сіздің қолданбаңызға және іріктеу контрактыңызға тиесілі. Маршруттау тариф нұсқасын және әр ақылы шақырудың идентификаторын бекіту қажеттілігін жоймайды.

Шекарасы жоқ кідіріс кездейсоқ фрагментті өлшейді

Өнімдік eval үшін трасса кідірісі түбірлік пайдаланушы сұрауы басталған сәттен соңғы нәтиже немесе терминалды бас тарту пайда болғанға дейінгі уақытқа тең. Пайдаланушы жүйенің баяулығын осы сан арқылы бағалайды.

Бір трасса ішінде тағы бірнеше уақытты сақтаған пайдалы: model_latency_ms, retrieval_latency_ms, tool_latency_ms, queue_wait_ms. Олар себептерді түсіндіреді, бірақ end_to_end_latency_ms өрісін алмастырмайды.

Есептеу ережесі ретрайлермен жұмыс істеуі керек. Сұрау 10:00:00-де басталып, іздеу 300 мс, модельдің алғашқы шақыруы 4 000 мс кейін таймаутпен аяқталып, екіншісі 3 500 мс ішінде жауап беріп, кейінгі өңдеу 200 мс алсын. Пайдаланушы шамамен 8 000 мс күтті, 3 500 мс емес. Экспортқа толық кідірісті, әрекет санын және бір model call ең ұзақ уақытын қосыңыз. Сонда баяу жауаптардың сапасын бөлек бағалап, кідірісті модель, желі немесе қайталау тудырғанын түсінесіз.

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

OpenTelemetry sampling шешімін трассаның басында қабылдап, оны әрі қарай таратуды ұсынады. Бұл өндірістік телеметрия үшін пайдалы, бірақ eval үшін іріктеу мәселесін шешпейді: head sampling сирек кездесетін қымбат қатені оның құны мен кідірісін білмей тұрып алып тастауы мүмкін.

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

Телеметриядағы қате мен нашар жауап бір нәрсе емес

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

Бұл кластарды бөлек сақтау керек. Түбір трасса үшін әдетте outcome өрісіне success, terminal_error, cancelled, policy_blocked және partial мәндерін қолданамын. Бұған қоса пайдаланушы, автоматты тексеруші немесе қолмен белгілеу берген болса, quality_signal өрісін қосамын. Quality signal жоқтығын жақсы жауаптың белгісіне айналдырмаңыз.

OpenTelemetry құжаттамасында қателерді жазу туралы айтылғандай, әр статус коды қателерді бірдей білдірмейді. HTTP 404 қолданба ресурс күтсе, проблема болуы мүмкін, ал оның бар-жоғын тексеру қалыпты нәтиже болса, қате емес. Сондай-ақ ақау өңделіп, жүйе жұмысын штаттық түрде аяқтаған операцияны қате ретінде жазбауға кеңес беріледі.

LLM қолданбасы үшін салдары айқын. Модельдің алғашқы шақыруындағы қателіктен кейін fallback пайдаланушыға дұрыс жауап берсе, түбір трассаны terminal_error деп белгілемеу керек. Әрекет оқиғасы мен retry_count мәнін сақтап, түбір нәтижені success күйінде қалдырыңыз. Әйтпесе «қателер» жиынтығына пайдаланушылар қалыпты алған сұраулар кіріп кетеді.

Екінші жағынан, HTTP жауабы 200 кодымен жіберілгені үшін түбірге OK қоймаңыз. API finish_reason=error бар құрылымды жауап қайтарса, агент қадамдар шегіне жетсе немесе валидатор нәтиже қабылдамаса, бұл қолданбалық сәтсіздік. Тасымалдау мінсіз жұмыс істесе де, оған жеке outcome қажет.

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

Сценарий түрін модель атағынан қалпына келтіруге болмайды

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

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

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

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

Әр сценарий үшін пайдалы ең аз сипаттама:

• күтілетін нәтиженің анықтамасы;
• қажет кіріс өрістері және рұқсат етілген бүркемелер;
• автоматты немесе қолмен бағалау тәсілі;
• күтілетін бас тарту кластары;
• қандай tool calls пен retrieval контекстін сақтау керегінің ережесі.

Бұл спецификация тағы бір қымбат қатеден қорғайды: команда тартымды жиынтық экспорттағанымен, белгі қоюшыға дұрыс жауап деп нені санау керегін түсіндіре алмайды.

Алдымен идентификаторларды таңдаңыз, кейін мазмұнды шығарыңыз

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

Бірінші кезең толық prompt, completion, retrieval құжаттары мен stack trace оқымауы керек. Ол уақыт, сценарий, орта, жиынтық кідіріс, жиынтық құн, outcome және қажетті мазмұнның бар-жоғы сияқты индекстелетін бағандармен жұмыс істейді.

WITH selected AS (
  SELECT
    trace_id,
    app_scenario,
    started_at,
    end_to_end_latency_ms,
    total_cost_usd,
    outcome,
    retry_count
  FROM trace_roots
  WHERE started_at >= TIMESTAMP '2026-06-01 00:00:00+00'
    AND started_at < TIMESTAMP '2026-06-08 00:00:00+00'
    AND environment = 'production'
    AND completed = TRUE
    AND app_scenario = 'support_rag'
    AND end_to_end_latency_ms >= 8000
    AND total_cost_usd >= 0.02
    AND outcome IN ('success', 'terminal_error')
    AND synthetic_traffic = FALSE
    AND root_input_available = TRUE
)
SELECT * FROM selected;

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

Дәл осы жерде деректердің байқатпай жоғалуы жиі болады. Мысалы, export job prompt кестесімен inner join қолданады. Сақтау саясаты бойынша prompt өшірілген трассалар жоғалады. Аналитик «дайын жиынтық» алады, бірақ ол сүзгіден өткен бастапқы жиынтық емес. Дұрыс әрекет басқа: left join, payload_state=missing_or_redacted өрісі және толық болмау себептері туралы жеке есеп.

Пайдалы жүктемелер белгі қоюшыларға немесе сыртқы бағалаушыға берілмес бұрын бүркемеленуі керек. Бұл тек ат пен телефонға қатысты емес. LLM контекстінде PII еркін мәтінде, құрал JSON-ында, URL-де, файл атауында және қате хабарында жасырынуы мүмкін. Бастапқы деректерді бақыланатын контурда сақтап, export record ішіне бүркемеленген өрістер мен бүркемелеу ережесінің нұсқасын салыңыз.

Іріктеу құрамын тексеру жолдардың ауысуын анықтауы керек

«CSV-де сұрау қайтарғандай жол саны бар» деген тексеріс тым әлсіз. Ол бір trace_id жоғалып, екіншісі қосылғанын, дубликат бірегей трассаны ығыстырғанын немесе job көрші уақыт аралығынан дерек экспорттағанын байқамайды.

Бірінші кезеңнен кейін іріктеу манифесін жасаңыз. Ол әр экспортқа, тіпті айына бір рет қолмен жасалатын экспортқа да қажет.

{
  "selection_id": "eval-support-rag-slow-errors-v3",
  "schema_version": "trace-eval-v2",
  "source_window": {
    "started_at_gte": "2026-06-01T00:00:00Z",
    "started_at_lt": "2026-06-08T00:00:00Z"
  },
  "trace_count": 184,
  "unique_trace_count": 184,
  "trace_id_sha256": "sha256(sorted trace_id values)",
  "filter_sha256": "sha256(canonical selection yaml)",
  "pricing_version": "provider-rates-2026-06-01",
  "payload_policy_version": "redaction-v4"
}

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

Екінші кезеңнен кейін төрт мәнді салыстырыңыз:

• тізілімдегі және export record ішіндегі жолдар саны;
• бірегей trace_id саны;
• сұрыпталған trace_id тізімінің бақылау хеші;
• пайдалы жүктеменің толық болмау себептерінің таралуы.

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

Идемпотенттілік тестін қосыңыз. Бір дерек snapshot-ында экспортты екі рет іске қосып, манифестерді салыстырыңыз. Идентификатор хеші өзгерсе, себеп көбіне қалқымалы now(), ORDER BY-сыз детерминирленбеген лимит, жаңартылып тұратын тариф кестесі немесе жолдарды көбейтетін join болады.

Сүзгіден кейінгі кездейсоқ іріктеу стратификацияны қажет етеді

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

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

Әр жол үшін trace_id және бекітілген seed негізінде алынған детерминирленген кездейсоқ сан қосыңыз. Содан кейін әр страта ішінде осы сан бойынша қажетті жол санын таңдаңыз. Қайта іске қосқанда сол seed дәл сол жиынтықты береді, ал жаңа seed сақтау ретіне жасырын тәуелсіз басқа жиынтық жасайды.

Манифестте sampling_method, sampling_seed және страталар квотасын сақтаңыз. Кандидаттардың толық тізілімін бөлек сақтаңыз. Сонда команда екі түрлі сұраққа жауап бере алады: «қандай трассалар шарттарға сай болды?» және «олардың қайсысы қолмен eval-ге кірді?» Бұл бір нәрсе емес.

Экспортты eval пайплайнының бөлігі ретінде тестілеу керек

Трасса экспорты тек нашар SQL кесірінен бұзылмайды. Оны схеманың жаңа нұсқалары, атрибуттардың қайта аталуы, redaction өзгерісі, кеш келген спандар, нәтиженің жаңа түрлері және «таза дерек» үшін left join-ды inner join-ға ауыстырған әзірлеуші де бұза алады.

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

Пайплайн мыналарды растауы керек:

• сүзгі тек аяқталған түбір трассаларды таңдайды;
• ретрайлер бір трассаға біріктіріліп, құнды қайталамайды;
• unknown ақша шегіне нөл ретінде кірмейді;
• full export мазмұн жоқ болса да тізілімдегі барлық trace_id мәндерін сақтайды;
• бір snapshot-тағы қайталама іске қосу сол manifest hash мәнін береді.

Бұл тестілерді көлем мониторингімен алмастырмаңыз. «Бүгін кеше сияқты жол саны экспортталды» метрикасы құрамның өзгеруін ұстамайды. Жақсы жүйе манифесті, страталар бойынша diff-ті және толық емес пайдалы жүктемелер есебін өзі жариялайды.

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

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