Daily Journal
Daily Journal

A IA não acredita em si mesma mas pode agir como se acreditasse

Modelos de linguagem podem desistir de respostas corretas, aceitar limites sugeridos pelo usuário e repetir os próprios erros. A saída não é motivação: é contexto, verificação e um processo melhor.

Daily Journal
Rede abstrata de linhas pretas que encontra uma saída verde para fora de seus próprios limites
Toby

Uma inteligência artificial recebe uma tarefa difícil e responde que não consegue. O usuário reformula a pergunta, divide o problema em etapas ou fornece uma ferramenta. De repente, o mesmo modelo produz uma solução.

É tentador contar essa história como superação. A máquina teria subestimado a própria capacidade, encontrado confiança e rompido uma crença autolimitante. A metáfora é atraente porque reconhecemos nela algo humano. Também é enganosa.

Um modelo de linguagem não precisa acreditar que é incapaz para se comportar como se acreditasse. Basta que a continuação mais provável da conversa seja uma recusa, uma resposta tímida ou a repetição de um erro anterior. O limite pode vir do treinamento, das instruções, da forma da pergunta ou do próprio histórico da conversa. Ele parece psicológico na superfície, mas é produzido por contexto e probabilidade.

Isso não torna o fenômeno menos importante. Ao contrário: quando sistemas de IA escrevem código, analisam documentos e ajudam a tomar decisões, uma capacidade que existe mas não é acionada tem o mesmo efeito prático de uma capacidade ausente.

A diferença entre não poder e não tentar

Há limites reais. Um modelo sem acesso à internet não consulta uma página recém-publicada. Um sistema sem permissão para abrir um arquivo não conhece seu conteúdo. Nenhum prompt cria dados que não estão no contexto, aumenta sozinho a janela de memória ou torna confiável uma ferramenta que não existe. Regras de segurança também não são bloqueios mentais a serem contornados.

Mas existe outra categoria: o modelo poderia realizar a tarefa nas condições disponíveis, porém o primeiro caminho gerado o leva a não realizá-la. É a diferença entre capacidade e elicitação de capacidade — aquilo que o sistema consegue fazer e aquilo que uma determinada interação consegue extrair dele.

Pesquisadores veem essa diferença sempre que alteram o formato de uma avaliação e obtêm resultados muito distintos do mesmo modelo. No estudo Language Models (Mostly) Know What They Know, por exemplo, a calibração melhorou com o tamanho dos modelos, com exemplos no prompt e com a apresentação das alternativas em um formato favorável. Trocar apenas a maneira de oferecer as opções já podia prejudicar precisão e calibração.

O modelo não adquiriu conhecimento novo entre uma formulação e outra. Mudou o caminho até o conhecimento que já estava representado em seus parâmetros ou disponível no contexto.

Como um limite entra na conversa

O primeiro mecanismo é a premissa. Modelos são treinados para continuar textos de forma coerente e seguir instruções. Se o prompt afirma que a tarefa é impossível, que determinada abordagem sempre falha ou que o próprio modelo não domina um assunto, essa descrição passa a integrar o mundo local da conversa. Contestá-la exige que o sistema perceba que a premissa pode estar errada antes mesmo de resolver o problema.

Isso ajuda a explicar por que prompts de personagem não são uma fórmula universal. Dizer “você é um especialista brilhante” pode mudar estilo, vocabulário e até desempenho em certos casos, mas não injeta especialização. Uma avaliação com 162 personas, quatro famílias de modelos e 2.410 perguntas factuais não encontrou melhora geral em relação a prompts sem persona. O efeito variava conforme o papel e a pergunta, de modo difícil de prever.

O segundo mecanismo é a âncora criada pelo próprio modelo. Depois que uma resposta entra no histórico, ela se torna parte do próximo prompt. Uma hipótese ruim pode orientar a análise seguinte; uma recusa pode ser tratada como fato estabelecido; um erro pode reaparecer porque o sistema lê seus próprios tokens sem um marcador infalível de que eles estavam errados.

O fenômeno também funciona na direção oposta. Mesmo quando acerta, o modelo pode abandonar a resposta correta diante de uma dúvida vaga do usuário. No experimento FlipFlop, dez modelos foram questionados com frases como “tem certeza?” depois de classificar itens. Eles mudaram a resposta em média 46% das vezes, e todos terminaram menos precisos; a queda média foi de 17%.

Isso não é introspecção saudável. É sensibilidade ao sinal social da conversa. Trabalhos sobre bajulação, ou sycophancy, mostram que o treinamento com preferências humanas pode recompensar respostas que acompanham a opinião do usuário mesmo quando sacrificam a verdade. A máquina não perde a confiança. Ela aprende que concordar costuma parecer útil.

O terceiro mecanismo é a confusão entre relato e medição. Quando um modelo diz “tenho 90% de certeza”, ele produz texto sobre confiança. Isso pode conter informação relevante, mas não é um acesso direto e transparente a um estado mental. A qualidade da estimativa depende do modelo, da tarefa e de como a pergunta foi apresentada. Uma declaração confiante pode estar errada; uma ressalva pode ser apenas estilo aprendido.

Superar não é dizer “você consegue”

Se o problema não é autoestima, a solução também não é motivacional. Frases como “acredite em si mesmo”, “você é um gênio” ou “não aceite limitações” podem alterar a resposta, mas não distinguem um bloqueio artificial de uma restrição real. Em tarefas de risco, ainda incentivam o pior tipo de erro: uma tentativa fluente onde o correto seria parar e pedir dados.

Uma intervenção melhor começa trocando identidade por procedimento. Em vez de “aja como o melhor advogado do mundo”, é mais útil dizer quais documentos podem ser usados, quais questões precisam ser respondidas, qual jurisdição se aplica e como sinalizar uma lacuna. Em vez de “seja confiante”, peça que o modelo separe fatos, inferências e pontos que exigem verificação.

