Tecnologia para converter PDF em Markdown com rapidez e alta precisão

 (github.com/VikParuchuri)
2 pontos por GN⁺ 2023-12-02 | 1 comentários | Compartilhar no WhatsApp
  • Marker é uma ferramenta de inteligência documental que converte com rapidez e precisão não só PDFs, mas também documentos em imagem, PPTX, DOCX, XLSX, HTML e EPUB para Markdown, JSON, chunks e HTML
  • Oferece suporte para formatar tabelas, formulários, equações, matemática inline, links, referências e blocos de código, além de extração e salvamento de imagens e remoção de artefatos como cabeçalhos e rodapés
  • Para aumentar a precisão, é possível usar um LLM junto com --use_llm; o padrão é gemini-2.0-flash, com suporte a Gemini, Ollama, Claude, OpenAI, Azure OpenAI e outros
  • Nos benchmarks, o Marker registrou média de 2.83837 segundos por página única de PDF, pontuação heurística de 95.6709 e pontuação LLM de 4.23916; no modo batch com H100, a expectativa é de throughput de 25 pages/second
  • Requer Python 3.10+ e PyTorch; o código está sob GPL, e os pesos do modelo usam uma licença AI Pubs OpenRAIL-M modificada, gratuita para pesquisa, uso pessoal e startups com menos de $2M

Documentos e saídas que o Marker converte

  • Marker converte documentos para Markdown, JSON, chunks e HTML
  • Os formatos de entrada incluem PDF, imagens, PPTX, DOCX, XLSX, HTML e EPUB, com suporte a documentos em todos os idiomas
  • Escopo de processamento de elementos do documento:
    • tabelas, formulários, equações e matemática inline
    • links, referências e blocos de código
    • extração e salvamento de imagens
    • remoção de cabeçalhos, rodapés e outros artefatos
  • Pode ser expandido com sua própria formatação e lógica
  • Ao fornecer um esquema JSON, pode realizar extração estruturada; esse recurso está em beta
  • Funciona em GPU, CPU e MPS

Plataforma gerenciada da Datalab

  • A plataforma gerenciada da Datalab executa o modelo open source mais recente Chandra
  • O Chandra é apresentado como mais preciso que o Marker, com retenção de dados desativada por padrão, além de SOC 2 Type 2 e BAA customizado
  • O serviço de processamento em lote para cargas de alto volume já processou mais de 200M páginas por semana
  • Ao se cadastrar, oferece $5 em créditos grátis, além de um playground público
  • O self-hosting comercial exige licença, e a licença on-premises é tratada separadamente

Desempenho e modo híbrido com LLM

  • O Marker apresenta resultados de benchmark favoráveis em relação a serviços em nuvem como Llamaparse e Mathpix, além de outras ferramentas open source
  • Os resultados completos de desempenho no README são baseados em execução serial por página única de PDF
  • No modo batch, ele é mais rápido, e em um H100 a expectativa é de throughput de 25 pages/second
  • Para máxima precisão, é possível usar um LLM junto com a flag --use_llm
    • mesclagem de tabelas que atravessam páginas
    • tratamento de matemática inline
    • melhoria da formatação de tabelas
    • extração de valores em formulários
  • O modo híbrido com LLM alcança maior precisão no benchmark de tabelas do que o Marker sozinho ou o Gemini Flash sozinho

Instalação e uso básico

  • Requer Python 3.10+ e PyTorch
  • Instalação voltada para PDF: 
    pip install marker-pdf
  • Para processar formatos de documento além de PDF, instale dependências extras 
    pip install marker-pdf[full]
  • Conversão de arquivo único: 
    marker_single /path/to/file.pdf
  • Conversão de múltiplos arquivos por pasta: 
    marker /path/to/input/folder
  • Conversão em várias GPUs: 
    NUM_DEVICES=4 NUM_WORKERS=15 marker_chunk_convert ../pdf_in ../md_out
    • NUM_DEVICES é o número de GPUs a usar e deve ser 2 ou mais
    • NUM_WORKERS é o número de processos paralelos por GPU

