É o terceiro dia de um projeto com uma corretora de seguros de médio porte, e o chefe de operações de sinistros solicita uma ferramenta de chat capaz de responder rapidamente aos reguladores de sinistros. Eles querem que a ferramenta cite as regras mais recentes da apólice, explique exceções e indique a página exata no manual correto. Na mesma reunião, a equipe jurídica acrescenta mais uma restrição: a ferramenta nunca deve exibir conteúdo de um contrato de cliente, a menos que o regulador esteja designado para aquela conta.
É aqui que entra a geração aumentada por recuperação (RAG) específica para o cliente no trabalho de implantação avançada em campo (FDE). O RAG específico para o cliente é uma configuração na qual o sistema de IA responde buscando fatos nas fontes do próprio cliente e, em seguida, redigindo a resposta com base nesses fatos. Ele é específico para o cliente porque as fontes mudam ao longo do tempo e porque é o cliente — e não nós — quem decide o que constitui uma resposta aceitável.
Na prática, não estamos entregando um chatbot genérico. Estamos entregando um fluxo de trabalho de respostas vinculado a documentos reais, permissões reais e resultados de negócios reais. Para a corretora, “correto” significa que a resposta coincide com a versão atual do manual, cita essa versão e respeita as regras de acesso em nível de conta, mesmo quando a pergunta é ambígua.
A estratégia fundamental do FDE é tratar o RAG como um sistema de ponta a ponta, e não apenas como uma funcionalidade. Se pensarmos apenas nos prompts do modelo, deixaremos passar os aspectos que tornam o sistema seguro e confiável em produção. O restante desta lição baseia-se no caso dessa corretora, pois cada decisão tomada afetará diretamente o que o regulador de sinistros vê no momento em que precisa de uma resposta.
Falhas de RAG em produção raramente são dramáticas. Elas costumam ser silenciosas, plausíveis e custosas. O regulador recebe uma resposta que parece correta, age com base nela e, só mais tarde, alguém percebe que o sinistro foi tratado com base na regra errada.
Considere a seguinte situação: a corretora faz o upload de um novo boletim sobre “Exceções para Danos por Água” na segunda-feira. Na quarta-feira, a ferramenta de chat ainda responde usando o manual do mês anterior, pois o pipeline de conteúdo não reprocessou o novo arquivo. Não ocorre nenhum erro, e o sistema pode até citar um número de página real; trata-se apenas do número de página incorreto para o conjunto de apólices atual.
Outra falha comum envolve os limites de acesso. Se a etapa de recuperação consegue acessar um documento, o sistema de IA pode acabar resumindo-o, mesmo que o usuário final não devesse ter acesso a ele. É por isso que as permissões não são apenas um detalhe de interface no RAG. Elas fazem parte do design de recuperação de informações e devem ser aplicadas antes que qualquer texto seja enviado ao modelo.
As falhas silenciosas são outro problema crítico. Uma pergunta como “Podemos dispensar a inspeção se o dano for inferior a 2 mil?” pode exigir uma cláusula de exceção específica. Se o sistema de recuperação não a encontrar, o modelo frequentemente tentará ser útil mesmo assim, preenchendo a lacuna com uma regra de aparência genérica. Sem medição, você não perceberá esse desvio até que a área de negócios reclame.
Explore as principais formas como essas falhas se relacionam com o impacto nos negócios.
Presuma a deriva, comprove a qualidade Se você não está monitorando a qualidade ao longo do tempo, ela já está mudando, mesmo que você ainda não consiga perceber.
Esses modos de falha definem a verdadeira questão do FDE (Framework Design & Evaluation). O que precisamos decidir, e em que ordem, para que o sistema permaneça correto à medida que documentos, usuários e regras mudam?
O trabalho de RAG (Retrieval-Augmented Generation) específico para um cliente é uma cadeia de decisões na qual cada elo altera o que o próximo elo pode fazer com segurança. Se avançarmos diretamente para embeddings ou tamanhos de chunks (fragmentos de texto), acabaremos reescrevendo o sistema mais tarde, quando surgir uma regra de negócio que deveria ter sido um requisito fundamental desde o início.
Comece com requisitos específicos o suficiente para serem testados. Para a corretora, escrevemos critérios de aceitação como “deve citar a seção exata do manual” e “deve recusar a resposta quando o usuário não tiver permissão de acesso”. Esses não são objetivos vagos; são verificações de aprovação/reprovação que podemos transformar em um conjunto de avaliação.
O próximo passo são os dados. Mapeamos as fontes que alimentarão a recuperação de informações e como elas mudam: manuais no SharePoint, comunicados por e-mail, contratos de clientes em uma exportação do CRM. Também mapeamos quem tem permissão para ver o quê, pois esse modelo de permissões moldará a indexação e a filtragem no momento da consulta.
Em seguida, vem o design da recuperação (retrieval). A recuperação é a forma como o sistema seleciona quais trechos de documentos serão apresentados ao modelo. A grande decisão é se podemos filtrar por permissões no momento da consulta ou se precisamos de índices separados por segmento para evitar vazamento de informações. No caso da corretora, os contratos de clientes frequentemente exigem uma filtragem rigorosa, pois um único erro constitui um incidente grave.
O grounding (ancoragem) é o processo que mantém o modelo vinculado ao texto recuperado. Geralmente, inclui regras como “responda apenas com base no contexto fornecido” e “inclua citações”. Também abrange o comportamento do sistema quando o contexto está ausente, como fazer uma pergunta de esclarecimento ou responder “Não encontro essa informação nos documentos de apólice atuais”.
A avaliação é a etapa em que tornamos a confiabilidade mensurável. Uma avaliação consiste em um conjunto repetível de perguntas de teste com comportamentos esperados, executadas antes e depois de alterações. Para esta corretora, priorizamos a precisão das citações, a correção na recusa de acesso a documentos restritos e a cobertura de cenários de sinistros de alto risco.
As decisões de implantação transformam tudo isso em um sistema operacional. Decidimos como a ingestão é executada, com que frequência os índices são atualizados, como registramos as solicitações com segurança e como implementamos as atualizações. A iteração torna-se, então, um ciclo com diretrizes de segurança (guardrails). Quando os analistas de sinistros relatam uma falha, determinamos se ela decorreu de uma lacuna nos dados, na recuperação ou nas instruções, e corrigimos a camada apropriada.
Veja as etapas como um sistema interligado de escolhas.