Klient z finančného sektora nám raz ukázal agenta, ktorý zvládal jednoduché otázky skvele — ale keď rozhovor trval dlhšie alebo sa vrátili k nemu na druhý deň, agent sa správal, akoby sa nikdy nestretli. Zabudol kontext. Zabudol rozhodnutia, ku ktorým dospeli. Zabudol, čo klient povedal o svojich prioritách pred dvoma hodinami. „Je to predsa AI — prečo si nepamätá?" bola ich frustrovaná otázka.
Je to otázka architektúry, nie modelu. Pamäť AI agenta nie je automatická vlastnosť — je to navrhnutá vrstva systému. A navrhnúť ju zle znamená, že agent opakuje otázky, stráca kontext pri každom novom volaní a nemôže sa učiť z predchádzajúcich interakcií. Tento článok vysvetlí, ako pamäť agenta funguje, kde sú jej hranice a ako ich riešiť v praxi.
Čo je pamäť agenta a prečo nie je to isté ako RAG
Skôr než pôjdeme ďalej, je dôležité rozlíšiť dve veci, ktoré sa v praxi často zamieňajú: pamäť agenta a RAG (Retrieval-Augmented Generation).
RAG je mechanizmus na načítanie znalostí — keď agent potrebuje odpovedať na otázku, siahe do vektorovej databázy a načíta relevantné dokumenty (technická dokumentácia, firemné predpisy, produktové katalógy). RAG je o prístupe k znalostiam zvonka.
Pamäť agenta je o stave agenta — o tom, čo si pamätá z prebiehajúcej interakcie, z histórie session alebo o konkrétnom používateľovi/entite. Pamäť je o kontinuite konverzácie a kontextu.
Praktický rozdiel: keď sa agent spýta „v akom formáte chcete výstup?" a vy odpoviete „Excel", mal by si to pamätať do konca session. To nie je RAG — to je pracovná pamäť agenta. RAG by ste použili, keď agent potrebuje nájsť, aké výstupné formáty váš systém podporuje.
Zmätok medzi týmito dvoma konceptmi vedie k zlým architektonickým rozhodnutiam. Tímy nasadzujú RAG, keď potrebujú pamäť, alebo opačne.
Štyri vrstvy pamäte agenta
V praxi rozlišujeme štyri odlišné typy pamäte, pričom každý rieši iný problém:
1. In-context pamäť (short-term)
Toto je primárna pracovná pamäť agenta — konverzačná história, ktorá sa priamo nachádza v context window modelu. Agent "vidí" celú históriu rozhovoru ako súčasť vstupu.
Výhody sú zjavné: nulová latencia pri prístupe, agent vždy "vidí" čo bolo povedané, jednoduché na implementáciu.
Limity sú rovnako zjavné:
- Kontext nie je nekonečný. Väčšina produkčných modelov má kontext 128k–1M tokenov, no to neznamená, že agent rovnako dobre spracuje informácie na začiatku aj na konci dlhej konverzácie.
- "Lost in the middle" efekt — overený jav: model venuje menšiu pozornosť informáciám v strede dlhého kontextu. Dlhá história neznamená spoľahlivé spracovanie celej histórie.
- Náklady rastú lineárne s dĺžkou konverzácie — každý token v histórii sa posiela znovu pri každom ďalšom volaní.
- Pamäť zmizne po ukončení session. In-context pamäť je efemérna — pri novom rozhovore je agent tabuľa rasa.
In-context pamäť je výborná pre krátke, uzavreté interakcie. Pre dlhé alebo perzistentné scenáre nestačí sama.
2. Externá (long-term) pamäť
Keď interakcia presahuje jednu session alebo kontext okno, potrebujeme externú pamäť — perzistentné úložisko, do ktorého agent zapisuje a z ktorého číta.
Najčastejšie implementácie:
- Vektorová databáza (napr.
Qdrant,pgvector) — agent uloží kľúčové fakty alebo celé konverzačné fragmenty ako vektory. Pri ďalšej session ich načíta cez sémantické vyhľadávanie. Je to podobné RAG, ale na pamäťovú históriu namiesto znalostnej bázy. - Relačná databáza / key-value store — pre štruktúrované fakty o entitách (používateľ preferuje slovenčinu, pracuje v oddelení X, má rolu Y). Rýchle a deterministické.
- Epizodická pamäť — záznamy o minulých interakciách uložené vo forme "čo sa stalo v session Z" — agent ich môže načítať a naučiť sa z nich alebo sa na ne odkazovať.
Kľúčový rozdiel oproti RAG nad znalostnou bázou: v externej pamäti agent píše sám — je to jeho vlastný stav, nie externý dokument.
Externá pamäť prináša vlastné výzvy: kedy zapisovať (po každom výmene? na konci session?), čo je hodné uloženia a čo nie, ako zvládnuť konfliktné alebo zastarané záznamy.
3. Sumarizačná pamäť
Pre dlhé konverzácie je praktickým riešením priebežná sumarizácia. Namiesto uchovávania celej histórie agent (alebo samostatný summarizer krok) periodicky komprimuje staršie časti konverzácie do stručného súhrnu.
Typický vzor implementácie v LangGraph:
- Drž posledných N správ v plnom znení v kontexte (napr. posledných 20 výmen)
- Všetko staršie skomprimuj do 2–3 odsekov súhrnu
- Súhrn sa nachádza na začiatku kontextu ako "doterajší stav"
Výhody: kontext ostáva riaditeľný, náklady nerastú neobmedzene, agent má stále prístup k podstate predchádzajúcich rozhovorov.
Nevýhody: sumarizácia je stratová — detail môže zmiznúť. Pri právnych alebo compliance scenároch kde záleží na presnom znení je to riziko. Pre technické rozhovory kde jeden konkrétny konfiguračný parameter bol spomínaný pred hodinou, sumarizácia ho môže vynechať.
4. Working memory (procedurálna / stavová pamäť)
Toto je najčastejšie prehliadaná vrstva. Working memory je štruktúrovaný stav, ktorý agent udržiava počas vykonávania úlohy — nie konverzácia, ale *operačný kontext*.
Príklady: - Zoznam krokov, ktoré agent dokončil a ktoré ešte čakajú - Medzivýsledky z volania nástrojov - Rozhodnutia prijaté v predchádzajúcich krokoch (napr. „zvolili sme formát XML") - Stav multi-step pipeline (v ktorej fáze sme)
V LangGraph sa working memory prirodzene mapuje na State grafu — každý uzol číta a zapisuje do zdieľaného state objektu. Toto je jedna z hlavných výhod explicitného state managementu oproti jednoduším frameworkom.
Working memory je kritická pre agentov, ktorí vykonávajú dlhé pipeline úlohy — bez nej agent "zabudne" čo urobil v predchádzajúcich krokoch a môže duplikovať prácu alebo si odporovať.
Ako tieto vrstvy spolupracujú
V praxi produkčný agent kombinuje všetky štyri vrstvy. Ako to vyzerá na príklade agenta pre technickú podporu vo výrobnej firme:
- 1.Používateľ otvorí novú session → agent načíta z externej pamäte (vektorová DB) relevantné informácie o tomto zákazníkovi: jeho stroje, predchádzajúce tikety, preferovaný kontakt. Toto ide do začiatku kontextu.
- 1.Počas konverzácie → celá história správ je in-context. Agent udržiava working memory: "zákazník popísal problém s motorom M3, skontroloval som už kroky A a B, čakám na výstup diagnostického nástroja."
- 1.Konverzácia sa predĺži nad 20 výmen → sumarizačný krok komprimuje staršie časti. Kľúčové fakty (typ stroja, sériové číslo, popis problému) sú extrahované a uložené v sumarizácii.
- 1.Session sa ukončí → agent zapíše do externej pamäte: "tiket #1234, zákazník X, problém Y, riešenie Z, spokojnosť 4/5". Toto bude dostupné pri ďalšom otvorení.
- 1.O týždeň zákazník opäť píše → cyklus sa opakuje, ale tentokrát s históriou ako základ.
Toto nie je sci-fi — je to štandardná produkčná architektúra, ktorú implementujeme pre zákazníkov. Zložitosť nie je v technológii, ale v rozhodnutí čo uložiť, kedy a v akom formáte.
Dizajn externej pamäte: čo uložiť a čo nie
Jeden z najčastejších problémov, s ktorými sa stretávame pri nasadzovaní agentov s dlhodobou pamäťou, je pamäťová explózia — agent ukladá príliš veľa, relevancia zápisov klesá, a pri načítaní sa dostáva späť irelevanty šum.
Niekoľko pravidiel, ktoré fungujú v praxi:
- Ukladaj fakty, nie text. Namiesto celého paragrafu konverzácie uloží agent extrahovaný fakt:
{"user_id": "X", "preference": "output_format: Excel", "confidence": "explicit"}. Štruktúrovaný fakt je ľahšie vyhľadať, ľahšie aktualizovať a zaberá menej miesta.
- Rozlíš trvalosť. Niektoré informácie sú trvalé (zákazník má stroje značky Siemens), iné sú dočasné (v tejto session riešime konkrétnu poruchu). Tieto by mali byť v oddelených úložiskách s odlišnou TTL (time-to-live).
- Pamäť má verzie. Keď zákazník zmení preferenciu, stará hodnota by nemala byť premazaná — mala by byť archivovaná s časovou značkou. Toto je dôležité pre auditovateľnosť.
- Explicitná vs. implicitná pamäť. Keď používateľ explicitne povie „pamätaj si, že...", je to jednoznačné. Keď agent usudzuje z kontextu (zákazník sa trikrát spýtal na tú istú tému → pravdepodobne je to priorita), je to implicitná pamäť — menej spoľahlivá, vyžaduje vyššiu mieru dôvery.
Kedy dlhý kontext nestačí
Môže sa zdať, že s modelmi s miliónovým kontextom je otázka pamäte vyriešená — jednoducho vložte celú históriu. V praxi to nefunguje tak jednoducho.
Po prvé, "lost in the middle" efekt — model venuje nepomerne menšiu pozornosť informáciám uprostred dlhého kontextu. Kritický fakt zo začiatku dlhej konverzácie môže byť de facto neviditeľný.
Po druhé, nákladový aspekt — celá história sa posiela pri každom volaní. Pre rozhovor s tisíckami výmen je to zbytočný token overhead, ktorý priamo ovplyvňuje náklady agenta v produkcii.
Po tretie, škálovateľnosť — systém s 10 000 aktívnymi agentmi kde každý drží plnú históriu v kontexte nie je realistický. Perzistentná externá pamäť umožňuje škálovanie, pretože stav je mimo procesu.
Po štvrté, multi-session kontinuita — kontext okno je vždy resetované pri novej session. Bez externej pamäte je každý nový rozhovor tabuľa rasa bez ohľadu na to, koľkokrát sa zákazník predtým ozval.
Dlhý kontext je mocný nástroj — ale je to nástroj pre spracovanie dlhých dokumentov a komplexné jednorazové úlohy, nie náhrada za navrhnutú pamäťovú architektúru.
Sumarizácia vs. selektívne uloženie: kde je hranica
Dve hlavné stratégie pre správu dlhej konverzačnej histórie sú sumarizácia a selektívne uloženie kľúčových faktov. Každá má svoje miesto.
Sumarizácia je vhodná keď: - Konverzácia je naratívna, kontextuálna, ťažko štruktúrovateľná - Dôležité sú relácie a tok myšlienok, nie izolované fakty - Rýchlosť implementácie je priorita
Selektívne uloženie faktov je vhodné keď: - Konverzácia obsahuje jasne identifikovateľné entity a atribúty - Fakty je potrebné neskôr vyhľadávať, aktualizovať alebo agregovať - Auditovateľnosť je požiadavka (financie, compliance)
V produkčných systémoch väčšinou kombinujeme oboje: sumarizácia pre "príbeh" session, štruktúrované fakty pre entity a rozhodnutia.
Priame prepojenie na spôsob, ako agent uchováva stav medzi krokmi, nájdete v článku o architektúrach AI agentov — najmä v sekcii o checkpointingu v LangGraph.
Technická implementácia: LangGraph ako referenčný vzor
Pre produkčné nasadenie odporúčame LangGraph ako referenčný rámec pre pamäťové vzory — nie preto, že je "módny", ale preto, že explicitne modeluje stav ako prvého občana architektúry.
Kľúčové koncepty v kontexte pamäte:
- State schema — definujete čo je v working memory agenta: aké polia, aké typy, aké defaultné hodnoty. Toto eliminuje skryté globálne stavy.
- Checkpointing — LangGraph natívne podporuje ukladanie stavu grafu do perzistentného úložiska (SQLite, PostgreSQL). To umožňuje resume po prerušení, HITL (human-in-the-loop interrupt), aj post-mortem debugging.
- Memory store — novšie verzie LangGraph obsahujú dedikovaný memory store pre cross-thread pamäť (zdieľanú medzi rôznymi konverzáciami toho istého používateľa).
Checkpointing v LangGraph je aj základná technika pre human-in-the-loop pri agentoch — agent sa zastaví pred kritickou akciou, stav sa uloží, a po ľudskom schválení pokračuje od rovnakého miesta.
Alternatívne: mem0 je dedikovaná open-source knižnica pre pamäť agentov, ktorá poskytuje abstrakciu nad rôznymi úložiskami (vektorová DB, KV store, graf). Vhodná ak nechcete byť viazaní na jeden framework.
Bezpečnostné aspekty pamäte agenta
Toto sa v diskusiách o pamäti agentov zriedkavo objavuje, ale je kritické: pamäť agenta je útočná plocha.
Ak agent načítava pamäť z externého úložiska a vkladá ju do kontextu, útočník s prístupom k tomuto úložisku môže vložiť škodlivé inštrukcie, ktoré budú tichými súčasťami každej budúcej session. Toto je variant prompt injection útoku — a je zákernejší ako priamy injection, pretože prichádza z dôveryhodného interného zdroja.
Praktické opatrenia:
- Pamäťové záznamy by mali prechádzať sanitizáciou pred vložením do kontextu
- Rozlišujte medzi dôveryhodnou pamäťou (systémom zapisovanou) a nedôveryhodnou (zákazníkom alebo externou službou)
- Loggujte čo agent načítal z pamäte — to je súčasť observability AI agentov
- Pri high-risk agentoch (finančné transakcie, prístup k systémom) uvažujte o pamäti s explicitným human review pred aktiváciou
Časté otázky
Je RAG to isté ako pamäť agenta?
Nie. RAG je mechanizmus na načítanie znalostí z externej znalostnej bázy — napríklad firemnej dokumentácie alebo databázy produktov. Pamäť agenta je o stave samotného agenta: čo si pamätá z konverzácie, o používateľovi alebo o predchádzajúcich interakciách. V architektúre sú to dve odlišné vrstvy, hoci technicky môžu oboje používať vektorovú databázu na uloženie.
Postačuje dlhé context window namiesto externej pamäte?
Pre jednorazové, uzavreté úlohy áno — model s miliónovým kontextom zvládne spracovať aj veľmi dlhý dokument. Pre multi-session agentov s históriou, pre škálovateľné systémy alebo pre scenáre kde si agent musí pamätať fakty naprieč dňami a týždňami, dlhý kontext nestačí. Navyše, "lost in the middle" efekt obmedzuje spoľahlivosť pri veľmi dlhých vstupoch.
Ako zabrániť, aby agent "zabudol" na dôležitú informáciu z dlhej konverzácie?
Kombinácia troch opatrení: (1) sumarizácia histórie s explicitnou extrakciou kľúčových faktov do structured formatu, (2) uloženie faktov do externej pamäte ihneď pri ich identifikácii (nie na konci session), (3) pracovná pamäť (working memory) ako explicitný state objekt v grafovom agente, kde dôležité rozhodnutia sú priamo zapísané ako polia — nie schované v konverzačnom texte.
Koľko stojí externá pamäť agenta navyše?
Priame náklady sú nízke — vektorová databáza ako Qdrant je open-source a na typické objemy (státisíce záznamov) zvládne aj cenovo dostupný server. Väčší nákladový dopad má retrieval latencia (pridáva 50–200 ms na dotaz) a vývojársky čas na správny dizajn pamäťovej schémy. Horšia správa pamäte (ukladanie všetkého namiesto selektívneho ukladania) môže zvýšiť token náklady pri retrievali — relevantnosť záznamu priamo ovplyvňuje, koľko tokenov sa načíta späť do kontextu.
Aká je najčastejšia chyba pri implementácii pamäte agenta?
Z praxe: zabúdanie na sumarizáciu a čistenie. Tímy implementujú zápis do pamäte, ale neriešia čo sa stane, keď sa pamäť zaplní irelevantnými zápismi alebo zastaranými faktami. Po niekoľkých týždňoch agent načítava späť šum, ktorý znižuje kvalitu jeho odpovedí. Pamäťová vrstva potrebuje rovnako premyslenú "stratégiu zabudnutia" ako stratégiu ukladania.
*Pamäťová architektúra je jednou z tých vrstiev systému, kde sa projekty najčastejšie podceňujú vo fáze prototypu — a kde sa zaplatí cena pri škálovaní do produkcie. Ak navrhujete agenta, ktorý má fungovať v reálnom prostredí s reálnymi používateľmi naprieč dňami a týždňami, radi s vami preberieme, aká pamäťová vrstva dáva zmysel pre váš konkrétny prípad.*