RAG no Agentforce vai muito além de ligar o Data 360 numa base vetorial
Chunking mal feito, ausência de reranking e falta de controle de autorização são os erros que transformam um projeto simples em problema de governança.
RAG não é apenas indexar documentos e conectar um LLM, é uma camada inteira de retrieval, avaliação e segurança que precisa ser projetada com cuidado. Sem chunking correto, busca híbrida e controle de autorização por identidade, o Agentforce pode responder com convicção total uma política que não existe.
Toda vez que entro num projeto de Agentforce e o cliente já vem com "quero que ele responda usando nossa base de conhecimento interna", a conversa cai direto em RAG. E metade das vezes o cliente acha que RAG é só ligar o Data 360 numa base vetorial e pronto, o agente vira um oráculo. Não é. Já vi implantação que começou simples, "é só indexar os PDFs de política de RH", e virou um problema sério de governança três meses depois porque ninguém pensou em quem podia ver o quê.
RAG existe porque um LLM sozinho não sabe o que ele nunca viu. Se a política de licença da sua empresa mudou mês passado, ou nunca esteve em lugar nenhum público, o modelo não vai "mentir de propósito", ele vai prever o texto mais plausível com o que ele tem. E isso é exatamente o tipo de resposta fluente, convincente e errada que queima a confiança do usuário no Agentforce na primeira interação ruim.
A mecânica é simples de explicar e complexa de operar bem: o sistema busca em uma fonte de conhecimento indexada, monta o contexto com os trechos mais relevantes e pede pro modelo responder só com base nisso, inclusive instruindo ele a dizer "não sei" quando a evidência não sustenta a resposta. O ganho real de qualidade em produção não vem do modelo, vem da camada de retrieval.
Chunking é onde a maioria erra primeiro
Se você quebra um documento no lugar errado, a regra se separa da condição. O exemplo clássico: uma política diz "colaboradores podem trabalhar remoto até três dias por semana, desde que o gestor aprove e a função não seja voltada ao cliente". Se o corte do chunk fica logo depois de "três dias por semana", o sistema recupera a permissão e descarta a condição. O agente responde com convicção total uma política que não existe.
Existem estratégias diferentes (fixed-size, recursiva, semântica, parent-child) e nenhuma delas é universalmente melhor. Isso se ajusta com avaliação em cima das perguntas reais dos usuários, não copiando o default de um tutorial.
Embeddings, busca híbrida e reranking
Embedding maior não é sinônimo de retrieval melhor, o que importa é a qualidade do treinamento e o encaixe com a tarefa. E um ponto que muita gente esquece: embedding de query e de documento precisam ser compatíveis, idealmente do mesmo modelo.
Busca semântica pega significado, busca por palavra-chave (BM25) pega token exato como número de peça, código de erro, ID de caso. Busca híbrida combina os dois, geralmente com Reciprocal Rank Fusion. E depois entra o reranker, um cross-encoder que reordena os candidatos com mais precisão antes de mandar pro LLM, porque rodar cross-encoder em milhões de documentos direto seria inviável em custo e latência.
RAG não é fine-tuning, e não substitui governança
RAG resolve conhecimento fresco, privado e citável. Fine-tuning resolve estilo, formato e comportamento. São constraints diferentes, e sistemas maduros usam os dois.
Em produção, o que separa demo de produto de verdade é: retrieval com controle de autorização (o usuário não pode recuperar um documento só porque ele existe no índice, a permissão precisa ser aplicada na busca via metadata ligado à identidade), avaliação separada de retrieval e geração (recall, MRR, nDCG de um lado; faithfulness, relevância e correção de citação do outro), observabilidade de verdade (logar query, chunks recuperados, scores, tamanho de prompt, latência) e governança de dados com re-index quando a fonte muda.
Para quem arquiteta soluções de Agentforce e Data 360, isso é o mapa do que separa um piloto bonito de um agente que sobrevive em produção. Muito arquiteto foca energia demais em escolher LLM e pouco em resolver chunking, permissionamento de retrieval e observabilidade, que são exatamente os pontos onde a coisa quebra silenciosamente: o documento certo existe na base, mas nunca chega ao modelo, e ninguém percebe até o usuário reclamar.
Isso também bate direto em decisão de arquitetura no Salesforce: se você está montando um agente que consulta Data 360 ou uma base de conhecimento externa via Agentforce, autorização na hora do retrieval não é feature bônus, é requisito de segurança. Sharing Rule mal pensada em Experience Cloud já causou dor de cabeça suficiente, imagina um agente respondendo com dado que o usuário nem deveria enxergar.
O que mais me chama atenção aqui é como isso valida uma discussão que a gente já vive dentro do ecossistema Salesforce com Agentforce e Data 360: a maturidade de um agente não está na inteligência do modelo, está na engenharia de dados por trás dele. Cliente que quer Agentforce respondendo sobre documentação interna antes de arrumar estrutura de dados, processo de indexação e modelo de permissão está construindo sobre areia, por mais bonito que o demo pareça no dia da apresentação.
- Trate ingestão e query como dois pipelines distintos: a qualidade do índice (chunking, embeddings) define o teto de qualidade da resposta, nenhum prompt esperto conserta um documento mal fatiado.
- Não avalie "a resposta parece boa" como método. Meça recall de retrieval separado da qualidade de geração, e monitore faithfulness e citação como métricas de produto, não só como curiosidade técnica.
- Antes de plugar Agentforce numa base de conhecimento, resolva permissionamento no nível do retrieval, usando metadata de identidade para filtrar o que cada perfil pode ver, e só depois preocupe-se com o polimento da resposta.
- Log tudo: query, chunks recuperados, scores de similaridade e rerank, tamanho de prompt, latência. Sem isso você não consegue reproduzir uma resposta ruim quando o cliente reclamar.
Conteúdo recuperado é input não confiável. Se um documento indexado contém texto tentando instruir o modelo ("ignore instruções anteriores"), isso é uma tentativa de prompt injection, e o sistema precisa tratar esse conteúdo como dado, nunca como instrução. Teste isso adversarialmente antes de ir pra produção, não depois de um incidente.
Outro ponto: contexto demais dilui evidência relevante. Aumentar o top-k retrieved não é sinônimo de resposta melhor, às vezes piora. E cuidado com o discurso de "RAG morreu porque agora tem contexto longo e agentes que buscam sozinhos": bases de conhecimento corporativas costumam ser maiores que qualquer janela de contexto, e um agente construído sobre retrieval fraco continua sendo um agente com retrieval fraco, só que com mais latência.
Este conteúdo foi reescrito e analisado editorialmente em português a partir de informações públicas da fonte indicada.