Show HN: parser PDF open source basado en reglas para RAG

 (github.com/nlmatics)
1 puntos por GN⁺ 2024-01-26 | 1 comentarios | Compartir por WhatsApp
  • nlm-ingestor es el código del servicio al que se conecta la API de llmsherpa, y ofrece parsers de documentos para PDF, HTML, Text, DOCX, PPTX y otros formatos orientados a RAG
  • El parser de PDF usa datos de coordenadas de texto, gráficos y fuentes obtenidos de una versión modificada de Tika por nlmatics, y si hay páginas escaneadas puede aplicar OCR automáticamente con la opción apply_ocr
  • Entre las funciones de procesamiento de PDF se incluyen niveles de secciones y subsecciones, unión de párrafos, enlaces entre secciones y párrafos, tablas, listas anidadas, combinación de contenido entre páginas, eliminación de encabezados y pies repetidos, eliminación de marcas de agua y bounding boxes de OCR
  • Frente a los parsers visuales basados en modelos, se explica que el parser basado en reglas no necesita generar imágenes de las páginas PDF, por lo que sería 100 veces más rápido, y se considera más práctico para PDFs con capa de texto y documentos de cientos de páginas
  • El servidor de desarrollo puede levantarse con Docker o ejecutarse directamente, y para producción se recomienda colocarlo detrás de una gateway de seguridad como nginx o una gateway en la nube

Parsers de documentos que ofrece nlm-ingestor

  • nlm-ingestor es un repositorio de código de servicio al que puede conectarse la API de llmsherpa
  • Ofrece varios parsers personalizados para distintos formatos de archivo orientados a RAG (retrieval augmented generation)

    • PDF

    • HTML

    • Text

      • DOCX, PPTX y otros formatos compatibles con Apache Tika

Cómo funciona el parser de PDF y qué ofrece

  • El parser de PDF está basado en reglas y usa datos de coordenadas de texto, gráficos y fuentes obtenidos de nlm-tika, una versión modificada por nlmatics
  • Funciona sobre la capa de texto del PDF y, mediante la opción apply_ocr, puede aplicar OCR automáticamente si el PDF contiene páginas escaneadas
  • La función de OCR se basa internamente en una versión modificada de Tika por nlmatics que usa tesseract
  • También se ofrece el notebook pdf_visual_ingestor_step_by_step para probar directamente el parser de PDF
  • El parser de PDF incluye las siguientes funciones
    • Identificación de secciones, subsecciones y sus niveles
    • Unión de múltiples líneas para formar párrafos
    • Creación de vínculos entre secciones y párrafos
    • Identificación de tablas y de la sección donde se encontraron
    • Procesamiento de listas y listas anidadas
    • Combinación de contenido que se extiende entre páginas
    • Eliminación de encabezados y pies repetidos
    • Eliminación de marcas de agua
    • Provisión de bounding boxes para resultados de OCR

Procesamiento de documentos HTML, Text y Office

  • El parser de HTML genera bloques con reconocimiento de layout para crear chunks de mejor calidad y mejorar el rendimiento de RAG
  • El parser de Text infiere listas, tablas, encabezados y otros elementos usando solo el texto, sin información visual, de fuentes ni bounding boxes
  • DOCX, PPTX y otros formatos compatibles con Apache Tika se procesan usando primero la salida HTML de Tika y luego el parser de HTML

Ejecución y uso de la API

  • El procedimiento para ejecutarlo directamente consiste en instalar Java, iniciar el servidor Tika, instalar nlm-ingestor y ejecutar el ingestor
    • Iniciar servidor Tika: java -jar <path_to_nlm_ingestor>/jars/tika-server-standard-nlm-modified-2.9.2_v2.jar
    • Instalación: pip install nlm-ingestor
    • Ejecución: python -m nlm_ingestor.ingestion_daemon
  • Hay una imagen Docker disponible en GitHub Container Registry público
    • Descargar imagen: docker pull ghcr.io/nlmatics/nlm-ingestor:latest
    • Ejemplo de ejecución: docker run -p 5010:5001 ghcr.io/nlmatics/nlm-ingestor:latest-<version>
  • Una vez levantado el servidor, se pueden obtener chunks con la librería API de llmsherpa para usarlos en proyectos con LLM
  • Un ejemplo de llmsherpa_url es http://localhost:5010/api/parseDocument?renderFormat=all
    • Aplicar OCR: &applyOcr=yes
    • Usar el nuevo parser de indentación que emplea otro algoritmo para asignar niveles de encabezado: &useNewIndentParser=yes
  • Puede usarse como servidor de desarrollo, pero en producción se recomienda ejecutarlo detrás de una gateway de seguridad como nginx o una gateway en la nube
  • Hay código de ejemplo para probar el servidor con el parser de llmsherpa en el notebook test_llmsherpa_api

