Busca vetorial contra grafo de conhecimento: quanto custa de verdade construir e manter um GraphRAG

• Corpus original e tamanho do grafo: 10.019 fichas de conhecimento transformadas em 5.237 nós e 19.803 arestas (arquivo SQLite de 15 MB)
• Economia na fase de construção: redução do custo de extração de $1.500 estimados (com 117K tokens de prefixo por chamada) para poucos dólares
• Compressão de entidades com um dicionário canônico: 1.213 variações de nomes de projetos foram reduzidas a 81 projetos canônicos (15 vezes menos)
• Velocidade do pipeline híbrido: 13 ms para um resultado ranqueado via FTS5 sobre 538.956 mensagens, e 87 ms para um JOIN de grafo em dois saltos

Depois de um ano operando meu próprio sistema de memória, resumi a diferença entre as duas abordagens em uma frase: a busca vetorial responde "me encontre uma citação sobre X", enquanto o grafo responde "me explique como X é estruturado e quem está conectado a ele". Quando você pergunta "quais ferramentas usamos no projeto durante um ano e meio e quem participou", a resposta correta não cabe inteira em nenhum trecho de texto — a busca vetorial retorna três fragmentos aleatórios, e o modelo completa com confiança os 80% restantes do quadro, mesmo que seja invenção.

O famoso estudo da Microsoft Research (`arXiv:2404.16130`), que promete a vitória do GraphRAG em 72% a 83% das comparações pareadas quanto à completude da resposta, está correto, mas com condições de contorno bem rígidas. A medição foi feita em uma tarefa de resumo global do corpus (`query-focused summarization` com 1,0 a 1,7 milhão de tokens), e essa faixa de 72% a 83% inclui a configuração `TS`, que nem usa um grafo — ela faz `map-reduce` direto sobre os textos originais.

Como evitar gastar $1.500 no prompt do sistema ao extrair entidades de

10.019 registros?

Quando me sentei para construir um grafo a partir de 10.019 fichas de conhecimento (5.658 notas de aprendizado, 2.

657 trechos de código, 1.209 discussões e 155 análises de erros), a primeira implementação ingênua quase quebrou o projeto. Parecia natural dividir o corpus em lotes de 200 registros e disparar um agente de linha de comando como subprocesso para cada lote.

A primeira chamada de teste já custou 15 centavos: o cliente CLI recarregava o prompt de sistema, as regras e as descrições das skills a cada início — 117.000 tokens de prefixo de serviço por chamada. Em 49 lotes, isso já representava mais de $7 em desperdício puro, e processar os 10.

019 registros um a um faria a conta passar de $1.500.

Reconstruímos o pipeline: filtramos previamente 287 registros inúteis e lançamos ondas de 5 a 7 subagentes em paralelo dentro de uma única sessão-pai ativa, onde o prefixo já estava em cache. Tentar subir 20 workers de uma vez bateu em um throttling do servidor depois de 411 de 672 tarefas, então fixamos o ponto ideal: IDs de lote estáveis em um manifesto e ondas de até 6 a 8 agentes em paralelo.

Por que operar o grafo é mais caro que construí-lo, e como um

dicionário canônico comprime projetos 15 vezes?

Cada nova onda de extração de entidades traz dezenas de variações de grafia para os mesmos nomes e marcas. Se forem gravadas na base como estão, em um mês um único projeto se transforma em quinze ilhas isoladas dentro do grafo. O único remédio é um dicionário canônico determinístico (`_MAPS`) aplicado antes de gravar na base:

```python def canon(entity_kind: str, raw_name: str) -> str: # Normaliza o nome bruto de uma entidade para sua forma canônica, ou descarta ruído (string vazia) cleaned = (str(raw_name) if raw_name is not None else "").strip() return _MAPS.get(entity_kind, {}).get(cleaned, cleaned) ```

Depois de aplicar os mapas de normalização, 1.213 grafias brutas de projetos foram reduzidas a 81 projetos reais (15 vezes menos), as 2.542 variantes de ferramentas encolheram para 1.

068, as empresas passaram de 1.427 para 1.115, e as pessoas de 783 para 590.

Outras 66 pseudoferramentas e 11 "empresas" abstratas ("Holding", "Biblioteca") foram mapeadas para uma string vazia. De quebra, corrigimos dois erros clássicos: um loop `for t in stack` sobre um campo do tipo string em vez de lista, que havia gerado 96.000 arestas inúteis apontando para letras isoladas do alfabeto (corrigido com uma verificação `isinstance(v, list)`), e uma explosão de autovinculação por correspondência de substring em títulos que produziu 27.

000 conexões falsas (corrigida com um filtro de comprimento mínimo de 5 caracteres e a condição de que uma chave não aparecesse em mais de 4 projetos, o que resultou em 543 arestas `about` precisas).

Quando duas tabelas SQLite são suficientes em vez de um servidor de

grafo dedicado?

A primeira versão do nosso grafo vivia em um servidor com FalkorDB (construído sobre Redis e GraphBLAS). Ali descobrimos que o dialeto Cypher não suporta regex `=~` nem `shortestPath()` não direcionado, e por causa do conector MCP desativado e da necessidade de manter um túnel SSH, um grafo com 4.743 nós ficou completamente desconectado dos agentes por 7 semanas.

Transferimos todo o grafo para um arquivo SQLite local de 15 MB, composto por duas tabelas (`nodes` e `edges`). Na escala de 5.237 nós e 19.803 arestas, uma consulta SQL comum com dois `JOIN` encontra os principais projetos por número de ferramentas e sessões (o líder tem 277 sessões e 285 ferramentas) em 87 ms, enquanto a busca full-text via FTS5 sobre meio milhão de mensagens responde em 13 ms.

Esse tipo de busca híbrida, sem demônios extras, está incorporado à arquitetura da [Nomad AI](https://nomadnet.ai) e da plataforma em nuvem [agent.nomadnet.ai](https://agent.nomadnet.ai). É possível aprender a construir RAGs e grafos de conhecimento de nível profissional na [Hamidun Academy](https://academy.hamidun.com) (com teste gratuito de 72 horas disponível), e os scripts de canonização estão disponíveis no [Vibe Club](https://hamidun.com/club).