Jak udržet dlouhé běhy agenta v kontextovém okně

Model dokáže přečíst jen tolik najednou – své kontextové okno. Agent v Mythexu dělá dlouhou práci: čte mnoho souborů, spouští příkazy a předává ohraničené úkoly subagentům. Zjistili jsme tři způsoby, jak se dlouhá práce rozbíjela: subagenti rostli, dokud model neodmítl každý požadavek; subagent se zastavil předčasně, protože si myslel, že mu dochází místo; a náš počet tokenů byl pro ruštinu, čínštinu a japonštinu hluboko vedle. Tady je, co jsme změnili.

Pár pojmů na úvod

Tokeny jsou kousky, které model čte. Limity a náklady se počítají v nich, ne ve znacích nebo slovech.
Kontextové okno je nejvíc, co model dokáže přečíst v jednom požadavku. My si navíc nastavujeme nižší vlastní rozpočet pro každý požadavek, aby náklady a rychlost zůstaly rozumné.
Výsledky nástrojů jsou to, co agent dostane zpět od svých nástrojů: obsah souboru, který přečetl, výstup příkazu, který spustil. Při dlouhé práci tvoří většinu toho, co se posílá.
Subagent je pomocník, kterého hlavní agent spustí pro samostatný úkol, například „zkontroluj tyto kapitoly proti poznámkám“. Dostane jednu instrukci a pak pracuje sám přes mnoho volání nástrojů.

Problém 1: subagenti rostli, dokud je model neodmítl

Při každém kroku agent pošle modelu dosavadní konverzaci. Když byla moc velká, náš kód ji zkrátil – ale jen na začátku uživatelské zprávy, aby se volání nástroje a jeho výsledek nikdy nerozdělily. Ponechal první zprávu, přidal poznámku, že dřívější konverzace byla zkrácena, a ponechal nejnovější celá kola, která se vešla.

Subagent má přesně jednu uživatelskou zprávu: svou instrukci. Nebylo kde řezat. Takže při každém kroku posílal celou svou historii, která rostla, až byl požadavek větší, než model vůbec přijme – zhruba milion tokenů. V testu s 8 takovými subagenty bylo odmítnuto všech 8.

Oprava: nejdřív vymazat staré výsledky nástrojů

Požadavky se teď vejdou do rozpočtu ve třech krocích; každý se zkusí, jen pokud ten předchozí nestačil:

Vymazat nejstarší výsledky nástrojů. Jejich obsah se nahradí krátkou poznámkou: výsledek byl vymazán, aby konverzace zůstala v kontextu modelu, a agent může nástroj znovu spustit, pokud ho potřebuje. Soubor přečtený před hodinou je obvykle největší a nejméně užitečná věc v požadavku, a soubor je pořád k dispozici k přečtení znovu. Nejnovější výsledky zůstanou celé.
Ponechat celá uživatelská kola. Jako dřív: první zpráva, poznámka a nejnovější kompletní kola, která se vejdou.
Ponechat celá kola nástrojů. Uvnitř jednoho dlouhého běhu – jediného typu, který subagent má – ponechat první zprávu, poznámku a nejnovější kompletní kola „zavolej nástroj, dostaň jeho výsledek“.

Tohle ovlivňuje jen to, co se posílá. Uložená historie agenta si zachová všechno. Ve stejném testu bylo odmítnuto 0 z 8 a všech 8 dokončilo práci.

Mazání po dávkách, aby cache fungovala

Poskytovatelé modelů umí znovu využít práci na začátku požadavku, pokud je identický s tím posledním – cache předpony. Kdybychom při každém volání vymazali o jeden výsledek víc, začátek požadavku by se měnil při každém volání a cache by nikdy nepomohla.

