Resumo Técnico: MMLongBench-Doc-V2

Declaração do Problema

O MMLongBench-Doc (Ma et al., 2024) é um benchmark para o questionamento e resposta (QA) de documentos longos, composto por 1.082 perguntas em 135 PDFs. Embora projetado para testar a compreensão de documentos e suprimir alucinações através de perguntas "não respondíveis", o benchmark original (V1) sofre de duas falhas críticas que distorcem a medição de desempenho:

1. Limitações de Métricas de String: O V1 avalia as respostas comparando strings extraídas com chaves de referência. Isso penaliza respostas semanticamente corretas por diferenças mínimas de formatação (ex: 1,358,000 vs. 1358000, ou Operating Activities vs. Operations activities). Este problema afeta desproporcionalmente sistemas que respondem a perguntas baseadas em listas ou texto livre, distorcendo os rankings relativos em vez de apenas as pontuações absolutas. Além disso, seis perguntas eram tecnicamente impossíveis de pontuar porque suas respostas de referência violavam suas próprias restrições declaradas de answer_format (ex: erros de parsing).
2. Erros Sistemáticos de Anotação: Uma parte não trivial das anotações de verdade fundamental (ground-truth) está incorreta, ambígua ou incompleta. Esses erros não são aleatórios; eles estão concentrados em perguntas que sistemas capazes respondem corretamente, mas que são pontuadas como zero porque a resposta defensável do sistema conflita com uma chave falha. Isso cria um teto artificial no desempenho do benchmark que mimetiza uma limitação do modelo em vez de um problema do conjunto de dados.

Metodologia

O MMLongBench-Doc-V2 aborda essas questões por meio de um processo de revisão rigoroso envolvendo a substituição da métrica, correção de anotações e um procedimento de decisão formal para casos limítrofes.

1. Revisão da Métrica: O Juiz LLM Fixado (Pinned LLM Judge)

A métrica de identidade de string é substituída por um "juiz LLM fixado".

• Entrada: O juiz recebe a pergunta, a resposta de referência, o formato esperado e o texto da resposta completa do sistema (não uma string pré-extraída).
• Restrição: O juiz é explicitamente instruído a não ler o documento de origem. Ele trata a resposta de referência como a verdade fundamental e determina apenas se a resposta do sistema transmite o mesmo significado.
• Rubrica: A redação, o caso (maiúsculas/minúsculas), as unidades, os separadores e a ordem da lista são flexíveis. No entanto, membros ausentes ou extras na lista, valores diferentes ou uma recusa em responder (quando existe uma resposta) são penalizados. Para referências de "Não respondível", apenas uma recusa clara é aceita; oferecer voluntariamente um valor aproximado conta como erro.
• Estabilidade: O modelo juiz, o esforço de raciocínio e o esquema JSON são fixos ("pinned") para garantir a reprodutibilidade, embora a escolha do modelo permaneça um parâmetro livre para a métrica.

2. Correções de Anotação

O autor auditou 1.082 perguntas, identificando e corrigindo 106 anotações.

• Tipos de Correção: As mudanças incluem a correção de respostas erradas (26), reparação de perguntas defeituosas (19), esclarecimento de perguntas ambíguas (19), complementação de respostas incompletas (16) e reclassificação de itens "Não respondíveis" como respondíveis (14).
• Defeitos no Corpus: Dez perguntas direcionadas a documentos enviados sob nomes de arquivos incorretos foram removidas inteiramente, pois nenhum sistema poderia respondê-las. Uma pergunta duplicada com chaves contraditórias também foi removida.
• Documentação: Cada correção é publicada com a anotação original, a versão corrigida e evidência específica (números de página ou aritmética) para permitir a verificação independente.

3. Procedimento de Decisão para Chaves de "Conjunto Vazio"

Um desafio específico envolveu perguntas com chaves 0 (ex: "quantos gatos?") versus "Não respondível". O autor estabeleceu um procedimento de decisão para determinar quando uma chave de "conjunto vazio" deve ser ampliada para "Não respondível" sem destruir a natureza deliberadamente negativa de amostras do benchmark.

• Critérios de Ampliação: Uma chave é ampliada apenas se o recipiente existe (ex: um intervalo de páginas específico) e a entidade alvo é verificavelmente ausente. Neste caso, "nenhum" ou "0" é uma leitura válida do documento.
• Critérios de Não Ampliação: A ampliação é proibida se:
  • O próprio recipiente estiver ausente (ex: intervalos de páginas inexistentes).
  • A entidade nunca aparece no escopo do documento (ex: um ano específico não coberto).
  • A pergunta pede um complemento contra um universo ilimitado (ex: "ícones não encontrados").
  • O conjunto é curto, mas não vazio (ex: perguntar por dois itens quando apenas um existe).
• Verificação: Este processo depende de verificações de vacuidade executáveis em vez da intuição do revisor para evitar erros silenciosos.

Principais Contribuições e Resultados

• Corpus Corrigido: O V2 contém 1.071 perguntas em 134 documentos (reduzido de 1.082/135).
• Registro de Anotação: Um registro público de 106 correções com evidências de suporte é fornecido.
• Harness de Avaliação: Um harness de avaliação de código aberto é lançado, implementando o juiz LLM fixado.
• Fatia "Não Respondível": 208 perguntas (19,4%) permanecem não respondíveis, com 14 chaves ampliadas de acordo com o novo procedimento de decisão.
• Impacto na Pontuação: As pontuações do V2 não são comparáveis aos números do V1. As pontuações são geralmente mais altas para os mesmos sistemas, com os maiores ganhos observados em tarefas de lista e texto livre, onde a métrica de string anteriormente penalizava variações de formatação.

Significância e Limitações

O artigo posiciona o MMLongBench-Doc-V2 como um reparo necessário, em vez de uma substituição do benchmark original. Sua principal significância reside em:

• Restauração da Validade de Medição: Ao desacoplar a pontuação da identidade de string e corrigir erros sistemáticos de anotação, o benchmark reflete melhor as capacidades reais de compreensão de documentos de um modelo.
• Preservação do Design "Não Respondível": O benchmark continua sendo um dos poucos conjuntos onde responder confiantemente a uma pergunta não suportada acarreta uma penalidade, um recurso que o autor argumenta ser essencial para detectar alucinação.
• Rigor Metodológico: A introdução de um procedimento de decisão formal para chaves de "conjunto vazio" e a publicação transparente de registros de correção estabelecem um padrão para a manutenção futura de benchmarks.

Limitações:

• Viés de Auditoria: As correções foram derivadas de perguntas que um sistema específico respondeu com confiança, mas pontuou como zero. Consequentemente, a taxa de erro geral do corpus permanece não medida; uma auditoria de amostragem aleatória uniforme não foi realizada.
• Cobertura de Tipo de Tarefa: A verificação foi minuciosa para as tarefas de lookup, derive, compare e verify, mas menos completa para as tarefas de count e enumerate, onde cerca de 95 linhas permanecem onde um sistema capaz discorda da chave, mas o erro não pôde ser provado.
• Rótulos Automatizados: Os rótulos de tipo de tarefa e requires_visual foram gerados por uma única passagem de modelo e não são verdade fundamental verificada por humanos.
• Falibilidade do Juiz: Embora o juiz seja fixado e explicitamente regrado, ele ainda é um modelo e não é infalível.

O autor conclui que o corpus corrigido, os registros por entrada e o harness de avaliação estão disponíveis sob Apache 2.0, convidando a novas correções via issues que citem páginas e entradas específicas.