FAQ como RAG: quando você pode desenhar o próprio corpus

Quando a base de conhecimento que alimenta um sistema de RAG (Geração Aumentada por Recuperação) é uma FAQ escrita pela própria equipe, todo o pipeline se inverte — e isso muda radicalmente a arquitetura. É esse o argumento central de um artigo da série “Enterprise Document Intelligence” no Towards Data Science, assinado por Kezhan Shi.

O problema que a maioria ignora

Poucas semanas depois do lançamento de um chatbot de suporte, os logs revelam um padrão: a maior parte das consultas é variação de umas quinze perguntas. “Como eu cancelo?”, “Posso encerrar a apólice antes do prazo?” e “Como interrompo a cobertura?” são três formas de fazer a mesma pergunta — cuja resposta a equipe de suporte já escreveu, palavra por palavra, anos atrás.

O erro clássico é alimentar essa FAQ pelo mesmo pipeline de embed-and-retrieve usado para PDFs brutos. “Quando a fonte já é pergunta-e-resposta, o RAG precisa tratá-la assim”, resume o autor.

Os quatro tijolos, de cabeça para baixo

Num RAG tradicional, o corpus é herdado (PDFs, escaneamentos, contratos) e o parsing é metade da batalha. Na FAQ, você escreve o corpus. A estrutura é a que você definir. Isso simplifica cada etapa:

• Parsing vira carregamento estruturado: nada de OCR ou reconstrução de layout. Basta um schema simples — identificador, tag, pergunta canônica e resposta curada.
• Recuperação vira cache: os embeddings das perguntas canônicas são calculados uma vez. Cada consulta exige uma única chamada de embedding e uma multiplicação matriz-vetor, com latência de milissegundos.
• Geração fica barata: quando a consulta bate diretamente numa pergunta canônica, a resposta é devolvida verbatim, sem nenhuma chamada ao LLM.

Três desfechos, três custos

O coração do sistema é um classificador que compara a consulta do usuário às perguntas canônicas e devolve um de três desfechos:

• Acerto direto (similaridade alta): devolve a resposta canônica. Zero tokens de LLM.
• Acerto adjacente (similaridade média): usa os pares Q&A mais próximos como exemplos in-context e deixa o modelo adaptar a resposta.
• Erro (sem correspondência): a consulta vai para uma fila de especialistas humanos, que escrevem a resposta canônica — e ela entra na FAQ.

O autor destaca que o limiar para “acerto direto” deve ser conservador (exemplo: 0,92 de similaridade). Um falso acerto direto quebra a confiança do usuário rapidamente: “o bot respondeu a pergunta errada com alta confiança”.

Few-shot dinâmico: a sacada menos óbvia

Em vez de fixar exemplos prontos no prompt do sistema (o “few-shot estático”, que envelhece mal), a FAQ recuperada permite um few-shot dinâmico: os exemplos são os próprios pares Q&A mais próximos da consulta, puxados em tempo de execução. Quando a FAQ muda, os exemplos mudam junto — sem custo adicional.

Isso ainda entrega dois bônus: disciplina de escopo (o modelo não inventa respostas genéricas de internet) e detecção gratuita de contradição (quando a resposta do LLM diverge dos exemplos recuperados, o descompasso aparece nos logs).

A lição para times brasileiros

Para empresas com suporte ao cliente, a mensagem prática é valiosa: se você já tem uma lista de perguntas que os usuários repetem, não jogue essa estrutura fora empurrando tudo por um RAG genérico. A FAQ é a resposta, pré-escrita e pareada com sua pergunta. O sistema deve existir para reaproveitar cada resposta curada milhares de vezes — e para mostrar as lacunas que precisam de um especialista humano, não para inventar respostas plausíveis.