Думаєте про 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 і ALTK-Evolve дають однакову відповідь: ні. Рахуйте їх, а не стискайте. Лічильники ACE для кожного пункту та наші лічильники підтримки — це два способи сформулювати ту саму ідею.

У чому ми відрізняємося

У двох аспектах: як пам’ять створюється і як вона подається — причому саме відмінність у подачі відображається у витратах на токени.

Консолідація (як створюється сховище). ACE розвиває один посібник через цикл Генератор → Рефлектор → Куратор, застосовуючи інкрементальні дельта-оновлення та усуваючи дублікати за допомогою вбудовувань. Ми групуємо близькі дублікати уроків і об’єднуємо їх у межах кластера, зберігаючи підтримку — коли кілька уроків об’єднуються, отриманий урок успадковує їхній сукупний лічильник, тому сховище зменшується без втрати інформації про обсяг досвіду, що підтверджує кожну настанову. Ми також виділяємо типізовані настанови — стратегію, відновлення й оптимізацію — із причинною атрибуцією та походженням, пов’язаним із вихідною траєкторією, на рівні підзавдань, завдяки чому урок, отриманий в одному застосунку, може переноситися в інший.

Подача (що доходить до моделі під час інференсу). Саме це визначає показники. 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 (виконання цілі сценарію), для якого потрібно пройти кожен варіант сценарію. Пам’ять видобувається лише з train/dev; результати отримано в одному запуску (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 загалом) через описану вище різницю в шаблоні запиту.