Memory Engine
Sistema de memória hierárquico multi-tier (Hot/Warm/Cold) com compressão semântica inteligente, compliance automático LGPD/HIPAA, e context injection para continuidade AI ↔ Humano.
⚡ O Problema
Chatbots enterprise precisam de memória de contexto. Quando um cliente retorna dias depois, o bot precisa lembrar conversas anteriores, preferências e histórico de atendimentos.
- ✗Tokens são caros: Injetar todo o histórico no prompt explode os custos
- ✗Latência mata UX: Busca em banco relacional adiciona 200-500ms
- ✗Compliance obrigatório: LGPD, CFM, CFO têm regras rígidas de retenção
- ✗Handover complica: AI precisa saber o que aconteceu quando humano atendeu
✨ A Solução
Arquitetura Hot/Warm/Cold
Sistema de armazenamento em 3 tiers com estratégia Write-Through:
Write-Through: Toda escrita vai primeiro para PostgreSQL (durabilidade garantida), depois replica para Redis (performance).
Customer Facts Temporais
Em vez de armazenar conversas brutas, extraímos fatos estruturados com janela de validade temporal:
CustomerFact:
fact_key: "preferred_times"
fact_value: {"morning": true}
valid_at: 2025-01-01T10:00:00Z
invalid_at: null ← fact currently active
# Customer changed preference 3 months later:
fact_key: "preferred_times"
fact_value: {"afternoon": true}
valid_at: 2025-04-01T14:00:00Z
invalid_at: null
Histórico temporal completo para auditoria. Consulta O(1) para fatos atuais via índice parcial.
Compressão Semântica com LLM
Conversas longas são comprimidas usando OpenAI com templates verticais específicos (dental, médico, jurídico):
- ✓Preserva: Fatos críticos, decisões, próximos passos
- ✓Remove: Saudações, confirmações redundantes, detalhes operacionais
- ✓Resultado: 90% redução com 100% preservação de informação relevante
Compliance Automático
Classificação e tratamento automático baseado no vertical:
Anonimização inteligente: CPF -> ***.***.***.00
Handover Summary
Continuidade perfeita quando atendente humano intervém:
🏗️ Arquitetura
┌─────────────────────────────────────────────────────────────┐ │ MEMORY ENGINE │ ├─────────────────────────────────────────────────────────────┤ │ │ │ 🔥 HOT (Redis) 🌡️ WARM (Redis) 🧊 COLD (PostgreSQL) │ TTL: 1 min TTL: 1 hour Permanent │ │ Latency: <10ms Latency: <50ms Latency: ~100ms │ │ │ │ ┌─────────┐ ┌─────────┐ ┌─────────────┐ │ │ │ Última msg │ │ Sessão Ativa │ │ Histórico Completo │ │ │ │ │───────▶│ │────────▶│ │ │ │ └─────────┘ └─────────┘ └─────────────┘ │ │ │ │ │ │ │ └───────────────────┴────────────────────┘ │ │ Write-Through Strategy │ │ (PostgreSQL = Source of Truth) │ └─────────────────────────────────────────────────────────────┘ ┌─────────────────────────────────────────────────────────────┐ │ CONTEXT COMPOSER v2 │ ├─────────────────────────────────────────────────────────────┤ │ Facts (Lógica) │ Summary (Linguagem) │ Recent (Chat) │ │ ─────────────── │ ──────────────────── │ ───────────── │ │ name: "João" │ "Customer preferred" │ [últimas 5 msgs]│ │ phone: "11..." │ "morning, already" │ │ │ pref: morning │ "scheduled 2..." │ │ └─────────────────────────────────────────────────────────────┘
🎯 Decisões Técnicas
Por que Write-Through e não Write-Behind?
Write-Behind (async write to DB) é mais performático mas arriscado. Em atendimento ao cliente, perder uma mensagem é inaceitável. Write-Through garante durabilidade imediata com performance aceitável.
Por que schema isolation e não row-level security?
RLS adiciona overhead em cada query. Com schemas separados (t_), o isolamento é físico e a performance é máxima. Trade-off: mais complexidade operacional.
Por que Customer Facts temporais?
LLMs são péssimos em "esquecer". Se o cliente mudou de preferência, o modelo com histórico completo continuaria usando a preferência antiga. Facts temporais com valid_at/invalid_at resolvem isso elegantemente.
Por que separar Facts vs Summary no Context Composer?
Facts são para lógica (o sistema usa para tomar decisões). Summary é para linguagem (o LLM usa para gerar respostas naturais). Essa separação evita que o LLM "alucine" sobre dados estruturados.