La ingesta: de PDF, HTML y bases de datos a texto limpio

Con esta entrega se abre el segundo bloque de la serie, dedicado a la preparación del corpus. Las siete primeras explicaron qué es RAG y cómo encajan sus piezas; a partir de aquí entramos en el trabajo sucio, empezando por el paso que casi ningún tutorial enseña y casi todos los proyectos acaban sufriendo.

El paso que decide el techo antes de empezar

Un sistema RAG se construye sobre fragmentos de texto, y todo lo que viene después opera sobre lo que la ingesta haya producido. Si la extracción mezcla dos columnas de un PDF, ninguna estrategia de recuperación posterior va a recomponer las frases. Si el pie de página se cuela en mitad de un párrafo, el fragmento que contenga la respuesta llevará ruido dentro para siempre. Si una tabla se aplana en una fila de números sin cabecera, el dato existe en el índice pero es ilegible.

Es también donde menos se avanza probando librerías al azar: la única forma de hacerlo bien es inventariar los formatos que hay de verdad en el corpus, mirar documentos de cada uno a mano y decidir un tratamiento por familia.

Extracción por formato

PDF nativo

Un PDF nativo —generado desde un procesador de texto y no escaneado— no contiene párrafos: contiene cadenas de caracteres posicionadas en la página. Reconstruir el párrafo es trabajo del extractor, y ahí aparecen las diferencias entre herramientas.

Los problemas recurrentes son siempre los mismos. El orden de lectura en documentos a dos columnas: si el extractor recorre la página por posición vertical, va alternando líneas de la izquierda y la derecha y produce un texto sin sentido. Las herramientas que analizan el layout —que agrupan bloques por proximidad y detectan columnas antes de serializar— resuelven esto; las que se limitan a volcar el flujo interno del PDF, no. Conviene comprobarlo con un documento a dos columnas antes de decidir nada.

El segundo problema son los encabezados y pies repetidos: el título, el número de página y el aviso de confidencialidad acaban incrustados cada dos mil caracteres. La detección es mecánica —si una línea corta aparece en la misma posición vertical en la gran mayoría de las páginas, es cabecera o pie y se retira— y es de las limpiezas con mejor relación entre esfuerzo y beneficio.

El tercero son los guiones de corte: un texto justificado parte palabras al final de línea, una acaba en «recupera-» y la siguiente empieza en «ción». Sin recomponerlos, el índice contiene tokens inexistentes y la búsqueda por palabra clave falla justo en los términos largos, que suelen ser los técnicos. La regla habitual —unir cuando la línea termina en guion y la siguiente empieza en minúscula— acierta casi siempre, con cuidado con los compuestos legítimos.

PDF escaneado y OCR

Si el PDF es una imagen hace falta reconocimiento óptico de caracteres (OCR), y conviene ajustar expectativas: sobre documentos limpios y bien digitalizados da resultados muy utilizables; sobre fotocopias torcidas, sellos, manuscritos o formularios con casillas, da un texto con errores que se propagan al índice sin que nadie los vea.

Tres decisiones importan. El preprocesado de imagen —enderezar, binarizar, subir resolución— mejora el resultado más que cambiar de motor. El idioma hay que declararlo: un OCR configurado en inglés sobre texto español destroza tildes y eñes. Y hace falta una puerta de calidad: registrar la confianza media por documento y marcar los que bajen de un umbral en lugar de indexarlos en silencio, porque un OCR malo no es neutro, envenena la recuperación con fragmentos que parecen texto y no lo son.

Los modelos de visión transcriben bien maquetas complejas y tablas, a cambio de un coste por página muy superior y de un riesgo nuevo: un OCR se equivoca por parecido gráfico, pero un modelo puede completar lo que cree que debería poner. En documentación crítica, eso obliga a muestreo humano.

HTML y páginas web

En HTML el problema no es extraer, es descartar. Menú, pie, banner de cookies y bloques de navegación, indexados, se convierten en cientos de fragmentos idénticos que compiten con el contenido real. Las librerías de extracción de contenido principal —las que puntúan la densidad de texto por nodo— resuelven la mayoría de los casos; en sitios propios, apuntar con un selector CSS al contenedor del artículo es más fiable y más barato.

La ventaja del HTML es que la estructura viene marcada: encabezados, listas y tablas están explícitos. Aplanarlo a texto pelado es tirar información que el troceado va a echar de menos; convertirlo a Markdown conserva la jerarquía a coste casi nulo.

Ofimática y correo

Los formatos de Office son XML comprimido y se leen con fiabilidad; los detalles molestos están en los márgenes. En Word, el control de cambios y los comentarios pueden colarse como texto del documento. En Excel, cada hoja hay que serializarla con sus cabeceras y las fórmulas leerlas por su valor calculado. En PowerPoint, el orden de los cuadros de texto no coincide con el de lectura, y las notas del ponente suelen valer más que la diapositiva.

