Phase D-memory + E — Plánované¶

Pozn. Phase D-core (chat s RAG injection) byla dokončena 30.4.2026. Detail viz Phase D — Chat s RAG injection. Tato stránka popisuje co je deferováno po D-core.

Phase D-memory — Cognee + Neo4j + chat message vector index¶

Stav: ⏳ Plánováno (separátní session po validaci D-core na reálných queries) Cíl: Plnohodnotná "chat memory" — kompletní historie chatu uživatele dohledatelná přes vektory + entity graph pro cross-session continuity.

Co D-memory přidá nad D-core¶

D-core má last-N-páry-v-promptu jako transitional přístup. To stačí pro follow-up rozpoznání během jedné konverzace, ale neřeší:

Plný history retrieval — uživatel se vrací po týdnu, chce „co jsme řešili minule o té povodňové zóně?“
Cross-conversation entity tracking — stejná nemovitost ve 2 konverzacích, různé stakeholdery (kupující + prodávající + odhadce)
Temporální fakta — „V březnu jsem říkal že Q100 zóna je problém“ (Graphiti pattern v Cognee)
Selektivní embedding — ne každá user message má retrieval value („díky“, „prosím rozveď“); Cognee orchestrator decidne co jde do vector / graph storage

Architektura¶

[Chat user input]
    ↓
Cognee orchestrator (Python lib)
    ├─→ Pgvector (Supabase) — sémantické chunks (Phase C HOTOVÉ — reuse)
    └─→ Neo4j + Graphiti — entity graph + temporální fakta (D-memory NEW)
    ↓
Hybrid memory context → LLM

Komponenty které D-memory přidá¶

Backend: - cognee Python lib — orchestrator pro vector + graph - app/memory/ modul — entity extraction tasks, episode model, hybrid retrieval - DB metoda db.embed_message(message_id) — async batch worker pro existing messages backfill

Infra: - Neo4j Sliplane Docker service (4. service: backend + redis + worker + neo4j) - ENV NEO4J_URI / NEO4J_USER / NEO4J_PASSWORD

Schema: - nemoreport.messages migrace: embedding_status text + embedded_at timestamptz columns (additive) - Možná separate nemoreport.message_chunks (= same shape jako chunks, jen FK na messages místo reports)

Open questions D-memory (rozhodnout v separate session)¶

Episode model: 1 conversation = 1 episode? per-turn? mix?
Co embedovat: každou message? jen user queries? jen "informational" messages (filter triviálních „díky“)?
Vector dimensionality pro messages: stejné halfvec(1536) jako reports, nebo full 3072 (krátké queries by mohly těžit z full)?
Entity types: parcely, adresy, sekce reportu, rizika, kontakty (banka, pojišťovna)? Granularita matters pro graph utility.
Retrieval policy: kdy vector (sémantické "podobné dotazy") vs graph (vztahy entit) vs hybrid?
TTL pro messages embeddings: indefinite? 90 dní? Per-tenant policy?

Co D-memory NEBLOKUJE¶

D-core pipeline je production-ready bez D-memory. D-memory je quality-of-life upgrade — bez něj funguje chat na single-conversation úrovni, s ním funguje napříč sessions.

Časový odhad¶

~3–5 dnů implementace (Cognee + Neo4j setup + entity tasks tuning + smoke test) + 1 den iterace na real chat datech.

Phase D-core — deferred polish (nice-to-have)¶

Tyto věci jsou v scope D-core jako expand items (mimo spine), deferované do dalšího iteration cyklu po validaci:

Multi-report cross-folder RAG — compare_report_ids ≥ 2 zatím na full-text concat, RAG path by potřeboval scope.type='multi_report' v /retrieve (501 v Phase C.5)
Section scope retrieval — body.section projde do system promptu jako focus hint, retrieve scope zůstává folder
Figure binary delivery v RAG mode — chunks figures mají AI annotation v content, binary obrázky až po validaci value-vs-cost
Pre-stream event: retrieval SSE — frontend UX progress indicator („Hledám relevantní informace…“)
Sources UI badge / modal — citace jsou inline text, badge UI je nice-to-have
Debug mode ?debug=1 — debug payload v response (chunks scores, rewrite, latence per stage) pro tester troubleshooting
Admin retrieval quality dashboard — top queries, latency histogram, feedback correlation

