Incrível ou superestimado? Testei o parsing de documentos do OXR com meus próprios PDFs horríveis

Autoria: Prompt Engineer 48 · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: AWESOME or Overhyped? OXR Document Parsing, Tested With My Own Ugly PDFs · Canal: Prompt Engineer 48 · 10:21 · Assistir no YouTube

Tópicos: Avaliação e benchmarks de IA, Infraestrutura e hardware de IA, Modelos de IA, Open source e ecossistemas de software, RAG, busca e recuperação de informação

Resumo

O vídeo testa o OXR, um modelo de parsing de documentos que seus autores dizem liderar três benchmarks, embora o repositório tenha poucas estrelas e o relatório técnico ainda não esteja disponível. Após falhas na API gratuita e dificuldades para configurar o modelo, o apresentador o executa em uma GPU alugada e testa exemplos, um artigo acadêmico e um recibo fotografado. O OXR processa bem alguns documentos, inclusive tabelas complexas e fórmulas, mas falha no reconhecimento de um recibo e apresenta uma saída repetitiva em uma demonstração. A conclusão é que o modelo parece promissor, mas os testes são limitados e a licença tem restrições comerciais e de uso como serviço online.

Pontos-chave

Os autores afirmam que o modelo, com 1,3 bilhão de parâmetros, lidera três benchmarks de parsing de documentos; o apresentador não consegue verificar essa classificação.
A API gratuita retorna erros 429, e o computador do apresentador não atende aos requisitos de memória GPU indicados.
A execução em uma GPU alugada exigiu ajustes de ambiente, download do modelo e alteração da porta do serviço de layout.
Em alguns testes, o OXR reconhece texto, fórmulas em LaTeX, tabelas com células mescladas e a estrutura de um artigo acadêmico.
Na página de demonstração, uma imagem de prova gerou uma repetição de caracteres; o apresentador não confirma a causa.
Um recibo fotografado teve preços associados às linhas erradas, endereço ausente e total sem valor.
A licença permite uso comercial apenas dentro de limites de financiamento e receita e impõe condições para serviços online.
O apresentador considera o OXR promissor, mas ressalta que seus poucos testes não comprovam a precisão estatística nem a alegação dos autores.

Capítulos

Início	Capítulo	Resumo
00:00	A alegação do OXR e os limites da API gratuita	O apresentador introduz as alegações sobre o modelo, explica sua arquitetura em termos gerais e relata que a API gratuita falhou nos primeiros testes.
02:18	Aluguel de GPU e configuração	Sem memória suficiente no próprio computador, o apresentador aluga uma GPU e resolve problemas de ambiente e de configuração para iniciar os serviços.
04:36	Testes com exemplos, tabelas e um artigo	O OXR processa exemplos e um artigo acadêmico, com resultados positivos em elementos como fórmulas e tabelas, mas também apresenta uma saída repetitiva na demonstração.
07:36	Falha no recibo e restrições da licença	O teste com um recibo fotografado revela erros na associação de preços e campos, e o apresentador explica as condições adicionais da licença.
09:13	Veredito: promissor, mas ainda não comprovado	O apresentador resume os acertos e as falhas, ressalta que seus testes não verificam a classificação nos benchmarks e encerra com o custo do experimento.

Citações

Ou acabei de encontrar uma mina de ouro ou o README está exagerando. — 00:00

É uma falha real e está registrada em vídeo. — 05:38

É o primeiro fracasso honesto, e prefiro mostrá-lo. — 08:08

É promissor, não mágico. — 09:45

Conceitos e entidades

OXR (modelo): Modelo de parsing de documentos testado no vídeo, que transforma PDFs e imagens em saídas como Markdown ou JSON.
document parsing (conceito): Processo de extrair e organizar texto, tabelas e outros elementos estruturais de documentos.
layout model (conceito): Componente separado que analisa o layout do documento e que, segundo a descrição do OXR, pode ser substituído.
recursive self-improvement loop (conceito): Processo descrito pelos autores em que o modelo é treinado repetidamente com páginas que processou incorretamente, sem rótulos humanos.
RunPod (empresa): Serviço usado pelo apresentador para alugar uma GPU e executar o OXR.
vLLM (ferramenta): Ferramenta mencionada na inicialização dos serviços usados para executar o modelo.
Apache License 2.0 (conceito): Licença citada no vídeo, cuja página de demonstração não exibia os termos adicionais presentes no arquivo de licença.

