Представьте себе сложную корпоративную задачу: агенту нужно разделить счет в ресторане, найти конкретную песню в библиотеке и сверить заказ по девяти различным симулированным приложениям. На первый взгляд, это кажется тривиальным, но для Large Language Model (LLM) это настоящий лабиринт. Когда агент терпит неудачу в таких сценариях, причина редко кроется в отсутствии знаний. Модель знает, как работают API, и понимает логику задач. Проблема заключается в другом: она не усвоила надежные паттерны использования этих инструментов. Она может ошибиться в пагинации, выбрать неверного пользователя или вернуть значение там, где его не запрашивали. Это не ошибка знания, это ошибка применения.
Именно здесь в игру вступает концепция агентной памяти (agentic memory). Идея проста: превратить прошлые траектории работы агента в переиспользуемые уроки и подавать их обратно во время инференса, не обновляя веса модели и не требуя человеческих аннотаций. Два недавних подхода — ACE (Agentic Context Engineering) и новый метод от IBM Research под названием ALTK-Evolve — используют эту парадигму. Они оба учат агента на его собственном опыте, но делают это по-разному. Разница заключается не в том, что они учат, а в том, как они доставляют эти знания модели. И именно этот аспект «доставки» определяет размер вашего счета за токены.
01Общий фундамент: Отказ от сжатия
Прежде чем углубляться в различия, важно понять, в чем эти две системы полностью согласны. И ACE, и ALTK-Evolve отвергают идею сжатия опыта агента в краткие сводки. В индустрии существует тенденция к «сжатию» контекста: собрать все ошибки и решения в один компактный промпт, чтобы сэкономить токены. Оба подхода считают, что это ошибка.
ACE называет проблему предвзятостью краткости (brevity bias) — оптимизация приводит к тому, что инструкции становятся слишком общими и короткими, теряя суть. Также существует риск контекстного коллапса (context collapse): когда модель просят переписать весь контекст на каждом шаге, она может случайно «суммировать» важные детали, удаляя их из памяти. Ответ ACE — поддерживать богатый, детализированный «плейбук» (playbook), где каждый пункт имеет счетчики полезности и вреда, позволяя модели самой определять релевантность при чтении.
ALTK-Evolve приходит к тому же выводу с другой стороны. Каждая отдельная «направляющая» (guideline) сохраняет счетчик поддержки (support count) — количество независимых эпизодов, в которых она была обнаружена. Мы никогда не сводим хранилище к горстке правил. Направляющая, которую обнаружили пять разных задач, — это совершенно другой объект, чем та, что появилась один раз, и обе они заслуживают сохранения. Таким образом, на фундаментальном вопросе «следует ли сжимать уроки агента в аккуратную сводку?» оба ответа звучат как «нет». Считайте их, а не сворачивайте.
02Различия в архитектуре: Консолидация и Доставка
Где же расходятся пути этих двух систем? Есть два основных места: как создается хранилище памяти (консолидация) и как оно подается модели во время работы (доставка). Именно второй аспект — доставка — оказывает наибольшее влияние на стоимость инференса.
Консолидация: Как строится хранилище
ACE формирует один единый плейбук через цикл Generator → Reflector → Curator. Он применяет инкрементальные обновления и устраняет дубликаты с помощью эмбеддингов. Когда уроки похожи, они объединяются в кластеры, и победитель наследует суммарный счет поддержки. Это позволяет хранилищу сжиматься без потери информации о том, сколько опыта стоит за каждым правилом. Кроме того, ACE извлекает типизированные направляющие (стратегии, восстановления, оптимизации) с указанием причинно-следственных связей и происхождения.
ALTK-Evolve также консолидирует уроки, но сохраняет их как индивидуально извлекаемые направляющие. Мы не стремимся к созданию одного монолитного документа. Вместо этого мы создаем набор правил, каждое из которых имеет свою историю и вес. Это позволяет гибче управлять тем, что именно попадает в контекст модели.
Доставка: Что видит модель
Это самый важный момент для понимания разницы в затратах. ACE внедряет полный плейбук на каждом шаге выполнения задачи, независимо от модели или сложности задачи. Это как давать студенту на экзамене всю учебную литературу, даже если он знает, что ответ находится на одной странице.
ALTK-Evolve рассматривает доставку как регулятор, а не константу. Мы используем стратегию, при которой небольшая фиксированная часть высокоподдерживаемых направляющих всегда доступна, а затем, в зависимости от задачи, выбирается несколько дополнительных правил, релевантных текущему контексту (с помощью косинусного сходства или LLM-направляемого отбора). Если модель обладает достаточной «головной вместимостью» (headroom), мы можем отправить полный набор, но для слабых моделей это будет только вредом.
03Результаты на практике: AppWorld Benchmark
Чтобы проверить эффективность этих подходов, IBM Research провела внутренние тесты на бенчмарке AppWorld, используя одного и того же базового агента ReAct. Мы сравнили производительность ACE и ALTK-Evolve на двух разных моделях: DeepSeek-V3.2 (мощная модель) и gpt-oss-120b (менее мощная модель). Результаты оказались впечатляющими и наглядно демонстрируют преимущество подхода ALTK-Evolve.
Давайте разберем цифры. На мощной модели DeepSeek-V3.2:
- ACE: TGC (Task Goal Completion) 80.4%, SGC 73.2%, затраты 634K токенов на задачу.
- ALTK-Evolve: TGC 89.3%, SGC 80.4%, затраты 263K токенов на задачу.
Здесь ALTK-Evolve не только превосходит ACE по точности, но и делает это при затратах, составляющих примерно 40% от затрат ACE. Это значительное улучшение как по качеству, так и по стоимости.
На более слабой модели gpt-oss-120b разница становится еще более драматичной:
- ACE: TGC 54.8%, SGC 35.7%, затраты 777K токенов на задачу.
- ALTK-Evolve: TGC 56.0%, SGC 37.5%, затраты 116K токенов на задачу.
На слабой модели точность практически идентична (разница в 1.2% находится в пределах шума бенчмарка, и в повторных запусках результаты совпали), но стоимость инференса упала до одной седьмой от затрат ACE. Это означает, что вы получаете ту же точность, но платите в 7 раз меньше за вычислительные ресурсы.
04Почему точность не падает? Анализ по сложности задач
Возникает закономерный вопрос: как можно использовать меньше токенов и не потерять в точности? Ответ кроется в анализе по уровню сложности задач (Easy, Medium, Hard). График ниже показывает, как системы справляются с разными типами задач.
На модели gpt-oss-120b (слабая модель) ACE лидирует на легких и средних задачах. Это логично: на простых задачах достаточно общих инструкций, и полный плейбук помогает модели следовать им. Однако на сложных задачах (Hard), где модели нужно выбрать правильный урок среди множества, а не просто следовать общим указаниям, ALTK-Evolve выходит вперед. Калиброванная доставка позволяет модели сфокусироваться на релевантных правилах, не отвлекаясь на шум. Именно сложные задачи решают итоговый результат, и здесь выборочный отбор побеждает.
На модели DeepSeek-V3.2 (мощная модель) картина меняется. Сильная модель способна эффективно усваивать полный плейбук ACE, поэтому на средних задачах ACE немного опережает нас. Однако ALTK-Evolve лидирует на легких, сложных и общих задачах. У мощной модели есть «запас прочности», чтобы использовать больше правил, но даже в этом случае наш подход с калиброванной доставкой оказывается более эффективным или сопоставимым по точности, но значительно дешевле.
05Технические детали и методология
Для тех, кто хочет погрузиться в детали, важно отметить, что тесты проводились на наборе данных AppWorld test_normal, состоящем из 168 задач. Использовался агент ReAct, где каждый шаг записывает код на Python, а среда возвращает результат. Память добывалась только из обучающей и проверочной выборок (train/dev), а результаты представлены как single runs (pass@1), что является стандартом для этого бенчмарка.
Цифры ACE в нашем отчете получены путем наших собственных запусков агента ACE, оцененного в той же среде, на тех же сплитах данных и тех же базовых моделях, что и ALTK-Evolve. Это необходимо, так как оригинальная статья ACE использует другую базовую модель (DeepSeek-V3.1). Контролируя модель и среду, мы обеспечиваем честное сравнение. Обе системы используют одного и того же агента ReAct, и различия заключаются только в шаблоне промпта. Именно поэтому базовые показатели без памяти различаются (79.8% TGC для ALTK-Evolve против 72.0% для ACE), но мы не строим сравнение на этом разрыве. Мы фокусируемся на том, что изменение промпта не может исправить: claim о том, что можно достичь той же или лучшей точности при доли затрат.
06Что это значит на практике
Для разработчиков и компаний, внедряющих LLM-агентов в реальные бизнес-процессы, выводы из этого исследования имеют прямое практическое значение. Во-первых, экономия токенов — это не просто вопрос оптимизации, это вопрос архитектуры памяти. Подход ACE, хотя и эффективен в создании контекста, требует огромных затрат на его доставку. ALTK-Evolve показывает, что интеллектуальная доставка может снизить эти затраты в разы.
Во-вторых, не существует универсального размера контекста. То, что работает для мощной модели (DeepSeek-V3.2), может быть вредным для более слабой (gpt-oss-120b). Системы памяти должны быть адаптивными. ALTK-Evolve предлагает механизм, где доставка памяти регулируется в зависимости от возможностей модели и сложности задачи. Это позволяет масштабировать решения на разные классы моделей без необходимости переписывать логику агента.
В-третьих, сохранение детализации опыта критически важно. Отказ от сжатия уроков в краткие сводки позволяет сохранить нюансы, которые могут быть критичны для сложных сценариев. Счетчики поддержки помогают отфильтровать шум, не удаляя ценный опыт. Это особенно важно в корпоративной среде, где ошибки могут стоить дорого, а контекст задач часто сложен и многогранен.
Если вы работаете с агентами и сталкиваетесь с высокими затратами на инференс, стоит пересмотреть стратегию доставки контекста. Возможно, вам не нужно сжимать память, но нужно научиться доставлять ее более избирательно. Библиотека ALTK-Evolve, включающая пайплайн извлечения, консолидации и отбора, доступна для использования, что позволяет внедрить эти принципы в свои проекты уже сегодня.
В будущем мы планируем исследовать, как именно масштабировать этот подход и как настраивать объем вводимого контекста в зависимости от спектра возможностей моделей. Но уже сейчас ясно: умная доставка памяти — это ключ к созданию экономичных и точных агентов нового поколения.
Источник: Hugging Face ↗