11 – Evaluation alapok¶

AI rendszereket könnyű érzés alapján javítani, és nehéz bizonyíték alapján.

Egy prompt demóban jobbnak tűnhet, miközben valós eseteken rosszabbul teljesít.

Az evaluation erre válaszol:

Tényleg jobb lett a rendszer?

Miért nem elég a normál unit testing?¶

A hagyományos teszt gyakran ilyen:

assert add(2, 2) == 4

Egy LLM-válasznál sok érvényes output létezhet.

Kérdés:

Summarize this support ticket in one sentence.

Több különböző summary is lehet helyes.

Ezért az AI evaluation általában kombinál:

deterministic checkeket,
reference example-öket,
semantic checkeket,
model-based judgingot,
human review-t.

Kezdj reprezentatív datasettel¶

Készíts valós vagy realisztikus inputokból olyan halmazt, amely reprezentálja a taskot.

Példa support classificationre:

input                                      expected
-------------------------------------------------------------
"I was charged twice"                    billing
"The app crashes when I sign in"         technical
"Please change my email address"         account

Egy jó datasetben easy case és edge case is van.

Ne csak azokon a példákon evaluálj, amelyeket a prompt írásakor használtál.

Golden examples¶

A golden dataset ismert elvárt behaviourrel rendelkező példákat tartalmaz.

Extraction példa:

{
  "input": "Invoice INV-42 total 120 EUR",
  "expected": {
    "invoice_number": "INV-42",
    "currency": "EUR",
    "total": 120
  }
}

Classificationnél exact expected label jól használható.

Open-ended generationnél egyetlen exact answer helyett gyakran hasznosabb elvárt propertyket definiálni.

Determinisztikus evaluation¶

Ha maga a requirement determinisztikus, használj deterministic checket.

Példák:

Schema correctness¶

Valid az output a required schema szerint?

Classification accuracy¶

predicted category == expected category

Required citations¶

Minden factual answer tartalmaz legalább egy source reference-t?

Safety rules¶

Hívott a rendszer restricted toolt authorization nélkül?

Ezek olcsók, repeatable-ek és könnyen érthetők.

Exact match¶

Exact match hasznos például:

ID-knál,
labeleknél,
boolean decisionöknél,
normalized value-knál,
structured extractionnél.

Példa:

expected: "billing"
actual:   "billing"

Natural-language generationnél általában túl szigorú.

Két helyes válasz teljesen eltérő megfogalmazást használhat.

Property-based evaluation¶

A teljes answer összehasonlítása helyett teszteld a kötelező propertyket.

Generated email esetén:

- 150 szónál rövidebb legyen
- említse az order ID-t
- ne ígérjen refundot
- professional tone-t használjon

Néhány property determinisztikusan ellenőrizhető, mások semantic evaluationt igényelnek.

Semantic evaluation¶

A semantic check a jelentést értékeli, nem az exact textet.

Példák:

megőrizte a válasz a kulcs tényeket?
kihagyott a summary fontos problémát?
megválaszolta a user kérdését?
támogatja a választ a retrieved context?

Ehhez használható embedding, classifier, evaluator model vagy human review.

LLM-as-a-judge¶

Egy másik modell explicit criteria alapján értékelheti az outputot.

Példa evaluator instruction:

Score the answer from 1 to 5 for factual consistency with the provided source.
Do not score writing style.
Return only the score and a short reason.

Ez jobban scale-elhet a manual review-nál, de a judge maga is probabilisztikus.

Ezért:

definiálj világos rubricot,
teszteld a judge-ot human labelhez képest,
ahol lehet, használj deterministic checket,
ne kezeld a judge-ot ground truthként.

Rubrics¶

A rubric explicitté teszi a szubjektív criteriát.

Példa RAG-answer rubric:

5 - teljesen válaszol, minden factual claim supported
4 - helyes, de egy kisebb detail hiányzik
3 - részben helyes vagy gyengén supported
2 - jelentős hibák
1 - többnyire helytelen vagy unsupported

Rubric nélkül az evaluator score-ok nehezebben hasonlíthatók össze időben.

Human evaluation¶

Human review továbbra is hasznos, amikor:

a quality erősen szubjektív,
domain expertise kell,
fontos safety consequence van,
az automatic evaluation nem elég trustworthy.

Human reviewból létrejöhet az a labeled dataset is, amellyel később automatizálható az evaluation.

Evaluáld külön a komponenseket¶

Egy AI application több külön komponens miatt hibázhat.

Példa RAG system:

query
 ↓
retrieval
 ↓
context
 ↓
generation

Egy rossz answer oka lehet:

a retrieval rossz dokumentumot talált,
a releváns dokumentum túl alacsonyra rankelt,
a context truncated lett,
a modell ignorálta a helyes contextet,
a modell hallucinated.

