Co je agentická paměť?
Agentická paměť je mechanismus, díky kterému si AI agent udrží informace mezi jednotlivými běhy, místo aby každé spuštění bral jako první seznámení. Bez ní agent zná jen to, co se vejde do aktuálního kontextového okna: prompt, dosavadní konverzaci a dokumenty, které jste do něj tentokrát vložili. Jakmile session zavřete, všechno to zmizí. Agentická paměť je vrstva, která přežije reset – místo, kam si agent zapíše, co se stalo, a při dalším běhu si to zase přečte.
Odborná literatura o agentech postavených na jazykových modelech, třeba framework CoALA, ji dělí na několik pracovních kategorií:
- Pracovní paměť. Co agent drží pro běh, ve kterém je právě teď. Krátkodobá, jakmile běh skončí, zmizí.
- Epizodická paměť. Záznam konkrétních minulých událostí: jaký úkol proběhl, co agent rozhodl a jaký byl výsledek.
- Sémantická paměť. Fakta a preference vytažené z těchto událostí a uložené tak, aby si je agent mohl později vyhledat – třeba roli uživatele, omezení projektu nebo opravu, kterou už nemá zopakovat.
- Procedurální paměť. Jak agent postupuje: vzorce zabudované přímo v modelu a k tomu kroky sepsané v jeho vlastním kódu a instrukcích.
Úložiště pod tím vším může být skoro cokoliv: vektorová databáze pro podobnostní vyhledávání, relační tabulka, key-value úložiště, nebo obyčejné soubory v Markdownu a JSONu, které agent čte přímo. Názvy kategorií popisují, k čemu paměť slouží, ne jak je uložená.
Lidsky řečeno
Představte si rozdíl mezi úplně novým brigádníkem a někým, kdo ve firmě pracuje už tři roky. Oba mají na stole stejnou příručku (to je kontextové okno). Zkušenější kolega má navíc sešit s poznámkami typu „to už jsme zkoušeli, nefungovalo to“ a „tento klient vždycky chce X, ne Y“, do kterého nahlédne, než odpoví. Agentická paměť je přesně ten sešit – a k tomu disciplína nové stránky do něj opravdu psát a ty staré občas vyhodit.
Kdy na tom záleží
- Práce, která přesahuje jeden běh. Agent, který třídí supportní tickety, hlídá projekt nebo celé dny pracuje na backlogu, si potřebuje pamatovat, co už rozhodl. Jinak při každém probuzení opakuje stejné hledání a stejné chyby.
- Opravy, které mají platit dál. Když člověk agentovi řekne „nedělej X, dělej radši Y“, ta instrukce je k ničemu, pokud se na konci session vypaří. Paměť je to, co jednorázovou opravu promění v trvalé pravidlo.
- Personalizace bez opakovaného vysvětlování. Agent, který si pamatuje stack uživatele, jeho roli a preference, si tento kontext nemusí při každém volání skládat znovu. Samotné učení v kontextu na to po skončení session nestačí.
- Náklady. Vkládat stejné podklady do každého promptu stojí při každém běhu tokeny. Krátký, dobře udržovaný záznam v paměti bývá mnohem levnější, než stejný kontext pokaždé znovu odvozovat nebo vysvětlovat od nuly. Navíc drží okno během dlouhého běhu kratší, a právě krátké okno context rot oddaluje.
Časté chyby
- Automaticky sáhnout po vektorové databázi. Embeddingy a vektorové úložiště jsou nástroj na konkrétní problém: fuzzy sémantické vyhledávání ve velkém nestrukturovaném korpusu. Některým agentům přitom stačí malá a stabilní sada trvalých faktů o projektu nebo o člověku. Pro takový případ bývají jednodušší a levnější strukturované záznamy v Markdownu nebo JSONu, které agent přímo čte a zapisuje. Člověk je taky snáz zkontroluje než podobnostní vyhledávání, které vrací výsledky „dost blízké“.
- Stavět soubory a vektorové úložiště proti sobě. Jeden z našich interních agentů používá obě vrstvy a dělí je podle úkolu. Fakta, která musí sedět přesně, drží v obyčejných Markdown záznamech, ke kterým patří malý index. Ten si agent načte na začátku každé session. Patří sem omezení projektu, záznamy o tom, kdo co rozhodl, a opravy, které se nesmí opakovat. Člověk je přečte, upraví a změnu zkontroluje v pull requestu. Agent si všechno, co za měsíce viděl, vybavuje přes naši samostatnou paměťovou službu Mozeček. Ta stojí na PostgreSQL a pgvectoru a hledá hybridně, vektorově i fulltextově. Soubory nesou to, co musí sedět přesně, vektorové úložiště to, čemu stačí být dost blízko. Začněte u souborů; úložiště přidejte, až si to vyžádá objem dat a neurčitost dotazů, ne naopak.
- Ukládat závěry bez zdroje. Záznam v paměti, který říká „klient preferuje týdenní reporty“, je mnohem méně užitečný než záznam, u kterého navíc víte, kdo to řekl, kdy a proč. Bez zdroje se zastaralý nebo chybný záznam nedá odlišit od správného a nikdo ho pak bezpečně neaktualizuje.
- Nikdy nic nezapomenout. Paměť, která jen přibírá záznamy, se časem změní v hromadu zastaralých a protichůdných poznámek. Užitečné paměťové systémy staré záznamy nahrazují nebo je nechávají vypršet, jakmile jim odporují nové informace, místo aby si navždy uchovávaly každou verzi.
- Zaměňovat paměť za větší kontextové okno. Větší okno znamená, že agent toho v jednom běhu udrží víc najednou. Neříká to ale nic o tom, jestli z toho něco přežije do dalšího běhu. Paměť a velikost okna řeší každá jiný problém.
Související články:
- Co je kontextové okno? – Krátkodobá paměť během jedné session; tu má agentická paměť přežít.
- Co je context rot? – Proč víc dat v okně nenahradí skutečnou paměť.
- Co to je Agent? – Systém, který agentická paměť mění z bezstavového na stavový.
- Co je učení v kontextu? – Naučit se úkol z příkladů v promptu, aniž by po skončení něco zůstalo.
- Co je agentní RAG? – Vzorec vyhledávání, který často staví na paměťovém úložišti agenta.
Chcete být o krok napřed?
Nenechte si utéct naše nejlepší postřehy. Žádný spam, jen praktické analýzy, pozvánky na exkluzivní eventy a shrnutí podcastů přímo do vaší schránky.