Módulo 5.2 — Memória SQLite vs Wiki Markdown

🗄️ Como o Intelecto Usa SQLite

O SQLite do Intelecto é uma memória episódica automática: cada conversa é sumarizada pelo LLM e armazenada como uma linha na tabela FTS5. Recuperação via BM25 é transparente — acontece em milissegundos antes de cada resposta.

🗄️ Pipeline de Memória SQLite

Schema SQLite do Intelecto

-- Tabela FTS5 para memórias
CREATE VIRTUAL TABLE memories USING fts5(
    content,           -- Texto da memória sumarizada
    created_at UNINDEXED,  -- Timestamp de criação
    source UNINDEXED   -- 'conversation' | 'vault' | 'manual'
);

-- Query de recuperação por BM25
SELECT content, bm25(memories) AS score
FROM memories
WHERE memories MATCH 'Python async vault'
ORDER BY score  -- BM25 nativo do FTS5 (negativos = mais relevantes)
LIMIT 5;

⚠️ Limitações da Memória SQLite

A memória SQLite é excelente para o que foi projetada — contexto de conversa. Mas tem limitações fundamentais para conhecimento de longo prazo que justificam a existência do wiki.

⚠️ Problemas com SQLite como memória de longo prazo

✗
Degradação por sumarização: Cada rodada de sumarização perde detalhes. Após 5 sumarizações de um conceito complexo, o que sobra é uma sombra do original — sem a precisão necessária para conhecimento técnico.
✗
Sem versionamento: Memórias são sobrescritas sem histórico. Você não sabe como seu entendimento de um conceito evoluiu — o Git do wiki registra cada mudança com timestamp e diff.
✗
Sem links estruturados: Memórias são ilhas de texto sem conexão tipada. O wiki tem [[links]] bidirecionais que criam um grafo de conhecimento navegável — o SQLite não sabe que "Python" e "asyncio" estão relacionados.
✗
Não auditável por humanos: O arquivo .db é binário. Você não pode revisar, corrigir ou editar memórias diretamente — ao contrário de um arquivo .md que você abre no Obsidian e edita em segundos.

Visualizando a degradação por sumarização

Original: "SQLite FTS5 usa BM25 com parâmetros k1=1.2 e b=0.75. Para o caso do Intelecto com memórias curtas (~100 tokens), reduzir k1 para 0.9 melhora o recall em 23% conforme benchmark interno de março."

1ª sumar.: "Intelecto usa SQLite FTS5 com BM25. Ajuste de parâmetros melhora recall."

2ª sumar.: "Intelecto usa BM25 para recuperar memórias."

3ª sumar.: "Sistema tem memória."

✅ Vantagens do Wiki Markdown

O wiki Markdown não degrada, não perde estrutura e mantém o contexto original com precisão cirúrgica. É um repositório de conhecimento que você pode confiar para estar correto em 5 anos.

✓ Propriedades do Wiki Markdown

✓Versionado com Git — diff completo de cada mudança, blame por linha, rollback a qualquer ponto
✓Legível por humanos — abra no Obsidian, VS Code ou até cat no terminal. Sem ferramenta especial
✓Links bidirecionais — [[conceito]] cria grafo navegável. O Obsidian Graph View mostra clusters e gaps
✓Auditável e editável — erro encontrado? Edite o .md diretamente. Sem intermediário
✓Compilável pelo LLM — index.md como catálogo permite respostas estruturadas de qualidade superior

Exemplo de página wiki compilada

---
titulo: SQLite FTS5 e BM25
tipo: conceito-tecnico
relacionados:
  - [[intelecto-memoria]]
  - [[bm25-algoritmo]]
  - [[segundo-cerebro-arquitetura]]
atualizado: 2026-01-15
---

# SQLite FTS5 e BM25

## O que é
FTS5 (Full-Text Search 5) é a extensão
de busca textual do SQLite. BM25 é o
algoritmo de ranking padrão...

## Parâmetros críticos
- k1=1.2 (saturação de termo)
- b=0.75 (normalização de comprimento)
- Para textos curtos: k1=0.9 melhora recall

## Referências
- [[intelecto-configuracao]]
- [[memoria-curto-longo-prazo]]

