Context rot není problém velikosti context window

Začátkem letoška jsme stavěli agenta pro klienta, který zpracovává dokumenty. Něco, co nabere stoh smluv, vytáhne závazky, porovná je s databází pravidel a napíše shrnutí. V demu jelo krásně. Krásně to šlapalo i u prvních dvanácti dokumentů. Pak, někde kolem čtyřicátého dokumentu, na běhu, který trval něco přes půl hodiny, začal agent sebejistě přisuzovat klauzule špatné smlouvě, odkazoval na pravidlo, které o tři kroky dřív sám označil za zastaralé, a obecně se choval jako schopný junior, který sedí v meetingu už moc dlouho a kýve hlavou, aniž by poslouchal. Context window nebylo ani zdaleka plné. Pohybovali jsme se možná na čtyřiceti procentech dostupných tokenů na modelu s oknem dvě stě tisíc tokenů. Žádné ořezávání, žádné vyhazování, nic se neztratilo. A agent přesto potichu ztratil nit. Pokud jste někdy shipovali agenta na dlouhé úlohy, tohle znáte. Tichou degradaci, která se neprojeví jako chyba, ale jako pomalé hromadění malých špatných odboček, které se sčítají, až je výstup nenápadně a draze k ničemu. Nejotravnější je, že se to samo neohlásí. Žádná výjimka, žádný rate limit, žádná červená řádka v logu. Agent prostě postupem času hloupne způsobem, který koreluje spíš s délkou běhu a počtem kroků než s tím, kolik okna jste spotřebovali.

Instinkt, a je to instinkt silný, protože působí intuitivně, říká, že modelu došlo místo a začal zapomínat, takže řešením musí být větší okno. Skočíte ze 128k na 200k, nebo sáhnete po některé z variant na milion tokenů, a problém zmizí. Jenže nezmizí. Analýza nasazení podnikových agentů z roku 2025 přisoudila zhruba šedesát pět procent selhání driftu kontextu během vícekrokového uvažování, ne vyčerpání tokenů, což sedí s tím, co jsme viděli v produkci: selhání přicházejí, i když máte spoustu místa navíc. Existuje zřetelný a dobře zdokumentovaný jev, kdy se výkon modelu zhoršuje s tím, jak roste množství kontextu, i když se technicky všechno vejde. Pozornost totiž není zadarmo a není rovnoměrná. Schopnost modelu vytáhnout a správně zvážit konkrétní fakt pohřbený uprostřed obřího kontextu je mnohem horší než jeho schopnost naložit se stejným faktem v krátkém promptu. Říká se tomu context rot. Signál, na kterém vám reálně záleží, se rozředí nahromaděným šumem každého mezikroku uvažování, každého výstupu z nástroje, každého retry, každého kousku konverzačního lešení, které agent cestou vygeneroval. Větší okno to zhorší, ne zlepší, protože jste modelu dali víc místa k zaplnění bezcennými tokeny, které utopí ty tři nebo čtyři fakty, na kterých pro aktuální rozhodnutí opravdu záleží. Optimalizujete špatnou proměnnou a dodavatelé, kteří vám prodávají velikost okna, nemají důvod vás vyvádět z omylu.

Co mě přesvědčilo, že jde o problém disciplíny a ne o problém modelu, bylo sledovat, jak se degradace shlukuje kolem zhruba stejného časového horizontu u úplně různých agentů na úplně různých modelech. Někde kolem 35. minuty, plus minus, se koherence začíná rozpadat, a platí to, ať je okno 128k nebo milion. Důvod je ten, že dlouhoběžící agent nehromadí jen tokeny, hromadí rozhodnutí, a každé rozhodnutí padlo v kontextu těch předchozích. Takže jakákoli malá chyba na začátku se zapeče do stopy uvažování a každý další krok ji bere jako svatou pravdu. Tohle je propagace chyb a je korelovaná s časem, protože čas je jen náhrada za počet kroků. Agent, který běží 35 minut, obvykle udělal dost kroků na to, aby jeho vlastní minulý výstup teď dominoval kontextu, a minulý výstup zahrnuje i jeho chyby, jeho napůl zformulované hypotézy, jeho volání nástrojů, která vrátila nesmysl, nad kterým pak uvažoval, jako by byl skutečný. Model začne věřit vlastnímu přepisu. Jakmile je ten přepis znečištěný, každý nový krok znečištění zdědí, a protože agent nemá žádný mechanismus, jak rozlišit sebejistě vyřčený mezitip od ověřeného faktu, rot se šíří. Zvednutí stropu okna s tím nic neudělá. Můžete agentovi dát nekonečno tokenů a on si stejně otráví vlastní studnu.

