LLM-трассаларға tail based sampling не үшін керек?

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

Tail based sampling осы теңсіздікті түзетеді. Алдымен жүйе трассаның соңғы нәтижесін көру үшін жеткілікті spans жинайды. Содан кейін қымбат, баяу немесе бұзылған трассаны толық сақтайды, ал қалыпты ағынның аз ғана бөлігін қалдырады. Бұл «сақтау орнын үнемдеудің» тәсілі емес. Бұл тергеуге қажет материалды тастауды тоқтатудың жолы.

LLM үшін бұл тәсіл көптеген кәдімгі HTTP-сервистерге қарағанда тиімдірек. Себебі сұраудың қорытындысы соңында белгілі болады: модель мен маршрут, токендер саны, нақты құн, қайталау саны, агенттің соңғы күйі және әр tool call нәтижесі көрінеді. Head sampling шешімді тым ерте қабылдайды. Ол бастапқыда тыныш көрінген сұраудың екі секундтан кейін күндегі ең қымбат жағдайға айналатынын білмейді.

Tail sampling уәдені емес, нәтижені таңдайды

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

Tail sampler коллекторда жұмыс істейді. Ол spans-тарды trace_id бойынша жинайды, белгіленген уақытты күтеді, жиналған трассаны бағалайды және оның барлық spans-ын немесе ешқайсысын жібереді. OpenTelemetry Collector Contrib құжаттамасында тиімді шешім қабылдау үшін бір трассаның барлық spans-ы бір коллектор экземплярына түсуі керек деп нақты көрсетілген. Құжаттама кідіріс, статус коды, жолдық және сандық атрибуттар, логикалық белгілер, spans саны, ықтималдық және ағынды шектеу бойынша ережелерді де сипаттайды.

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

Tail sampling-тің өз құны бар. Коллектор аяқталмаған трассаларды уақытша сақтайды, шешімді кідіріспен қабылдайды және мұқият бағыттауды талап етеді. Орташа кідіріс қана қажет қызметтік endpoint үшін бұл артық болуы мүмкін. Агенттік тізбектер, RAG, төлем тексерістері, медициналық кеңестер және қымбат генерациялар үшін мұндай шығын әдетте ақталады.

Tail sampling-ті әр prompt-ты журналдаумен шатастырмаңыз. Трассаны таңдау «қай операцияны сақтау керек?» деген сұраққа жауап береді. Деректер саясаты басқа сұрақты шешеді: «қай өрістерді коллекторға жіберуге болады?». Екінші сұрақ біріншісінен бұрын шешілуі тиіс.

p99 ережеге сиқырлы сан ретінде жазылмайды

«p99-ды сақтаймыз» деген сөз нақты естіледі, бірақ конфигурацияда ол жиі қателікке айналады. p99 бір бақылаудың қасиеті емес, белгілі бір кезеңдегі бақылаулар жиынының қасиеті. Ұзақтығы 4,2 секунд болатын span-ға терезе, салыстыру тобы және үлестірім анықталмайынша p99 деп айтуға болмайды.

Барлық LLM сұрауларын бір p99 арқылы салыстыру әсіресе зиянды. Қысқа түйіндеме жасау мен келісімшартты көп қадаммен тексерудің қалыпты ұзақтығы әртүрлі. Жылдам модель мен reasoning моделі де бөлек үлестірімдерде жұмыс істейді. Оларды араластырсаңыз, шек бір ағын үшін тым төмен, ал екіншісі үшін мағынасыз жоғары болады.

Алдымен семплингке дейін кідіріс метрикаларын ең қажетті өлшемдермен құрыңыз:

• operation.name, мысалы support.reply немесе contract.check;
• модельдер тобының немесе маршрут класының идентификаторы;
• операция түрі: генерация, embedding, rerank, tool execution;
• нәтиже коды.

OpenTelemetry Span Metrics Connector spans-тардан сұраулар, қателер және ұзақтық метрикаларын агрегаттайды. Кейін қай толық трассаларды сақтағаныңызға қарамастан, квантильдерді есептеуге жарайды.

Одан кейін талдау нәтижесін жұмыс шегіне айналдырыңыз. Мысалы, команда аптасына бір рет нақты маршруттағы contract.check үшін құйрықтағы шектік кідіріс 8 секунд екенін көреді. Бұл «мәңгілік p99» емес. Бұл модельді, провайдерді, кэшті немесе workflow-дың өзін өзгерткенде қайта қаралатын ағымдағы пайдалану шегі.

Түбірлік span-ға өлшенген ұзақтықты жазыңыз, ал ыңғайлы болу үшін қолданба немесе processor есептейтін белгі қосыңыз:

llm.trace.duration_ms = 8427
llm.tail.latency_outlier = true
llm.operation = "contract.check"
llm.route_class = "reasoning"

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

