RAG com Grafos de Conhecimento (Híbridos)

O que significa “RAG com Grafo de Conhecimento (Híbridos)”

RAG com Grafo de Conhecimento (Híbridos) (Knowledge Graph RAG (Hybrids)) é uma família de sistemas de geração aumentada por recuperação (retrieval-augmented generation, RAG) que combinam recuperação estruturada (structured retrieval) a partir de um grafo de conhecimento (knowledge graph, KG) com recuperação não estruturada (unstructured retrieval) sobre texto (tipicamente via vetores de incorporação (embeddings) e/ou busca por palavras-chave (keyword search)). O objetivo é obter o melhor dos dois mundos:

Grafos de conhecimento oferecem precisão, restrições e relacionamentos explícitos (ex.: “A reporta para B”, “medicamento trata doença”, “política se aplica à região”).
Corpora não estruturados (docs, tickets, wikis, PDFs) oferecem cobertura e nuance (ex.: explicações, exceções, atualizações mais recentes).

Essa abordagem híbrida é mais útil quando os usuários fazem perguntas que exigem:

Raciocínio de múltiplos saltos (multi-hop reasoning) (seguir relacionamentos entre entidades)
Desambiguação (disambiguation) (qual “Apple” ou qual “John Smith”?)
Respostas fundamentadas com fontes rastreáveis e texto de política atualizado
Junções complexas (complex joins) (filtrar por atributos, tempo, jurisdição, versões)

O RAG com Grafo de Conhecimento é melhor entendido como uma extensão do RAG clássico: em vez de recuperar apenas blocos (chunks) de texto, você também recupera e percorre um grafo estruturado para encontrar as entidades e os relacionamentos certos e, em seguida, usa evidências não estruturadas para justificar e explicar.

Por que combinar recuperação estruturada e não estruturada?

O RAG puramente textual (vetores densos (dense vectors), às vezes combinados com busca esparsa (sparse search)) é forte em correspondência semântica, mas fraco em restrições rígidas (hard constraints):

“Mostre todos os fornecedores na Alemanha que fornecem a peça X e são certificados ISO 27001”
“Quais funcionários da organização A têm acesso ao sistema S por meio de aninhamento de grupos?”
“Quais ensaios sustentam o medicamento D para a condição C no estágio II?”

Essas perguntas geralmente exigem:

Filtragem exata (país=Alemanha)
Travessia de relacionamentos (relationship traversal) (acesso herdado via associação a grupos)
Semântica controlada (controlled semantics) (o que conta como “fornecedor” ou “ensaio”?)

Um grafo de conhecimento codifica essas relações explicitamente. Mas um KG sozinho costuma ser incompleto: os detalhes mais recentes, a justificativa, as exceções e os procedimentos vivem em texto. Daí o híbrido.

Fundamentos teóricos

Grafos de conhecimento em poucas palavras

Um grafo de conhecimento representa informação como entidades e relações.

Dois modelos comuns:

Armazenamentos de triplas RDF (RDF triple stores): fatos são triplas (sujeito, predicado, objeto)
Exemplo: (“Alice”, “works_for”, “Acme Corp”)
Consultados com SPARQL.
Grafos de propriedades (property graphs): nós e arestas têm propriedades
Exemplo: (Alice)-[:WORKS_FOR {since: 2023}]->(Acme)
Consultados com Cypher (Neo4j) ou Gremlin.

KGs se destacam em:

Restrições de esquema/ontologia (tipos, relações permitidas)
Travessia de grafo (graph traversal) (consultas de múltiplos saltos)
Resolução de entidades (entity resolution) (um nó canônico por objeto do mundo real)
Explicabilidade (explainability) (evidência baseada em caminhos)

Fundamentos de recuperação não estruturada

A recuperação não estruturada normalmente usa:

Busca vetorial densa (dense vector search): vetores de incorporação + índice de vizinhos mais próximos aproximados (ANN index) (HNSW, IVF etc.)
Veja Busca Vetorial e Vetores de Incorporação.
Recuperação esparsa (sparse retrieval): correspondência BM25/palavra-chave
Frequentemente combinada via Busca Híbrida (Esparsa + Densa).
Reranqueamento (reranking): codificadores cruzados (cross-encoders) ou reranqueadores baseados em modelo de linguagem grande (LLM) para precisão
Veja Reranqueamento.

