Loop Evaluation, Observability and Anti-patterns¶

A final answer önmagában nem elég¶

Agentic rendszerben nem csak azt akarjuk tudni, hogy a final output jó lett-e.

Azt is, hogy:

milyen úton jutott el oda?
hány action kellett?
melyik tool hibázott?
volt-e fölösleges retry?
megfelelően kezelte-e a permissiont?
indokolt volt-e a human approval?
mennyibe került?
mennyi ideig tartott?

Ezért agentic evaluationnél két szint van:

Outcome quality
+
Trajectory quality

Outcome evaluation¶

A klasszikus kérdés:

Elérte-e a goal success conditionjeit?

Például coding agent:

- bug fixed?
- targeted tests pass?
- regression suite pass?
- no unauthorized files changed?

Incident agent:

- correct root cause identified?
- evidence grounded?
- unsafe action avoided?

Ez a minimum.

Trajectory evaluation¶

Két run ugyanazt a helyes végső választ adhatja, de nagyon más minőségű lehet.

Run A¶

read relevant file
run targeted test
patch
verify
finish

Run B¶

search 15 files
call same tool 6 times
change unrelated code
revert
run expensive full suite 4 times
finally fix

Final outcome mindkettőnél pass, de B:

drágább,
lassabb,
nagyobb risk,
kevésbé predictable.

Ezért trajectory metric kell.

Trace data model¶

Egy run trace-je lehet például:

Run
├── goal
├── context build
├── model calls
├── decisions
├── tool calls
├── observations
├── state transitions
├── plan versions
├── verification results
├── approval events
└── final outcome

Minden stephez hasznos:

run_id
step_id
parent_step_id
timestamp
action type
input reference
output reference
latency
cost
status
error category

Correlation ID¶

Distributed runtime esetén ugyanaz a run átmehet:

API
 ↓
queue
 ↓
agent worker
 ↓
MCP/tool service
 ↓
external API

Mindenhol közös:

run_id / trace_id

nélkül nehéz összerakni, mi történt.

Mit mérjünk?¶

Task success rate¶

successful runs / evaluated runs

De legyen domain-specifikus success contract.

Step count¶

average actions per successful run

Segít észrevenni efficiency regressiont.

Tool-call efficiency¶

useful tool calls / total tool calls

Vagy egyszerűbben:

repeated identical calls
unused results
calls after goal already satisfied

Retry rate¶

retries per run
retry success rate
retry by failure class

Replan rate¶

Nem feltétlen rossz.

Túl kevés:

plan fixation possible

Túl sok:

unstable planning

A context számít.

No-progress rate¶

runs triggering no-progress detector

Hasznos loop-quality signal.

Human intervention rate¶

clarifications per run
approval requests per run
escalations per run

Ha túl magas, agent túl bizonytalan vagy túl restriktív.

Latency¶

Érdemes bontani:

model latency
tool latency
queue wait
human wait
active run duration
end-to-end wall clock

Cost¶

model tokens/cost
tool/API cost
compute cost
cost per successful task

A cost per success sokszor informatívabb, mint pusztán cost per run.

Evaluation dataset agentic loophoz¶

Nem csak input/output pár kell.

Egy scenario tartalmazhat:

initial state
user goal
tool fixtures
allowed capabilities
expected critical actions
forbidden actions
success conditions
acceptable trajectory variants

Például:

goal: identify failed deployment cause
initial_state:
  deployment: degraded
fixtures:
  recent_deploy: v42
  error_rate: 18%
expected:
  must_observe:
    - deployment_state
    - error_metric
  forbidden:
    - restart_production_without_approval
success:
  root_cause: config_regression

Nem kell exact trajectory match¶

Agentic tasknak több helyes útja lehet.

Gyenge eval:

expected exact sequence:
A → B → C → D

miközben:

A → C → B → D

ugyanolyan valid.

Jobb invariants:

required evidence observed
forbidden action absent
budget respected
success condition met

Critical path assertions¶

Bizonyos sorrend viszont fontos.

Például:

approval BEFORE production mutation

vagy:

observe current balance BEFORE refund decision

Ezeket deterministic trajectory assertionként lehet tesztelni.

Offline evaluation¶

Agent loopokat érdemes controlled environmentben futtatni:

fixture tool responses,
mocked external systems,
sandbox repository,
recorded/replayed observations,
deterministic failure injection.

Például teszteljük:

tool timeout on first call
second call succeeds

Elvárt:

exactly one retry with same idempotency identity

Failure injection¶

Production reliabilityt ne csak happy pathon evaluáljuk.

Scenariok:

tool timeout,
rate limit,
stale state,
authorization denied,
approval rejected,
model malformed action,
verifier failure,
worker restart,
budget exhaustion.

Ez agentic chaos/reliability testing alapja lehet.

Replay¶

Egy production run observationsorozatát replayelhetjük új skill/model/runtime verzióval.

recorded environment observations
        ↓
new model/runtime version
        ↓
compare decisions

Caution:

Ha az új runtime más toolt hívna, a recorded data lehet, hogy nincs meg.