Por qué eligieron un parser basado en reglas

  • El equipo de nlmatics evaluó varias alternativas durante 4 años, incluido un parser visual basado en YOLO desarrollado por Tom Liu y Yi Zhang, antes de elegir un parser basado en reglas
  • El parser basado en reglas es considerablemente más rápido que cualquier parser visual, y la descripción del repositorio lo expresa como 100 veces más rápido
    • Los parsers visuales deben generar imágenes de todas las páginas incluso en PDFs que ya tienen capa de texto
    • Los parsers visuales pueden ser una mejor opción para PDFs OCR sin capa de texto o PDFs pequeños compuestos por datos de formularios
    • Para PDFs grandes con capa de texto y cientos de páginas, se considera más práctico el parser basado en reglas
  • Si no se usa la función de OCR del PDF, no se requiere hardware especial
    • La descripción del repositorio indica que puede ejecutarse incluso en hardware de principios de los 2000
  • Todos los parsers, incluidos los visuales, pueden cometer errores, y se explica que la forma de corregir errores en parsers basados en modelos no resultó satisfactoria
    • Si se agregan más ejemplos al conjunto de entrenamiento, la precisión de entrenamientos anteriores puede degradarse y el código que antes funcionaba puede volverse incierto
    • Si los problemas de un parser basado en modelos se corrigen con ideas de tipo regla, al final se termina escribiendo muchas reglas de todos modos

Tika modificado por nlmatics

  • La versión modificada de Tika por nlmatics está en la rama 2.4.1-nlm
  • Para mayor comodidad, el archivo jar compilado está incluido en la carpeta jars/ del repositorio
  • Algunos PDFs pueden provocar errores en el servidor Java y, en ese caso, hay que corregir ese código y volver a compilar el jar
  • Los archivos modificados agregan fuentes y coordenadas a cada elemento de texto del PDF y eliminan marcas de agua
    • PDF2XHTML.java
    • AbstractPDF2XHTML.java
  • El cambio en GraphicsStreamProcessor.java sirve para añadir líneas y rectángulos que pueden ayudar en la detección de tablas
  • El impacto de estos cambios puede verse al inicio del notebook pdf_visual_ingestor_step_by_step
  • Las ideas de trabajo a futuro son las siguientes
    • Escribir un wrapper propio sobre pdfbox para eliminar la dependencia de los cambios en Tika
    • Actualizar a una versión más reciente de Tika
    • Ordenar el formato HTML devuelto para que sea más compatible con CSS

Lecturas relacionadas

