Escolha entre grafo de conhecimento e RAG

O que é e por que usar

Quando você precisa que um assistente de IA responda perguntas sobre uma base de conhecimento da sua empresa, existem duas abordagens que aparecem em praticamente toda discussão técnica: RAG (Retrieval-Augmented Generation) e grafo de conhecimento (knowledge graph). Muita gente trata isso como “qual é melhor”, mas a pergunta certa é qual resolve o seu problema específico com menos manutenção e mais precisão.

O RAG funciona assim: você fatia seus documentos em pedaços (chunks), transforma cada pedaço em vetor (embedding) e armazena num banco vetorial. Quando chega uma pergunta, o sistema busca os pedaços mais similares semanticamente e injeta no prompt do modelo de linguagem. É rápido de montar, funciona bem com texto não estruturado (manuais, políticas, e-mails, contratos) e não exige modelagem prévia. A limitação aparece quando as respostas dependem de relacionamentos explícitos entre entidades —”quem aprova o quê”, “qual regra se aplica a qual combinação de condições” — ou quando a pergunta exige raciocinar em múltiplos saltos.

Já o grafo de conhecimento modela entidades (pessoas, produtos, normas, países) e as arestas que as conectam com semântica definida (APROVA, PROÍBE, SUBSTITUI, APLICA-SE-A). A recuperação acontece via consultas estruturadas — em geral Cypher, no Neo4j, ou SPARQL em grafos RDF — e a resposta é o resultado de uma travessia determinística. Isso traz auditabilidade, precisão e explicação do caminho de raciocínio, mas exige curadoria: alguém precisa definir o esquema e manter as relações atualizadas.

Na prática, projetos maduros quase sempre terminam em GraphRAG (grafo + vetorial), mas decidir o ponto de partida importa porque o custo de modelagem e o tempo até o primeiro resultado são muito diferentes. Este artigo mostra como escolher com base no tipo de pergunta que o seu usuário vai fazer.

Pré-requisitos

• Noção de embeddings e busca vetorial — saber o que é similaridade de cosseno e por que chunking afeta o recall.
• Um LLM acessível via API — OpenAI, Anthropic, Gemini ou um modelo local via Ollama (ex.: Llama 3.1 8B).
• n8n instalado — self-hosted em Docker ou cloud. Versão 1.40 ou superior para os nós de AI Agent e Vector Store estáveis.
• Banco de dados — PostgreSQL 15+ com a extensão pgvector para o lado vetorial, e Neo4j 5.x (Community serve) para o lado de grafo.
• Conhecimento básico de Cypher ou SQL — o suficiente para ler e ajustar consultas prontas.
• Uma pasta com documentos reais — 20 a 200 arquivos já é suficiente para o primeiro teste de decisão.

Exemplo Prático: consultoria regulatória de defensivos para exportação agrícola

O cenário

A Cerrado Verde Exportadora vende soja, café e laranja para União Europeia, China e Estados Unidos. Três agrônomos de campo usam um assistente interno para tirar dúvidas do tipo: “Posso aplicar o produto X na lavoura de café que vai para a União Europeia? Qual o período de carência se aplicar no estágio de floração?”

Hoje eles perdem cerca de 40 minutos por consulta cruzando PDFs de agências reguladoras (ANVISA, EFSA, EPA), bulas de fabricantes e uma planilha interna de limites máximos de resíduo (LMR). O objetivo é responder em menos de 30 segundos, sempre com a fonte citada.

Por que esse caso expõe a diferença

Existem duas categorias de perguntas aqui:

• Perguntas abertas — “O que mudou na regulamentação europeia sobre resíduos em 2024?” → RAG resolve bem.
• Perguntas relacionais — “Quais defensivos podem ser aplicados no café exportado para a UE que tenham carência menor que 30 dias?” → exige cruzar ativo × cultura × país × LMR × carência. RAG tende a devolver chunks soltos e o modelo “cola” informações erradas.

A decisão da Cerrado Verde foi começar por um grafo de conhecimento porque 70% das consultas dos agrônomos são relacionais e envolvem risco regulatório (multa, apreensão de carga). Erro não é aceitável.

Resultado esperado

Um fluxo no n8n exposto como webhook, que recebe { cultura, pais, ativo } e retorna: se é permitido, o LMR aplicável, o período de carência e o link da norma que sustenta a resposta. Tempo alvo: menos de 3 segundos, com trilha auditável de qual documento originou a relação.

Configuração Passo a Passo

1. Modelagem do grafo (Neo4j)

Defina quatro tipos de nó e três tipos de aresta. Comece pequeno:

// Nós
(:Ativo {nome, cas_number})
(:Cultura {nome, grupo})
(:Pais {codigo, nome})
(:Norma {id, orgao, url, data_vigencia})

// Arestas
(:Ativo)-[:PERMITIDO_EM {lmr_mg_kg, carência_dias}]->(:Cultura)
(:Cultura)-[:EXPORTADA_PARA]->(:Pais)
(:Norma)-[:REGULAMENTA]->(:Ativo)

Carregue os dados iniciais via LOAD CSV. Um arquivo permissoes.csv com 400 linhas cobre o piloto.

2. Configuração da consulta Cypher que responde a pergunta real

