Estudo mostra que camadas de verificação em LLMs só filtram respostas, não corrigem erros

Um estudo publicado em 10 de novembro de 2026 pelo InfoQ, assinado por Pushpdeep Mishra e Wejdan Bagais dentro do InfoQ Certified Architect Program, derruba uma premissa comum em quem coloca LLMs↳LLMs48 conteúdosConsiderações básicas de hardware para modelos de linguagem em código aberto: Memória, Desempenho e ViabilidadeMarketing Tech · out 2025Modelos de linguagem sob ataque: o lado obscuro da IA generativaDevSecOps · mai 2025Criando um LLM – modelo de linguagem de grande escala – do zero com TransformersAI · abr 2024Ver tudo em AI → em produção: a de que empilhar camadas de verificação sobre a saída de um modelo aumenta a acurácia de forma cumulativa. Os autores testaram seis camadas de confiabilidade, do checker determinístico ao revisor humano, sobre o mesmo extrator de linguagem natural e mediram o que cada uma realmente mudava nos resultados. A resposta curta: elas ordenam as respostas por confiança, mas corrigem quase nada.

O ângulo interessa direto a quem constrói agentes e pipelines com LLM hoje, porque o desenho testado (modelo lê, camada determinística confere, segundo modelo julga, humano decide o que sobra) é quase o padrão de arquitetura que qualquer time monta ao colocar um LLM em produção. O estudo mostra onde esse padrão entrega valor real e onde é teatro de confiabilidade.

A teoria que não se sustentou

A hipótese testada era que as camadas são aditivas: cada uma pegaria os erros que a anterior deixou passar, então a acurácia subiria a cada camada adicionada. Essa é a lógica usada por boa parte das arquiteturas de agentes hoje, com self-correction, votação por amostragem (sampling e voto), um segundo modelo como juiz, e recusa de resposta (refusal) quando a confiança é baixa.

As camadas ordenaram as respostas por quão confiáveis elas eram, mas corrigiram quase nenhuma.

Pushpdeep Mishra e Wejdan Bagais, InfoQ Certified Architect ProgramThe layers sorted the answers by how far to trust them and corrected almost none.

Para testar isso com rigor, os autores usaram o CADEC (CSIRO Adverse Drug Event Corpus), um corpus público desde 2015 com 1.250 posts de fórum sobre dois medicamentos, cada reação adversa marcada como um trecho exato de texto e associada a um código SNOMED CT. Ter um gabarito por menção permite comparar o veredito de cada camada contra a resposta certa, em vez de confiar no que a camada diz de si mesma.

Como era o pipeline testado

O desenho evita o erro mais comum: o modelo nunca é perguntado o código diretamente. Ele só cita o trecho do texto; um buscador sem nenhum modelo de linguagem (um lookup determinístico) varre 227.554 linhas de palavra-chave para código, extraídas da edição australiana do SNOMED CT de 31 de julho de 2026, usando o embedding granite-embedding:30m rodado localmente, e mostra ao modelo um menu com os 20 conceitos mais próximos para ele escolher.

As seis camadas testadas sobre esse extrator foram:

• Checagem de vocabulário (0 tokens): confirma se o código existe e se o trecho está mesmo no post.
• Auto-correção: devolve ao modelo os erros que a checagem provou errados.
• Votação: roda o extrator três vezes e usa maioria.
• Juiz (segundo modelo): um modelo menor avalia se a resposta do extrator está certa.
• Recusa (refusal): retém respostas duvidosas para revisão humana.
• Revisão humana: decide o que a recusa reteve.

O que cada camada entregou, e o que custou

Os resultados por camada, medidos em três rodadas sobre 40 documentos de desenvolvimento, mostram um padrão claro: as duas camadas gratuitas cumpriram o que prometiam, as três pagas, não.

A votação chegou a destruir de 2 a 5 respostas certas por rodada, porque quem vota é o próprio modelo que errou: um voto não carrega informação que a resposta já não tinha. E o juiz, que de fato discriminava melhor quando via o mesmo menu de opções do extrator (separação 3,4 a 4,2 vezes mais nítida que a checagem gratuita), teve seu veredito simplesmente ignorado pelo resto do pipeline. Retirar as três camadas pagas e manter só a recusa mudou o resultado em um único registro, em uma das três rodadas.

Reconhecer é mais fácil que gerar

