KI-Chatbot-Observability: Traces, Retrieval und Tool-Aufrufe verstehen

Svetainės pokalbių botas gali pateikti teisingą atsakymą, tačiau nueiti iki jo pavojingu keliu: galbūt lemiamas sakinys buvo paimtas iš pasenusio šaltinio, įrankis buvo bereikalingai iškviestas du kartus arba atsarginis variantas (fallback) paslėpė klaidą. KI-Chatbot Observability padaro šią grandinę atsekamą. Ji sujungia techninius veikimo laiko duomenis su informacijos paieškos (retrieval), kokybės ir saugumo informacija, kad komandos matytų ne tik tai, kad kažkas nutiko ne taip, bet ir kur bei kodėl.

Šis vadovas pateikia pragmatišką struktūrą svetainių komandoms. Ji tinka tiek paprastiems RAG pokalbių botams, tiek sistemoms, jungiančioms išorinius įrankius, CRM užklausas ar kelias paslaugas. Dėmesio centre – aiškūs pėdsakai (traces), keli patikimi rodikliai ir duomenų apsaugos koncepcija, apibrėžta dar prieš pradedant diegti instrumentus.

Kodėl tradicinių svetainės rodiklių neūžtenka DI pokalbių botams

Būsenos kodas, bendra trukmė ir klaidų dažnis išlieka svarbūs. Tačiau HTTP 200 nieko nepasako apie tai, ar atsakymas rėmėsi tinkamu šaltiniu, ar modelis nuslėpė neapibrėžtumą, ar įrankis pateikė tikėtą rezultatą. Net ir greitas pokalbis gali būti neteisingas iš esmės. Ir priešingai, lėtesnis atsakymas gali būti prasmingas, jei reikiama duomenų užklausa buvo atlikta teisingai.

Todėl veikimas ir kokybė turėtų būti atskirti, tačiau tarpusavyje susieti. Straipsnyje apie vėlavimo biudžetus, srautinį perdavimą ir laiko limitus paaiškinamas laiko aspektas. Stebimumas jį papildo vykdymo keliu: kuris komponentas dalyvavo, kiek laiko užtruko kiekvienas žingsnis ir kurioje vietoje pasikeitė atsakymo kokybė?

Nuo puslapio peržiūros iki nuoseklaus pėdsako

Pėdsakas (trace) aprašo vienos užklausos kelią per kelis komponentus. Jo dalys vadinamos tarpiniais pėdsakais (spans). W3C rekomendacija Trace Context apibrėžia bendrą formatą su traceparent ir tracestate, kuriuo šis ryšys gali būti perduodamas per paslaugų ribas. Pokalbių botui tai ypač naudinga, nes kitaip naršyklė, API, paieška, modelis ir įrankiai generuoja atskirus, izoliuotus žurnalus.

Aiškus minimalus kelias gali atrodyti taip:

1. Tinklapio užklausa: Pokalbio valdiklis išsiunčia žinutę su techniniu užklausos ID.
2. Orkestravimas: Serveris nusprendžia dėl atsakymo režimo, žinių bazės, kalbos ir leidžiamų įrankių.
3. Retrieval (informacijos paieška): Paieška grąžina dokumentų ID, versijas ir atitikimo balus.
4. Modelio iškvietimas: Sistema išsiunčia paruoštą kontekstą pasirinktam modeliui.
5. Įrankio iškvietimas: Jei reikia, įvykdoma ir patikrinama tiksliai apibrėžta funkcija.
6. Atsakymas ir perdavimas: Atsakymas patikrinamas, transliuojamas arba perduodamas žmogui.

Kiekvienas span turėtų turėti pradžią, pabaigą, rezultato būseną ir nedidelį kiekį stabilių atributų. Pavadinimai turi išlikti tokie patys per kelis leidimus. Laisvas tekstas, pilni užklausų tekstai (prompts) ar visi įrankių atsakymai neturėtų automatiškai patekti į kiekvieną trace.

