Cómo prevenir alucinaciones de IA en mantenimiento de grúas
📋 Resumen clave
En el mantenimiento de grúas, lo más peligroso de los grandes modelos de lenguaje no es que se equivoquen, sino que lo hagan con total seguridad: pueden inventar una cláusula de la norma que no existe, fabricar un procedimiento de mantenimiento aparentemente razonable o generar datos de detección sin origen verificable. Esto es lo que se conoce como «alucinación». Este artículo desglosa sus tres manifestaciones típicas, los métodos de interrogación y verificación para identificarla, y explica su causa raíz: el modelo genera texto por probabilidad, sin una restricción real sobre los hechos. La prevención se articula en cuatro capas: generación aumentada por recuperación, restricción de la base de conocimiento, límites de alcance y revisión manual. El principio es uno solo: la IA solo asiste; toda decisión que afecte a la seguridad debe ser confirmada por una persona.
La confianza que los técnicos veteranos de mantenimiento de grúas depositan en los grandes modelos de lenguaje es precisamente su mayor peligro. Cuanto más fluida y contundente es la respuesta del modelo, más probable es que esté inventando con total seriedad una cláusula de la norma que no existe. No duda, no dice «no estoy seguro»; solo ofrece una respuesta con formato impecable, tono seguro y completamente imposible de verificar.
Este fenómeno tiene un nombre específico: «alucinación». No se trata de un simple «error ocasional» del modelo, sino de una limitación estructural de los modelos generativos: lo que el modelo hace de principio a fin es predecir cuál es la palabra siguiente más probable, no comprobar si un hecho existe. Cuando se le pregunta «¿cómo se repara un ruido anormal en el reductor de una grúa?», es capaz de componer un proceso de mantenimiento que parece legítimo, pero el modelo no sabe si cada paso es realmente válido.
En el mantenimiento de grúas, el daño de la alucinación no está en «quedar mal», sino en «causar problemas». Una cláusula de la norma inexistente incorporada a una hoja de inspección, un procedimiento de mantenimiento inventado que un novato sigue al pie de la letra, o unos datos de detección ficticios utilizados para decidir una parada de equipo: cualquiera de estos escenarios puede derivar en un accidente de seguridad. Por eso la cuestión no es «¿usamos o no un gran modelo?», sino «¿cómo lo mantenemos dentro de los límites de los hechos?». Kelude Industrias Pesadas ha tropezado con este problema en varios proyectos de mantenimiento y ha incorporado la prevención de alucinaciones como primer paso en sus aplicaciones de IA.
Cómo se manifiesta la alucinación: invención de cláusulas, fabricación de pasos y datos falsos
La primera manifestación típica de la alucinación es la invención de cláusulas de la norma que no existen.
Cuando se pregunta al modelo «¿según qué norma?», puede ofrecer un número y un texto con formato perfectamente correcto, pero que en realidad no existen. Sabe cómo se estructura un número de norma y, siguiendo el patrón «GB/T número-año», inventa uno sobre la marcha, con un contenido que parece verosímil. Si el técnico de mantenimiento no consulta el texto original palabra por palabra, es fácil que se deje engañar.
La segunda manifestación típica es la fabricación de procedimientos de mantenimiento aparentemente razonables.
El modelo puede encadenar «desmontaje, detección, reemplazo y remontaje» en un proceso lógico, pero los parámetros clave intermedios pueden ser producto de su «imaginación»: por ejemplo, el par de apriete de un perno o el valor de ajuste de una holgura. Estas cifras no provienen de ningún manual, sino de la combinación estadística de frases similares en los datos de entrenamiento.
La tercera manifestación típica es la invención de datos de detección y conclusiones.
Cuando se pregunta «¿qué indican estos datos de vibración?», el modelo puede generar directamente un análisis con valores numéricos y gráficos, afirmando que «la amplitud supera el límite; se recomienda la parada». Estos valores no guardan ninguna relación con los datos originales, pero resultan creíbles por su formato impecable. Esta es la forma más peligrosa de alucinación, porque conduce directamente a decisiones de mantenimiento erróneas.
Procedimiento de diagnóstico para identificar alucinaciones: verificación de fuentes, contraste y validación de valores
Identificar alucinaciones no requiere métodos esotéricos, sino una serie de comprobaciones repetibles. Kelude Industrias Pesadas ha consolidado una lista de verificación cruzada en su base de conocimiento interna; el personal de primera línea solo tiene que seguirla punto por punto. El núcleo son tres acciones.
El primer paso es la verificación de fuentes.
Cada número de norma, cada parámetro y cada conclusión que ofrezca el modelo debe ir acompañado de la pregunta «¿cuál es la fuente?». Solo se acepta lo que pueda vincularse a una entrada concreta de la base de conocimiento; lo que no tenga fuente, o la tenga ambigua, se marca directamente como sospechoso.
El segundo paso es el contraste cruzado.
Se comparan las respuestas del modelo, punto por punto, con el manual de mantenimiento, el registro de equipos y las órdenes de trabajo históricas. Si los parámetros no coinciden, si el modelo del equipo no es el correcto o si los procedimientos de operación no se ajustan a la realidad, es señal de que el modelo está «imaginando». Este paso permite frenar la gran mayoría de las alucinaciones por confusión de elementos.
El tercer paso es la validación de la coherencia de los valores.
Ante un valor numérico proporcionado por el modelo, la primera pregunta debe ser «¿es razonable este número?». Un valor de par que contradice claramente el sentido común, o una carga que supera el rango nominal del equipo, deben rechazarse de inmediato, aunque el formato sea impecable. La validación de coherencia no busca precisión, sino filtrar primero los errores más evidentes.
Tabla comparativa: identificación y tratamiento de alucinaciones
| manifestación de alucinación | Identificaciónseñal | Detecciónmedio | conclusión de evaluación | acción de tratamiento |
|---|---|---|---|---|
| fabricacióncláusulas de la norma | Normanúmero sin registro | consulta en base de datos original | sin fuente verificable, se determina como alucinación | anotacióndeshabilitar y retroalimentar |
| invenciónMantenimientopaso | Parámetroprecisión excesiva | verificación cruzada con manual | Parámetrodiscrepancia se determina como alucinación | revertir al manualNormapaso |
| ficticioDeteccióndato | valor sin fuente | comparación con datos originales | sin trazabilidad se determina como alucinación | prevalecen los datos originales |
| asignación errónea de equipo | Modelomecanismoconfusión | verificación con registro de equipos | Modeloinconsistencia se determina como alucinación | corregir y reformular |
| conclusión sobreconfiada | expresión sin reservas | requisitosproporcionar fundamento | sin fundamento se determina como alucinación | transferirrevisión manualconfirmación |
| error de vigencia | referencia a norma derogadaNorma | verificación con versión vigente | Normaderogado se determina como alucinación | actualizar entrada de base de conocimiento |
Por qué los grandes modelos alucinan: la raíz de la generación probabilística y la ausencia de restricciones fácticas
Para prevenir las alucinaciones, primero hay que entender por qué ocurren. La salida de un gran modelo es, en esencia, generación probabilística: cada token que produce se muestrea de la «distribución más probable del siguiente token» calculada a partir de todos los anteriores. El modelo no dispone de una base de datos fáctica independiente contra la que contrastar, ni comprende la semántica de «correcto» o «incorrecto»; solo entiende que, en ese contexto, «lo más natural es continuar así».
Esto explica por qué las alucinaciones suelen presentarse con «gramática impecable, coherencia lógica y contenido erróneo»: la fluidez es el objetivo con el que se entrena al modelo, pero los hechos no lo son. Cuando cierto tipo de contenido aparece con suficiente frecuencia en el corpus de entrenamiento, el modelo aprende su formato; sin embargo, cuando se le pide generar una respuesta concreta, única y verificable, que el formato sea correcto no implica que el contenido lo sea.
La segunda causa raíz es la ausencia de restricciones fácticas sólidas.
Un manual de mantenimiento real vincula cada paso a componentes y parámetros que existen físicamente; la memoria del modelo, en cambio, es una condensación estadística de los datos de entrenamiento. Puede fusionar información de distintos equipos y condiciones de operación, generando un híbrido que no existe en la realidad. Esta «confusión de atribuciones» es, en esencia, un fallo de recuperación, no un engaño deliberado por parte del modelo.
La tercera causa raíz es la caducidad del conocimiento.
Una vez completado el entrenamiento, el conocimiento del modelo queda congelado. Las normas se revisan y los procedimientos se actualizan, pero el modelo no lo sabe automáticamente. Cuando se le pregunta por una norma nueva, puede responder recurriendo a recuerdos de la versión anterior, o incluso ensamblar fragmentos de memoria hasta componer una «norma nueva» que jamás ha existido.
Sistema de prevención de alucinaciones: generación aumentada por recuperación, restricción del conocimiento y límites de actuación
La primera capa de prevención es la generación aumentada por recuperación, conocida como RAG.
En lugar de que el modelo «recuerde» de la nada, es preferible que primero consulte. El enfoque de la generación aumentada por recuperación consiste en: antes de generar la respuesta, recuperar de la base de conocimiento de la empresa los pasajes relevantes —textos normativos, manuales de mantenimiento, historiales de órdenes de trabajo— y alimentar al modelo con esos pasajes junto con la pregunta, exigiéndole que «responda únicamente con base en el material proporcionado». De este modo, la respuesta queda anclada a hechos verificables y el margen de invención del modelo se reduce drásticamente.
La experiencia práctica de Kelude Industrias Pesadas es que la eficacia de RAG depende de la calidad de la base de conocimiento. Las cláusulas de la norma y los parámetros contenidos en ella deben ser autoritativos, vigentes y trazables. La norma GB/T 28264 — Sistema de Monitoreo y Gestión de Seguridad para aparatos de elevación establece requisitos normativos para la recopilación y el almacenamiento de los datos de monitoreo, y constituye la base fundamental de la capa de datos de la base de conocimiento; por su parte, el reglamento TSG 51-2023 — Reglamento de supervisión técnica de seguridad para aparatos de elevación es la fuente autoritativa de la base de conocimiento de mantenimiento. Cada referencia a una norma debe poder localizarse en su texto original dentro de la base; de lo contrario, se tratará como una alucinación.
La segunda capa es la restricción del conocimiento.
El enfoque es directo: solo se permite al modelo citar entradas que existan realmente en la base de conocimiento, quedando prohibido que «improvisé sobre la marcha». Cada número de norma y cada parámetro que aparezca en la respuesta debe poder enlazarse de vuelta a una entrada concreta de la base. Esta restricción no basta con incluirla en el prompt; debe aplicarse también una verificación estricta a nivel de sistema: los números de norma presentes en la salida del modelo se comparan automáticamente contra la base y, si no se encuentran, se bloquean y se marcan.
La tercera capa son los límites de actuación.
Esta es la regla más importante: el gran modelo no participa en las decisiones de seguridad. Puede resumir documentación, redactar borradores de informes y explicar cláusulas, pero las determinaciones relativas a detener o no una máquina, sustituir o no un componente, o autorizar o no la continuación de la operación deben tomarlas siempre personas. Limitar el papel de la IA al de «asistencia» y no al de «decisión» es la medida más eficaz para contener el riesgo de alucinaciones desde el plano institucional.
La cuarta capa es la revisión manual.
Todo contenido generado por el modelo que vaya a utilizarse en la operación práctica debe ser revisado por personal cualificado. El objetivo de la revisión no es «comprobar si se lee con fluidez», sino verificar que «cada número de norma pueda localizarse, cada parámetro coincida con el manual y cada conclusión cuente con respaldo de datos originales». La experiencia de Kelude Industrias Pesadas demuestra que integrar la revisión como un procedimiento fijo es mucho más fiable que depender de la responsabilidad individual.
Referencia rápida de cláusulas normativas para la base de conocimiento anti-alucinaciones
| Norma/Procedimiento | puntos clave de cláusula | función contra alucinaciones |
|---|---|---|
| GB/T 28264 — Sistema de Monitoreo y Gestión de Seguridad《aparatos de elevaciónsistema de monitoreo y gestión de seguridad》 | Monitoreoadquisición de datosy almacenamientorequisitos | datos de base de conocimientobaseproporcionar fundamento |
| reglamento TSG 51 — Reglamento técnico de seguridad de equipos especiales-2023《aparatos de elevaciónreglamento de supervisión técnica de seguridad》 | Inspecciónyrequisitos técnicos de seguridad | Mantenimientofuente autorizada de base de conocimiento |
| norma FEM 1.001《especificación de diseño de grúa》 | cálculo de diseñodisposición básica | Parámetroreferencia autorizada de verificación |
| ISO 24621:2022《grúadiagnóstico de fallos por IA》 | AIDiagnósticorequieretrazableverificable | restricciónAIconclusión debe ser rastreable |
| ISO 4310《especificación de ensayo de grúay procedimiento》 | Ensayoproyecto yAceptacióndeterminación | razonabilidad de valoresverificaciónproporcionar fundamento |
📖 Lecturas relacionadas: ¿Qué aplicaciones reales tiene un gran modelo en el mantenimiento de grúas? Escenarios prácticos y límites de capacidad | Gestión de la salud de los equipos PHM: práctica de ingeniería de mantenimiento predictivo de puentes grúa con macrodatos y ML
Preguntas frecuentes
P: ¿Es mejor la generación aumentada por recuperación (RAG) o el ajuste fino para evitar alucinaciones? ¿Cuál es la diferencia esencial?
R: La RAG consulta una base de conocimiento antes de generar la respuesta, utilizando las entradas relevantes como punto de anclaje fáctico para el modelo, lo que permite rastrear el origen de cada afirmación. El ajuste fino, en cambio, modifica los parámetros del modelo con datos del dominio para que "entienda mejor" el campo, pero no elimina la naturaleza probabilística de la generación. No son excluyentes: primero se usa RAG para garantizar que las citas tengan respaldo y, si es necesario, se aplica ajuste fino para mejorar la expresión del dominio. En escenarios de mantenimiento de grúas donde la seguridad es crítica, la restricción estricta de RAG tiene prioridad, porque cada cita puede verificarse contra el texto original. Kelude también utiliza RAG como primera línea de defensa en sus implementaciones.
P: El modelo cita una norma que no se puede encontrar. ¿Es una alucinación o es que la base de conocimiento no está actualizada? ¿Cómo se investiga?
R: Primero se investiga por dos vías. La primera es comprobar si la base de conocimiento incluye la versión más reciente de esa norma; si no está, probablemente sea una carencia de la base y no una invención del modelo. La segunda es pedir al modelo que muestre el fragmento original y el enlace de la fuente de esa norma; si no puede hacerlo, o si los pasajes que ofrece son contradictorios, se puede concluir que es una alucinación. Como medida, se marca como no fiable, se reincorpora a la base de conocimiento y se retroalimenta al modelo para evitar que se repita.
P: ¿Con qué frecuencia aparecen alucinaciones en el mantenimiento de grúas y en qué escenarios hay que tener más cuidado?
R: Las alucinaciones no son un hecho aislado, sino una limitación inherente a los modelos generativos. Su frecuencia depende del grado de apertura de la pregunta y de la rigidez de las restricciones de la base de conocimiento. Los tres escenarios que requieren mayor atención son: cuando se pide citar cláusulas de la norma, cuando se pide generar pasos de mantenimiento y cuando se pide interpretar datos de detección y dar conclusiones. Siempre que se trate de decisiones de parada, reemplazo de componentes o límites de seguridad, la respuesta del modelo no debe aceptarse directamente; hay que rastrear cada afirmación y someterla a revisión manual.
