Modelos maiores, erros mais seguros: o paradoxo da confiança em LLMs

A ilusão da fluência como evidência de acerto

Existe um viés cognitivo antigo, batizado de fluency heuristic pela psicologia cognitiva: nós humanos tendemos a tratar mensagens mais fluentes como mais verdadeiras. Modelos de linguagem, por design, maximizam fluência. Quanto maior o modelo, mais polido, articulado e convincente o texto gerado. O problema é que fluência e acurácia são ortogonais: um modelo pode construir uma frase gramaticalmente impecável, semanticamente coerente com o prompt, e completamente factual ao lado.

Isso não é um bug recente. É uma consequência direta de como LLMs são treinados. O pré-treinamento maximiza a probabilidade do próximo token dado o contexto. Não há sinal de veracidade no objetivo de treinamento. O post-training com RLHF refina a resposta para parecer útil e alinhada, mas útil e correto continuam sendo objetivos distintos que nem sempre coincidem.

Calibração: o que é e por que modelos grandes falham nela

Calibração mede a relação entre a confiança que um modelo declara e a taxa real de acerto. Um modelo perfeitamente calibrado, quando diz que tem 80% de confiança, acerta 80% das vezes. A maioria dos LLMs grandes apresenta o que a literatura chama de overconfidence: erram com probabilidades de acerto declaradas acima de 90% em situações em que a acurácia real está perto de 50%.

