Engram: čtyři nastavení řídí paměť AI agenta

Paměť, která funguje, ale ne vždy tak, jak chcete

Služba Engram od Weaviate má agentům dávat dlouhodobou paměť. Weaviate o ní tvrdí, že po úvodním nastavení funguje i s výchozími hodnotami. Podle autora praktického průvodce ale mezi stavem „funguje to“ a „funguje to tak, jak jsem to myslel“ zbývají čtyři rozhodnutí, která Engram za uživatele neudělá. První je, co si pamatovat, a to určují popisy témat. Druhé je, kolik vzpomínek a čí, což řeší omezená témata a rozsah. Třetí je, co se při hledání vrací, a to nastavuje režim vyhledávání. Čtvrté se týká toho, kam se vzpomínky vloží do promptu. Autor všechna čtyři ukazuje na reálných výstupech z projektu, který běží na téměř výchozí šabloně pro personalizaci. Tento text se věnuje třem rozhodnutím, která průvodce rozebírá nejpodrobněji: popisům témat, omezeným tématům a umístění vzpomínek v promptu. K režimu vyhledávání nemáme dost podkladů, takže ho pouze jmenujeme.

Popis tématu je ve skutečnosti prompt

Zásadní zjištění zní: popis tématu není popisek pro lidi, ale přímo extrakční prompt. Určuje tedy, co se z konverzace vytáhne a uloží jako vzpomínka. Autor to předvedl na jediné zprávě, v níž se uživatel představí jako vývojářský evangelista ve Weaviate, který všechna demo v Pythonu píše podle tvrdého pravidla, že mají méně než 100 řádků. Zpráva prošla třemi tématy a vrátilo se pět vzpomínek. Jedna patřila do UserProfile (jméno uživatele), tři do UserKnowledge a jedna do ConversationSummary. V UserKnowledge se věta rozpadla na tři samostatné fakty: povolání, jazyk dem a pravidlo o 100 řádcích. Každý z nich lze vyhledat zvlášť. ConversationSummary naopak uložilo stejnou informaci vcelku, jako souvislé vyprávění. Vstup, zpracování i okamžik byly shodné. Podle autora rozdíl způsobily jen odlišné popisy témat, nikoli nějaká vlastní logika směrování. Prakticky to znamená, že tvar paměti, tedy jednotlivé atomické fakty, nebo shrnutí, si volíte formulací popisu.

Pravidlo, co vynechat, vyhrává nad seznamem, co zahrnout

Popis ovlivňuje nejen tvar, ale i to, co se do paměti vůbec nedostane. Autor popisuje UserKnowledge jako univerzální téma šablony, kam patří cokoli osobního o uživateli, co se může časem změnit. Právě taková široká kategorie snadno nasbírá šum. Autor proto vytvořil nové téma UserFacts, které UserKnowledge nahradilo, a jeho popis zakončil pravidlem, že se nemají zaznamenávat události, incidenty ani pomíjivé okolnosti. Podle něj tahle jediná věta rozhodla, protože dává modelu obecné kritérium, co ignorovat, a model ho nemusí odvozovat z příkladů. Výsledek zněl takto: ve 24 bězích se do vzpomínek vytvořených tématem UserFacts nedostal žádný z rušivých incidentů a trvalá rozhodnutí se zachytila ve všech. Autor z toho vyvozuje zásadu, že u úzce zaměřeného tématu odvede víc práce pravidlo o vynechání než výčet toho, co zahrnout. Jde o výsledek jednoho autorova testu, ne o garantované chování pro každé téma.

Kolik vzpomínek a čí: omezená témata

Druhé nastavení se týká počtu vzpomínek. Omezené (bounded) téma drží nejvýše jednu vzpomínku na každý jedinečný rozsah. Mechanismus je jednoduchý: Engram odvozuje ID vzpomínky z názvu tématu a rozsahu, takže každý další zápis dopadne na stejné ID a stávající vzpomínku aktualizuje, místo aby přidal novou. U neomezeného tématu takové sjednocení nenastává, a počet vzpomínek proto závisí na tom, jak model extrahuje fakty. Příznak „bounded“ patří mezi konfigurační pole, která se na rozdíl od popisu netýkají formulací a mají vlastní účinky. Formulář pro nové téma v konzoli Engramu nabízí název, popis, uživatelský rozsah, rozsahy vlastností a právě tento příznak. Témata lze v konzoli kdykoli upravit, přidat nebo odebrat či přeformulovat, aniž by se musel vytvářet nový projekt. Díky tomu se dá nastavení postupně ladit, dokud se paměť nechová podle očekávání.

Test pěti čerstvých uživatelů

