Ako udržať dlhé kroky agenta v kontextovom okne

Model dokáže naraz prečítať len toľko – je to jeho kontextové okno. Agent v Mythexe robí dlhú prácu: číta veľa súborov, spúšťa príkazy a odovzdáva ohraničené úlohy subagentom. Zistili sme tri spôsoby, akými sa dlhá práca pokazila: subagenti rástli, až model odmietol každú požiadavku; subagent sa zastavil predčasne, lebo si myslel, že mu došlo miesto; a náš počet tokenov bol veľmi nesprávny pre text v ruštine, čínštine a japončine. Tu je, čo sme zmenili.

Najprv niekoľko pojmov

• Tokeny sú kúsky, ktoré model číta. Limity a náklady sa počítajú v nich, nie v znakoch ani slovách.
• Kontextové okno je najviac, čo model dokáže prečítať v jednej požiadavke. My si navyše nastavujeme nižší vlastný rozpočet pre každú požiadavku, aby náklady a rýchlosť zostali rozumné.
• Výsledky nástrojov sú to, čo agent dostane späť z nástrojov: obsah súboru, ktorý prečítal, alebo výstup príkazu, ktorý spustil. Pri dlhej práci tvoria väčšinu toho, čo sa posiela.
• Subagent je pomocník, ktorého hlavný agent spustí pre samostatne ohraničenú úlohu, napríklad „skontroluj tieto kapitoly oproti poznámkam“. Dostane jednu inštrukciu a potom pracuje cez mnoho volaní nástrojov sám.

Problém 1: subagenti rástli, až ich model odmietol

Agent pri každom kroku posiela modelu doterajšiu konverzáciu. Keď bola príliš veľká, náš kód ju orezal – ale len na začiatku správy používateľa, takže volanie nástroja a jeho výsledok sa nikdy nerozdelili. Ponechala sa prvá správa, pridala sa poznámka, že predchádzajúca konverzácia bola orezaná, a ponechali sa najnovšie celé kroky, ktoré sa zmestili.

Subagent má presne jednu správu používateľa: svoju inštrukciu. Nebolo kde rezať. Preto pri každom kroku posielal celú svoju históriu, ktorá rástla, až bola požiadavka väčšia, než model vôbec prijme – približne milión tokenov. V teste s 8 takými subagentmi odmietol model všetkých 8.

Oprava: najprv vymazať staré výsledky nástrojov

Požiadavky sa teraz zmestia do rozpočtu v troch krokoch, pričom každý sa použije, len ak predchádzajúci nestačil:

1. Vymazať najstaršie výsledky nástrojov. Ich obsah sa nahradí krátkou poznámkou: výsledok bol vymazaný, aby konverzácia zostala v kontexte modelu, a agent môže nástroj spustiť znova, ak ho potrebuje. Súbor prečítaný pred hodinou je zvyčajne najväčšia a najmenej užitočná vec v požiadavke a súbor je stále k dispozícii na opätovné čítanie. Najnovšie výsledky zostávajú celé.
2. Ponechať celé kroky používateľa. Ako predtým: prvá správa, poznámka a najnovšie celé kroky, ktoré sa zmestia.
3. Ponechať celé kolá nástrojov. V rámci jedného dlhého kroku – a len taký krok má subagent – ponechať prvú správu, poznámku a najnovšie celé kolá „zavolaj nástroj, dostaň výsledok“.

Toto mení len to, čo sa posiela. Uložená história agenta obsahuje všetko. V tom istom teste odmietol model 0 z 8 a všetkých 8 dokončilo prácu.

Mazanie po dávkach, aby cache fungovala

Poskytovatelia modelov dokážu znovu použiť prácu na začiatku požiadavky, ak je identická s predchádzajúcou – ide o cache prefixu. Keby sme pri každom volaní vymazali o jeden výsledok viac, začiatok požiadavky by sa menil pri každom volaní a cache by nikdy nepomohla.