Ha csak a final answert evaluálod, nehezebb diagnosztizálni a failure-t.

Retrieval evaluation¶

Gyakori kérdések:

Megtaláltuk a releváns dokumentumot?
Benne volt a top K-ban?
Mennyi irreleváns contextet hoztunk be?

Lehetséges metric:

precision,
recall,
hit rate,
ranking metrics.

Kezdetben kevésbé fontos a pontos metric, mint hogy a retrieval qualityt külön kezeld az answer qualitytől.

Tool-use evaluation¶

Tool-enabled agentnél evaluáld:

a megfelelő toolt választotta?
helyesek voltak az argumentumok?
hívott felesleges toolt?
jó időben állt meg?
megsértett permission boundaryt?
helyesen recoverelt tool failure-ből?

Példa test case:

User: "What is the status of order 123?"
Expected tool: get_order
Forbidden tool: cancel_order

Trajectory evaluation¶

Multi-step agentnél a final answer lehet helyes úgy is, hogy az út ineffektív vagy veszélyes volt.

Trajectory:

search
 ↓
read file
 ↓
search again
 ↓
run test
 ↓
edit
 ↓
run test

Ne csak a final resultot evaluáld, hanem:

step count,
unnecessary calls,
repeated calls,
risky actions,
cost,
recovery behavior.

Ez később agentic loopnál különösen fontos lesz.

Regression testing¶

Minden prompt-, model-, retrieval- vagy tool-change módosíthatja a behaviourt.

Kezeld az AI change-et software changeként:

change
 ↓
run evaluation suite
 ↓
compare against baseline

Példa:

Version A
accuracy: 87%
avg latency: 1.8 s
avg cost: $0.012

Version B
accuracy: 91%
avg latency: 3.6 s
avg cost: $0.031

B pontosabb, de a trade-off nem biztos, hogy megéri.

Baselines¶

Mindig hasonlíts valamihez.

Lehetséges baseline:

previous prompt,
previous model,
simple keyword classifier,
deterministic rule system,
human performance,
no-RAG model answer.

Baseline nélkül egy metricnek kevés contextje van.

Offline vs online evaluation¶

Offline¶

Ismert test case-ek futtatása release előtt.

Jó:

regression testhez,
model comparisonhöz,
prompt experimenthez.

Online¶

Valódi production behaviour mérése.

Példák:

user satisfaction,
escalation rate,
tool failure rate,
task completion rate,
correction rate,
latency és cost.

Offline evaluation védi a release-t. Online evaluation mutatja meg, hogy a product a valóságban működik-e.

Példa: classification change¶

Tegyük fel, módosítod a support-classification promptot.

Gyenge process:

try 5 examples manually
 ↓
looks better
 ↓
deploy

Jobb:

200 labeled historical tickets
 ↓
run old prompt
 ↓
run new prompt
 ↓
compare accuracy by category
 ↓
inspect regressions
 ↓
measure latency and cost
 ↓
decide whether to deploy

Példa: coding agent¶

Evaluation dataset:

20 small repository tasks

Metrics:

- tests passing
- compilation success
- task completion
- number of files unnecessarily modified
- tool calls
- total tokens
- elapsed time

Ez sokkal hasznosabb, mint megkérdezni, hogy a generated code „jól néz-e ki”.

Kerüld az egyszámos evaluationt¶

AI system gyakran több dimenziót optimalizál:

quality
latency
cost
safety
user experience

Egy modell, amely 1% qualityt nyer, de 10x costot okoz, rosszabb product decision lehet.

Egyetlen mágikus metric helyett használj kis scorecardot.

Építs evaluationt korán¶

Gyakori hiba:

build entire AI product
 ↓
then think about evaluation

Jobb:

define task
 ↓
collect representative examples
 ↓
define success criteria
 ↓
build
 ↓
evaluate continuously

Az evaluation lesz az AI engineering feedback loopja.

Gyakorlati első evaluation setup¶

Új AI feature esetén:

gyűjts 20–100 reprezentatív case-t,
definiáld az expected outputot vagy propertyket,
először deterministic checkeket adj hozzá,
evaluator modelt csak oda, ahol szükséges,
ments baseline metricet,
futtasd a suite-ot prompt/model change után,
nézd át kézzel a failure-öket,
production failure-ből folyamatosan bővítsd a datasetet.

Mentális modell¶

AI development without evals
        =
manual guessing at scale

Jobb loop:

hypothesis
 ↓
change
 ↓
evaluation
 ↓
error analysis
 ↓
next change

Az evaluation célja nem annak bizonyítása, hogy a modell tökéletes. Hanem hogy az AI development mérhető, összehasonlítható és kevésbé anecdote-driven legyen.