Voltar às notícias
InovaçãoInstruções AI Understanding

Estudo constata que modelos de linguagem equipados com ferramentas podem fazer afirmações sem suporte, mesmo quando a verificação é possível

Um novo preprint relata que um modelo de linguagem testado às vezes fazia afirmações finais sem suporte, apesar de ter acesso a ferramentas de resolução de evidências, enquanto uma regra de verificação automática corrigia os erros em uma pequena avaliação sintética.

6 min readRead the primary source
Source-page capture accompanying Study finds tool-equipped language models can make unsupported claims even when checking is possible
Documento de origem primáriaFonte registrada
Editora
arxiv.org
Link da fonte
arxiv.orghttps://arxiv.org/abs/2608.27768
Tipo de fonte
Documento primário - um anúncio oficial, papel, arquivamento ou página original que lemos diretamente.
ContextoEntenda isso em 60 segundos

Comece aqui

Termos-chave

Generalização
O desempenho de um modelo em dados novos e não vistos fora do conjunto de treinamento.
Uso de ferramentas
A capacidade de um modelo de chamar ferramentas externas, como pesquisa, calculadoras ou APIs.
Calcular
Os recursos de processamento necessários para treinar e executar modelos, geralmente medidos em FLOPS ou horas de GPU.
Teste você mesmoQuestionário explicado sobre modelos de IA

O que aconteceu

Uma nova pré-impressão arXiv examina por que os modelos de linguagem equipados com ferramentas às vezes se comprometem com afirmações que não são apoiadas pelas evidências disponíveis. O estudo separa o problema em quantas vezes ocorrem reclamações não comprovadas e quantas vezes elas podem ser reparadas quando as evidências faltantes são fornecidas.

O artigo estuda modelos de linguagem que podem chamar ferramentas para resolver incertezas. A sua conclusão central é que o acesso à ferramenta por si só nem sempre levou o modelo à verificação. Em uma configuração fixa do Qwen3-32B, 33 das 512 primeiras respostas a 256 novos modelos de prompt terminaram com uma afirmação estabelecida sem suporte, embora uma única chamada de ferramenta disponível pudesse ter resolvido a incerteza e as instruções proibissem explicitamente suposições e suposições. Os autores definem uma afirmação não suportada utilizando as evidências visíveis para o modelo e sua resposta final, sem depender da resposta correta oculta.

Os pesquisadores então reproduziram cada um desses 33 casos a partir de uma cópia exata do estado em que a reclamação ocorreu. As respostas alternativas da ferramenta foram combinadas em estrutura e comprimento e diferiam apenas em um código de resposta de um caractere. De acordo com o jornal, o fornecimento de evidências de resolução consertou todas as 33 reivindicações não comprovadas. Uma resposta correspondente que não continha nenhuma informação útil não corrigiu nenhum deles. Quando a evidência apoiou a resposta original do modelo, o modelo manteve essa resposta em todos os 33 casos, sem nenhum dano observado neste teste.

Uma experiência separada examinou uma regra de verificação automática em 64 casos em que eram necessárias provas. A regra desencadeou 21 chamadas de evidências adicionais. O artigo relata que corrigiu todas as 10 afirmações erradas e não comprovadas, preservou 11 respostas que estavam corretas por acidente e nunca transformou uma resposta correta em uma errada. Estes resultados sugerem que a intervenção foi direcionada no cenário testado, mas não estabelecem como a regra funcionaria com diferentes sugestões, modelos, ferramentas ou tipos de evidências.

O modelo de comparação produziu um resultado nitidamente diferente. Em uma configuração fixa do Gemma 4 usando as mesmas configurações de amostragem, o modelo chamou a ferramenta em todas as 512 primeiras respostas e nunca fez uma afirmação final sem suporte. Como nenhuma reivindicação não comprovada de ocorrência natural apareceu nessa configuração, os autores não puderam medir o reparo condicional para ela. A fonte identifica os experimentos como duas configurações de modelos fixos locais em duas famílias de tarefas sintéticas.

Detalhes da fonte: arxiv.org ↗

Por que isso importa

As conclusões apontam para um problema prático de fiabilidade para sistemas de IA que podem consultar ferramentas, bases de dados ou serviços externos: o acesso à verificação não garante que um modelo a utilizará antes de fazer uma afirmação. O artigo também relata que uma simples regra de verificação automática corrigiu os erros observados em uma configuração testada, embora a evidência seja limitada.

A questão prática não é simplesmente se um modelo possui uma ferramenta. Um sistema pode estar conectado a uma função de busca, banco de dados ou calculadora e ainda assim responder antes de obter informações que resolveriam uma incerteza. Para aplicações em que uma afirmação não comprovada pode enganar o usuário, a distinção entre disponibilidade e uso da ferramenta tem consequências. O resultado do artigo fornece uma maneira concreta de descrever essa distinção, em vez de tratar a confiabilidade como uma pontuação única.

O estudo também oferece uma estrutura de avaliação potencialmente útil. A medição da ocorrência pergunta com que frequência um modelo faz de forma independente uma afirmação sem suporte. A medição do reparo condicional pergunta se a mesma reivindicação muda quando a evidência faltante é fornecida. Essa separação pode ajudar os avaliadores a determinar se o problema de um modelo é falha na verificação, falha na atualização após a verificação ou ambos. Neste experimento, a configuração Qwen mostrou uma falha observada na verificação, mas respondeu corretamente quando a evidência de resolução foi fornecida.

