Скільки пам’яті насправді потрібно вашому агенту?
Оснащення агента агентною пам’яттю звучить просто: вилучити уроки з його попередньої роботи, повернути їх у контекст — і більше досвіду має означати кращу продуктивність. Але так працює не завжди. Коли ми розширили оцінювання до восьми моделей — від щільної моделі на 30B параметрів до передових пропрієтарних систем — особливо вирізнився один висновок:
Агентна пам’ять — це не функція, яку можна просто ввімкнути. Це дозування, яке потрібно відкалібрувати під модель.
Коротко
ALTK-Evolve дає агенту змогу вчитися на власних попередніх траєкторіях: дистилювати багаторазово застосовні рекомендації та повертати їх під час інференсу без оновлення ваг і людської анотації.
Правильна доза відрізняється залежно від рівня моделі: сильні моделі із запасом продуктивності потребують повного набору рекомендацій, слабші найкраще працюють із компактним ядром і пошуком рекомендацій для кожного завдання, а насичені моделі не демонструють вимірюваного покращення.
Курований пошук може бути одночасно найточнішим і найдешевшим варіантом: gpt-oss-120b підвищила частку виконаних завдань на +16,1 в. п. лише за +5% токенів, а кешування промптів робить навіть повний набір рекомендацій доступним для використання у виробництві.
Ключовий висновок: дозування залежить від можливостей
Не кожна модель отримує користь від однакового обсягу пам’яті. Серед восьми моделей, що охоплювали весь спектр можливостей, ми побачили три повторювані закономірності:
Сильні моделі із запасом продуктивності потребують повного набору рекомендацій — кожної рекомендації, включно з уроками про рідкісні крайові випадки. Вони мають достатню здатність засвоїти й застосувати все це. DeepSeek-V3.2 (671B MoE) підвищила частку виконаних завдань на 9,5 відсоткового пункту, коли отримала повний набір самостійно добутих рекомендацій.
Менші або слабші моделі губляться у великому наборі рекомендацій. Для них найкраще працює стислий, високонадійний базовий набір плюс кілька релевантних до завдання рекомендацій, отриманих для кожного завдання. gpt-oss-120b (117B MoE) покращила результат на 16,1 в. п. завдяки такому вибірковому підходу, тоді як повний набір дав менше покращення і коштував приблизно на 50% більше токенів.
Вже насичені моделі не демонструють вимірюваного покращення. Ми називаємо це насиченою закономірністю — назва описує те, що ми спостерігали, а не доведену причину. Модель могла вже бути близькою до свого максимуму на цих завданнях, рекомендації могли не стосуватися її невирішених помилок або модель могла неефективно застосовувати настанови. У наших запусках GLM-5 (745B MoE) належала саме до цієї категорії.
Те, що визначає належність моделі до тієї чи іншої закономірності, — не просто кількість параметрів. Запас продуктивності на бенчмарку, розмір контекстного вікна, архітектура, якість рекомендацій і розподіл завдань, схоже, разом визначають результат, а розмежування цих чинників ще триває. Практичний висновок залишається незмінним: правильна доза пам’яті залежить від моделі, і ми можемо її відкалібрувати.
Навчання відбувається навколо моделі, а не всередині неї
«Пам’ять» тут не означає повторне відтворення минулої стенограми. Йдеться про набір рекомендацій — стратегії, які спрацювали, помилки, яких слід уникати, і крайові випадки — дистильовані з попередніх траєкторій самого агента. Цикл простий:
Агент виконує завдання та створює траєкторії.
ALTK-Evolve вилучає поведінкові рекомендації як із вдалих, так і з невдалих запусків.
Він об’єднує ці рекомендації в багаторазово застосовний набір.
Під час інференсу агент отримує або повний набір рекомендацій, або релевантну до завдання його частину.
Ваги моделі не оновлюються. Цикл навчання змінює доступні агенту настанови, а не базову модель — саме тому його недорого впроваджувати й легко переносити між вісьмома протестованими моделями.
Результати для всього спектра
Ми оцінювали моделі на AppWorld — 585 багатокрокових завданнях (168 test_normal + 417 test_challenge) у 9 змодельованих застосунках (календарі, обмін повідомленнями, платежі тощо). Завдання оцінюються двома способами: чи повністю виконує агент кожне завдання (TGC — Task Goal Completion, виконання цілі завдання) і чи проходить кожен варіант сценарію (SGC — Scenario Goal Completion, виконання цілі сценарію, суворіший принцип «усе або нічого»). Повні визначення наведено в додатку.
Три конфігурації, які ми порівнюємо
Оскільки заплутана частина будь-якого дослідження пам’яті — це що саме міститься у контекстному вікні, ми заздалегідь визначаємо конфігурації.
Обидві конфігурації пам’яті використовують той самий набір рекомендацій, видобутий один раз (через описаний вище цикл) лише з навчальної вибірки AppWorld. Між ними змінюється тільки спосіб подачі цього набору — повний набір рекомендацій додається на кожному кроці цілком, тоді як курований пошук подає вибрану підмножину; спосіб створення рекомендацій не змінюється, і дані тестової вибірки ніколи не використовуються для його побудови.
| Конфігурація | Що міститься в контексті агента |
|---|---|
| Базова | Без пам’яті — агент у початковому вигляді. |
| Повний набір рекомендацій | Кожна видобута рекомендація, додана на кожному кроці ReAct. |
| Курований пошук | Фіксоване високонадійне ядро з того самого набору рекомендацій плюс кілька релевантних до завдання рекомендацій, отриманих для кожного завдання (фіксована частина + змінна частина). |
Кількість рекомендацій, які видобуває модель, залежить від її власних можливостей, тому ми подаємо конфігурації за стратегією — «повний набір рекомендацій» проти «курованого пошуку», — а не за абсолютною кількістю, яка не дає змоги порівнювати моделі.
Три закономірності в одному поданні
Репрезентативні моделі з тестування восьми моделей, виміряні за часткою виконаних завдань (TGC) на test_normal:
Рисунок 1. Репрезентативні моделі для трьох спостережуваних закономірностей. Стовпчики показують TGC на AppWorld test_normal для базової конфігурації та найкращої конфігурації з пам’яттю; вісь x починається з 40%, щоб зробити відмінності помітнішими. Сам показник TGC недооцінює більші покращення SGC — див. стовпці SGC у таблиці нижче.
На рисунку показано TGC для зручності читання; таблиця додає суворіший показник SGC, де покращення часто більші:
| Модель | Закономірність | Базова TGC / SGC | Найкраща TGC / SGC із пам’яттю | Найкраща конфігурація | Δ TGC | Δ SGC |
|---|---|---|---|---|---|---|
| gpt-oss-120b (117B MoE) | Слабка / вибіркова | 39.9 / 21.4 | 56.0 / 37.5 | курований пошук | +16.1 | +16.1 |
| DeepSeek-V3.2 (671B MoE) | Сильна із запасом продуктивності | 79.8 / 64.3 | 89.3 / 80.4 | повний набір рекомендацій | +9.5 | +16.1 |
| Claude Opus 4.6 | Сильна із запасом продуктивності | 90.5 / 87.5 | 94.6 / 94.6 | повний набір рекомендацій | +4.1 | +7.1 |
| GPT-5.5 | Сильна (майже на межі) | 92.3 / 82.1 | 95.2 / 89.3 | повний набір рекомендацій | +2.9 | +7.2 |
| GLM-5 (745B MoE) | Насичена | 87.5 / 80.4 | 87.5 / 80.4 | повний набір рекомендацій | 0.0 | 0.0 |
Як видно зі стовпця SGC, суворіший показник зазвичай змінюється сильніше, ніж TGC: SGC DeepSeek зростає на 16,1 в. п. порівняно з покращенням TGC на 9,5 в. п., оскільки якісні рекомендації особливо допомагають агенту пройти кожен варіант сценарію, а не лише середній випадок. І цей ефект не зникає на верхньому рівні діапазону: GPT-5.5 і Opus, обидві близькі до максимуму за TGC, усе ще отримують +7,2 і +7,1 в. п. SGC відповідно. Пам’ять продовжує приносити користь, доки в моделі залишається невирішений тип помилок, на який можна вплинути.
Найдешевша стратегія пам’яті може також бути найкращою
Практичне занепокоєння полягає в тому, що додавання повного набору рекомендацій збільшує обсяг вхідних даних на кожному кроці ReAct, оскільки рекомендації надсилаються повторно під час кожного ходу. Ось що ми спостерігали:
| Модель | Конфігурація | Токенів/завдання (базова) | Токенів/завдання (+ пам’ять) | Накладні витрати |
|---|---|---|---|---|
| DeepSeek-V3.2 | повний набір рекомендацій | 148K | 263K | +78% |
| gpt-oss-120b | повний набір рекомендацій | 110K | 166K | +51% |
| gpt-oss-120b | курований пошук | 110K | 116K | +5% |
Таблиця 1. Середнє використання токенів на завдання, накопичене на всіх кроках агента, порівняно з базовою конфігурацією без пам’яті.
Два висновки:
Курований пошук утримує вартість близькою до базової. Для слабших моделей, де вибірковий підхід перемагає за точністю, він також перемагає за вартістю — найкращий із двох варіантів (+16,1 в. п. TGC лише за +5% токенів для gpt-oss-120b). Краща продуктивність тут не потребує більших витрат на інференс.
Пам’ять не роздуває цикл міркування. DeepSeek виконує приблизно стільки ж кроків ReAct із пам’яттю, скільки й без неї (у середньому ≈18–19), тож додаткові витрати зумовлені збільшенням кількості вхідних токенів, а не довшими траєкторіями.
Справжній важіль ефективності у виробництві — це кешування промптів: статична частина набору рекомендацій ідентична на різних кроках і може кешуватися, суттєво зменшуючи фактичну вартість. Над дизайном промптів із врахуванням кешування — збереженням стабільного спільного префікса набору рекомендацій, щоб він залишався доступним для кешу, — варто попрацювати. Ми також припускаємо, що розмір контекстного вікна відіграє певну роль: моделі з більшими вікнами можуть ефективніше засвоювати повний набір рекомендацій, тоді як моделі з меншим контекстом більше виграють від пошуку, який зберігає компактність доданого вмісту. Ми ще не проводили контрольованих експериментів, що ізолювали б цей чинник.
Пам’ять слід калібрувати, а не просто накопичувати
Урок полягає не в тому, щоб дати агенту все, чого він навчився. Потрібно дати йому такий обсяг досвіду, який він справді здатен використати.
Для слабких моделей це означає компактне ядро плюс кілька специфічних для завдання уроків — що, до речі, також є найдешевшим варіантом.
Для сильних моделей із запасом продуктивності це означає збереження повного набору рекомендацій, доступного для використання у виробництві завдяки кешуванню промптів.
Для насичених моделей це означає не витрачати додатковий контекст, доки їхні невирішені типи помилок не будуть краще зрозумілі.
Покращення реальні для всього спектра — автоматичні, без витоку даних і без потреби в людській анотації, — але лише тоді, коли доза відповідає моделі.
Що далі
Це лише початок, а не фінішна лінія:
Навчений селектор. Наша поточна система пошуку ранжує рекомендації за косинусною подібністю, яка, як ми показали, не ідеально передбачає, які рекомендації допоможуть у конкретному завданні. Селектор, навчений на сигналі результату, є природним наступним кроком.
Пам’ять для дуже слабких моделей. Нижче мінімального базового рівня можливостей самодистиляція не має достатнього сигналу. Пам’ять, дистильована вчителем для дуже слабких моделей, — окрема проблема, яку ми досліджуємо.
За межами AppWorld. Ці результати підтверджено на AppWorld — суворому багатокроковому бенчмарку, але лише одному. Триває робота над ширшим спектром бенчмарків агентів і розгортаннями у реальному світі.
Виокремлення впливу контекстного вікна. Як зазначалося вище, ми хочемо провести контрольовані експерименти, які відокремлять розмір контекстного вікна від загальних можливостей моделі.
Спробуйте бібліотеку ALTK-Evolve — вона містить використаний тут конвеєр вилучення, консолідації та пошуку — або прочитайте повний технічний звіт із докладним описом методу та абляцій.
Додаток: як зрозуміти метрики
Завдання AppWorld оцінюються за двома метриками, обидві подаються у відсотках (що вище, то краще):
TGC — Task Goal Completion. Частка окремих завдань, які агент виконує повністю та правильно. Це основне число у сенсі «чи виконав він завдання».
SGC — Scenario Goal Completion. Суворіша метрика за принципом «усе або нічого». Кожен сценарій об’єднує кілька варіантів одного завдання (той самий запит із різними даними, формулюваннями або крайовими умовами). SGC зараховує сценарій як успішний лише тоді, коли агент успішно виконує кожен варіант. Вона вимірює надійність — агент, який розв’язує завдання здебільшого, але не проходить один із варіантів, отримує бали за TGC, але не за SGC.
Спільнота
· Зареєструйтеся або увійдіть, щоб залишити коментар
Перекладено автоматично з англійської. Оригінал статті — за посиланням нижче.