Rozdíl mezi omezeným a neomezeným tématem autor ověřil pěti běhy. Pokaždé poslal úvodní zprávu a pak zprávu s opravou, tedy odvoláním dřívějšího tvrzení. Dělal to čerstvým uživatelům s prázdným úložištěm a spočítal, kolik vzpomínek vzniklo. Neomezené téma UserKnowledge jich skončilo v rozmezí dvou až čtyř (2, 4, 4, 3 a 3): někdy se odvolání uložilo jako jedna vzpomínka, jindy jako dvě. Omezené téma UserProfile drželo ve všech pěti bězích přesně jednu. Autorův závěr je jednoznačný. Pokud váš kód potřebuje načíst jedinou stálou vzpomínku k tématu, téma vždy omezte a nespoléhejte na to, že počet vzpomínek vyjde sám. Vzorek je malý, ale rozdíl mezi „vždy jedna“ a „dvě až čtyři“ je zřetelný a odpovídá popsanému mechanismu odvozování ID.

Kam s vyhledanými vzpomínkami: skrytá cena v cache

Čtvrté rozhodnutí se může projevit až na účtu, zejména v dlouhých relacích. Většina poskytovatelů velkých jazykových modelů cachuje prompt od začátku, a to až po tzv. bod přerušení (breakpoint). Pokud se cokoli před tímto bodem změní, vše od změny dál se znovu plně zpoplatní. Výsledky vyhledávání v paměti se přitom mohou měnit v každém kole. Když je vložíte do systémového promptu, stojí před zbytkem konverzace, tedy před historií. Každá změna vzpomínek tak zneplatní cache pro všechno, co následuje. Historie za nimi se pak téměř nikdy nečte z cache a v každém kole se platí za celý prompt. Nejnepříjemnější je, že se nic nehlásí jako chyba. Aplikace funguje správně, jen roste náklad.

Výsledky vyhledávání dejte na konec

Autor doporučuje opačné pořadí: výsledky vyhledávání přesunout na konec promptu, za zprávu uživatele, a poslat je jako samostatnou zprávu. Stabilní část, tedy systémový prompt a dosavadní historie, tak zůstane na začátku beze změny a může se číst z cache. Měnící se blok vzpomínek stojí až za ní. Breakpoint pak patří na uživatelskou zprávu těsně před tímto blokem. Detail je podstatný, protože bez explicitního umístění ho poskytovatel dá na konec poslední zprávy, a to je v tomto uspořádání právě blok vzpomínek. Cachovaná část by se tak opět změnila v každém kole. Podle autora by v takové situaci modely GPT-5.6 cachovaly jen systémový prompt a modely Claude by nezískaly žádný zásah cache. Tvrzení o konkrétních modelech pochází z autorova popisu a nemohli jsme ho ověřit jinde.

Úspora má své podmínky

Kolik se ušetří, záleží podle autora na dvou věcech: kolik textu stojí před blokem vzpomínek a jak dlouhá je relace. Krátká konverzace s malým prefixem ušetří málo, dlouhá relace s velkým prefixem podstatně víc. Proto autor radí měřit počet cachovaných tokenů na vlastním řešení a kontrolovat ho při každé změně rozložení promptu. Když cache přestane fungovat, nic nespadne, jen vzroste účet. Existuje i varianta, kdy se stále aktivní témata načtou na začátku relace jako součást prefixu a hledání proběhne zvlášť, s výsledky odeslanými na konec. Celá historie pak zůstává v cache. Varianta má nevýhodu v aktuálnosti dat. Co uživatel řekne v aktuální relaci, je v historii tak či tak. Pokud ale jiná relace přepíše některou načtenou vzpomínku, aktuální relace změnu neuvidí, dokud se neotevře další.

Co z textu nevyplývá

Je dobré znát meze zdroje. Jde o blog samotného Weaviate, tedy o popis vlastního produktu, a čísla pocházejí z autorových vlastních testů, například z 24 nebo pěti běhů. Nezávislé srovnání dodaný materiál neobsahuje. Praktický závěr je přesto konkrétní. Vlastní témata si vyzkoušejte na sadě stejných vět. Kde mají být stálé vzpomínky, téma omezte. U úzce zaměřených témat do popisu přidejte pravidlo, co vynechat. A po každé úpravě rozložení promptu zkontrolujte počet cachovaných tokenů, protože jinak se problém ukáže až na faktuře.

Grafy a schéma pocházejí z původního článku uvedeného ve zdrojích.

Zdroje

1. Agent Memory with Engram: A Practical Guide | Weaviate — Weaviate Blog

Článek vznikl s pomocí AI; podklady a odkazy jsou uvedeny výše.