Phase E — Nette integration¶

Stav: ⏳ Plánováno (gate: Nette tým ready) Cíl: Embed chat do Nette aplikace, JWT bridge, HMAC webhooks, DNS cutover

Co bylo připraveno v Phase A/B¶

verify_nette_jwt() ready hook v app/auth.py — RS256 + iss/aud/exp enforcement, neaktivní v A
POST /reports/{id}/attachments/system — HMAC-authed endpoint pro Nette automatické attachment uploady (Phase B B.11)
Embed-first frontend — chat je vždy iframe, jen parent origin se změní

Plánovaný flow¶

Nette user logged in
  → Nette signs RS256 JWT { sub: nette_user_id, email, aud: "nemoreport-ai", iss: "nemoreport.cz", exp: now+15min }
  → postMessage { type: "nemoreport-ai:init", authToken: "<JWT>" }
  ↓
Chat iframe (https://review.algaweb.cz/chat?id=...)
  → POST /auth/nette-exchange { jwt }
  ↓
Backend
  → verify_nette_jwt(token) — RS256 přes NETTE_JWT_PUBLIC_KEY
  → lookup or create Supabase user via auth.identities(provider='nette')
  → generate Supabase session → return { access_token, refresh_token }
  ↓
Frontend uses Supabase session, chatuje bez druhého loginu

Komponenty¶

Backend: - POST /auth/nette-exchange — verify Nette JWT → mint Supabase session - ENV NETTE_JWT_PUBLIC_KEY (PEM) — pro RS256 verify - ENV NETTE_AUDIENCE = "nemoreport-ai", NETTE_ISSUER = "nemoreport.cz"

Frontend: - iframe child listener pro postMessage event nemoreport-ai:init - apiFetch exchange Nette JWT → Supabase session - Adjust CORS / origins pro Nette domain

Infra: - DNS cutover: NemoReport AI app on review.algaweb.cz (currently on nemoreport-ai-frontend-v2.algaweb.workers.dev) - CF Workers route bind

Časový odhad¶

~1 týden implementace + integration testing s Nette tým + DNS cutover.

Další plánované funkce (mimo phase plan)¶

Token credit system (přeprodej)¶

Per project memory project_nemoreport_admin_section:

Až přijde, bude další admin sekce — token mint/refund, user balances, transaction log. Cost tracking se přepíše z raw halíře na "tokens spent". Pro Phase C zatím držet raw cost v ingestion_cost_cents.

User explicit decision 30.4: bude "přeprodej tokenů jako platební systém — uživatelé kupují kredity, utrácejí na platformě". Frontend cost zobrazení teď interní, pro produkci se přepíše.

Admin analytics dashboard¶

/admin/retrieval/* endpointy nad retrieval_log: - Top queries / scope distribution - A/B variant comparison - Per-tenant retrieval stats - Latency p50/p95/p99 trends

/admin/cost/* UI v admin frontu (zatím jen JSON endpointy).

Multi-report scope retrieval¶

Phase C MVP supports jen scope.type='folder' (single report). Multi-report scope:

scope.type='multi_report', report_ids=[...]
HNSW with WHERE report_id IN (...) — pgvector iterative_scan='relaxed_order'
Use case: cross-report comparison ("porovnej tyto 3 nemovitosti")

Resend production domain¶

Pro reálné testery (mimo owner email). Verifikace auth.algaweb.cz nebo auth.nemoreport.cz.

Cohere production key¶

Trial limit ~1000 calls/měsíc. Pilot OK, scale potřebuje upgrade.