O achado mais direto para quem desenha prompts e pipelines: pedir ao modelo para lembrar um identificador de cabeça é muito pior do que pedir para ele reconhecer a opção certa num menu. Os autores testaram três formas de obter o código SNOMED: recordar da memória, nomear o conceito e buscar, ou escolher de um menu. Pedir o código de memória produziu de 13% a 18% de códigos que não existem em nenhuma versão do SNOMED, e deixou até 38% dos registros sem resposta. Escolher num menu teve desempenho dez vezes melhor.

Em resumo: nunca peça ao modelo um identificador, ID ou código de memória. Peça para ele citar o trecho e escolher entre opções que um lookup determinístico já validou, e deixe o código sair do lookup, não da geração do modelo.

Determinismo: a maioria repete, uma minoria não

Outro ponto prático para quem já assumiu que temperature=0 garante reprodutibilidade: quatro das cinco famílias de modelo testadas (llama3.1:8b, mistral:7b-instruct, qwen3:8b, granite4:micro-h) reproduziram sua saída byte a byte em três rodadas idênticas. O extrator escolhido pelos autores, gpt-oss:20b, foi o único modelo de mixture-of-experts entre os cinco, e o único que variou: concordou em span e código em 70% das menções entre as três rodadas, mesmo em temperatura zero. Ele foi mantido mesmo assim, por entregar 6,5 pontos a mais de F1 que o llama3.1:8b.

A lição prática: medir o piso de variação do seu próprio pipeline, com no mínimo três rodadas idênticas, antes de assumir qualquer ganho de uma camada nova. Metade do que parece melhoria pode ser ruído do próprio modelo.

O teto que nenhuma camada derruba

O achado mais estrutural é que nenhuma camada acima do extrator consegue recuperar uma menção que o extrator simplesmente não leu. Quase metade das menções anotadas no CADEC nunca foi citada do jeito que os anotadores marcaram, por limites de frase que se esticam, palavras isoladas ignoradas e figuras de linguagem lidas ao pé da letra. Uma vez que a menção é encontrada, o pipeline é confiável: o conceito certo chega ao menu em 93% dos casos e o modelo escolhe certo em 81% deles. O gargalo é na leitura, não no vocabulário.

Modelos de domínio específico não resolveram isso: o BioMistral-7B não conseguiu devolver respostas parseáveis de forma confiável, e usar o SapBERT como encoder do buscador melhorou o menu, mas piorou a resposta final. O que funcionou foi mais simples: um exemplo trabalhado nas convenções de anotação do próprio corpus e uma regra para reações negadas no texto.

O que muda para quem coloca LLM em produção

O estudo testou mais sete corpora e cinco famílias de modelo além do CADEC, e quatro das cinco lições se repetiram em outros dados. Para quem arquiteta sistemas com LLM hoje, os pontos que atravessam domínios diferentes são:

1. Camadas de verificação filtram, não corrigem: meça yield (respostas certas sobre o total), não só acurácia do que passou, porque acurácia isolada sempre favorece quem descarta mais.
2. Checagem determinística (vocabulário, schema, compilador) prova que uma resposta está errada, nunca que está certa; teste-a contra seu próprio gabarito antes de confiar nela, porque em corpus de nomes de lugar ela acertou só 7% a 26% das vezes.
3. Votação por amostragem pode destruir respostas certas quando o votante é o mesmo modelo que errou.
4. Um juiz separado só ajuda se alguém ou algo ler o veredito dele; juiz cujo resultado ninguém consome é custo sem efeito.
5. O teto de qualquer pipeline é o que o extrator encontra na primeira leitura; investir em uma segunda leitura (outro modelo revisando o que o primeiro perdeu) é o único caminho citado pelos autores para passar desse teto, e eles não o testaram.

Para equipes brasileiras rodando agentes e extratores de informação em produção, com Postgres↳PostgreSQL11 conteúdosPostgreSQL via SSL com GolangData · abr 20195 itens legais sobre data types do PostgreSQLData · mar 20195 serviços gratuitos na cloud para bancos de dados PostgresData · fev 2025Ver tudo em Data →, pgvector ou qualquer stack de RAG, o recado prático é direto: gastar tokens em self-correction e votação tende a ser dinheiro jogado fora se ninguém mediu o ganho real contra o ruído do próprio modelo. O dinheiro rende mais numa checagem determinística bem desenhada e numa régua clara de quando reter resposta para humano revisar, do que em mais uma camada de IA checando IA.

Fonte: InfoQ