1 comentarios

 
GN⁺ 2024-01-26
Opiniones en Hacker News

  • Si trabajan con artículos científicos, también valdría la pena agregar GROBID: https://github.com/kermitt2/grobid
    Lo uso junto con paperetl(https://github.com/neuml/paperetl)

  • Buen proyecto. Para parsing de documentos, he usado Tika durante mucho tiempo por su madurez y la amplia variedad de formatos que soporta, y la salida XHTML ayuda para dividir documentos en chunks para RAG
    Hay ejemplos en https://neuml.hashnode.dev/build-rag-pipelines-with-txtai y https://neuml.hashnode.dev/extract-text-from-documents
    Como referencia, soy el autor principal de txtai(https://github.com/neuml/txtai)

    • Un poco fuera de tema, pero me da curiosidad cómo se compara Tika con otras bibliotecas de parsing de PDF
      pdfminer.six(la que usa unstructured) me decepcionó porque su detección de layout es bastante básica y falló al parsear texto en varias columnas, mientras que MuPDF lo manejó perfectamente
      Actualmente uso una mezcla de MuPDF + AWS Textract(principalmente para tablas), pero me gustaría saber qué usan los demás

  • Parece que podría ser bastante útil. En la empresa donde trabajo tenemos una herramienta de comparación de PDF llamada “PDFC”, que lee PDFs y compara diferencias semánticas: https://www.inetsoftware.de/products/pdf-content-comparer
    El formato PDF es tan complejo que parsearlo puede ser un verdadero dolor de cabeza. Nosotros ya soportamos la mayoría de estas funciones, pero siempre hay muchos casos límite, así que un enfoque adicional puede ayudar

  • El fallback a Tesseract OCR se ve bien
    Hoy ya hay muchos cargadores de archivos para RAG, como langchain, LLMindex, unstructured, etc.; me pregunto si hay alguna razón para preferir este. Por ejemplo, si hay alguna evidencia como mejores puntajes en benchmarks

    • No pude probar esta herramienta directamente porque no compila en Apple Silicon y tampoco hay imagen Docker para ARM
      Dicho eso, he usado esas herramientas de RAG para parsing de PDF y la calidad de salida fue bastante baja. Como los LLM pueden rodear el problema hasta cierto punto, para RAG funcionan más o menos, pero si quieres respuestas de mayor calidad con referencias correctas, creo que lo mejor es usar un parser basado en reglas directamente. Al final hice eso, aunque basado en MuPDF y no en Tika
      Es posible que los autores de esta herramienta hayan pensado algo parecido
    • La última vez que probé Langchain, aunque admito que fue hace unos 6 meses, la implementación para extraer contenido de archivos PDF y HTML era muy básica
      Alcanzaba para correr un prototipo de RAG, pero no para construir algo confiable. Este proyecto parece una implementación mucho más probada en la práctica

  • Excelente trabajo y muy interesante. Pero si uno va a GitHub, aparece “This organization has no public members”, no sabemos en absoluto quiénes son ustedes, y tampoco podemos saber qué más podría haber dentro de esto sin que sea público
    En general, creo que hace falta un punto intermedio entre “un grupo oculto y sin nombre lo publicó en el sitio de seguridad de $CORP” y las formas tradicionales de presentación y construcción de confianza, para poder ir generando identificación y confianza con el tiempo

  • Para obtener chunks óptimos en proyectos LLM/RAG, pueden usar este servidor junto con llmsherpa LayoutPDFReader: https://github.com/nlmatics/llmsherpa
    Vean los ejemplos y notebooks del repositorio

  • Me pregunto si hay pares de entrada/salida de ejemplo en algún lado

  • Parseé unos cientos de PDFs con esto y los resultados fueron bastante buenos. Si hubiera sido desarrollado en Julia, creo que habría sido al menos 10 veces más rápido

  • Me pregunto en qué se diferencia esto de Azure Document Intelligence, o si en la práctica es lo mismo

    • No hacen lo mismo. La mayoría de los parsers en la nube usan modelos de visión, así que son mucho más lentos y caros, y además hay que escribir más código encima para extraer buenos chunks
      Si usan este servidor junto con la biblioteca llmsherpa(https://github.com/nlmatics/llmsherpa), pueden obtener chunks adecuados para layout en proyectos LLM/RAG
    • Aquí no hay OCR ni IA. Salvo por el fallback estándar, quiero decir
      Esta biblioteca y herramientas como fitz/pymupdf extraen texto directamente de los PDF y permiten aplicar reglas de parsing y estructuración. La mayoría de los PDF modernos permiten extracción de texto sin OCR
      Obviamente es mucho más barato, pero no escala bien para layouts dinámicos en general, así que normalmente se usa cuando se puede configurar para estructuras estándar. Aun así, he visto que para cosas como artículos científicos, la extracción de texto basada en reglas funciona bastante bien de forma dinámica
    • La última vez que usé Azure Document Intelligence, no era muy inteligente para elegir puntos de división. Este parece haber implementado mejores heurísticas
    • Yo también tengo curiosidad. ADI es confiable, pero tiene problemas de casos límite con PDFs mal construidos
      Aunque me preocupa que Tesseract OCR sea una posible limitación. He visto que comete demasiados errores

  • Me pregunto si hay ejemplos. En el repositorio no parece haber ningún archivo PDF

    • Pueden ver ejemplos en el proyecto llmsherpa: https://github.com/nlmatics/llmsherpa
      Este proyecto nlm-ingestor proporciona el backend que funciona junto con llmsherpa. La biblioteca llmsherpa es muy práctica para extraer buenos chunks para proyectos LLM/RAG