Думаете об ACE? Мы можем сделать это с меньшим числом токенов

Vatche Isahagian

Vatche

ibm-research

Jayaram Radhakrishnan

jayaramkr

ibm-research

Vinod Muthusamy

vinodmut

ibm-research

Gaodan Fang

gaodan-fang

ibm-research

Punleuk Oum

illeatmyhat

ibm-research

G Thomas

gsthomasx

ibm-research

Ashwath Vaithinathan Aravindan

ashwath-vaithina

ibm-research

Evelyn Duesterwald

evduester

ibm-research

Merve Unuvar

mrvnvr

ibm-research

Если дать агенту на базе LLM реалистичную многошаговую задачу — разделить счёт, найти песню, сопоставить заказ в девяти симулированных приложениях, — то при неудаче обычно дело не в нехватке знаний. Агент неправильно обрабатывает пагинацию API, выбирает не того человека или возвращает значение, хотя его никто не просил. Модель знает API; чего ей не хватает, так это усвоенного надёжного способа их использования. Этому можно научиться на собственной истории агента.

Две недавние системы делают именно это для одного и того же типа агента: ACE (Agentic Context Engineering) и наша ALTK-Evolve (представленная здесь). Обе являются разновидностью агентной памяти — они превращают прошлые траектории агента в пригодные для повторного использования уроки и подают их обратно во время вывода; обновление весов и человеческая разметка не требуются. Они даже сходятся в том, что касается самой сложной части. Различие проявляется в способе доставки.

Небольшое пояснение о терминах: две системы называют эти сущности по-разному, поэтому необработанные знания, которые агент усваивает, мы будем называть уроком. ACE организует уроки в один всеобъемлющий, постоянно развивающийся плейбук; мы объединяем свои уроки в отдельно извлекаемые рекомендации. Уроки те же, контейнеры разные.

В чём мы сходимся

Обе системы отказываются от сжатия.

ACE точно называет причины сбоев: смещение в пользу краткости — когда оптимизация сводится к коротким, обобщённым инструкциям, — и схлопывание контекста — когда модель, которой на каждом шаге предлагают переписать весь контекст, постепенно убирает детали в процессе суммирования. Решение ACE — хранить подробный, структурированный плейбук с индикатором полезности/вреда для каждого пункта и позволять модели определять релевантность во время чтения.

Мы приходим к тому же выводу с другой стороны. Для каждой отдельной рекомендации хранится счётчик подтверждений — количество независимых эпизодов, в которых она возникла, — и мы никогда не сжимаем хранилище до нескольких правил. Урок, обнаруженный в пяти разных задачах, — это не то же самое, что урок, появившийся однажды, и оба заслуживают сохранения.

Поэтому на главный вопрос — следует ли сжимать с трудом добытые уроки агента в аккуратное резюме? — ACE и ALTK-Evolve дают один и тот же ответ: нет. Считайте их, но не схлопывайте. Счётчики для каждого пункта в ACE и наши счётчики подтверждений — два варианта записи одной идеи.

В чём мы различаемся

В двух моментах: как память создаётся и как она доставляется — причём именно разница в доставке отражается на расходе токенов.

Консолидация (как создаётся хранилище). ACE развивает один плейбук посредством цикла Generator → Reflector → Curator, применяя инкрементальные дельта-обновления и устраняя дубликаты по эмбеддингам. Мы объединяем близкие дубликаты уроков в кластеры и сливаем их внутри кластера, сохраняя подтверждения: когда несколько уроков объединяются, итоговый урок наследует их совокупный счётчик, поэтому хранилище уменьшается, но запись о том, какой объём опыта подтверждает каждую рекомендацию, не теряется. Мы также извлекаем типизированные рекомендации — стратегические, восстановительные и оптимизационные — с причинной атрибуцией и указанием происхождения вплоть до исходной траектории, на уровне подзадач, чтобы урок, усвоенный в одном приложении, мог переноситься на другое.

Доставка (что получает модель во время вывода). Именно это определяет цифры. ACE внедряет полный плейбук на каждом шаге, одинаково для любой модели и задачи. Мы рассматриваем доставку как регулятор, а не константу: небольшое фиксированное ядро рекомендаций с высокой степенью подтверждения, расширяемое для каждой задачи несколькими рекомендациями, выбранными с учётом текущей задачи (по косинусному сходству или под руководством LLM, с учётом приоритета), — либо, если модель располагает достаточным контекстным окном, весь консолидированный набор. Обеим системам доступны одни и те же уроки; разница в том, что ACE всегда отправляет их все, а мы отправляем столько, сколько конкретная модель действительно способна использовать.

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

Мы запустили обе системы на AppWorld с одним и тем же базовым агентом ReAct:

На сильной модели мы превосходим оба показателя при примерно 40% стоимости вывода ACE. На слабой модели мы немного опережаем ACE: 56.0 против 54.8 — достаточно близко, чтобы назвать это ничьей по точности (повторный запуск у нас дал 54.8, почти полностью совпав с ACE, что укладывается в разброс результатов между запусками, характерный для этого бенчмарка), — при примерно в семь раз меньшей стоимости.

