A geração aumentada de recuperação (RAG) tornou-se o padrão de fato para fundamentar grandes modelos de linguagem (LLMs) em dados privados. A arquitetura padrão – agrupar documentos, incorporá-los em um banco de dados vetorial e recuperar os k resultados principais por meio de similaridade de cosseno – é eficaz para pesquisa semântica não estruturada.
No entanto, para domínios empresariais caracterizados por dados altamente interligados (cadeia de abastecimento, conformidade financeira, deteção de fraudes), o RAG apenas vetorial falha frequentemente. Ele captura semelhança mas sente falta estrutura. Ele enfrenta questões de raciocínio multi-hop como: “Como o atraso no Componente X afetará nossa entrega do terceiro trimestre para o Cliente Y?” porque o armazenamento de vetores não “sabe” que o Componente X faz parte da entrega do Cliente Y.
Este artigo explora o padrão RAG aprimorado por gráfico. Com base na minha experiência na construção de sistemas de registro de alto rendimento na Meta e na infraestrutura de dados privados na Cognee, percorreremos uma arquitetura de referência que combina a flexibilidade semântica da pesquisa vetorial com o determinismo estrutural dos bancos de dados gráficos.
O problema: quando a pesquisa vetorial perde o contexto
Os bancos de dados vetoriais são excelentes na captura de significado, mas descartam a topologia. Quando um documento é fragmentado e incorporado, os relacionamentos explícitos (hierarquia, dependência, propriedade) geralmente são nivelados ou totalmente perdidos.
Considere um cenário de risco na cadeia de abastecimento. Embora este seja um exemplo hipotético, ele representa a classe exata de problemas estruturais que vemos constantemente nas arquiteturas de dados empresariais:
-
Dados estruturados: Um banco de dados SQL que define que o Fornecedor A fornece o Componente X à Fábrica Y.
-
Dados não estruturados: Uma reportagem afirmando, “As inundações na Tailândia interromperam a produção nas instalações do Fornecedor A.”
Uma pesquisa vetorial padrão por “riscos de produção” recuperará a reportagem. No entanto, provavelmente falta o contexto para vincular esse relatório à produção da Fábrica Y. O LLM recebe a notícia, mas não consegue responder à questão crítica do negócio: “Quais fábricas a jusante estão em risco?”
Na produção, isso se manifesta como alucinação. O LLM tenta preencher a lacuna entre a notícia e a fábrica, mas não possui o link explícito, o que o leva a adivinhar relações ou a retornar uma resposta “Não sei”, apesar dos dados estarem presentes no sistema.
O padrão: recuperação híbrida
Para resolver isso, passamos de uma arquitetura “Flat RAG” para uma arquitetura “Graph RAG”. Isso envolve uma pilha de três camadas:
-
Ingestão (a lição “Meta”): Na Meta, trabalhando na infraestrutura de registro do Shops, aprendemos que a estrutura deve ser aplicada na ingestão. Você não pode garantir análises confiáveis se tentar reconstruir posteriormente a estrutura a partir de logs confusos. Da mesma forma, no RAG, devemos extrair entidades (nós) e relacionamentos (arestas) durante a ingestão. Podemos usar um modelo LLM ou de reconhecimento de entidade nomeada (NER) para extrair entidades de blocos de texto e vinculá-los a registros existentes no gráfico.
-
Armazenar: Usamos um banco de dados gráfico (como Neo4j) para armazenar o gráfico estrutural. Os embeddings de vetores são armazenados como propriedades em nós específicos (por exemplo, um nó RiskEvent).
-
Recuperação: Executamos uma consulta híbrida:
Implementação de referência
Vamos construir uma implementação simplificada deste analisador de risco da cadeia de suprimentos usando Python, Neo4j e OpenAI.
1. Modelando o gráfico
Precisamos de um esquema que conecte nossos “eventos de risco” não estruturados às nossas entidades estruturadas de “cadeia de suprimentos”.
2. Ingestão: estrutura de ligação e semântica
Nesta etapa, assumimos que o gráfico estrutural (fornecedores -> fábricas) já existe. Ingerimos um novo “evento de risco” não estruturado e o vinculamos ao gráfico.
3. A consulta de recuperação híbrida
Este é o principal diferencial. Em vez de apenas retornar os k pedaços principais, usamos Cypher para realizar uma pesquisa vetorial para encontrar o evento e, em seguida, percorrer para encontrar o impacto posterior.
A saída: em vez de um pedaço de texto genérico, o LLM recebe uma carga estruturada:
[{‘issue’: ‘Severe flooding…’, ‘impacted_supplier’: ‘TechChip Inc’, ‘risk_to_factory’: ‘Assembly Plant Alpha’}]
Isso permite que o LLM gere uma resposta precisa: “A inundação na TechChip Inc coloca a planta de montagem Alpha em risco.”
Lições de produção: latência e consistência
Mover essa arquitetura de um notebook para produção exige lidar com compensações.
1. O imposto de latência
As travessias de gráficos são mais caras do que pesquisas simples de vetores. Em meu trabalho de experimentação de imagens de produtos na Meta, lidamos com orçamentos de latência rígidos, onde cada milissegundo impactava a experiência do usuário. Embora o domínio fosse diferente, a lição arquitetônica se aplica diretamente ao Graph RAG: você não pode se dar ao luxo de calcular tudo na hora.
Mitigação: Usamos cache semântico. Se um usuário fizer uma pergunta semelhante (semelhança de cosseno > 0,85) a uma consulta anterior, exibiremos o resultado do gráfico em cache. Isso reduz o “imposto gráfico” para consultas comuns.
2. O problema da “borda obsoleta”
Em bancos de dados vetoriais, os dados são independentes. Em um gráfico, os dados são dependentes. Se o Fornecedor A parar de fornecer a Fábrica Y, mas a borda permanecer no gráfico, o sistema RAG alucinará com segurança um relacionamento que não existe mais.
Mitigação: Os relacionamentos gráficos devem ter Time-To-Live (TTL) ou ser sincronizados por meio de pipelines Change Data Capture (CDC) da fonte da verdade (o sistema ERP).
Quadro de decisão de infraestrutura
Você deve adotar o Graph RAG? Aqui está a estrutura que usamos na Cognee:
-
Use RAG somente vetorial se:
-
O corpus é plano (por exemplo, um Wiki caótico ou um despejo do Slack).
-
As perguntas são amplas (“Como faço para redefinir minha VPN?”).
-
Latência <200ms é um requisito difícil.
-
-
Use RAG aprimorado por gráfico se:
-
O domínio é regulamentado (finanças, saúde).
-
“Explicabilidade” é necessária (você precisa mostrar o caminho de travessia).
-
A resposta depende de relacionamentos multi-hop (“Quais subsidiárias indiretas são afetadas?”).
-
Conclusão
O RAG aprimorado por grafos não é um substituto para a pesquisa vetorial, mas uma evolução necessária para domínios complexos. Ao tratar sua infraestrutura como um gráfico de conhecimento, você fornece ao LLM algo que ele não pode alucinar: a verdade estrutural do seu negócio.
Daulet Amirkhanov é engenheiro de software na UseBead.
Bem-vindo à comunidade VentureBeat!
Nosso programa de guest posts é onde especialistas técnicos compartilham insights e fornecem análises profundas, neutras e não adquiridas, sobre IA, infraestrutura de dados, segurança cibernética e outras tecnologias de ponta que moldam o futuro das empresas.
Leia mais do nosso programa de guest post – e confira nosso diretrizes se você estiver interessado em contribuir com um artigo de sua autoria!