Tradução completa (pt-BR)

00:00 Certo, preciso mostrar uma coisa para vocês e, sinceramente, ainda não sei se é real. Este é o OXR. Os autores dizem que um modelo com 1,3 bilhão de parâmetros ocupa o primeiro lugar em três benchmarks de parsing de documentos. Três benchmarks, e o repo tem cerca de 180 estrelas. Isso é muito pouco. Coisas tão boas geralmente têm milhares. Então, ou acabei de encontrar uma mina de ouro, ou o README está exagerando. Vou descobrir diante das câmeras, usando os próprios exemplos deles e alguns documentos feios meus. >> [música]

00:32 >> Oi, sou Prompt Engineer. De verdade, não sei como isso vai terminar. Então fique comigo. Vamos descobrir juntos. Resumindo a alegação: você fornece um PDF ou uma imagem e recebe markdown ou JSON, com coordenadas para cada bloco. São 13 tipos de elementos: tabelas, fórmulas, blocos de código, até estruturas químicas e carimbos. E tem uma escolha de design de que gosto. A análise de layout é feita por um modelo separado, que você pode substituir, enquanto o OXR faz a leitura e determina a ordem de leitura. Então, se seus documentos forem diferentes, como notas fiscais, você pode conectar seu próprio modelo de layout. Eles também dizem que ele passou por pós-

01:05 treinamento com um ciclo recursivo de autoaperfeiçoamento. Basicamente, encontram as páginas em que o modelo erra, treinam com elas e repetem o processo sem rótulos humanos. Essa é a descrição deles. O relatório técnico diz que será publicado em breve, então não posso verificar como essa parte funciona. O que posso verificar é o resultado. E um detalhe sobre o model card: o README diz 1,3 bilhão de parâmetros, mas o Hugging Face lista cerca de 1,53 bilhão. É um detalhe pequeno, mas eu notei.

01:46 Primeiro plano: usar a API gratuita deles no meu próprio computador. O README diz que não precisa se cadastrar nem de uma chave. Então instalei a ferramenta de linha de comando Somar, baixei três exemplos do README e executei o primeiro. Nada. Flag errada. A pasta de saída precisa já existir. Tudo bem, criei as pastas e executei de novo. Erro 429: muitas solicitações. Ele tentou novamente por quase 4 minutos e depois desistiu. Segundo arquivo, mesma coisa. Terceiro arquivo, mesma coisa. Não sei dizer por quê. Talvez muita gente esteja tentando usar agora. De qualquer forma, esse plano morreu, e API gratuita não é um plano. Certo, então posso simplesmente rodar isso aqui? É meu notebook. RTX 4060, 8 GB de VRAM no

02:18 Windows. O README diz que é preciso Linux e 24 GB de memória de GPU só para começar. Então, não, não vou fingir que consegui enfiar o modelo real numa GPU real. Vou alugar uma. A conta é simples: 24 GB é o mínimo, então preciso de uma placa de 24 GB, e o driver tem que ser compatível com CUDA 13. Consultei os preços em tempo real pela API do RunPod. RTX 3090, 24 GB, 22 centavos por hora na community cloud. RTX 4090, a mesma memória, 34 centavos. As duas estavam marcadas como com pouco estoque. Escolhi a 4090 por 34 centavos por hora e cliquei em criar.

03:00 Erro de capacidade. Mudei o limite de CUDA, fixei o data center e tentei de novo. Erro de capacidade. Mudei para a 3090, mais barata. A mesma coisa. Três tentativas, três falhas. E, sinceramente, essa é a parte que ninguém mostra. Então paguei mais: secure cloud, 89 centavos por hora pela 4090. E sempre confiro a resposta da criação, porque o preço informado e o preço final podem ser diferentes. Custo: 0,89, igual ao preço informado. O pod está rodando. A primeira coisa no pod: o NVIDIA diz que é uma RTX 4090, com 24 GB, driver 595, CUDA 13.2,

03:30 Ubuntu 24.04, Python 3.12. Não tinha Docker, então segui o caminho de execução a partir do código-fonte indicado no README. Foi aí que a coisa ficou séria. No primeiro script de instalação, o pip se recusou a funcionar. Ambiente gerenciado externamente: é o Ubuntu se protegendo. Então mudei para ambientes virtuais UV. Depois percebi que isso significava não ter o comando HF. Por isso, o download do modelo simplesmente não aconteceu, sem avisar. Percebi, executei

