Dlouhodobá paměť pro AI agenty: Jak naučit asistenta pamatovat si tě (a ušetřit za tokeny)

Tvoje AI agent si pamatuje jméno uživatele přesně tak dlouho, jak trvá jedno okno chatu. Zavřeš konverzaci — a příště začíná od nuly. Zeptá se na preference, které před týdnem už sbíral. Znovu vysvětluje kontext, který dávno máš v databázi. A ty za ten zbytečný context opakovaně platíš tokeny.

Dlouhodobá paměť je dnes jeden z posledních nerušených battlegroundů agent stacku. Řeknu ti, proč o to běží, jaké jsou reálné možnosti (Mem0, Zep, Letta, Redis) a jak ji nasadit, aniž bys vyhořel na context pollution nebo účtech za LLM.

Proč je paměť těžká (a proč LLM sám o sobě nestačí)

Jednoduchá pravda: LLM jsou stateless. Sama o sobě si mezi dvěma API voláními nepamatují vůbec nic. ChatGPT a Claude mají paměť vrstvenou navrch, ale když si stavíš vlastního agenta, musíš tu vrstvu postavit sám.

A není to jedna věc. V produkci typicky potřebuješ tři typy paměti (formalizuje to CoALA framework):

• Episodická — konkrétní minulé události a interakce. „Před měsícem si rezervoval let do Londýna na konferenci, preferuješ hotel v centru."
• Procedurální — naučené dovednosti a operční znalost. Agent ví, že pro tvůj booking workflow je správná sequence: ověř vízum → zkontroluj layover → rezervuj hotel.
• Sémantická — obecná fakta a vztahy, často nad znalostní bází (firemní politika, FAQ, pravidla).

Většina týmů si tohle podcení, dokud nejsou hluboko ve vývoji. Pak zjistí, že retrieval je pomalý, kontext se zanáší nesmysly a reasoning agenta se horší místo zlepšuje.

Krátkodobá vs. dlouhodobá paměť: jedna věta

Krátkodobá paměť = RAM, drží kontext pro jedno konverzační vlákno. Dlouhodobá = disk, perzistuje napříč sessions. Pokud chceš, aby si agent pamatoval, že preferuješ přímé lety i za tři měsíce, potřebuješ obojí.

Čtyři možnosti, které dnes reálně fungují

1. Mem0 — dedikovaná paměťová vrstva

Mem0 je open-source paměťová vrstva stavěná přímo pro agenty. 90 000+ vývojářů, SOC 2, HIPAA, self-host přes Docker.

Co dělá jinak než „ulož si celý historii":

