Context Architecture¶

A context architecture annak megtervezése, hogy milyen információ jut el a modellhez, milyen formában, milyen forrásból, milyen trust levellel és milyen budget mellett.

A context window nem adatbázis, memory system vagy source of truth. Egyetlen model decisionhöz összeállított ideiglenes working set.

Hasznos mental model:

Canonical Sources
  ├── run state
  ├── user/task input
  ├── policies
  ├── skill definition
  ├── retrieved evidence
  ├── tool observations
  └── memory
        ↓
Context Builder
  ├── select
  ├── normalize
  ├── rank
  ├── compact
  ├── label trust/provenance
  └── fit budget
        ↓
Model Context

A context builder ezért inkább compilerhez hasonlít, mint string concatenation helperhez.

Context mint projection, nem canonical state¶

A runtime state sokkal több információt tartalmazhat annál, mint amire a modelnek szüksége van.

Canonical Run State
        ↓ projection
Current Model Context

A projection tartalmazhat:

current goal,
releváns success conditionöket,
current plan fragmentet,
friss authoritative observationöket,
available capabilityket,
selected business rule-okat,
retrieved evidence-t,
unresolved questionöket.

Nem kell automatikusan minden historical message, tool result és artifact.

Context layer-ek¶

Hasznos fogalmi stack:

1. platform/system constraints
2. application policy/instructions
3. active skill instructions
4. task and goal
5. canonical state projection
6. observations and evidence
7. relevant memory
8. user interaction/history needed now

A konkrét API-reprezentáció providerfüggő, de az architecture tudja, melyik layer mit tulajdonol.

Stable instructions vs runtime data¶

Válaszd szét a stabil behavior és változó task data rétegeket.

Stable:

application role,
hard interaction rules,
skill contract,
output schema guidance,
domain terminology.

Dynamic:

current customer/order,
latest tool result,
current plan,
retrieved documents,
remaining budget,
current failure.

Context ownership¶

A context assembly rule-okat dedikált ContextBuilder vagy hasonló komponens tulajdonolja.

class ContextBuilder(Protocol):
    def build(self, run: AgentRun, purpose: ContextPurpose) -> ModelContext: ...

A purpose fontos, mert planning, tool selection, verification és summarization más projectiont igényelhet.

PLANNING context
  goal + constraints + coarse state

ACTION_SELECTION context
  current state + fresh observations + capabilities

VERIFICATION context
  claimed result + evidence + success conditions

Egy universal giant context template tipikusan zajos és drága lesz.

Context mint budgeted resource¶

A nagyobb context nem automatikusan jobb.

Költségei:

több input token,
nagyobb latency,
több distractor,
nagyobb chance conflicting instructionre,
nehezebb provenance tracking,
stale information tovább marad látható.

Gondolkodj budgetben:

context_budget
├── instructions
├── task/state
├── evidence
├── tool schemas
└── reserve for output

A buildernek legyen prioritás- és truncation policyje még azelőtt, hogy a provider context overflow-t dobna.

Relevance fontosabb, mint chronology¶

Chat applicationök gyakran chronological historyt adnak tovább. Agent runtime-ban inkább relevance-oriented state projection kell.

Gyenge:

last 100 messages

Jobb:

current goal
current plan step
fresh relevant observations
required constraints
selected evidence
important unresolved facts

Observation normalization¶

Raw tool outputot általában normalizálj model context előtt.

Raw:

{
  "status": 200,
  "headers": {},
  "internal_metadata": {},
  "payload": {}
}

Model-facing:

{
  "source": "order_service",
  "observed_at": "...",
  "order_id": "123",
  "payment_status": "PAID",
  "shipment_status": "NOT_SHIPPED"
}

A raw artifact külön megmaradhat audit/debug célra.

Előny:

kevesebb transport noise,
kisebb token use,
stabilabb contract,
jobb security filtering.

Fact vs hypothesis¶

A context tegye megkülönböztethetővé:

FACT
  authoritative observation

INFERENCE
  interpretation derived from facts

HYPOTHESIS
  unverified assumption used for planning

Ha ezek összemosódnak, a model a saját korábbi guessét később factként kezelheti.

Példa:

{
  "claim": "customer may be eligible for refund",
  "kind": "hypothesis",
  "evidence_refs": ["obs-41", "policy-7"]
}

Provenance¶

Evidence hordozzon source metadata-t:

source_id
source_type
retrieved_at / observed_at
tenant / access scope
trust classification
content version
citation/artifact reference

A provenance támogatja:

groundingot,
auditot,
freshness checket,
tenant isolationt,
verificationt,
canonical source újralekérését.

Freshness¶

Egyes factek gyorsan elavulnak:

repository HEAD      changes often
order status         may change
flight status        changes
policy document      versioned, slower
static product spec  relatively stable

A runtime source/capability szinten definiáljon freshness policyt.

cached observation
      ↓
older than threshold?
      ↓ yes
