En muchas empresas, RAG (Retrieval-Augmented Generation) se ha convertido en el atajo preferido para “conectar” documentos internos con un modelo de lenguaje: indexas archivos, creas una base vectorial y el chatbot responde con seguridad. Sobre el papel suena tan sencillo como poner etiquetas a cajas en un trastero y pedirle a alguien que te traiga “la caja de facturas”. El problema aparece cuando el trastero no son cajas, sino un manual de ingeniería lleno de tablas, notas al pie, diagramas y jerarquías visuales.
En sectores donde la precisión es irrenunciable —infraestructura, fabricación, energía, aeroespacial— el resultado suele ser decepcionante: el usuario hace una pregunta concreta y el bot contesta algo plausible, pero incorrecto. Y lo más incómodo: a veces el fallo se interpreta como “el modelo alucina”, cuando en realidad el tropiezo ocurre antes, en la cocina del sistema. Esta idea, defendida en un análisis publicado en la comunidad de VentureBeat por el arquitecto de IA Dippu Kumar Singh, apunta a un culpable menos glamuroso que el modelo de turno: el preprocesado del documento.
El error clásico: tratar un documento como una cadena de texto
Muchos tutoriales de RAG parten de un supuesto práctico: el documento es texto corrido. Con esa premisa, el paso típico es cortar en trozos de tamaño fijo, como si usaras unas tijeras que recortan cada 500 caracteres o cada X tokens. Funciona razonablemente con prosa narrativa, políticas internas sencillas o artículos. Con PDF técnicos, ese enfoque se parece a intentar entender una receta recortando cada línea por la mitad y mezclándola en una bolsa.
El ejemplo más habitual es una tabla de especificaciones. Imagina una fila con “Límite de voltaje” en una columna y “240 V” en otra, dentro de una tabla larga. Si el recorte cae justo en medio, el sistema guarda por un lado el encabezado y por otro el valor. En la búsqueda vectorial, el fragmento que contiene “Límite de voltaje” puede recuperarse sin el fragmento donde está “240 V”. Cuando el modelo tiene que responder, rellena el hueco como haría cualquiera ante un examen sin el libro: intenta inferir, elige una cifra plausible y la presenta con tono convincente. El problema no es que el modelo “sea mentiroso”; es que lo estás obligando a improvisar porque el dato está separado del contexto que le da sentido.
Chunking semántico: recortar siguiendo la lógica del manual
La alternativa práctica es abandonar el recorte por longitud y pasar a un chunking semántico. La idea es simple: en lugar de cortar por metrónomo, cortas por estructura, como haría un lector humano. Aquí entran en juego herramientas de análisis de maquetación y estructura, tipo Azure Document Intelligence de Microsoft, que detectan capítulos, apartados, párrafos, encabezados, pies de figura y límites de tabla.
Cuando el troceado respeta esa arquitectura, cada “chunk” se parece más a una unidad de conocimiento real. Una sección sobre un componente concreto se conserva completa, aunque sea más larga o más corta que el promedio. Y, crucialmente, una tabla se mantiene como una entidad íntegra: no se trocean filas y columnas como si fueran frases. Esto preserva las relaciones fila-columna, que en documentación técnica son prácticamente el significado.
Piénsalo como hacer una mudanza: si empaquetas los tornillos de una estantería en una caja y las instrucciones en otra, el montaje se vuelve un juego de adivinanzas. Si los guardas juntos, el trabajo sale a la primera. En sistemas de RAG, esa “caja conjunta” es un chunk con cohesión lógica.
La gran zona ciega: diagramas, esquemas y “datos oscuros” visuales
Incluso con chunking semántico, muchos sistemas siguen fallando por una razón menos obvia: son ciegos. Una parte enorme del conocimiento corporativo está en diagramas, flujogramas, esquemas eléctricos, planos, capturas de pantallas, mapas de arquitectura. Si tu pipeline de indexado solo procesa texto, todo ese contenido se queda fuera. Es el equivalente a tener un manual con dibujos clave y taparlos con una hoja antes de leer.
En la práctica, esto significa que si la respuesta está en un diagrama de flujo (por ejemplo, la condición exacta para que un proceso cambie de estado), el sistema no lo encontrará. No porque no quiera, sino porque nunca lo metiste en el índice. Muchos embeddings puramente textuales —por ejemplo, modelos del estilo text-embedding-3-small— no “ven” imágenes; si el pipeline no las transforma, se saltan.
Textualización multimodal: convertir una imagen en algo buscable
Una solución que se está popularizando en equipos de ingeniería de datos es la textualización multimodal: antes de enviar nada a la base vectorial, conviertes los elementos visuales en descripciones textuales ricas y recuperables. El flujo suele tener dos pasos complementarios.
Primero, OCR (reconocimiento óptico de caracteres) para extraer etiquetas que estén dentro del gráfico: nombres de cajas, flechas, valores, leyendas. Segundo, un modelo con visión genera una explicación en lenguaje natural de lo que ocurre en la imagen. En el artículo de VentureBeat se menciona el uso de un modelo con capacidades visuales como GPT-4o para describir, por ejemplo, que un flujograma indica que “si la temperatura supera cierto umbral, el proceso A deriva al proceso B”. Esa descripción se guarda como texto asociado a la imagen, se embebe y entra en la base vectorial como cualquier otro fragmento.
El cambio es enorme: una consulta como “flujo del proceso con temperatura” ya no depende de que el diagrama tuviera exactamente esas palabras impresas; puede coincidir con la descripción generada. Es como poner subtítulos detallados a un vídeo para poder buscarlo.
La capa de confianza: respuestas con pruebas, no con fe
La precisión importa, pero en empresa hay otro factor igual de determinante: la verificabilidad. En una interfaz típica de RAG, el bot da una respuesta y cita un archivo. El usuario, si desconfía, tiene que abrir el PDF y jugar al “dónde está Wally” hasta encontrar el párrafo o la tabla original. En preguntas de riesgo —seguridad química, límites de operación, normativas— ese esfuerzo mata la adopción.
Si durante el preprocesado mantienes el vínculo entre cada chunk y su ubicación exacta (página, coordenadas, tabla, figura), puedes construir una UI con citaciones visuales: al lado de la respuesta aparece el recorte de la tabla o el diagrama del que sale el dato. No es un detalle estético; es un contrato de transparencia. En lugar de “créeme”, el sistema dice “míralo tú mismo”.
En la práctica, esto reduce discusiones internas y acelera decisiones. El ingeniero no tiene que debatir con un chatbot: valida con sus ojos. Y, de paso, el equipo de datos identifica más rápido qué partes del pipeline están fallando cuando algo no cuadra.
Lo que viene: embeddings multimodales nativos y contextos largos
La textualización multimodal es una solución pragmática porque da control: puedes ajustar el nivel de detalle de la descripción, imponer plantillas, guardar metadatos, decidir qué se indexa. Aun así, el mercado se mueve hacia embeddings multimodales nativos, capaces de mapear texto e imagen en el mismo espacio vectorial sin necesidad de “traducir” el gráfico a palabras. En ese terreno se citan propuestas como Cohere Embed 4, que apuntan a simplificar pipelines al ingerir directamente contenido visual y textual.
También está la evolución de los modelos hacia contextos cada vez más largos. La fantasía sería “meter el manual entero” en la ventana de contexto y olvidarse del troceado. Suena bien, pero en sistemas en tiempo real pesan la latencia y el coste. Hasta que las llamadas de cientos de miles o millones de tokens sean rutinarias y baratas, el preprocesado inteligente seguirá siendo la vía más realista para producción.
Un RAG para manuales se construye como un lector exigente, no como una trituradora
La diferencia entre una demo y un sistema útil en empresa rara vez está en “comprar un modelo más grande”. Suele estar en respetar la estructura de los PDF técnicos, conservar la integridad de tablas y secciones, rescatar el conocimiento que vive en diagramas y rematarlo con una experiencia que facilite la auditoría humana mediante citaciones visuales.
Visto así, diseñar un buen RAG se parece menos a entrenar un loro listo y más a crear un archivista meticuloso: alguien que no arranca páginas al azar, que entiende que un encabezado sin su valor es ruido, y que cuando afirma algo, te enseña el documento abierto por la línea correcta.