O agente citou a fonte certa e ainda errou a resposta: o problema é a lacuna entre os fatos
Por que RAG tradicional falha em decisões condicionais e onde o GraphRAG entra na arquitetura de Agentforce
Um agente pode retornar uma citação perfeita, com a política correta, e ainda tomar a decisão errada. O problema não é a qualidade do dado recuperado, é a conexão que falta entre eles. Isso muda como eu penso arquitetura de retrieval para Agentforce.
Tem um cenário que todo arquiteto que já lidou com agente de IA em produção reconhece na hora: o agente nega uma devolução, você confere a citação, a política de fato diz 90 dias, você confere a compra, ela está fora da janela. Tudo bate. E a resposta está errada mesmo assim.
O cliente tinha direito a uma exceção que o sistema nunca chegou a buscar. A classificação do produto estava no catálogo, a regra de elegibilidade estava numa wiki, o nível de membership do cliente estava no CRM. Cada fato isolado estava correto e acessível. O que faltou foi a costura entre eles.
Esse é o ponto que mais me interessa nesse material da engenharia da Salesforce sobre GraphRAG aplicado a Agentforce: ele não trata de um bug de recuperação de dado impreciso, trata de um problema estrutural de RAG tradicional, que os engenheiros chamam de "flat bag of chunks". Busca vetorial e busca por palavra-chave são ótimas para achar o trecho parecido com a pergunta. O problema é que a pergunta do cliente é sobre uma lavadora quebrada, não sobre classificação de produto ou threshold de membership. O fato decisivo não se parece em nada com a pergunta feita.
O que é multi-hop retrieval, na prática
A saída proposta é combinar RAG com um knowledge graph que conecta entidades e relacionamentos. No exemplo do texto, o produto WM-500 leva à classificação "Major Appliance", que leva à política de devolução estendida, que por sua vez exige checar tier de membership e valor da compra. Isso é multi-hop retrieval: o agente segue relações sucessivas para alcançar contexto que nunca apareceu entre os resultados iniciais de similaridade.
O grafo direciona a busca para os fatos relacionados, o texto (os chunks) continua fornecendo evidência e citação. Uma coisa não substitui a outra.
TBox e ABox: onde a maioria vai quebrar a cara
A parte mais valiosa, na minha leitura, é a separação entre TBox (o blueprint, os tipos de entidade e relacionamento) e ABox (as instâncias reais, esse cliente Gold, essa compra de $899). Se o blueprint nunca representou a exigência de membership como condição da política estendida, não importa quantos registros de cliente você jogar no grafo depois. Você não conserta um blueprint incompleto adicionando mais dados. A revisão de negócio precisa validar a estrutura proposta pela IA antes da extração popular o grafo, porque um erro no TBox se propaga silenciosamente para toda decisão que depende daquela regra.
Tem ainda um terceiro gap, mais sutil: a conexão entre o conceito extraído de conteúdo não estruturado (a entidade no grafo) e o dado estruturado correspondente (a tabela onde está o valor real da compra). Sem um ponteiro explícito entre os dois, o agente precisa inferir esse mapeamento a cada chamada, inspecionando catálogo, schema, tentando achar a entidade certa por nome parecido. Isso é caro e não é confiável. O ideal é resolver essa conexão na preparação, não na hora da requisição.
Se você está desenhando agente de Agentforce para responder pergunta condicional (elegibilidade, exceção comercial, aprovação com regra composta), retrieval baseado só em similaridade de texto vai te entregar exatamente esse tipo de erro: resposta bem citada, decisão errada. Isso importa direto para quem monta a camada de conhecimento que alimenta Agentforce em Revenue Cloud, service ou qualquer fluxo onde a decisão depende de cruzar catálogo, regra de negócio e registro de cliente.
Este é material de engenharia da própria Salesforce sobre a arquitetura de retrieval usada em Agentforce, não é um anúncio de feature nem documentação de produto com nome comercial definido ainda. Trato como conceito de arquitetura validado internamente, aplicável hoje ao desenho de bases de conhecimento e integrações de dados para agentes, mas sem benchmark de performance publicado (o próprio texto é explícito sobre isso).
Antes de sair montando knowledge graph, separe o diagnóstico em três camadas: (1) o contexto recuperado chegou completo ao agente, incluindo a classificação e a regra conectada, ou parou na política geral? (2) o blueprint (TBox) representa a condição de negócio antes de você popular instância, ou você está tentando resolver regra faltante com mais dado? (3) existe ponteiro explícito entre a entidade do grafo e o registro estruturado, ou o agente está inferindo essa ligação a cada chamada?
Essa sequência de perguntas vale tanto para quem está construindo Data 360 com relacionamento entre objetos quanto para quem está pensando em como alimentar Agentforce com contexto de Revenue Cloud, onde regra de elegibilidade comercial frequentemente vive espalhada entre Product Catalog, Pricing Procedure e registro de cliente.
Cuidado com a tentação de achar que "mais dado no grafo" resolve problema de blueprint incompleto. Se a estrutura nunca capturou a condição de negócio (tier de membership, valor mínimo de compra), adicionar registro não cria a regra que falta, só aumenta o volume de instância sem regra aplicada corretamente.
Outro ponto: recuperar toda a evidência necessária não garante que o agente vai interpretar cada condição corretamente. São checagens separadas. Testar só se o dado chegou não é suficiente, você precisa validar se a decisão final bate com a regra de negócio real.
Este conteúdo foi reescrito e analisado editorialmente em português a partir de informações públicas da fonte indicada.