MATCH (a:Ativo {nome: $ativo})-[p:PERMITIDO_EM]->(c:Cultura {nome: $cultura})-[:EXPORTADA_PARA]->(pa:Pais {codigo: $pais})
MATCH (n:Norma)-[:REGULAMENTA]->(a)
RETURN a.nome AS ativo, c.nome AS cultura, pa.nome AS pais,
       p.lmr_mg_kg AS lmr, p.carencia_dias AS carencia,
       n.url AS fonte, n.data_vigencia AS vigencia

3. Montagem do fluxo no n8n

1. Nó Webhook — Tipo: Webhook. Método POST, path /consulta-regulatoria. Ative “Respond with: Using Respond to Webhook node” para controlar a resposta.
2. Nó Set — Tipo: Edit Fields. Extrai body.ativo, body.cultura, body.pais para campos normalizados.
3. Nó Neo4j — Tipo: Neo4j. Credencial com URI bolt://neo4j:7687. Query: cole o Cypher do passo 2. Parâmetros: use expressões {{ $json.ativo }}, {{ $json.cultura }}, {{ $json.pais }}.
4. Nó If — Tipo: If. Condição: {{ $json.lmr }} não está vazio. Se verdadeiro, segue para resposta positiva; se falso, vai para o nó LLM.
5. Nó Basic LLM Chain (fallback) — Tipo: Basic LLM Chain com OpenAI Chat Model (gpt-4o-mini). Prompt: “Não há regra cadastrada para esta combinação. Explique ao usuário apenas isso.” Isso evita alucinação quando o grafo não tem a resposta.
6. Nó Respond to Webhook — Retorna JSON { permitido, lmr, carencia, fonte, vigencia }.

4. Formato do request e response

POST /webhook/consulta-regulatoria
Content-Type: application/json

{ "ativo": "Tebuconazol", "cultura": "Café", "pais": "UE" }

// Resposta
{
  "permitido": true,
  "lmr_mg_kg": 0.05,
  "carencia_dias": 21,
  "fonte": "https://efsa.europa.eu/reg-2023-1042",
  "vigencia": "2023-09-01"
}

5. Teste e comparação com RAG

Antes de descartar o RAG, rode as mesmas 30 perguntas nos dois sistemas. Documente taxa de acerto, tempo de resposta e necessidade de intervenção humana. Na Cerrado Verde, o grafo acertou 28/30 e o RAG com pgvector acertou 17/30 — principalmente porque o RAG misturava normas antigas (revogadas) com as vigentes, já que embeddings não entendem vigência temporal.

Dicas e Variações

• Use GraphRAG híbrido quando ambos os tipos de pergunta convivem. No n8n, encadeie um classificador (nó Switch + LLM) que decide se a pergunta é relacional (vai ao Neo4j) ou exploratória (vai ao vector store).
• Adicione propriedades temporais nas arestas. Guarde vigencia_inicio e vigencia_fim em PERMITIDO_EM para responder “o que valia em 2022”.
• Sempre devolva a fonte. Se a resposta não citar o nó Norma, o usuário não vai confiar — e em contexto regulatório isso é fatal.
• Mantenha um cache no Redis para as combinações mais consultadas (as 20% que geram 80% das perguntas). Reduz latência para menos de 200 ms.
• Comece com perguntas de leitura, não de escrita. Deixe a atualização do grafo para uma segunda fase, via formulário no próprio n8n.

Erros Comuns e Como Evitá-los

1. Escolher grafo por moda. Se 80% das suas consultas são “resuma este documento”, você só vai criar trabalho. Faça o inventário de perguntas reais antes de decidir.
2. Chunking errado no RAG e culpar a técnica. Chunks de 200 tokens cortam tabelas ao meio. Para documentos regulatórios, use 800–1200 tokens com sobreposição de 150 e preserve estrutura de tabela.
3. Ignorar versionamento no grafo. Normas mudam. Se você sobrescreve arestas, perde o histórico e qualquer auditoria.
4. Deixar o LLM gerar Cypher sem validação. Cypher gerado pode fazer varredura completa em grafo grande. Sempre sanitize e use parâmetros, nunca concatenação de string.
5. Não medir. Defina uma métrica antes: “percentual de respostas corretas verificadas por um especialista em 30 perguntas”. Sem isso, você troca de arquitetura por intuição.

Próximos Passos

Se você chegou até aqui, faça isto nesta semana, em ordem:

1. Liste as 30 perguntas mais frequentes que seu time faz hoje. Classifique cada uma como “aberta” ou “relacional”.
2. Se mais de 50% forem relacionais, monte um grafo piloto com 3 tipos de nó no Neo4j e conecte ao n8n seguindo o passo a passo acima.
3. Rode as 30 perguntas nos dois pipelines e registre a taxa de acerto numa planilha simples.
4. Se o resultado ficar equilibrado, migre para GraphRAG híbrido: mantenha o vector store para perguntas exploratórias e o grafo para as transacionais.

Quer acelerar? Baixe o template do fluxo n8n usado neste artigo, com os nós Webhook, Neo4j, If e Basic LLM Chain já conectados, e troque apenas as credenciais e o esquema do grafo pelos da sua área. Em uma tarde você tem a resposta empírica sobre qual arquitetura faz sentido para o seu caso — sem achismo.