14. AI Application Mental Model¶

Az utolsó foundation lépés az, hogy ne úgy gondoljunk az AI applicationre, mint „egy promptra, amely egy modellhez csatlakozik”, hanem mint normál software systemre, amely egy vagy több probabilisztikus komponenst tartalmaz.

Az LLM fontos, de nem maga az application.

Core architecture¶

User / Client
      ↓
Application API
      ↓
Orchestration / Application Logic
      ↓
+----------------+----------------+----------------+
|                |                |                |
LLM          Retrieval         Tools / APIs     Memory / State
|                |                |                |
+----------------+----------------+----------------+
      ↓
Validation / Policy / Business Rules
      ↓
Response / Side Effect

Az application dönti el:

mit lát a modell,
melyik model fut,
milyen toolok elérhetők,
milyen data retrieve-olható,
milyen state persistálódik,
milyen output shape fogadható el,
milyen action authorizált,
mikor kell megállni,
hogyan kezeljük a failure-t.

Probabilistic core, deterministic shell¶

Hasznos mentális modell:

Deterministic application shell
        ↓
Probabilistic AI capability
        ↓
Deterministic validation / execution

Az LLM erős például:

natural language understanding,
classification,
extraction,
synthesis,
ambiguity resolution,
planning,
alternatives generálása,
tool választás.

A deterministic code erősebb például:

authorization,
exact arithmetic,
persistence,
constraints,
transaction boundaries,
idempotency,
schema validation,
rate limits,
workflow invariants.

Az architecture mindkettőt használja.

End-to-end request lifecycle¶

Tegyük fel, egy support assistant ezt kapja:

"Can you refund the headphones I bought last week?"

Production-style flow lehet:

1. HTTP request
        ↓
2. Authentication
        ↓
3. Load conversation / relevant state
        ↓
4. Retrieve authorized customer/order context
        ↓
5. Build model context
        ↓
6. Call LLM
        ↓
7. Model requests get_order(order_id)
        ↓
8. Application validates tool arguments
        ↓
9. Application authorizes the read
        ↓
10. Execute tool
        ↓
11. Return result to model
        ↓
12. Model requests create_refund(...)
        ↓
13. Application checks refund policy
        ↓
14. Execute side effect or require approval
        ↓
15. Return result to model
        ↓
16. Generate final user response
        ↓
17. Log metrics / evaluation data

Lehet több model call, de a workflow tulajdonosa az application.

Fő komponensek¶

1. Interface layer¶

Példák:

REST API,
chat UI,
CLI,
background job,
webhook.

Ez normál application infrastructure. Transportot, authenticationt, request ID-t, limiteket és response deliveryt kezel.

2. Application / orchestration layer¶

Ez a layer koordinálja a use case-t.

Ilyen kérdésekről dönt:

Which model?
Which prompt version?
Which context?
Which tools?
Which retrieval scope?
How many loop iterations?
What timeout?
What fallback?

Később itt jelenik meg az agentic behaviour.

3. Model gateway¶

Provider-specific callok szétszórása helyett egy model gateway centralizálhatja:

provider/model selection,
request configuration,
retry,
timeout,
usage metrics,
logging,
fallback,
structured output handling.

Példa abstraction:

Application
    ↓
ModelGateway
    ↓
OpenAI / Anthropic / local model / future provider

A cél nem az azonnali over-abstraction, hanem hogy provider mechanics ne váljon domain logicként kezeltté.

4. Prompt / instruction layer¶

A prompt application artifact.

Kezeld code/configuration jelleggel:

versionöld,
review-zd a change-et,
teszteld,
evaluáld a regressziót,
válaszd szét a stable instructiont a runtime datától.

A prompt engineering az architecture része, nem az egész architecture.

5. Context builder¶

A context builder csak az aktuális model callhoz szükséges információt állítja össze.

Lehetséges input:

system instructions
conversation summary
current request
retrieved documents
application state
tool results
memory

Itt válik a context engineering executable application logicként működő komponenssé.

6. Retrieval layer¶

A retrieval külső knowledge elérését biztosítja.

Lehetséges source:

SQL database,
vector database,
search engine,
document store,
repository,
internal API.

Fontos distinction:

retrieval finds candidate information
LLM interprets / synthesizes it

A retrieval nem memory és nem reasoning.

7. Tool layer¶

A tool kontrollált capabilityt expose-ol a modellnek.

Példák:

