Módulo 2.3 — Memória e Conhecimento

🗃 SQLite FTS5 — Busca em Texto Completo

FTS5 (Full-Text Search versão 5) é um módulo do SQLite que transforma o banco em um motor de busca completo. Zero configuração, zero servidor, zero custo — apenas SQLite com superpoderes de busca.

🏗 Schema da Memória

CREATE VIRTUAL TABLE memories USING fts5(

content, -- Texto do fato/memória

category, -- fact | conversation | solution

created_at, -- Timestamp ISO

metadata, -- JSON com contexto extra

tokenize = 'unicode61'

);

💡 Por que não embeddings + vector DB?

Vector databases são mais precisos para busca semântica, mas adicionam complexidade e custo (modelo de embedding + banco separado). Para assistente pessoal com vocabulário consistente, FTS5 + BM25 tem performance excelente com complexidade zero.

📊 BM25 — Ranking de Relevância

BM25 (Best Match 25) é o algoritmo de ranking que o SQLite FTS5 usa por padrão. É o mesmo algoritmo que o Elasticsearch e Solr usam. Resulta em memórias ranqueadas por relevância real, não por data de criação.

🔍 Query com BM25

-- Busca memórias sobre Python, ordenadas por relevância

SELECT content, category, bm25(memories) as score

FROM memories

WHERE memories MATCH 'Python FastAPI'

ORDER BY score

LIMIT 5;

🏗 Sistema de 2 Camadas de Memória

A arquitetura de memória resolve o problema do context window: você não pode colocar toda a memória no system prompt. A solução é 2 camadas com propósitos distintos.

📄 Camada 1: MEMORY.md

Fatos estáticos de bootstrap. Sempre no system prompt. Exemplo: nome do usuário, stack tecnológica, empresa, fuso horário.

Tamanho recomendado: < 500 tokens

🗄 Camada 2: memory.db

Fatos dinâmicos e histórico. Buscados por relevância quando necessário. Pode crescer indefinidamente — só os top-5 relevantes entram no contexto.

Tamanho: ilimitado (busca por relevância)

🏷 Categorias de Memória

Cada entrada no memory.db tem uma categoria que permite buscas mais precisas. Quando o Jarvis precisa de contexto, ele filtra pela categoria mais relevante para a pergunta atual.

fact

Fatos sobre o Usuário e Mundo

Preferências, configurações, informações sobre projetos. Ex: "Usuário usa PostgreSQL 16 em produção"

conversation

Trechos de Conversas Importantes

Decisões tomadas, contexto de projetos discutidos. Ex: "Em 2026-04, decidimos usar Redis para sessões"

solution

Soluções que Funcionaram

Como problemas foram resolvidos. O Jarvis consulta isso antes de sugerir soluções. Ex: "Docker build lento → adicionar .dockerignore resolveu"

🔍 Deduplicação Automática

Sem deduplicação, a memória acumula variações do mesmo fato. O store.py implementa upsert inteligente: antes de salvar, busca fatos similares e atualiza o existente se a similaridade for alta.

🔄 Algoritmo de Deduplicação

Novo fato chega para ser salvo

FTS5 busca fatos similares na mesma categoria

Se score BM25 > threshold (0.7): UPDATE do fato existente

Se score < threshold: INSERT de novo fato

🗜 Compactação Automática

Memória que cresce sem limite torna-se lenta de buscar. Compactação automática periodicamente sumariza entradas antigas em fatos mais densos, mantendo a relevância sem consumo descontrolado de espaço.

✓ O que Compactar

✓Conversas com mais de 30 dias
✓Fatos redundantes do mesmo tópico
✓Histórico de decisões antigas

✗ O que Preservar

✗Soluções que funcionaram (high-value)
✗Preferências fundamentais do usuário
✗Fatos acessados frequentemente

✅ Resumo do Módulo 2.3

✓

SQLite FTS5 — Busca full-text nativa, zero dependências externas

✓

BM25 — Ranking por relevância real, não por data

✓

2 Camadas — MEMORY.md (bootstrap estático) + memory.db (histórico dinâmico)

✓

Categorias — fact, conversation, solution para buscas precisas

✓

Deduplicação — Upsert inteligente evita duplicatas usando BM25 similarity

✓

Compactação — Sumarização de memórias antigas mantém a busca eficiente

Próxima Trilha:

Trilha 3 — Segurança Zero-Trust: a trilha mais importante do curso

← Módulo 2.2 Trilha 3: Segurança →