El correo es un caso aparte por las cadenas citadas: un hilo de veinte mensajes contiene veinte veces el primero. Sin recortar la cita, el índice se llena de duplicados casi idénticos. Hay que separar el cuerpo nuevo de la cita y decidir si se indexa cada mensaje por separado o el hilo como una unidad.

Bases de datos

Una fila no es un documento. Volcar registros como id=4471; estado=2; fecha=2024-03-11 produce texto que ningún modelo de embeddings representa bien, porque no hay lenguaje natural que representar. La técnica que funciona es la verbalización: una plantilla que convierte cada registro en una frase legible, resolviendo los códigos a sus etiquetas.

Antes conviene preguntarse si el caso pide RAG: para «cuántos pedidos se cancelaron en marzo», una consulta SQL gana por goleada. El dato estructurado entra en el corpus cuando viene mezclado con texto libre —observaciones, incidencias, descripciones— o cuando el usuario pregunta en términos que no corresponden a ninguna columna.

Tabla de referencia por formato

Tablas: el formato que más se pierde

Las tablas son donde más información se destruye: aplanadas a texto pierden la relación entre celda y cabecera, y el fragmento contiene los números pero no lo que significan. Hay tres tratamientos, en orden creciente de esfuerzo: serializar a Markdown conservando la cabecera, que salva la mayoría de los casos y conviene por defecto; convertir cada fila en una frase con sus cabeceras; o guardar la tabla aparte, indexar una descripción y entregar la tabla completa cuando esa descripción se recupera.

Normalización y detección de idioma

Queda una capa de limpieza que hay que hacer con mano ligera: normalizar espacios y saltos múltiples, unificar la forma Unicode para que las tildes no aparezcan en dos codificaciones distintas, quitar caracteres invisibles y recomponer los guiones de corte. Lo que no conviene es lo que hacía la búsqueda clásica —bajar a minúsculas, quitar acentos, eliminar puntuación—: los modelos de embeddings usan esa información y quitarla degrada la representación.

La detección de idioma se hace en la ingesta y se guarda como metadato. Permite enrutar a modelos distintos, filtrar en la recuperación y, de paso, detectar extracciones defectuosas: cuando un detector devuelve baja confianza sobre un texto largo, casi siempre es que la extracción falló. Es una prueba de calidad barata y eficaz.

Conservar la estructura en vez de aplanar

La tentación al final de la ingesta es entregar una cadena de texto larga y seguir. Es un error caro: si al extraer sabes que una frase pertenece a la sección «Garantías» del capítulo «Condiciones de venta», página 14, esa información no vuelve a estar disponible nunca más si la tiras. Y sirve para trocear por secciones en vez de por longitud arbitraria, anteponer el camino de títulos a cada fragmento y citar con precisión.

La salida razonable de una ingesta no es texto plano: es Markdown, o un árbol de bloques con tipo, nivel jerárquico y posición de origen. Cuesta poco más y evita rehacer el trabajo tres entregas después.

Límites y contraindicaciones

La ingesta perfecta no existe y perseguirla es una forma de no terminar nunca. Hay documentos que no se extraen bien —planos, formularios manuscritos, diapositivas que son una imagen— y para los que la decisión correcta suele ser excluirlos del corpus y decirlo, en vez de indexarlos mal. Las pipelines muy elaboradas se vuelven lentas y frágiles: una reindexación que tarda dos días condiciona todo el ciclo de vida del corpus. Y toda regla de limpieza tiene falsos positivos, empezando por el detector de cabeceras, que se come títulos legítimos.

La práctica que más rinde es la menos técnica: extraer veinte o treinta documentos representativos, leer el texto resultante con los ojos y anotar qué se ha roto. Media hora ahí ahorra semanas depurando la recuperación en busca de un problema que estaba dos pasos antes.

Qué viene ahora

Con el texto limpio y estructurado, el siguiente paso es partirlo. La próxima entrega abre las tres dedicadas al troceado: por qué es obligatorio, en qué unidad se mide y las dos estrategias de partida —tamaño fijo con solapamiento y división recursiva— con criterios para elegir tamaño sin ir a ciegas.

Los tres libros gratuitos de los que nace esta serie están disponibles en PDF y EPUB: RAG para tu negocio (nivel básico), RAG por dentro (intermedio) y RAG en producción (avanzado).

Aviso de contenido generado con inteligencia artificial.
Este artículo ha sido redactado con la asistencia de sistemas de inteligencia artificial y revisado antes de su publicación. Se informa de ello de forma expresa en cumplimiento de la normativa vigente sobre transparencia en el uso de IA.