Kokie duomenys iš tiesų padeda kiekviename žingsnyje

Užklausos ir valdymo kontekstas

Pradžioje dažniausiai pakanka techninių, žemo kardinalumo požymių: produkto srities, kalbos/regiono (locale), anonimizuotos sesijos nuorodos, leidimo versijos, prompt versijos ir pasirinkto atsakymo kelio. Naudotojo vardas, el. pašto adresas ar visas klausimas daugeliui eksploatavimo klausimų nėra būtini. Tačiau svarbu, kad prompt ar žinių bazės pakeitimas vėliau galėtų būti priskirtas konkrečiam klaidų klasteriui.

• Trace ID ir laiko žyma
• Locale ir kanalas, pavyzdžiui, svetainė arba klientų portalas
• Programos, prompt ir žinių indekso versija
• Pasirinktas režimas, pavyzdžiui, RAG, fallback arba perdavimas žmogui (Human Handoff)
• Galutinė būsena, pavyzdžiui, sėkminga, nutraukta, viršytas laiko limitas arba užblokuota

Informacijos paieška (Retrieval) ir šaltiniai

RAG sistemose šaltinių grandinė dažnai yra svarbesnė nei modelio pavadinimas. Todėl išsaugokite atsekamus dokumentų ID, indekso versiją, rezultatų skaičių ir – jei naudojama paieškos technologija leidžia juos prasmingai palyginti – atitikimo balus. Pilni dokumentų tekstai tam retai reikalingi. Esamas vadovas apie hibridinę paiešką ir rangavimą iš naujo (reranking) parodo, kaip veikia raktažodžių ir vektorių paieška kartu; pėdsakas turėtų parodyti, kuris etapas kokius rezultatus pateikė.

Ypač vertingos yra aiškiai įvardytos būsenos: nėra rezultatų, tik rezultatai žemiau vidinės ribos, pasenęs indeksas arba šaltinis nepasiekiamas. Tuomet komanda gali atskirti, ar žinių bazėje yra spraga, ar informacijos paieška nerado esamų žinių.

Modelio ir įrankių žingsniai

Modelio iškvietimams būdingi eksploatavimo duomenys yra tiekėjo ir modelio identifikatorius, trukmė, tokenų kiekis, nutraukimo priežastis ir pakartotinių bandymų skaičius. Įrankiams papildomai pateikiamas funkcijos pavadinimas, patikrinta rezultato būsena ir saugus klaidos kodas. Jautrūs argumentai ar rezultatai neturėtų patekti nei į span pavadinimus, nei nebalansuoti į atributus. Pavyzdžiui, užsakymo užklausos atveju dažniausiai pakanka „leidimas patikrintas, įrašas rastas, atsakymas patvirtintas“ – o ne viso adreso ar užsakymų istorijos.

„Microsoft“ savo agentų pėdsakų apžvalgoje aprašo traces ir įdėtinius spans kaip priemonę modelio, įrankių, vėlavimo ir išlaidų informacijai tirti visos eigos metu. Šis principas yra neutralus tiekėjams: svarbiausia yra nuoseklus duomenų modelis, o ne konkretus stebėsenos produktas.

Telemetrijos kūrimas taupant duomenis

Stebimumas neturi tapti visų pokalbių šešėline kopija. „OpenTelemetry“ gairėse dėl jautrių duomenų pabrėžiama, kad instrumentai patys negali atpažinti jautraus turinio. Atsakomybė už duomenų minimizavimą, apsaugą, sutikimą ir saugojimą tenka valdytojui. Todėl prieš pirmąjį gamybinį trace reikėtų sudaryti leidžiamų atributų sąrašą (allowlist), nustatantį, kurie atributai apskritai gali palikti sistemą.

n