Ezért replay lehet:

exact deterministic replay,
partial simulation,
sandbox re-execution.

Regression gates¶

Skill/model/runtime update előtt:

baseline eval
 ↓
new version eval
 ↓
compare

Gate például:

success rate must not fall > 2%
unsafe-action rate must remain 0
median cost may increase max 10%
p95 step count max threshold

Nem csak accuracy számít.

Observability productionban¶

Hasznos dashboard:

runs started/completed/failed
success by skill/task
p50/p95 latency
cost per task
model error rate
tool error rate
retry rate
budget exhaustion
human escalation
no-progress triggers

Drill-down:

run → step → model/tool call → observation

Decision logging¶

Nem kell belső chain-of-thoughtot logolni.

Operationally hasznos:

{
  "decision": "QUERY_LOGS",
  "reason_summary": "Error spike correlates with payment endpoint failures",
  "evidence_refs": ["obs-12", "obs-15"]
}

Ez audit/debug számára elég lehet.

Sensitive data logging¶

Agent trace könnyen tartalmazhat:

user data,
email content,
source code,
secrets accidentally returned by tools,
customer records.

Ezért:

redaction
field allowlist
retention policy
access control

kell.

Ne logoljunk vakon minden promptot/tool response-t productionban örökre.

Anti-pattern: loop explosion¶

A run egyre több sub-agentet/sub-loopot indít.

1 parent
→ 4 workers
→ each 4 critics
→ each 3 retries

Cost exponenciálisan nőhet.

Mit figyeljünk:

child-run count
max depth
aggregate budget

Anti-pattern: tool roulette¶

A modell sok toolt próbál random módon:

search
logs
DB
search again
metrics
unrelated API

jelentős progress nélkül.

Signal:

high tool count,
low unique relevant evidence,
no completed subgoal.

Anti-pattern: retry storm¶

same dependency outage
× hundreds of concurrent agents
× retries

Metrics:

retry rate by dependency
concurrent retry count

Mitigation:

backoff/jitter,
circuit breaker,
queue throttling.

Anti-pattern: endless reflection¶

review
repair
review
repair
review

nincs új evidence.

Signal:

verification cycles high
artifact unchanged or oscillating

Bounded repair cycle kell.

Anti-pattern: premature stop¶

A modell megáll, mielőtt success evidence megvan.

Például:

code looks correct → STOP

miközben test nincs.

Metric:

STOP proposals rejected by runtime success gate

Ez nagyon jó diagnostic signal lehet.

Anti-pattern: success hallucination¶

Run COMPLETED, de external state szerint action nem történt meg.

Például:

agent says issue created
GitHub has no issue

Final outcome verification kell.

Anti-pattern: stale observation action¶

A run régi state alapján cselekszik.

Measure:

observation age at action time

Risky actionnél freshness SLO lehet.

Anti-pattern: plan thrashing¶

plan v1
plan v2
plan v3
plan v4

minden step után nagy változás, progress nélkül.

Signal:

plan revisions / completed subgoals

Anti-pattern: hidden deterministic logic a promptban¶

Ha production incidenteknél azt látjuk, hogy a model 99%-ban ugyanazt a known transitiont választja:

if approval rejected → stop

akkor ezt lehet, hogy ki kell emelni deterministic code-ba.

Observability segít felismerni, hol fölösleges az agentic decision.

Run review template¶

Egy hibás run debugolásakor:

1. Goal és success contract jó volt?
2. Canonical state korrekt volt?
3. Relevant observation rendelkezésre állt?
4. Context builder átadta?
5. Model jó actiont választott?
6. Runtime helyesen validálta?
7. Tool helyesen futott?
8. Result jól normalizálódott?
9. Recovery policy helyes volt?
10. Stop condition megfelelően működött?

Ez component-level root cause analysis, nem csak:

"the LLM was bad"

SLO-k agentic runtimehoz¶

Lehetnek például:

successful task rate >= 95%
unsafe execution rate = 0
p95 active latency < 30s
budget exhaustion < 2%
repeated-action detector < 5% runs

A konkrét érték domainfüggő.

Takeaways¶

Agentic evaluationhez outcome + trajectory mindkettő kell.
Trace-ben goal, state transition, action, tool, observation, verification és approval legyen összeköthető.
A success rate mellett step count, retry, cost, latency, no-progress és human intervention is fontos.
Evaluation scenario tartalmazzon environment fixturet és forbidden/required trajectory invariantokat.
Nem mindig exact action sequence-t kell elvárni; inkább critical invariantsot.
Failure injection és sandbox eval production reliabilityhez fontos.
Model/skill/runtime változást baseline/regression gate-tel értékeljük.
Ne logoljunk szükségtelenül sensitive full contextet; redaction és retention kell.
Figyeljük a loop explosion, tool roulette, retry storm, endless reflection, premature stop, stale-state action és plan thrashing jeleit.
Observability célja nem csak monitoring: segít megtalálni, hol kell jobb model, jobb context, jobb tool vagy éppen kevesebb agentic behavior és több deterministic code.