Ontologia e grafo de conhecimento: a arquitetura que faz a IA parar de chutar
O GraphRAG entrega os fatos certos, mas fatos soltos não formam significado. Uma jaqueta "azul", "impermeável", "até R$200", "tamanho M" vira quatro nós no grafo, nenhum deles diz como combinar essas restrições. Sem uma camada de significado explícito (uma ontologia) que defina quais combinatórias são válidas e quais são proibidas, o LLM vai juntar azul e R$100 achando que resolveu, e vai errar. Este post mostra as quatro camadas que transformam grounding em correção: o grafo dá a fundamentação factual, a ontologia impõe as regras de combinação, o orquestrador traduz a intenção numa consulta validada e o LLM vira um verbalizador que só escreve o que já foi verificado. A ordem importa, e pular uma camada é o caminho mais rápido para uma resposta que parece certa mas não está.
O catálogo diz que existe uma jaqueta azul, que existe uma jaqueta impermeável, e que existe uma jaqueta até R$200. Três fatos verdadeiros no grafo. Só que a jaqueta azul custa R$250, a impermeável é tamanho G, e a de R$200 é verde. O grafo não impediu a combinação errada, ele só disse que as três existem.
O post anterior mostrou que o GraphRAG resolve o problema de encadear fatos que nunca aparecem juntos no mesmo parágrafo. Para o exemplo do compliance, ele conecta X, Z, Y e a sanção numa travessia que revela a relação indireta. Mas e quando a pergunta não é sobre existência de uma relação, e sim sobre uma restrição combinatória? A consulta "jaqueta azul impermeável até R$200, tamanho M, com entrega em 2 dias" não pergunta se cada atributo existe isoladamente: ela pergunta qual produto satisfaz todos ao mesmo tempo.
O grafo sabe que existe um nó Cor: Azul, um nó Feature: Impermeável, um nó Preço: R$200, um nó Tamanho: M e um nó Prazo: 2 dias. Ele pode até ligar cada um desses nós a produtos diferentes. Mas ele não sabe, sozinho, que a combinação "Azul + Impermeável + R$200 + M" é um único produto ou uma interseção impossível. O grafo dá a verdade dos fatos, mas não impõe o significado de juntá-los. Esse salto exige uma camada a mais, e é o que este post descreve.
Por que o grafo de conhecimento sozinho não garante o significado
O grafo de conhecimento é excelente para representar fatos atômicos: "A Jaqueta A é azul", "A Jaqueta B é impermeável", "A Jaqueta C custa R$200". Cada afirmação é uma aresta entre um nó de produto e um nó de atributo, e o grafo é fiel aos dados: se o dado diz que a Jaqueta A é azul, a aresta existe; se não diz, não existe. Mas o significado de uma pergunta composta não está nos fatos individuais, está na regra de combinação entre eles. "Azul E impermeável E até R$200 E tamanho M" é uma conjunção lógica, e o grafo não tem operadores lógicos: ele tem nós e arestas. Um LLM que recebe o subgrafo com os três fatos tende a combiná-los mesmo assim, porque a linguagem natural permite essa composição. É o mesmo mecanismo que faz um LLM alucinar uma conexão que não existe no grafo: ele completou o padrão com o que parecia fazer sentido.
O grafo responde "existe um produto azul?" (sim) e "existe um produto impermeável?" (sim), mas não sabe responder "existe um produto que é azul E impermeável?" se essas duas arestas apontam para produtos diferentes. A ausência de uma tripla que una os dois atributos no mesmo sujeito força o LLM a inferir uma combinação que não está representada. O grafo é um modelo de dados baseado em triplas sujeito-predicado-objeto; ele não implementa, por si só, operações de junção entre propriedades de sujeitos distintos. Por isso, sem uma camada que discipline essas combinações, o LLM vai criar ligações falsas.
O grafo diz o que é verdade. Ele não diz o que é permitido combinar. E o LLM, sozinho, vai combinar tudo o que puder.
Ontologia: a gramática dos fatos no grafo de conhecimento
A primeira camada que falta é a ontologia. Uma ontologia é uma especificação explícita das categorias de entidades que existem no domínio e de como elas podem se relacionar. No e-commerce, ela define que Cor, Feature, Preço, Tamanho e Prazo são categorias distintas de atributos, e que um produto pode ter exatamente um valor de cada categoria. A ontologia transforma o grafo de uma coleção de fatos soltos numa estrutura disciplinada: ela não cria novos fatos, mas organiza os existentes e, mais importante, define o que é uma pergunta válida.
Na prática, uma ontologia declara as classes que existem (Produto, Cor, Feature) e as propriedades que ligam umas às outras (temCor, temFeature), e impõe restrições sobre elas: "temCor" liga um Produto a uma Cor, e nada mais; "impermeável" só pode ser atribuída a um produto da classe vestuário externo. Uma consulta que pede "azul, impermeável, R$200, M" é, então, decomposta pela ontologia numa verificação de consistência: existe um produto cujo nó de cor é "Azul", cujo nó de feature inclui "Impermeável", cujo nó de preço está na faixa "até R$200", cujo nó de tamanho é "M", e cujo nó de prazo é "2 dias"? A ontologia valida se todas as categorias estão presentes e se as combinações são permitidas.
Ela também impõe restrições específicas: "Impermeável" só pode ser aplicado a vestuário externo, não a acessórios; "tamanho M" só existe para roupas, não para sapatos. Sem essa gramática, o LLM trata "azul" e "impermeável" como dois adjetivos que podem ser somados livremente. Com ela, a consulta vira uma interseção de conjuntos, não uma soma de adjetivos. A ontologia é o que impede o modelo de juntar azul e R$100 como se fosse uma combinação óbvia, porque ela sabe que essas duas categorias não se misturam sem verificação de produto.
A ontologia é a gramática que impede o modelo de combinar atributos que nunca estiveram juntos. Sem ela, toda pergunta composta é um palpite.
Orquestração semântica: da intenção à consulta validada sobre o grafo
A ontologia organiza os fatos, mas ela não fala diretamente com a pergunta do usuário. Alguém precisa traduzir "jaqueta azul impermeável até R$200" numa consulta que respeite a ontologia. Essa é a função da orquestração semântica, a camada que fica entre o usuário e o grafo.
A orquestração faz três coisas, nessa ordem. Primeiro, lê a pergunta em linguagem natural e separa cada pedaço na categoria certa da ontologia: "azul" é uma cor, "impermeável" é uma feature, "até R$200" é uma faixa de preço, "M" é um tamanho, "2 dias" é um prazo. Depois, ela confere essa combinação contra as regras da ontologia antes de tocar no grafo: as categorias existem, podem coexistir num mesmo produto, e nenhuma viola uma restrição do domínio. Só então monta a consulta ao grafo e a executa. Se a combinação não fecha, a orquestração para ali e devolve um aviso, sem nunca passar a bola pro LLM.
Essa separação é o que distingue um sistema que parece inteligente de um que é confiável. A orquestração não adivinha o que o usuário quis dizer: ela aplica a gramática do domínio para transformar intenção em consulta, e só deixa passar o que é válido. É a ponte que impede o LLM de combinar atributos incompatíveis antes mesmo de ele ver qualquer resultado.
A orquestração semântica é a ponte que impede o LLM de combinar atributos incompatíveis antes mesmo de ele ver o resultado da consulta.
LLM: só escrever o que já foi verificado pelo grafo e pela ontologia
Depois que a orquestração validou a consulta e o grafo devolveu o resultado, o que resta para o LLM fazer é verbalizar. O modelo recebe a resposta estruturada (uma lista de produtos que satisfazem as restrições) e a transforma em linguagem natural. Ele não precisa mais "pensar" sobre a resposta: ela já foi determinada pelas camadas anteriores. Essa é a função mais enxuta e mais rigorosa do LLM num harness bem projetado. O modelo não infere, não completa, não adivinha. Ele só escreve o que já foi verificado.
Na prática, a verbalização funciona assim: o prompt inclui uma instrução explícita, "Com base nos dados fornecidos, escreva uma resposta. Não adicione nenhuma informação que não esteja nos dados." O LLM recebe os fatos como contexto (por exemplo, uma lista formatada de produtos com seus atributos) e gera uma frase ou parágrafo que os descreve. Ainda assim, o modelo pode, por inércia, adicionar um "mais vendido" ou "melhor avaliado" que não está no resultado. Por isso a instrução precisa ser acompanhada de guardrails que bloqueiam inserções não autorizadas, como uma verificação pós-geração que compara a saída com os fatos originais.
O princípio é claro: quando o LLM só verbaliza, o chute estrutural é eliminado. Ele não decide se a jaqueta azul é impermeável: ele escreve que o grafo disse que uma jaqueta específica tem cor azul e é impermeável. O LLM vira um tradutor de dados estruturados para linguagem natural. Quanto mais ele "pensa" sobre a resposta, mais chance de errar.
O LLM vira um tradutor de dados estruturados para linguagem natural. Quanto mais ele "pensa" sobre a resposta, mais chance de errar.
Onde a Pumpkin entra
O harness da Pumpkin sempre colocou o grafo de conhecimento no centro, como o post anterior mostrou. Mas o grafo é só o começo: a engenharia de um agente confiável exige que a gente construa as três camadas ao redor dele, a ontologia que organiza os fatos em categorias coerentes, a orquestração semântica que traduz intenção em consulta validada, e a verbalização controlada que impede o LLM de extrapolar. Cada uma dessas camadas é desenhada para o domínio específico do cliente: a ontologia de um e-commerce é diferente da ontologia de compliance, que é diferente da ontologia de uma seguradora. O que não muda é o princípio: o LLM não decide a resposta, ele só escreve o que foi verificado em cada uma das camadas, e a ordem importa, primeiro o grafo fundamenta, depois a ontologia impõe as regras de combinação, depois a orquestração valida a consulta, e só então o LLM verbaliza.
Formalizado. A representação de conhecimento via ontologias é um campo maduro, com semântica formal definida (Guarino, 1998; Gruber, 1995). A validação de consultas contra restrições de domínio é um algoritmo clássico de inferência em lógica descritiva. O pipeline de orquestração (extração, mapeamento, validação, consulta) segue o padrão de sistemas de perguntas e respostas baseados em conhecimento, com décadas de uso em produção.
Interpretação (consistente, não um teorema fechado). Que a verbalização controlada reduz alucinações a zero é uma prática de engenharia de prompt, apoiada por evidências empíricas, mas não provada formalmente. A afirmação de que a ordem das camadas impede erros combinatórios é um princípio de design, coerente com a teoria de sistemas multiagente, mas sujeita a falhas de implementação (ex.: ontologia incompleta, orquestração com falsos positivos). Apresentamos como modelo mental robusto, não como resultado fechado.
O que é ontologia em um grafo de conhecimento?
Por que o grafo de conhecimento sozinho não garante respostas corretas?
Como a ontologia e o grafo de conhecimento trabalham juntos?
O que é orquestração semântica e qual seu papel?
Qual a diferença entre GraphRAG e ontologia?
Como garantir que o LLM não invente informações ao verbalizar a resposta?
- Guarino, N. Formal Ontology in Information Systems. IOS Press, 1998.
- Gruber, T. Toward Principles for the Design of Ontologies Used for Knowledge Sharing. International Journal of Human-Computer Studies, 1995.
- Hogan, A. et al. Knowledge Graphs. ACM Computing Surveys, 2021.
- Pan, J. Z. et al. Ontology-Driven Knowledge Graphs. Springer, 2024.