Andrew Stellman egy Radar-szerkesztője, Mike Loukides kérdésére reagálva vizsgálja a LLM-eknél tapasztalható jelenséget, amelyben a modell úgy tűnik, hogy figyelmen kívül hagyja a hosszú kontextus közepén lévő információkat. Stellman rámutat, hogy bár a kontextus törlése és újratöltése csak ideiglenes megoldás lehet, maga a hiba mélyebb és strukturálisabb: a kutatás ma már U‑alakú teljesítménygörbének (U‑shape) nevezi.
Mit mutat a kutatás?
Nelson Liu (Stanford) kísérleteiben hosszú dokumentumoknál a releváns válasz elhelyezésének pozícióját variálta, és azt találta, hogy a modellek legjobban a kontextus elején vagy a legfrissebb végén teljesítenek, míg a középső pozíciókban jelentősen romlik a teljesítmény. Ezt a mező primacy bias-nak (első elemek felé húzó hatás) és recency bias-nak (legutóbbi elemek felé húzó hatás) nevezi; amikor ezeket együtt ábrázolják, U‑alakot kapnak.
További elméleti magyarázatokat ad egy 2025‑ös ICML‑cikk ("On the Emergence of Position Bias in Transformers"), amely szerint a jelenség a transzformerek belső erői közötti egyensúlyból fakad: a causális maszk felerősíti az elején lévő tokenek hatását, míg a pozíciókódolások (például RoPE) a generálás helyéhez közelebb eső tokeneket súlyozzák. Borun Chowdhury (Meta) 2026‑os munkája („Lost in the Middle at Birth: An Exact Theory of Transformer Position Bias”) azt állítja, hogy a U‑alak már a modell inicializációjakor jelen van, véletlenszerű súlyok mellett is.
Ezért a nagyobb kontextusablakok — bár javítják az egyszerű, egyetlen tény kinyerésére épülő feladatokat — nem oltják ki automatikusan a középen elvesztés problémáját: egy kétmillió tokenes ablak egyszerűen egy sokkal nagyobb „középet” hoz létre, amibe az információ kieshet.
Öt gyakorlatias technika a U‑alak kezelésére
Stellman öt, a saját Quality Playbook fejlesztése során használt módszert mutat be, amelyek mind a feltételezett működő memória megbízhatatlanságán alapulnak: külső tárolás, kontextus kurátorlása, és determinisztikus ellenőrzések.
1) Kurátorkodás, ne felhalmozás
Ne hagyd, hogy egyetlen hosszú munkamenet felhalmozódjon és reménykedj, hogy a modell továbbra is koherens marad. Írj egy külön, önálló "context brief" dokumentumot, majd indíts új munkamenetet azzal a rövidebb, céltudatos kontextussal. Stellman például a Quality Playbook v1.5.2 készítésekor így ismét indította a végső javításokat: a brief tartalmazta a fájlútvonalakat, sorhivatkozásokat, pontos diffeket és teszteket, így a friss munkamenet olvasva azt megbízhatóbb eredményt adott.
2) Helyezd a kritikus információt az élekre
Mivel a modell jobban figyel az ablak elejére és végére, tedd oda a legfontosabb szabályokat vagy adatokat, és hagyd a kevésbé kritikus anyagokat a közepére. Claude Code esetén például a --append-system-prompt opcióval a brief kiválasztott részeit a rendszerpromptba lehet tenni, ami végig erősebben befoghatóvá teszi azokat.
3) Rövid munkamenetek hosszú helyett
Tervezd a munkát úgy, hogy sok rövid, újraindítható munkamenet olvassa a lemezen lévő állapotot, ahelyett, hogy egyetlen, hosszú, felhalmozott kontextusban próbálkoznál. Stellman példája a Haiku 4.5 alapú chatindexáló rendszere: először a modell próbálta a deduplikációs és állapotadatokat a fejében tartani, ami kudarcot vallott; a megoldás az volt, hogy minden lépés után állapotfájlokat (például progress.json) írattak, és új munkamenetek olvasták ezeket be.
4) Ismételd meg a kulcsinfót közvetlenül használat előtt
Ha a modellnek most kell alkalmaznia egy szabályt vagy adatot, idézd fel rögtön a cselekvés előtt, és kényszerítsd fájlból történő friss olvasásra. A Quality Playbooknál a BUGS.md‑ből való adatok beemelésekor Stellman egy parancsot adott: "Before writing BUG‑NNN.md, re‑read the BUG‑NNN entry in BUGS.md... Do not paraphrase from memory." Ez a „ne emlékezetből fogalmazz” kitétel biztosította, hogy a modell ténylegesen újraolvassa a forrást a művelet pillanatában.
5) Teszteld a közepet — determinisztikusan ellenőrizd
Nem elég feltételezni, hogy a modell használja a középen lévő információt: ellenőrizd le. Például minden új munkamenet elején hasonlítsd össze az agent által jelzett állapotot (cursor, progress.json) a lemezen lévő valós sorral; ha eltérés van, a modell jelezze és álljon meg, ne folytassa hibás állapottal. Stellman checkpoint jelentései pontosan ezt a mintát követték: amikor a diszk és a progress.json megegyeztek, folytatás következett; ha nem, a különbséget fel kellett tárni.
Az elv: a munka memória megbízhatatlan — építs kívülre
A Quality Playbook fázisos architektúrája először a kontextus kompaktálódása (compaction) elleni védekezésként született, de kiderült, hogy ugyanaz az architektúra a középen elveszett hibát is csökkenti: minden fázis rövid, célzott kontextussal dolgozik, a brief az elején és a friss állapot a végén, így nincs sok „közép”, ahová az információ kieshet.
A szerző hangsúlyozza: a kontextusablakok nőni fognak, és a kompaktálás egyre „okosabb” lehet, de az alapvető korlátok részben strukturálisak. Ha egy ügynök munkája fontos információtól függ, azaz a működő memória nem megbízható, az információnak tartósabb helyen kell élnie — lemezen vagy explicit artefaktumban —, és a munkafolyamatnak úgy kell felépülnie, hogy rövid, ellenőrizhető lépésekre bontsa a folyamatot.
Következtetés
A U‑alakú kontextusprobléma nem csupán egy múló furcsaság: sok kutatás szerint a transzformerek architektúrájának következménye. A gyakorlatban alkalmazható módszerek — kontextus kurálása, fontos információk élre helyezése, rövid munkamenetek, kulcsinformációk újraolvastatása és determinisztikus ellenőrzések — csökkentik a hibák előfordulását, és növelik az ügynökök megbízhatóságát hosszú, többlépcsős feladatoknál. Stellman tapasztalata alapján ezek a technikák ma használhatók és valós, azaz reprodukálható előnyökkel járnak a fejlesztésben.
