Dauguma organizacijų generatyvinio DI (GenAI) išlaidas stebi taip pat, kaip stebėtų debesijos paslaugų sąskaitą: bendras tokenų skaičius, bendra API kaina, mėnuo iš mėnesio. Šis skaičius parodo, kiek išleidote. Jis nepasako, ką už tuos pinigus gavote, ir būtent šis atotrūkis yra vieta, kurioje biudžeto valdytojai kitame planavimo cikle pradeda kelti nepatogius klausimus.
FinOps generatyviniam DI yra apie šio atotrūkio sumažinimą: kainos už tokeną pakeitimą kaina už rezultatą, kad kiekvienas išleistas euras atitiktų kažką, ką verslo savininkas iš tikrųjų pripažįsta rezultatu.
Matuokite kainą už naudingą rezultatą, ne kainą už tokeną
Esminį pokytį lengva apibūdinti, tačiau sunkiau įgyvendinti: nustokite klausti „kiek kainavo tokenai” ir pradėkite klausti „kiek kainavo vienas priimtas, kokybės patikrą praėjęs rezultatas”. Rezultatas turi būti skaičiuojamas, turėti savo atsakingą asmenį ir būti patvirtintas kokybės patikra, kitaip jūs tiesiog pervadinate tą patį tokenų skaičių ir vadinate jį pažanga. Atkreipkite dėmesį ir į apgaulingą taupymą: pigesnio modelio naudojimas sąskaitoje gali atrodyti kaip laimikis, tačiau tuo pat metu tyliai padidinti pakartotinio darbo, eskalacijų ar klaidų kiekį kitur, o tai padidina tikrąją kainą už rezultatą, net jei tokenų sąskaita mažėja.
Rinkitės rezultatus, kurie tikrai svarbūs
Rezultatų apibrėžimus imkite iš jau egzistuojančių sistemų: savo užklausų valdymo platformos, CRM, ERP. Geri rezultatai yra tai, ką verslo savininkas atpažintų be jokio vertimo: uždarytos bylos, apdoroti dokumentai, sutrumpėjęs ciklo laikas. Venkite bendrinių, DI būdingų rodiklių, tokių kaip „sugeneruotas tekstas” ar „atlikti įrankio kvietimai”, jie matuoja veiklą, o ne vertę.
Užfiksuokite apibrėžimą, prieš pradėdami ką nors matuoti
Rezultato apibrėžimui reikia trijų aiškiai nustatytų dalykų, prieš pradedant jį stebėti: aiškaus pradžios ir pabaigos taško, konkrečiai nurodytų atvejų, kurie įskaičiuojami ir kurie neįskaičiuojami, ir kokybės taisyklės, kuri nusprendžia, ar rezultatas iš tikrųjų įskaičiuojamas. Pavyzdžiui: pagalbos užklausa įskaičiuojama kaip išspręstas rezultatas tik jei ji pažymima kaip išspręsta per septynias dienas, nėra pakartotinai atidaroma per 72 valandas ir pasiekia minimalų kokybės (QA) balą. Neturint tokio tikslumo, kiekviena komanda žodį „išspręsta” interpretuos skirtingai, ir jūsų skaičiai nebus palyginami mėnuo iš mėnesio.
Sudarykite pilną išlaidų struktūrą, ne tik API sąskaitą
Kintamos išlaidos yra akivaizdi dalis: tokenai, embedingai, API kvietimai, pakartotiniai bandymai. Išlaidos, kurios dažniausiai praleidžiamos, yra fiksuotos ir pusiau fiksuotos: inžinerinio darbo laikas, žmogaus atliekama patikra, monitoringas, saugumo darbas ir mokymai. Čia nereikia tobulo paskirstymo modelio, reikia nuoseklaus. Naudokite tą pačią mėnesinę metodiką kaskart, kad tendencijos būtų iš tikrųjų palyginamos, o ne siekite tikslumo, kuris kiekvieną ketvirtį keičia apibrėžimus.
Apskaičiuokite kainą už rezultatą
Kaina už rezultatą = (visos kintamos išlaidos + paskirstytos fiksuotos išlaidos) / priimtų rezultatų skaičius. Žodis „priimtų” yra svarbesnis, nei atrodo. Jei sugeneravote 1000 juodraščių, ir tik 600 iš jų praėjo kokybės patikrą, dalykite iš 600, ne iš 1000. Čia taip pat pasireiškia apgaulingo taupymo spąstai: pigesnis modelis, kuris sukuria daugiau atmestų rezultatų, gali padidinti kainą už rezultatą, net jei tokenų išlaidos mažėja.
Užtikrinkite sistemos atsekamumą
Kiekvieną naudojimo atvejį pažymėkite bent pavadinimu, atsakingu asmeniu ir aplinka (testavimo ar gamybos). Susiekite šį žymėjimą su savo politikos taisyklėmis ir pakeitimų žurnalais. Kai kainos už rezultatą skaičius pasikeičia, atsekamumas leidžia jums iš tikrųjų sužinoti, kodėl, o ne spėti, ar tai buvo modelio pakeitimas, užklausos (prompt) pakeitimas, ar pagrindinio darbo krūvio pasikeitimas.
Pateikite ataskaitą taip, kad finansų komanda galėtų ją realiai patvirtinti
Dėmesio verta mėnesio ataskaita turi įtraukti keturis dalykus: išlaidas (pagal naudojimo atvejį ir biudžeto valdytoją, atskirtus į gamybos ir testavimo grupes), rezultatus (priimtų rezultatų skaičius, naudojant anksčiau užfiksuotus griežtus apibrėžimus), kokybę (minimalių reikalavimų rodiklis plius vienas apsauginis rodiklis, pavyzdžiui, pakartotinio darbo rodiklis, eskalacijų rodiklis ar skundų rodiklis) ir pakeitimus (visi tą mėnesį atlikti modelio atnaujinimai, užklausų peržiūros, darbo eigos pakeitimai ar politikos pokyčiai). Tokia struktūra biudžeto valdytojams suteikia aiškų pagrindą vienam iš trijų sprendimų: patvirtinti, koreguoti arba sustabdyti.
Kam visa tai reikalinga
Visa tai nėra apie tai, kaip iš savo tiekėjo išspausti pigesnius tokenus. Tai apie galimybę ginti generatyvinio DI išlaidas su tokiu pačiu pasitikėjimu, kaip gintumėte bet kurią kitą biudžeto eilutę, nes galite tiksliai parodyti, ką už tuos pinigus gavote.
Jei kuriate tokio pobūdžio išlaidų stebėjimo sistemą ir norite, kad kas nors papildomai peržiūrėtų jūsų rezultatų apibrėžimus ar išlaidų struktūrą, susisiekite su mumis ir mes padėsime jums viską teisingai sutvarkyti iš pirmo karto.