Principais opções de CLI

  • --page_range TEXT: especifica os números e intervalos de páginas a processar
  • --output_format [markdown|json|html|chunks]: define o formato de saída
  • --output_dir PATH: define o diretório onde salvar os arquivos de saída
  • --paginate_output: insere números de página e separadores na saída
  • --use_llm: aumenta a precisão com LLM
  • --force_ocr: força OCR em todo o documento e também formata corretamente matemática inline
  • --block_correction_prompt: define o prompt para corrigir a saída do Marker no modo LLM
  • --strip_existing_ocr: remove o texto OCR existente e refaz o OCR com surya
  • --redo_inline_math: melhora a qualidade da conversão de matemática inline junto com --use_llm
  • --disable_image_extraction: não extrai imagens do PDF
  • --converter_cls: seleciona o padrão marker.converters.pdf.PdfConverter ou o especializado em tabelas marker.converters.table.TableConverter
  • --llm_service: define o serviço de LLM ao usar --use_llm; o padrão é marker.services.gemini.GoogleGeminiService
  • --workers: define o número de workers de conversão simultânea
    • cada worker usa até 5GB de VRAM, com média de 3.5GB de VRAM

API Python e manipulação interna de blocos

  • É possível converter diretamente em Python com PdfConverter 
    from marker.converters.pdf import PdfConverter
from marker.models import create_model_dict
from marker.output import text_from_rendered

converter = PdfConverter(
    artifact_dict=create_model_dict(),
)
rendered = converter("FILEPATH")
text, _, images = text_from_rendered(rendered)
  • Em saída Markdown, rendered possui os atributos markdown, metadata e images
  • Em saída JSON, rendered possui children, block_type e metadata
  • Com ConfigParser, é possível configurar formato de saída, processors, renderers, serviço de LLM e mais
  • O documento é composto por uma árvore de páginas e blocos, e cada página pode conter blocos adicionais
  • Com contained_blocks, é possível extrair programaticamente apenas blocos específicos, como formulários

Tipos de conversor

  • PdfConverter: conversor padrão para PDFs completos
  • TableConverter: extrai e converte apenas tabelas
    • ao definir force_layout_block=Table, evita a detecção de layout e assume todas as páginas como tabelas
    • com output_format=json, também é possível obter as bounding boxes das células
  • OCRConverter: executa apenas OCR
    • ao definir --keep_chars, mantém caracteres individuais e suas bounding boxes
  • ExtractionConverter: conversor de extração estruturada em beta
    • é necessário configurar primeiro um serviço de LLM
    • retorna valores extraídos em saída JSON
    • ao passar original_markdown de uma execução anterior como existing_markdown, é possível pular o reparse do documento

Formatos de saída

  • Saída Markdown:
    • links de imagem
    • tabelas formatadas
    • equações LaTeX envoltas por $$
    • blocos de código com crases triplas
    • sobrescrito para notas de rodapé
  • Saída HTML:
    • imagens com tag img
    • equações com tag <math>
    • código com tag pre
  • Saída JSON:
    • representa páginas como lista, e cada página é um bloco do esquema interno do Marker
    • contém as chaves id, block_type, html, polygon e children
    • os blocos filhos incluem adicionalmente section_hierarchy e images
    • a estrutura dos blocos é em árvore
  • Saída Chunks:
    • semelhante ao JSON, mas achata tudo em uma única lista
    • inclui o HTML completo de cada bloco, o que permite uso flexível em chunking para RAG
  • Todos os formatos de saída retornam metadata
    • table_of_contents, que é o sumário calculado do PDF
    • page_stats, com o método de extração de texto e a quantidade de blocos por página

Serviços de LLM suportados

  • Serviços disponíveis ao usar --use_llm:
    • Gemini: usa por padrão a Gemini developer API e requer --gemini_api_key
    • Google Vertex: requer --vertex_project_id e a definição de marker.services.vertex.GoogleVertexService
    • Ollama: usa modelo local com --ollama_base_url e --ollama_model
    • Claude: requer --claude_api_key e --claude_model_name
    • OpenAI: suporta endpoints compatíveis com OpenAI com --openai_api_key, --openai_model e --openai_base_url
    • Azure OpenAI: requer --azure_endpoint, --azure_api_key e --deployment_name

Estrutura interna e pontos de extensão

  • O Marker funciona como um pipeline de modelos de deep learning
    • extração de texto e, se necessário, execução de OCR
    • detecção de layout de página e ordem de leitura
    • limpeza e formatação de cada bloco
    • melhoria de qualidade com LLM, quando necessário
    • combinação de blocos e pós-processamento do texto completo
  • As etapas ligadas a OCR e layout usam surya
  • A formatação relacionada a equações usa texify
  • Componentes centrais:
    • Providers: fornecem informações a partir de arquivos-fonte como PDF
    • Builders: criam os blocos iniciais do documento e preenchem o texto
    • Processors: processam blocos específicos, como formatadores de tabela
    • Renderers: renderizam os blocos no formato de saída
    • Schema: classes de todos os tipos de bloco
    • Converters: executam o pipeline end-to-end completo
  • Para alterar o comportamento do processamento, redefina processors
  • Novos formatos de saída podem ser adicionados escrevendo um novo renderer
  • Novos formatos de entrada podem ser adicionados escrevendo um novo provider