O que “híbrido” adiciona, especificamente

Os híbridos de RAG com Grafo de Conhecimento introduzem um segundo canal de recuperação:

Recuperação no grafo: consulta/travessia estruturada retorna entidades, arestas e atributos.
Recuperação de texto: recupera passagens de apoio a partir de documentos.
Fusão (fusion): mescla ambos em um contexto do qual o modelo possa responder com confiabilidade.

Um princípio-chave de design: Use o KG para decidir o que ler; use o texto para decidir o que dizer.

Arquiteturas comuns (padrões)

Na prática, sistemas de RAG com Grafo de Conhecimento geralmente seguem um destes padrões.

1) KG primeiro (Estruturado → Não estruturado → Gerar)

Melhor quando as perguntas implicam restrições, junções ou lógica de múltiplos saltos.

Fluxo:

Converter a pergunta em uma consulta ao grafo (SPARQL/Cypher) ou em uma travessia guiada.
Obter um conjunto candidato de entidades (ex.: fornecedores, políticas, sistemas).
Usar IDs/nomes de entidades como âncoras para recuperar texto de suporte (blocos vinculados a entidades).
Gerar a resposta com citações do texto recuperado e, opcionalmente, caminhos no grafo.

Exemplo: “Quais serviços o Time Alpha possui, e onde está o runbook de plantão?”

Grafo: Time Alpha → OWNS → Serviços
Texto: páginas de runbook anexadas a cada nó de serviço

2) Texto primeiro (Não estruturado → Extração de entidades (entity extraction) → Subgrafo (subgraph) → Gerar)

Melhor quando a pergunta é aberta e você ainda não sabe quais entidades importam.

Fluxo:

Recuperar top-k blocos de texto (híbrido denso/esparso).
Extrair entidades dos blocos recuperados (LLM ou reconhecimento de entidades nomeadas (NER)).
Expandir um subgrafo ao redor dessas entidades (vizinhos, restrições).
Gerar uma resposta usando tanto as passagens originais quanto o subgrafo.

Exemplo: “Por que o projeto Orion atrasou?”

A recuperação de texto encontra postmortems e atualizações de status.
Entidades encontradas: “Orion”, “Fornecedor Z”, “Revisão de compliance”.
A expansão do subgrafo revela: Fornecedor Z → aditivo contratual → data escorregou.

3) Recuperação paralela + fusão tardia (KG || Texto → Reranquear → Gerar)

Melhor quando você quer robustez e velocidade sem planejamento profundo de consultas.

Fluxo:

Executar em paralelo uma estratégia de recuperação no grafo e uma estratégia de recuperação de texto.
Normalizar resultados em um formato comum de “evidência”.
Reranquear e deduplicar evidências.
Gerar a partir das melhores evidências.

Esse padrão combina bem com RAG agentivo (Agentic RAG) (refinamento iterativo se a evidência inicial for fraca).

4) RAG com Grafo iterativo/agentivo (Planejar → Chamadas de ferramenta → Verificar)

Este é um híbrido mais avançado em que o modelo:

decompõe a pergunta,
decide quando consultar o grafo vs. recuperar documentos,
e verifica afirmações intermediárias.

Em geral, ele usa Chamada de Funções/Uso de Ferramentas (Function Calling / Tool Use) e se beneficia de Saídas Estruturadas (Structured Outputs).

Blocos de construção de um sistema de RAG com Grafo de Conhecimento

1) Ingestão e fragmentação em blocos (Ingestion and Chunking) (lado não estruturado)

Você ainda precisa de um pipeline não estruturado sólido:

analisar documentos (PDF/HTML/Markdown),
fragmentá-los adequadamente,
anexar metadados (fonte, timestamps, controle de acesso),
gerar vetores de incorporação para blocos e indexá-los.

Veja Ingestão e Fragmentação em Blocos.

2) Construção do grafo de conhecimento (lado estruturado)

Formas de construir o KG:

A partir de dados estruturados existentes: CMDB, HRIS, CRM, catálogos de produtos
A partir de texto (extração de informação (information extraction)):
- NER/ligação de entidades (entity linking): identificar menções e mapeá-las para entidades canônicas
- Extração de relações (relation extraction): “X owns Y”, “X depends on Y”
- Extração de eventos (event extraction): incidentes, mudanças, aprovações

