IBM Research: ALTK-Evolve дозирует память ИИ-агента под модель

Исследователи IBM Research опубликовали в блоге Hugging Face метод ALTK-Evolve, способ дать ИИ-агенту «память» без дообучения весов модели и без разметки человеком. Агент выполняет задачи, ALTK-Evolve извлекает из его успешных и неудачных попыток поведенческие рекомендации, что сработало, каких ошибок избегать, какие граничные случаи учитывать, и объединяет их в единый набор. При выполнении новых задач агенту либо дают этот набор целиком, либо отбирают под конкретную задачу нужную часть (curated retrieval, «отбор по запросу»). Веса модели при этом не меняются: обучается не сама модель, а контекст, который ей подают, поэтому метод дёшев и переносим между разными моделями.

Метод проверили на восьми моделях, от плотной модели на 30 млрд параметров до топовых проприетарных систем, на бенчмарке AppWorld: 585 многошаговых задач (168 test_normal и 417 test_challenge) в 9 симулированных приложениях вроде календарей, мессенджеров и платежей. Качество мерили двумя метриками: TGC (Task Goal Completion, доля полностью и верно выполненных задач) и более строгой SGC (Scenario Goal Completion, сценарий засчитывается, только если агент прошёл абсолютно все его варианты).

Результаты разошлись на три паттерна, и определяет их не число параметров модели, а её уровень возможностей. Сильные модели с запасом выигрывают от полного набора рекомендаций, включая редкие пограничные случаи: DeepSeek-V3.2 (671B, MoE) прибавила +9,5 процентного пункта к TGC на полном наборе своих же рекомендаций. Более слабые модели «тонут» в большом наборе советов, им подходит компактное ядро из самых надёжных правил плюс несколько релевантных задаче рекомендаций, отобранных под неё: gpt-oss-120b (117B, MoE) на таком избирательном подходе прибавила +16,1 процентного пункта TGC, больше, чем дал полный набор, который к тому же обошёлся примерно на 50% дороже по токенам. Третий паттерн, «насыщенные» модели, для которых память вообще не даёт измеримого выигрыша; таким в этих прогонах оказался GLM-5 (745B, MoE). Авторы уточняют: «насыщенность», это ярлык для наблюдения, а не доказанная причина; модель могла уже быть у своего потолка на этих задачах, рекомендации могли не бить по её реальным слабостям, или она могла просто не суметь ими воспользоваться.

По более строгой метрике SGC прирост обычно больше, чем по TGC: у DeepSeek-V3.2 SGC выросла на +16,1 п.п. против +9,5 п.п. по TGC, хорошие рекомендации особенно помогают пройти сценарий целиком, а не только в среднем по задачам. Эффект сохраняется даже у моделей, близких к потолку по TGC: GPT-5.5 и Opus прибавили соответственно +7,2 и +7,1 процентного пункта по SGC.

Отдельно проверили стоимость: избирательный отбор рекомендаций держит расход токенов близким к базовому уровню без памяти, для gpt-oss-120b прирост TGC на +16,1 п.п. обошёлся всего в +5% токенов. Память также не удлиняет цепочку рассуждений: DeepSeek-V3.2 делает примерно одинаковое число шагов ReAct что с памятью, что без неё (≈18, 19 в среднем), так что дополнительная стоимость, это раздувание входного контекста на каждом шаге, а не более долгие траектории. Главный рычаг экономии в продакшне, кеширование промптов: статичная часть набора рекомендаций одинакова на каждом шаге и кешируется, что заметно снижает фактическую стоимость даже для полного набора. Авторы также предполагают, но пока не проверяли отдельным экспериментом, что размер контекстного окна модели тоже играет роль: модели с большим окном могут лучше усваивать полный набор рекомендаций, а модели с меньшим контекстом выигрывают от отбора, который держит добавленный текст компактным.

Метод не претендует на финальную версию. Для очень слабых моделей самодистилляции не хватает сигнала, обучение рекомендациям от модели-учителя для таких случаев авторы называют отдельной задачей, которую только исследуют. Текущий отбор рекомендаций работает по косинусному сходству, а оно не идеально предсказывает, какая рекомендация действительно поможет в конкретной задаче, следующий шаг это обучаемый селектор. Результаты пока проверены только на одном бенчмарке, AppWorld, тестирование на других агентных бенчмарках и в реальных продуктах в процессе. Библиотека ALTK-Evolve с пайплайном извлечения, консолидации и отбора рекомендаций доступна, к посту приложен технический отчёт с полным описанием метода и абляциями.

