AI Engineer · Lecke 06

Evalok és megfigyelhetőség

Egy nyelvi modellre épülő rendszernél a legnehezebb kérdés nem az, hogyan építsd meg, hanem az, honnan tudod, hogy jó. Mivel a kimenet nyílt végű és nem determinista, mérés nélkül vakon dolgozol. Ez a lecke az offline és az online kiértékelésről, a pontozás módszereiről, az LLM mint bíró használatáról és a tracingről szól.

Vissza a tananyaghoz


Miért nehéz a kiértékelés

A hagyományos szoftvernél egy teszt vagy átmegy, vagy elbukik, mert a helyes kimenet egyértelmű. A nyelvi modellnél ez ritkán van így. Egy összefoglalóra több jó megoldás létezik, egy válasz lehet helyes, de túl bő, vagy udvarias, de pontatlan. Ráadásul ugyanarra a bemenetre a modell nem feltétlenül ad kétszer azonos választ. Ebből következik, hogy nem elég egy-két kézi próba, rendszerezett kiértékelésre van szükség. A kiértékelés, angolul eval, az a folyamat, amely mérhetővé teszi, hogy a rendszered valóban azt teszi-e, amit elvárunk tőle. Enélkül minden promptmódosítás és minden modellcsere csak találgatás, mert nem tudod megmondani, javított vagy rontott.


Offline eval, a kiértékelő készlet

Az offline eval lényege egy gondosan összeállított kiértékelő készlet, amely reprezentatív bemenetekből és a hozzájuk tartozó elvárásokból áll. Ezt a készletet a rendszer minden érdemi változtatása előtt lefuttatod, és összeveted a korábbi eredménnyel. Így a promptmódosítás, a RAG hangolása vagy a modellcsere nem érzésre, hanem számok alapján dől el. A jó kiértékelő készlet nem a könnyű esetekből áll, hanem szándékosan tartalmazza a nehéz, a ritka és a rosszindulatú bemeneteket is, mert éles forgalomban ezek okozzák a bajt. A készlet így egyben regressziós teszt is, mert megvéd attól, hogy egy javítás máshol csendben elrontson valamit. Ez az eval-vezérelt fejlesztés alapja.


OFFLINE, kiadás előtt kiértékelő készlet rendszer új változata pontozás javult vagy romlott ONLINE, éles forgalomban valós forgalom jelzések gyűjtése visszajelzés, mérce új eset a készletbe a hibákból tanulunk visszatáplálás
Az offline eval a kiadás előtt méri a rendszert egy rögzített készleten, az online eval az éles forgalmat figyeli. A kettő zárt hurkot alkot, mert az éles hibákból új esetek kerülnek a kiértékelő készletbe.

Hogyan pontozzunk

A pontozásra több módszer van, és a feladat dönti el, melyik illik hozzá. A referenciaalapú pontozás akkor működik, ha van egyértelmű helyes válasz, például strukturált kimenetnél, ahol a mezők értékét pontosan össze lehet vetni. A rubrikaalapú pontozás egy előre rögzített szempontrendszer szerint értékel, például külön a pontosságot, a teljességet és a hangnemet. A humán kiértékelés a legmegbízhatóbb, de lassú és drága, ezért tipikusan mintavételesen alkalmazzuk. A gyakorlatban ritkán elég egyetlen módszer. A gépi mérőszám gyors és olcsó, de nem fogja meg a minőség finomságait, a humán ítélet fordítva. A jó kiértékelés ezért rétegzett, gyors gépi szűrés alul, alaposabb, néha emberi vizsgálat felül.


Az LLM mint bíró és a torzításai

Egy elterjedt köztes megoldás, hogy egy modellt kérünk meg egy másik modell kimenetének pontozására, ezt hívjuk LLM mint bíró megközelítésnek. A bíró modellnek megadjuk a kérdést, a választ és a pontozási szempontokat, ő pedig ítéletet ad. Ez sokkal olcsóbb és gyorsabb, mint az ember, és jól skálázódik. A módszernek azonban megvannak a maga torzításai, amelyeket ismerni kell. A bíró hajlamos lehet a hosszabb választ jobbnak ítélni pusztán a terjedelme miatt, vagy két válasz összevetésekor a sorrendtől is függhet a döntése. Ezért a bíró sem hiteles önmagában. A bírót magát is validálni kell, tehát egy emberi címkékkel ellátott mintán ellenőrizni, hogy az ítélete valóban egybecseng-e az emberi megítéléssel, mielőtt rábíznánk a méréseket.


kérdés és a válasz pontozási szempontok bíró modell ítéletet és indoklást ad pontszám Vigyázz a torzításokra: a hosszabb válasz és a sorrend is befolyásolhatja a bírót.
Az LLM mint bíró olcsón és gyorsan pontoz, de ismert torzításai vannak. Használat előtt emberi címkéken kell ellenőrizni, hogy az ítélete valóban egybevág-e az emberi megítéléssel.

Tracing és megfigyelhetőség

Egy modellre épülő rendszer akkor is elromolhat, ha minden komponens külön-külön jónak tűnik. A hiba gyakran a lépések közötti átadásban rejlik, például egy rossz visszakeresésben vagy egy elrontott eszközhívásban. Ezért minden kérésről érdemes teljes nyomvonalat, tracet rögzíteni, amely tartalmazza a beérkező kérést, a végső promptot, a visszakeresett dokumentumokat, az eszközhívásokat és azok eredményét, a modell kimenetét, valamint a késleltetést és a költséget lépésenként. Ez a megfigyelhetőség teszi egyáltalán lehetővé egy nem determinista rendszer hibakeresését, mert utólag pontosan végig lehet nézni, mi történt egyetlen konkrét kérés útján. A trace ráadásul az online eval nyersanyaga is, hiszen a valós forgalom rögzített nyomvonalaiból emeljük ki a hibás eseteket, és tesszük be őket a kiértékelő készletbe.


6

Hat mező, amit minden trace-ben rögzíts. A beérkező kérés, a végső prompt, a visszakeresett dokumentumok, az eszközhívások és eredményeik, a modell kimenete, valamint a lépésenkénti késleltetés és költség. Ez a hat mező elég ahhoz, hogy szinte bármely hibát utólag rekonstruálj.


← Előző lecke Következő lecke →

Workshop

AI Transformation Day

Egésznapos, vezetőknek szóló program. Feltérképezzük, hol tart a szervezet, mi az első reális lépés, és milyen belső feltételek szükségesek a sikerhez. A nap végén konkrét, prioritizált cselekvési lista.

Érdekel a program →