Справедливости ради отметим: собственная история эффективности ACE связана с тем, чтобы дёшево создавать контекст. Наш подход работает по другой оси — обслуживание этого контекста. Именно извлечение нескольких рекомендаций для каждой задачи вместо внедрения всего плейбука на каждом шаге определяет расход токенов и является прямым следствием описанной выше разницы в доставке.

Откуда берётся точность? Разбивка по сложности показывает две разные картины:

Рисунок 1. Достижение цели задачи после добавления памяти в зависимости от сложности: наш результат и ACE. На DeepSeek-V3.2 (справа) мы выигрываем на простых и сложных задачах, а также в общем результате; ACE лишь немного опережает нас на задачах средней сложности. На gpt-oss-120b (слева) ACE лидирует на простых задачах и задачах средней сложности, но выбор рекомендаций для каждой задачи выигрывает на сложных задачах — и в совокупном результате. Каждая система улучшается относительно собственного базового показателя без памяти (см. справочные таблицы по сложности в разделе «Методические примечания» ниже).

Две модели рассказывают разные истории. На gpt-oss-120b полный плейбук ACE даёт преимущество на простых задачах и задачах средней сложности: значительная часть задачи решается за счёт общего следования инструкциям, поэтому подробный промпт помогает больше, чем отвлекает. Но на сложных задачах, где модели нужно выбрать правильный урок, а не пробираться через все уроки, тщательно подобранное извлечение выходит вперёд — и именно этот уровень определяет совокупный результат. На DeepSeek-V3.2 картина обратная: более сильная модель достаточно хорошо усваивает полный плейбук ACE, чтобы немного опередить нас на задачах средней сложности, однако мы лидируем на простых и сложных задачах, а также в общем результате — при большей доступной ёмкости больше уроков (доставленных нашим способом) продолжают помогать, а не мешают друг другу.

Для каждой модели мы выбираем её лучшую конфигурацию — полный консолидированный набор для сильной модели и выборочное извлечение для более слабой, поскольку большой контекст перегружает слабую модель, а не помогает ей. (Именно вопрос о том, какой объём следует внедрять и как масштабировать его в зависимости от возможностей модели, станет темой следующей публикации.)

Одни уроки, разная доставка

Обе системы отказываются превращать с трудом добытый опыт агента в аккуратное резюме — в этом мы согласны. Разница в том, является ли доставка фиксированной или калибруемой: ACE отправляет весь плейбук на каждом шаге независимо от обстоятельств, а мы отправляем столько рекомендаций из набора, сколько конкретная модель действительно способна использовать. Именно эта калибровка обеспечила приведённые выше результаты — такую же или более высокую точность при значительно меньшей стоимости вывода ACE, — а на более слабой модели она стала различием между рекомендациями, которые помогали, и рекомендациями, которые мешали.

Попробуйте библиотеку ALTK-Evolve — она включает использованный здесь конвейер извлечения, консолидации и поиска, — или прочитайте полный технический отчёт, чтобы ознакомиться с подробным описанием метода и абляционными исследованиями.

Связанные материалы и источники

• Предыдущая публикация: введение в ALTK-Evolve — ссылка
• ACE (Agentic Context Engineering) — ссылка
• Бенчмарк AppWorld — ссылка
• ALTK-Evolve — ссылка
• Полный технический отчёт — ссылка

Методические примечания

AppWorld test_normal, 168 задач. Программный агент ReAct (на каждом шаге он записывает код на Python; среда возвращает результат). TGC = Task Goal Completion, достижение цели задачи; SGC = Scenario Goal Completion, достижение цели сценария, для которого требуется успешное выполнение каждого варианта сценария. Память извлекалась только из обучающей и валидационной выборок; результаты представлены для одного запуска (pass@1), как принято в этом бенчмарке.

Показатели ACE получены нами при собственных запусках агента ACE, оценённых внутри компании на тех же разбиениях AppWorld и тех же базовых моделях, что и ALTK-Evolve (DeepSeek-V3.2 и gpt-oss-120b). В статье об ACE представлены результаты для другой базовой модели (DeepSeek-V3.1), поэтому самостоятельный запуск позволяет контролировать сравнение по модели и программной оболочке. Обе системы используют одного и того же агента ReAct и различаются только шаблоном промпта — именно поэтому два базовых показателя без памяти отличаются (72.0 против 79.8 TGC); мы не основываем сравнение на этом разрыве, а учитываем только утверждения, на которые изменение промпта не может повлиять: такая же или более высокая точность при меньшем количестве токенов.

Справочные таблицы

DeepSeek-V3.2 — test_normal (168 задач):

gpt-oss-120b — test_normal:

gpt-oss-120b — по сложности (TGC):

DeepSeek-V3.2 — по сложности (базовый показатель → +память): две системы начинают с разных базовых показателей без памяти (79.8 против 72.0 TGC в общем результате) из-за описанного выше различия в шаблонах промптов.