Tecnología para convertir PDF a Markdown rápido y con alta precisión

 (github.com/VikParuchuri)
2 puntos por GN⁺ 2023-12-02 | 1 comentarios | Compartir por WhatsApp
  • Marker es una herramienta de inteligencia documental que convierte de forma rápida y precisa no solo PDF, sino también imágenes, documentos PPTX, DOCX, XLSX, HTML y EPUB a Markdown, JSON, chunks y HTML
  • Da formato a tablas, formularios, fórmulas, matemáticas inline, enlaces, referencias y bloques de código, y soporta la extracción y guardado de imágenes, así como la eliminación de artefactos como encabezados y pies de página
  • Para aumentar la precisión, se puede usar un LLM junto con --use_llm; el valor predeterminado es gemini-2.0-flash, y es posible elegir Gemini, Ollama, Claude, OpenAI, Azure OpenAI, entre otros
  • En benchmarks, Marker registró un promedio de 2.83837 segundos por una sola página PDF, una puntuación heurística de 95.6709 y una puntuación LLM de 4.23916; en modo batch con H100 se estima un throughput de 25 pages/second
  • Requiere Python 3.10+ y PyTorch; el código es GPL, y los pesos del modelo usan una licencia AI Pubs OpenRAIL-M modificada, con condiciones gratuitas para investigación, uso personal y startups con menos de $2M de funding/revenue

Documentos que convierte Marker y salidas

  • Marker convierte documentos a Markdown, JSON, chunks y HTML
  • Los formatos de entrada incluyen PDF, imágenes, PPTX, DOCX, XLSX, HTML y EPUB, y procesa documentos en todos los idiomas
  • Alcance del procesamiento de elementos del documento:
    • Tablas, formularios, fórmulas, matemáticas inline
    • Enlaces, referencias, bloques de código
    • Extracción y guardado de imágenes
    • Eliminación de encabezados, pies de página y otros artefactos
  • Se puede extender con formateo y lógica propios
  • Si se proporciona un esquema JSON, puede realizar extracción estructurada; esta función está en beta
  • Funciona en GPU, CPU y MPS

Plataforma gestionada de Datalab

  • La plataforma gestionada de Datalab ejecuta el modelo open source más reciente Chandra
  • Chandra se presenta como más preciso que Marker; no conserva datos por defecto y ofrece SOC 2 Type 2 y BAA personalizados
  • Su servicio de procesamiento batch para workloads de alto volumen ha procesado más de 200M páginas por semana
  • Al registrarse ofrece $5 en créditos gratuitos, y también cuenta con un playground público
  • Para self-hosting comercial se requiere una licencia, y las licencias on-premise se consultan por separado

Rendimiento y modo híbrido con LLM

  • Marker presenta resultados de benchmark favorables frente a servicios en la nube como Llamaparse y Mathpix, y frente a otras herramientas open source
  • Los resultados completos de rendimiento del README se basan en la ejecución serial de una sola página PDF
  • En modo batch es más rápido, y en H100 se estima un throughput de 25 pages/second
  • Para lograr la máxima precisión, se puede usar un LLM junto con el flag --use_llm
    • Fusión de tablas que se extienden más allá de una página
    • Procesamiento de matemáticas inline
    • Mejora del formateo de tablas
    • Extracción de valores desde formularios
  • El modo híbrido con LLM tiene mayor precisión en el benchmark de tablas que Marker solo o Gemini Flash solo

Instalación y uso básico

  • Requiere Python 3.10+ y PyTorch
  • Instalación centrada en PDF: 
    pip install marker-pdf
  • Para procesar formatos de documento distintos de PDF, instalar dependencias adicionales 
    pip install marker-pdf[full]
  • Conversión de un solo archivo: 
    marker_single /path/to/file.pdf
  • Conversión de múltiples archivos por carpeta: 
    marker /path/to/input/folder
  • Conversión en varias GPU: 
    NUM_DEVICES=4 NUM_WORKERS=15 marker_chunk_convert ../pdf_in ../md_out
    • NUM_DEVICES es la cantidad de GPU a usar y debe ser 2 o más
    • NUM_WORKERS es la cantidad de procesos paralelos por GPU

