Manter Knowledge Graph: 3 padrões de quebra

Quem já colocou um Knowledge Graph em produção sabe uma coisa que raramente aparece em post de LinkedIn: o custo real fica todo na manutenção. Construir é a parte barata; o que consome tempo é manter o bicho vivo enquanto tudo em volta muda.

Escrever no grafo dá pouco trabalho. Ler dele, também. A evolução de schema é o inimigo silencioso.

Montei um KG pessoal a partir do conteúdo de kenimoto.dev: cerca de 200 posts em quatro idiomas, mais tags, mais entidades extraídas com LLM, tudo em Obsidian com plugin de grafo. Construir levou um fim de semana. Manter, três meses depois, ainda consome mais tempo por semana do que escrever posts novos. E o culpado é o próprio formato, não a minha falta de disciplina.

O que os cases da Meta e do LinkedIn deixam de fora

Os dois cases de KG empresarial mais citados:

• Meta (abril 2026): mais de 50 agentes de IA especializados subiram a cobertura de contexto de ~5% para 100% em pipelines espalhados por 4.100+ arquivos. Chamadas de ferramenta caíram 40%.
• LinkedIn: KG + RAG sobre tickets de suporte, mediana do tempo de resolução caiu 28,6% e MRR melhorou 77,6% em seis meses.

Os números impressionam. Só que nenhum dos dois relatos toca no que acontece no mês 7, quando alguém do time de dados resolve renomear uma entidade e metade das arestas fica órfã. Ou quando a ontologia precisa acomodar um tipo de nó que ninguém previu e o índice inteiro tem que ser reconstruído.

O trecho “seis meses em operação” do case LinkedIn é o pedaço que virou artigo. Os primeiros seis meses também aconteceram; ninguém escreve o post sobre eles.

Três formas do KG quebrar depois que está rodando

Os padrões que vi (uns no meu KG pessoal, outros em conversa com quem opera KG maior):

1. Renomear uma propriedade e não notar

Você decide que authoredBy é um nome ruim e troca por writtenBy. O código de escrita novo usa o nome novo. As queries de leitura antigas continuam esperando o velho. O Neo4j não avisa: retorna resultados vazios para as queries antigas, e você só descobre quando algum dashboard começa a mostrar zero.

A solução no papel é migrar em duas fases: escrever nos dois campos e, depois de N semanas, remover o antigo. Na prática, a fase dois quase nunca acontece. O KG acumula três nomes para a mesma coisa e ninguém lembra qual é o canônico.

2. Extração via LLM que muda de comportamento entre versões

O cap. 13 do livro fala em “extração automática via LLM” como um dos sete passos de construção. O que fica de fora no capítulo: a mesma tarefa de extração devolve resultado um pouco diferente entre modelos. Basta trocar de família de modelo, ou até de versão dentro da mesma família, para que as entidades voltem iguais no sentido mas com strings um pouco diferentes (“React Native” de um lado, “react-native” do outro; “SEO” virando “search engine optimization” em outra rodada).

Se o pipeline de ingestão faz upsert por string, cada conceito acabou de virar dois. A partir daí, o cluster de “React Native” fica com metade dos posts de um lado e metade do outro, e nenhuma query enxerga o conjunto inteiro.

O que funciona na prática: normalização determinística antes do upsert (lowercase, remoção de acento, mapa de aliases explícito). E fixar a versão do modelo. Trocar de modelo é migração de schema disfarçada.

3. Explosão combinatória de arestas

Você começa com “post → tag” e “post → conceito”. Aí quer “conceito → conceito relacionado”. Aí “autor → tópico de expertise”. E logo depois “post → post similar”.

Cada relação nova é um join a mais em cada query. Depois de três meses, o EXPLAIN de uma query que “só devia percorrer dois hops” mostra o Neo4j fazendo um cartesiano que ele mesmo não sinaliza como cartesiano. A latência p95 sobe de 40ms para 2s, e a culpa cai no hardware.

Por que “criar” parece mais barato

Quando você constrói o KG do zero, todo commit é terreno virgem. Define o schema, ingere, mede. Se algo está errado, reconstrói.

Já com o KG em produção, três coisas mudam de custo:

• Reconstruir do zero deixa de ser de graça. Existem clientes/aplicativos/agentes de IA lendo do índice atual. Reconstruir vira versionar índices em paralelo.
• Toda mudança de schema é migração. Não existe “só adicionar um campo” quando há consumidor lendo.
• A verificação sai de “os testes passam” para “as respostas ainda fazem sentido”. A segunda é bem mais cara de rodar, e ninguém tem test suite pra ela.

O padrão lembra o que acontece com banco relacional depois que passa pra produção. A diferença: schemas relacionais têm 30 anos de ferramenta em volta. Grafo em produção ainda não montou tudo isso.

O que o KG pessoal me ensinou (e as empresas grandes já sabiam)

No meu grafo pessoal com Obsidian + plugin InfraNodus (cap. 14 do livro), a análise de gap estrutural começou útil e virou barulho depois do mês dois. Motivo: continuei adicionando notas sem consolidar aliases, e a “detecção de comunidade” começou a agrupar por acidente de nomenclatura. A semântica ficou fora do processo.

A correção foi burra: parar de adicionar por duas semanas, escrever um script que normaliza aliases, rodar uma vez. Depois disso, as sugestões automáticas de pesquisa voltaram a fazer sentido.

Manter é chato. Ninguém posta sobre isso. Só que, se a decisão entre KG e busca vetorial pura passa pelo TCO real, o custo de manutenção precisa entrar na conta. Esse mesmo eixo é o que faz GraphRAG valer 7x o custo em alguns casos e não valer em outros, e o que faz MCP em 27k tokens perder para KG em alguns cenários e ganhar em outros.

O que eu recomendaria a alguém começando hoje

Coisas que gostaria de ter feito no dia zero:

• Aliases explícitos desde o começo. Um YAML com “React Native” → “react-native” → “RN” apontando todos para o mesmo canonical_id. Custa 30 minutos no início e uma tarde inteira depois.
• Versionar o prompt de extração. Se o modelo mudar, dá para rodar o prompt antigo no modelo novo lado a lado antes de trocar em produção. Sem isso, ninguém sabe o que mudou.
• Um teste de invariante semântico. Pega 20 queries com resposta conhecida e roda toda semana. Se alguma começa a voltar vazia, o KG entrou em drift.

Nenhum dos três é “excitante” o bastante para virar tweet. Foram exatamente os três que teriam me poupado o mês três.

ken imoto · WebRTC & Voice AI engineer · kenimoto.dev · TabNews