🏗️ Arquitetura Híbrida

A arquitetura híbrida combina o melhor dos dois sistemas: SQLite como cache rápido de curto prazo, Wiki como repositório permanente de longo prazo. A transição entre eles é gerida por regras explícitas.

🏗️ Arquitetura em Camadas

🔄 Sincronização das Duas Memórias

O bridge entre SQLite e Wiki é um script Python simples (~50 linhas) que lê o index.md do vault e insere entradas estruturadas no SQLite do Intelecto, enriquecendo o BM25 com conhecimento compilado.

Wiki → SQLite (bridge.py)

import sqlite3, pathlib, re

VAULT = pathlib.Path("~/vault/wiki")
DB = "intelecto.db"

def sync_wiki_to_sqlite():
    conn = sqlite3.connect(DB)
    index = (VAULT / "index.md").read_text()

    # Parse entradas do index.md
    for match in re.finditer(
        r'\[\[(.+?)\]\].*?—\s*(.+)', index
    ):
        page, summary = match.groups()
        full = (VAULT / f"{page}.md").read_text()
        # Insere no SQLite FTS5
        conn.execute(
            "INSERT INTO memories(content, source)"
            "VALUES (?, 'vault')",
            [f"{page}: {summary}\n{full[:500]}"]
        )
    conn.commit()

sync_wiki_to_sqlite()

SQLite → Wiki (promoção manual)

# Listar memórias candidatas à promoção
SELECT id, content, created_at
FROM memories
WHERE source = 'conversation'
  AND length(content) > 200
  AND created_at < date('now', '-7 days')
ORDER BY bm25(memories, 'importante')
LIMIT 10;

# Após revisar, exporte a memória
# e salve em vault/raw/insight-YYYY-MM-DD.md
# Depois execute /ingere para compilar

A promoção é manual: você decide o que merece virar página wiki permanente

💡 Dica: Sincronização Incremental

Execute bridge.py apenas para páginas modificadas recentemente, usando o timestamp do arquivo. No cron: find ~/vault/wiki -newer ~/vault/.last_sync -name "*.md" — isso evita re-inserir o vault inteiro a cada execução e mantém a sincronização rápida mesmo com centenas de páginas.

🧠 Escolhendo o Modelo Mental Correto

A regra principal é simples: use SQLite para o efêmero e wiki para o permanente. O critério é a "vida útil esperada da informação".

🗄️ Use SQLite quando...

→Contexto de uma conversa específica
→TODO item com prazo curto (<2 semanas)
→Nota rápida para não esquecer hoje
→Preferências e hábitos do usuário
→Estado atual de um projeto (muda toda semana)
→Resultado de reunião com itens de ação

📖 Use Wiki quando...

→Conceito técnico que você quer dominar
→Decisão arquitetural com justificativa
→Comparação entre tecnologias ou abordagens
→Entidade relevante (pessoa, ferramenta, projeto)
→Insight que você quer consultar em 6 meses
→Padrão ou anti-padrão documentado

🎯 A pergunta decisiva

"Eu vou querer consultar isso em 6 meses?"

❌ Não

Deixe no SQLite. Vai sumarizar e eventualmente ser deduplicated. Custo de compilação wiki não se justifica.

✅ Sim

Compile para o wiki. Invista 5 minutos agora para economizar horas de reconstrução mental no futuro.

✅ Resumo do Módulo 5.2

✓

SQLite FTS5 + BM25 — memória episódica automática com ranking por relevância, sumarização e deduplication

✓

Limitações do SQLite — degrada por sumarização, sem versionamento, sem links, não auditável diretamente

✓

Vantagens do Wiki — Git, legível, links bidirecionais, auditável, permanente, compilável pelo LLM

✓

Arquitetura híbrida — SQLite para curto prazo, wiki para longo prazo, bridge para sincronização

✓

Modelo mental — "vou querer isso em 6 meses?" decide entre SQLite e wiki

Próximo Módulo:

5.3 — Integrando Vault Obsidian com Intelecto: bridge.py, ingestão pelo Telegram e consulta híbrida em ação.

← Módulo 5.1 Próximo Módulo →