Principales opciones de CLI

  • --page_range TEXT: especifica los números y rangos de páginas a procesar
  • --output_format [markdown|json|html|chunks]: especifica el formato de salida
  • --output_dir PATH: especifica el directorio donde se guardarán los archivos de salida
  • --paginate_output: incluye números de página y separadores en la salida
  • --use_llm: aumenta la precisión con un LLM
  • --force_ocr: fuerza OCR en todo el documento y también formatea adecuadamente las matemáticas inline
  • --block_correction_prompt: especifica un prompt para corregir la salida de Marker en modo LLM
  • --strip_existing_ocr: elimina el texto OCR existente y vuelve a hacer OCR con surya
  • --redo_inline_math: mejora la calidad de conversión de matemáticas inline junto con --use_llm
  • --disable_image_extraction: no extrae imágenes del PDF
  • --converter_cls: elige el valor predeterminado marker.converters.pdf.PdfConverter o marker.converters.table.TableConverter, específico para tablas
  • --llm_service: al usar --use_llm, especifica el servicio LLM; el valor predeterminado es marker.services.gemini.GoogleGeminiService
  • --workers: especifica la cantidad de workers de conversión simultáneos
    • Usa hasta 5GB de VRAM por worker, con un promedio de 3.5GB de VRAM

API de Python y manipulación interna de bloques

  • Se puede convertir directamente desde Python con 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)
  • El rendered de la salida Markdown tiene los atributos markdown, metadata, images
  • El rendered de la salida JSON tiene children, block_type, metadata
  • Con ConfigParser se pueden configurar el formato de salida, procesadores, renderers, servicio LLM, etc.
  • El documento está compuesto por un árbol de páginas y bloques, y las páginas pueden contener bloques a su vez
  • Con contained_blocks se pueden extraer programáticamente solo bloques específicos, como formularios

Tipos de convertidores

  • PdfConverter: convertidor predeterminado que convierte el PDF completo
  • TableConverter: extrae y convierte solo tablas
    • Si se especifica force_layout_block=Table, evita la detección de layout y asume que todas las páginas son tablas
    • Si se usa output_format=json, también se pueden obtener los bounding boxes de las celdas
  • OCRConverter: ejecuta solo OCR
    • Si se configura --keep_chars, conserva caracteres individuales y sus bounding boxes
  • ExtractionConverter: convertidor de extracción estructurada en estado beta
    • Primero requiere configurar un servicio LLM
    • Devuelve los valores extraídos como salida JSON
    • Si se pasa el original_markdown de una ejecución anterior como existing_markdown, se puede omitir el reparsing del documento

Formatos de salida

  • Salida Markdown:
    • Enlaces a imágenes
    • Tablas formateadas
    • Fórmulas LaTeX envueltas en $$
    • Bloques de código con triple backticks
    • Superscript para notas al pie
  • Salida HTML:
    • Imágenes con etiqueta img
    • Fórmulas con etiqueta <math>
    • Código con etiqueta pre
  • Salida JSON:
    • Representa las páginas como una lista, y cada página es un bloque del esquema interno de Marker
    • Tiene las claves id, block_type, html, polygon, children
    • Los bloques hijos tienen además section_hierarchy, images
    • La estructura de bloques tiene forma de árbol
  • Salida Chunks:
    • Similar a JSON, pero aplana todo en una sola lista
    • Al incluir el HTML completo de cada bloque, puede usarse de forma flexible para chunking en RAG
  • Todos los formatos de salida devuelven metadata
    • table_of_contents, la tabla de contenidos calculada del PDF
    • page_stats, que incluye el método de extracción de texto por página y la cantidad de bloques

Servicios LLM soportados

  • Servicios que se pueden elegir al usar --use_llm:
    • Gemini: usa la Gemini developer API por defecto y requiere --gemini_api_key
    • Google Vertex: requiere --vertex_project_id y especificar marker.services.vertex.GoogleVertexService
    • Ollama: usa un modelo local y configura --ollama_base_url, --ollama_model
    • Claude: configura --claude_api_key, --claude_model_name
    • OpenAI: soporta endpoints compatibles con OpenAI y configura --openai_api_key, --openai_model, --openai_base_url
    • Azure OpenAI: configura --azure_endpoint, --azure_api_key, --deployment_name

Estructura interna y puntos de extensión

  • Marker funciona como un pipeline de modelos de deep learning
    • Extracción de texto y OCR cuando sea necesario
    • Detección de layout de página y detección del orden de lectura
    • Limpieza y formateo de cada bloque
    • Mejora de calidad con LLM cuando sea necesario
    • Combinación de bloques y postprocesamiento del texto completo
  • Las etapas relacionadas con OCR y layout usan surya
  • Para el formateo relacionado con fórmulas se usa texify
  • Componentes principales:
    • Providers: proporcionan información desde archivos fuente como PDF
    • Builders: crean los bloques iniciales del documento y completan el texto
    • Processors: procesan bloques específicos, como formateadores de tablas
    • Renderers: renderizan bloques al formato de salida
    • Schema: clases de todos los tipos de bloques
    • Converters: ejecutan todo el pipeline end-to-end
  • Para cambiar el comportamiento de procesamiento, se redefinen los processors
  • Para agregar un nuevo formato de salida, se escribe un nuevo renderer
  • Para agregar un nuevo formato de entrada, se escribe un nuevo provider