search_orders
create_ticket
run_tests
read_repository_file
get_weather
calculate_price

A tool layer kezelje:

schema,
validation,
authorization,
execution,
error,
audit.

A modell kéri a capabilityt; application code tulajdonolja.

8. State és memory¶

State az az információ, amely a workflow folytatásához kell.

Példák:

current step
completed tool calls
approval state
conversation summary
pending action

Memory olyan persistált információ, amely későbbi interactiont befolyásol.

Kapcsolódnak, de nem azonosak.

Long-running agent explicit state managementet igényel; különben a fontos state csak implicit módon, egyre növekvő promptban él.

9. Validation és policy¶

Ez a determinisztikus boundary a probabilisztikus behaviour körül.

Példák:

schema validation,
business constraints,
authorization,
tenant isolation,
safety rules,
transaction limits.

Gyakran ez a layer választja el az AI demót a production systemtől.

10. Observability¶

A hagyományos metric továbbra is kell:

latency,
error rate,
throughput,
CPU/memory, ahol releváns.

AI-specific observability hozzáadja:

model,
model version,
prompt version,
token usage,
cost,
tool calls,
retrieval results,
loop iteration count,
evaluation scores.

Ideális esetben egy request trace-elhető az egész AI workflow-n keresztül.

Válaszd szét a domain logicot és AI integrationt¶

Rossz architecture:

Controller
  ↓
500-line prompt
  ↓
LLM
  ↓
parse random text
  ↓
update database

Jobb:

Controller
  ↓
Application Use Case
  ↓
AI Service / Orchestrator
  ├── Model Gateway
  ├── Context Builder
  ├── Retrieval
  └── Tools
  ↓
Validated result / domain command
  ↓
Domain / Infrastructure

Így az AI-specific rész replaceable és testable marad.

LLM output DTO vs domain model¶

A model-facing contractnak nem kell domain modellé válnia.

Példa AI output:

{
  "intent": "refund_request",
  "order_id": "A123",
  "reason": "damaged"
}

Application mapping:

LLM output DTO
      ↓
validation
      ↓
RefundRequestCommand
      ↓
Refund domain service

Ez megakadályozza, hogy az LLM contract átszivárogjon az egész rendszeren.

Retrieval, tool és model knowledge más kérdést válaszol meg¶

Hasznos separation:

Model knowledge:
"Mit tudok általánosságban?"

Retrieval:
"Milyen releváns információ létezik most?"

Tool:
"Milyen actiont vagy authoritative queryt tud az application végrehajtani?"

Példa:

User:

"Where is my package?"

A model training knowledge irreleváns az aktuális package state-hez.

Helyes flow:

LLM understands intent
        ↓
get_shipment_status(order_id)
        ↓
authoritative logistics API
        ↓
LLM explains result

Nem minden AI applicationnek kell agent¶

Sok hasznos rendszer egyetlen kontrollált pipeline:

input
  ↓
retrieval
  ↓
one model call
  ↓
structured output
  ↓
validation

Agentic loopot csak akkor használj, ha a task ténylegesen iteratív decisionöket igényel.

Komplexebb agent:

observe
  ↓
reason / choose action
  ↓
tool
  ↓
observe result
  ↓
repeat until stop condition

Az eddigi foundationök teszik ezt a loopot biztonságossá és reliable-lé.

Workflow vs agent¶

Deterministic workflow esetén az útvonal kódban van:

A → B → C → D

Agent esetén a következő step dinamikus:

state
  ↓
LLM chooses A / B / C
  ↓
new state
  ↓
choose again

Ha a sequence ismert, preferáld a deterministic workflow-t.

Agentic decision-making ott kell, ahol a flexibility valós értéket ad.

Így nem építünk agentet csak azért, mert trendi.

Példa: document analysis application¶

Non-agentic architecture:

Upload PDF
   ↓
Document parser
   ↓
Chunking
   ↓
Embedding/indexing
   ↓
User question
   ↓
Retrieval
   ↓
Context builder
   ↓
LLM
   ↓
Structured answer + citations
   ↓
UI

Az LLM csak egy stage a pipeline-ban.

Példa: coding agent¶

Agentic architecture:

User task
   ↓
Repository context
   ↓
Agent state
   ↓
LLM chooses action
   ├── read file
   ├── search code
   ├── edit file
   └── run tests
   ↓
Tool result
   ↓
state update
   ↓
