Datalab lança o OmniParseBench, um benchmark aberto para parsing de documentos

A Datalab publicou o OmniParseBench, um benchmark aberto para OCR e parsing de documentos que, segundo a empresa, foi estruturado em torno de 16.288 testes. De acordo com a página do projeto no PyPI e com a publicação da Datalab em seu blog, o benchmark avalia páginas individuais por meio de verificações binárias, em vez de usar distância de edição contra uma única saída de referência. Na prática, cada teste pergunta se um determinado elemento está presente na saída de um provedor, na ordem correta, em uma célula específica de tabela ou dentro de um bloco de layout de certo tipo. A Datalab apresenta isso como uma forma de concentrar a avaliação em saber se os sistemas extraíram o conteúdo correto, e não se reproduziram um único estilo de saída considerado preferencial.

Um benchmark construído como testes unitários

O protocolo descrito no PyPI é centrado em afirmações de nível de página, respondidas com sim ou não. Um teste pode verificar um ou mais argumentos, cada um correspondente a um conteúdo em um ponto específico da página. O benchmark agrupa os resultados em três famílias: texto, tabelas e layout. A pontuação principal é a média das pontuações dessas três famílias.

Esse desenho é importante porque, na narrativa da Datalab, benchmarks mais antigos ficaram mais fáceis de otimizar por meio de ajustes de formatação ou de pós-processamento específico para benchmark. Em sua publicação no blog, a empresa argumenta que alternativas amplamente usadas podem recompensar mais a conformidade com convenções de saída esperadas do que a qualidade subjacente do modelo. Essas críticas são alegações da Datalab, e não conclusões independentes presentes nas fontes fornecidas, mas ajudam a explicar por que a empresa diz ter criado o OmniParseBench e por que pretende usá-lo em seus próprios relatórios de lançamento.

Quanto à cobertura, o PyPI afirma que cada teste recebe marcações em várias dimensões. Elas incluem tags de estrutura, como table, math, form e multi_column; tags de renderização, como handwriting, tiny, rotated e degraded; tags de função, como heading, caption, footnote, list, code, figure e header_footer; tags de escrita baseadas na ISO 15924; e tags de idioma baseadas na ISO 639-3. As tags não determinam se um teste passa ou falha. Em vez disso, elas permitem que os usuários recortem o benchmark e avaliem subconjuntos dos dados. Como um mesmo teste pode carregar várias tags, as pontuações por tag se sobrepõem e não retornam, por média simples, ao número principal de manchete.

Como funcionam a pontuação e as execuções

O benchmark pode ser executado no conjunto de dados da Datalab hospedado no Hugging Face ou em um conjunto de dados do próprio usuário, segundo a descrição no PyPI. Ele também expõe primitivas de pontuação e de predição de nível mais baixo, para que equipes possam integrá-lo aos seus próprios pipelines de avaliação. Uma execução pode ser retomada, e cada configuração de provedor é tratada como uma execução própria. O projeto diz que cada execução grava um arquivo scores.jsonl com uma linha por teste, enquanto os resultados resumidos podem ser lidos em summary.json.

A pontuação não reduz todos os resultados a aprovação ou reprovação. O PyPI lista quatro veredictos:

• pass
• fail
• unsupported, quando um provedor não consegue produzir a saída solicitada
• error, quando a própria correção gera um problema, em vez de o provedor falhar

Uma escolha metodológica notável é que os veredictos unsupported e error são excluídos de toda pontuação, em vez de serem contados como falhas. O PyPI diz que isso busca evitar punir fornecedores por saídas que eles não conseguem produzir ou por bugs no corretor. Ao mesmo tempo, isso significa que as comparações entre sistemas podem depender em parte de quais tipos de saída um provedor suporta. Um sistema que não consegue emitir uma determinada representação pode ter esses testes removidos de sua nota, em vez de receber zero neles.

O projeto também informa que os adaptadores de provedores usam o mesmo tempo limite por chamada e, por padrão, as configurações mais precisas de cada provedor. As ferramentas da Datalab podem chamar APIs de fornecedores, mas pedem confirmação antes de fazer isso, porque essas chamadas têm custo. O pacote exige Python 3.11 ou posterior e é distribuído sob Apache 2.0 para o código, enquanto os dados e os testes carregam licenças mistas, dependendo da fonte.

O que é público, e o que não é

