Pessoal, o agent puxou um trecho bonito. Similaridade alta. Confiança alta. Estava no stub errado.
Não foi "RAG fraco". Foi porta errada. Índice caro, lixo na entrada.
O post anterior foi sobre consultar o grafo de código: token cai quando o agent pergunta ao mapa, não quando o gitignore está certo. Aqui é a outra conta. Vector, GraphRAG, híbrido: como recuperar. Contrato: o que pode ser lembrado e por onde se entra. Sem a segunda, o índice só erra mais rápido.
A prova também não é o vendor. É o transcript. Primeiro passo foi abrir o hub canônico, ou foi grep no cemitério?
Tabela de Conteúdo
- 1. O índice acertou. O mundo, não
- 2. Vector vs GraphRAG vs híbrido: a conta real
- 3. A prova está na porta, não no recall
- 4. O contrato em quatro peças
- 5. Hub-first na prática: o steering que roda
- 6. Anti-padrões com nome
- 7. O checklist antes do índice
1. O índice acertou. O mundo, não
A pergunta clássica era qual banco de vetor? A de 2026 é vector, grafo ou os dois?
A minha ficou outra: quando o agent pergunta "onde está X?", ele entra pelo hub ou grepa o bak?
Se for a segunda, tanto faz o logo. Você indexou o labirinto.
O debate público é retrieval. Lookup ("qual o prazo neste contrato?") vs síntese ("quais os riscos em todos?"). Vector costuma ganhar no primeiro. GraphRAG no segundo, caro de manter. Híbrido roteia.
Isso importa. Mas não decide se legado/ pode ser porta. Não decide se o agent mistura diário com runbook no mesmo contexto. Embedding "certo" em guia morto é política ausente.
2. Vector vs GraphRAG vs híbrido: a conta real
Antes de escolher o banco, a pergunta é o tipo de trabalho que o agent faz.
| Critério | Vector (embedding) | GraphRAG | Híbrido |
|---|---|---|---|
| Força | Lookup semântico. "Acha o trecho parecido" | Síntese multi-hop. "Cruza entidades e relações" | Roteia por tipo de pergunta |
| Fraqueza | Não conecta. Dois chunks parecidos, sem relação | Custo de manutenção. Grafo desatualiza | Complexidade de roteamento |
| Custo de setup | Baixo. Embed + index | Alto. Extração de entidades + grafo | Médio. Dois pipelines |
| Custo de manutenção | Baixo. Re-embed no delta | Alto. Re-extrair relações | Médio |
| Quando usar | FAQ, doc único, busca por similaridade | Base de conhecimento interconectada, análise de risco | Volume alto + perguntas mistas |
Um recorte com data: vector vs GraphRAG, 2026. Snapshot, não ranking.
O ponto: nenhum dos três resolve porta errada. Se o agent entra por backup_old/ com cosine similarity de 0.92, você tem recall alto e resposta errada. GraphRAG com entidade extraída de stub deprecado é o mesmo problema com grafo bonito.
No meu setup o contrato veio antes do vetor. Não estou dizendo que vetor é inútil. Estou dizendo que porta entrega valor no dia zero. Eval de recall é outra conta.
3. A prova está na porta, não no recall
Mesma lógica do grafo de código. Lá eu olho se o primeiro tool foi query ou o décimo Read. Aqui eu olho se o agent cita o hub ou só a similaridade.
Pergunta: qual a regra de entrada da memória do agent?
Turno caro (anti-padrão)
[agent]
grep "memória" (em tudo)
Read README.bak
Read staff/old-notes.md
Read legado/cursor-setup-v1.md
→ responde com confiança, regra invertida
O agent achou 4 arquivos. Todos com "memória" no texto. Nenhum é o canônico. O mais recente era de março. A resposta saiu confiante e errada.
Turno barato (hub-first)
[agent]
scope = meta
Read pages/meta/rag-contract.md (o hub)
→ vê que a regra está na seção 3
→ responde citando o hub
grep só se precisar de detalhe
Mesma pergunta. Um Read. Resposta certa. O agent disse por qual porta entrou.
Se o agent não consegue dizer por qual porta entrou, você não tem contrato. Tem índice.
4. O contrato em quatro peças
Cabem em qualquer vault. Os nomes das caixas são seus.
4.1 Fonte única
Um canônico. O resto é espelho ou lixo.
No meu caso: um vault Logseq, versionado em git. Confluence continua fonte oficial de produto em conflito factual. Mas o agent não entra pelo Confluence. Entra pelo vault.
4.2 Scopes
Cada página pertence a uma caixa. Sem caixa, o search mistura incidente com diário.
| Scope | Hub | Contém |
|---|---|---|
pessoal |
pages/pessoal/_hub.md |
Identidade, valores, mentoria |
carreira |
pages/carreira/_hub.md |
Portfolio, plano, progresso |
ops |
pages/ops/_hub.md |
Incidentes, runbooks, projetos |
meta |
pages/meta/rag-contract.md |
Regras do vault, contratos |
legado |
redirect only | Stubs apontando pro canônico |
Página nova declara scope::. Sem isso, você está indexando ruído.
4.3 Porta (hub-first)
- Classificar scope pela pergunta
- Abrir o hub do scope com Read (não só grep)
- Seguir links canônicos
- Grep é complemento, não entrada
4.4 Hop máximo
Redirect fino (≤15 linhas) aponta pro canônico. Máximo 1 hop. Labirinto de stub é indexar lixo de propósito.
staff/* e legado/* são redirects only. Nenhuma página viva nova entra ali.
5. Hub-first na prática: o steering que roda
O contrato vira steering no agent. No meu setup (Kiro/Cursor), é um arquivo markdown que carrega em toda sessão.
# RAG hub-first
## Regra
**Código/arquitetura** → usar graph_search (graphify MCP). Não ir ao Logseq.
**Memória/domínio/ops** → hub-first no Logseq conforme abaixo.
## Hub-first — quando aplicar
Gatilhos: "aonde está", "no RAG", currículo, LinkedIn,
o que estudo, VSUS/incidente, plano de carreira.
1. Classificar scope: pessoal | carreira | ops | meta
2. Abrir o hub correspondente:
- ops → pages/ops/_hub.md
- carreira → pages/carreira/_hub.md
- pessoal → pages/pessoal/_hub.md
- meta → pages/meta/rag-contract.md
3. Seguir canônico do hub. Citar [[scope/pagina]] na resposta.
**Proibido:** responder localização só com grep sem abrir o hub.
O steering é a política. O hub é a porta. O scope é a caixa. Sem os três, você tem vendor.
6. Anti-padrões com nome
Nomear o problema ajuda a identificar no transcript.
| Anti-padrão | O que acontece | Sintoma no transcript |
|---|---|---|
| Grep no cemitério | Agent busca em backup/, old/, legado/
|
Primeiro tool é grep, não Read do hub |
| Stub farm | Dezenas de stubs apontando pra lugar nenhum | Hop > 1, resposta circular |
| Labirinto indexado | Vector index inclui deprecated + draft + backup | Alta similaridade, baixa relevância |
| Scope soup | Incidente mistura com diário mistura com carreira | Resposta cruza contextos sem sentido |
| Hub bypass | Agent ignora o hub e vai direto no grep | Resposta não cita fonte canônica |
O mais comum: hub bypass. O agent sabe que existe um hub. Mas o grep é mais rápido. Aí ele pula a porta e entra pela janela. A resposta vem. Só que do stub de 2024.
7. O checklist antes do índice
Antes de rodar embed() ou extrair entidades pro grafo:
1. Fonte canônica: um vault, não cinco?
2. Scopes: cada caixa tem hub?
3. Página nova declara scope?
4. Porta: steering força hub-first?
5. Redirect: hop máximo 1?
6. Proibido como entrada: legado, backup, bak, draft?
7. Search é complemento, nunca substituto do hub?
8. Nunca no contexto: segredo, PII, case identificável?
9. Como você sabe que errou? (agent cita o hub usado)
Se você não consegue responder a 9, você tem recall. Não tem prova.
O que eu ainda não resolvi
O contrato funciona pra memória de domínio. Pra código, o caminho é outro: grafo de código (graphify), não vault de texto. Os dois coexistem, mas não se misturam.
Embedding vetorial no vault eu ainda não liguei. O hub-first resolve 90% dos casos sem custo de index. Quando ligar, o contrato continua valendo: o vetor é retrieval, não porta.
GraphRAG pra síntese de entidades (tipo "quais incidentes afetaram o módulo X nos últimos 6 meses") é o próximo passo. Mas isso é outro post.
No seu último "RAG": o agent entrou por porta, por similaridade, ou por grep no bak? O que você proibiria como entrada amanhã?
Top comments (3)
This is a good distinction: retrieval quality and memory architecture are two different problems.
GraphRAG can give you a highly relevant result and still be wrong if the agent entered through the wrong source. I also like the “hub-first” idea because it makes the retrieval path observable instead of treating similarity score as proof that the context is valid.
The scope + canonical source + limited hops feels especially important once a project has enough historical material to create conflicting versions of the same rule.
One question I’d be interested in: how are you evaluating the memory contract itself? Not just whether the final answer is correct, but whether the agent followed the expected entry point and avoided prohibited sources. That seems like a useful eval signal for agent reliability.
Thanks, Kane. You nailed the next problem I’m exploring. A correct final answer isn’t enough if the agent reached it through the wrong source.
I’m evaluating the contract through the retrieval trace: expected entry point, sources visited, hop limit, and whether any prohibited source was touched.
Your question is a great next step. I’ll go deeper into this evaluation layer in the next post.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.