DI pokalbių botų kaštų matavimas sprendimui: teisingas tokenų, įrankių ir palaikymo poveikio paskirstymas

Prietaisų skydelis rodo mažėjančias tokenų išlaidas, tačiau klientų aptarnavimo sąskaita auga. Pigesnis modelis atsako į daugiau užklausų, bet sukelia papildomų patikslinančių klausimų. Įrankio iškvietimas sutaupo darbo, tačiau jo išorinė paslauga atsiranda kitoje išlaidų eilutėje. Todėl tie, kurie žiūri tik į vieno modelio iškvietimo kainą, nematuoja svetainės pokalbių boto ekonominio efektyvumo.

Naudingas matavimo vienetas yra vartotojo gautas rezultatas: išspręstas klausimas, kvalifikuotas perdavimas specialistui arba patvirtintas kitas veiksmas. Šis vadovas rodo, kaip techninis naudojimas ir funkcinis poveikis susijungia į duomenis taupantį išlaidų modelį.

Nuo sąskaitos faktūros iki pokalbio kelio

Tiekėjų sąskaitose nurodomi modeliai, tokenai, regionai arba laikotarpiai. Produktų komandos, priešingai, mąsto apie svetaines, klientus, funkcijas ir intentus. Tarp jų reikalingas paskirstymo sluoksnis. Suteikite kiekvienam pokalbiui pseudoniminį ID, o kiekvienam apdorojimo žingsniui – „span“: apsaugos patikrinimui, paieškai (retrieval), vektorių kūrimui (embedding), modeliui, įrankiui, saugojimui ir perdavimui (handoff). Šiame žingsnyje įrašoma modelio bei konfiguracijos versija ir naudojimo rodikliai, bet ne visas pokalbio turinys.

OpenTelemetry apibrėžia bendrus atributus ir metrikas generatyviniam DI, įskaitant operaciją, prašomą modelį bei įvesties ir išvesties tokenus. Tokios konvencijos palengvina nuoseklų duomenų srautą. Tačiau jos automatiškai nepateikia piniginių sumų, nes kainos, nuolaidos ir podėlio (cache) dalys priklauso nuo sutarties bei laiko.

Laikykite kainas versijuotas, o ne įrašytas kode

Pirmiausia išsaugokite stebimą naudojimą natūraliais vienetais: įvesties tokenais, išvesties tokenais, podėlyje išsaugotais tokenais, embeddings skaičiumi, paieškos operacijomis, įrankių iškvietimais ir vykdymo laiku. Priskirkite išlaidas naudodami versijuojamą kainų lentelę. Kiekvienoje taisyklėje nurodomas tiekėjas, modelis ar paslauga, valiuta, galiojimo laikotarpis ir kainos matmuo.

Taip istorinės ataskaitos išlieka atsekamos, net jei tiekėjas pakeičia kainas. Venkite visuotinės „kainos už tokeną“, kuri sujungia skirtingus modelius, podėlio nuolaidas ar specialias sąlygas. Aiškiai pažymėkite numatomas išlaidas, jei sąskaita faktūra neleidžia tikslesnio paskirstymo.

Sąžiningas bendrųjų išlaidų paskirstymas

Vektorių indeksas, duomenų bazė ar stebėsenos paslauga aptarnauja daug pokalbių. Šių išlaidų ne visada įmanoma priskirti tiesiogiai. Nustatykite suprantamą paskirstymo taisyklę, pavyzdžiui, pagal paieškos operacijas, dokumentų kiekį, vykdymo laiką ar aktyvius klientus. FOCUS specifikacija aprašo struktūrizuotus bendrų debesijos išlaidų duomenis pagal metodą, santykį, kiekį ir vienetą. Šis principas naudingas ir pokalbių botų paslaugoms: kiekvienas paskirstymas turi paaiškinti, kaip jis atsirado.

Askirkite tiesiogines kintamąsias išlaidas nuo bendrų platformos išlaidų. Trumpalaikiams maršruto parinkimo sprendimams svarbios kintamosios išlaidos; biudžetui ir produkto kainai reikia pilno vaizdo. Nemaišykite abiejų į vieną skaičių be žymėjimo.

Išlaidos už rezultatą, o ne už pokalbį

Pokalbis su vienu modelio iškvietimu nėra automatiškai pigus. Jei vartotojai po to klausia dar kartą arba jiems reikia žmogaus pagalbos, pirmasis iškvietimas galėjo būti neefektyvus. Todėl apibrėžkite rezultatų būsenas:

• Išspręsta: Tikslas buvo pasiektas patvirtintu įvykiu arba kontroliuojamu kokybės patikrinimu.
• Kvalifikuotai perduota: tinkamas žmogaus kanalas gavo pakankamai konteksto.
• Saugiai apribota: pokalbių botas teisingai atpažino žinių trūkumą arba neleistiną veiksmą.
• Neišspręsta: nutraukimas, pakartotinis klausimas arba neigiamas atsiliepimas be tinkamo kito žingsnio.

Apskaičiuokite išlaidas už išspręstą arba prasmingai perduotą užklausą. Be to, pateikite ataskaitose paskirstymą, o ne tik vidurkį. Kai kurie sudėtingi atvejai gali būti brangūs, jei jie padeda išvengti didelių rankinio darbo išlaidų.

Kokybė kaip fiksuotas apribojimas