Disciplína, která tohle spraví, je context engineering. Znamená to brát kontext, který modelu v každém kroku dáváte, jako záměrně kurátorovaný artefakt, ne jako neustále rostoucí log, do kterého se jen přidává. V produkci nesou většinu váhy tři techniky. První je pinování cíle, kdy držíte původní záměr a aktuální dílčí cíl v pevném slotu s vysokou prioritou na začátku každého promptu, znovu vkládaný čerstvě v každém kroku, takže model je vždycky jen pár set tokenů od toho, aby si pamatoval, co má vlastně dělat. Bez toho cíl odplave na konec rostoucího přepisu a zůstane hladový po pozornosti. Druhá je hierarchická sumarizace, kdy místo tahání kompletní surové historie periodicky komprimujete dokončené fáze do stručných, strukturovaných shrnutí, takže z bloku dvaceti volání nástrojů, který vyřešil dílčí úlohu, uděláte pětiřádkovou poznámku „tohle jsme zjistili a tady je aktuální stav". Zahodíte lešení uvažování a necháte si závěry. Třetí je odkládání paměti, kdy fakta, která musí přetrvat, jdou do externího úložiště, tabulka v Postgresu, hash v Redisu, soubor jako scratchpad, cokoli sedí, a agent si je vytahuje na vyžádání, místo aby se snažil držet všechno v okně. Přesně takhle byste navrhli systém pro lidského analytika, který si neudrží sto faktů v pracovní paměti, a funguje to ze stejného důvodu. Když jsme toho dokumentového agenta přestavěli kolem těchhle myšlenek, pinovali jsme cíl, sumarizovali každý dokument do strukturovaného záznamu a odkládali vytažené závazky do Postgresu, aby model vždycky viděl jen tu hrstku relevantní pro aktuální porovnání, zeď ve 35. minutě zmizela. Běhy, které se dřív rozpadly u čtyřiceti dokumentů, držely koherenci přes dvě stě.

Pokud máte agenta, který ztrácí koherenci na dlouhých úlohách, přestaňte sahat po větším modelu a začněte měřit kontext. Logujte přesný prompt poslaný v každém kroku, pak si přečtěte ty kolem bodu, kde kvalita padá, a vsadím se, že najdete původní cíl pohřbený pod deseti tisíci tokeny nahromaděného tlachání nástrojů a modelova vlastního přemítání. To je vaše diagnóza. Přidejte pinovaný blok s cílem a vkládejte ho znovu v každém kroku, samo o sobě vám to koupí překvapivě hodně. Pak se podívejte, co vaše historie doopravdy obsahuje, a buďte nemilosrdní v tom, jak komprimujete cokoli, co představuje dokončenou práci, do strukturovaného shrnutí. Surové uvažování, které vás tam dostalo, má totiž po dosažení závěru zápornou hodnotu, jen ředí pozornost. Přesuňte trvalá fakta z okna do úložiště, na které se agent dotazuje, a navrhněte vytahování tak, aby stáhlo pár věcí relevantních pro aktuální krok, ne aby všechno naházelo zpátky. Nic z toho není exotika. Je to nudná inženýrská disciplína aplikovaná na místo, které většina týmů považuje za magii. Ve steezru téhle práce děláme docela dost, stavíme dokumentové pipeliny a AI automatizaci pro klienty, kteří nejdřív zkusili naivní přístup a dívali se, jak degraduje, a vzorec je pořád stejný: selhání se chybně diagnostikuje jako limit modelu, i když jde o problém se správou kontextu, na který tým nikdy nestavěl. Větší okna jsou pohodlí, ne lék. Týmy, které shipují spolehlivé agenty na dlouhé úlohy, jsou ty, které se rozhodly, že kontext je jejich věc a budou ho inženýrovat.