A 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 concebido em torno de 16 288 testes. De acordo com a página do projeto no PyPI e com a publicação da Datalab no seu blogue, o benchmark avalia páginas individuais através de verificações binárias, em vez de recorrer à distância de edição face a uma única saída de referência. Na prática, cada teste pergunta se um determinado elemento está presente na saída de um fornecedor, na ordem correta, numa célula específica de uma tabela ou dentro de um bloco de layout de certo tipo. A Datalab apresenta esta abordagem como uma forma de se concentrar em saber se os sistemas extraíram o conteúdo correto, e não se corresponderam a um único estilo de saída considerado preferencial.

Um benchmark concebido como testes unitários

O protocolo descrito no PyPI está centrado em afirmações à escala da página, com resposta sim ou não. Um teste pode verificar um ou mais argumentos, correspondendo cada um deles a conteúdo localizado num ponto 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 destas três famílias.

Este desenho é relevante porque, na explicação da Datalab, os benchmarks mais antigos tornaram-se mais fáceis de otimizar através de ajustes de formatação ou de pós-processamento específico para o próprio benchmark. No artigo do blogue, a empresa defende que alternativas amplamente utilizadas 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, não conclusões independentes presentes nas fontes fornecidas, mas ajudam a explicar por que razão a empresa afirma ter construído o OmniParseBench e por que tenciona usá-lo nos seus próprios relatórios de lançamentos.

Quanto à cobertura, o PyPI indica que cada teste é etiquetado em várias dimensões. Estas incluem etiquetas de estrutura, como table, math, form e multi_column; etiquetas de renderização, como handwriting, tiny, rotated e degraded; etiquetas de função, como heading, caption, footnote, list, code, figure e header_footer; etiquetas de escrita baseadas na norma ISO 15924; e etiquetas de língua baseadas na ISO 639-3. As etiquetas não determinam se um teste passa ou falha. Em vez disso, permitem aos utilizadores segmentar o benchmark e pontuar subconjuntos dos dados. Como um mesmo teste pode ter várias etiquetas, as pontuações por etiqueta sobrepõem-se e não regressam por média ao número principal.

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

Segundo a descrição no PyPI, o benchmark pode ser executado sobre o conjunto de dados da Datalab alojado no Hugging Face ou sobre um conjunto de dados do próprio utilizador. Também disponibiliza primitivas de mais baixo nível para pontuação e previsão, para que as equipas o possam integrar nas suas próprias pipelines de avaliação. Uma execução pode ser retomada, e cada configuração de fornecedor é tratada como uma execução independente. O projeto afirma que cada execução escreve um ficheiro scores.jsonl com uma linha por teste, enquanto os resultados de síntese podem ser lidos a partir de summary.json.

A pontuação não reduz todos os resultados a passar ou falhar. O PyPI enumera quatro veredictos:

• pass
• fail
• unsupported, quando um fornecedor não consegue produzir a saída pedida
• error, quando a própria avaliação levanta um problema em vez de o fornecedor falhar

Uma escolha metodológica assinalável é que os veredictos unsupported e error são excluídos de qualquer pontuação, em vez de contarem como falhas. O PyPI diz que isto pretende evitar penalizar fornecedores por saídas que não conseguem produzir ou por erros no avaliador. Ao mesmo tempo, isso significa que as comparações entre sistemas podem depender em parte dos tipos de saída que cada fornecedor suporta. Um sistema que não consiga emitir uma determinada representação pode ver esses testes excluídos da sua pontuação, em vez de receber zeros nesses casos.

O projeto refere ainda que os adaptadores de fornecedores usam o mesmo tempo limite por chamada e, por defeito, as definições mais precisas de cada fornecedor. As ferramentas da Datalab podem chamar APIs de fornecedores, mas pedem confirmação antes de o fazer, porque essas chamadas têm custo. O pacote requer Python 3.11 ou posterior e é distribuído sob licença Apache 2.0 para o código, enquanto os dados e os testes têm licenças mistas consoante a origem.

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

A partir das fontes fornecidas, a publicação pública inclui claramente código, documentação e um benchmark empacotado no PyPI. O PyPI refere também 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 utilizador. A mesma página remete os utilizadores para documentação sobre a API, o desenho do benchmark, a construção dos testes, os fornecedores e a etiquetagem. Refere ainda que, se os utilizadores 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 fornecem uma decomposição completa dos 16 288 testes por família, língua, escrita ou tipo de documento. Também não incluem resultados agregados de leaderboard do próprio OmniParseBench. Assim, o número de 16 288 testes é aqui referido como parte do enquadramento apresentado para o benchmark, mas os textos fornecidos não detalham a repartição exata por detrás desse total. Do mesmo modo, o material de origem não traz números de desempenho à escala do benchmark que mostrem que fornecedores 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 blogue da Datalab concentra-se em explicar por que considera insuficientes os benchmarks existentes. A empresa afirma que o olmOCR está saturado e cita exemplos em que o pós-processamento pode alterar as pontuações comunicadas em cerca de um ou dois pontos. Defende também que o ParseBench pode ser fortemente influenciado pela formulação do prompt, por convenções de formatação e por pipelines especializadas, sobretudo em gráficos e visual grounding. Estas são alegações substanciais feitas pela Datalab, mas devem ser lidas como o relato da empresa. Não existe validação independente nas fontes disponibilizadas.

Ainda assim, essas alegações ajudam a esclarecer o que o OmniParseBench está a tentar 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 uma referência. A Datalab defende que esta estrutura deve produzir sinais de erro mais claros, porque um teste falhado corresponde a um erro específico numa página específica. Isso pode facilitar a vida a programadores de modelos e a compradores empresariais que queiram perceber se um sistema tem dificuldades, por exemplo, com texto rodado, formulários, escrita manual ou estrutura de tabelas, em vez de ver apenas uma pontuação agregada.

Limites visíveis na própria publicação

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

Há também constrangimentos práticos. Executar fornecedores requer chaves de API e chamadas pagas. O benchmark pode ser retomado e comparado entre execuções, mas a reprodutibilidade pode ainda variar com as definições dos fornecedores, porque cada configuração conta como uma execução própria. Por fim, o conjunto de dados herda licenças mistas das fontes de origem, e a Datalab nota que os datasets a montante também devem ser citados. Isto não reduz o valor do benchmark, mas significa que a adoção em fluxos de avaliação de produção pode exigir análise jurídica e operacional.

Para empresas de língua inglesa, a mudança concreta é que o OmniParseBench oferece uma forma mais inspecionável de testar sistemas de IA documental página a página, com recortes para tabelas, layout, escritas e condições de renderização difíceis, em vez de uma única pontuação opaca. Na prática, isto pode ajudar equipas a comparar fornecedores ou modelos internos nas características documentais que realmente lhes interessam, mas convém também verificar que saídas surgem como unsupported, rever 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.