Honnan tudod, hogy az AI rendszered tényleg működik? (eval suite útmutató)

Az AI projektek legnagyobb csendes kockázata nem a hibás kód — hanem hogy senki sem tudja megmondani, valóban működik-e a rendszer. A 'kipróbáltam párszor és jó volt' nem mérés. Egy eval suite az, ami megmondja a valós pontosságot, elkapja a regressziót modellváltáskor, és bizonyítékot ad az ügyfélnek. Ez az útmutató lebontja, hogyan építs ilyet.

Miért nem elég az 'úgy tűnik, működik'

Az LLM-ek nem-determinisztikusak: ugyanarra a kérdésre ma jó választ adnak, holnap rosszat. Egy demó során a fejlesztő öntudatlanul a könnyű kérdéseket teszi fel. Az első éles deploy után három hónappal derül ki, hogy a valós pontosság 90% helyett 55%. Az eval suite ezt a vakfoltot szünteti meg — számszerű, ismételhető mérést ad.

1. lépés: golden set építése

A golden set 50–200 kérdés-válasz pár, ami a valós használatot tükrözi. Ne te találd ki — gyűjtsd a tényleges felhasználói kérdésekből vagy a domain-szakértőtől. Mindegyikhez tartozzon: a kérdés, az elvárt válasz (vagy elfogadási kritérium), és RAG-nál a forrás-dokumentum, amiből jönnie kell. A nehéz, peremeset kérdéseket is tedd bele — azok mutatják meg a valós teljesítményt.

2. lépés: a megfelelő metrikák

• Hit rate (RAG) — a retrieval kikereste-e a helyes chunk-ot? Ha nem, a legjobb LLM sem tud jó választ adni.
• Faithfulness — az LLM válasza a kikért chunk-okból jön-e, vagy hallucinál? Regulated domain-ben ez a legfontosabb.
• Answer relevance — a válasz tényleg a feltett kérdésre felel-e?
• Tone / format compliance — a válasz tartja-e az elvárt hangnemet és struktúrát (pl. JSON séma, magyar formális stílus)?
• Latency és cost — a válaszidő és a token-költség kérdésenként, mert ezek skálázáskor robbannak.

3. lépés: az eszközök

• Ragas — RAG-specifikus metrikák (faithfulness, context precision) automatikus mérése.
• Promptfoo — prompt- és modell-összehasonlítás, CI-be köthető, YAML-alapú teszt-definíció.
• LangSmith — Anthropic/OpenAI hívások trace-elése, dataset-kezelés, eval futtatás egy helyen.
• LLM-as-judge — egy erős modell (pl. Claude Opus) pontozza a válaszokat egy rubrika alapján, ahol nincs egzakt elvárt válasz.

4. lépés: a gyakoriság

Az eval nem egyszeri esemény. Futtasd: minden prompt-változtatás után (CI-ben), minden modellváltáskor (a vendor új verziót ad ki — a tied csendben romolhat), és heti rendszerességgel a production forgalom új mintáin. Ha a hit rate vagy a faithfulness egy küszöb alá esik, az build-et bukásra állítod — pont mint egy unit teszt.

“A RAG és agent rendszerek 80%-a azon bukik el, hogy nem csinálnak eval suite-ot. Az első éles deploy után azt hiszik, működik — aztán három hónap múlva derül ki, hogy 40%-os a valós pontosság.”

A lényeg

Az eval suite nem 'nice to have' — ez a különbség egy demó és egy production rendszer között. Építsd meg a golden set-et a fejlesztés ELSŐ hetében, ne az utolsóban. Ha egy szállító nem beszél eval-ról az ajánlatában, az piros zászló: olyan rendszert épít, amiről maga sem tudja, működik-e.