Servidor API y despliegue

  • Se puede ejecutar un servidor FastAPI simple 
    pip install -U uvicorn fastapi python-multipart
marker_server --port 8001
  • El servidor es accesible en localhost:8001, y en localhost:8001/docs se pueden ver las opciones del endpoint
  • Este servidor API no es una API robusta y está pensado solo para uso a pequeña escala
  • Si se necesita una opción de conversión más robusta, se puede usar la API alojada de Datalab
  • Los ejemplos de despliegue incluyen desplegar un endpoint web mediante Modal

Solución de problemas

  • Si hay problemas de precisión, usar un LLM con --use_llm
    • En ese caso, se debe configurar la clave de la API de Gemini como GOOGLE_API_KEY
  • Si se ve texto corrupto, volver a hacer OCR del documento con force_ocr
  • Con TORCH_DEVICE se puede forzar el dispositivo torch a usar
  • Si hay errores por falta de memoria, se puede reducir la cantidad de workers o dividir PDFs largos en varios archivos
  • La opción debug guarda imágenes de páginas con el layout y el texto detectados, y archivos JSON con información de bounding boxes

Resultados de benchmarks

  • El benchmark de conversión de PDFs completos usa un benchmark set creado extrayendo páginas PDF individuales de common crawl
  • Las puntuaciones se calculan con una heurística que alinea segmentos de texto de ground truth y con un enfoque LLM-as-judge
  • Resultados de conversión de PDFs completos:
    • marker: tiempo promedio 2.83837, heurística 95.6709, LLM 4.23916
    • llamaparse: tiempo promedio 23.348, heurística 84.2442, LLM 3.97619
    • mathpix: tiempo promedio 6.36223, heurística 86.4281, LLM 4.15626
    • docling: tiempo promedio 3.69949, heurística 86.7073, LLM 3.70429
  • marker y docling se ejecutaron en H100, mientras que llamaparse y mathpix usaron servicios en la nube
  • El benchmark de throughput para PDFs largos usa Think Python
    • marker: 0.18 segundos por página
    • 43.42 segundos por documento
    • 3.17GB de VRAM
    • En H100 se pueden ejecutar 22 procesos individuales, por lo que se estima un throughput de 122 pages/second
  • El benchmark de conversión de tablas compara la representación HTML del test split de FinTabNet
    • marker: puntuación promedio 0.816, total 99 tablas
    • marker w/use_llm: puntuación promedio 0.907, total 99 tablas
    • gemini: puntuación promedio 0.829, total 99 tablas
  • Se filtran las tablas que no pueden alinearse con el ground truth por diferencias entre FinTabNet y el método de detección del modelo de layout

Limitaciones y licencia

  • PDF es un formato difícil de manejar, por lo que Marker no siempre funciona de manera perfecta
  • Limitaciones conocidas:
    • Es posible que no funcionen layouts muy complejos con tablas y formularios anidados
    • El rendering de formularios puede no funcionar bien
  • Pasar los flags --use_llm y --force_ocr puede resolver la mayoría de estos problemas
  • Los pesos del modelo usan una licencia AI Pubs OpenRAIL-M modificada
    • Es gratuita para investigación, uso personal y startups con funding/revenue inferior a $2M
  • El código está bajo licencia GPL
  • Las licencias comerciales más amplias o la eliminación de requisitos GPL se gestionan en la página de pricing

Lecturas relacionadas