Preto sa najstaršie výsledky mažú po štyroch, nie po jednom. Vymazaná časť potom zostáva rovnaká počas niekoľkých volaní. Výsledok, ktorý nie je o veľa väčší ako poznámka, sa nechá tak: vymazaním by sa ušetrilo takmer nič a začiatok požiadavky by sa aj tak zmenil. To, koľko zostáva celé, určuje veľkosť, nie počet: najnovšie výsledky, ktoré sa zmestia do štvrtiny rozpočtu, zostávajú a vždy aspoň jeden. Skoršia verzia nechávala pevných šesť celých, čo bolo správne pre krátky výstup príkazov, no pri dlhých čítaniach súborov ponechalo väčšinu rozpočtu starým výsledkom.

Odmietnutia teraz hovoria pravdu

Požiadavka, ktorú model odmietne ako neplatnú, sa už neopakuje; poslanie tej istej požiadavky dostane rovnakú odpoveď. Ak je konverzácia pre model príliš dlhá, používateľ uvidí: „Táto konverzácia bola na to, aby ju model prečítal naraz, príliš dlhá. Začnite nový chat pre ďalší krok – všetko, čo ste doteraz vytvorili, zostáva.“ Je to vec používateľa, ktorú môže vyriešiť, nie výpadok, takže nezavolá našu pohotovosť.

Problém 2: agent sa zastavil, aby „ušetril miesto“

Subagent, ktorého sme požiadali prečítať 40 dlhých kapitol, sa zastavil po 2 a povedal, že chce ušetriť miesto. Mal spotrebovaných približne 100 000 tokenov z rozpočtu 400 000.

Nemal spôsob, ako vedieť, že staré výsledky mu teraz budú vymazávané. Preto sme mu to povedali. Inštrukcie agenta teraz hovoria, že keď konverzácia presiahne to, čo model zvládne, najstaršie výsledky nástrojov sa vymažú a najnovšie zostanú celé – takže dlhú úlohu nezastavujte, aby ste ušetrili miesto; pokračujte a ak potrebujete vymazaný súbor, prečítajte ho znova.

Oprava, ktorú model nevidí, nie je z pohľadu modelu opravou. Mechanizmus pomôže len vtedy, ak mu agent dôveruje.

Problém 3: počítanie tokenov, akoby všetko bolo po anglicky

Tokeny sme odhadovali bez spustenia tokenizéra, ako znaky delené štyrmi. Je to rozumné pravidlo pre angličtinu. Pre iné písma to neplatí: ruština má zhruba 2,2 znaku na token, čínština alebo japončina zhruba jeden.

Subagent, ktorý čítal ruské kapitoly, teda poslal požiadavku s približne 640 000 tokenmi, kým náš odhad hovoril, že je pod rozpočtom 400 000. Odhad by rovnako dobre mohol posunúť požiadavku za tvrdý limit modelu.

Odhad teraz počíta podľa písma: čistý ASCII so štyrmi znakmi na token, čínštinu, japončinu a kórejčinu s jedným a všetko ostatné – azbuku, grécku abecedu, arabčinu, písmená s diakritikou, emoji – s dvoma. Má tendenciu nadhodnocovať. Pri jednej ruskej kapitole odhaduje 43 423 tokenov oproti približne 44 600 nameraným; predtým hovoril 25 023. Keďže sa správa po napísaní nikdy nemení, jej odhad sa vypočíta raz a uloží, namiesto toho, aby sa počítal pri každom kroku.

Čo sme si z toho odniesli

• Orezávajte tam, kde je skutočná veľkosť. Pri práci agenta sú to výsledky nástrojov, nie správy používateľa.
• Povedzte agentovi o jeho vlastných bezpečnostných sieťach. Inak plánuje okolo limitov, ktoré už neplatia.
• „Znaky ÷ 4“ je predpoklad platný pre angličtinu. Všetko, čo počíta tokeny pre používateľov v rôznych jazykoch, musí počítať podľa písma, alebo použiť skutočný tokenizér.
• Dávajte pozor na cache. Požiadavka, ktorá sa pri každom volaní mení na začiatku, stojí viac a beží pomalšie.

Ak stavate funkcie s AI do vlastnej aplikácie, naši sprievodcovia čo je LLM a ako používať LLM API od začiatku vysvetľujú kontextové okná a tokeny. Viac o tom, ako subagenti fungujú v Mythexe, nájdete v dokumentácii k subagentom.