📏 O Problema de Escala
Com 50 notas, qualquer abordagem funciona. Com 500 notas, o LLM não pode ler tudo a cada consulta. Com 5.000, precisamos de indexação hierárquica e estratégia de contexto.
📈 Tokens vs. Notas no Vault
🗂️ Indexação Hierárquica
A solução para vaults grandes é um índice de dois níveis: o index.md principal aponta para índices de subdomínio, que por sua vez apontam para notas individuais.
🗂️ Índice Hierárquico de 2 Níveis
🗜️ Compressão de Contexto
Para notas muito longas, o LLM pode criar uma versão comprimida — um resumo de 3-5 linhas que captura os fatos-chave. O index.md aponta para esses resumos, não para as notas completas.
# Projeto Alpha — Fase 2
## Contexto
O projeto Alpha iniciou em Janeiro como...
[histórico longo de 3 parágrafos]
## Decisões Técnicas
Em Fevereiro, o time decidiu migrar de...
[detalhes de 5 decisões]
## Status Atual
O sprint 8 está em andamento...
[atualizações semanais dos últimos 3 meses]
## Riscos
[lista de 12 riscos identificados]
## Ação Items
[50 items de backlog]## projeto-alpha
Status: Sprint 8, 75% completo
Tech: FastAPI + PostgreSQL
Líder: [[joao-carlos]]
Risco principal: bug em prod (P1)
Demo: 2024-03-22 para cliente
→ [[projeto-alpha]] (nota completa)10× menos tokens para decisão de leitura
LLM decide se precisa da nota completa baseado no resumo
Cada nota tem um resumo de 3-5 linhas no topo. O index.md replica esses resumos. O LLM lê resumos para decidir quais notas completas precisa — como um abstract científico.
🔀 Sharding: Múltiplos Vaults
Quando um vault supera ~1.000 notas, considere sharding por domínio: múltiplos vaults especializados com um vault-raiz que os referencia.
🔀 Arquitetura Multi-Vault
- → Consultas mais rápidas (contexto menor)
- → Colaboração possível por domínio
- → Agents especializados por vault
- → Links cross-vault são mais complexos
- → Manutenção de múltiplos CLAUDE.md
- → Overhead de orquestração
🚀 Caching de Consultas Frequentes
Algumas consultas são feitas todo dia: status de projetos, dashboard de métricas, lista de tarefas. Pre-computar essas consultas reduz custo e latência.
Nota de Dashboard Pré-computado
# dashboard.md — atualizado diariamente pelo agente
## Status (atualizado: 2024-03-20)
### Projetos Ativos
| Projeto | Status | Prazo | Líder |
|---------|--------|-------|-------|
| Alpha | Sprint 8 — 75% | Mar 22 | João |
| Beta | Em pausa | Abr 01 | Maria |
### Bloqueadores
- [P1] Bug PostgreSQL em Alpha (João, hoje)
- [P2] Aprovação cliente para Beta (vendas, Thu)
### Esta Semana
- Demo Alpha — Sexta 14h
- Standup Beta — Qui 10h
Gerado por: agente-dashboard — raw/agenda/*.md📊 Benchmarks e Metas de Performance
Defina metas de performance para seu vault. Um sistema lento ou caro vai ser abandonado — o objetivo é resposta em menos de 30 segundos e menos de 5k tokens por consulta.
| Tamanho do Vault | Estratégia | Tokens/Consulta | Latência |
|---|---|---|---|
| < 100 notas | index.md simples | 2-5k | < 10s |
| 100-500 notas | Índice hierárquico + resumos | 5-10k | < 20s |
| 500-2.000 notas | Multi-índice + dashboard cache | 8-15k | < 30s |
| > 2.000 notas | Sharding + agentes especializados | 5-10k por shard | < 30s |