Stebėjimo tikslas	Taupus signalas	Ko vengti
Rasti paieškos etapo klaidą	Indekso versija, dokumento ID, rezultatų klasė	visas dokumento tekstas
Atpažinti įrankių problemas	Įrankio pavadinimas, būsenos kodas, trukmė, rezultato tipas	tokenai, adresai arba laisvo teksto rezultatai
Palyginti kokybę po naujo leidimo	Prompt versija, vertinimo etiketė (eval label), leidimo ID	nefiltruoti pokalbių žurnalai
Susieti pasikartojančius atvejus	trumpalaikė pseudoniminė nuoroda	ilgalaikis aiškus ID

Praktikoje pasiteisino padalijimas į tris lygius: agreguoti rodikliai nuolatiniam darbui, atrinkti pėdsakai (sampled traces) techninei analizei ir griežtai kontroliuojamos pokalbių imtys turinio peržiūrai. Prieigos teisės ir ištrynimo terminai turėtų būti apibrėžti kiekvienam lygiui. Daugiau pagrindų pateikiama straipsnyje apie duomenis taupančią pokalbių botų analitiką.

Iš pėdsakų – veiksmingi rodikliai

Pėdsakas paaiškina atskirą atvejį; rodikliai parodo, ar jis yra dėsningumo dalis. Pradėkite nuo kelių rodiklių, kurie išprovokuoja konkretų sprendimą:

• Bendra sėkmės norma (End-to-End): užklausų dalis, kurios baigiasi be techninių klaidų ar nepageidaujamo nutraukimo.
• Paieškos be rezultatų norma (Retrieval No-Result): RAG užklausų dalis be pakankamai atitinkančio rezultato, atskirta pagal locale ir indekso versiją.
• Įrankių sėkmės norma: sėkmingi, atmesti ir nesėkmingi iškvietimai vienai funkcijai.
• Vėlavimas pagal etapą: ne tik bendra trukmė, bet ir atskirai paieškai, modeliui, įrankiui bei papildomam apdorojimui.
• Fallback ir Handoff norma: kaip dažnai suveikia saugus atsarginis atsakymas arba perdavimas žmogui.
• Kokybės imtis: pagrindimas (grounding), atitikimas arba vidinio patikrinimo etiketės apibrėžtai srauto daliai.

„Microsoft“ GenAI stebimumo apžvalgoje taip pat atskiriamas vertinimas, stebėsena ir tracing. Tai naudingas mąstymo modelis: mažėjantis klaidų dažnis dar neįrodo geresnės atsakymų kokybės, o geras kokybės rodiklis nepakeičia sistemos eksploatavimo stebėsenos.

Pavyzdys: teisingas atsakymas iš neteisingo šaltinio

Tarkime, pokalbių botas pateikia teisingą grąžinimo terminą. Tačiau pėdsakas rodo, kad dabartinis pagalbos straipsnis paieškoje liko žemiau ribos ir vietoj jo buvo panaudotas senas PDF dokumentas. Be pėdsako atsakymas atrodo įprastas. Su pėdsaku tampa matoma konkreti rizika: kai tik pasikeis terminas, botas greičiausiai pateiks pasenusį atsakymą.

Dabar komanda gali imtis tikslingų veiksmų: patikrinti dabartinio straipsnio indeksavimą, pašalinti seną dokumentą iš patvirtintų šaltinių sąrašo, pridėti regresinį testą ir ieškoti panašių atvejų pagal tą patį dokumento ID. Nereikia nei keisti paties modelio, nei rankiniu būdu skaityti visų pokalbių.

Įspėjimams reikalinga reakcija, o ne tik ribinė reikšmė

Įspėjimas yra naudingas tik tada, kai apibrėžta atsakomybė ir kitas žingsnis. Todėl kiekvienam signalui turėtų būti dokumentuota: riba, stebėjimo langas, paveikta vartotojų grupė, atsakinga komanda, saugi neatidėliotina priemonė ir grįžimo į įprastą būseną sąlyga. Padidėjus įrankių klaidų skaičiui, neatidėliotina priemonė gali būti funkcijos išjungimas ir perdavimo žmogui siūlymas. Paieškos sutrikimų atveju gali būti prasminga naudoti patvirtintą atsarginį atsakymą (fallback).

