Мислите за ACE? Можем да го направим с по-малко токени
Дайте на LLM агент реалистична задача от няколко стъпки — да раздели сметка, да намери песен, да съгласува поръчка в девет симулирани приложения — и когато се провали, обикновено причината не е липса на знания. Той неправилно обработва страницирането на API, избира грешния човек или връща стойност, когато такава не е била поискана. Моделът познава API-тата; това, което не е усвоил вътрешно, е как да ги използва надеждно. Това може да се научи от собствената история на агента.
Две скорошни системи правят точно това върху един и същ тип агент: ACE (Agentic Context Engineering) и нашата ALTK-Evolve (представена тук). И двете са форма на агентна памет — превръщат миналите траектории на агента в повторно използваеми уроци и ги подават обратно по време на инференция, без актуализации на теглата и без човешки етикети. Те дори са съгласни по трудната част. Разделят се по въпроса за предоставянето.
Бележка относно термините, тъй като двете системи назовават нещата по различен начин: ще наричаме суровото нещо, което агентът научава, урок. ACE организира уроците си в единен, развиващ се наръчник; ние обединяваме нашите в индивидуално извличаеми насоки. Едни и същи уроци, два контейнера.
С какво сме съгласни
И двете системи отказват да компресират.
ACE назовава точно режимите на отказ: пристрастие към краткостта — оптимизацията се свива до кратки, общи инструкции — и срив на контекста — модел, на който е възложено да пренаписва целия си контекст на всяка стъпка, премахва подробностите чрез обобщаване. Решението му е да поддържа богат, структуриран наръчник с брояч за полезност/вредност към всяка точка и да остави модела да извлича релевантното при прочит.
Ние достигаме до същия извод от обратната посока. Всяка отделна насока поддържа брой поддръжки — колко независими епизода са я породили — и никога не обобщаваме хранилището до шепа правила. Урок, открит от пет различни задачи, е различен обект от урок, появил се веднъж, и двата си струва да бъдат запазени.
И така, по основния въпрос — трябва ли трудно придобитите уроци на агента да се компресират в подредено обобщение? — ACE и ALTK-Evolve дават един и същ отговор: не. Бройте ги, не ги сливайте. Броячите на ACE към всяка точка и нашите броеве на поддръжките са два начина да се изрази една и съща идея.
Къде се различаваме
На две места: как се изгражда паметта и как се предоставя — и именно разликата в предоставянето се вижда в сметката за токени.
Консолидиране (как се изгражда хранилището). ACE разраства един наръчник чрез цикъл Генератор → Рефлектор → Куратор, прилагайки постепенни делта актуализации и премахвайки дубликатите чрез ембединг. Групираме близките дубликати на уроци и ги обединяваме в рамките на дадена група, като съхраняваме поддръжката — когато няколко урока се слеят, оцелелият наследява общия им брой, така че хранилището се свива, без да губи записа за това колко опит подкрепя всяка насока. Извличаме и типизирани насоки — за стратегия, възстановяване и оптимизация — с причинно приписване и произход, проследим до изходната траектория, и на ниво подзадача, така че урок, научен в едно приложение, да може да се прехвърли към друго.
Предоставяне (какво достига до модела при инференция). Това е факторът, който определя числата. ACE инжектира пълния наръчник на всяка стъпка по един и същ начин, независимо от модела или задачата. Ние разглеждаме предоставянето като регулатор, а не като константа: малко фиксирано ядро от насоки с висока подкрепа, разширено за всяка задача с няколко насоки, избрани според конкретната задача (чрез косинусова близост или насочвано от LLM избиране, претеглено по приоритет) — или, когато моделът има достатъчен капацитет, целият консолидиран набор. Едни и същи уроци са достъпни и за двата агента; разликата е, че ACE винаги изпраща всички, а ние изпращаме толкова, колкото даден модел действително може да използва.
Защо това е важно
В AppWorld, с един и същ базов ReAct агент, при вътрешно изпълнение на двете системи:
| Модел | TGC / SGC | Токени/задача | |
|---|---|---|---|
| DeepSeek-V3.2 | ACE | 80.4 / 73.2 | 634K |
| ALTK-Evolve | 89.3 / 80.4 | 263K | |
| gpt-oss-120b | ACE | 54.8 / 35.7 | 777K |
| ALTK-Evolve | 56.0 / 37.5 | 116K |
При силния модел сме по-добри и по двата показателя при ~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 = изпълнение на целта на задачата; SGC = изпълнение на целта на сценария, което изисква всеки вариант на даден сценарий да бъде преминат. Паметта се извлича само от 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 задачи):
| Система | Насоки | TGC | SGC | Токени/задача |
|---|---|---|---|---|
| ReAct, без памет | 0 | 79.8 | 64.3 | 148K |
| ReAct + ACE | 106 | 80.4 | 73.2 | 634K |
| ReAct + ALTK-Evolve | 191 | 89.3 | 80.4 | 263K |
gpt-oss-120b — test_normal:
| Система | Насоки | TGC | SGC | Токени/задача |
|---|---|---|---|---|
| ReAct, без памет | 0 | 39.9 | 21.4 | 110K |
| ReAct + ACE | пълни | 54.8 | 35.7 | 777K |
| ReAct + ALTK-Evolve (избрани) | ~29 | 56.0 | 37.5 | 116K |
gpt-oss-120b — по трудност (TGC):
| Трудност | Базова линия | ACE | ALTK-Evolve |
|---|---|---|---|
| Лесни | 66.7 | 84.2 | 82.5 |
| Средни | 35.4 | 60.4 | 56.2 |
| Трудни | 19.1 | 23.8 | 31.8 |
| Общо | 39.9 | 54.8 | 56.0 |
DeepSeek-V3.2 — по трудност (базова линия → +памет): двете системи започват от различни базови линии без памет (79.8 спрямо 72.0 TGC общо) заради описаната по-горе разлика в шаблона на промпта.
| Ниво | ALTK TGC | ALTK SGC | ACE TGC | ACE SGC |
|---|---|---|---|---|
| Общо | 79.8 → 89.3 | 64.3 → 80.4 | 72.0 → 80.4 | 57.1 → 73.2 |
| Лесни | 93.0 → 94.7 | 84.2 → 84.2 | 78.9 → 84.2 | 63.2 → 78.9 |
| Средни | 81.2 → 97.9 | 62.5 → 93.8 | 85.4 → 100.0 | 75.0 → 100.0 |
| Трудни | 66.7 → 77.8 | 47.6 → 66.7 | 55.6 → 61.9 | 38.1 → 47.6 |
Общност
· Регистрирайте се или влезте, за да коментирате
Преведено автоматично от английски. Оригиналната статия е на връзката по-долу.