Convertir PDF a texto es un problema difícil
(marginalia.nu)- Aunque se agregó el indexado de PDF al motor de búsqueda, obtener texto estructurado útil para búsqueda desde PDF es mucho más complicado que procesar HTML
- Un PDF se parece más a un formato gráfico basado en coordenadas que a un documento de texto, por lo que los glifos pueden estar rotados, superpuestos o en un orden mezclado
- PDFTextStripper de PDFBox puede servir como punto de partida, pero no conserva lo suficiente la estructura semántica, como títulos y párrafos, lo que limita la evaluación de relevancia en búsqueda
- Para distinguir títulos y párrafos, suelen ser más útiles heurísticas como las estadísticas de tamaño de fuente por página y la mediana del interlineado que una referencia global de todo el documento
- Como la extracción perfecta de texto desde PDF es difícil, para un motor de búsqueda la meta realista es una solución suficientemente buena que obtenga de forma estable la estructura de título, resumen y cuerpo
Problemas que salieron a la luz al agregar indexado de PDF
- El motor de búsqueda recientemente pasó a poder indexar archivos PDF, y los cambios se irán desplegando durante varios meses
- Desde la perspectiva de un motor de búsqueda, un HTML limpio es lo más fácil de manejar, pero un PDF no ofrece de inmediato el mismo nivel de texto estructurado
- Aunque a simple vista se vea texto, reconstruir dentro de un PDF oraciones y párrafos utilizables para búsqueda es casi un problema aparte
Por qué el PDF dificulta la extracción de texto
- Un PDF no es un formato de texto convencional, sino algo más cercano a un formato gráfico
- Su representación interna se parece más a colocar glifos en coordenadas sobre una “hoja” que a almacenar oraciones o párrafos
- Los glifos pueden estar en estados como estos
- Rotados
- Superpuestos entre sí
- En un orden distinto al de lectura
- Con muy poca información semántica asociada
- Que un visor de PDF o un navegador permita buscar con
ctrl+fya es, en sí mismo, algo bastante sorprendente - Los modelos de machine learning basados en visión pueden ser una buena aproximación por ahora, pero no encajan bien con una escala donde hay que procesar cientos de GB de PDF en un solo servidor sin GPU
Se puede empezar con PDFBox, pero no basta
- No es un problema completamente inexplorado, así que se puede tomar como punto de partida la clase PDFTextStripper de PDFBox
- PDFTextStripper extrae texto de un PDF, pero como indica su nombre, su enfoque está en “desprender” el texto
- Para un motor de búsqueda, la información semántica como los títulos es una señal importante de relevancia, pero con el resultado de extracción básico es difícil obtener suficientemente bien esa estructura
Heurísticas para encontrar títulos
- La detección más simple de títulos consiste en buscar líneas con grosor semibold o mayor que estén separadas del resto del texto
- Pero no todos los títulos están en negritas, y muchos documentos distinguen los títulos por el tamaño de fuente
- Un punto de referencia global del tamaño de fuente varía mucho entre documentos
- Un documento puede usar 10pt para el cuerpo y 16pt para los títulos
- Otro puede usar 14pt para el cuerpo y 20pt para los títulos
- A veces las estadísticas por página son más adecuadas que las de todo el documento
- La primera página puede diferir mucho de las demás en elección de fuentes por el resumen y la lista de autores
- En el documento de ejemplo, el título del documento usa fuente de tamaño 17, y los títulos posteriores usan tamaño 14
- En cada página suele haber un tamaño de fuente dominante que corresponde al cuerpo del texto
- Si se aplica un coeficiente de aproximadamente 20% a la mediana del tamaño de fuente por página, se pueden identificar títulos con bastante estabilidad
- Siguen existiendo excepciones, pero se puede capturar la mayoría de los casos importantes
Unir títulos de varias líneas en uno solo
- Por razones de estilo, los títulos muchas veces se dividen en varias líneas, así que a veces hay que unir en uno solo los renglones consecutivos de título
- Decidir cuándo unirlos no es algo simple
- En el ejemplo aparecen juntas condiciones como estas
- Un título de dos líneas
- Un título alineado a la derecha
- Un nombre de autor en semibold inmediatamente después del título
- Un título sin negritas varias líneas más abajo
- La sangría también se usa como señal para separar párrafos, así que un título alineado a la derecha complica aún más la decisión
- Unir títulos consecutivos que tengan el mismo tamaño de fuente y grosor suele funcionar bastante bien, aunque también puede producir resultados no deseados
La trampa del interlineado al identificar párrafos
- PDFTextStripper realiza bastante bien la identificación de párrafos
- Decide dónde dividir párrafos observando juntos el interlineado y la sangría
- Hay margen de mejora, especialmente en la lógica del interlineado
- El gran problema de PDFTextStripper es que usa una referencia fija para separar líneas
- Si la distancia entre líneas supera esa referencia, decide que no pertenecen al mismo párrafo
- Esto no refleja suficientemente que el interlineado cambia de un documento a otro
- En borradores académicos y preprints es bastante común un interlineado de 1.5 a 2 veces
- Si el umbral se fija demasiado alto, algunos títulos pueden quedar absorbidos dentro de párrafos del cuerpo y dificultar su identificación
Corregir con estadísticas de interlineado
- Igual que con el tamaño de fuente, se pueden aplicar técnicas estadísticas a la distancia entre líneas
- Si se construye un histograma de distancias entre líneas en una página con texto, tienden a aparecer outliers grandes
- La media se altera fácilmente por esos outliers, pero la mediana a veces coincide con precisión con el interlineado usado en el cuerpo
- Si se aplica un cierto coeficiente a la mediana, se puede crear una heurística de separación de párrafos que resista distintos interlineados
La meta realista es estabilidad, no perfección
- Es difícil que la extracción de texto desde PDF llegue a ser perfecta
- El propio formato PDF no fue diseñado para ese tipo de trabajo, y al elegir una solución “suficientemente buena” aparecen varios trade-offs
- A un motor de búsqueda le interesan especialmente los siguientes datos
- Señales de relevancia como los títulos
- La identificación del resumen
- Una estructura razonablemente consistente del resto del texto
- Con esos objetivos, se puede llegar a una solución capaz de procesar la mayoría de los documentos relevantes sin demasiadas complicaciones
Texto de muestra usado
Can Education be Standardized? Evidence from Kenya (2022) - Working PaperGuthrie Gray-Lobe, Anthony Keats, Michael Kremer, Isaac Mbiti, Owen W. OzierThe theory of ideas and Plato’s philosophy of mathematics (2019)Dembiński, B.The role of phronesis in Knowledge-Based Economy (2024)Anna Ceglarska, Cymbranowicz Katarzyna
1 comentarios
Opiniones de Hacker News
A veces uno olvida por completo algo en lo que se metió durante meses o años hasta volverse experto, y más tarde piensa: “esto es nuevo e interesante”
Aunque haya hecho bastantes cosas interesantes, desaparecen de la memoria y, hasta que algo las dispara, uno se siente como alguien que empieza la vida de nuevo
Recuerdo vagamente que hace unos 6 o 7 años hice algo bastante bueno con PDF y OCR, y al buscarlo parece que fue con Tesseract
Era un hack más cercano a una heurística, y creo que la vieja API de Poppler de esa época no representaba los tramos de texto de una forma adecuada para una API de accesibilidad
La selección multicolumna entró en cierta medida, pero después fue difícil convencer a los mantenedores de aceptar propuestas de mejora de rendimiento, porque la heurística cambiaba un poco y en algunas situaciones el resultado de la selección era distinto
Para empezar, no había una única “respuesta correcta”, así que exigir coincidencia de resultados no tenía sentido, y así fue como la selección multicolumna de kpdf terminó existiendo en cierta medida
Hoy probablemente tenga más sentido usar Tesseract directamente para este tipo de caso
No sé cuándo terminará esta locura
Tiene mayor precisión de base, aceleración por GPU e implementa como pipelines combinables varias arquitecturas de modelos de detección y reconocimiento de texto
También se puede entrenar y ajustar finamente con PyTorch o TensorFlow para mejorar aún más el rendimiento en dominios específicos
Así que sí, esas cosas realmente pasan
Lo siguiente suele ser un área totalmente distinta, así que toca empezar otra vez desde lo básico
Ojalá alguien hiciera algo parecido a las herramientas de desarrollador del navegador, pero para PDF
Como “inspeccionar elemento”, que permita ver el flujo de contenido del PDF como fuente y comprobar cómo los operadores de texto
BT … ETo el operador de colocación de textoTjespecifican y generan cada píxelEs lo opuesto a la tendencia actual, en la que los modelos visuales “ven” y leen el PDF como una persona, pero sería mucho mejor poder entender qué hay realmente dentro de un archivo PDF
Hay algunas herramientas para inspeccionar contenido de PDF (https://news.ycombinator.com/item?id=41379101), pero se quedan en el nivel de objetos PDF, de modo que todo el flujo de contenido se ve como un solo objeto
Por ejemplo, en la página 8 del PDF, página 6 según el documento, de https://bfi.uchicago.edu/wp-content/uploads/2022/06/BFI_WP_2... mencionado en el artículo, el texto se coloca con operadores como
BT, configuración de fuente,TdyTJSi se pudiera ver esa “fuente” y el PDF renderizado lado a lado, y al pasar el mouse por un lado se resaltara el área correspondiente del otro, se podría depurar como una página HTML
Por ejemplo, cada
Tjpodría convertirse en un elemento del DOM, yTJen un grupo de varios elementosComo tendría que reflejar correctamente el documento original para funcionar, es probable que haga una conversión bastante fiel
Se puede generar JSON con
cpdf -output-json -output-json-parse-content-streams in.pdf -o out.json, modificar ese JSON y luego volver a convertirlo a PDF concpdf -j out.json -o out.pdfEso sí, no hay vinculación bidireccional en tiempo real
Aunque no inspeccionaba la página como tal, sino que navegaba por el árbol de contenido, y sí resaltaba los objetos sobre la página
No llegaba al nivel de comandos; solo hasta el nivel de objetos o flujos
https://observablehq.com/@player1537/pdf-utilities
No se trata solo de “ver” el PDF como una persona y leer texto, sino de entender el contenido, incluidas tablas, imágenes, texto, fórmulas y escritura a mano
Por eso parsean el PDF y ejecutan varios modelos para extraer fragmentos de Markdown o JSON, de modo que los datos reales puedan pasarse a agentes de IA, LLM y otras aplicaciones
https://tensorlake.ai
“PDF a texto” es una expresión demasiado simplificada
Dentro de esta categoría están: 1) OCR confiable para índices de búsqueda o como entrada para bases de datos vectoriales, 2) extracción de datos estructurados para obtener valores específicos, y 3) pipelines de documentos de extremo a extremo, como la automatización de solicitudes hipotecarias
Lo que Marginalia tiene que resolver es el OCR del punto 1, y gracias a modelos como Gemini Flash se está volviendo rápidamente algo de uso general
He visto a varias empresas reemplazar sus pipelines de OCR existentes por Flash y reducir mucho los costos, lo cual me sorprendió bastante
Pero los puntos 2 y 3 son mucho más difíciles, y todavía hay una gran brecha entre la salida OCR en bruto y un pipeline de documentos de misión crítica en un entorno operativo
Los LLM y los modelos de lenguaje visual no son magia, y si esperas una automatización del 100%, te vas a sorprender
Sigue siendo necesario construir y etiquetar datasets, orquestar pipelines de
clasificación -> segmentación -> extracción, detectar incertidumbre y hacer revisión humana, además de ajustes finosA largo plazo, esto podría acercarse a una automatización casi completa, pero requiere tiempo y esfuerzo, y parece claro que el futuro va en esa dirección
Relacionado con esto, inicié una empresa de procesamiento de documentos con LLM llamada https://extend.ai
Los flujos de trabajo empresariales suelen tratar solo con unos pocos documentos definidos, pero un lector de PDF de propósito general no puede saber qué documento va a abrir el usuario
Debe reconocer no solo texto, sino también tablas, encabezados y pies de página, notas al pie, títulos, fórmulas matemáticas, etc.
Como es para consumo humano, hay que minimizar errores, así que no se debe usar OCR cuando no sea necesario; se debe aprovechar el texto base incluido en el PDF y, al mismo tiempo, extraer la estructura semántica
Al final se necesitan dos rutas: una para PDF que son solo imágenes y otra para PDF de los que se puede obtener información a partir del flujo de contenido
Pero el flujo de contenido puede contener texto distinto de lo que realmente aparece en pantalla. Por ejemplo, información oculta con letras blancas, o implementaciones al estilo LaTeX que dibujan signos de acento mediante comandos en lugar de usar acentos Unicode
Normalmente se ejecuta como una app local en dispositivos de bajo rendimiento de los usuarios, y es muy probable que no haya servidor ni modelo de suscripción, por lo que tampoco se pueden usar modelos de IA en la nube
Los usuarios de software de accesibilidad pueden tener dificultades para imprimir y completar con pluma, así que hay que procesar no solo formularios limpios conforme a la especificación, sino también formularios pensados para impresión
Este es un problema abierto que todavía no está ni cerca de resolverse, y las soluciones actuales son insuficientes de alguna manera; no existe una única solución que resuelva bien los cinco puntos anteriores
Etiquetan imágenes muy bien, y funcionan bien con documentos simples, como texto de una sola columna, títulos centrados de un solo nivel o una imagen o tabla por página
La mayoría de las demos de MVP muestran ejemplos de ese tipo
Pero en documentos complejos con tablas e imágenes mezcladas, parece que todavía harían falta muchísimos más parámetros para que siquiera lleguen a un “mal nivel”
Por ahora alucinan demasiado; incluso una tabla simple con un título arriba, datos al centro y un resumen abajo es difícil de usar tal cual
El OCR actual es excelente, pero mantener la estructura global del documento es mucho más complicado
Obtener HTML consistente en documentos grandes todavía parece lejano, y con Markdown se obtienen resultados más o menos buenos si se pasa varias veces por un LLM para extraer la estructura del documento y luego se usa como contexto para la extracción página por página
En Apple trabajaron en este problema durante varios años con bastante éxito, y el secreto principal fue tratar todo como geometría e intentar distinguir, mediante análisis de clustering, entre espacios entre palabras y espacios entre letras
En muchos PDF funciona muy bien, pero los tipos de PDF son tan variados que siempre hay casos en los que el resultado no es bueno
Si lo volviera a hacer hoy, mantendría la geometría y evitaría por completo el OCR, pero probablemente usaría machine learning
La gran ventaja del machine learning es que se pueden aprovechar herramientas existentes que generan PDF a partir de texto conocido para automatizar por completo la etapa de entrenamiento
Bertrand Serlet presentando esta función en la WWDC 2009: https://youtu.be/FTfChHwGFf0?si=wNCfI9wZj1aj9rY7&t=308
Una mejor solución es embeber dentro del PDF el documento original editable
En LibreOffice es fácil hacerlo y, como se comprime bien, normalmente casi no ocupa espacio
Así se puede obtener información mucho mejor sobre el texto y la semántica, y además funciona bien con los lectores de PDF existentes
En el ámbito de la exhibición electrónica de pruebas, es común que quien entrega evidencia la vuelque deliberadamente en PDF para dificultar que el abogado de la contraparte consuma el contenido
Si ambas partes tienen mucho dinero, no es una barrera, pero, por ejemplo, un defensor público no tiene fondos para contratar a alguien que procese los PDF en un formato fácil de leer, por lo que el tiempo de procesamiento se alarga mucho y aumenta la carga psicológica para el acusado
Incluso puede que ni siquiera se puedan procesar bien los datos
La solución es ilegalizar estas prácticas
Por ejemplo, los datos de intervenciones telefónicas deberían entregarse en un formato estandarizado legible por máquina, y no hay razón ética para que una simple fricción técnica influya en el resultado de un proceso penal
Me pregunto cuánto tiempo tendría que pasar para que esta solución tuviera efecto
En la empresa también tenemos miles de estos archivos; algunos son escaneos pésimos, otros tienen OCR de Adobe embebido, pero la mayoría no tiene nada
Pero, por lo general, no tienes ese control
El siguiente PDF en realidad es un archivo
.txtSi se guarda con la extensión
.pdf, se puede abrir en un visor de PDF y también modificar con un editor de textoPor ejemplo, al editar este archivo de texto se puede cambiar el texto que aparece en pantalla al abrir el PDF, la fuente, el tamaño de letra, el interlineado, la cantidad máxima de caracteres por línea, la cantidad de líneas por página, el ancho y alto del papel, e incluso la orientación vertical u horizontal
El ejemplo es una estructura mínima de PDF que empieza con
%PDF-1.4, escrita directamente como texto conCatalog,Pages,Font,Page,Contents,xref,trailer, etc.PDF no fue creado para texto, sino para diseño de página y gráficos
El ejemplo es bueno, pero cada línea podría estar dividida en una llamada por carácter, una llamada por palabra, o incluso estar en un orden mezclado
En la sección “2.3.2 Portability” del documento de referencia de PDF 1.0, los archivos PDF se describen como archivos ASCII de 7 bits, y se indica que incluso los documentos con imágenes y caracteres especiales se describen usando solo el subconjunto imprimible de ASCII
Como resultado, se explica que son altamente portables entre distintos entornos de hardware y sistemas operativos
https://opensource.adobe.com/dc-acrobat-sdk-docs/pdfstandard...
Hoy en día, en la mayoría de los PDF todos los objetos están comprimidos con deflate
Además, para hacerlo más difícil de seguir, muchos PDF agrupan la mayoría de los objetos dentro de objetos de tipo stream de objetos y luego vuelven a comprimirlos
Por eso, aunque intentes rastrear el final de
6 0 R, no puedes buscar6 0 Objen un editor de textoHay un documento que me gusta y que muestra las dificultades descritas en este texto: https://academic.oup.com/auk/article/126/4/717/5148354
Desde la primera página hay texto típico en dos columnas, un título centrado y un cuadro de texto metido entre las dos columnas que cambia la longitud de las líneas y la sangría
Más adelante aparecen encabezados que cambian entre páginas pares e impares, e incluso reglas de encabezados de sección que varían mucho
Peor aún, no hay espaciado adicional entre párrafos y tampoco siempre hay sangría en la primera línea, así que contiene todo tipo de dificultades
En alrededor del 95% de los casos era bastante bueno, y durante años eso fue suficiente en PDFKit y Preview de Mac
Si pensamos en la aplicación original que creó el PDF, por ejemplo un procesador de textos, es muy probable que haya renderizado el texto desde su propio búfer de texto hacia el contexto PDF en un orden bastante razonable
Por eso, incluso en documentos de dos columnas, muchas veces el texto fluía correctamente de la columna izquierda a la derecha, y dentro del PDF ya estaba en el orden correcto
Sin embargo, con los pies de página o encabezados no hay forma de saber en qué orden los volcó al contexto la aplicación que generó el PDF
Extraer texto de un PDF, incluso texto estructurado, no es nada fácil
Extraer tablas de un documento HTML suele ser sencillo incluso si el sitio usa el antipatrón de hacer todo con
div, y es aún más fácil si usa elementos semánticosCon PDF no es así
No soy experto en el formato, así que no sé cuánta compatibilidad hay con estructura semántica, pero he visto muchos PDF que construyen tablas como una colección suelta de elementos gráficos y de texto que solo parecen una tabla al renderizarse
En la práctica, tuve bastante éxito extrayendo datos de tablas convirtiendo primero el PDF a HTML con las utilidades PDF de Poppler, luego buscando los encabezados de tabla esperados y calculando las columnas según la coordenada x de cada valor para extraer los valores por fila
Es un método sucio, pero funcionó de manera estable para lo que necesitaba, y fue mucho mejor que lidiar con texto plano con formato, espaciado irregular o saltos de línea metidos en medio de una fila
Tiene varias funciones misceláneas, pero el objetivo central es interactuar de una forma más humana, como
page.find('text:bold:contains("Summary").below().extract_text()Como cada PDF es una pesadilla a medida, estoy recopilando ejemplos difíciles de extraer para usarlos como base de una biblioteca metodológica
https://jsoma.github.io/natural-pdf/
https://badpdfs.com/
Si alguien conoce una biblioteca de extracción de tablas de PDF que se pueda integrar en una app C++ y que sea gratis o cueste menos de unos cientos de dólares, agradecería que me avisara
Hay muchísimas formas de crear el mismo PDF
Algunas herramientas se parecen más a exportar desde un editor gráfico un diseño con texto y gráficos, mientras que otras se parecen más a exportar texto y gráficos donde las palabras van primero, como en un procesador de textos
La perspectiva con la que la aplicación generadora maneja la información suele influir en la forma en que produce el PDF
Si buscas una utilidad ya hecha, herramientas como cisdem han resuelto esto hasta el punto de extraer datos estructurados bastante bien para usuarios locales
Hay muchas herramientas de este tipo, y muchas prometen compatibilidad con datos estructurados, pero tienen que encajar bien con lo que quieres hacer
PDF es un formato de visualización.
Está optimizado para el ojo humano y para las impresoras, y sus funciones fueron aumentando con el tiempo.
Como medio para transmitir datos entre máquinas es pésimo, pero es muy bueno para que una persona lo lea o para guardar una página A4.
Si uno parte de la premisa de que, como un
.pdfalmacena texto, lo que quiere es ese texto, es como si le dijeran que simplemente agrande los ojos.O, si no, hay que lidiar con algo muy complejo.
Para empezar, el problema es si ese texto es texto real o una imagen.
El ojo humano puede leerlo igual con solo volver a ponerse los lentes, pero un parser puede romperse por errores de segmentación.
Como PDF está pensado para que lo lean personas, para leer un PDF hay que imitar a una persona.
Hace tiempo hice un parser de PDF de juguete, y cuando entendí cómo funcionaba el formato me llevé una gran sorpresa.
Pensándolo así, resulta todavía más extraño que PDF se use tanto para casos con mucho texto.
Me vienen a la mente especialmente casos como las facturas.
Los sistemas digitales deberían poder extraer datos fácilmente del archivo y, al mismo tiempo, presentarlos con un formato agradable para las personas.
Creo que sería mucho mejor si la industria tecnológica migrara a un formato más adecuado.