Išlaidų eksperimentui reikia neginčijamų apsaugos ribų (guardrails): pagrįstų atsakymų, saugumo, sėkmingo perdavimo, delsos (latency) ir vartotojų atsiliepimų. Mažesnis modelis gali gauti daugiau srauto tik tada, kai jis išlieka šiose ribose jam priskirtose intentų klasėse. Priešingu atveju sutaupymas pasiekiamas pretenzijų ar rizikos sąskaita.

Naudokite „Golden Set“ kiekvienam maršrutui. Paprasti vieši DUK gali būti nukreipiami kitaip nei individualūs sutarties klausimai. Esant mažam paieškos patikimumui arba rizikingiems veiksmams, kelias veda prie stipresnio modelio arba prie žmogaus. Šis eskalavimas yra suplanuotos vieneto kainos dalis, o ne išimtis, kuri pašalinama iš ataskaitos.

Matuojamas podėlio ir konteksto optimizavimas

Tiekėjo užklausų podėlis (prompt cache), semantinis atsakymų podėlis ir trumpesni kontekstai veikia skirtingai. Registruokite podėlio kūrimą ir podėlio pataikymus atskirai, kad sutaupymai būtų matuojami, o ne tik spėjami. Stabilus sistemos prefiksas gali padidinti podėlio naudojimą; tačiau nereikalingai ilga pokalbių istorija didina įvesties tokenų skaičių kiekviename ture.

Pirmiausia optimizuokite švaistymą: dubliuojamas dokumentų ištraukas, nesvarbią istoriją, pasikartojančias įrankių schemas ir nepanaudotą išvestį. Netrumpinkite informacijos, kuri būtina pagrindimui ar teisėms patikrinti. Kiekvienas pakeitimas tikrinamas pagal tą patį kokybės rinkinį.

Biudžetų nustatymas keliais lygiais

Viena mėnesio riba reaguoja per vėlai. Derinkite apribojimus užklausai, sesijai, klientui ir laikotarpiui. Užklausos biudžetas gali sustabdyti nekontroliuojamą įrankio ciklą. Sesijos biudžetas inicijuoja perdavimą po pakartotinių nesėkmingų bandymų. Kliento biudžetas atpažįsta netinkamą konfigūraciją ar piktnaudžiavimą, neribodamas kitų klientų.

Elegantiškas veikimo suprastėjimas (graceful degradation) nereiškia, kad tiesiog nebus pateiktas atsakymas. Galimi lygiai: mažesnis, patikrintas modelis paprastiems intentams, trumpesnis kontekstas, išjungtos papildomos funkcijos arba skaidrus perdavimas. Saugumo patikrinimai ir prieigos kontrolė visada išlieka aktyvūs.

Išlaidų prietaisų skydelis, leidžiantis priimti sprendimus

Naudingas prietaisų skydelis rodo apimtis, tiesiogines išlaidas, paskirstymą, išlaidas už rezultatą, kokybės apsaugos ribas ir pokyčius lyginant su konfiguracijos versija. Filtrai pagal klientą, kalbą, intentą ir modelio maršrutą padeda rasti priežastis. Apribokite matmenis su labai didele kardinalumu; vartotojo ar pokalbio ID priklauso stebėsenos „traces“, skirtoms tikslinei diagnostikai, o ne nuolatinėms laiko eilutėms.

Gaukite įspėjimus apie pokyčius su kontekstu: didesnis išvesties tokenų skaičius išlaikant tą pačią apimtį, sumažėjęs podėlio pataikymų skaičius po naujos versijos išleidimo arba išaugusios įrankių išlaidos nepadidėjus išspręstų atvejų skaičiui. Vien tik biudžeto riba pasako, kad pinigai buvo išleisti, bet nepaaiškina kodėl.

Praktinis įgyvendinimo planas

1. Perduoti pokalbių ir „span“ ID per visą procesą.
2. Fiksuoti naudojimą natūraliais vienetais.
3. Pridėti versijuojamas kainas ir dokumentuotus paskirstymus.
4. Apibrėžti rezultatų būsenas kartu su aptarnavimo ir produkto komandomis.
5. Pateikti ataskaitose išlaidas už rezultatą kartu su kokybės ribomis.
6. Pakeisti vieną švaistymo šaltinį ir kontroliuojamai palyginti.
7. Reguliariai tikrinti biudžetus bei saugų suprastintą režimą.

Išvada: pigiausias atsakymas nėra automatiškai ekonomiškiausias

Pokalbių botų išlaidos tampa valdomos, kai techninis naudojimas yra sekamas iki patikrinto vartotojo rezultato. Versijuojamos kainos, skaidrus paskirstymas ir atskiros kokybės metrikos neleidžia tariamai pigiam modelio iškvietimui paslėpti brangaus papildomo darbo.

Pradėkite nuo dažnai pasitaikančio intento ir užregistruokite visus tiesioginius žingsnius iki rezultato. Net ši maža išlaidų grandinė dažniausiai parodo, ar tokenai, paieška, įrankiai, ar pakartotiniai nesėkmingi pokalbiai yra geresnis optimizavimo svertas.

Šaltiniai

• OpenTelemetry: GenAI Semantic Conventions
• OpenTelemetry: GenAI Observability ir tokenų metrikos
• FOCUS 1.3: Split Cost Allocation
• NIST AI RMF Core: Measure