Pelas fontes fornecidas, o lançamento público inclui claramente código, documentação e um benchmark empacotado no PyPI. O PyPI também afirma que o repositório contém uma forma de executar o benchmark usando o conjunto de dados da Datalab no Hugging Face ou dados do próprio usuário. A mesma página direciona os usuários para uma documentação que cobre a API, o desenho do benchmark, a construção dos testes, os provedores e o sistema de tags. Ela também afirma que, se os usuários encontrarem um teste incorreto, podem abrir uma issue, o que sugere que o benchmark foi pensado para ser inspecionável e passível de correção.

No entanto, as fontes disponíveis não trazem uma decomposição completa dos 16.288 testes por família, idioma, escrita ou tipo de documento. Elas também não incluem resultados agregados de leaderboard do próprio OmniParseBench. Assim, o número de 16.288 testes é relatado aqui como parte do enquadramento do benchmark, mas os textos fornecidos não detalham a divisão exata por trás desse total. Da mesma forma, não há, no material de origem, números de desempenho em escala do benchmark mostrando quais provedores lideram em texto, tabelas ou layout.

Resultados alegados em torno de outros benchmarks

Em vez de publicar resultados de leaderboard do OmniParseBench nos materiais fornecidos, o blog da Datalab se concentra em explicar por que a empresa acredita que os benchmarks existentes são insuficientes. A empresa diz que o olmOCR está saturado e cita exemplos em que o pós-processamento pode alterar as pontuações reportadas em cerca de um ou dois pontos. Ela também argumenta que o ParseBench pode ser fortemente influenciado pela formulação do prompt, por convenções de formatação e por pipelines especializados, especialmente para gráficos e visual grounding. Essas são alegações substanciais feitas pela Datalab, mas devem ser lidas como o relato da empresa. Nenhuma validação independente está incluída nas fontes disponibilizadas.

Ainda assim, essas alegações ajudam a iluminar o que o OmniParseBench está tentando otimizar. As verificações de sim ou não do benchmark são apresentadas explicitamente como mais difíceis de manipular do que abordagens baseadas em correspondência com referência. A Datalab argumenta que essa estrutura deve produzir sinais de erro mais claros, porque um teste reprovado corresponde a um erro específico em uma página específica. Isso pode facilitar para desenvolvedores de modelos e compradores corporativos enxergar se um sistema tem dificuldade, por exemplo, com texto rotacionado, formulários, escrita à mão ou estrutura de tabelas, em vez de ver apenas uma pontuação única e agregada.

Limites visíveis no próprio lançamento

O próprio desenho do OmniParseBench também cria limites. Em primeiro lugar, as fontes fornecidas não mostram resultados completos no nível do benchmark, de modo que leitores externos ainda não podem avaliar se ele produz rankings materialmente diferentes dos de alternativas mais antigas. Em segundo lugar, como saídas unsupported são omitidas da pontuação, o benchmark pode recompensar a qualidade dentro do intervalo de saídas suportadas por um provedor, e não a amplitude dos tipos de saída. Em terceiro lugar, os recortes por tags se sobrepõem por definição, o que é útil para diagnóstico, mas pode tornar menos intuitiva a interpretação dos resumos.

Também há restrições práticas. Executar fornecedores exige chaves de API e chamadas pagas. O benchmark pode ser retomado e comparado entre execuções, mas a reprodutibilidade ainda pode variar conforme as configurações do provedor, porque cada configuração constitui uma execução própria. Por fim, o conjunto de dados herda licenças mistas de suas fontes, e a Datalab observa que os conjuntos de dados de origem também devem ser citados. Isso não reduz o valor do benchmark, mas significa que sua adoção em fluxos de avaliação de produção pode exigir revisão jurídica e operacional.

Para empresas que atuam em inglês, a mudança concreta é que o OmniParseBench oferece uma forma mais inspecionável de testar sistemas de IA para documentos página por página, com recortes para tabelas, layout, escritas e condições difíceis de renderização, em vez de uma única nota opaca. Na prática, isso pode ajudar equipes a comparar fornecedores ou modelos internos com base nos recursos documentais que realmente importam para elas, mas também convém verificar quais saídas estão marcadas como unsupported, revisar os termos de licenciamento do benchmark e evitar tratar qualquer pontuação principal isolada como uma medida completa da qualidade de compreensão de documentos.