IBM porovnal pamäť agentov s ACE: selektívne pokyny znížili objem kontextu

Pamäť nie je iba archív

Výskumníci z IBM predstavili ALTK-Evolve ako systém, ktorý premieňa úspešné aj neúspešné behy AI agenta na opakovane použiteľné pokyny. Nejde o ďalšie trénovanie základného modelu ani o ručné označovanie príkladov. Systém analyzuje trajektórie agenta, identifikuje postupy spojené s výsledkom a ukladá ich ako samostatné usmernenia. Pri novej úlohe potom môže načítať pevné jadro najlepšie podložených pravidiel a doplniť ho o pokyny vybrané podľa podobnosti s aktuálnym zadaním. Dôležitou časťou návrhu je teda nielen vytváranie pamäte, ale aj rozhodovanie, čo z nej model skutočne uvidí.

Takáto pamäť má riešiť praktické chyby, ktoré sa objavujú pri práci s nástrojmi. Agent môže poznať dostupné API, no nesprávne stránkovať výsledky, zameniť používateľa, prehliadnuť podmienku alebo zmeniť údaje, ktorých sa úloha netýkala. AppWorld, na ktorom IBM systém hodnotilo, je určený práve na podobné interaktívne úlohy. Pôvodná práca o benchmarku opisuje prostredie deviatich simulovaných aplikácií, 457 API a 750 úloh s automatickou kontrolou výsledného stavu vrátane neželaných vedľajších zmien. Nejde preto iba o test odpovedania na otázky, ale o kontrolované vykonávanie viacstupňových operácií.

ALTK-Evolve a ACE sa rozchádzajú pri doručení pokynov

IBM porovnáva svoj prístup s ACE, teda Agentic Context Engineering. ACE spravuje skúsenosti ako rozvíjajúci sa playbook a používa cyklus generovania, reflexie a kurátorstva. Jeho autori upozorňujú na „brevity bias“, pri ktorom optimalizácia vytvára čoraz kratšie a všeobecnejšie rady, aj na „context collapse“, keď opakované prepisovanie postupne odstráni užitočné detaily. Namiesto jedného stručného súhrnu preto ACE zachováva štruktúrované položky a priebežne ich dopĺňa či upravuje. Práca bola prijatá na ICLR 2026, ale konkrétne porovnávacie čísla v článku IBM nepochádzajú od autorov ACE.

ALTK-Evolve vychádza z podobného odmietnutia agresívnej kompresie, no usmernenia uchováva jednotlivo. Každé môže niesť informáciu o pôvode a počet nezávislých epizód, ktoré ho podporujú. Pri zlučovaní podobných položiek sa má zachovať súčet tejto podpory, takže často potvrdené pravidlo zostáva odlíšiteľné od jednorazového pozorovania. Pokyny môžu byť označené ako strategické, obnovovacie alebo optimalizačné a previazané s trajektóriou, z ktorej vznikli. Takáto granularita uľahčuje kontrolu konfliktov, odstránenie zastaraného pravidla aj skúmanie toho, prečo agent dostal konkrétnu radu.

Hlavný rozdiel je v množstve pamäte posielanej modelu. Podľa opisu IBM ACE vkladá rozsiahly playbook do kontextu pri každom kroku, zatiaľ čo ALTK-Evolve umožňuje voliť medzi celým konsolidovaným súborom a selektívnym výberom. Ten môže používať vektorovú podobnosť alebo hodnotenie jazykovým modelom a zohľadniť prioritu či počet podporných epizód. Nie je to však univerzálne pravidlo, že menej pokynov je vždy lepšie. IBM pri výkonnejšom modeli použilo celý konsolidovaný súbor, kým selektívne načítanie nasadilo pri slabšom modeli, ktorý podľa autorov veľké množstvo inštrukcií využíval horšie.

Čo ukázalo interné porovnanie