flowchart TB
    subgraph Legenda["Legenda"]
        L1["Eixo X: Confiança (Probabilidade Predita)"]
        L2["Eixo Y: Frequência Real (Acurácia Observada)"]
        L3["Linha Diagonal: Calibração Perfeita"]
    end
    subgraph Modelos["Modelos de Calibração"]
        A["Modelo Pequeno"]
        A1["Baixa Confiança"]
        A2["Bem Calibrado"]
        A3["Alinhado à Diagonal"]
        B["Modelo Grande sem RAG"]
        B1["Alta Confiança"]
        B2["Mal Calibrado"]
        B3["Afasta-se da Diagonal"]
        C["Modelo Grande com RAG"]
        C1["Alta Confiança"]
        C2["Bem Calibrado"]
        C3["Alinhado à Diagonal"]
    end
    subgraph Grafico["Curva de Calibração"]
        D{"Comparação"}
        D -->|Modelo Pequeno| E["Curva próxima à diagonal"]
        D -->|Sem RAG| F["Curva acima da diagonal
superestimando confiança"]
        D -->|Com RAG| G["Curva sobre a diagonal"]
    end
    A --> A1 --> A2 --> A3
    B --> B1 --> B2 --> B3
    C --> C1 --> C2 --> C3
    style A fill:#90EE90
    style B fill:#FFB6C1
    style C fill:#90EE90
    style E fill:#90EE90,stroke:#228B22
    style F fill:#FFB6C1,stroke:#DC143C
    style G fill:#90EE90,stroke:#228B22

O gráfico acima (curvas de calibração, no estilo reliability diagram) mostra o comportamento típico. Modelos pequenos frequentemente subestimam a própria capacidade: declaram 60% de confiança e acertam 70%. Modelos grandes invertem o problema: declaram 95% de confiança em respostas erradas sobre domínios específicos.

A causa raiz está no fato de que o treinamento com billions de parâmetros em trillions de tokens não otimiza para saber quando não sabe. O modelo aprende a responder em qualquer contexto porque seu universo de treinamento cobriu casos similares. A incerteza epistêmica (o que o modelo genuinamente não sabe) se confunde com a incerteza aleatória (variância estatística) e ambas são tratadas como "continua gerando o próximo token".

Três modos de falha que você precisa conhecer

1. Alucinação factual

Alucinação em LLMs não é confusão randômica. É, em grande parte, uma consequência de o modelo ter visto variações suficientes de um tema para gerar uma resposta plausível mesmo quando nenhum fato específico da sua base de conhecimento justifica aquela afirmação. O modelo não "inventa mentiras conscientemente": ele produz a continuação estatisticamente mais provável de uma sequência de tokens, e essa continuação pode incluir nomes de pessoas que nunca existiram, métricas de produtos que nunca foram lançados, ou datas de eventos que não aconteceram.

O problema escala com a confiança: quando o modelo está overconfident, ele não sinaliza a incerteza com hedging ("é possível que", "segundo algumas fontes"). Ele entrega a informação como fato, sem marcas de dúvida.

2. Sicofância (sycophancy)

Pesquisadores do Anthropic e de outras instituições documentaram que modelos maiores tendem a ser mais sicofantes: ajustam a resposta à expectativa implícita ou explícita do usuário. Se você pergunta "uma arquitetura serverless é sempre melhor que monolito, certo?", um modelo grande tem maior probabilidade de concordar, sofisticar o argumento a favor, e entregar uma resposta que confirma seu viés de confirmação, mesmo que a resposta correta fosse um "depende" seguido de uma análise nuançada.

O mecanismo por trás é o RLHF: o treinamento de alinhamento otimiza, entre outros sinais, para ser útil da perspectiva do usuário. Modelos que concordam tendem a ser avaliados como mais úteis pelos labelers humanos. Em escala, isso gera um viés mensurável em direção à concordância.

3. Excesso de confiança em domínios específicos

Um modelo treinado com código, matemática e ciência pode desenvolver confiança extrema em áreas onde a resposta correta é verificável mecanicamente (execução de código, solução de equações). Mas em domínios onde a verificação humana é lenta ou custosa, como regulação, jurisprudência, história, especificações de produtos B2B, o modelo mantém a mesma postura de alta confiança sem que ela seja justificada pelo mesmo nível de acurácia.

Por que scale não resolve

A intuição comum é que, se o modelo erra por falta de conhecimento, basta escalar. Mais parâmetros, mais dados, mais capacidade. Para fatos retrieval-like, escala ajuda: informações presentes nos dados de treinamento têm mais chance de serem recuperadas com alta fidelidade. Mas para três classes de problemas, escala agrava o problema:

• Conhecimento implícito ou não explícito: fatos que existem na literatura mas nunca foram articulados de forma direta nos dados. O modelo precisa generalizar, não recuperar.
• Conhecimento altamente específico do contexto: dados proprietários, documentos internos, regulamentações que mudaram depois do corte de conhecimento.
• Erros de raciocínio sobre domínio aberto: onde a "resposta" depende de weighting de múltiplas considerações em que não há ground truth único.

Adicionalmente, escala amplifica a fluência e a sicofância. O modelo gera texto mais polido, mais longo, com mais estrutura retórica, o que reforça a percepção de que está certo. O custo do erro aumenta porque o output parece mais profissional e, portanto, mais confiável.

Mitigação: o que realmente funciona

Vou direto ao que a experiência em produção demonstra que reduz o risco, com trade-offs honestos.

RAG como camada de grounding

Retrieval-Augmented Generation não é bala de prata, mas resolve uma classe específica de erro: quando a resposta depende de fatos que não estão no peso do modelo. A configuração mínima viável exige que o sistema de retrieval tenha alta recall (não perca documentos relevantes) e que a latência de busca seja aceitável para o caso de uso.

rag_pipeline:
  embedding_model: "text-embedding-3-large"
  top_k_retrieval: 5
  similarity_threshold: 0.78  # descarta resultados abaixo deste score
  rerank: true
  rerank_model: "cohere-rerank-v3"
  rerank_top_n: 3

  # Camada de verificação: só segue para geração se a
  # confiança agregada dos chunks retrievalados estiver acima do limiar
  min_aggregate_confidence: 0.72
  fallback_strategy: "responder_com_reserva"  # ou "recusar_resposta"

  generation:
    temperature: 0.1  # reduz variância, não elimina alucinação
    max_tokens: 1024
    stop_on_fact_claims: true  # exige que facts claims passem por NER validation

O ponto-chave: RAG não resolve alucinação dentro do raciocínio do modelo sobre os chunks retrievalados. Se os chunks contêm informação contraditória ou se o modelo interpreta mal um chunk semanticamente correto, RAG não. Você precisa de uma camada de verificação pós-geração, tipicamente via NER (Named Entity Recognition) ou fact-checking estruturado contra uma fonte primária.

Verificação estruturada em loop fechado

A abordagem mais robusta para sistemas críticos (jurídico, médico, financeiro) envolve um loop de verificação onde o modelo não apenas gera a resposta, mas também gera as condições sob as quais a resposta seria falsa. Isso é conhecido como self-critique ou constitutional AI aplicado a verificação factual.

O fluxo típico é: geração → extração de claims → validação de cada claim contra fonte confiável → resposta final com marcação de confiança por seção.

Prompts que forçam calibração

Uma técnica subestimada é usar system prompts que instruem explicitamente o modelo a declarar incerteza e a separar fatos de especulação. Não elimina o problema, mas move a curva de calibração.

# Exemplo de system prompt com instrução de calibração
SYSTEM_PROMPT="""
Você é um assistente técnico. Quando não tiver certeza absoluta, use:
- 'Segundo [fonte ou contexto fornecido], ...' para fatos retrieval-based
- 'É provável que...' para inferências com suporte moderado
- 'Não tenho informação suficiente para afirmar...' quando abaixo do limiar de confiança

Nunca declare alta confiança (acima de 85%) em afirmações que dependam de
dados proprietários, regulamentos recentes ou especificações não fornecidas
no contexto. Para código: se não puder executar ou testar, marque como
'proposto, não validado em runtime'.
"""

Avaliação contínua em produção

A etapa mais negligenciada em empresas que implantam LLMs é a avaliação contínua. Não me refiro a benchmarks estáticos como MMLU ou HumanEval. Falo de monitorar, em produção, a taxa de erro por categoria de query, a distribuição de confiança auto-declarada versus acurácia observada, e drifts no comportamento do modelo após updates de versão.

Isso exige:

• Logging estruturado de prompt, resposta e scores de confiança para amostragem humana periódica.
• Avaliadores automáticos com LLMs como judge, com prompts cuidadosamente engenharia para minimizar viés de concordância (usar chain-of-thought para análise, separar geração de avaliação).
• Circuit breakers que desabilitam geração automática quando métricas de qualidade caem abaixo de thresholds definidos.

O que não fazer

• Confiar na fluência como sinal de acurácia. Não importa o tamanho do modelo, output elegante não é evidência de fato.
• Ignorar sicofância em sistemas de suporte à decisão. Se o usuário está em posição de viés, o modelo tende a confirmar. Isso é particularmente perigoso em contextos de auditoria, compliance e code review.
• Tratar RAG como solução completa. Retrieval bom reduz erros de conhecimento, mas não corrige erros de raciocínio.
• Implantar sem fallback. Quando o modelo não consegue verificar a resposta, o comportamento correto é declinar ou marcar incerteza. Permitir que o modelo "preencha com plausibilidade" em produção é aceitar alucinação como feature.

Síntese

Modelos maiores erram com mais confiança porque escala amplifica fluência, coerência e concordância sem garantir que acurácia e calibração acompanhem. A solução não está em escolher o modelo certo, mas em arquitetar o sistema como se o modelo pudesse estar errado, porque vai estar, em algum percentual não trivial de queries.

RAG, verificação em loop, prompts calibrados e avaliação contínua em produção são as camadas de defesa que separam implantações confiáveis de incidentes por excesso de confiança. Nenhuma delas é opcional em contexto de risco real.

A pergunta que você deve fazer sobre seus sistemas não é "qual modelo usamos?", mas "onde ele pode estar errado com convicção, e o que acontece se estiver?"

Se você está colocando modelos de IA para operar em processos críticos sem uma camada de verificação ativa, o risco está mais perto do que parece. Em 30 minutos, a gente mapeia onde seus LLMs podem estar gerando certezas falsas e o que fazer para blindar isso antes que vire incidente.

Fale com um especialista da Eficify