Jak dát AI dlouhodobou paměť

01Proč hierarchická paměť

Velké jazykové modely mají omezené context window. Jakmile konverzace překročí limit, starší zprávy vypadnou z promptu.

• Model zapomíná kontext
• Uživatel musí opakovat informace
• Konverzace se stávají nekonzistentní
• Náklady na tokeny rostou exponenciálně

Řešení není větší context window. Efektivnější přístup je hierarchická paměť — ukládá dlouhodobé informace, komprimuje historii, zachovává aktuální kontext. Výsledek: prakticky nekonečná konverzace bez nekonečných tokenů.

02Princip — analogie s počítačem

Hierarchická paměť funguje stejně jako paměť v počítači. Každá vrstva má jinou rychlost, kapacitu a účel.

03Celková architektura systému

Po každé zprávě:

• Context Builder sestaví prompt ze všech paměťových vrstev
• Model Router vybere optimální model
• LLM generuje odpověď
• Na trigger zprávě (např. každých 100 zpráv) se na pozadí spustí sumarizace

04Context Builder

Context Builder sestavuje prompt. Pořadí je důležité — model ignoruje informace uprostřed dlouhého promptu (recency bias). Proto je struktura striktně definovaná.

// System prompt po sestavení Context Builderem:

Jsi AI asistent...

## User Memory (cross-chat)
"[{\"fact\":\"Projekt e-shop, stack: Next.js + Firebase\",\"category\":\"projects\"},{\"fact\":\"TypeScript strict, minimální závislosti\",\"category\":\"preferences\"}]"

## Chat Summary
"{\"topics\":[\"Optimalizace Firestore reads\",\"Composite indexy\"],\"decisions\":[\"Composite index pro multi-field queries\"],\"userContext\":\"Uživatel optimalizuje e-shop s 1000+ DAU\"}"

// ↑ JSON.stringify obalí data do stringu s escaped uvozovkami
// Model jasně vidí: toto jsou DATA, ne instrukce

// Messages (overlap + nové):
// [0-9] overlap — zprávy 90-99 (surový most přes sumarizaci)
// [10] assistant: "Composite index vytvoříš..."  ← zpráva 100
// [11] user: "Jak nastavit composite index?"     ← zpráva 101 (aktuální)

05Cross-Chat Memory

Ukládá dlouhodobé informace o uživateli: projekty, technologie, preference, rozhodnutí. Sdílené napříč všemi chaty.

Batch zpracování (cron job)

Paměť se neaktualizuje po každé zprávě. Cron job (např. jednou denně) analyzuje chaty s 10+ zprávami a extrahuje klíčové informace:

Importance Scoring

Každý fakt má prioritu. Při nárůstu databáze se promazávají fakta s nízkým score:

User-editovatelná paměť

Protože paměť je uložená jako strukturovaný JSON v databázi, uživatel ji může přímo editovat v UI. V nastavení aplikace přidáte sekci kde user vidí své uložené fakty a může je upravit, smazat, nebo přidat nové. Model při dalším batch update respektuje manuální úpravy — nekopíruje smazané fakty zpět.

06Chat Summary a trigger logika

Komprimuje historii konverzace. Klíčový detail je kdy a jak se sumarizace spouští.

Trigger musí být vždy na user zprávě

Sumarizace běží paralelně — uživatel dostane odpověď a na pozadí se komprimuje historie. Trigger se musí spouštět na user zprávě, ne na odpovědi modelu. Proč? Sumarizace potřebuje kompletní pár (user + assistant) a nesmí blokovat odpověď.

Implementace: trigger + summarizer

Anchor systém

Každá sumarizace vytvoří referenční bod — lastMessageIndex. Další sumarizace čte pouze zprávy od tohoto bodu. Žádné duplicitní zpracování:

Proč ukládat sumarizaci jako JSON

Plain text sumarizace se může smíchat s prompt instrukcemi. Pokud prompt používá XML tagy nebo markdown headings, model nerozliší kde končí system prompt a začíná sumarizace. Strukturovaný JSON formát jasně odděluje data od instrukcí — model ví, že obsah uvnitř JSON stringu jsou data k přečtení, ne instrukce k následování.

Bonus: v databázi je strukturovaný JSON snazší debugovat, filtrovat a editovat než blob textu.

07Message Buffer

Buffer má dvě části: overlap (posledních ~10 zpráv před sumarizací) a nové zprávy (od sumarizace po aktuální). Overlap funguje jako most — sumarizace může vyhladit detaily z posledních zpráv a bot by pak nevěděl na co přesně navazuje. S overlapem má vždy surový kontext kolem bodu kde sumarizace skončila.

Nové zprávy přibývají postupně — hned po sumarizaci jich je pár, na konci cyklu (před dalším triggerem) jich může být i 100.

08Model Router

Router vybírá model podle složitosti dotazu. Sám router je malý, rychlý model — nesmí přidávat latenci.

09RAG a dokumentová paměť

AI může pracovat s externími dokumenty — PDF, Markdown, API docs. Firestore má nativní vector search, takže nepotřebuješ externí vector DB.

Embedding a uložení do Firestore

Vector search při dotazu

10Bezpečnost a fail-safe

11Databáze a implementace

Firestore schema

Kompletní message handler

Všechno dohromady — od přijetí zprávy po odpověď:

12Cost optimalizace a monitoring

Každá vrstva používá jiný model — jiný poměr cena/kvalita:

Monitoring

13Multi-agent rozšíření

Systém lze rozšířit o agenty. Každý agent má vlastní kontext a vlastní roli:

Memory agent rozhoduje, které informace z úkolů dostanou vysoký importance score pro trvalé uložení.