Тек YAML ішінде әдемі көрінгені үшін бүкіл кластерге «5000 мс-тан асқандардың бәрін сақтау» ережесін қоймаңыз. Ол баяу, бірақ штаттық маршрутты қымбат трассалардың шексіз көзіне тез айналдырады.

Қымбат сұрау мен ұзақ сұрау бір нәрсе емес

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

Құнды қолданба фактілерді білетін жерде есептеген дұрыс. Провайдер немесе шлюз жауап бергеннен кейін кіріс пен шығыс токендерін жинап, тарифті қолданыңыз, қайталап жіберулерді есепке алып, нәтижені түбірлік span-ға жазыңыз. Prompt кэштелсе, кэштелген токендерді бөлек белгілеңіз, әйтпесе қарапайым формула бойынша есептелген құн жалған болады.

Мысалы:

llm.usage.input_tokens = 18640
llm.usage.output_tokens = 2176
llm.observed_cost_usd = 0.1374
llm.retry_count = 2

Мұндағы атрибут атауы әдейі қолданбалық түрде берілген. Телеметрия стандарты сіздің валютаңызды, келісімшарттық тарифіңізді, жеңілдігіңізді, кэштелген токендерді немесе GPU-дың ішкі құнын біледі деп күтпеңіз. OpenTelemetry GenAI semantic conventions модель, токендер және анық қосылған жағдайда prompt, completion, tool call пен құрал нәтижесінің мазмұны туралы мәліметтерді стандарттайды. Тариф логикасы сіздің жүйеңіздің міндеті болып қалады.

Әр операция үшін ақша шегін бөлек таңдаңыз. Жаппай классификаторда 5 цент тергеуге себеп болуы мүмкін. Сирек орындалатын заңгерлік workflow үшін бұл қалыпты баға болуы ықтимал. Содан кейін шектен асқан трассаларды ұзақтығы мен статусына қарамастан толық сақтаңыз.

Жиі кездесетін нашар кеңес мынадай: «Токені көп сұрауларды ғана қалдырыңыз». Бұл кеңес ұнайды, себебі токен санағышы барлық жерде дерлік бар. Бірақ токендер сұраудың неге қымбат екенін түсіндірмейді. 40 мың кіріс токені бар трассада себеп күтілетін ұзын құжат болуы мүмкін. 6 мың токені бар трассада қате tool schema салдарынан үш рет қайталау себеп болуы ықтимал. Семплер екі жағдайды да ұстауы керек, бірақ оларды әртүрлі себептермен белгілеуі қажет.

Сәтті HTTP жауабы агенттің сәтсіздігін жасыруы мүмкін

LLM қолданбасында көлік деңгейіндегі қате мен тапсырма қатесі жиі сәйкес келмейді. Провайдер HTTP 200 қайтарды, модель JSON құрды, құрал аргументтерді алды, бірақ CRM сұрауды рұқсатқа байланысты қабылдамады. Немесе құрал бос нәтиже қайтарды, агент әрекетті қайталады, лимитті тауысқан соң пайдаланушыға сенімді, бірақ пайдасыз жауап жазды.

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

Мен әдетте құралдың нақты орындалуына бір span қосып, кемінде мыналарды жазамын:

name = "tool.execute"
llm.tool.name = "customer_lookup"
llm.tool_call.index = 2
llm.tool_call.failed = true
llm.tool_failure.kind = "permission_denied"
llm.tool.retryable = false

Егер операция шынымен орындалмаса, span-ды ERROR күйіне қойыңыз. Құрал орындалып, күтілетін бос нәтиже қайтарса, семплинг үшін оны қате деп жарияламаңыз. llm.tool.result = "empty" сияқты нақты нәтиже қосып, оның қызықты немесе қызықсыз екенін бөлек шешіңіз. Әйтпесе қателер метрикасы шуға толып, инженерлер оған сенбейтін болады.

Workflow аяқталғаннан кейін трасса соңғы статусты алуы керек. Агент мақсатына жетпесе, барлық желілік шақырулар сәтті аяқталғанына қарамастан, түбірлік span ERROR болуы мүмкін. Сонымен бірге llm.workflow.outcome мәнін жазған пайдалы: completed, failed, abandoned, guardrail_blocked. Бұл мәндерді командаңыз анықтайды, сондықтан оларды құжаттап, сервистен сервиске жазылуын өзгертпеңіз.

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

Ережелер ерекше жағдайлардан бақылау тобына қарай реттелуі керек

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

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