04:02 no ambiente certo, e 3 GB foram baixados em cerca de 6 segundos. Depois, o script de inicialização do VLLM tentou chamar o pip dentro de um ambiente que não tem pip. Em seguida, o serviço de layout informou que a porta 8081 já estava em uso. Era o próprio Engine X do RunPod. Mudei para a porta 8091, editei a configuração e, finalmente, os três serviços estavam funcionando.

04:36 Um número de que gosto: os pesos do modelo carregam em cerca de 3 segundos e ocupam 2,6 GB na GPU. Com os três serviços funcionando, o nvidia-smi mostrou cerca de 23 GB em uso, e a maior parte disso era o VLLM reservando cache, não o modelo. Primeiro teste: os exemplos do README. Peguei a prova A3 e enviei três imagens. Só isso: três blocos, todos imagens, nenhum texto. Meu estômago afundou, então abri a imagem. O exemplo do README está no documento. É um pôster. O original à esquerda, o layout no meio e a prévia do parsing à direita. Enviei o pôster inteiro, e ele

05:08 identificou corretamente três imagens. Meu erro, não do modelo. Então recortei o painel original e executei de novo. Pela API, o resultado veio com 42 blocos: 34 textos, seis títulos e duas imagens, em 1,5 segundo. Uma prova de matemática chinesa, e as fórmulas são retornadas como

05:38 LaTeX, como x = 1 + a raiz quadrada de 2002 sobre 2. Mas depois executei a mesma imagem na página de demonstração, e levou 43 segundos. Olhe para o lado direito. A área do cabeçalho aparece e, em seguida, vem um paredão do mesmo caractere repetido. Na demonstração, o reconhecimento de cabeçalho e rodapé estava ativado. Não testei com ele desativado, então não posso dizer que essa seja a causa, mas é uma falha real, e está gravada.

06:13 A tabela complexa foi processada com as células de cabeçalho mescladas preservadas como row spans e column spans em HTML, e é aí que muitos parsers se perdem. A primeira chamada levou 13 segundos porque tudo ainda estava inicializando. A caligrafia em inglês foi processada em cerca de um segundo, com o texto do parágrafo legível. Só estou comparando com a prévia do próprio pôster, então não estou alegando números de precisão. Estou dizendo que ele não desmoronou.

06:46 Agora, algo de verdade: Attention Is All You Need. O PDF original do arXiv, 15 páginas, duas colunas, equações, tabelas: 11,8 segundos para processar tudo. Ele encontrou oito fórmulas, quatro tabelas, nove legendas e cinco figuras. Título, bloco de autores e resumo na ordem certa; o texto do resumo que conferi corresponde ao artigo.

07:36 A interface de demonstração facilita a visualização. Você envia o arquivo e recebe a prévia, o conteúdo de origem e o layout, com as caixas e a ordem de leitura. Esta é a página de um recibo, o que me leva à parte em que não funciona. Fiz este recibo: uma foto de celular borrada e girada, com itens, preços, imposto e um total. O total correto é 34,32. Agora, olhe a tabela: os preços estão deslocados uma linha em relação aos itens. O leite de aveia não tem preço, e o primeiro preço aparece numa linha em branco. As linhas do endereço sumiram, e o total não tem número. Os números do subtotal e do imposto estão lá,

08:08 mas associados aos rótulos errados. Então, ele entendeu que era uma tabela, mas interpretou a estrutura incorretamente. Recibo sintético, uma imagem, então, por favor, não interpretem isso como um benchmark. Mas é a primeira falha honesta, e prefiro mostrá-la.

08:42 Antes de construir um negócio com isso, leia a licença. Baixei-a do pod. É Apache 2.0 com termos adicionais. O uso comercial é gratuito apenas enquanto você e suas afiliadas permanecerem abaixo de US$ 2 milhões em financiamento total e abaixo de US$ 2 milhões em receita anual. Se ultrapassar qualquer um desses limites, você precisa de uma licença separada. Se executar isso como um serviço online, deve dar crédito ao SoMark OXR e não pode oferecer uma API hospedada de parsing de documentos concorrente, independentemente do tamanho. O uso interno é permitido. Além disso, o rodapé da página de demonstração diz apenas Apache 2.0. O arquivo da licença é o que

