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 TRAPO 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. Estafa PDF técnicosese 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 el medio, el sistema guarda por un lado el encabezado y por otro el valor. En la búsqueda vectorialel 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.
fragmentación semántica: recortar siguiendo la lógica del manual
La práctica alternativa es abandonar el recorte por longitud y pasar a un fragmentación semántica. La idea es simple: en lugar de cortar por metrónomo, cortas por estructura, como haría un lector humano. Aquí ingresa al juego herramientas de análisis de maquetación y estructura, tipo. Inteligencia de documentos de Azure 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 “trozo” 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 un estante 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 TRAPOesa “caja conjunta” es un trozo con cohesión lógica.
La gran zona ciega: diagramas, esquemas y “datos oscuros” visuales
Incluso con fragmentación semánticamuchos sistemas siguen fallando por una razón menos obvia: son ciegos. Una parte enorme del conocimiento corporativo está en diagramasflujogramas, esquemas eléctricos, planos, capturas de pantallas, mapas de arquitectura. Si tu tubería de indexado solo procesa texto, todo ese contenido 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. Muchas incrustaciones puramente textuales —por ejemplo, modelos del estilo incrustación-de-texto-3-pequeño— no hay imágenes “ven”; si el oleoducto 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, LOC (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 TRAPOel 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 fragmento 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 “creeme”, el sistema dice “míralo tú mismo”.
En la práctica, esto reduce las discusiones internas y acelera las 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 ducto están fallando cuando algo no cuadra.
Lo que viene: incrustaciones 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 incrustaciones 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 Insertar 4que 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 millas 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 demostración 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écnicospreservar 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ña un buen TRAPO se parece menos a entrenar un loro listo y más a crear un archivero 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.