1 comentarios

 
GN⁺ 2023-12-02
Opiniones en Hacker News

  • La forma en que se compara con Nougat a lo largo del repo resulta un poco confusa.
    Nougat es un modelo entrenado específicamente para documentos académicos, y no creo que nunca se haya afirmado que Nougat sea el mejor modelo de OCR. Incluso en el benchmark se indica que, en documentos de arXiv, Nougat tiene mayor precisión. Además, decir que marker convierte menos ecuaciones que Nougat y aun así comparar la velocidad con Nougat se siente algo desafortunado, justamente porque es un modelo para documentos académicos.
    Si quieres hacer OCR de PDFs con matemáticas, definitivamente vale la pena probar Nougat. Es fácil de instalar como paquete de Python y, con un solo comando, extrae ecuaciones, texto, tablas, etc. a un archivo .mmd. Para uso personal, la velocidad también está bien: en una laptop i5 de hace 4 años, solo con CPU, tardó unos 30 segundos en convertir un documento de 6 páginas.

    • Comparar dos cosas no significa que la opción existente se haya promocionado como la mejor.
      Es solo una forma de poner una herramienta nueva junto a una referencia familiar. Como dices, Nougat es fácil de instalar y ejecutar, así que es natural usarlo como punto de comparación. Por supuesto, sería mejor y más útil incluir más bibliotecas en la comparación.
    • Me da curiosidad qué tan bien manejaría Nougat los PDFs de manuales de RPG.
      Estoy buscando un modelo de OCR que me ayude a pasar partes de libros de RPG a Markdown. Si es posible, sería bueno que también conserve énfasis como negritas o cursivas.
      La combinación de texto, números y símbolos matemáticos parece similar a la de documentos técnicos o académicos, pero suele venir mezclada con formatos extraños, cuadros de texto en los márgenes y muchos diagramas.
    • Soy el autor. Mi caso de uso era la conversión masiva de PDFs científicos, así que Nougat era la mejor solución, y por eso lo tomé como comparación base.
      Más abajo también lo comparé con extracción de texto simple. Nougat es un modelo excelente y convierte bien muchos PDFs, pero yo quería algo más rápido y más generalizable.
    • Quiero hacer extracción de estados financieros en formato de tabla dentro de PDFs; ¿Nougat también sería adecuado para ese uso?

  • No hay que subestimar el impacto de herramientas como esta. Se trata de liberar una enorme cantidad de conocimiento atrapado en un formato “bueno para leer, malo para distribuir”.
    Me entusiasma mucho. Sería bueno crear un pipeline: todos los PDFs → convertirlos todos a Markdown → guardarlos todos en archive.org

    • Para fines de preservación, ese pipeline no parece adecuado. Un mejor orden sería todos los PDFs → preservar los originales → convertir a Markdown.
      Así se puede volver a ejecutar la conversión cada vez que se corrijan bugs y haya mejoras. En la preservación de registros, normalmente se prefiere guardar el material en una forma lo más cercana posible al original, porque cualquier conversión posterior solo puede generar pérdida de datos.
    • En realidad, PDF es un excelente formato de distribución.
      Puede incluir de forma invisible, en el formato que quieras, los datos crudos usados para generar el documento que ve el usuario final. Por ejemplo, si renderizas HTML con PrinceXML para crear un PDF, puedes meter dentro del PDF el JSON original usado para generar todo el texto, gráficas, charts, etc. Claro que la mayoría no lo hace en la práctica, pero eso no es culpa de la especificación.
    • Soy el autor. Esta es precisamente una de las razones por las que creé esta herramienta.
      También vale la pena revisar https://github.com/VikParuchuri/libgen_to_txt. Todavía no lo he integrado con marker; actualmente usa extracción de texto simple.
    • Hay una demanda enorme por este tipo de herramientas. Especialmente en organizaciones grandes con muchos documentos PDF de formas muy diversas, el interés inevitablemente será alto.
      Aunque cubra solo una parte de las necesidades o casos de uso, si funciona bien será muy útil.
    • También es muy útil desde el punto de vista de la accesibilidad.
      Hacer que un PDF sea correctamente accesible es una tarea enorme y, aunque se logre, es muy probable que el visor de PDF que use la persona no soporte los estándares necesarios.

  • Voy a probarlo por mi cuenta el fin de semana.
    A menudo transcribo a mano escaneos de PDFs de RPG de origen desconocido, que no tienen OCR y por eso no hay texto seleccionable, o que sí lo tienen pero de mala calidad.
    A veces, literalmente, es más rápido simplemente teclearlo yo mismo que corregir errores de copiar y pegar, o corregir errores después de pasarlo a texto con OCR.
    Incluso en PDFs oficiales, el formato suele romperse y aparecen dobles o triples espacios, o tabs, entre palabras. Si se puede usar bien, parece que ahorraría muchísimo tiempo.

    • Yo también tenía en mente este caso de uso. Ya lo intenté con un libro, pero los resultados no fueron muy buenos.
      Las tablas y los cuadros de texto se dañaron bastante. Si tomaba screenshots de las tablas y las pegaba en ChatGPT para pedir una conversión a tablas Markdown, obtenía resultados bastante buenos. Con un poco de prompt, como “lee fila por fila; los encabezados de columna son X, Y, Z; X es texto, Y es número, Z es palabra”, también podía manejar tablas irregulares.
    • Pensé justo en eso porque entre los materiales relacionados con RPG hay muchísimos que nunca salieron en soporte físico y que quedaron huérfanos en términos de propiedad intelectual.

  • ¿Qué tan bueno es hoy Tesseract OCR? Cuando lo probé hace años, estaba muy por detrás del OCR online de AWS, Azure y GCP.

    • Hubo bastantes actualizaciones recientes, y en git se menciona Tesseract 5 como dependencia. Es muy posible que haya mejorado bastante desde la última vez que lo probaste.
      https://github.com/tesseract-ocr/tesseract/releases
      Al final, dependerá del caso de uso. Para este tipo de trabajo personal, probablemente sea suficiente, y no requiere datos de usuario ni tarjetas de crédito.
    • Me pareció sorprendentemente bueno, y su rendimiento dentro del navegador también fue impresionante.
      Eso sí, es muy sensible a la resolución. Si la imagen baja de cierto tamaño, aunque para una persona siga siendo suficientemente legible, la salida de Tesseract se vuelve un desastre.
    • Requiere bastante preprocesamiento. Solo he usado la solución de GCP y, según mi experiencia, esa fue mejor.
    • Lo probé hace relativamente poco y falló incluso con imágenes muy básicas.
      También intenté con la API Vision de iOS, pero igualmente falló. El caso de prueba era una foto nítida de una página de un libro.

  • Pregunta para el autor: ¿por qué Markdown? La parte difícil de esta herramienta parece ser parsear el PDF con alta precisión, no el formato en el que se exporta después.
    Por eso estaría bueno que el usuario pudiera elegir el formato de salida. Si existiera un parser de PDF de alta precisión, me gustaría usarlo para generar EPUB

    • Hace falta algún tipo de marcado que conserve lo más posible el marcado estructural.
      Administro ebooks en una editorial universitaria, y tenemos una larga lista de títulos antiguos esperando conversión; en muchos casos solo quedan escaneos de páginas de las ediciones impresas viejas. Para ofrecerlos como EPUB, hay que saber dónde están las divisiones de capítulos, títulos, tablas, gráficos, fórmulas, citas, etc. Un proveedor externo puede hacerlo, pero en algunos libros el costo de conversión supera los ingresos por ventas. Sería bueno poder hacer al menos una parte internamente
    • Estoy de acuerdo en que el formato intermedio debería ser cercano a texto plano, que opcionalmente pueda convertirse a otros formatos.
      Dicho eso, aquí parece que Markdown se usa como formato intermedio. Es cercano a texto plano, pero puede conservar información simple de layout. En la práctica, creo que tomaría la salida Markdown y la conectaría con una herramienta que la convierta al formato de salida final que quiera
    • La razón para elegir Markdown fue que quería conservar fórmulas, tablas, información de negritas/cursivas y títulos.
      Las fórmulas se pueden envolver con $/$$. Todavía no revisé la salida a EPUB, pero por estos requisitos se descartó el texto plano

  • Tengo un caso de uso particular para el que todavía no encontré una buena solución: leer documentos de construcción.
    Los planos siempre llegan en PDF, pero me iba mucho mejor al parsear archivos DXF (AutoCAD). Sin embargo, aunque yo sea el contratista general a cargo de la obra, no siempre es fácil lograr que el arquitecto me mande los DXF

  • Los textos largos los leo principalmente en un lector de ebooks.
    Los PDF, especialmente con layout en varias columnas, son casi una pesadilla con las funciones básicas de Amazon Kindle o Pocketbook. Creo que esta herramienta podría mejorar bastante la experiencia de lectura

  • Buen trabajo.
    Me preguntaba de dónde venían las alucinaciones que se ven en la salida de Nougat. Si uno hojea la salida de Nougat del ejemplo de Think Python, se entiende a qué me refiero.
    Al volver a mirarlo, veo que pasa por un LLM, así que las alucinaciones eran esperables

    • Creo que este tipo de herramientas son riesgosas hasta que la tasa de alucinaciones en el texto o el formato sea menor que la tasa de errores de un lector cuidadoso al leer el documento repetidas veces.
      Ese nivel está casi en 0, y según el uso quizá tenga que ser realmente 0. Si el contenido exacto del documento no importa, en general estaría bien, pero no creo que sea común que existan grandes cantidades de documentos que no sean importantes para nadie, ni ahora ni en el futuro, y que aun así necesiten ser más accesibles que un PDF

  • Parece una herramienta que podría ayudarme a migrar mis notas desde OneNote

  • Bastante interesante. Estaría bueno agregar al repo algunos ejemplos de antes y después de la conversión.
    Me da curiosidad para qué tipo de PDF lo están ajustando. ¿Cómo maneja las anotaciones manuscritas?