Na 168 úlohách rozdelenia AppWorld test_normal použilo IBM pri oboch pamäťových systémoch agenta typu ReAct, ktorý v jednotlivých krokoch píše kód v Pythone. Pri modeli DeepSeek-V3.2 dosiahol ALTK-Evolve podľa zverejnenej tabuľky 89,3 % v metrike Task Goal Completion a 80,4 % v prísnejšej Scenario Goal Completion. ACE dosiahlo 80,4 % a 73,2 %. Priemerný objem bol 263-tisíc tokenov na úlohu pri ALTK-Evolve a 634-tisíc pri ACE, teda približne 42 % porovnávanej hodnoty. Ide o počet spracovaných tokenov, nie o univerzálne vyčíslenie finančnej ceny, ktorá závisí od modelu a spôsobu prevádzky.

Pri modeli gpt-oss-120b boli výsledky bližšie: ALTK-Evolve dosiahlo 56,0 % TGC a 37,5 % SGC, kým ACE 54,8 % a 35,7 %. IBM samo interpretuje rozdiel v úspešnosti skôr ako remízu, pretože ďalší beh ALTK-Evolve skončil na 54,8 % TGC. Rozdiel v tokenoch zostal veľký: 116-tisíc oproti 777-tisícom na úlohu. Selektívna konfigurácia pritom načítavala približne 29 pokynov. Podrobnejší rozpis naznačuje, že ACE bolo s týmto modelom lepšie pri ľahkých a stredných úlohách, zatiaľ čo ALTK-Evolve viedlo v ťažkej skupine.

Tieto čísla nemožno čítať ako nezávislé potvrdenie prevahy jedného rámca. Experiment aj implementáciu ACE vykonal tím IBM stojaci za ALTK-Evolve a zverejnené výsledky sú jednotlivé behy typu pass@1. Navyše sa líšili šablóny promptov: pri DeepSeek-V3.2 mal agent bez pamäte v konfigurácii ALTK TGC 79,8 %, ale v konfigurácii ACE 72,0 %. IBM preto porovnanie neopiera o rozdiel medzi týmito základnými líniami, no odlišný štart zároveň komplikuje čisté pripísanie výsledku samotnej pamäti. Potrebné sú verejné konfigurácie, viac opakovaní a replikácia tímom, ktorý nevyvíja ani jeden systém.

Dôsledky pre európske nasadenia

Pre firmy je podstatné, že dlhodobá pamäť agenta vytvára tri samostatné náklady: uloženie skúsenosti, vyhľadanie relevantnej položky a opakované spracovanie textu modelom. Veľký playbook môže zvýšiť latenciu a spotrebu tokenov, zabrať kontextové okno a prekryť pokyny dôležité pre aktuálnu úlohu. Príliš úzky retrieval môže, naopak, vynechať kritické pravidlo. Produkčný systém preto potrebuje merať nielen úspešnosť úloh, ale aj presnosť výberu pamäte, počet vložených tokenov, vedľajšie zmeny, čas odozvy a náklady na jednotlivé typy úloh.

V slovenskom a európskom prostredí je dôležitý aj pôvod uložených skúseností. Trajektória podnikového agenta môže obsahovať osobné údaje, obchodné informácie alebo výstupy zo systémov s rozdielnymi lehotami uchovávania. Organizácia musí samostatne posúdiť pravidlá ochrany údajov, prístupové oprávnenia a uplatniteľné povinnosti podľa aktu o umelej inteligencii. Evidencia zdroja, podpory a verzie každého pokynu môže pomôcť pri audite a riadení zmien, sama osebe však nezaručuje súlad. Užitočná pamäť by mala mať vlastníka, čas platnosti a mechanizmus na odstránenie údajov aj chybných poučení.

Otvoreným problémom zostáva zastarávanie. Pravidlo odvodené zo starej verzie API môže po aktualizácii zvyšovať chybovosť a opakovane potvrdená skúsenosť nemusí platiť v inom právnom, jazykovom alebo používateľskom kontexte. Retrieval riadený ďalším jazykovým modelom navyše pridáva vlastnú cenu a možnosť nesprávneho výberu. ALTK-Evolve preto zatiaľ najpresvedčivejšie ukazuje architektonickú hypotézu: pri agentoch nestačí skúsenosti iba hromadiť, treba riadiť ich pôvod, platnosť a dávkovanie. Či sa deklarované úspory zachovajú aj mimo AppWorldu, pri reálnych dátach a dlhodobej prevádzke, musí potvrdiť nezávislé hodnotenie.