Reflection, Verification and Critique¶

Reflection nem egyenlő verificationnel¶

Agentic rendszereknél gyakori ötlet:

model produces answer
 ↓
ask model: "Are you sure?"
 ↓
model thinks again

Ez néha javít a minőségen, de önmagában gyenge guarantee.

A fontos különbség:

Reflection
= a modell újraértékeli a saját eredményét

Verification
= külső vagy függetlenebb evidence alapján ellenőrizzük az eredményt

New evidence is generally stronger than another pass over the same assumptions.

Mikor hasznos reflection?¶

Reflection segíthet:

obvious inconsistency észlelésében,
hiányzó edge case felismerésében,
output rubric szerinti önellenőrzésben,
plan vagy action újraértékelésében,
repair candidate generálásában.

Például:

Draft answer
 ↓
Check:
- answered all requested fields?
- claims supported by evidence?
- any contradictions?

Ez hasznos quality pass lehet.

Mikor gyenge?¶

Ha a probléma forrása hiányzó vagy hibás evidence.

Példa:

Model assumes production version = 7.4.1

Majd:

"Think again carefully."

A modell ettől nem kap új deployment state-et.

Jobb:

get_current_deployment()
 ↓
new observation
 ↓
re-evaluate

Verification hierarchy¶

Nem minden verifier azonos erősségű.

Deterministic verifier¶

Példák:

JSON Schema validation
unit tests
compiler
static type checker
linter
policy engine
database constraint
cryptographic hash

Ha a property determinisztikusan ellenőrizhető, általában ezt preferáljuk.

External state verifier¶

Például:

Did deployment actually reach READY?
Did GitHub PR actually merge?
Does invoice actually exist?

A current source of truthból kérdezünk.

Semantic verifier¶

Vannak dolgok, amiket nem lehet egyszerű boolean szabállyal ellenőrizni.

Például:

Does this review finding correctly identify a real architecture risk?

Itt lehet:

human review,
rubric-based evaluator,
second model / judge,
domain-specific heuristic.

Ez gyengébb guarantee, de még mindig strukturáltabb, mint sima self-confidence.

Generate → Verify → Repair¶

Fontos loop pattern:

Generate candidate
       ↓
Verify candidate
       ↓
Pass? ── yes → finish
  │
  no
  ↓
Repair using verifier feedback
       ↓
Verify again

Példa coding agent:

edit code
 ↓
compile
 ↓
compiler error
 ↓
repair
 ↓
unit test
 ↓
failed assertion
 ↓
repair
 ↓
regression suite

A verifier feedback explicit observationként kerül vissza a loopba.

Verifier output legyen strukturált¶

Gyenge:

"Something seems wrong."

Jobb:

{
  "status": "FAILED",
  "checks": [
    {
      "name": "payment-regression",
      "status": "FAILED",
      "evidence": "RefundRetryTest failed: expected 1 charge, got 2"
    }
  ]
}

A repair step így konkrét evidence-re reagál.

Critic pattern¶

Lehet külön critic role/component:

Producer
  ↓ candidate
Critic
  ↓ findings
Producer / Repairer
  ↓ revised candidate

A critic lehet:

ugyanaz a model más instructions-szel,
másik model,
külön skill,
human,
deterministic verifier kombinációja.

Fontos:

Egy külön „critic agent” nem automatikusan független vagy helyes.

Ha ugyanazt a rossz contextet és ugyanazokat a téves assumptionöket kapja, ugyanazt a hibát megerősítheti.

Independent evidence¶

A valódi érték sokszor nem a külön agent személyiségből, hanem az eltérő evidence source-ból jön.

Példa:

Generator:
reads implementation

Verifier:
runs tests + checks runtime output

Ez erősebb, mint:

Generator model
 ↓
Same model asks itself whether code is correct

Verifier independence dimensions¶

Lehet függetlenséget növelni:

más data source,
deterministic checker,
más model family,
külön prompt/rubric,
hidden expected output test fixture,
human reviewer.

Nem kell minden dimenziót használni, csak tudjuk, mit akarunk ellenőrizni.