Төменде OpenTelemetry Collector Contrib үшін конфигурация мысалы берілген. Атрибут атаулары мен шектерді өз мәндеріңізбен ауыстырыңыз. Синтаксис status_code, boolean_attribute, numeric_attribute, latency және probabilistic қолдау көрсетілетін policy түрлерін пайдаланады. Процессор құжаттамасы оларды статус, атрибуттар, ұзақтық және трафик үлесі бойынша таңдау ережелері ретінде сипаттайды.

processors:
  tail_sampling:
    decision_wait: 20s
    num_traces: 50000
    expected_new_traces_per_sec: 250
    decision_cache:
      sampled_cache_size: 100000
      non_sampled_cache_size: 100000
    policies:
      - name: workflow-errors
        type: status_code
        status_code:
          status_codes: [ERROR]

      - name: failed-tool-call
        type: boolean_attribute
        boolean_attribute:
          key: llm.tool_call.failed
          value: true

      - name: expensive-request
        type: numeric_attribute
        numeric_attribute:
          key: llm.observed_cost_usd
          min_value: 0.05

      - name: slow-contract-check
        type: and
        and:
          and_sub_policy:
            - name: contract-check
              type: string_attribute
              string_attribute:
                key: llm.operation
                values: [contract.check]
            - name: contract-tail
              type: latency
              latency:
                threshold_ms: 8000

      - name: ordinary-control-group
        type: probabilistic
        probabilistic:
          sampling_percentage: 1

Бұл нұсқа барлық шартты бір алып policy-ге әдейі тықпаламайды. Жеке ережелерді инцидент талқылауында түсіндіру оңай: трассаны workflow қатесі, құрал қатесі, құн, нақты операцияның кідірісі немесе бақылау үлгісі сақтады. Егер коллектор нұсқасы шешім қабылдаған policy-ді жазуға мүмкіндік берсе, бұл мүмкіндікті қосып, оны backend ішінде тексеріңіз. Процессорда tailsampling.policy, tailsampling.composite_policy атрибуттарын және кэштен алынған шешім белгісін қосатын feature gate бар.

Соңына «қосалқы нұсқа» болады деген үмітпен always_sample қоспаңыз. Ол барлық үнемділікті жояды. Қалыпты трафиктен үлгі керек болса, үлесі анық көрсетілген ықтималдық ережесін пайдаланыңыз.

Алдымен өрістерді бүркемелеңіз, содан кейін трассаны буферде ұстаңыз

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

Деректерді үш деңгейге бөліңіз. Біріншісін ережелерде пайдаланып, кең көлемде сақтауға болады: статус, кідіріс, токендер, құн, операция атауы, қате түрі, қайталау саны, шаблон хэші. Екіншісі тек қорғалған қоймада және қысқа мерзімге рұқсат етіледі: жауаптың өңделген үзіндісі, құжат идентификаторы, бас тарту себебінің коды. Үшіншісі жеке келісілген негізсіз telemetry pipeline ішіне түспеуі керек: бастапқы құжаттар, шикі prompt-тар, tool arguments мазмұны және PII бар жауаптар.

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

llm.prompt.template_id = "claim-review-v7"
llm.prompt.characters = 48122
llm.prompt.sha256 = "..."
llm.tool.arguments_schema = "customer_lookup:v3"
llm.tool.arguments_bytes = 312

Хэш деректерді автоматты түрде қауіпсіз етпейді. Қысқа немесе алдын ала болжауға болатын мәндерді хэш бойынша қайта табуға болады. Ол бірдей input-тарды байланыстыруға пайдалы, бірақ құпияларды бөгде ортаға жіберуге сылтау болмауы тиіс.

Қазақстандағы командалар үшін деректерді орналастыру мәселесі формадағы келісім өрісімен емес, көбіне архитектурамен шешіледі. AI Router бірыңғай OpenAI-үйлесімді endpoint пен open-weight модельдердің бір бөлігін жеке GPU-инфрақұрылымда орналастыру мүмкіндігін ұсына алады. Бірақ атрибуттарды бүркемелеу мен трассаларды сақтау ережелері кез келген exporter-ге дейін жұмыс істеуі керек. Қолданба пайдаланушының төлқұжат деректерін трассаға жазып қойған болса, ешқандай API шлюзі оны түзете алмайды.

decision_wait интуициямен емес, кешіккен spans бойынша таңдалады

Егер қолданба оған арнайы аяқталу белгісін жібермесе, tail sampler трассаның «анық аяқталғанын» білмейді. Еншілес spans түбірлік span-нан кейін келуі мүмкін. Сондықтан ол decision_wait уақытша терезесін пайдаланады. Тым қысқа терезе кешіккен tool span-ды кесіп, толық емес тарих жасайды. Тым ұзын терезе экспорт кідірісін және жад шығынын арттырады.

