Correção de Regex Rigoroso Aumenta Recall de Avaliação de Agentes em 60 Pontos Percentuais

Classificadores automatizados para sistemas agênticos falham onde avaliadores de LLM de turno único não falham. Nova pesquisa da Columbia Statistics identifica exatamente onde o sinal vaza. Um artigo intitulado "Grading the Grader" (Zheng e Hsu, junho de 2026) executou LAMBDA—um sistema dual-agente de análise de dados de código aberto—contra 153 tarefas numéricas QRData no benchmark DSGym. Pesquisadores testaram sob estresse três estratégias de classificação contra rótulos humanos e exposeram dois modos de falha que a maioria dos pipelines de avaliação encontra.

LAMBDA pareia um agente "programador" que escreve Python a partir de instruções em linguagem natural com um agente "inspetor" que detecta erros de execução e sugere correções. O loop é executado até que o código seja bem-sucedido ou um limite de retry seja atingido. Esse design iterativo e emissor de código quebra classificadores padrão: a resposta final do agente pode aparecer em uma variável impressa, uma string formatada, um log de diagnóstico ou um rastreamento parcial—qualquer um que um regex ingênuo perderá.

O artigo testou três camadas. Primeira: correspondência rigorosa de regex, uma abordagem não-GenAI que extrai números por padrão. Segunda: classificação leniente baseada em LLM, que interpreta a resposta em contexto. Terceira: inspeção humana baseada em snippet. Na precisão, ambos os classificadores automatizados alcançaram zero falsos positivos em 70 amostras validadas por humanos. Recall divergiu drasticamente. Uma heurística de último número—pegue qualquer numeral que apareça por último na saída—deixou o classificador rigoroso muito exposto. Substituindo-o por um pipeline de extração ancorado por palavra-chave—um que digitaliza tokens adjacentes à resposta antes do número—aumentou o recall do classificador rigoroso em 60 pontos percentuais. Essa mudança única é o resultado mais acionável no artigo para equipes que executam pipelines regex-primeiro.

O recall do classificador LLM leniente atingiu 97% contra rótulos humanos, mas apenas após resolver um problema separado: o próprio classificador estava falhando em ser executado. Sem intervenção, apenas 36% das invocações de classificação foram concluídas com sucesso, com uma taxa de aprovação leniente de 16%. A solução foi um mecanismo de nudge iterativo—um prompt que empurra o LLM de classificação em direção a um template de resposta estruturado. Com nudging, o sucesso da execução de classificação aumentou para 97% e as taxas de aprovação leniente para 46%. Re-injetar a pergunta da tarefa original junto com o nudge não forneceu benefício adicional. O nudge funciona como uma sugestão de formatação, não como um scaffold de compreensão. Equipes que adicionam contexto de pergunta para estabilizar seus juízes LLM desperdiçam tokens.

Tipo de variável—o tipo de dados da resposta esperada (integer, float, percentage, etc.)—provou ser o campo de metadados de tarefa mais consistentemente associado ao comportamento do pipeline de classificação e às notas observadas. Ele supera outras características de tarefa como um sinal de diagnóstico. Quando os números de avaliação parecem incorretos, dividir por tipo de variável localizará o problema mais rapidamente do que dividir por domínio ou comprimento da tarefa.

Um artigo separado (Nie et al., 2026) mostrou que uma porção substancial de tarefas QRData pode ser resolvida sem os arquivos de dados reais—através de memorização ou priors estatísticos. A filtragem de atalhos revelou uma queda de até 21% na precisão relativa uma vez que a dependência de dados foi imposta. O desempenho do agente nessa classe de tarefas provavelmente está superestimado em toda a placa. Pipelines de avaliação que relatam altas taxas de aprovação podem estar medindo recall de priors de tempo de treinamento, não raciocínio genuíno.

Implante uma stack de dois classificadores: regex com extração ancorada por palavra-chave como uma âncora de precisão, classificador LLM com nudging de template como a camada de recall. Estratifique diagnósticos por tipo de variável. Não confunda falhas de execução de classificação com falhas de agente até ter instrumentalizado ambos os caminhos separadamente.