Capítulo 2 — Parsing inteligente de documentos

Segunda entrega del recorrido capítulo por capítulo de LLM Primer III: Enhancing Enterprise AI with RAG. Un sistema de recuperación hereda la calidad de sus entradas — y la capa de entrada es donde vive, en silencio, la causa más habitual de una calidad decepcionante en RAG.

Por qué existe este capítulo

La primera versión de una pipeline RAG casi siempre usa la utilidad de PDF-a-texto que tenía a mano. Sale un texto de aspecto plausible, el índice se rellena, el modelo produce respuestas de aspecto plausible. Meses después el equipo descubre que las tablas se aplanaron en silencio convertidas en prosa, los artículos a doble columna se entremezclaron línea a línea, las notas al pie se metieron dentro de los párrafos y los pies de figura se perdieron por completo. El techo de calidad de la recuperación quedó fijado por estas decisiones antes de que la recuperación estuviera siquiera configurada. El capítulo va de tomarse en serio la capa de entrada, porque nada aguas abajo puede rescatar lo que el parser tiró.

2.1 Por qué aplanar un PDF pierde lo que importa

Un PDF es una lista de glifos con coordenadas, dibujados sobre páginas de dimensión declarada. La estructura visual que ve una persona — columnas, tablas, pies de imagen, barras laterales — no está guardada en ningún sitio en forma semántica. Vive en la imagen renderizada. Por eso "extraer texto del PDF" es más difícil de lo que parece: el extractor ingenuo lee el flujo de glifos en el orden en que se dibujaron, lo que en una página a dos columnas entrelaza las columnas línea a línea. Lo que sale es texto gramaticalmente raro y semánticamente roto compuesto de palabras reales del documento real — el tipo de fallo difícil de detectar en una revisión rápida.

Con las tablas es peor. El significado de 1.427 en la fila 3, columna 4 es la intersección de Q3 2024 y región Noreste. Para un extractor ingenuo es un número sin relación con ninguna de las dos cadenas, porque esas cadenas se dibujaron en otro punto de la página. La tabla se disuelve en una lista de números separados por espacios en blanco, y las consultas sobre "ingresos del Noreste en Q3" no encuentran nada — el chunk que contiene 1.427 no contiene Noreste lo bastante cerca para asociarlos en el embedding. Los formularios tienen el modo de fallo análogo: etiquetas y valores salen como cadenas inconexas, y el índice ahora contiene valores sin sus nombres de campo. El OCR sobre documentos escaneados añade errores a nivel de carácter justo en términos técnicos y nombres propios — el sitio donde la recuperación es más sensible a la ortografía.

2.2 Parsing consciente del layout: reponer las señales

La respuesta es una clase de herramientas que tratan el documento como un artefacto bidimensional en lugar de un flujo de glifos. La página se renderiza a imagen, un modelo de detección de layout la segmenta en regiones (párrafos, tablas, figuras, encabezados), el orden de lectura se reconstruye con heurísticas de layout y las tablas pasan por modelos especializados que recuperan estructura de filas y columnas en HTML, Markdown o JSON. La salida ya no es una cadena plana — es una representación estructurada que preserva la jerarquía, ata los pies de figura a sus figuras y expone metadatos sobre los que el chunker de abajo puede dividir.

El coste es cómputo — de uno a varios segundos por página frente a milisegundos de la extracción ingenua, lo cual importa con corpus de millones de páginas. Y el modo de fallo cambia: un extractor ingenuo que destroza una tabla al menos produce texto. Un parser consciente del layout que identifica mal una región produce salida estructurada que puede estar confiadamente equivocada — una figura confundida con una tabla, un encabezado detectado como cuerpo de texto. El equipo necesita revisar a mano páginas complejas representativas antes de confiar en la pipeline a escala.

2.3 El panorama actual de herramientas