next decision
   ↓
stop condition
   ↓
final summary

A loop körül továbbra is kell:

permissions,
sandbox,
maximum iterations,
timeout,
test validation,
git boundaries,
logging.

Failure az architecture része¶

Tervezz ezekre:

model timeout,
provider outage,
malformed output,
retrieval returns nothing,
tool failure,
rate limit,
context overflow,
loop exceeds budget,
low-confidence result.

Lehetséges response:

retry
fallback model
fallback deterministic path
ask user for missing information
human escalation
partial response
stop safely

A production AI design jelentős része controlled failure mode-ok tervezése.

Cost és latency architekturális constraint¶

Egy one-model-call design nagyon más, mint egy 20 sequential agent steppes design.

Request latency
≈
retrieval
+ model calls
+ tool calls
+ retries
+ queueing

Request cost
≈
Σ model token cost
+ retrieval/reranking cost
+ tool/infrastructure cost

Ezért model selection, context size, caching és stop condition architecture concern.

Evaluation zárja a loopot¶

Az architecture kezdettől támogassa az evaluationt.

Production request
      ↓
trace
      ↓
input + retrieval + model + tools + output
      ↓
evaluation
      ↓
feedback / regression dataset
      ↓
next version

Evaluation nélkül prompt és model change találgatássá válik.

Gyakorlati reference architecture¶

                    ┌─────────────────────┐
                    │    Client / UI      │
                    └──────────┬──────────┘
                               │
                    ┌──────────▼──────────┐
                    │   Application API   │
                    │ auth / rate limits  │
                    └──────────┬──────────┘
                               │
                    ┌──────────▼──────────┐
                    │ Orchestrator / Use  │
                    │       Case          │
                    └─────┬────┬────┬─────┘
                          │    │    │
              ┌───────────┘    │    └───────────┐
              │                │                │
      ┌───────▼───────┐ ┌─────▼─────┐ ┌────────▼────────┐
      │ Model Gateway │ │ Retrieval │ │ Tool Registry   │
      └───────┬───────┘ └─────┬─────┘ └────────┬────────┘
              │               │                │
              ▼               ▼                ▼
            LLMs        Knowledge Stores    APIs / DB / OS
              │               │                │
              └───────────────┴────────────────┘
                              │
                    ┌─────────▼─────────┐
                    │ Validation/Policy │
                    └─────────┬─────────┘
                              │
                    ┌─────────▼─────────┐
                    │ Domain / Response │
                    └───────────────────┘

Cross-cutting:
- state / memory
- tracing / metrics
- evaluation
- cost controls
- security

Hogyan áll össze a korábbi foundation témákból?¶

01 LLM Mental Model
        ↓
understand the probabilistic component

02 Tokens & Context
03 Inputs & Structured Outputs
04 Prompt Engineering
05 Context Engineering
        ↓
control communication with the model

06 Sampling
07 Model Selection
08 Embeddings
        ↓
choose and supply the right AI capabilities

09 Tool Calling
10 Reliability
        ↓
connect AI decisions to real software safely

11 Evaluation
12 Cost & Latency
        ↓
operate and improve the system

13 Safety & Trust Boundaries
        ↓
protect data and side effects

14 Application Mental Model
        ↓
assemble everything into architecture

Fő design elvek¶

Az LLM komponens, nem maga az application.
Probabilistic decision determinisztikus boundaryn belül maradjon.
Software-consumed model outputhoz structured contractot használj.
Contextet tudatosan építs, ne küldj mindent.
Aktuális/privát knowledge-et retrieve-olj, ne várd, hogy a modell tudja.
Real-world capabilityt narrow tool mögé tegyél.
Authorizationt a modellen kívül enforce-old.
Ismert pathnál deterministic workflow-t preferálj.
Agentic loopot csak akkor használj, ha dynamic decision értéket ad.
Evaluation, observability, cost, latency és failure handling kezdettől architecture concern.

Merre tovább?¶

Ezekkel a foundationökkel a mélyebb témák már nem elszigetelt buzzwordként tanulhatók.

Természetes következő területek:

RAG és retrieval architecture,
MCP,
AI / agent skills,
agentic loops,
agent state és memory,
workflow engines és durable execution,
single-agent és multi-agent architecture,
production evaluation és observability.

A foundation cél akkor teljes, amikor ezeket egyetlen software system részeiként értjük, nem külön AI feature-ökként.