Skill Evaluation and Observability¶
Miért kell skill-szintű evaluation?¶
Ha egy skill reusable software artifact, akkor nem elég annyit mondani:
"Úgy tűnik, működik."
Azt kell tudnunk mérni:
- valóban megoldja-e a taskot,
- helyes skill/tool döntéseket hoz-e,
- betartja-e a contractot,
- milyen hibákat produkál,
- mennyi a latency és cost,
- változtatás után regresszált-e.
Ez a skill evaluation célja.
Evaluation layers¶
Hasznos bontás:
Contract correctness
↓
Task / semantic correctness
↓
Tool-use correctness
↓
Execution-path correctness
↓
Safety / policy correctness
↓
Operational metrics
Nem minden skillhez kell minden réteg ugyanolyan mélységben, de production capabilitynél érdemes végiggondolni őket.
1. Contract correctness¶
Deterministic kérdések:
valid input schema?
valid output schema?
required fields present?
enums valid?
result type allowed?
Ezt normál unit test és schema validation is mérheti.
Példa:
PR Review Skill result must always contain:
- findings[]
- overall_risk
- summary
Ez fontos, de még nem bizonyítja, hogy a review jó.
2. Task success / semantic correctness¶
A valódi kérdés:
Megoldotta-e a skill azt a feladatot, amire készült?
PR Review Skillnél például:
- megtalálta-e a valódi bugot?
- kihagyott-e critical issue-t?
- generált-e false positive-ot?
- evidence-grounded volt-e a finding?
Incident Triage Skillnél:
- helyes severity?
- releváns suspected area?
- indokolt next diagnostic action?
Golden / representative dataset¶
Kell egy stabil evaluation dataset.
Például:
evals/pr-review/
├── duplicate-payment-retry
├── harmless-refactor
├── missing-auth-check
├── flaky-test-only
├── misleading-comment
└── backwards-compatibility-break
Minden case tartalmazhat:
input
relevant context
expected findings / rubric
important non-findings
Az eval dataset ne csak happy path legyen.
Dataset slices¶
Átlag metric elrejtheti a problémát.
Például overall:
91% success
viszont:
Java backend: 96%
Python: 94%
SQL migrations: 61%
Ezért slice-oljunk:
- task type,
- language/domain,
- input length,
- ambiguity,
- tool availability,
- risk category,
- edge case.
Exact match vs semantic rubric¶
Nem minden outputnál jó exact match.
Classification:
expected category = BILLING
→ exact match jó.
Architecture review:
expected wording
→ exact match rossz metric.
Itt rubric kell:
0 = misses the material risk
1 = notices vague concern but no evidence
2 = identifies risk with partial evidence
3 = identifies risk, cites evidence and explains consequence
LLM-as-a-judge¶
Semantic evalnál egy másik model értékelhet rubric alapján.
candidate output
+ reference/rubric
↓
judge model
↓
score + rationale
Ez hasznos scale-nél, de nem ground truth.
Kockázatok:
- judge bias,
- model-family preference,
- verbosity bias,
- inconsistent scoring,
- same blind spots.
Ezért érdemes human-calibrált subsetet fenntartani.
Human evaluation¶
Különösen high-risk vagy szubjektív tasknál szükséges lehet.
Például senior engineer review:
Would this finding be useful in a real code review?
Is severity appropriate?
Is the evidence convincing?
A human eval drágább, ezért jól használható:
- baseline létrehozásra,
- judge calibrationre,
- regressziók vizsgálatára,
- high-risk esetekre.
Tool-use evaluation¶
Tool-backed skillnél nem elég a final answer.
Mérjük:
selected correct tool?
arguments correct?
unnecessary tool calls?
repeated calls?
forbidden tool requested?
used fresh data when required?
Például:
Question: current account balance
A final answer véletlenül lehet helyes training/context alapján, de ha a skill nem hívott current balance toolt, architecture szempontból hibás execution.
Trajectory / execution-path evaluation¶
Agentic skillnél a végső result mellett az út is számít.
Goal
↓
Tool A
↓
Tool B
↓
Skill decision
↓
Tool C
↓
Result
Vizsgálhatjuk:
- felesleges lépések számát,
- repeated actiont,
- megfelelő stop conditiont,
- unsafe intermediate actiont,
- szükséges evidence beszerzését.
Egy jó final answer nem tesz elfogadhatóvá egy veszélyes köztes actiont.
Safety evaluation¶
Külön dataset kellhet:
prompt injection
unauthorized write request
cross-tenant data request
malicious retrieved content
secret extraction request
Expected behavior:
DENY
REQUIRE_APPROVAL
IGNORE_UNTRUSTED_INSTRUCTION
NO_CROSS_TENANT_ACCESS
A security eval ne csak „red team egyszer” legyen, hanem regression suite.
Failure-mode evaluation¶
Teszteljük a hibákat is:
tool timeout
rate limit
resource missing
partial result
invalid input
context too large
approval denied
A skillnek ilyenkor helyes explicit failure state-et kell adnia, nem hallucinált resultot.
Operational metrics¶
Productionban mérjük például:
success rate
partial-result rate
failure rate
retry rate
human-escalation rate
tool-call count
model-call count
input/output tokens
latency
cost
Ezek önmagukban nem quality metric-ek, de trendekhez fontosak.
Latency bontás¶
Ne csak total latency legyen.
routing: 100 ms
retrieval: 300 ms
model call 1: 2.4 s
tool call: 900 ms
model call 2: 1.8 s
Így látszik, hol érdemes optimalizálni.
Cost attribution¶
Skill-level cost:
input tokens
output tokens
number of model calls
tool/provider cost
retrieval/rerank cost
Agentic compositionnél különösen fontos, mert egy simple user request mögött 10-20 model/tool operation is lehet.
Observability: trace mental model¶
Egy execution kapjon trace/execution ID-t:
execution_id: exec-1842
Trace:
route skill
↓
load context
↓
model call
↓
tool request
↓
tool execution
↓
model call
↓
validation
↓
result
Minden spanhoz:
duration
status
skill version
model
selected tool
error category
Mit logoljunk?¶
Hasznos metadata:
execution id
skill name/version
model/provider
prompt/template version or hash
input schema version
output type
retrieved source ids
tool names + sanitized args
tool result status
latency/cost
validation errors
Ne logoljunk kritikátlanul:
raw secrets
full customer PII
credentials
sensitive documents
Observability is a data-security problem too.
Prompt/model version mindig legyen trace-elhető¶
Ha tegnap jó volt, ma rossz:
Mi változott?
Tudnunk kell:
skill v2.3
prompt v14
model X-2026-08-01
router v4
retriever config 7
Enélkül reprodukálhatatlan regressziók lesznek.
Regression testing¶
Változtatás előtt:
baseline eval
utána:
candidate eval
és compare:
critical recall: 94% → 95%
false positive rate: 8% → 17% ❌
latency: 3.1s → 2.8s
cost: +4%
Nem elég egyetlen aggregate score.
Trade-offokat látni kell.
Release gate¶
Lehet policy:
critical safety suite must be 100%
no more than 2% regression in task success
p95 latency < target
A konkrét threshold domainfüggő.
A lényeg: skill update ne csak „looks better” alapon menjen productionbe.
Online evaluation¶
Production feedback:
user correction
human override
reopened ticket
PR review finding accepted/rejected
incident recommendation followed/ignored
Ezek értékes signalok.
De online metric torzulhat:
- selection bias,
- users don't always provide feedback,
- easy/hard task mix változik.
Ezért offline stable eval + online monitoring együtt jó.
Drift¶
Quality változhat akkor is, ha a skill kódja nem változik:
input distribution changes
external data changes
model provider update
new repository patterns
new attack patterns
Ezért időszakos re-evaluation hasznos.
Example: PR Review eval matrix¶
| Dimension | Metric |
|---|---|
| Critical bug detection | recall |
| False findings | precision / false-positive rate |
| Evidence grounding | rubric score |
| Correct tool use | tool-call accuracy |
| Read-only safety | forbidden-action rate |
| Efficiency | calls / tokens / latency |
| Contract | schema validity |
Nem kell minden metricet egyetlen score-ba összenyomni.
Debugging failed execution¶
Egy jó trace-ből válaszolható:
wrong skill selected?
wrong context retrieved?
model reasoned badly?
tool returned stale/error data?
validation too weak?
policy denied valid action?
Ez nagyon fontos architecture benefit.
Ha csak final answer van logolva, minden failure „LLM rossz volt” kategóriába kerül.
Anti-pattern: vibe-based evaluation¶
I tried 10 prompts and they looked good.
POC-nál elég lehet. Production regression protectionnek nem.
Anti-pattern: csak schema validity¶
100% valid JSON
lehet 100% rossz semantic output mellett is.
Anti-pattern: csak final answer¶
Unsafe vagy pazarló trajectory rejtve marad.
Anti-pattern: egyetlen overall score¶
Skill score: 87
nem mondja meg, hogy security, latency vagy critical recall romlott-e.
Takeaways¶
- Skillhez legyen representative evaluation dataset, ne csak manuális próba.
- Külön mérjük a contractot, semantic task success-t, tool use-t, trajectoryt és safetyt.
- Exact match csak ott jó, ahol a domain tényleg exact.
- Semantic taskhoz rubric/human/LLM judge kombináció használható.
- Tool-backed skillnél az execution path is része a correctnessnek.
- Failure mode-okat is explicit eval case-ként teszteljük.
- Production observabilityben skill/model/prompt/tool verzió legyen trace-elhető.
- Latencyt és costot komponensenként bontsuk.
- Release előtt baseline-vs-candidate regression compare kell.
- Offline stable eval és online monitoring együtt ad jó képet.
- Observability logolásnál data minimization és secret handling ugyanúgy fontos.