Процессор құжаттамасында нақты ескерту бар: трасса decision_wait аяқталмай тұрып сақина буферінен өшірілсе, ол тасталуы мүмкін. Авторлар өшіру жасын өлшеп, оның перцентильдерін decision_wait мәнімен салыстыруға кеңес береді. Жақын мәндер жүктеме өскенде жоғалту қаупін білдіреді.

Әдепкі мән болғаны үшін 30 секундты таңдай салмаңыз. Өлшеу жүргізіңіз:

1. Workflow ішіндегі әдеттегі асинхронды tool calls-ты қамтитын терезеден бастаңыз.
2. Кешіккен spans жасының үлестірімін және буфер толуына байланысты өшірілген трассалар санын жинаңыз.
3. Қажет еншілес spans-тардың елеулі бөлігі шешімнен кейін келсе, терезені ұзартыңыз.
4. Трассалар терезе біткенше жоғалса, сыйымдылықты немесе экземпляр санын арттырыңыз.
5. Сақталған ұзын трассалардың толықтығын қайтадан қолмен тексеріңіз.

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

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

Бір трасса бір жерге түсуі керек

Kubernetes және көп аймақты жүйелерде ең жағымсыз ақау үнсіз орын алады. Түбірлік span collector A-ға, құрал spans-тары collector B-ге, ал агенттің соңғы span-ы collector C-ге түседі. Әр экземпляр шешуші белгілері жоқ бір бөлікті ғана көреді. Backend-те үзік-үзік бөліктер пайда болып, команда инструменттеуді қате кінәлайды.

Tail sampler-ден бұрын trace_id бойынша бағыттау керек. Ол детерминистік болуы тиіс: бір идентификаторы бар барлық telemetry records топтың бір экземплярына бағытталуы керек. SDK-дан кейінгі қарапайым round-robin үлестіру жарамайды. Collector құжаттамасы бір трасса spans-тарының бір экземплярға бірге түсуі қажет екенін бөлек атап көрсетеді.

Мұны диаграммамен емес, тест арқылы тексеріңіз. Түбірлік span, екі параллель tool және ERROR бар соңғы span-нан тұратын жасанды агенттік операция іске қосыңыз. Әр span-ға test.case_id атрибутын қосыңыз. Backend-те күтілетін spans саны және бір sampling себебі бар бір трасса шығуы керек. Егер сол test.case_id үшін екі немесе үш трасса көрсеңіз, бағыттау жүйесі әлдеқашан бұзылған.

Кешіккен spans-тарды да ескеріңіз. Процессор жиналған трасса өшірілгеннен кейін келген spans-қа бірдей нәтиже беру үшін шешімдер кэшін сақтайды. Кэш көлемі ағынға және кешіккен spans өмір сүру уақытына сәйкес болуы керек. Әйтпесе оң шешім қабылданғаннан кейін тарихтың бір бөлігі сақталып, қалғаны жоғалады.

Көлемді пайызбен емес, байтпен шектеңіз

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

Сондықтан екі шаманы бөлек өлшеңіз: сақталған трассалар саны және олардың байттағы көлемі. Tail sampling processor ішінде трассалардың нақты protobuf өлшемі бойынша token bucket қолданатын bytes_limiting policy бар. Ол деректердің тұрақты ағынын шектеп, burst үшін белгіленген көлемге рұқсат береді. Бұл инциденттен кейін толық қателер саны кенет өскенде пайдалы.

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

Практикадағы пайдалы тексеріс: бірнеше күн сайын әр сыныптан сақталған трассаларды алып, орташа өлшемін, spans санын, оқиғалар санын, prompt өрістерінің болуын және қайталап жіберу үлесін есептеңіз. Осылайша сақтау орнын нақты не үлкейтіп тұрғанын көресіз. Көбіне кінәлі LLM span-ының өзі емес, біреу «уақытша» қосқан құралдың HTTP жауабы денесі бар егжей-тегжейлі event болады.

Семплингті бизнес логикасы ретінде тексеріңіз

Таңдау ережелері YAML ішінде тұрса да, олар код болып саналады. Атрибуттар схемасы, модель, SDK немесе workflow өзгерген сайын оларды тестілеу керек. llm.tool_call.failed атрибутын tool.failed деп өзгертіп, policy-ді жаңартуды ұмытсаңыз, бір аптадан кейін тергеуге ештеңе қалмағанын байқайсыз.

CI ішінде немесе тест коллекторында іске қосылатын синтетикалық трассалар жиынын құрыңыз. Онда кемінде мыналар болсын: қалыпты сәтті сұрау, қымбат әрі жылдам сұрау, баяу штаттық workflow, түбірлік операция қатесі, HTTP 200 кезінде сәтсіз tool call және кейін қайталау арқылы түзетілген қате. Әр жағдай үшін күтілетін нәтиже мен policy name-ді алдын ала көрсетіңіз.

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

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