05 - Context Engineering¶

A context engineering annak megtervezése, hogy milyen információt lát a modell abban a pillanatban, amikor egy feladatot végrehajt. A prompt engineering arra fókuszál, hogyan írjuk meg az instrukciókat; a context engineering arra, hogyan állítjuk össze köréjük a megfelelő munkakészletet.

Production AI rendszereknél ez gyakran fontosabb, mint a prompt megfogalmazásának finomhangolása.

Miért fontos?¶

Az LLM csak azon tud gondolkodni, ami az aktuális contextben rendelkezésre áll. Ha fontos tény hiányzik, találgathat. Ha túl sok irreleváns információt adunk, a hasznos signal felhígulhat.

Hasznos mentális modell:

Task
  + instructions
  + relevant conversation
  + retrieved knowledge
  + current application state
  + tool results
  + selected memory
  = model context

A cél nem a context méretének maximalizálása, hanem a releváns információ/token arány maximalizálása.

A context working memory, nem storage¶

Gyakori hiba a context window-t adatbázisként kezelni:

Van 200k tokenes context window,
tehát tegyünk bele mindent.

Ez általában rossz architektúra. A tartós információ source of truthban legyen, például adatbázisban, repositoryban, object store-ban vagy knowledge systemben. Az alkalmazás ebből választja ki az aktuális feladathoz szükséges részt.

Ez a repository is ezt a mintát követi:

GitHub repository = tartós source of truth
START_HERE.md      = routing information
status.md          = tömör aktuális állapot
specific topic     = részletes context csak amikor kell

Egy AI Foundations munkát folytató assistantnek nincs szüksége a repository minden fájljára.

A context fő forrásai¶

1. System és application instructions¶

Stabil viselkedési szabályok, például:

milyen szerepet lát el az assistant,
milyen toolokat használhat,
milyen security constraintjei vannak,
milyen output structure kötelező,
milyen szabályok szerint módosíthat adatot.

Ezek általában magas prioritású contextet jelentenek.

2. Aktuális user request¶

Az azonnali feladat maradjon jól látható és könnyen elkülöníthető a háttérinformációtól.

3. Conversation history¶

A conversation history tartalmazhat fontos döntéseket és constraintjeit, de a teljes beszélgetés vak visszajátszása ritkán ideális.

Lehetséges stratégiák:

utolsó N üzenet,
releváns üzenetek szemantikai kiválasztása,
régebbi history összefoglalása,
chat replay helyett persistált project state.

4. Retrieved knowledge¶

A RAG rendszerek dokumentumokat vagy chunkokat keresnek ki az aktuális kérdéshez.

Példa:

User: Hogyan működik a retry policy?
       |
       v
Search internal documentation
       |
       v
Retrieve retry-policy.md
       |
       v
LLM csak a releváns részeket kapja meg

5. Application state¶

A modellnek szüksége lehet olyan aktuális állapotra, amely soha nem volt része a beszélgetésnek:

bejelentkezett user permissionjei,
aktív workflow step,
aktuális shopping cart,
issue status,
project configuration,
előző tool execution eredménye.

6. Tool results¶

A tool output gyakran rövid életű context, amely a következő döntéshez kell.

LLM requests get_order(123)
        |
Application executes tool
        |
Tool result enters context
        |
LLM decides next step

7. Memory¶

A memory legyen szelektív. Hasznos persistált információ lehet preference, project decision vagy hosszú életű state. Ne azt jelentse, hogy minden interakciót örökre tárolunk és újrajátszunk.

Context selection¶

Az alkalmazás tegye fel ezeket a kérdéseket:

Mit kell tudnia a modellnek ehhez a konkrét feladathoz?
Melyik forrás authoritative?
Mi aktuális és mi stale?
Mi hagyható ki?
Mit tilos permission vagy privacy miatt egyáltalán átadni?

Így a context building explicit pipeline lesz, nem szövegek véletlen felhalmozódása.

Példa: coding assistant¶

Rossz megközelítés:

Küldd el az egész repositoryt a modellnek.

Jobb megközelítés:

User task
  |
  +--> repository instructions
  +--> relevant architecture document
  +--> target source files
  +--> direct dependencies
  +--> relevant tests
  +--> recent compiler/test errors

A második olcsóbb és általában tisztább signal-t ad a modellnek.

Context compression¶

Ha a hasznos context túl nagy, tömörítsük, mielőtt továbbadjuk.

Technikák:

summarization,
csak a döntések extractionje,
duplicate text eltávolítása,
csak releváns szekciók megtartása,
verbose tool output strukturált state-té alakítása.

Példa:

20 000 soros CI log helyett:

Failed step: integration-tests
Error: database connection timeout
First failing test: PaymentRepositoryTest
Relevant stack trace: ...

Context pollution¶

Context pollution akkor történik, amikor irreleváns, elavult, ellentmondó vagy alacsony értékű információ versenyez a feladathoz szükséges információval.

Tipikus források:

hosszú, nem kapcsolódó chat history,
duplikált retrieved chunkok,
stale project decisionök,
verbose tool response-ok,
unrelated repository fájlok.

A több context tehát ronthatja is az eredményt.

Context ordering és prioritás¶

Még akkor is számít a struktúra, ha minden belefér. A fontos szabályok és task definitionök legyenek könnyen azonosíthatók.

Gyakori koncepcionális sorrend:

Stable instructions
Current task
Relevant state
Retrieved evidence
Tool results
Output requirements

A pontos API-reprezentáció providerfüggő, az architekturális elv nem.

Context engineering vs prompt engineering¶

A prompt engineering kérdése:

Hogyan specifikáljam a feladatot?

A context engineering kérdése:

Milyen információ legyen elérhető a feladat végrehajtásakor?

Például jobb prompt sem pótolja a hiányzó aktuális product price adatot. Ha a modellnek mai ár kell, az alkalmazásnak ki kell keresnie és contextbe kell helyeznie.

Security boundary¶

A context selection authorization probléma is.

Ha egy user olvashatja a Project A-t, de a Project B-t nem, a retrievalnek ezt még azelőtt enforce-olnia kell, hogy a dokumentumok a modellhez jutnának.

User request
   |
Authorization filter
   |
Permitted retrieval
   |
LLM context

Ne a prompttól várjuk, hogy a modell ne adjon ki olyan információt, amelyet eleve nem lett volna szabad megkapnia.

Developer takeaway¶

A context constructiont kezeld application logicként explicit inputokkal, rankinggel, filteringgel, authorizationnel, token budgetekkel és observabilityvel.

Egy erős AI application nem csak ezt kérdezi:

Milyen promptot küldjünk?

Hanem ezt is:

Mi az a legkisebb, legjobb minőségű információkészlet, amelyből a modell helyesen meg tudja oldani ezt a feladatot?