Reflection before action¶

Nem csak final outputnál lehet reflection.

Magasabb risk action előtt:

Proposed action: restart production service
 ↓
Check:
- current state fresh?
- approval exists?
- safer diagnostic action available?
- expected effect explicit?

De a hard checks továbbra is runtime policyk legyenek.

Reflection nem helyettesíti:

authorization
approval token
precondition validation

Confidence vs evidence¶

Model output:

confidence: 0.95

nem ugyanaz, mint:

test suite passed

A confidence lehet routing signal, de nem hard correctness proof.

Például:

high confidence + no source evidence

még mindig gyenge.

Verification budget¶

A verification maga is loop lehet.

Veszély:

generate
 ↓
critic
 ↓
repair
 ↓
critic
 ↓
repair
 ↓
...

Ez endless reflection.

Ezért:

{
  "max_repair_cycles": 3,
  "required_verifiers": ["schema", "unit_tests"],
  "optional_verifiers": ["semantic_review"]
}

Ha három repair után sem megy:

BLOCKED / human escalation

Verification ordering¶

Érdemes olcsóbb/gyorsabb checkkel kezdeni.

Például code generation:

1. syntax/format
2. compile/typecheck
3. targeted unit test
4. regression suite
5. expensive integration test

Ne futtassunk 20 perces integration suite-ot olyan code-on, ami nem compile-ol.

Semantic verification example: PR review¶

Generator találat:

{
  "severity": "HIGH",
  "claim": "This retry can charge twice."
}

Verification:

1. evidence location exists?
2. call path really reaches non-idempotent charge?
3. retry can actually repeat after ambiguous failure?
4. existing idempotency key prevents duplication?

Ha 4. pont szerint van protection:

finding rejected

A verifier nem csak szövegstílust néz, hanem claim-evidence kapcsolatot.

Verification example: data extraction¶

LLM output:

{
  "invoice_total": 1200.00,
  "currency": "EUR"
}

Checks:

schema valid? ✅
source document actually contains 1200 EUR? ✅
line-item sum equals total? ❌

Ez mutatja:

schema correctness
≠
semantic/business correctness

Model-as-judge¶

LLM judge hasznos lehet, ha:

semantic qualityt kell mérni,
sok candidate van,
rubric jól definiált,
deterministic metric nincs.

De production hard gate-nél óvatosan.

Jó pattern:

hard deterministic checks
       +
semantic judge
       +
periodic human calibration

Verification feedback mint observation¶

Verifier result legyen runtime observation:

{
  "type": "VERIFICATION_RESULT",
  "verifier": "unit_test_runner",
  "status": "FAILED",
  "evidence": "RetryTest: duplicate charge"
}

Ez alapján a next decision:

REPAIR
REPLAN
STOP_FAILED
ASK_HUMAN

Anti-pattern: „Are you sure?” loop¶

LLM: answer A
System: are you sure?
LLM: yes

Ez kevés plusz signal.

Ha fontos, adjunk:

rubricot,
evidence-t,
verifier outputot,
konkrét contradictiont.

Anti-pattern: critic ugyanazt a hallucinationt erősíti¶

producer sees false stale fact
critic sees same false stale fact
critic says result looks correct

A critic nem lett source of truth.

Anti-pattern: verification nélkül mutating action¶

generated migration
 ↓
immediately apply production

Jobb:

generate
 ↓
validate syntax
 ↓
run in sandbox/staging
 ↓
review impact
 ↓
approval
 ↓
production

Takeaways¶

Reflection és verification külön fogalom.
Self-reflection hasznos quality pass lehet, de új evidence nélkül limitált.
Deterministic/external verifier erősebb, ahol használható.
A generate → verify → repair pattern az egyik legfontosabb bounded agentic loop.
Verifier output legyen strukturált és evidence-backed.
Critic agent nem automatikusan független; a data source és checker diversity számít.
Confidence nem correctness proof.
Verification loopnak is kell budget és stop condition.
Olcsó deterministic checkeket futtassuk a drágább semantic/integration checkek előtt.
Verifier result observationként menjen vissza a canonical run state-be.