09:13 vale. Então, mina de ouro? Aqui vai minha resposta sincera. A velocidade é real na maioria das execuções: de menos de um segundo a cerca de 13 segundos em uma única placa de 24 GB. Além disso, aquele ciclo de 143 segundos, as tabelas mescladas, as fórmulas, o texto em chinês e um artigo real me pareceram corretos. Mas ele falhou duas vezes. Ficou repetindo no cabeçalho A3 da demonstração e

09:45 embaralhou meu recibo. O primeiro lugar em três benchmarks é uma alegação dos autores. O relatório técnico ainda está por vir, e cinco documentos meus não provam nada estatisticamente. Ainda está no começo, com 180 estrelas, uma licença personalizada e uma API gratuita que estava caindo. Não consigo confirmar a classificação com o que pude testar. É promissor, não é mágico. Custo total do experimento: o pod rodou por cerca de 16 minutos, a 89 centavos por hora, aproximadamente 24 centavos, pelas minhas contas. Encerrei o pod, e a lista de pods está vazia.

10:21 Se você está procurando GPUs baratas e confiáveis, eu uso Runpod, e o link está na descrição. Então, será que encontrei uma mina de ouro? Acho que encontrei algo que vale a pena acompanhar. Deixe nos comentários o documento mais feio que você tem, e vou processá-lo com o OXR e mostrar o resultado.

Transcrição original

[00:00] Okay, I need to show you something and honestly, I don’t know yet if it’s real. This is OX R. The authors say a 1.3 billion parameter model ranks number one on three document parsing benchmarks. Three and the repo has about 180 stars. That is tiny. Things this good usually have thousands. So either I just stumbled onto a gold mine or the read me is overselling. I’m going to find out on camera with their own examples and a couple of ugly documents of my own. >> [music]

[00:32] >> Hey, I’m Prompt Engineer. I genuinely don’t know how this one ends. So stay with me. Let’s find out together. Quick version of the claim. You give it a PDF or an image and you get markdown or JSON back with coordinates for every block. 13 element types, tables, formulas, code blocks, even chemical structures and stamps. And here’s the design choice I like. Layout analysis is a separate model you can swap out while OX R does the reading and the reading order. So if your documents are weird, say invoices, you can plug in your own layout model. They also say it was post

[01:05] trained with a recursive self-improvement loop. Roughly, find the pages the model gets wrong, train on those, repeat without human labels. That’s their description. The technical report says coming soon, so I can’t check how that part works. What I can check is the output. And one small thing on the model card, the read me says 1.3 billion parameters, but hugging face lists about 1.53 billion. Small thing, but I noticed it.

[01:46] First plan, use their free API from my own machine. The read me says no sign up, no key. So I installed the Somar command line tool, downloaded three of the read me examples and ran the first one. Nothing. Wrong flag. The output folder has to exist already. Fine, made the folders, ran it again. 429 too many requests. It retried for almost 4 minutes, then gave up. Second file, same. Third file, same. I can’t tell why. Maybe a lot of people are trying it right now. Either way, that plan is dead and free API is not a plan. Okay, so can I just run it here? It’s my laptop. RTX 4060, 8 GB of VRAM on

[02:18] Windows. The readme says Linux and 24 GB of GPU memory just to get started. So, no, I’m not going to pretend I squished it in real model, real GPU. I rent one. The math is simple. 24 GB is the floor, so I need a 24 gig card, and the driver has to support CUDA 13. I pulled live prices from the RunPod API. RTX 3090, 24 gigs, 22 cents an hour on community cloud. RTX 4090, same memory, 34 cents. Both marked low stock. I went for the 4090 at 34 cents an hour and hit create.

[03:00] Capacity error. I changed the CUDA floor, pinned the data center, tried again. Capacity error. Switched to the cheaper 3090. Same thing. Three tries, three failures. And honestly, that’s the part nobody shows you. So, I paid more, secure cloud, 89 cents an hour for the 4090. And I always check the create response because the quoted price and the built price can differ. Cost 0.89, same as the quote. Pod running. First thing on the pod, NVIDIA says me RTX 4090, 24 GB driver 595, CUDA 13.2,