O resultado da verificação automática é importante porque testa uma possível salvaguarda operacional, em vez de apenas documentar uma falha. No experimento relatado de 64 casos, a regra adicionou 21 chamadas de evidências e corrigiu as 10 afirmações erradas e não comprovadas sem alterar nenhuma resposta correta. Essa combinação é encorajadora no experimento, especialmente para sistemas nos quais uma chamada de verificação é mais barata do que permitir que uma resposta não suportada chegue ao usuário.

Os limites são igualmente importantes. A fonte descreve uma pré-impressão, não um estudo revisado por pares, e relata resultados de apenas duas configurações de modelo fixo e duas famílias de tarefas sintéticas. Os autores dizem explicitamente que as descobertas não mostram quão comum é a falha em implantações no mundo real ou que reflete um mecanismo geral compartilhado entre modelos. Os números, portanto, apoiam uma conclusão restrita de confiabilidade, e não uma afirmação ampla sobre os modelos linguísticos como um todo.

Os diferentes resultados de Qwen3-32B e Gemma 4 também alertam contra a generalização. Às vezes, um modelo falhava na verificação, enquanto o outro chamava a ferramenta em todas as primeiras respostas na configuração declarada. A fonte não estabelece quais fatores arquitetônicos, de treinamento, de estímulos ou específicos da tarefa causaram essa diferença. Também não informa se os modelos foram testados com evidências ruidosas, conflitantes, atrasadas ou dispendiosas.

Interactive Mechanism

Mecanismo interativo: como realmente funciona

Explore a tecnologia subjacente a este desenvolvimento de forma interativa.

Agent Lifecycle Stage:
1
User Intent & Planning: "Audit customer refund request #4092 and settle payment."
2
Tool Calling: Emits structured JSON call crm_get_transaction(id='4092').
3
Guardrail & Verification:🛡️ Paused: High-value action requires human operator sign-off.
4
Final Settlement: Refund recorded, email receipt dispatched, and audit log stored.
Core takeaway: An AI agent is not just a language model—it is a closed loop of planning, tool invocation, and environment feedback. Production systems require self-healing retries and strict human approval guardrails.
Verificação de conceito interativo+10 Points
AI Models Explained Quiz

Which component of an AI application is the machine-learning model itself?

O que assistir a seguir

A questão principal é se o comportamento relatado aparece além das duas configurações de modelo fixo e das famílias de tarefas sintéticas do estudo. Novos trabalhos deverão testar mais modelos, ferramentas realistas e condições de implantação, e determinar se as regras de verificação permanecem seguras e úteis quando as provas são ambíguas, incompletas ou de obtenção dispendiosa.

A replicação é a próxima etapa mais importante. Os pesquisadores devem testar as medidas de ocorrência e reparo em famílias de modelos adicionais, tamanhos de modelos, configurações de amostragem e políticas de uso de ferramentas. A fonte atual não estabelece se as 33 alegações não comprovadas são típicas, invulgarmente frequentes ou invulgarmente raras. Também não mostra se a regra de verificação automática funcionaria quando os modelos enfrentassem instruções mais variadas ou cadeias mais longas de chamadas de ferramentas.

Tarefas realistas serão um teste crítico. O artigo usa famílias de tarefas sintéticas, enquanto os sistemas implantados podem pesquisar na web, consultar registros comerciais, recuperar documentos, executar código ou interagir com APIs. Esses ambientes podem produzir evidências parciais, fontes contraditórias e falhas nas próprias ferramentas. Ainda não se sabe se o fornecimento de códigos de resolução de um caractere captura a dificuldade de decidir quando verificar em ambientes práticos.

Os avaliadores também devem examinar o custo e os efeitos colaterais da verificação. A fonte relata 21 chamadas de evidências adicionais no experimento separado, mas não fornece uma análise de custos mais ampla nem mostra como a regra se comporta quando as ferramentas são lentas, com taxas limitadas ou indisponíveis. Uma salvaguarda que melhore o suporte factual ainda pode afetar a latência, o uso da computação ou a experiência do usuário. Essas compensações não são medidas aqui.

O campo deve verificar se as regras de verificação permanecem conservadoras sob incerteza. No experimento relatado, a regra nunca converteu uma resposta correta em uma errada, mas esse resultado vem de uma pequena amostra controlada. Testes maiores devem procurar intervenções falsas, falhas na reparação e casos em que as evidências estão tecnicamente disponíveis, mas não são fiáveis. A fonte não fornece evidências sobre essas condições.

Finalmente, as definições do documento poderiam apoiar relatórios mais comparáveis. Separar a ocorrência de reclamação não fundamentada da reparação condicional torna possível dizer se um sistema falhou na procura de provas ou não utilizou as provas uma vez obtidas. Se essas medidas se tornarão padrão dependerá da replicação e da demonstração de que elas prevêem falhas que os usuários encontrarão fora das avaliações sintéticas.

Guias e questionários relacionados

Modelos de IA explicadosAgentes de IAÉtica da IAPrompt EngineeringTeste o que você sabe – experimente um teste gratuito de IAProcure um termo de IA em nosso glossárioSiga o rastreador de lançamento de modelo de IA
Achou isso útil?