5 checagens para não cair na alucinação de IA (e quando usar RAG)

Framework simples para verificar respostas, citar fontes, comparar saídas e decidir entre RAG, busca tradicional e ajuste fino. alucinação IA

Se existe um erro que machuca a confiança do usuário é a resposta que parece perfeita — mas não é. A alucinação não é “maldade” do modelo; é o efeito colateral de um sistema que completa padrões com muita fluência mesmo quando faltam fatos. O antídoto não é desconfiar de tudo, e sim estruturar a conversa para que a IA seja precisa quando precisa e humildade quando não sabe. Nas linhas abaixo eu compartilho cinco checagens simples, de uso diário, e um guia direto para decidir quando RAG entra no jogo e quando ele só complica.

Começo pela checagem da pergunta: o que exatamente você quer como saída? Formato importa. Quando o modelo sabe qual é o objetivo, a audiência e os limites, ele erra menos por “criatividade” e mais por falta de dado real — que é onde queremos chegar. Peça explicitamente linguagem objetiva, delimite escopo (apenas o que está no contexto) e limite de tamanho. Se a tarefa exige precisão factual (por exemplo, doses, datas, códigos), inclua “se não houver evidência, diga que não há” como regra inegociável. Não é enfeite; é o que autoriza a IA a recusar o chute.

A segunda checagem é a de fontes. Sempre que você pedir fatos, peça também referências verificáveis e visíveis. Não aceite “estudos mostram” sem nome, autor e URL. Para material público, um formato simples resolve: marcadores [1], [2] e um bloco “Fontes consultadas” ao final. Para material privado, peça IDs de documento e trechos relevantes. Esse pedido muda o comportamento do modelo de “soar plausível” para “apoiar no que existe”. E, claro, a validação humana é parte do processo: clique nos links que importam e veja se a citação sustenta a afirmação.

A terceira checagem é a de consistência interna. Antes de finalizar, peça um passo de verificação: “liste possíveis contradições com o contexto, lacunas e itens que exigem confirmação humana”. Não é para revelar o raciocínio passo a passo, e sim para produzir um parágrafo curto de autocontrole de qualidade. Se aparecer algo como “dose mencionada acima não está no contexto” ou “não há dado para inferir X”, você acabou de ganhar um radar para erros sutis e um rascunho do que precisa checar fora da IA.

A quarta checagem é a de limites e sensibilidade. Em áreas reguladas ou com risco clínico, incline a balança para respostas conservadoras. Inclua regras como anonimização de dados sensíveis, proibição de inventar nomes comerciais e doses, e um bloco obrigatório de “riscos e limitações”. Quando o sistema se obriga a declarar limites, a chance de extrapolar cai — e a revisão fica objetiva. Esse é um dos “hacks” mais subestimados: instruções de segurança explícitas reduzem a taxa de alucinação praticamente sem custo.

A quinta checagem é a de reprodutibilidade. Se você precisa desse processo todo dia, crie critérios de aceitação que a saída deve passar (sem contradições com o contexto, sem jargão desnecessário, limite de tamanho por seção). Padronize. Quanto mais clara for a régua de aprovação, menos subjetiva fica a revisão. E quando algo escapar, você consegue ajustar a regra, não só reescrever o texto. É assim que um fluxo vira sistema.

E onde entra o RAG? Entra quando o conhecimento que você precisa não está “no ar” ou muda rápido, e quando há uma base documental confiável que deve ser a fonte da verdade. Três sinais de que é caso de RAG: a informação é proprietária (prontuários, políticas internas), é dinâmica (protocolos que atualizam) ou é detalhada demais para depender de memória do modelo (normas, tabelas, códigos). Com RAG, você não pede “o que o modelo sabe”; você pede “o que está nestes documentos”. A saída deve citar arquivos, trechos e, idealmente, IDs que permitem auditar o caminho entre a pergunta e a resposta.

Quando o RAG não ajuda? Para tarefas de opinião, brainstorming criativo, reescrita de tom e revisão estilística, ele é muitas vezes supérfluo e pode até piorar velocidade e custo. Também não vale a pena montar RAG para perguntas genéricas e atemporais que o modelo já responde bem. RAG é uma ferramenta de grounding: use quando há chão para pisar. Sem base boa, ele só dá a impressão de rigor.

Se você quiser um “mini decision tree” para a rotina, guarde assim: pergunta factual + base disponível = RAG; pergunta factual sem base = peça fontes públicas e aceite “não sei” como resposta válida; pergunta de estilo/opinião = sem RAG; pergunta híbrida (fatos + opinião) = RAG nos fatos, criatividade ajustada no restante. Combine isso com as cinco checagens e você terá um fluxo que reduz a alucinação por desenho, não por sorte.

Para acelerar a prática, eu deixei um Template de Prompt Antialucinação pronto, com campos de objetivo, contexto, regras de veracidade, formato de saída, critérios de aceitação e um bloco opcional para RAG. Ele também traz um esqueleto de texto para copiar e colar. Minha sugestão é que você crie uma versão específica para sua clínica ou empresa, com as seções e limites que fazem sentido para o seu time, e mantenha um local único para atualizações. Em pouco tempo, você vai notar que o que mais reduz a alucinação não é a troca de modelo, é a disciplina do fluxo.

Se o seu ambiente permite, vale medir: quantas respostas exigem correção factual? Quais checagens mais pegam erro? Quanto tempo você gasta para revisar um rascunho com e sem RAG? Esses números guiam ajustes melhores que qualquer debate teórico. No meu dia a dia, a curva é consistente: a checagem de fontes e o bloco de “riscos e limitações” cortam boa parte dos falsos positivos de plausibilidade. E quando eu adiciono RAG com bons documentos, o ganho vem não só de precisão, mas de rastreabilidade — que é o que fecha a confiança no processo.

No fim, a boa prática é mais simples do que parece: pergunte com clareza, exija fontes, aceite o “não sei”, padronize critérios e use RAG quando existir base para isso. A IA não precisa ser onisciente para ser útil; ela precisa ser honesta e auditável. O resto é método.

— Chip Spark