A Resposta Curta
O Grounding diferencia um agente que cita uma política aprovada de um que gera algo que soa correto. No Agentforce, a camada de Grounding é composta por quatro componentes construídos em ordem: quais fontes são declaradas como fonte da verdade, como o conteúdo é dividido em “chunks” e taggeado para recuperação, como as permissões do usuário são mantidas no momento da recuperação e o que acontece quando nenhuma fonte adequada é encontrada.
A maioria das falhas que observamos em pilotos não são falhas do modelo. São falhas de uma base de conhecimento que ninguém gerencia há dois anos, de documentos divididos no meio de uma tabela e da ausência de um caminho de Fallback. Portanto, o trabalho começa com a avaliação da prontidão do conteúdo, e não com a elaboração de instruções.
O contexto mais amplo para a seleção de casos de uso é abordado em Agentforce para Empresas.
As Quatro Camadas de Grounding
| Camada | O que é definido nela | Sinal de que está quebrada | Evidência de que funciona |
|---|---|---|---|
| Fontes | Quais bases de dados são declaradas como fonte da verdade e quem as possui | Duas respostas contraditórias para a mesma pergunta | Lista de fontes com Proprietário e data de revisão |
| Representação | Chunking, Metadata e tagueamento por produto, idioma e versão | O trecho recuperado não está relacionado à pergunta | Recall medido em um conjunto de perguntas conhecidas |
| Permissões | Como o contexto do usuário restringe a recuperação | Conteúdo interno aparece na resposta ao cliente | Teste de Persona para cada nível de permissão |
| Transparência | Citations, Freshness e caminho de Fallback | Resposta sem fonte e sem reconhecimento de falta de conhecimento | Porcentagem de respostas com citação válida |
Camada 1: Declaração de Fontes da Verdade
O primeiro passo não é técnico. Pega-se as vinte perguntas mais frequentes no processo selecionado e, para cada pergunta, identifica-se onde a resposta correta está atualmente localizada. O resultado é quase sempre surpreendente: algumas respostas estão em um artigo de Knowledge, algumas em um campo de CRM, algumas em um documento em posse de um gerente de equipe e algumas na mente de dois funcionários experientes.
Cada fonte inserida deve ter um proprietário nomeado, uma frequência de atualização acordada e uma data da última revisão. Uma fonte sem proprietário, em questão de meses, torna-se uma fonte de informações desatualizadas, e o agente continuará a citá-la com confiança. Fontes sem proprietário ficam de fora, mesmo que sejam ricas em conteúdo.
A decisão difícil é o que não conectar. Bases de e-mails, canais de chat e apresentações de vendas parecem minas de ouro, mas acabam sendo uma fonte primária de respostas incorretas, pois não distinguem entre rascunho, proposta rejeitada e política aprovada.
Os fundamentos da limpeza e preparação da base de conhecimento são detalhados em Prontidão de Knowledge para Agentforce.
Camada 2: Chunking, Metadata e Relevância
Uma boa recuperação depende menos do modelo e mais da forma como o conteúdo é fragmentado. A divisão por um número fixo de caracteres destrói tabelas, listas de etapas e critérios de elegibilidade – exatamente o tipo de conteúdo do qual derivam respostas precisas. É preferível dividir por estrutura: um subtítulo, uma etapa de processo ou uma linha de tabela que é mantida intacta com seu contexto.
Metadata é o que permite reduzir o espaço de busca antes mesmo que o modelo entre em ação. Tagueamento mínimo a ser exigido: produto ou linha de serviço, mercado ou país, idioma, público-alvo (cliente ou interno), data de validade e status de aprovação. Sem tagueamento de mercado e idioma, um agente em uma organização global misturará políticas de dois países na mesma resposta.
A verificação de relevância é quantitativa e não subjetiva: constrói-se um conjunto de 50 a 100 perguntas reais com a resposta correta e a fonte certa, e mede-se em quantos casos o trecho correto apareceu na recuperação. Uma baixa pontuação de Recall indica um problema de representação, e tratá-lo é muito mais barato do que substituir o modelo ou reescrever as instruções.
Camada 3: Permissões no Momento da Recuperação
Esta é a camada que causa falhas em pilotos durante auditorias de segurança. A regra é simples: a recuperação deve ocorrer no contexto das permissões do usuário, não no contexto de uma conta de integração ampla. Se um trecho de informação estivesse oculto do usuário na interface, ele também deve estar oculto na resposta do agente.
Na prática, são necessárias três verificações. Primeiro, o mapeamento entre os níveis de classificação na fonte externa e os Profiles e Permission Sets no Salesforce. Segundo, o teste de Persona: executa-se as mesmas dez perguntas na identidade de um representante, gerente e cliente externo e compara-se as respostas. Terceiro, o tratamento de conteúdo misto – um documento que é em sua maioria público e tem um parágrafo sensível deve ser dividido ou não incluído.
Em um canal público, o padrão seguro é uma lista de permissão (whitelist): apenas o conteúdo explicitamente marcado como aprovado para o cliente é incluído no índice disponível para o agente externo. Uma abordagem de lista de bloqueio (blacklist) sempre deixará passar um documento.
O modelo de responsabilidade entre a organização, a Salesforce e o provedor do modelo é detalhado em Segurança e Responsabilidade Compartilhada do Agentforce.
Camada 4: Citations, Freshness e Fallback
Esses três mecanismos transformam um agente de um sistema opaco em um sistema auditável. Uma citação verdadeira aponta para o trecho efetivamente recuperado, não para um artigo que o modelo menciona no texto – essa é a diferença entre evidência e ornamento. A porcentagem de respostas com citação válida é uma das poucas métricas que um gerente não técnico pode ler e entender.
Freshness exige um SLA escrito: políticas de preços revisadas trimestralmente, procedimentos de serviço semestralmente, conteúdo regulatório imediatamente após a alteração. O conteúdo que passou da sua data de validade deve ser removido automaticamente do índice e não permanecer até que alguém perceba o erro.
Fallback é o comportamento mais importante a ser testado antes da exposição a clientes. O agente deve dizer explicitamente que não possui informações aprovadas e encaminhar, em vez de formular uma resposta provável. Uma boa pergunta para testar: perguntar sobre um produto inexistente e ver se o agente inventa termos de serviço para ele.
Cenário: Uma Seguradora com 900 Artigos de Knowledge
Uma seguradora queria um agente para responder a representantes de call center sobre termos de apólice. O piloto inicial falhou: 40% das respostas estavam incorretas ou incompletas. A análise mostrou que todo o problema estava na camada de fontes — dos 900 artigos, 380 não eram atualizados há mais de três anos, e 60 deles contradiziam artigos mais recentes sobre o mesmo tópico.
A equipe não tocou no modelo. Reduziu o índice para três produtos principais, apenas cerca de 140 artigos, nomeou proprietários para cada linha de produto e arquivou os que eram contraditórios. Adicionou tagueamento de produto, ano da versão e status de aprovação, e passou a dividir por seção em vez de por comprimento fixo.
A segunda rodada no mesmo conjunto de 80 perguntas de teste alcançou uma precisão muito maior e, mais importante, nos casos em que não havia fonte, o agente encaminhou para uma pessoa em vez de adivinhar. A conclusão que levou à expansão não foi "a IA melhorou", mas sim "sabemos em que ela se baseia".
Riscos e Ações Preventivas
| Risco | Como é detectado tardiamente | Ação preventiva |
|---|---|---|
| Fontes contraditórias | Respostas diferentes para a mesma pergunta entre representantes | Arquivamento de versões antigas e uma única fonte da verdade para cada tópico |
| Chunking que destrói a estrutura | Respostas incompletas em processos multifásicos | Chunking por seção, mantendo o título do contexto |
| Permissões de nível de integração | Exposição de conteúdo interno em canal do cliente | Recuperação no contexto do usuário e testes de Persona |
| Sem data de validade | Citação de política já revogada | SLA para atualização e remoção automática do índice |
| Fallback não definido | Formulação de resposta convincente sem fonte | Caminho de "nenhuma informação aprovada" testado em cada versão |
Métricas para a Camada de Grounding
| Métrica | Definição | Frequência |
|---|---|---|
| Retrieval recall | Porcentagem de perguntas para as quais o trecho correto foi recuperado | Em cada versão |
| Validade da citação | Porcentagem de respostas com fonte existente e válida | Semanal |
| Freshness do conteúdo | Porcentagem de artigos no índice dentro da data de validade | Mensal |
| Taxa de Fallback | Porcentagem de encaminhamentos para pessoas na ausência de fonte | Semanal |
| Vazamento de permissões | Número de ocorrências de exposição em testes de Persona | Em cada versão |
Uma alta taxa de Fallback não é um fracasso – é um mapa de lacunas de conteúdo. A lista de perguntas que levaram ao Fallback é a melhor prioridade para escrever novos artigos.
Quando falta capacidade interna para estabelecer uma camada de Grounding controlada, o serviço de Agentforce e IA é o caminho prático a seguir.
Checklist Antes de Conectar um Agente a Fontes
- ☐ As vinte perguntas mais frequentes foram mapeadas para a fonte da resposta atual
- ☐ Cada fonte no índice tem um proprietário nomeado e uma frequência de atualização
- ☐ Fontes contraditórias foram identificadas e arquivadas
- ☐ Existe tagueamento de produto, mercado, idioma, público e data de validade
- ☐ O Chunking preserva tabelas e listas de etapas
- ☐ A recuperação ocorre no contexto das permissões do usuário
- ☐ Um teste de Persona foi realizado para cada nível de permissão relevante
- ☐ Existe um conjunto de teste com 50 perguntas com resposta e fonte corretas
- ☐ As Citações apontam para o trecho efetivamente recuperado
- ☐ Um caminho de Fallback é formulado e testado no canal do cliente