El espacio se ha consolidado en torno a media docena de herramientas que vale la pena conocer. LlamaParse es el parser alojado de LlamaIndex — fuerte en tablas y formularios, el valor por defecto adecuado si ya estás dentro del ecosistema LlamaIndex y los servicios gestionados son aceptables. Docling es el parser open-source de IBM consciente del layout, con el modelo TableFormer manejando estructuras de tablas complejas, y es la elección natural para despliegues on-premise donde los datos no pueden salir de tu infraestructura. Unstructured optimiza por amplitud — muchos formatos de entrada, un modelo de particionado por elemento tipado, una interfaz consistente aguas abajo — y es la primera elección más segura para corpus empresariales heterogéneos. Marker-PDF hace una cosa muy bien: PDF a Markdown limpio, con especial atención a títulos, listas y bloques de código. Firecrawl resuelve la entrada por el lado web — URL dentro, Markdown limpio fuera, con el boilerplate eliminado. DeepSeek-OCR, lanzado a finales de 2025, codifica páginas en muy pocos tokens de visión con un consumo de memoria y cómputo drásticamente menor, y es el contendiente serio cuando el throughput manda en el presupuesto.

La evaluación práctica se parece a esto: coge cincuenta documentos representativos que cubran el rango de dificultad del corpus, pasa cada herramienta sobre ellos, compara a mano en las dimensiones que importan a tu corpus — fidelidad de tabla, orden de lectura multi-columna, precisión del OCR en escaneos, manejo de figuras, throughput. El ganador rara vez es el mejor en todas las dimensiones. Es el mejor en las dimensiones que más importan a tu corpus, a un coste que tu presupuesto puede absorber.

2.4 La alternativa multimodal

Una vía paralela rechaza directamente el planteamiento. Si un modelo de visión-lenguaje puede leer una página lo bastante bien como para responder preguntas sobre ella, ¿por qué convertirla a texto? Los retrievers multimodales de interacción tardía como ColPali y ColQwen2 extienden la idea de ColBERT a imágenes — un embedding por parche de la página, puntuado contra los tokens de la consulta con agregación max-similarity. El retriever saca a la luz páginas cuyo contenido textual por sí solo no habría encajado, porque la información relevante estaba en una tabla, una figura o un layout que la extracción de texto habría estropeado. El modelo de visión-lenguaje lee la página directamente.

El coste es sustancial y vale la pena ser concretos. Un chunk de texto estándar produce un embedding de ~1.024 dimensiones — unos pocos kilobytes. Una página codificada con ColPali produce alrededor de mil embeddings de parche de ~128 dimensiones — medio megabyte por página. El tamaño del índice para un millón de páginas crece de gigabytes a centenas de gigabytes, la puntuación es más cara y la generación requiere un modelo de visión-lenguaje. Para corpus densos en tablas y figuras la mejora es real. Para corpus dominados por prosa con presupuesto ajustado, la recuperación de texto bien parseado sigue siendo el valor por defecto coste-efectivo. Las configuraciones híbridas — ColPali para recuperación, texto convertido para generación, o al revés — son donde aterrizará la mayoría del RAG multimodal en producción a lo largo del próximo año.

Lo que prepara el Capítulo 2

Un parse limpio y consciente del layout es necesario para un RAG de alta calidad y suficiente para nada. Un documento parseado sigue siendo un documento — hay que romperlo en piezas lo bastante pequeñas para embeberlas y lo bastante grandes para que signifiquen algo. El chunker que ignora las pistas estructurales del parser tira lo que el parser se esforzó por preservar. Las dos capas hay que diseñarlas juntas, y el Capítulo 3 recorre el espectro de chunking y las técnicas de frontera que lo han remodelado.

Próximamente — Capítulo 3: Frameworks avanzados de chunking. El espectro del chunking desde tamaño fijo hasta consciente de la estructura, el mito del solapamiento, el precipicio de contexto y las técnicas de recuperación contextual y late chunking que han cambiado las cuentas.