• Single-pass extrakce: Zpracuje každou interakci jednou, vytáhne memory-worthy fakta, uloží jen ta. Neplácá celé transkripty zpět do promptu.
• ADD-only model: Paměť je append-only. Nové pozorování nesmaže staré — přidá se k němu s timestampem. Agent tak může uvažovat o tom, kdy se co změnilo („adresa se změnila 1. 3. 2026").
• Multi-level scoping: Paměť je vázaná na user, session, agent i organizaci. Multi-tenant z dob výroby.

Nasadíš to v Pythonu takhle:

from mem0 [import Memory](/content/claude-import-memory)

m = Memory()
# uložení po každé interakci
m.add("Preferuju přímé lety, nesnáším layover v Frankfurtu.",
      user_id="petr", agent_id="travel-bot")

# před dalším turnem vytáhni relevantní kontext
hits = m.search("let do Tokia", user_id="petr")
# vrátí stručný context block místo celého transkriptu

Default používá gpt-5-mini pro extrakci a text-embedding-3-small pro vektory. Můžeš vyměnit za jakýkoliv jiný LLM.

2. Zep — paměť stavěná pro konverzační AI

Zep extrahuje entity, intenty a fakta ze konverzací a ukládá je strukturovaně. Má progresivní sumarizaci (kondenzuje dlouhou historii při zachování klíčových bodů) a podporuje sémantické i temporální vyhledávání.

Kdy ho vybrat místo Mem0: když máš dlouhé, dialogově těžké konverzace (customer support, therapy-like flows) a potřebuješ časovou osu „co se kdy řeklo".

3. Letta — paměť jako operační systém

Letta se inspiruje OS architekturou. Main context = RAM, external storage = disk. Agent si sám funkcemi read/write/archive přesouvá informace mezi aktivním kontextem a long-term storage. Implementuje myšlenku MemGPT.

Kdy vybrat: dlouho běžící konverzační agenti, kteří potřebují efektivně pracovat s context window a „odkladat" věci, které teď nepotřebují.

4. Redis — když chceš platformu, ne další dependency

Redis kombinuje všechny potřebné storage patterny na jednom místě: in-memory hash/JSON pro krátkodobý stav, nativní vector search pro sémantickou paměť, eviction policies pro decay. Referenční implementace je open-source Redis Agent Memory Server.

Proč to zmiňuji separatně: když si Mem0 nebo LangGraph nasadíš, stejně pod tím běží nějaká databáze. Redis ti umožní konsolidovat session store, cache i vector store v jedné infrastruktuře — což je reálné zjednodušení operací.

Architektonická rozhodnutí, která tvarují všechno ostatní

Ať už si vybereš cokoliv, čekají tě čtyři rozhodnutí:

1. Co ukládat. Neukládej všechno. Customer support agent potřebuje hlavně episodickou paměť (historie ticketů). Recommendation agent potřebuje sémantickou (produkty, vztahy). Coding asistant potřebuje procedurální (naučené debugging strategie). Match architekturu na use case, nepřidávej komplexitu pro teoretické požadavky.

2. Jak ukládat. Tři osvědčené přístupy v produkci:

• Sumarizace — LLM kondenzuje konverzaci, ukládá klíčové body. Riziko: ztratí detail, který teď vypadá nedůležitý, ale za měsíc bude klíčový.
• Vektorizace — paměť jako embeddingy, sémantický retrieval. Funguje pro „konceptuálně podobné" dotazy.
• Extrakce — tahá fakta, entity, preference do strukturovaného formátu (RedisJSON), podporuje exact match i range query.

Většina produkčních agentů kombinuje vícero.

3. Jak retrieve-ovat. Nejčastěji hybrid retrieval: nejdřív strukturovaný lookup (user_id, timestamp), pak vector search pro sémantickou relevance. Pro začátek vezmi prostý vector search a přidávej komplexitu, až se retrieval kvalita stane bottleneckem.

4. Kdy zapomenout. Bez decay mechanismu paměť roste neomezeně a retrieval se horší. Dvě praktické cesty: přidat timestamp jako metadata a vážit novější paměti výše při retrievalu, nebo použít eviction policy (Redis umí automaticky vyřadit stará data).

Nejčastější místa, kde to praská

Všechny body níže jsem viděl v reálných deploymentech. Pozor na ně:

• Context pollution. Když do promptu nasypeš příliš pamětí, reasoning se horší. LLM si nevybere, co je relevantní — odvede pozornost. Lepší menší, přesnější kontext než velký.
• Token costs replay. Tým re-dotazuje celou historii při každém turnu, aby agent „měl kontext". Měsíčně tisíce dolarů zbytečně. Single-pass extrakce (Mem0) je tady game-changer.
• Retrieval latency. Na hot path každé interakce běží vícero lookupů. Latency se sčítá. Relevance AI hlásí zlepšení z 2 s na 10 ms po migraci na Redis — 99,5 %. To je rozdíl mezi „působí pomalu" a „působí instant".
• Žádná verze pamětí. Když agent naučíš špatnou věc, nemůžeš se vrátit. Mem0 má versioning built-in. Pokud si píšeš vlastní, implementuj.
• Self-host bez auth. Mem0 OSS má od nedávna auth zapnutou defaultně. Migrace ze staré verze bez nastavení ADMIN_API_KEY ti rozbije deployment. Čti upgrade notes.

Konkrétní rozhodovací strom

Potřebuješ rychle pustit do produkce? → Mem0 (hosted) nebo Zep. Máš developerka, self-host, striktní data rules? → Mem0 OSS (Docker) nebo Redis Agent Memory Server. Dlouho běžící agent, omezený context window? → Letta. Už Redis používáš na session store? → Zůstaň u Redis, neskákej na další dependency.

Praktický start: za 30 minut máš paměť

Nejrychlejší cesta v srpnu 2026:

# 1. Mem0 self-host přes Docker
docker run -d -p 8080:8080 \
  -e OPENAI_API_KEY=$OPENAI_API_KEY \
  mem0/server:latest

# 2. V agentovi: před každým turnem retrieve, po každém add

Většina frameworků (LangGraph, CrewAI, AutoGen) má dnes Mem0 integraci hotovou. Nahradíš storage backend, logika paměti se nemění.

Shrnutí

Dlouhodobá paměť není „nice to have" — je to rozdíl mezi agentem, který působí jako nástroj, a agentem, který působí jako asistent. Ceny LLM nerostou lineárně s kvalitou, takže čím víc dokážeš vytáhnout z kontextu a nechat v paměťové vrstvě, tím levnější provoz.

Začni jednoduše: Mem0 nebo Redis. Vyber jeden memory type pro use case, který reálně řešíš. Nasazuj hybrid retrieval jen když to bude potřeba. Měř retrieval kvalitu a latenci — ne slepě věř, že „to funguje".

A pamatuj: paměť, kterou si nenaučíš auditovat, se ti v měsíci vrátí jako regression, kterou nedokážeš vysvětlit. Versioning od prvního dne.