Nejstarší výsledky proto mažeme po čtyřech, ne po jednom. Vymazaná část pak zůstává stejná přes několik volání. Výsledek, který není o moc větší než poznámka, se nechá být: jeho vymazání by ušetřilo téměř nic a stejně by změnilo začátek požadavku. O tom, kolik zůstane celé, rozhoduje velikost, ne počet: nejnovější výsledky, které se vejdou do čtvrtiny rozpočtu, zůstanou, a vždy alespoň jeden. Dřívější verze držela pevných šest celých, což sedělo na krátký výstup příkazů, ale u dlouhých čtení souborů nechávalo většinu rozpočtu starým výsledkům.

Odmítnutí teď říkají, co se stalo

Požadavek, který model odmítne jako neplatný, se už nezkouší znovu; poslání stejného požadavku dostane stejnou odpověď. Pokud je konverzace pro model příliš dlouhá, člověk uvidí: „Tato konverzace je pro model příliš dlouhá, aby ji zpracoval najednou. Pro další krok začni nový chat – všechno, co jsi zatím vytvořil, zůstane.“ To je věc, kterou musí člověk vyřešit sám; není to výpadek, takže to nespouští náš pohotovostní alarm.

Problém 2: agent se zastavil, aby „ušetřil místo“

Subagent, který měl přečíst 40 dlouhých kapitol, se zastavil po 2 a řekl, že chce ušetřit místo. Spotřeboval zhruba 100 000 tokenů z rozpočtu 400 000.

Neměl jak vědět, že mu teď staré výsledky budou automaticky mazány. Tak jsme mu to řekli. Instrukce agenta teď říkají, že když konverzace naroste nad to, co model zvládne, nejstarší výsledky nástrojů se vymažou a nejnovější zůstanou celé – takže dlouhý úkol nezastavuj kvůli úspoře místa; pokračuj a přečti soubor znovu, pokud potřebuješ něco, co bylo vymazáno.

Oprava, kterou model nevidí, není z jeho pohledu opravou. Mechanismus pomůže jen tehdy, když mu agent věří.

Problém 3: počítání tokenů, jako by všechno bylo anglicky

Tokeny jsme odhadovali bez spuštění tokenizéru, jako počet znaků dělený čtyřmi. To je rozumné pravidlo pro angličtinu. Pro jiná písma neplatí: ruština má zhruba 2,2 znaku na token, čínština nebo japonština zhruba jeden.

Subagent, který četl ruské kapitoly, tak poslal požadavek o zhruba 640 000 tokenech, zatímco náš odhad říkal, že je pod rozpočtem 400 000. Odhad by stejně snadno mohl poslat požadavek přes tvrdý limit modelu.

Odhad teď počítá podle písma: čistá ASCII po čtyřech znacích na token, čínština, japonština a korejština po jednom a vše ostatní – azbuka, řečtina, arabština, znaky s diakritikou, emoji – po dvou. Má být spíš nadhodnocený. U jedné ruské kapitoly teď odhaduje 43 423 tokenů proti zhruba 44 600 naměřeným; dřív to bylo 25 023. Protože se zpráva po zapsání nikdy nemění, její odhad se spočítá jednou a uloží se, místo aby se počítal při každém kroku.

Co jsme si z toho odnesli

Zkracuj tam, kde je skutečná velikost. U práce agenta jsou to výsledky nástrojů, ne uživatelské zprávy.
Řekni agentovi o jeho bezpečnostních sítích. Jinak bude plánovat kolem limitů, které už neplatí.
„Znaky ÷ 4“ je předpoklad o angličtině. Cokoli, co počítá tokeny pro vícejazyčné uživatele, musí počítat podle písma, nebo použít skutečný tokenizér.
Pozor na cache. Požadavek, který se na začátku mění při každém volání, stojí víc a běží pomaleji.

Pokud do své aplikace stavíš AI funkce, naše průvodce co je LLM a jak používat LLM API pokrývají kontextová okna a tokeny od základů. Víc o tom, jak fungují subagenti v Mythexu, najdeš v dokumentaci k subagentům.