Preparar PDF para LLM y pipelines de recuperación

Por qué no basta con extraer el texto en crudo

Cualquier biblioteca de PDF te dará el texto de un documento en un par de líneas de código, y para un memorándum a una columna eso basta de verdad. Para cualquier otra cosa no, por tres razones que cuestan calidad de recuperación.

Primera, el orden de lectura. La extracción en crudo devuelve el texto en el orden en que se dibujaron los glifos, lo que en una página a dos columnas entrelaza las columnas. La mitad de tus chunks pasan a ser fragmentos de frase alternando entre párrafos sin relación, y se incrustan en un punto del espacio vectorial que no corresponde a nada.

Segunda, los límites. Sin títulos no hay nada sobre lo que trocear salvo el recuento de caracteres, así que los chunks se parten a mitad de frase y a mitad de tabla, y un chunk que empieza a mitad de una explicación no se entiende por sí solo, que es justo lo que un chunk recuperado tiene que hacer.

Tercera, las tablas. Extraída como texto en crudo, una tabla se convierte en un flujo de números sin ninguna indicación de a qué columna pertenece cada uno. Un modelo que lea eso responderá igualmente a tu pregunta. Solo que la respuesta será falsa.

Qué le aporta Markdown al pipeline

Markdown es un buen formato intermedio aquí por razones que no tienen nada que ver con que sea bonito.

• Los títulos te dan límites semánticos de chunk, así que un chunk es una sección y no una ventana de mil caracteres.
• La ruta de títulos da contexto a cada chunk: puedes anteponer "Capítulo 3 › Límites de tasa › Comportamiento en ráfagas" antes de incrustarlo, lo que mejora de forma medible la recuperación en documentos donde la misma palabra significa cosas distintas en secciones distintas.
• Las tablas de barras mantienen asociadas filas y columnas, así que un modelo que lea una tabla recuperada puede saber qué cifra pertenece a qué encabezado.
• Es compacto. Markdown transporta estructura a coste de unos pocos caracteres por elemento, mientras que HTML o los formatos JSON de maquetación gastan tokens en marcado que no le dice nada al modelo.
• Es un formato del que todos los modelos actuales han visto cantidades enormes durante el entrenamiento, así que no necesita explicación en el prompt.

Trocear, en concreto

El enfoque que funciona con documentos convertidos es partir primero por títulos y recurrir a los límites de tamaño solo dentro de una sección demasiado grande.

Parámetros aproximados que aguantan en casi todos los tipos de documento:

Nunca partas una tabla

Es la regla que más pipelines incumplen, porque un troceador ingenuo no tiene ni idea de que está dentro de una.

Una tabla de GFM partida por la mitad produce dos chunks, y ninguno es una tabla válida: el primero tiene cabecera y algunas filas, el segundo tiene filas sin cabecera alguna. El segundo es peor que inútil, porque sus números no llevan etiqueta y el modelo se la pondrá adivinando.

Detecta los bloques de tabla antes de trocear y mantén cada uno intacto, aunque eso signifique un chunk por encima del tamaño objetivo. Si una tabla es de verdad demasiado grande para un chunk, repite la fila de cabecera en cada trozo.

Dónde encajan los documentos escaneados

Un escaneo no tiene texto, así que no hay nada que trocear. El reconocimiento de texto tiene que ir primero, y su salida tiene propiedades que un pipeline debe tener en cuenta, porque el reconocimiento es una estimación y no una transcripción.

Dos en particular. La confianza varía por página, así que un documento puede ser casi perfecto durante cuarenta páginas y poco fiable en tres; si tu paso de reconocimiento informa de la confianza por página, llévala a los metadatos del chunk para poder marcar una respuesta de baja confianza. Y las palabras ilegibles se descartan en lugar de señalarse, lo que significa que el texto parece fluido y completo mientras le faltan justo los elementos que más le costaron al motor: a menudo nombres, códigos de referencia y cifras.

Para cualquier cosa donde un error tenga consecuencias, el texto reconocido debe tratarse como una pista que verificar contra el original, no como fuente de registro.

Qué revisar antes de indexar un corpus

Indexar es el paso caro, lento y difícil de deshacer, así que vale la pena dedicar veinte minutos antes a una muestra. Convierte cinco documentos elegidos por ser distintos entre sí y lee el Markdown.

• ¿Los títulos forman una escalera sensata? Si están planos, tu troceador no tiene por dónde partir y acabarás con ventanas de tamaño fijo en todo el corpus.
• ¿Sobrevivieron las tablas? Cuenta las columnas contra el original en dos o tres.
• ¿Es correcto el orden de lectura en las páginas a varias columnas? Las columnas entrelazadas son obvias en cuanto las miras e invisibles una vez indexadas.
• ¿Hay conversiones vacías o casi vacías? Eso son escaneos, y necesitan otro camino.
• ¿Se repite el mismo texto de plantilla en todos los documentos? Los encabezados y pies repetidos se convierten en chunks casi duplicados que desplazan al contenido real en los resultados.

La dimensión de privacidad, que no es accesoria

Los corpus para RAG se construyen justo con los documentos que las organizaciones menos quieren entregar a un tercero: contratos, informes internos, registros de clientes, investigación aún no publicada.

Vale la pena ser deliberado sobre qué pasos de tu pipeline envían esos documentos a algún sitio. La conversión no tiene por qué ser uno de ellos: un conversor basado en navegador procesa el archivo en la máquina donde ya está, así que el paso de conversión no añade ninguna parte a la cadena. Si los pasos posteriores lo hacen es una decisión aparte, pero es una decisión que puedes tomar por separado.