10 – Reliability és Determinisztikus Boundaryk¶

Az LLM-alapú rendszerek két külön világot kombinálnak:

probabilistic model behavior
          +
deterministic software behavior

A megbízható AI application ott működik jól, ahol ezek a boundaryk explicitek.

Alapszabály:

Az LLM-et interpretationre, generationre, rankingre és flexible reasoningre használd. Determinisztikus software garantálja a contractokat, permissionöket, invariantokat, pénzügyi szabályokat, identityt, persistence-t és side effecteket.

Miért fontos ez?¶

Egy normál functiontől elvárjuk, hogy pontosan a kód szerint fusson.

result = calculate_vat(1000, 0.27)

Azonos input és kód mellett ugyanazt az eredményt várjuk.

Egy LLM-call más:

same prompt
same model
same context
    ↓
possibly different wording or decision

Még stabil model behaviour mellett is törékeny architecture-t kapunk, ha tökéletesen determinisztikus komponensként kezeljük.

Döntsd el, mit dönthet el a modell¶

Hasznos architecture kérdés:

Mi igényel judgmentet?
Mi igényel guarantee-t?

Példa: support-ticket routing.

Ésszerű LLM responsibility:

classify message as:
- billing
- technical
- account
- other

Deterministic responsibility:

if category == "billing":
    assign billing queue

Az LLM értelmezi a nyelvet. Az application hajtja végre a valódi routing rule-t.

Kritikus invariant ne csak promptban legyen¶

Gyenge design:

System prompt:
"Never approve refunds above 500 EUR."

Ez segíthet a model behaviouren, de nem ez legyen az enforcement layer.

Jobb:

if refund.amount > 500:
    require_manager_approval()

A prompt elmagyarázhatja a policyt, de a determinisztikus kód enforce-olja.

Structured output mint boundary¶

Tegyük fel, hogy a modell requestet klasszifikál.

Ehelyett:

"This seems quite urgent and probably related to billing."

inkább contract:

{
  "category": "billing",
  "priority": "high"
}

Majd használat előtt validáld.

LLM
 ↓
structured result
 ↓
schema validation
 ↓
business validation
 ↓
application logic

Ez csökkenti a determinisztikus core-ba bejutó free-form model behaviour mennyiségét.

A validation több rétegű¶

Példa:

{
  "currency": "EUR",
  "amount": 1000000
}

Lehet valid JSON és schema-valid is.

Business logic mégis elutasíthatja.

Gondolkodj rétegekben:

1. Syntax / transport validity
2. Schema / type validity
3. Business-rule validity
4. Authorization validity
5. Side-effect execution

Ne mosd ezeket egyetlen promptba.

Retry¶

A retry hasznos transient failure esetén, de veszélyes vakon alkalmazva.

Lehetséges retryable failure:

model timeout,
provider 5xx,
temporary rate limit,
network error,
temporary tool outage.

Nem automatikusan retryable:

invalid user input,
permission denied,
business-rule violation,
rossz promptból eredő ismételt malformed logic,
non-idempotent side effect, amely lehet, hogy már sikerült.

A jó retry policy különbséget tesz failure classok között.

failure
  ↓
classify
  ├── transient → retry
  ├── permanent → stop
  └── ambiguous side effect → reconcile before retry

Idempotency¶

Az idempotency különösen fontossá válik, amikor agent vagy tool-enabled system actiont ismételhet.

Példa:

LLM → create_payment(100 EUR)
network timeout
application nem tudja, sikerült-e a payment
retry

Idempotency nélkül a customer kétszer fizethet.

Biztonságosabb:

create_payment(
    amount=100,
    idempotency_key="order-123-payment"
)

Az external system felismeri, hogy az ismételt request ugyanaz a logical operation.

Ez nem specifikusan AI elv. AI systemben azért fontosabb, mert a retry és loop gyakoribb.

Timeoutok és budgetek¶

Minden model- vagy tool-callnak legyen limitje.

Példák:

request timeout,
maximum tool-call count,
maximum loop iterations,
maximum total elapsed time,
maximum token usage,
maximum cost per task.

Explicit limit nélkül:

agent
 ↓
retry
 ↓
search
 ↓
retry
 ↓
tool
 ↓
search
 ↓
...

korlátlan processzé válhat.

Stop conditionök¶

