Planta de producción, dos de la madrugada. Un técnico experimentado busca en un manual de 3 400 páginas qué tipo y cantidad de lubricante prescribe el fabricante para un rodamiento a temperaturas superiores a 80 °C. El PDF tiene numeración de páginas inconsistente, la tabla con los valores está escaneada como imagen y la norma a la que remite el manual está en un archivo independiente. Tras 40 minutos encuentra lo que buscaba. La misma situación se repite decenas de veces por turno, en toda la planta.
Exactamente este problema resuelven los LLM sobre documentación industrial. No es un buzzword — es un caso de uso concreto y verificable donde un sistema correctamente desplegado ahorra horas medibles por operario y mes. Este artículo toma la decisión: qué funciona, dónde falla el enfoque ingenuo y qué debe resolver antes de empezar.
Qué quiere conseguir exactamente
Antes de hablar de arquitectura, aclare qué espera del sistema. En la práctica vemos tres casos de uso distintos que se parecen pero tienen requisitos diferentes:
1. Búsqueda y Q&A para técnicos — el técnico hace una pregunta en lenguaje natural y el sistema responde con referencia a una parte concreta del manual o la norma. No una transcripción del texto, sino una respuesta con cita: «Según la sección 7.3.2 del manual del equipo XY, el lubricante prescrito es ISO VG 220, aplicar cada 2 000 horas de operación».
2. Navegación por SOP y asistencia paso a paso — el operario trabaja según un procedimiento y necesita la explicación de un paso, una alternativa cuando una herramienta no está disponible, o una verificación rápida de que está haciendo lo correcto. El sistema debe ser determinista y preciso — una respuesta errónea en un procedimiento de producción tiene costes directos.
3. Conformidad normativa y soporte a auditorías — el ingeniero necesita identificar rápidamente qué partes de la documentación cubren los requisitos de una norma concreta (p. ej., ISO 9001, IEC 62443, ATEX), o detectar lagunas. Requiere comprensión tanto de la estructura de la norma como de la documentación interna.
Cada uno de estos casos de uso tiene requisitos distintos de precisión, latencia y forma de evaluación. Mezclarlos en un mismo piloto es un error habitual.
Por qué el RAG ingenuo no funciona sobre documentos industriales
RAG — siglas de retrieval-augmented generation — es la arquitectura básica: se dividen los documentos en fragmentos (chunks), se almacenan en una base de datos vectorial, al llegar una pregunta se recuperan las partes relevantes y se presentan al modelo. Sobre documentos comunes funciona bien. Sobre documentos industriales se topará con cuatro problemas que hay que resolver activamente.
Problema 1: El chunking ingenuo destruye las tablas
El manual de un equipo contiene una tabla con 30 filas y 8 columnas: tipo de equipo, temperatura de trabajo, tipo de lubricante, intervalo, cantidad, norma, nota, altitud. El chunking ingenuo por número de caracteres trocea esta tabla en 4 fragmentos. Cada fragmento pierde el contexto de las columnas que estaban en la página anterior.
Solución: un parser de documentos que reconozca las tablas y las conserve íntegras, o las convierta a formato estructurado (JSON, tabla Markdown). Herramientas como LlamaIndex tienen parsers especializados para estos casos. Los modelos multimodales (p. ej., Qwen2.5-VL) pueden extraer tablas incluso de PDF escaneados — algo habitual en manuales antiguos.
Problema 2: Los planos y esquemas son invisibles para el RAG solo de texto
Esquemas eléctricos, diagramas hidráulicos, P&ID (piping and instrumentation diagrams) — son partes clave de la documentación técnica que un pipeline solo de texto sencillamente omite. Si el técnico pregunta «¿dónde está ubicada la válvula V-12 en el esquema hidráulico de la línea L2», el RAG de texto responderá «la información no se encuentra en los documentos» o alucinará.
La solución depende de los recursos disponibles. La vía más sencilla: para los planos clave crear descripciones textuales estructuradas (una vez, manualmente o con ayuda de un VLM), que se indexan junto con el resto del texto. La vía más exigente: un pipeline multimodal completo donde el VLM genera la descripción de la imagen directamente durante la indexación — funciona, pero requiere un modelo computacionalmente costoso en cada adición de documento.
Problema 3: Versiones de normas y referencias cruzadas
La documentación industrial está llena de referencias: «proceda según ISO 14119:2013, anexo D» o «véase plano D-04-7812-rev3». El RAG ingenuo no resuelve estas referencias — carga el fragmento donde se menciona la norma, pero no tiene acceso al contenido de la propia norma si no está en el índice. Resultado: una respuesta que cita la referencia pero no contiene la información real.
Solución: gestión rigurosa de fuentes. Antes del despliegue hay que decidir explícitamente qué normas y qué versiones forman parte del índice, e instaurar un proceso de actualización ante revisiones. Esto es un problema organizativo tanto como técnico.
Problema 4: La context window no es ilimitada
Ni siquiera la ventana de contexto de 1 M de tokens de los modelos frontier es solución para un manual de 5 000 páginas. La atención del modelo se dispersa con entradas extremadamente largas — un fenómeno que la investigación confirma repetidamente. El RAG sigue siendo relevante incluso con modelos de contexto largo, porque carga selectivamente solo las partes relevantes en lugar del documento completo.
Cómo construir un pipeline fiable
Un pipeline experimentado para documentación industrial tiene varias capas sobre el RAG básico.
Preparación de documentos (ingestion)
Este es el paso más largo y el más infravalorado. Antes de indexar:
- Distinguir tipos de contenido: texto puro, tablas, imágenes, planos. Cada tipo merece un tratamiento diferente.
- Documentos escaneados mediante OCR — no el viejo
Tesseractpara documentos técnicos complejos, sino un VLM especializado o una API de document intelligence que entienda el contexto de la página (un número en la esquina superior derecha = número de página, el mismo número en una tabla = valor crítico). Más sobre esta capa en el artículo OCR e inteligencia documental para la industria. - Metadatos: para cada chunk guardar el documento fuente, número de página, sección, versión del documento, fecha de vigencia. Sin metadatos no son posibles las citas.
- Estructura jerárquica: capítulo → subcapítulo → tabla/procedimiento.
LlamaIndextiene soporte nativo para chunking jerárquico.
Retrieval — más que búsqueda vectorial
La búsqueda vectorial por sí sola tiene debilidades: captura partes semánticamente similares, pero puede pasar por alto una coincidencia exacta de palabra clave (número de pieza, código de alarma, identificador de equipo). El hybrid search — combinación de BM25 (palabras clave) y vectores — es más importante en contexto industrial que en el ámbito general. Consulte hybrid search con BM25 y vectores, donde se desarrolla con detalle.
Sobre la búsqueda híbrida añada un reranker — un modelo que ordena los resultados por relevancia con respecto a la pregunta. El BGE reranker (disponible libremente) o una API (p. ej., Cohere Rerank) mejora considerablemente la precisión en documentos largos con frases repetidas.
Generación con citas
Esta es la diferencia clave frente a un chatbot común: cada respuesta debe contener una referencia a la fuente concreta. El prompt debe exigir explícitamente: - Qué documento, sección, página. - Cita literal del valor crítico en lugar de paráfrasis. - Indicación explícita si la información no está disponible en los documentos proporcionados.
Este último punto es decisivo. La respuesta «no encuentro esta información en los manuales disponibles» es significativamente mejor que un valor alucinado con apariencia de certeza. Configurar el prompt de sistema para que el modelo exprese explícitamente la incertidumbre es más importante que la elección del modelo. Más sobre citas y grounding en RAG en el artículo citas y grounding en RAG.
Evaluación antes del despliegue
No exponga a los técnicos a un sistema que no ha probado con preguntas reales. Conjunto de evaluación básico:
- 50–100 preguntas de situaciones reales que los técnicos resuelven efectivamente
- Para cada pregunta, una respuesta verificada con referencia a la fuente (gold standard)
- Métricas: faithfulness (¿es la respuesta coherente con la fuente?), answer relevance (¿responde a la pregunta?), tasa de alucinaciones
Los sistemas en producción se fijan objetivos: faithfulness ≥ 95 %, tasa de alucinación ≤ 2 %. Un RAG correctamente implementado reduce las alucinaciones entre un 60 y un 71 % respecto a un LLM puro sin grounding — pero no las elimina por completo.
Elección del modelo: cloud vs. on-prem
Para los documentos industriales rige una lógica distinta a la de los despliegues públicos. La documentación técnica contiene a menudo know-how interno, parámetros de diseño y procedimientos de seguridad. Muchas empresas, especialmente en sectores regulados, no quieren que estos datos salgan de su infraestructura.
Los modelos open-weight on-prem son en 2026 una opción real:
- Familia
Qwen 2.5yQwen 3(licencia Apache 2.0, adecuada para despliegue comercial) — sólidos en document understanding incluidos sus variantes multimodales. Mistral Small(~22B) — buena relación rendimiento/requisitos de hardware.DeepSeek R1/V3(licencia MIT) — razonamiento fuerte, adecuado para preguntas complejas sobre normas y su interpretación.
Requisitos orientativos: para un modelo 7B basta una tarjeta con 12–14 GB de VRAM (inferencia QLoRA/quantized), para un modelo 22B se necesitan 24 GB o más GPU. Más sobre la elección de hardware en el artículo PC personalizado para LLM locales.
Para empresas sin datos sensibles o con una política clara de data governance, los modelos frontier (clase Claude Sonnet, GPT-4o) son significativamente mejores en razonamiento complejo sobre documentos estructurados — a costa de los gastos de API y del egreso de datos.
Requisitos organizativos que la tecnología no resolverá
En decenas de despliegues de sistemas RAG sobre documentación hemos comprobado que la parte técnica suele ser el problema menor frente a la organizativa.
Gestión de versiones de documentos. Si el manual existe en cinco versiones en distintos discos compartidos sin indicación clara de cuál es la actual, está indexando el caos. Antes de desplegar IA debe existir una single source of truth — una fuente autoritativa y única de la documentación vigente. Esto no es un problema de IA, sino de gestión documental.
Responsabilidad sobre la actualización del índice. ¿Quién y cuándo añade un nuevo manual? ¿Quién invalida la versión antigua de una norma? Sin un proceso definido, el sistema trabaja a los 6 meses con datos obsoletos y los técnicos dejan de confiar en él.
Expectativas adecuadas de los técnicos. Un sistema que no responde al 10 % de las preguntas y dice «no lo sé» es un sistema correctamente configurado. Si los técnicos esperan un 100 % de cobertura, el primer «no lo sé» se interpretará como un fallo. El onboarding es parte del proyecto.
Dónde falla el sistema — y qué hacer
Incluso un sistema bien construido tiene límites. Definir estos límites con honestidad antes del lanzamiento protege el proyecto de decepciones.
Seguridad en procedimientos: El sistema nunca debería ser la única fuente de verdad para un procedimiento de trabajo en tensión, trabajo en zona ATEX u otras operaciones críticas para la seguridad. RAG vs. fine-tuning para despliegues industriales analiza cuándo el fine-tuning es mejor que el RAG precisamente para estos casos — pero ni siquiera un modelo fine-tuned sustituye la formación certificada y la revisión por parte de la persona responsable.
Equipos nuevos sin documentación: Si el equipo no está en el índice, el sistema no responderá. Esto es una característica, no un error — peor sería que alucinara documentación inexistente.
Diagnóstico complejo: Preguntas como «por qué mi equipo vibra más de lo habitual» van más allá del Q&A documental. Aquí el lugar lo ocupa la analítica predictiva y los datos de sensores, no el RAG sobre manuales.
Preguntas frecuentes
¿Necesitamos fine-tuning o basta con RAG?
Para la mayoría de los casos de uso sobre documentación basta con RAG — no requiere preparación de dataset, entrenamiento ni riesgo de degradación del modelo. El fine-tuning aporta valor si quiere que el modelo entienda la terminología específica de su empresa o responda en un formato concreto. El marco de decisión está en el artículo RAG vs. fine-tuning.
¿Cómo garantizamos que el sistema no alucinará valores técnicos?
Combinación de tres medidas: (1) un prompt que prohíbe explícitamente responder fuera de las fuentes disponibles y exige cita, (2) un reranker que mejora la calidad del contexto recuperado, (3) un conjunto de evaluación con pruebas periódicas. Con una implementación rigurosa se alcanza una tasa de alucinación inferior al 2–3 % — nunca cero.
¿El sistema gestiona documentos en alemán, inglés y español?
Sí, los modelos de embedding modernos (p. ej., BGE-M3) son multilingües y funcionan bien entre idiomas. Las preguntas y las respuestas pueden estar en un idioma diferente al del documento fuente. En la práctica recomendamos indexar los documentos en su idioma original y dejar que el modelo traduzca en la respuesta — se preserva la precisión terminológica.
¿Cuánto lleva implementar un piloto?
Un sistema piloto para un tipo de documentación (p. ej., manuales de un equipo) con conjunto de evaluación e interfaz básica está en un rango de 4–8 semanas. La preparación de datos (OCR, limpieza, gestión de versiones) lleva más tiempo que la propia implementación técnica. Un sistema de producción completo con múltiples tipos de documentación e integración en sistemas existentes: 3–6 meses.
¿Funciona también para normas ISO y documentos regulatorios?
Sí, pero con una advertencia importante: las normas están sujetas a derechos de autor (ISO, EN, UNE). No se puede simplemente cargar una norma adquirida en un sistema interno — verifique las condiciones de licencia. En la práctica las empresas indexan los documentos internos que implementan la norma (especificaciones técnicas, listas de verificación) y hacen referencia a los números de requisito concretos en lugar de citar literalmente el texto normativo.
*Si está valorando cómo dar los primeros pasos con su documentación concreta — verificación del caso de uso, evaluación de los datos disponibles, diseño de la arquitectura — estamos disponibles para una consulta. MP Industrial Solutions implementa RAG sobre documentación industrial desde la preparación inicial de los datos hasta el despliegue en producción.*