Servidor API e implantação

  • É possível executar um servidor simples com FastAPI 
    pip install -U uvicorn fastapi python-multipart
marker_server --port 8001
  • O servidor fica acessível em localhost:8001, e as opções de endpoint podem ser vistas em localhost:8001/docs
  • Este servidor API não é uma API robusta e foi pensado apenas para uso em pequena escala
  • Para opções de conversão mais robustas, é possível usar a Datalab API hospedada
  • Os exemplos de implantação incluem publicar um endpoint web com Modal

Solução de problemas

  • Se houver problemas de precisão, use um LLM com --use_llm
    • nesse caso, é preciso definir a chave da Gemini API em GOOGLE_API_KEY
  • Se aparecer texto corrompido, reprocesse o documento com force_ocr
  • É possível forçar o dispositivo torch a ser usado com TORCH_DEVICE
  • Em caso de erro de falta de memória, reduza o número de workers ou divida PDFs longos em vários arquivos
  • A opção debug salva imagens das páginas com o layout e texto detectados, além de arquivos JSON com informações de bounding box

Resultados de benchmark

  • O benchmark de conversão de PDF completo usa um conjunto de benchmark criado a partir da extração de páginas únicas de PDF do common crawl
  • As pontuações são calculadas com uma heurística de alinhamento com segmentos de texto ground truth e também com o método LLM-as-judge
  • Resultados da conversão completa de PDF:
    • marker: tempo médio 2.83837, heurística 95.6709, LLM 4.23916
    • llamaparse: tempo médio 23.348, heurística 84.2442, LLM 3.97619
    • mathpix: tempo médio 6.36223, heurística 86.4281, LLM 4.15626
    • docling: tempo médio 3.69949, heurística 86.7073, LLM 3.70429
  • marker e docling foram executados em H100, enquanto llamaparse e mathpix usam serviços em nuvem
  • O benchmark de throughput com PDFs longos usa Think Python
    • marker: 0.18 segundo por página
    • 43.42 segundos por documento
    • 3.17GB de VRAM
    • é possível executar 22 processos individuais em um H100, com throughput estimado de 122 pages/second
  • O benchmark de conversão de tabelas compara a representação HTML do test split do FinTabNet
    • marker: pontuação média 0.816, total de 99 tabelas
    • marker w/use_llm: pontuação média 0.907, total de 99 tabelas
    • gemini: pontuação média 0.829, total de 99 tabelas
  • Devido à diferença entre o FinTabNet e o método de detecção do modelo de layout, tabelas que não podiam ser alinhadas ao ground truth foram filtradas

Limitações e licença

  • PDF é um formato difícil de lidar, então o Marker nem sempre funciona perfeitamente
  • Limitações conhecidas:
    • layouts muito complexos com tabelas e formulários aninhados podem não funcionar
    • a renderização de formulários pode não sair bem
  • Ao usar as flags --use_llm e --force_ocr, é possível resolver a maior parte desses problemas
  • Os pesos do modelo usam uma licença AI Pubs OpenRAIL-M modificada
    • é gratuita para pesquisa, uso pessoal e startups com funding/receita abaixo de $2M
  • O código está sob licença GPL
  • Licença comercial mais ampla ou remoção das exigências da GPL são tratadas na página de preços

Leituras relacionadas