Agentic workflow-kban determinisztikus stop condition kell a probabilisztikus reasoning köré.

Példák:

stop if task completed
stop if max_steps == 10
stop if cost > budget
stop if tool returns terminal error
stop if human approval is required

Ne csak a modellre bízd, hogy eldöntse, mikor végzett.

Fallbackok¶

Fallback több szinten létezhet.

Model fallback¶

primary model unavailable
       ↓
secondary model

Behavior fallback¶

AI classification confidence/evaluation check fails
       ↓
manual queue

Tool fallback¶

semantic search unavailable
       ↓
keyword search

Product fallback¶

AI answer cannot be supported safely
       ↓
show source documents or escalate to human

A fallback legyen szándékosan tervezett, ne random emergency code.

A confidence trükkös¶

Ne feltételezd, hogy egy model-generated szám, például:

{
  "confidence": 0.98
}

kalibrált probability.

A modell képes confidence mezőt generálni, mert ezt kérted, de ebből nem következik, hogy a 0.98-ra címkézett esetek 98%-a helyes.

Ha confidence fontos, kalibráld evaluation data alapján, vagy használj megbízhatóbb signalokat.

Példa: invoice extraction¶

Cél: invoice data kinyerése uploaded textből.

Model output:

{
  "invoice_number": "INV-2026-991",
  "currency": "EUR",
  "total": 1250.50
}

Reliable flow:

uploaded document
      ↓
LLM extraction
      ↓
schema validation
      ↓
check currency against allowed list
      ↓
check total >= 0
      ↓
check invoice number uniqueness
      ↓
possibly verify against source text
      ↓
persist domain object

A modell fuzzy extractiont végez. Az application védi az invariantokat.

Példa: code-generation agent¶

Az agent code change-et javasol.

Gyenge flow:

LLM writes code
 ↓
merge

Jobb flow:

LLM writes code
 ↓
formatter
 ↓
compiler / type checker
 ↓
unit tests
 ↓
integration tests
 ↓
static analysis
 ↓
review / policy checks
 ↓
merge

Minél több determinisztikus verificationt tudsz a generation után tenni, annál biztonságosabban automatizálhatsz.

Az AI-assisted software engineering egyik legerősebb patternje:

A modell generáljon candidate-et. A determinisztikus rendszer ellenőrizze azt, ami ellenőrizhető.

Failure recovery¶

A megbízható rendszer explicit failure state-et tart.

Ehelyett:

something failed → ask model to try something else

strukturált state:

{
  "step": "create_ticket",
  "attempt": 2,
  "status": "failed",
  "error_code": "RATE_LIMIT",
  "retryable": true
}

Így az orchestration logic, nem pusztán a model intuition dönti el a következő lépést.

Observability¶

Production systemben elegendő adatot rögzíts a failure és cost megértéséhez, sensitive content kiszivárogtatása nélkül.

Hasznos signalok:

model name/version,
prompt/template version,
request latency,
input/output token counts,
tool calls,
tool latency,
retry count,
finish reason,
validation failures,
evaluation metrics,
total task cost.

Observability nélkül az AI reliability probléma könnyen random anecdote-nak tűnik.

A reliability system-level¶

Ne csak ezt kérdezd:

"How accurate is the model?"

Hanem ezt:

What happens when the model is wrong?

Nem tökéletes modell is támogathat nagyon megbízható applicationt, ha a hibák boundedek, detectálhatók, validálhatók vagy biztonságosan recoverelhetők.

Erősebb modell nem váltja ki a jó system designt.

Gyakorlati boundaryk¶

Jó LLM-candidate:

summarize text,
classify ambiguous language,
extract fuzzy information,
generate drafts,
rank candidates,
propose plans,
interpret user intent.

Jó deterministic-code candidate:

authorization,
monetary calculations,
schema validation,
database constraints,
retry policy,
workflow limits,
rate limiting,
state transitions,
final safety checks.

Mentális modell¶

Probabilistic intelligence
        ↓
controlled interface
        ↓
deterministic guardrails
        ↓
real side effects

A cél nem az, hogy az LLM determinisztikus legyen.

A cél olyan rendszer, ahol a probabilisztikus behaviour ott használatos, ahol értéket ad, és determinisztikus boundaryk védik azt, ahol guarantee szükséges.