Em sistemas modernos, LLMs são frequentemente usados para extração, mas você deve lidar com:

resolução de entidades (sinônimos, duplicatas),
governança de esquema (schema governance) (evitar “sopa de relações”),
limiares de confiança e revisão humana para fatos críticos.

3) Vincular blocos de texto a entidades do grafo

Aqui é onde os híbridos ficam poderosos. Adicione arestas como:

(Chunk)-[:MENTIONS]->(Entity)
(Chunk)-[:EVIDENCE_FOR {claim_type:"ownership"}]->(Edge)
(Document)-[:AUTHORED_BY]->(Person)

O vínculo permite recuperações como:

“Obter todos os blocos que mencionam serviços pertencentes ao Time Alpha”
“Encontrar os parágrafos de política que justificam esta regra de acesso”

4) Planejamento e execução de consulta

Um sistema híbrido precisa de um roteador/plano:

A pergunta requer uma consulta ao grafo?
Quais entidades estão envolvidas?
Quais propriedades/relações importam?
Que evidência textual é necessária para fundamentação (grounding)?

Isso pode ser baseado em regras (“se a pergunta contiver ‘quem reporta para’ → grafo”) ou baseado em modelo (LLM decide as chamadas de ferramenta).

5) Fusão de evidências e geração fundamentada (grounded generation)

O gerador deve:

citar passagens de texto recuperadas,
opcionalmente mostrar caminhos do grafo (“A → OWNS → B → RUNBOOK → URL”),
e recusar inventar fatos ausentes.

Veja Fundamentação e Citações.

Exemplo prático: assistente de Operações de TI “Propriedade + Runbook”

Dados

KG (grafo de propriedades):
- Team, Service, Runbook, Person
- arestas: (:Team)-[:OWNS]->(:Service), (:Service)-[:HAS_RUNBOOK]->(:Runbook)
Documentos:
- runbooks e notas de incidentes indexados como blocos
- cada bloco vinculado a Service via MENTIONS ou metadados

Consulta

Usuário: “Quem é o dono da Payments API, e onde está o runbook de escalonamento?”

Etapas

Consulta ao grafo (Cypher):

MATCH (s:Service {name: "Payments API"})<-[:OWNS]-(t:Team)
OPTIONAL MATCH (s)-[:HAS_RUNBOOK]->(r:Runbook)
RETURN t.name AS owner_team, r.url AS runbook_url

Recuperação de texto: recuperar os principais blocos do documento de runbook e notas recentes de incidentes para “Payments API escalation”.
Resposta: combinar fatos estruturados (time proprietário, URL do runbook) com detalhes não estruturados (como escalonar, rotação do pager, ressalvas).

Por que o híbrido ajuda

O KG garante que você não confunda “Payments API” com “Payments UI”.
O texto fornece as etapas reais de escalonamento e quaisquer exceções recentes.

Exemplo prático: literatura biomédica + grafo curado

Cenário: você mantém um KG de relações curadas:

medicamento ↔ alvo
medicamento ↔ indicação
ensaio ↔ desfecho

Mas a evidência vive em artigos e registros de ensaios.

Usuário: “Que evidências sustentam o uso do Medicamento D para a Condição C, e quais foram os desfechos?”

Abordagem híbrida:

O KG identifica ensaios e artigos relevantes (recall estruturado).
A recuperação não estruturada puxa os parágrafos específicos sobre desfechos.
A saída inclui ambos:
- uma lista estruturada de ensaios (fase, população, endpoints),
- passagens citadas descrevendo resultados e limitações.

Esboço de implementação (pseudocódigo estilo Python)

Abaixo está uma arquitetura simplificada mostrando recuperação paralela no grafo + texto, com fusão tardia e reranqueamento.