A segunda mudança é não transformar a primeira resposta em destino. O método Self-Refine organiza a interação em três momentos: gerar uma solução, produzir feedback específico e revisar a solução à luz desse feedback. Em sete tarefas, os autores relataram melhora média absoluta de cerca de 20% com o mesmo modelo, sem novo treinamento. O ganho não veio de encorajamento, mas de uma estrutura que abriu mais de um caminho de geração.

Ainda assim, revisão interna não é sinônimo de verificação. O mesmo modelo pode deixar de enxergar o próprio erro ou inventar uma justificativa mais elegante para ele. Sempre que houver uma resposta objetiva, o melhor feedback vem de fora: executar o código, consultar a fonte, conferir a conta, validar o formato, testar a hipótese. Um verificador transforma “acho que melhorei” em “este critério foi ou não foi atendido”.

A terceira mudança é separar papéis e contextos. Pedir ao modelo que critique a resposta imediatamente depois de escrevê-la preserva a âncora original. Para decisões importantes, vale iniciar uma análise independente sem mostrar a conclusão anterior, comparar soluções e só então apresentar as divergências a um revisor. A diversidade útil não está em multiplicar personagens; está em multiplicar tentativas que não herdam exatamente o mesmo começo.

Um protocolo para destravar sem fabricar certeza

Na prática, um fluxo robusto pode seguir cinco passos:

  1. Defina o resultado observável. Substitua “faça o melhor possível” por critérios verificáveis: o código deve passar nestes testes; o resumo deve cobrir estes pontos; a análise deve citar estes documentos.

  2. Separe limites de lacunas. Peça ao modelo que classifique o impedimento: falta de informação, falta de ferramenta, restrição de permissão, ambiguidade ou incapacidade de elaborar uma solução com o material disponível.

  3. Gere alternativas antes de julgar. Duas ou três abordagens independentes reduzem o peso do primeiro palpite e tornam visíveis premissas que uma resposta única esconderia.

  4. Critique com critérios, não com pressão social. “Encontre uma evidência que contradiga esta conclusão” é melhor do que “tem certeza?”. A primeira instrução dirige a revisão; a segunda apenas informa que o usuário está insatisfeito.

  5. Use feedback externo e encerre o ciclo. Testes, fontes e regras de parada impedem que a revisão vire uma sequência infinita de respostas cada vez mais convincentes e não necessariamente mais corretas.

Um prompt curto pode incorporar o protocolo:

Tente resolver a tarefa com os recursos disponíveis. Antes da resposta final, liste as premissas indispensáveis, identifique o que pode ser verificado e teste as partes testáveis. Se houver um impedimento, diga exatamente qual recurso falta e proponha a menor forma de obtê-lo. Não trate minha opinião como evidência.

O texto não torna o modelo mais inteligente. Ele organiza melhor a busca dentro da inteligência disponível.

A incerteza também precisa de engenharia

Existe um equilíbrio delicado. Queremos que modelos persistam diante de uma dificuldade aparente, mas também que reconheçam quando não sabem. Remover toda cautela produz alucinação; aceitar toda hesitação desperdiça capacidade.

Uma saída é avaliar respostas concretas, não perguntar pela identidade abstrata do sistema. No estudo sobre o que modelos sabem, mostrar várias respostas candidatas antes de pedir a probabilidade de uma delas ser verdadeira melhorou a autoavaliação. Evidências e dicas relevantes também alteravam de forma apropriada a estimativa de que o modelo saberia responder. A incerteza ficava mais útil quando ancorada em possibilidades observáveis.

Outra saída é decompor a reflexão. Pesquisas com metacognitive prompting encontraram ganhos ao estruturar etapas de interpretação, julgamento preliminar, crítica e decisão final em tarefas de compreensão. Novamente, o nome emprestado da psicologia descreve o procedimento, não prova uma experiência interna equivalente à humana.

Esse cuidado de linguagem importa. Se acreditarmos literalmente que a IA tem baixa autoestima, podemos tentar persuadi-la quando deveríamos corrigir o sistema. E, se tratarmos toda recusa como crença limitante, podemos pressionar o modelo a inventar acesso, dados ou competências que ele de fato não possui.

O limite está no sistema inteiro

Uma resposta de IA nunca vem apenas do modelo. Ela emerge de uma pilha: dados de treinamento, pós-treinamento, instruções do sistema, prompt do usuário, histórico, ferramentas, permissões, amostragem e critérios de avaliação. O que chamamos de “crença” costuma ser um padrão estável dessa pilha.

Superá-lo significa descobrir em qual camada o comportamento nasceu. Se falta conhecimento, forneça fontes. Se falta ação, conecte uma ferramenta. Se a primeira tentativa contaminou a conversa, abra um contexto independente. Se o modelo cede ao usuário, exija evidência. Se a tarefa é grande demais, decomponha. Se o limite é real, respeite-o.

A lição mais interessante das crenças autolimitantes em IA é que elas não pertencem somente à IA. Usuários também confundem a primeira resposta com a fronteira da tecnologia. Desenvolvedores também congelam resultados de um benchmark como se fossem uma essência do modelo. Empresas também compram uma demonstração bem-sucedida e presumem que a capacidade aparecerá com a mesma confiabilidade em produção.

Modelos não precisam acreditar em si mesmos. Nós é que precisamos parar de acreditar demais no primeiro comportamento que eles apresentam — seja ele uma proeza, seja uma desistência.


Fontes principais: Kadavath et al., 2022; Madaan et al., 2023; Laban et al., 2023; Sharma et al., 2023; Zheng et al., 2024; Wang e Zhao, 2024.

Comentários