re-observe canonical source

Ne a model judgementre bízd azt, amit kód biztosan enforce-olhat.

Trusted vs untrusted context¶

Nem minden token azonos trust levelű.

HIGHER TRUST
  system/application policy
  signed/internal configuration
  authoritative structured service data

VARIABLE TRUST
  internal documents
  retrieved knowledge
  external webpages
  emails/messages
  user-uploaded files

Retrieved content tartalmazhat instruction-szerű szöveget, de ez data, nem authority a runtime fölött.

Data trust vs instruction authority¶

Egy source megbízható lehet adatként, miközben nincs joga instructiont adni.

Például egy repository README lehet authoritative documentation, de nem adhat automatikusan új production permissiont az agentnek.

Hasznos külön dimenzióként kezelni:

content_trust = internal_repository
instruction_authority = none

Retrieval mint context acquisition¶

A RAG egy context acquisition mechanizmus:

question / state
   ↓
retrieval query
   ↓
search
   ↓
rerank/filter
   ↓
evidence
   ↓
context builder

A top-k result nem automatikusan helyes vagy releváns.

Filter lehet:

tenant authorization,
document version,
freshness,
source type,
relevance score,
duplication,
trust classification.

Tool result mint context acquisition¶

Másik source az operational tool:

Retrieval
  stored knowledge/evidence

Tool observation
  current operational state or action result

Például „invoice 42 paid?” kérdéshez a current billing service erősebb, mint egy embedded document snapshot.

Memory mint opcionális context source¶

Persistent memoryt se dumpolj teljes egészében:

Memory Store
   ↓ relevant memory retrieval
Context Builder

Memory recordhoz provenance, timestamp és megfelelő scope kell.

Remembered preference és current account state más kategória.

Summarization és compaction¶

Ha nő a context, lower-value historyt lehet summarizálni, miközben canonical records külön megmaradnak.

Rossz:

summarize everything
replace original state

Jobb:

canonical state/artifacts remain stored
         ↓
context-specific summary generated
         ↓
used only as projection

A summary lossy representation, ne váljon source of truth-vá.

Mit érdemes újralekérni summarization helyett?¶

Re-fetch, ha az adat:

operational/current,
olcsón query-zhető,
safety-critical,
authorization-sensitive,
likely to change.

Példák:

current bank balance,
order state,
repository branch HEAD,
user permissions.

Summarization jó lehet:

hosszú discussion history,
completed plan segmentek,
nagy evidence set, ha raw artifact elérhető,
previous reasoning outcome, ha nem authoritative external fact.

Context versioning és reproducibility¶

Debughoz rögzíts elegendő metadata-t:

context_template_version
skill_version
policy_version
state_version
observation_ids
retrieval_result_ids
model configuration

Nem biztos, hogy privacy miatt minden rendered promptot örökre tárolhatsz, de legyen reprodukciós strategy.

Context caching¶

Caching csökkentheti a costot és latencyt stabil prefix vagy repeated retrieval esetén, de figyelni kell:

tenant isolation,
authorization changes,
source version,
expiry/freshness,
privacy.

Példa: code review agent¶

Egy step contextje:

SYSTEM
  review policy + security constraints

SKILL
  PR review instructions + finding schema

TASK
  review PR #123 for correctness issues

STATE
  files reviewed: 8/11
  open findings: 2

OBSERVATIONS
  current diff for file X
  failing test Y

TOOLS
  read_file
  fetch_diff
  run_tests

BUDGET
  6 tool calls remaining

Nincs szükség minden repository file-ra, minden previous response-ra és minden CI logra minden stepben.

Context anti-patternök¶

Dump everything: több token = több intelligence feltételezés.
Chat history mint state.
Unlabelled evidence source/time/trust metadata nélkül.
Stale operational data irreversible actionhöz.
Summary válik canonical truth-vá.
Retrieved document felülírhatja a policy instructiont.
Egyetlen context template planninghez, actinghez és verificationhöz.

Praktikus context-building pipeline¶

1. Load canonical run state
2. Determine context purpose
3. Select required instructions/policy
4. Select relevant state projection
5. Refresh stale critical observations
6. Retrieve optional evidence/memory
7. Apply authorization/trust filters
8. Normalize and deduplicate
9. Rank by relevance/priority
10. Compact to token budget
11. Attach provenance metadata
12. Invoke model

Takeaways¶

Context temporary projection, nem canonical state.
Context construction architecture subsystem, nem string concatenation.
Planning, action selection és verification külön projectiont igényelhet.
Relevance és freshness fontosabb a chronological replaynél.
Fact, inference és hypothesis legyen külön.
Provenance és trust classification maradjon meg.
Retrieved/external instruction-szerű text defaultként data, nem control authority.
Current authoritative state-et kritikus esetben újra kell kérni.
Raw/canonical artifact maradjon summaryn kívül, így context compact lehet truth elvesztése nélkül.