Дългите агентски ходове в рамките на контекстния прозорец

Моделът може да прочете само определено количество наведнъж — своя контекстен прозорец. Агентът на Mythex върши дълга работа: чете много файлове, пуска команди, връчва ограничени задачи на подагенти. Открихме три начина, по които дългата работа се чупеше: подагентите растяха, докато моделът отказваше всяка заявка, подагент спираше рано, защото смяташе, че няма място, а броенето ни на токени беше силно грешно за руски, китайски и японски текст. Ето какво променихме.

Първо някои термини

Токените са парчетата, които моделът чете. Лимитите и цените се броят в тях, а не в символи или думи.
Контекстният прозорец е най-голямото количество, което модел може да прочете в една заявка. Ние също задаваме собствен по-нисък бюджет за всяка заявка, така че разходите и скоростта да останат разумни.
Резултатите от инструментите са това, което агентът получава обратно от инструментите си: съдържанието на файл, който е прочел, изходът от команда, която е пуснал. В дългата работа те са по-голямата част от изпратеното.
Подагент е помощник, който главният агент стартира за самостоятелна задача, например „провери тези глави спрямо бележките“. Той получава една инструкция и след това работи през много извиквания на инструменти сам.

Проблем 1: подагентите растяха, докато моделът ги отхвърли

Всяка стъпка агентът изпраща на модела досегашния разговор. Когато той ставаше твърде голям, нашият код го съкращаваше — но само в началото на потребителско съобщение, така че едно извикване на инструмент и резултатът му никога да не се разделят. Запазваше първото съобщение, добавяше бележка, че по-ранният разговор е съкратен, и пазеше най-новите цели ходове, които се побират.

Подагентът има точно едно потребителско съобщение: инструкцията му. Нямаше къде да се реже. Затова той изпращаше цялата си история при всяка стъпка, растейки всеки път, докато заявката стане по-голяма, отколкото моделът приема изобщо — около един милион токена. В тест с 8 такива подагента всички 8 бяха отхвърлени.

Решението: първо изчистване на старите резултати от инструменти

Заявките вече се побират в бюджета в три стъпки, като всяка се опитва само ако предходната не е стигнала:

Изчистване на най-старите резултати от инструменти. Съдържанието им се заменя с кратка бележка: резултатът е изчистен, за да се запази разговорът в контекста на модела, а агентът може да пусне инструмента отново, ако му трябва. Файл, прочетен преди час, обикновено е най-голямото и най-малко полезно нещо в заявката, а самият файл може да се прочете отново. Най-новите резултати остават цели.
Запазване на цели потребителски ходове. Както преди: първото съобщение, бележка и най-новите цели ходове, които се побират.
Запазване на цели кръгове с инструменти. В рамките на един дълъг ход — единственият вид, който има подагент — се запазва първото съобщение, бележка и най-новите цели кръгове „извикай инструмент, получи резултат“.

Това оформя само това, което се изпраща. Запазената история на агента пази всичко. В същия тест 0 от 8 бяха отхвърлени и всички 8 завършиха.

Изчистване на партиди, за да работи кешът

Доставчиците на модели могат да използват повторно работа от началото на заявка, ако е идентична с последната — префиксен кеш. Ако изчиствахме още един резултат при всяко извикване, началото на заявката щеше да се променя при всяко извикване и кешът никога нямаше да помогне.

Затова най-старите резултати се изчистват по четири, а не по един. Изчистената част остава същата през няколко извиквания. Резултат, който не е много по-голям от бележката, се оставя; изчистването му би спестило почти нищо и пак би променило началото на заявката. Колко остава цяло се определя от размера, а не от броя: най-новите резултати, които се побират в една четвърт от бюджета, остават, като винаги поне един. По-ранна версия пазеше фиксирани шест цели, което беше правилно за кратък изход от команди, но при дълги четения на файлове оставяше по-голямата част от бюджета на старите резултати.

Отказите вече го казват

Заявка, която моделът отхвърля като невалидна, вече не се опитва отново; изпращането на същата заявка пак дава същия отговор. Ако разговорът е твърде дълъг за модела, човекът вижда: „Този разговор стана твърде дълъг, за да го прочете моделът наведнъж. Започнете нов чат за следващата стъпка — всичко, създадено дотук, остава.“ Това е нещо, с което човекът трябва да се справи, а не авария, така че не ни вика.

Проблем 2: агентът спираше, за да „спести място“

Подагент, помолен да прочете 40 дълги глави, спря след 2, казвайки, че иска да спести място. Беше използвал около 100 000 токена от бюджет от 400 000.

Не можеше да знае, че старите резултати вече ще се изчистват за него. Затова му казахме. Инструкциите на агента сега казват, че когато разговорът расте над това, което моделът може да приеме, най-старите резултати от инструменти се изчистват, а най-новите остават цели — така че не спирайте дълга задача, за да спестите място; продължете, а ако ви трябва изчистено, прочетете файла отново.

Поправка, която моделът не може да види, не е поправка от гледна точка на модела. Механизмът помага само ако агентът му се довери.

Проблем 3: броене на токени, сякаш всичко е на английски

Оценявахме токените без да пускаме токенизатор, като символи, разделени на четири. Това е разумно правило за английски. За други писменности не е: руският е около 2,2 символа на токен, а китайският или японският — около един.

Затова подагент, който чете руски глави, изпращаше заявка от около 640 000 токена, докато нашата оценка казваше, че е под бюджета от 400 000. Оценката можеше също толкова лесно да прати заявка над твърдия лимит на модела.

Оценката вече брои по писменост: обикновен ASCII по четири символа на токен, китайски, японски и корейски по един, а всичко останало — кирилица, гръцки, арабски, букви с диакритика, емоджи — по два. Целта е да греши нагоре. За една руска глава сега оценява 43 423 токена при около 44 600 измерени; преди казваше 25 023. Тъй като едно съобщение никога не се променя след като е написано, оценката му се изчислява веднъж и се запомня, вместо при всяка стъпка.

Какво взехме от това

Съкращавайте там, където е размерът. В агентската работа това са резултатите от инструментите, а не потребителските съобщения.
Кажете на агента за собствените му предпазни мрежи. Иначе планира около лимити, които вече не важат.
„Символи ÷ 4“ е предположение за английски. Всичко, което брои токени за многоезични потребители, трябва да брои по писменост или да използва реален токенизатор.
Пазете кеша. Заявка, която се променя в началото при всяко извикване, струва повече и работи по-бавно.

Ако вграждате AI функции в собственото си приложение, нашите ръководства за какво е LLM и как да използвате LLM API обясняват контекстните прозорци и токените от самото начало. Повече за това как работят подагентите в Mythex има в документацията за подагенти.