Tercera parte de la serie «RAG personal».
En los artículos anteriores de esta serie expliqué por qué un sistema RAG personal no empieza por el modelo que redactará la respuesta.
Empieza mucho antes: organizando los documentos, entendiendo qué tenemos y construyendo una ingesta que no convierta una carpeta desordenada en una base de conocimiento igualmente desordenada.
En el primer capítulo describí ese recorrido general. Después, en el segundo capítulo, profundicé en el inventario documental.
En aquella visión general ya apunté que no todos los documentos debían pasar por el mismo procesador. Era una idea necesaria para explicar el recorrido completo, pero todavía quedaba por resolver cómo convertirla en una decisión consistente, explicable y segura para cada objeto documental.
No basta con localizar archivos. Hay que identificar su contenido, reconocer duplicados, conservar su procedencia y distinguir entre originales, copias, adjuntos, derivados y elementos contenidos dentro de otros archivos.
Una vez construida esa base apareció la siguiente pregunta:
Ya sé qué documentos tengo y de dónde proceden, pero ¿qué debe hacer el sistema con cada uno?
Mi primera respuesta fue bastante simple: reconocer la extensión, elegir un extractor y continuar.
Si era un PDF, utilizar el procesador de PDF. Si era un documento de texto, emplear el correspondiente. Si era una hoja de cálculo, aplicar otra ruta.
Sobre el papel parecía razonable.
El problema fue que los documentos reales no habían leído mi diseño.
Dos archivos con la misma extensión podían contener cosas completamente distintas. Un PDF podía tener texto perfectamente extraíble, estar compuesto por imágenes escaneadas, incluir una capa textual defectuosa, estar protegido o tener una estructura demasiado compleja para el tratamiento normal.
Algunos terminaban aparentemente bien. La herramienta no mostraba errores y el proceso devolvía un resultado.
Pero, al revisarlo, aparecían páginas reducidas a unas pocas palabras, tablas convertidas en una sucesión incomprensible de cifras o textos cuyo orden ya no tenía relación con el documento original.
Fue entonces cuando entendí que faltaba una capa entre descubrir el archivo y procesarlo.
A esa capa la llamo router documental. No es una denominación universal, sino una forma sencilla de describir el componente que observa cada objeto, reúne señales sobre él y decide qué camino debería seguir antes de ejecutar ninguna transformación.
Cuando «sin errores» no significa «correcto»
Una de las primeras sorpresas apareció durante las pruebas: algunos documentos parecían haberse procesado correctamente.
No había excepciones ni mensajes de error. El extractor terminaba y generaba texto.
El problema era que el resultado apenas servía para nada.
Los encabezados aparecían mezclados con los pies de página, algunos párrafos estaban fuera de orden y determinadas tablas se habían convertido en listas de valores sin una relación aparente entre ellos.
Técnicamente, el proceso había finalizado.
Documentalmente, había fracasado.
Esta experiencia me obligó a separar dos ideas que hasta entonces había tratado como si fueran la misma:
- que una herramienta sea capaz de abrir un archivo;
- que sea capaz de conservar la información que ese archivo representa.
Desde entonces intento no utilizar «procesado» como sinónimo de «correcto».
Que una herramienta termine sin errores solo demuestra que ha podido completar su operación. No demuestra que el contenido resultante conserve la estructura, el contexto o el sentido del original.
La ausencia de errores técnicos no es una prueba suficiente de calidad documental.
Procesar no es lo mismo que decidir cómo procesar
Cuando uno empieza a construir un RAG, es fácil imaginar una cadena lineal:
- Localizar el archivo.
- Extraer el texto.
- Dividirlo en fragmentos.
- Generar embeddings.
- Incorporarlo al índice.
Esta secuencia puede funcionar bien en una demostración preparada con unos cuantos documentos conocidos.
El problema aparece cuando se enfrenta a un repositorio real.
Una hoja de cálculo no se entiende recorriendo sus celdas como si fueran párrafos. Un correo puede tener poco valor por su cuerpo y mucho por sus adjuntos. Una presentación distribuye la información entre títulos, cuadros de texto, gráficos y notas. Un archivo comprimido puede contener numerosos objetos diferentes, cada uno con su propia identidad y procedencia.
También encontré documentos que parecían vacíos hasta que los inspeccioné de otra forma.
El contenido estaba allí. Simplemente estaba representado como imagen, incrustado dentro de otra estructura o almacenado de una manera que el primer extractor no sabía interpretar.
El documento no había fallado.
Había fallado la ruta elegida para tratarlo.
Un extractor que no obtiene un buen resultado no siempre demuestra que el archivo esté mal. A veces demuestra que hemos elegido el camino equivocado.
Qué hace realmente un router documental
Un router documental no debería ser una larga cadena de condiciones del tipo «si termina en PDF, utiliza el procesador de PDF».
La extensión es una pista útil, pero no una decisión.
El router observa el objeto y reúne señales suficientes para responder preguntas como estas:
- ¿Qué formato parece tener realmente?
- ¿Contiene texto accesible o predomina el contenido visual?
- ¿Qué estructura necesita conservarse?
- ¿De dónde procede y qué relación mantiene con otros objetos?
- ¿Está dentro de unos límites razonables de tamaño y complejidad?
- ¿Existe alguna condición que obligue a detener el tratamiento automático?
Con esas señales, el router asigna una ruta y registra por qué la ha elegido.
Su función no consiste en ejecutar el OCR, convertir el documento, abrir un contenedor o incorporar el contenido al índice.
Su responsabilidad es anterior: determinar qué tratamiento parece necesario, explicar la decisión y señalar qué pasos podrían plantearse después.
Al final, la entrada del router es bastante concreta: un objeto identificado y las señales obtenidas durante su inspección.
La salida también debería serlo: una ruta, las razones de la decisión y los pasos que podrían autorizarse después.
Esta separación cambió la forma en que estaba construyendo el sistema.
Primero se observa. Después se clasifica y se propone una ruta. Luego se autoriza, se ejecuta y se valida el resultado.
Cómo empezó realmente el router
La primera versión no era especialmente sofisticada.
Partía de una asociación bastante directa entre extensiones y procesadores. Era una forma lógica de empezar porque permitía recorrer el repositorio, asignar un tratamiento inicial y descubrir rápidamente los primeros problemas.
También dejó al descubierto su principal limitación: estaba clasificando nombres de archivo, no documentos.
El siguiente paso fue añadir señales.
Ya no bastaba con saber que algo terminaba en .pdf. También quería saber si contenía texto útil, si predominaba el contenido visual, si su estructura requería otro tratamiento o si había alguna razón para detenerlo.
Después añadí algo que al principio no parecía imprescindible: la explicación de la decisión.
El router no debía limitarse a asignar una ruta. Tenía que conservar por qué la había elegido.
La evolución fue aproximadamente esta:
- asociar extensiones con procesadores;
- inspeccionar el contenido antes de decidir;
- separar rutas normales, especiales y detenidas;
- registrar las señales que justificaban la clasificación;
- separar la decisión del permiso para ejecutarla;
- validar las reglas sobre el repositorio completo.
No fue un diseño que apareciera terminado desde el principio.
Fue una respuesta progresiva a los casos que dejaban de encajar en la versión anterior.
En ese momento todavía no estaba resolviendo cómo escribir cada regla en código. Antes necesitaba aclarar qué debía observar el sistema, qué decisiones podía emitir y qué información tendría que conservar para explicar después por qué había elegido una ruta y no otra.
Eso me llevó a definir algo que, en programación, suele llamarse un contrato. El término puede sonar más formal de lo que realmente es. En este contexto no se refiere a un documento legal, sino a un acuerdo claro sobre qué recibe una pieza del sistema y qué debe devolver a cambio.
Cuando conseguí separar esas responsabilidades, el contrato del router quedó reducido a unas cuantas cosas:
- recibe un objeto ya identificado y las señales obtenidas durante su inspección;
- evalúa una versión conocida de las reglas que pueden aplicarse a ese objeto;
- resuelve qué condición debe prevalecer cuando varias reglas apuntan en direcciones distintas;
- produce una ruta y explica por qué la ha elegido;
- deja identificada la versión de las reglas y señala qué pasos podrían autorizarse después.
Definir este contrato antes de programar el router me permitió separar dos problemas que al principio estaban mezclados. Uno era decidir qué debía ocurrir con cada documento. El otro era construir el código capaz de tomar esa decisión de una forma repetible.
Solo después de aclarar esa entrada y esa salida tenía sentido pensar en funciones, reglas, estados o estructuras de datos. El código debía representar una decisión ya entendida, no intentar descubrirla mientras se ejecutaba.
El router tampoco es el orquestador completo del proceso. Su trabajo termina cuando deja una decisión explicada. El orquestador es la pieza que toma esa decisión, comprueba si puede ejecutarse y coordina después el procesador correspondiente.
Una extensión no explica por sí sola el documento
Durante mucho tiempo hemos utilizado el formato como una descripción suficiente del contenido.
Decimos «es un PDF», «es una hoja de cálculo» o «es un correo» y asumimos que eso basta para saber qué hacer.
Pero un formato solo cuenta una parte de la historia.
Un PDF puede ser un informe digital, un formulario, una imagen escaneada, una colección de anexos o una combinación de texto y contenido visual.
Dos hojas de cálculo pueden compartir extensión y, sin embargo, ser completamente diferentes. Una puede contener una tabla sencilla. La otra puede depender de varias hojas, fórmulas, encabezados agrupados y relaciones que desaparecen cuando se convierte todo en texto lineal.
Lo mismo ocurre con los correos electrónicos.
Es habitual encontrar mensajes cuyo cuerpo apenas dice «Te envío la documentación» o «Adjunto la versión actualizada».
Si el sistema trata únicamente el texto visible, guarda una comunicación casi irrelevante.
La información valiosa puede estar en los adjuntos y en la relación entre ellos, el mensaje, la fecha y el hilo al que pertenecen.
Un archivo comprimido plantea otro problema.
El contenedor puede no aportar contenido semántico por sí mismo, pero conserva una estructura de procedencia. Cuando se inspeccionan sus elementos internos, esa relación no debería desaparecer.
Por eso el router no identifica únicamente formatos.
Intenta reconocer formas de información.
La pregunta deja de ser «¿qué extensión tiene?» y pasa a ser:
¿Cómo está representada aquí la información que necesito conservar?
Rutas normales, especiales y bloqueadas
Muchos documentos pueden seguir una ruta conocida y previsible. Otros requieren un tratamiento especial. Y algunos no deberían avanzar automáticamente.
La ruta normal
La ruta normal está pensada para objetos cuyo tratamiento está suficientemente controlado.
El formato está soportado, el archivo es legible, se encuentra dentro de los límites previstos y no presenta condiciones que obliguen a utilizar otra estrategia.
Las señales obtenidas durante la inspección indican que el contenido puede extraerse por la vía habitual y que su estructura debería conservarse con suficiente calidad.
En ese caso, el sistema puede extraer, validar el resultado, asociarlo con su procedencia y prepararlo para las fases posteriores.
Durante las primeras pruebas es fácil escribir una regla que, en la práctica, diga:
Si no he detectado ningún problema conocido, sigue adelante.
El inconveniente es que no detectar un problema no equivale a entender el documento.
En un diseño prudente, lo desconocido no se interpreta automáticamente como normal.
Las rutas especiales
Muchos archivos son perfectamente válidos, pero necesitan otro tratamiento.
Una ruta especial no exige necesariamente una aprobación humana. Puede estar previamente autorizada por una política, pero sigue siendo distinta de la ruta normal y debe ejecutarse bajo condiciones conocidas.
Un documento escaneado puede requerir reconocimiento óptico de caracteres. Un formato que necesita conversión previa puede exigir comprobaciones adicionales. Una hoja de cálculo extensa puede requerir un procesamiento que conserve filas, columnas y encabezados. Un correo puede necesitar separar cuerpo, cabeceras y adjuntos. Un contenedor puede necesitar primero un inventario de sus elementos internos.
Los formatos que requieren una conversión previa muestran bien por qué una ruta especial no consiste únicamente en elegir otra herramienta.
Convertirlos automáticamente puede resolver una dificultad y crear otras: comprobar si el resultado conserva todas las páginas, determinar si ha desaparecido algún elemento y mantener la relación entre el original y el nuevo archivo.
La conversión no es solo una solución técnica. Es una transformación que debe quedar registrada.
Una ruta especial también debe conservar la historia de lo ocurrido.
Las rutas bloqueadas o en revisión
También existen objetos que no deberían avanzar automáticamente.
Puede tratarse de archivos corruptos, incompletos, cifrados, no reconocidos o demasiado complejos para el procesamiento disponible.
En otros casos, la operación necesaria todavía no está autorizada o requiere una revisión que el sistema no puede sustituir.
Al principio, la existencia de archivos bloqueados puede parecer un fracaso del pipeline.
Con el tiempo empecé a verlo de otra forma.
Un sistema que fuerza todos los documentos hasta el índice puede parecer más completo, pero también puede estar incorporando contenido vacío, incompleto o mal interpretado.
No procesar automáticamente también puede ser una decisión correcta.
Bloquear un archivo no significa borrarlo ni ignorarlo.
Un bloqueo bien diseñado debe conservarlo, registrar la causa e indicar qué condición tendría que cumplirse para reconsiderarlo.
Quizá necesite una contraseña autorizada, una herramienta diferente, un entorno aislado, una revisión humana o una estrategia específica de recuperación.
La cuarentena, entendida así, no es un vertedero.
Es un estado controlado en el que el objeto permanece identificado, trazable y pendiente de una decisión posterior.
Un ejemplo sencillo: cuatro archivos que parecen iguales
Imaginemos que el inventario encuentra cuatro archivos PDF.
Desde fuera todos pertenecen al mismo formato, pero una primera inspección revela que representan la información de formas distintas.
El router no toma estas decisiones por intuición. Cada ruta nace de una señal observable: presencia de texto, contenido visual, estructura compleja o imposibilidad de inspección.
El primero contiene texto digital, tiene una estructura sencilla y el extractor conserva correctamente sus párrafos. El router le asigna la ruta normal.
El segundo está formado por páginas escaneadas. Una extracción convencional apenas devuelve contenido, pero la inspección detecta que las páginas contienen imágenes. En lugar de considerarlo vacío, el router propone una ruta de reconocimiento óptico.
El tercero combina texto con una tabla cuya relación entre filas y columnas es importante. Convertirla directamente en una sucesión de palabras destruiría parte de su significado. El router lo deriva hacia un tratamiento estructurado.
El cuarto está cifrado. El sistema reconoce el formato, pero no puede inspeccionar su contenido ni justificar una extracción. La decisión correcta no es intentar forzarlo, sino detenerlo y registrar la causa.
Los cuatro archivos terminan en .pdf.
Sin embargo, compartir extensión no implica compartir ruta.
Este ejemplo resume lo que acabé esperando del router: no que conociera todos los documentos, sino que supiera distinguir cuándo podía avanzar, cuándo necesitaba otro procedimiento y cuándo debía detenerse.
Cuando un archivo activa varias reglas
En la práctica, las condiciones no siempre aparecen de forma aislada.
Un mismo documento puede ser muy grande, estar escaneado, proceder de un contenedor y requerir una revisión adicional.
Este fue uno de los problemas que no apareció con claridad en las primeras pruebas.
Mientras utilizaba ejemplos sencillos, cada archivo parecía encajar en una única categoría. Cuando amplié el análisis, empezaron a aparecer objetos que activaban varias condiciones a la vez.
Una regla podía indicar que el documento necesitaba una ruta de recuperación técnica. Otra podía señalar que requería un tratamiento estructurado. Una tercera podía impedir que avanzara automáticamente.
Si cada regla actuaba de forma independiente, el resultado podía depender del orden en el que se ejecutaban las comprobaciones.
Tuve que decidir qué regla mandaba cuando varias se activaban sobre el mismo documento.
En la práctica, eso significa establecer una precedencia clara entre las distintas condiciones. El orden no es universal: depende de los riesgos, de las capacidades del sistema y, sobre todo, de qué operaciones permanecen bloqueadas en cada fase.
Lo importante es que exista una regla clara que responda a esta pregunta:
Cuando un objeto cumple varias condiciones, ¿cuál determina lo que puede ocurrir inmediatamente después?
Sin una precedencia definida, una modificación aparentemente pequeña puede cambiar la clasificación.
Con ese orden definido, el resultado deja de depender de qué comprobación se ejecutó primero y puede repetirse después en las mismas condiciones.
Clasificar también significa explicar
Un router no debería devolver una etiqueta opaca que solo entienda el código que la generó.
Si un documento se envía a recuperación, revisión o bloqueo, una persona debería poder comprender la causa.
No hace falta redactar un informe extenso para cada archivo, pero sí conservar información suficiente para reconstruir la decisión:
- qué condición se detectó;
- qué regla se activó;
- qué ruta se asignó;
- qué operaciones podrían proponerse o autorizarse después;
- qué operaciones continúan prohibidas.
En las primeras versiones de este tipo de clasificación es tentador utilizar códigos breves, porque resultan cómodos para el programa.
El problema aparece semanas después, cuando uno encuentra una etiqueta y ya no recuerda qué combinación exacta de condiciones la produjo.
Por eso empecé a tratar la explicación como parte de la salida, no como un comentario opcional.
Una decisión puede expresarse de forma sencilla:
Se propone una ruta de recuperación porque la extracción no contiene texto útil, aunque el documento presenta contenido visual que puede analizarse mediante otro procedimiento.
O:
El procesamiento automático se detiene porque la operación necesaria generaría un nuevo derivado y todavía no ha sido autorizada.
La explicación tiene que servir para algo: entender por qué se detuvo el documento y saber qué habría que hacer para que pudiera continuar.
Una clasificación explicable permite revisar errores, ajustar reglas y saber si el problema estaba en el documento, en la ruta elegida o en el propio diseño del sistema.
Detectar una necesidad no significa poder ejecutarla
Separar la necesidad de la autorización fue uno de los cambios que más orden puso en el diseño.
El router puede determinar que un archivo comprimido necesita inspección, pero eso no implica que pueda abrirlo inmediatamente.
Puede detectar que un documento requiere OCR sin que eso autorice a enviarlo a cualquier herramienta disponible.
Puede concluir que un formato necesita conversión, pero esa conversión genera un nuevo archivo y puede alterar aspectos del original.
Hay operaciones que crean derivados, expanden contenedores, consumen recursos, modifican estados persistentes o incorporan información a otros sistemas.
No deberían desencadenarse únicamente porque una regla haya identificado una necesidad.
El router debe poder decir:
Este es el tratamiento que parece necesario.
Mientras otra capa responde:
Este tratamiento está autorizado para este objeto, con estas condiciones y dentro de este alcance.
Separar ambas decisiones reduce el riesgo de ejecutar operaciones prematuras o difíciles de revertir.
También permite inspeccionar el plan antes de llevarlo a cabo.
Se puede revisar qué documentos recibirían OCR, cuáles serían convertidos, qué contenedores se abrirían o qué objetos permanecerían bloqueados.
Esa revisión previa permite detectar reglas demasiado amplias antes de que produzcan transformaciones reales.
Este fue uno de los aprendizajes más útiles: a veces es mucho más barato corregir una decisión que corregir todos los resultados que habría generado.
Pensar cada documento como un objeto que avanza entre estados me ayudó también a evitar saltos peligrosos.
Un archivo puede estar detectado, identificado, clasificado o pendiente sin estar todavía procesado, validado ni preparado para incorporarse al índice.
Cada paso debe tener una causa y unas condiciones.
Un archivo no debería pasar directamente de «encontrado» a «incorporado al índice» solo porque una biblioteca haya conseguido extraer unas cuantas líneas de texto.
Determinismo, trazabilidad y originales intactos
También necesitaba que el router no cambiara de opinión sin una razón.
Si recibe el mismo objeto, las mismas señales y la misma versión de las reglas, debería asignar la misma ruta.
Esto permite diferenciar dos situaciones que pueden parecer similares:
- ha cambiado el documento;
- han cambiado las reglas utilizadas para clasificarlo.
Si cambia el contenido, puede ser necesario evaluarlo como un objeto nuevo.
Si cambian las reglas, quizá haya que revisar decisiones anteriores aunque los archivos sigan siendo exactamente los mismos.
Para distinguir ambas cosas, las reglas necesitan una versión y las decisiones deben conservar suficiente trazabilidad.
Al mismo tiempo, el router no debería modificar el original.
Un texto extraído es un derivado. Un documento convertido es un derivado. El resultado de un OCR también lo es.
Todos pueden ser útiles, pero ninguno debería sustituir silenciosamente al archivo del que proceden.
He comprobado que esta disciplina parece innecesaria mientras solo existe una versión de cada cosa.
El problema llega después, cuando conviven el original, una conversión, varias extracciones, un reintento y una versión regenerada con una herramienta distinta.
Si la relación entre esos objetos no se registró desde el principio, reconstruirla posteriormente puede ser muy difícil.
Las pruebas pequeñas ayudan; en mi caso, el corpus completo decidió
Las pruebas pequeñas son indispensables durante el desarrollo.
Permiten reproducir errores, entender una condición y ajustar una regla sin recorrer todo el repositorio.
Yo también empecé así.
Seleccionaba unos cuantos documentos representativos, ejecutaba el router, revisaba las rutas y corregía lo que no encajaba.
Durante un tiempo, el resultado parecía bastante sólido.
Después lo probé con el conjunto completo.
Aparecieron formatos antiguos, archivos enormes, extensiones incorrectas, documentos híbridos, contenedores, extracciones vacías y objetos que activaban varias reglas a la vez.
También aparecieron casos que no había imaginado porque ninguna muestra escogida manualmente los contenía.
Una colección de prueba suele estar formada por aquello que esperamos encontrar.
El corpus real incluye también aquello que no sabíamos que existía.
Al validar la clasificación global pueden aparecer señales muy útiles:
- demasiados objetos están entrando por la ruta normal;
- una regla nunca se activa;
- un formato termina con demasiada frecuencia en revisión;
- una condición bloquea mucho más contenido de lo previsto;
- dos ejecuciones sobre las mismas entradas producen resultados distintos.
Estas estadísticas no sustituyen la revisión de casos concretos.
Pero ayudan a descubrir problemas que no serían visibles observando únicamente unos cuantos ejemplos.
Las muestras me sirvieron para depurar. Para considerar validado el router necesitaba comprobar que su comportamiento seguía siendo coherente cuando aparecían todas las excepciones del repositorio completo.
De contar archivos procesados a revisar decisiones
Construir esta capa cambió también mi forma de medir el avance.
Al principio parecía que el sistema progresaba cuando aumentaba el número de documentos procesados.
Después comprendí que una medida más útil era saber cuántos habían seguido una ruta justificada, cuántos habían producido un resultado validable y cuántos se habían detenido por una razón comprensible.
La extensión orienta, pero no decide. Un proceso sin errores puede producir un resultado documentalmente inútil. Detener un archivo es preferible a forzarlo hasta el índice sin garantías. Y cualquier regla que parece sólida con una muestra debe enfrentarse después al repositorio completo.
Un sistema serio no es el que afirma poder tratarlo todo.
Es el que sabe explicar qué puede tratar, cómo piensa hacerlo y en qué momento debe detenerse.
Lo que cambia al añadir esta capa
Cuando empecé, el recorrido parecía sencillo: encontrar un archivo, extraer su texto y continuar. El router apareció cuando comprobé que esa secuencia funcionaba con los documentos fáciles, pero no con todos los demás.
Añadir esta capa no sirve para procesar más deprisa ni para presumir de que el sistema admite cualquier formato. Sirve para evitar que una decisión equivocada al principio arrastre el error hasta el índice.
Ahora cada documento tiene que pasar primero por una pregunta bastante básica: ¿qué tengo realmente delante y cuál es la forma más razonable de tratarlo?
En algunos casos podrá seguir la ruta normal. En otros necesitará OCR, una conversión, un tratamiento que conserve su estructura o una revisión adicional. Y también habrá archivos que, por el momento, no deban avanzar.
Lo importante es que esa decisión no quede escondida dentro del extractor. Tiene que poder explicarse, repetirse y revisarse si cambian el documento, las señales o las reglas.
Con el router ya puedo decidir qué camino debería seguir cada objeto. El siguiente problema es comprobar si, después de recorrerlo, el resultado conserva de verdad el contenido, la estructura y el sentido del original.
Ese será el siguiente paso de la serie: no dar por buena una extracción solo porque haya terminado sin errores.
¿Quieres seguir explorando?
Puedes descubrir más artículos, seguir mis publicaciones en LinkedIn o escribirme.