Ключевые факты

ALTK-Evolve извлекает рекомендации из прошлых успешных и неудачных попыток агента и подаёт их обратно в контекст, без дообучения весов модели и без разметки человеком.
На восьми моделях (от 30B до топовых проприетарных) обнаружили три паттерна дозировки: сильным моделям нужен полный набор рекомендаций, слабым, компактное ядро с точечным отбором под задачу, насыщенным, память не помогает вовсе.
DeepSeek-V3.2 (671B, MoE) прибавила +9,5 п.п. TGC на полном наборе рекомендаций; gpt-oss-120b (117B, MoE) прибавила +16,1 п.п. TGC на избирательном отборе, потратив всего +5% токенов; GLM-5 (745B, MoE), без измеримого выигрыша.
Проверяли на бенчмарке AppWorld, 585 многошаговых задач в 9 симулированных приложениях, по двум метрикам: TGC (доля выполненных задач) и более строгой SGC (сценарий засчитывается, только если пройдены все его варианты).
Даже у моделей у потолка по TGC (GPT-5.5, Opus) память даёт до +7,2 п.п. по строгой метрике SGC; в продакшне полный набор рекомендаций остаётся доступным по цене за счёт кеширования промптов.

Почему это важно

Работа опровергает интуитивное «чем больше памяти у агента, тем лучше»: на восьми моделях IBM Research показала, что польза от накопленного опыта зависит от уровня модели, а не только от объёма рекомендаций. Это меняет саму постановку задачи для агентной памяти, вопрос не «включать или нет», а «сколько и в каком виде подавать под конкретную модель».

Кому это важно

Прежде всего командам, которые строят агентов на нескольких моделях разного уровня, от небольших открытых до топовых проприетарных, и решают, добавлять ли им общую систему памяти или retrieval поверх опыта агента. Полезно и тем, кто уже использует RAG или похожие механизмы для агентов и хочет понять, почему один и тот же объём контекста работает по-разному на разных моделях.

Как это применить

Практический рецепт из статьи: для слабых или небольших моделей, компактное ядро из самых надёжных рекомендаций плюс отбор нескольких релевантных под конкретную задачу (curated retrieval), это одновременно и точнее, и дешевле по токенам. Для сильных моделей с запасом возможностей, подавать полный набор рекомендаций целиком, а стоимость держать под контролем кешированием промптов, поскольку статичная часть набора одинакова на каждом шаге. Для уже насыщенных моделей, не тратить контекст на память, пока не станет понятнее, что именно мешает им дальше расти. Библиотека ALTK-Evolve и технический отчёт с полным методом и абляциями доступны для тех, кто хочет воспроизвести пайплайн.

Можно ли доверять

Публикация от исследовательского подразделения IBM, тестирование прозрачно описано, восемь моделей, конкретный бенчмарк AppWorld, две метрики (TGC и более строгая SGC), приложен технический отчёт с абляциями. Авторы честно отмечают ограничение собственных выводов: «насыщенность» модели у них, это ярлык для наблюдаемого паттерна, а не доказанная причина, и они не разделяли, что именно на неё влияет. Слабое место, результаты проверены только на одном бенчмарке, а точные абсолютные показатели TGC/SGC до и после памяти числом не названы, они есть на графике и в таблице статьи, а в пересказе даны только дельты в процентных пунктах.

Риски и подводные камни

Метод пока валидирован только на одном бенчмарке (AppWorld), и как он поведёт себя на других агентных задачах или в реальных продуктах, по словам самих авторов, ещё предстоит проверить. Отбор рекомендаций при curated retrieval сейчас работает по косинусному сходству, которое не идеально предсказывает, какая рекомендация реально поможет в задаче. Для очень слабых моделей метод, по признанию авторов, пока не работает, самодистилляции не хватает сигнала. И без кеширования промптов подача полного набора рекомендаций на каждом шаге заметно раздувает стоимость по токенам.

«Ярлык «насыщенность» описывает то, что мы наблюдали, а не доказанную причину.»

— исследователи IBM Research, блог ALTK-Evolve