[03:30] Ubuntu 2404, Python 312. No Docker here, so I followed the readme’s run from source path instead. This is where it got real. First install script, pip refuses. Externally managed environment, that’s Ubuntu protecting itself. So, I switched to UV virtual environments. Then I realized that meant no HF command. So, the model download silently never ran. I caught it, ran it

[04:02] from the right environment, and 3 GB came down in about 6 seconds. Then the VLLM start script tried to call pip inside an environment that has no pip. And then the layout service said port 8081 was already in use. That was runpod’s own engine X. I moved it to 8091, edited the config, and finally all three services were up.

[04:36] One number I like, the model weights load in about 3 seconds and take 2.6 GB on the GPU. With all three services running, Nvidia-smi showed about 23 gigs used, and most of that is VLLM reserving cache, not the model. First test, the readme examples. I grabbed the A3 exam paper and sent it three pictures. That’s it, three blocks, all pictures, no text. My stomach dropped, then I opened the image. The readme example is in the document. It’s a poster. Original on the left, layout in the middle, parsed preview on the right. I fed it the whole poster, and it

[05:08] correctly saw three pictures. My mistake, not the model’s. So, I cropped out the original panel and ran it again. Through the API, that came back as 42 blocks, 34 texts, six titles, two pictures in 1 and 1/2 seconds. A Chinese math exam, and the formulas come back as

[05:38] LaTeX, like x = 1 + the square root of 2002 over 2. But then I ran the same image on the demo page, and it took 43 seconds. Look at the right side. The header area comes back and then a wall of the same repeated character. The demo had header and footer recognition switched on. I didn’t test it off, so I can’t tell you that’s the cause, but it is a real failure and it’s on camera.

[06:13] The complex table came through with the merged header cells kept as HTML row spans and column spans, which is where a lot of parsers lose the plot. The first call took 13 seconds because everything was warming up. The English handwriting came back in about a second with the paragraph text readable. I’m only comparing against the poster’s own preview, so I’m not claiming accuracy numbers. I’m saying it didn’t fall over.

[06:46] Now, something real. Attention is all you need. The actual arXiv PDF, 15 pages, two columns, equations, tables, 11.8 seconds for the whole thing. It found eight formulas, four tables, nine captions, and five figures. Title, author block, abstract in the right order, and the abstract text I checked matches the paper.

[07:36] The demo interface makes this easy to see. You upload and you get preview, source, and layout with the boxes and the reading order. This is the receipt page, which brings me to the part where it doesn’t work. I made this receipt myself, a blurry, rotated phone photo with items, prices, tax, and a total. The correct total is 34.32. Now, look at the table, the prices are shifted one row from the items. Oat milk has no price, and the first price sits on a blank row. The address lines are gone, and the total has no number. The subtotal and tax numbers are in there,

[08:08] but on the wrong labels. So, it understood this was a table and got the structure wrong. Synthetic receipt, one image, so please don’t read this as a benchmark, but it’s the first honest failure, and I’d rather show it.

[08:42] Before you build a business on it, read the license. I pulled it off the pod. It’s Apache 2.0 plus extra terms. Commercial use is free only while you and your affiliates stay under $2 million in total funding and under $2 million in annual revenue. Go over either, and you need a separate license. If you run it as an online service, you must credit So Mark OXR, and you can’t offer a competing hosted document parsing API at any size. Internal use is fine. Also, the demo page footer just says Apache 2.0. The license file is the one that

[09:13] counts. So, Goldmine, here’s my honest answer. The speed is real in most runs, from under a second to about 13 seconds on a single 24 gig Plus that 143-second loop, merged tables, formulas, Chinese text, and a real paper looked right to me. But it failed twice. It looped on the A3

[09:45] header in the demo, and it scrambled my receipt. The number one on three benchmarks is the author’s claim. The technical report is still coming, and five documents from me prove nothing statistical. It’s early, 180 stars, a custom license, and a free API that was falling over. I can’t confirm the ranking on what I could test. It’s promising, not magic. Total bill for the experiment. The pod ran about 16 minutes at 89 cents an hour, roughly 24 cents by my math. I terminated it, and the pod list is empty.

[10:21] If you’re looking for cheap and reliable GPUs, I use Runpod, and the link is in the description. So, did I find a gold mine? I think I found something worth watching. Drop the ugliest document you own in the comments, and I’ll run it through OXR and show you what comes back.