1 comentários

 
GN⁺ 2023-12-02
Comentários no Hacker News

  • a forma de comparar com o Nougat ao longo de todo o repositório é um pouco confusa
    O Nougat é um modelo treinado de forma especializada para documentos acadêmicos, e não acho que nunca tenha sido afirmado que ele seja o melhor modelo de OCR. No benchmark também consta que, em documentos do arXiv, a precisão do Nougat é maior. Além disso, dizer que o marker converte menos fórmulas do que o Nougat e ainda assim comparar velocidade com o Nougat também deixa um pouco a desejar, justamente por ele ser um modelo voltado a documentos acadêmicos
    Se você quiser fazer OCR em PDFs com matemática, o Nougat definitivamente vale o teste. É fácil de instalar como pacote Python e, com um único comando, extrai fórmulas, texto, tabelas etc. para um arquivo .mmd. Para uso pessoal, a velocidade também é aceitável: em um notebook i5 de 4 anos, levou cerca de 30 segundos para converter um documento de 6 páginas usando apenas CPU

    • comparar dois alvos não significa que o alvo anterior tenha sido divulgado como o melhor
      É só uma forma de colocar a nova ferramenta lado a lado com algo familiar. Como você disse, o Nougat é fácil de instalar e executar, então é natural usá-lo como referência de comparação. Se a comparação incluísse mais bibliotecas, obviamente seria ainda melhor e mais útil
    • fiquei curioso para saber o quão bem o Nougat lidaria com PDFs de livros de regras de RPG
      Estou procurando um modelo de OCR que ajude a passar partes de livros de RPG para Markdown. Se possível, seria ótimo preservar também ênfases como negrito e itálico
      A combinação de texto, números e símbolos matemáticos parece semelhante à de documentos técnicos e acadêmicos, mas com frequência há formatações estranhas, caixas de texto nas margens e muitos diagramas misturados
    • sou o autor. Meu caso de uso é a conversão em massa de PDFs científicos, então o Nougat era a melhor solução e por isso o usei como base de comparação
      Mais abaixo também comparei com extração simples de texto. O Nougat é um ótimo modelo e converte muitos PDFs muito bem, mas eu queria algo mais rápido e mais generalizável
    • quero extrair demonstrativos financeiros em formato de tabela dentro de PDFs; o Nougat seria adequado também para esse tipo de uso?

  • não dá para subestimar o impacto desse tipo de ferramenta. Afinal, ela libera uma enorme quantidade de conhecimento preso em um formato “bom para leitura, ruim para distribuição”
    Estou realmente empolgado. Seria ótimo montar um pipeline: todos os PDFs → converter tudo para Markdown → guardar tudo no archive.org

    • para fins de preservação, esse pipeline não parece adequado. Uma sequência melhor seria todos os PDFs → preservar os originais → converter para Markdown
      Assim, sempre que bugs forem corrigidos e houver melhorias, você pode rodar a conversão de novo. Em geral, na preservação de acervos prefere-se armazenar os materiais na forma mais próxima possível do original, porque toda conversão posterior inevitavelmente gera perda de dados
    • na verdade, PDF é um excelente formato de distribuição
      Dá para embutir de forma invisível os dados brutos usados para gerar o documento que o usuário final vê, em qualquer formato desejado. Por exemplo, se você renderizar HTML com PrinceXML para criar um PDF, pode colocar dentro do PDF o JSON original usado para gerar todo o texto, gráficos e tabelas. Claro, a maioria das pessoas não faz isso na prática, mas isso não é culpa da especificação
    • sou o autor. Esse é justamente um dos motivos pelos quais fiz esta ferramenta
      Também vale ver https://github.com/VikParuchuri/libgen_to_txt. Ainda não o integrei ao marker, e no momento ele usa extração simples de texto
    • há uma demanda enorme por esse tipo de ferramenta. Em especial, grandes organizações com muitos documentos PDF em formatos variados inevitavelmente vão se interessar
      Mesmo que cubra só parte das necessidades ou dos casos de uso, se funcionar direito já será extremamente útil
    • isso também é muito útil do ponto de vista de acessibilidade
      Adequar corretamente a acessibilidade de PDFs dá um trabalhão e, mesmo quando isso é feito, há grande chance de o visualizador de PDF usado pelo usuário não suportar os padrões necessários

  • acho que vou testar pessoalmente no fim de semana
    Eu frequentemente transcrevo à mão scans de PDFs de RPG de origem desconhecida que não passaram por OCR para permitir texto selecionável, ou que até passaram, mas com qualidade ruim
    Às vezes é literalmente mais rápido só digitar tudo manualmente do que corrigir erros de copiar e colar, ou transformar em texto via OCR e depois corrigir os erros
    Mesmo em PDFs oficiais, a formatação frequentemente vem quebrada, com espaços duplos ou triplos e tabs entre palavras. Se isso funcionar de forma decente, parece que vai economizar muito tempo

    • eu também estava pensando nesse caso de uso. Já tentei com um livro, mas o resultado não foi tão bom
      Muitas tabelas e caixas de texto ficaram bem quebradas. Tirando screenshot das tabelas e colando no ChatGPT para fazer a conversão para tabela Markdown, consegui resultados bem bons. Dando um pouco de prompt, tipo “leia por linha. Os cabeçalhos das colunas são X, Y, Z. X é texto, Y é número, Z é palavra”, deu até para lidar com tabelas irregulares
    • pensei exatamente nisso, porque há muito material relacionado a RPG que nunca chegou a existir em mídia física e ficou órfão em termos de propriedade intelectual

  • hoje em dia, o Tesseract OCR está aceitável em que nível? Quando usei no passado, ele ficava muito atrás dos OCRs online da AWS, Azure e GCP

    • houve várias atualizações recentes, e no git o Tesseract 5 é mencionado como dependência. É bem possível que tenha melhorado bastante desde a última vez que usei
      https://github.com/tesseract-ocr/tesseract/releases
      No fim, isso provavelmente depende do caso de uso. Para esse tipo de projeto pessoal, há boa chance de ser suficiente, e também não exige informações de usuário ou cartão de crédito
    • achei surpreendentemente bom, e o desempenho no navegador também me impressionou
      Mas ele é muito sensível à resolução. Quando a imagem cai abaixo de certo tamanho, para humanos ela ainda é perfeitamente legível, mas a saída do Tesseract vira uma bagunça
    • precisa de bastante pré-processamento. Só usei a solução do GCP, mas na minha experiência ela era melhor
    • usei há bem pouco tempo e ele falhou até com imagens muito básicas
      Também tentei a API Vision do iOS, mas ela falhou do mesmo jeito. O caso de teste era uma foto nítida de uma página de livro

  • Pergunta ao autor: por que Markdown? Parece que a parte difícil desta ferramenta é fazer o parsing do PDF com alta precisão, não para qual formato exportar depois.
    Então seria bom se o usuário pudesse escolher o formato de saída. Se houver um parser de PDF de alta precisão, eu gostaria de usá-lo para gerar EPUB

    • É preciso algum tipo de marcação que preserve ao máximo a marcação estrutural
      Eu gerencio e-books em uma editora universitária, e há uma longa fila de obras antigas esperando conversão; em muitos casos, o que resta são apenas scans de páginas de edições impressas antigas. Para disponibilizar em EPUB, é preciso saber onde estão divisões de capítulos, títulos, tabelas, gráficos, fórmulas, citações etc. Uma empresa terceirizada pode fazer isso, mas para alguns livros o custo de conversão é maior que a receita de vendas. Seria bom conseguir fazer pelo menos parte disso internamente
    • Concordo que o formato intermediário deveria ser algo mais próximo de texto puro, que opcionalmente pudesse ser convertido para outros formatos
      Mas aqui parece que Markdown está sendo usado como formato intermediário. É próximo de texto puro, mas ainda consegue preservar algumas informações simples de layout. Na prática, eu provavelmente receberia a saída em Markdown e a conectaria a uma ferramenta que a convertesse para o formato final desejado
    • O motivo para escolher Markdown foi querer preservar fórmulas, tabelas, informações de negrito/itálico e títulos
      Fórmulas podem ser delimitadas com $/$$. Ainda não olhei para saída em EPUB, mas, por causa dessas exigências, texto puro ficou de fora

  • Há um caso de uso específico para o qual ainda não encontrei uma boa solução: ler documentos de construção
    As plantas sempre vêm em PDF, e funcionou muito melhor quando eu fazia parsing de arquivos DXF (AutoCAD). Mas, mesmo que eu seja o empreiteiro geral responsável pela obra, nem sempre é fácil conseguir que o arquiteto me envie o DXF

  • Eu leio textos longos principalmente em leitores de e-book
    PDF, especialmente com layout em múltiplas colunas, é quase um pesadelo nos recursos nativos do Amazon Kindle ou do Pocketbook. Parece que esta ferramenta pode melhorar bastante a experiência de leitura

  • Bom trabalho
    Eu estava curioso para saber de onde vêm as alucinações visíveis na saída do Nougat. Se você der uma olhada na saída do Nougat para o exemplo de Think Python, vai entender o que quero dizer
    Revendo agora, está dito que passa por um LLM, então as alucinações eram algo esperado

    • Acho esse tipo de ferramenta arriscado enquanto a taxa de alucinação em texto ou formatação não ficar abaixo da taxa de erro de um leitor cuidadoso ao reler o documento várias vezes
      Esse nível é praticamente próximo de 0 e, dependendo do uso, talvez precise ser literalmente 0. Se o conteúdo exato do documento não for importante, em geral tudo bem, mas acho raro haver um grande volume de documentos que não sejam importantes para ninguém agora ou no futuro e que, ainda assim, precisem ser mais acessíveis do que em PDF

  • Parece o tipo de ferramenta que poderia ajudar a migrar minhas notas do OneNote

  • Bem interessante. Seria bom adicionar alguns exemplos de antes e depois da conversão no repo
    Fiquei curioso sobre que tipo de PDF vocês estão ajustando. Como lidam com anotações manuscritas?