Як утримати довгі ходи агента в межах контекстного вікна

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

Спочатку кілька термінів

• Токени — це частини тексту, які читає модель. Ліміти й вартість рахуються в них, а не в символах чи словах.
• Контекстне вікно — це максимум, який модель може прочитати в одному запиті. Ми також встановлюємо власний, менший бюджет на кожен запит, щоб витрати й швидкість залишалися розумними.
• Результати інструментів — це те, що агент отримує назад від своїх інструментів: вміст прочитаного файлу, вивід виконаної команди. У довгій роботі саме вони становлять більшу частину того, що надсилається.
• Субагент — це помічник, якого головний агент запускає для самостійного завдання, наприклад «перевір ці розділи за нотатками». Він отримує одну інструкцію, а потім сам працює через багато викликів інструментів.

Проблема 1: субагенти росли, доки модель їх не відхиляла

Кожен крок агент надсилає моделі розмову, що накопичилася. Коли вона ставала занадто великою, наш код обрізав її, але лише на початку повідомлення користувача, щоб виклик інструмента і його результат ніколи не розривалися. Він зберігав перше повідомлення, додавав примітку, що попередня розмова була обрізана, і залишав найновіші цілі ходи, які вміщувалися.

У субагента рівно одне повідомлення користувача: його інструкція. Місця для обрізання не було. Тому він надсилав усю свою історію при кожному кроці, і вона росла, поки запит не ставав більшим за те, що модель взагалі приймає — близько мільйона токенів. У тесті з 8 такими субагентами всі 8 були відхилені.

Виправлення: спочатку очистити старі результати інструментів

Тепер запити вміщуються в бюджет за три кроки, і кожен наступний застосовується лише тоді, коли попередній не допоміг:

1. Очистити найстаріші результати інструментів. Їхній вміст замінюється короткою приміткою: результат очищено, щоб розмова вміщувалася в контекст моделі, і агент може знову запустити інструмент, якщо йому треба. Файл, прочитаний годину тому, зазвичай є найбільшим і найменш корисним у запиті, а сам файл можна прочитати знову. Найновіші результати залишаються повними.
2. Зберегти цілі ходи користувача. Як і раніше: перше повідомлення, примітка і найновіші повні ходи, які вміщуються.
3. Зберегти цілі раунди інструментів. Всередині одного довгого ходу — єдиного виду, який має субагент — зберегти перше повідомлення, примітку і найновіші повні раунди «викликати інструмент, отримати результат».

Це змінює лише те, що надсилається. Збережена історія агента зберігає все. У тому самому тесті 0 з 8 було відхилено, і всі 8 завершилися.

Очищення пакетами, щоб кешування працювало

Провайдери моделей можуть повторно використовувати роботу з початку запиту, якщо він ідентичний попередньому — це префіксний кеш. Якби ми очищали ще один результат при кожному виклику, початок запиту змінювався б щоразу, і кеш ніколи б не допомагав.

Тому найстаріші результати очищаються по чотири, а не по одному. Очищена частина тоді лишається тією самою протягом кількох викликів. Результат, який не набагато більший за примітку, не чіпаємо: очищення заощадило б майже нічого, але все одно змінило б початок запиту. Скільки лишається повним, визначає розмір, а не кількість: найновіші результати, що вміщуються в чверть бюджету, залишаються, і завжди принаймні один. Раніше ми зберігали фіксовані шість повних — це було правильно для короткого виводу команд, але з довгими читаннями файлів більша частина бюджету лишалася старим результатам.

Відмови тепер пояснюються

Запит, який модель відхилила як некоректний, більше не повторюється: надсилання того самого запиту дає ту саму відповідь. Якщо розмова занадто довга для моделі, людина бачить: «Ця розмова стала занадто довгою, щоб модель могла прочитати її за один раз. Почніть новий чат для наступного кроку — усе, що вже створено, залишиться». Це рішення людини, а не збій, тож це не піднімає тривогу в нас.

Проблема 2: агент зупинявся, щоб «заощадити місце»

Субагент, якого попросили прочитати 40 довгих розділів, зупинився після двох, сказавши, що хоче заощадити місце. Він використав близько 100 000 токенів із бюджету 400 000.

Він не мав способу знати, що старі результати тепер будуть очищатися для нього. Тому ми сказали йому про це. Інструкції агента тепер говорять, що коли розмова зростає понад те, що може прийняти модель, найстаріші результати інструментів очищаються, а найновіші залишаються повними — тож не зупиняйте довге завдання, щоб заощадити місце; продовжуйте, а якщо потрібно, прочитайте файл ще раз.

Виправлення, яке модель не бачить, з точки зору моделі не є виправленням. Механізм допомагає лише тоді, коли агент йому довіряє.

Проблема 3: підрахунок токенів так, ніби все англійською

Ми оцінювали токени без запуску токенізатора: символи, поділені на чотири. Це розумне правило для англійської, але не для інших писемностей: російська дає близько 2,2 символа на токен, китайська чи японська — близько одного.

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

Тепер оцінка враховує писемність: звичайний ASCII — по чотири символи на токен, китайська, японська та корейська — по одному, а все інше, зокрема кирилиця, грецька, арабська, літери з діакритикою та емодзі, — по два. Оцінка навмисно завищена. На одному російському розділі тепер вона дає 43 423 токени проти приблизно 44 600, виміряних фактично; раніше було 25 023. Оскільки повідомлення після написання не змінюється, його оцінку обчислюють один раз і запам'ятовують, а не при кожному кроці.

Що ми з цього винесли

• Обрізайте там, де насправді є розмір. У роботі агента це результати інструментів, а не повідомлення користувача.
• Розповідайте агенту про його запобіжники. Інакше він планує роботу навколо обмежень, які вже не діють.
• «Символи ÷ 4» — це припущення про англійську. Усе, що рахує токени для багатомовних користувачів, має рахувати за писемністю або використовувати справжній токенізатор.
• Стежте за кешем. Запит, що змінюється на початку при кожному виклику, коштує дорожче і працює повільніше.

Якщо ви вбудовуєте функції ШІ у власний застосунок, наші гайди що таке LLM і як використовувати API LLM з самого початку пояснюють контекстні вікна та токени. Більше про те, як працюють субагенти в Mythex, — у документації про субагентів.