Vadove apie DI pokalbių botų incidentų valdymą išsamiau aprašomas apribotas režimas (degraded mode) ir atstatymas (rollback). Stebimumas pateikia tam signalus ir įrodymus; incidentų žaismedis (playbook) apibrėžia reakciją.

Įdiegimo planas per keturis žingsnius

1. Pasirinkti kritinį vartotojo kelią: Pradėkite, pavyzdžiui, nuo palaikymo klausimo, kuriame naudojama paieška ir tiksliai vienas įrankis. Iš anksto apibrėžkite, į kokius diagnostinius klausimus turi atsakyti pėdsakas.
2. Nustatyti span modelį ir leidimų sąrašą: Apibrėžkite stabilius etapus ir leidžiamus atributus. Prieš paleidimą patikrinkite duomenų apsaugą, prieigą, atranką (sampling) ir saugojimą.
3. Kontroliuojamai simuliuoti klaidas: Išbandykite atvejus be rezultatų, laiko limitų viršijimą, neteisingą įrankio atsakymą, nutraukimą ir perdavimą. Kiekviena būsena turi būti atpažįstama pėdsake ir atskiriama nuo normalios eigos.
4. Sujungti rodiklius ir peržiūras: Agreguokite technines būsenas ir susiekite nedidelę, kontroliuojamą imtį su kokybės vertinimais. Tik tada įtraukite papildomus vartotojų kelius.

NIST AI Risk Management Framework Core rekomenduoja išbandyti DI sistemas prieš naudojimą ir reguliariai eksploatacijos metu, bei atsekamai dokumentuoti matavimų rezultatus. Svetainių komandoms tai retai reiškia kartojamą procesą: išmatuoti, ištirti priežastį, patikrinti pakeitimą ir iš naujo patikrinti tą patį atvejį.

Glaustas stebimumo kontrolinis sąrašas

• Ar kiekviena užklausa turi nuoseklų trace ID per API, paiešką, modelį ir įrankius?
• Ar span pavadinimai ir būsenos reikšmės yra stabilios, suprantamos ir žemo kardinalumo?
• Ar prompt, leidimo ir žinių indekso versijas galima priskirti konkrečiai eigai?
• Ar galima atskirti atvejus be rezultatų, fallback, įrankio atmetimą, laiko limitą ir perdavimą žmogui?
• Ar renkami tik leidžiami atributai ir jautrus turinys pašalinamas prieš eksportą?
• Ar sampling, prieigos teisės ir ištrynimo terminai yra dokumentuoti kiekvienam telemetrijos lygmeniui?
• Ar kiekvienas pavojaus signalas veda prie nustatyto patikrinimo arba saugaus eksploatavimo veiksmo?
• Ar techniniai rodikliai reguliariai lyginami su turinio kokybės testais?

Išvada: padaryti atsakymo kelią valdomą

KI-Chatbot Observability nėra kuo pilnesnis duomenų rinkimas. Tai sąmoningai apribotas paaiškinimo modelis realioms vartotojų užklausoms. Geri pėdsakai parodo, kuris šaltinis, kuris modelis ir kuris įrankis dalyvavo. Geri rodikliai padaro matomus dėsningumus. Geros duomenų apsaugos taisyklės neleidžia įrankiams sukurti naujų rizikų.

Pradėkite nuo vieno kritinio kelio ir 8–12 tikrai būtinų atributų. Jei jūsų komanda taip greičiau randa klaidą, kontroliuojamai išjungia nesaugų kelią ir atkuriamai patikrina pataisymą, instrumentai atlieka savo paskirtį. Tik po to verta plėsti apimtį.

Šaltiniai

• W3C: Trace Context
• OpenTelemetry: Handling sensitive data
• Microsoft Foundry: Observability in generative AI
• Microsoft Foundry: Agent tracing overview
• NIST: AI Risk Management Framework Core