def answer_question(q: str):
    # 1) Plan
    plan = router.decide(q)  # e.g., {"use_graph": True, "use_text": True}

    graph_hits = []
    if plan["use_graph"]:
        entities = entity_linker.link(q)             # map mentions to entity IDs
        graph_hits = graph_retriever.expand(entities, hops=2, filters=plan.get("filters"))

    text_hits = []
    if plan["use_text"]:
        text_hits = text_index.search(q, k=30)       # dense + sparse hybrid search

    # 2) Evidence linking (optional but powerful)
    # prioritize text chunks that are connected to graph entities
    boosted_text_hits = boost_by_graph_links(text_hits, graph_hits)

    # 3) Rerank
    top_evidence = reranker.rank(q, boosted_text_hits, k=8)  # see reranking article

    # 4) Build grounded context
    context = build_context(graph_hits=graph_hits, text_hits=top_evidence)

    # 5) Generate with citations
    return llm.generate(
        prompt=render_prompt(q, context),
        citations=[hit.source for hit in top_evidence]
    )

Em produção, você também incluiria:

filtragem por lista de controle de acesso (ACL) tanto em nós do KG quanto em documentos,
cache (veja Cache),
observabilidade (tracear qual caminho de recuperação importou).

Tradução de consultas: linguagem natural para consulta ao grafo

Um desafio-chave é mapear perguntas de usuários para consultas ao grafo com confiabilidade.

Abordagens

Modelo + preenchimento de slots (template + slot filling)
Bom para esquemas estáveis e intenções comuns.
Exemplo: “Who owns {service}?” → template Cypher fixo.
Consultas geradas por LLM (LLM-generated queries)
Flexíveis, mas exigem barreiras de segurança (guardrails):
- prompting ciente do esquema,
- validação (parseável? rótulos/relações permitidos?),
- execução somente leitura,
- timeouts e limites (evitar travessias caras).
Híbrido: LLM propõe, sistema valida, fallback para templates.

Exemplo: trecho de prompting ciente do esquema

You can query a Neo4j graph with labels: Team, Service, Runbook.
Relationships: (Team)-[:OWNS]->(Service), (Service)-[:HAS_RUNBOOK]->(Runbook).

Generate a read-only Cypher query that answers:
"Who owns the payments API and where is the escalation runbook?"

Only use allowed labels and relationships.
Return owner_team and runbook_url.

Estratégias de fusão de recuperação (como mesclar KG + texto)

Estratégias comuns incluem:

Recuperação de texto restringida pelo grafo (graph-constrained text retrieval)
Usar resultados do grafo para filtrar/impulsionar texto:
- recuperar apenas blocos vinculados a nós no subgrafo,
- ou adicionar nomes de entidades como termos obrigatórios.
Seleção de evidência baseada em caminho (path-based evidence selection)
Preferir blocos de texto que mencionem explicitamente o mesmo relacionamento da aresta do grafo.
Exemplo: se o KG diz que A owns B, preferir passagens que afirmem propriedade, não apenas que mencionem A e B.
Fusão de pontuações (score fusion)
Combinar pontuações de:
- similaridade vetorial,
- relevância BM25,
- proximidade no grafo (distância do caminho mais curto),
- confiança/atualidade do nó/aresta.
Reranquear com codificador cruzado/LLM
Especialmente útil quando você recupera muitos blocos candidatos.
Veja Reranqueamento.

Aplicações em que híbridos de RAG com Grafo de Conhecimento se destacam

Assistentes de conhecimento corporativo
- organogramas, propriedade, acesso, políticas
- “quem pode aprovar X?” / “de qual sistema Y depende?”
Suporte ao cliente
- grafo de produto (SKU → funcionalidade → compatibilidade)
- manuais e texto de troubleshooting
Segurança e conformidade
- grafos de identidade (usuários/grupos/funções), documentos de política, trilhas de auditoria
- “por que o usuário U tem acesso a S?”
Catálogos de dados
- grafos de linhagem + documentação de datasets
- “quais dashboards dependem desta tabela e o que isso significa?”
Domínios científicos
- KGs biomédicos + artigos, grafos de química + notas de laboratório

Modos de falha e como mitigá-los

1) Ambiguidade de entidade e erros de ligação

Se o sistema vincula “Orion” ao nó de projeto errado, tudo a jusante fica errado.

Mitigações:

manter aliases e IDs canônicos,
exigir desambiguação quando a confiança for baixa,
mostrar entidades candidatas (“Você quis dizer Orion (Projeto) ou Orion (Cliente)?”).

2) Grafo desatualizado vs. texto recente (ou o inverso)

Grafos podem ficar atrás da realidade; documentos podem conter instruções desatualizadas.

Mitigações:

rastrear timestamps e versões,
incorporar “atualidade” (freshness) na pontuação,
preferir fontes oficiais para atributos específicos (proprietário vindo do CMDB, passos vindos do runbook).

3) Confiar demais no KG sem fundamentação textual

O modelo pode declarar fatos estruturados sem explicar ou citar o texto de política relevante.

Mitigações:

exigir ao menos uma citação textual para afirmações críticas,
usar políticas de Fundamentação e Citações (“sem citação → sem afirmação”).

4) Injeção de consulta ao grafo / geração insegura de consultas

Consultas geradas por LLM podem ser caras ou inseguras.

Mitigações:

colocar rótulos/relações em whitelist,
impor consultas somente leitura,
aplicar limites (LIMIT, máximo de saltos),
validar sintaxe e custo estimado.

5) Lacunas de recall devido a extração incompleta

Se relações não foram extraídas para o KG, a recuperação “KG primeiro” pode perder contexto importante.

Mitigações:

manter recuperação não estruturada como fallback,
rodar melhorias periódicas de extração,
usar padrões “texto primeiro” ou de recuperação paralela.

Avaliação: medindo se os híbridos ajudam

Avalie em três níveis:

Qualidade de recuperação
- acurácia de ligação de entidades
- correção da consulta ao grafo (ela retorna os nós certos?)
- recall e precisão de documentos/blocos
Qualidade ponta a ponta de QA
- factualidade (correção em nível de afirmação)
- correção de citações (as citações sustentam a afirmação?)
- completude (faltaram restrições-chave?)
Métricas operacionais
- latência (consulta ao grafo + busca vetorial + custo de reranqueamento)
- estabilidade (timeouts, falhas de consulta)
- manutenibilidade (mudanças de esquema, reindexação)

Um método prático é construir um pequeno conjunto de perguntas “gold” com o esperado:

entidades/caminhos no grafo,
passagens de suporte,
e rubricas para a resposta final.

Dicas de design e boas práticas

Trate o KG como um “plano de controle (control plane)”: propriedade, acesso, relacionamentos, IDs.
Trate o texto como um “plano de evidências (evidence plane)”: explicações, procedimentos, exceções, nuance.
Vincule tudo: blocos ↔ entidades é o tecido conectivo do RAG híbrido.
Mantenha esquemas pequenos e significativos: muitos tipos de relação tornam a tradução de consulta frágil.
Prefira restrições determinísticas quando possível: use o KG para filtrar; use o modelo para resumir.
Use saídas estruturadas para chamadas de ferramenta: esquemas reduzem erros de geração de consulta. Veja Saídas Estruturadas.
Aplique recuperação em camadas: híbrido esparso+denso para texto (Busca Híbrida (Esparsa + Densa)) mais travessia no KG.

Quando você deve (e não deve) usar RAG com Grafo de Conhecimento

Use quando:

relacionamentos importam (propriedade, dependência, hierarquia, elegibilidade),
você precisa de filtragem exata e junções de múltiplos saltos,
seu domínio tem entidades estáveis com IDs (pessoas, ativos, produtos, ensaios).

Evite (ou adie) quando:

seus dados são majoritariamente livres e as fronteiras de entidades não são claras,
você não consegue manter resolução de entidades ou governança de esquema,
um RAG textual simples já atende aos requisitos.

Em muitas equipes, um bom caminho é:

construir primeiro um RAG textual forte,
adicionar um KG pequeno para relações de alto valor (propriedade, dependências),
aprofundar incrementalmente o grafo e os vínculos ao longo do tempo.

Resumo

RAG com Grafo de Conhecimento (Híbridos) combina recuperação estruturada no grafo com recuperação não estruturada em documentos para produzir respostas que sejam ao mesmo tempo precisas (graças a relacionamentos explícitos e restrições) e bem fundamentadas (graças a passagens citadas). O trabalho central de engenharia está em ligação de entidades, vinculação grafo-texto, planejamento de consulta e fusão de evidências — apoiado por componentes robustos de recuperação como vetores de incorporação, busca híbrida e reranqueamento.

Quando feito corretamente, híbridos de RAG com Grafo de Conhecimento viabilizam assistentes confiáveis para domínios em que “apenas buscar algum texto” não é suficiente — porque a parte difícil não é apenas encontrar palavras relevantes, mas também seguir os relacionamentos corretos.