В эпоху, когда каждый второй стартап пытается внедрить автономных AI-агентов, индустрия столкнулась с парадоксом. Логика подсказывает: если мы дадим агенту доступ к его прошлому опыту, к «памяти», он станет умнее, точнее и эффективнее. Идея кажется интуитивно понятной: собери уроки из прошлых сессий, сохрани их и подай обратно в контекст при решении новой задачи. Чем больше опыта — тем лучше результат. Однако, как показывают последние исследования IBM Research, это не всегда так. Память — это не переключатель, который можно просто включить. Это дозировка, которую необходимо тонко настраивать под конкретную модель.
В своей новой статье команда IBM Research, включая таких экспертов, как Ваче Исахагиян и Гаодан Фанг, представляет результаты масштабного сравнения фреймворка ALTK-Evolve с другими подходами. Они протестировали восемь различных моделей — от плотных архитектур на 30 миллиардов параметров до передовых проприетарных систем — и выявили три четких паттерна поведения. Оказалось, что способ доставки «само-дистиллированных» руководств (guidelines) напрямую влияет как на точность, так и на стоимость вычислений. В этой статье мы разберем, как правильно калибровать память агента, чтобы избежать перерасхода токенов и получить максимальную пользу от каждого запуска.
01Ключевой инсайт: Дозировка зависит от мощности модели
Главный вывод исследования заключается в том, что не все модели выигрывают от одинакового объема памяти. Команда IBM выделила три повторяющихся паттерна, которые определяют, как именно агент реагирует на добавление исторических данных. Понимание этих паттернов критически важно для инженеров, стремящихся оптимизировать затраты и производительность.
Сильные модели с запасом возможностей (Strong models with headroom)
Эти модели обладают достаточной вычислительной мощностью и архитектурной емкостью, чтобы усвоить и применить весь объем доступной информации. Для них оптимальным решением является подача полного набора руководств (full guideline set). Это включает в себя не только общие стратегии, но и редкие уроки, извлеченные из краевых случаев (edge cases), с которыми агент сталкивался ранее.
Ярким примером здесь выступает модель DeepSeek-V3.2 (671B MoE). Когда ей был предоставлен полный набор самодобытых руководств, показатель завершения задач (Task Goal Completion, TGC) вырос на +9,5 процентных пункта. Эта модель способна «переварить» большой контекст, не теряя фокуса, и извлекает пользу из каждого дополнительного факта.
Слабые или средние модели (Smaller or weaker models)
Для моделей меньшего размера или с более ограниченной архитектурой большой объем контекста может стать помехой. Избыток информации «затопляет» модель, затрудняя выделение релевантных инструкций. Для таких агентов лучшим подходом является использование компактного ядра высокой уверенности в сочетании с выборочным поиском (retrieval) нескольких релевантных руководств непосредственно для каждой конкретной задачи.
Модель gpt-oss-120b (117B MoE) продемонстрировала впечатляющий рост TGC на +16,1 процентных пункта именно при использовании селективного подхода. При этом подача полного набора руководств дала меньший прирост точности, но увеличила стоимость вычислений примерно на 50%. Это классический пример того, как «больше» данных приводит к «худшему» соотношению цены и качества.
Насыщенные модели (Saturated models)
Третий паттерн, который исследователи называют «насыщенным», описывает модели, которые уже достигли своего потолка возможностей на данных задачах. В таких случаях добавление памяти не дает измеримого улучшения. Это может быть связано с тем, что модель уже близка к максимальному результату, или же потому, что извлеченные руководства не адресуют оставшиеся ошибки модели.
В ходе тестирования модель GLM-5 (745B MoE) попала в эту категорию. Несмотря на огромный размер, она не показала никакого прироста в точности при добавлении памяти. Важно отметить, что принадлежность к одному из этих паттернов определяется не только количеством параметров. На это влияют размер контекстного окна, архитектура, качество самих руководств и распределение задач. Тем не менее, практический вывод остается неизменным: дозировку памяти нужно калибровать под конкретную модель.
02Как работает «память» в ALTK-Evolve: Обучение вне модели
Важно сразу прояснить терминологию. Под «памятью» в контексте ALTK-Evolve не подразумевается простое воспроизведение прошлых транскриптов или логов чата. Речь идет о наборе руководств (guideline set). Это высокоуровневые стратегии, которые сработали, ошибки, которых следует избегать, и особенности краевых случаев. Этот набор извлекается из собственных траекторий агента.
Процесс выглядит следующим образом:
- Агент выполняет задачи и генерирует траектории (последовательности действий).
- Система ALTK-Evolve извлекает поведенческие руководства как из успешных, так и из неудачных запусков.
- Эти руководства консолидируются в переиспользуемый набор.
- Во время инференса агенту предоставляется либо полный набор, либо его релевантная часть.
Ключевое преимущество этого подхода — отсутствие обновления весов модели (no weight updates). Обучение происходит не внутри нейросети, а на уровне доступного ей контекста. Это делает метод дешевым в внедрении и портативным: один и тот же набор руководств можно применять к разным моделям без необходимости их дообучения. Это также означает, что данные тестового набора никогда не используются для создания руководств, что предотвращает утечку данных (data leakage) и обеспечивает честную оценку.
03Результаты на бенчмарке AppWorld
Для оценки эффективности команда IBM использовала бенчмарк AppWorld, который включает 585 многошаговых задач в 168 вариантах test_normal и 417 вариантах test_challenge. Задачи охватывают 9 симулированных приложений: календари, мессенджеры, платежи и другие. Оценка проводилась по двум метрикам:
- TGC (Task Goal Completion): Доля задач, которые агент выполнил полностью и правильно. Это основной показатель «сделал ли он свою работу».
- SGC (Scenario Goal Completion): Более строгая метрика. Каждая сценарная группа включает несколько вариантов одной и той же задачи (с разными данными, формулировками или граничными условиями). Сценарий засчитывается только в том случае, если агент успешно справился со всеми его вариантами. Эта метрика измеряет надежность (reliability) агента.
Исследователи сравнивали три конфигурации:
- Baseline (Базовая): Агент без памяти, в исходном состоянии.
- Full Guideline Set (Полный набор): Все извлеченные руководства внедряются на каждом шаге ReAct.
- Curated Retrieval (Кураторский поиск): Фиксированное ядро высоконадежных руководств плюс несколько релевантных руководств, извлеченных для каждой конкретной задачи.
Анализ результатов: Точность и надежность
Результаты показали, что прирост по метрике SGC часто превышает прирост по TGC. Это логично: хорошие руководства помогают агенту не просто решить задачу в среднем случае, но и справиться со всеми вариациями сценария, включая сложные краевые случаи.
Например, для DeepSeek-V3.2 прирост по TGC составил +9,5pp, а по SGC — целых +16,1pp. Это означает, что память не только помогла агенту решить больше задач, но и сделала его работу значительно более стабильной. Даже для моделей, находящихся на вершине рейтинга, таких как GPT-5.5 и Claude Opus 4.6, память принесла значимый прирост по SGC (+7,2pp и +7,1pp соответственно). Память продолжает окупаться, пока у модели есть нерешенные режимы ошибок.
04Самая дешевая стратегия памяти может быть самой лучшей
Практическая проблема внедрения памяти заключается в стоимости. Внедрение полного набора руководств увеличивает количество входных токенов на каждом шаге ReAct, так как этот контекст отправляется заново на каждом шаге. Давайте посмотрим на данные по использованию токенов:
Model | Config | Tokens/task (baseline) | Tokens/task (+ memory) | Overhead
------------------|---------------------|------------------------|------------------------|---------
DeepSeek-V3.2 | full guideline set | 148K | 263K | +78%
gpt-oss-120b | full guideline set | 110K | 166K | +51%
gpt-oss-120b | curated retrieval | 110K | 116K | +5%Из таблицы видно, что для модели gpt-oss-120b использование стратегии curated retrieval дало прирост точности в +16,1pp при увеличении затрат всего на 5% токенов. Это идеальный сценарий: лучшая производительность без существенного роста стоимости. В то же время, подача полного набора для той же модели увеличила затраты на 51%, что может быть неоправданным для многих приложений.
Интересно, что добавление памяти не увеличивает количество шагов рассуждения (ReAct steps). Модель DeepSeek выполняет примерно одинаковое количество шагов (18-19) как с памятью, так и без нее. Дополнительная стоимость возникает исключительно из-за увеличения объема входных токенов (input-token inflation), а не из-за более долгого рассуждения.
05Реальный рычаг эффективности: Кэширование промптов
В продакшене ключевым инструментом для снижения стоимости является prompt caching (кэширование промптов). Поскольку статическая часть набора руководств остается неизменной на всех шагах, она может быть закэширована. Это существенно снижает эффективную стоимость.
Инженерам стоит задуматься о cache-aware prompt design (дизайне промптов, учитывающем кэширование). Это означает, что общая часть набора руководств должна быть зафиксирована в начале промпта, чтобы она оставалась кэшируемой. Кроме того, исследователи выдвигают гипотезу, что размер контекстного окна также играет роль: модели с большими окнами могут эффективнее усваивать полный набор, в то время как модели с меньшим окном выигрывают от поиска, который держит внедряемый контент компактным. Однако эти факторы требуют дальнейших контролируемых экспериментов.
06Что это значит на практике
Урок, который следует извлечь из этого исследования, заключается не в том, чтобы давать агенту всё, чему он научился, а в том, чтобы давать ему ровно тот объем опыта, который он может реально использовать. Вот практическое руководство для разработчиков:
- Для слабых моделей: Используйте компактное ядро руководств в сочетании с поиском (retrieval). Это не только повысит точность, но и сэкономит деньги. Не пытайтесь «загрузить» в них весь архив знаний.
- Для сильных моделей с запасом: Используйте полный набор руководств. Чтобы контролировать стоимость, обязательно настройте кэширование промптов. Убедитесь, что ваша архитектура поддерживает эффективное кэширование больших статических блоков текста.
- Для насыщенных моделей: Не тратьте контекст впустую. Если модель не показывает прироста, возможно, проблема не в недостатке информации, а в фундаментальных ограничениях модели или некорректности самих руководств. В таком случае лучше потратить ресурсы на улучшение качества самих руководств или на выбор другой модели.
Приросты, полученные с помощью ALTK-Evolve, реальны, автоматизированы и не требуют человеческой аннотации. Но они работают только тогда, когда дозировка памяти соответствует возможностям модели. В следующий раз, когда вы будете проектировать архитектуру AI-агента, задайте себе вопрос: «Сколько памяти на самом деле нужно этой модели?», а не «Какую максимальную память мы можем в нее запихнуть?».
07Что дальше?
Это исследование является лишь началом. Команда IBM Research уже работает над несколькими направлениями улучшения:
- Обучаемый селектор: Текущий поиск ранжирует руководства по косинусному сходству, что не всегда идеально предсказывает полезность для конкретной задачи. Следующий шаг — создание селектора, обученного на сигналах результата.
- Память для очень слабых моделей: Ниже определенного порога возможностей самодистилляция не дает достаточного сигнала. Исследуется использование памяти, дистиллированной учителем (teacher-distilled memory).
- Выход за пределы AppWorld: Результаты подтверждены на строгом бенчмарке, но впереди — тестирование на более широких наборах данных и в реальных развертываниях.
Вы можете попробовать библиотеку ALTK-Evolve, которая включает конвейер извлечения, консолидации и поиска, использованный в этом исследовании, или прочитать полный технический отчет для получения подробностей о методе и абляциях.
Источник: Hugging Face ↗