Mantenimiento inteligente de puentes grúa con IA: RAG y diagnóstico

¿Qué es lo que más preocupa cuando un puente grúa falla? No es la avería en sí, sino no encontrar a nadie que la repare. El técnico veterano que conocía el equipo de memoria se ha jubilado, el aprendiz nuevo hojea un manual de más de trescientas páginas sin dar con la sección correcta, y una alarma del variador de frecuencia puede tener al equipo de mantenimiento toda la mañana a vueltas. Es la queja más habitual que escuchamos en los servicios de reforma y mantenimiento.

Los grandes modelos de lenguaje (LLM) han avanzado enormemente en los últimos dos años. Combinados con los datos del Gemelo Digital del puente grúa, aportan un contexto mucho más rico para el diagnóstico de fallas. El salto del chat genérico a la aplicación vertical en la industria ya es un enfoque técnico consolidado. El mantenimiento de puentes grúa es precisamente un escenario idóneo para el despliegue de LLM: el conocimiento es relativamente cerrado (unos pocos manuales y guías de mantenimiento), los patrones de falla siguen una lógica recurrente (los códigos de alarma más comunes no superan las 100 categorías) y el riesgo de decisión es controlable (la IA propone, el técnico decide).

Este artículo describe el proyecto completo de ingeniería, desde el despliegue hasta la puesta en marcha: Ollama en local conectado a una base de conocimiento RAG, y el diagnóstico de fallas del puente grúa al alcance de una búsqueda. La inversión en hardware es de 30.000 a 80.000 EUR, un PC industrial puede dar servicio a 20-30 terminales de mantenimiento y la base de conocimiento, una vez creada, no caduca nunca.

Arquitectura del sistema en tres capas

El sistema asistente de mantenimiento con IA se estructura en tres capas independientes que se comunican entre sí mediante API estándar:

Detalles técnicos de implementación

El montaje del sistema completo se desarrolla en cuatro fases, cada una con una selección de herramientas y parámetros de configuración bien definidos.

2.1 Despliegue del modelo de lenguaje: Ollama + Qwen2.5

Ollama es, hoy por hoy, el framework más consolidado para ejecutar modelos de lenguaje en local. Compatible con Linux y Windows, permite instalar un modelo y acceder a su API con un solo comando. Se recomienda el modelo Qwen2.5 14B (14 000 millones de parámetros) de Alibaba, que ofrece una gran comprensión del chino y unos requisitos de hardware razonables: la versión cuantizada de 4 bits necesita únicamente 8 GB de memoria de vídeo para funcionar con fluidez.

Comando de despliegue:

# instalaciónOllama（SoporteGPUDetección automática） curl -fsSL https://ollama.com/install.sh | sh # ExtracciónQwen2.5 14B（Aproximadamente8.5GB） ollama pull qwen2.5:14b # Iniciar servicio（Por defecto127.0.0.1:11434） ollama serve

Verificación de que el servicio funciona correctamente:

curl http://localhost:11434/api/generate -d '{"model": "qwen2.5:14b","prompt": "Alarma del variador de frecuencia del puente grúaOCPosibles causas de falla por sobrecorriente？Enumere cinco causas","stream": false}'

2.2 Construcción de la base de conocimiento RAG

Confiar únicamente en el conocimiento del modelo no es suficiente: aunque Qwen2.5 conoce el concepto general de un puente grúa, no sabe cómo restablecer el PLC de su modelo concreto ni qué lote de repuestos se sustituyó el año pasado. RAG (generación aumentada por recuperación) resuelve precisamente este problema: se introducen los manuales de instrucciones, los registros de mantenimiento y los planos en una base de datos vectorial; ante cada consulta, el sistema recupera primero los documentos relevantes, los incorpora al prompt y, a continuación, el modelo genera la respuesta.

Flujo de construcción de la base de conocimiento:

Para la selección de una base de datos vectorial, se recomienda ChromaDB: implementada íntegramente en Python, no requiere despliegue independiente y admite modo en memoria, lo que la hace idónea para ejecutarse en un PC industrial. Como modelo de incrustación se recomienda BGE-small-zh-v1.5 de BAAI (384 dimensiones, solo 150 MB, inferencia de aproximadamente 50 ms por consulta en CPU), que ofrece buenos resultados en la recuperación semántica de chino y exige pocos recursos de hardware.

2.3 Flujo de generación aumentada por recuperación (RAG)

Un flujo completo de preguntas y respuestas es el siguiente:

from langchain_community.vectorstores import Chroma from langchain_community.embeddings import HuggingFaceEmbeddings import requests embeddings = HuggingFaceEmbeddings( model_name="BAAI/bge-small-zh-v1.5") db = Chroma(persist_directory="./crane_kb", embedding_function=embeddings) question = "Alarma del variador de frecuencia del puente grúaOUCómo manejar la falla por sobretensión？" docs = db.similarity_search(question, k=4) context = "\\\\n\\\\n".join([d.page_content for d in docs]) prompt = f"""Responda la pregunta del usuario basándose en el siguiente manual de mantenimiento del puente grúa。 Si el manual no lo contiene，Indicar"Contenido no encontrado en el manual"。 Contenido del manual： {context} Responda la pregunta del usuario basándose en el siguiente manual de mantenimiento del puente grúa：{question}""" resp = requests.post( "http://localhost:11434/api/generate", json={"model": "qwen2.5:14b", "prompt": prompt, "stream": False}) print(resp.json()["response"])

El núcleo de este flujo es el ensamblado del prompt. La eficacia del RAG no depende tanto del modelo de lenguaje (Qwen2.5 es suficiente), sino de si los documentos recuperados son realmente relevantes. Se recomienda, durante las pruebas, puntuar manualmente cada pregunta típica (tasa de acierto, precisión de la respuesta); si el resultado es inferior al 80 %, conviene ajustar la estrategia de segmentación o el modelo de incrustación.

Script de evaluación recomendado:

def evaluate_rag(test_qs, db, llm_url): results = [] for q, expected in test_qs: docs = db.similarity_search(q, k=4) hit = any(expected in d.page_content for d in docs) results.append({"q": q, "hit": hit}) rate = sum(1 for r in results if r["hit"]) / len(results) print(f"Retrieval hit rate: {rate:.1%}") return results

3. Escenarios de aplicación típicos

3.1 Diagnóstico asistido de fallos (el escenario más frecuente)

El técnico de mantenimiento introduce el síntoma de la avería en el móvil o la tableta, y la IA le ofrece las posibles causas y los pasos a seguir. Tomemos como ejemplo el fallo por sobrecorriente (OC) en un variador de frecuencia:

3.2 Guía de mantenimiento (con instrucciones paso a paso)

La IA no solo le indica qué ocurre, sino también qué tornillo debe aflojar primero. Cada tipo de operación de mantenimiento en la base de conocimiento se registra mediante pasos estandarizados:

El usuario pregunta：Cómo reemplazar el forro de freno del puente grúa？ AIRespuesta：A continuación se presentan los pasos de reemplazo—— 1. Cortar la energía y colocar etiqueta de bloqueo，Confirmar que el freno está en estado liberado 2. Retirar los pernos de fijación de la cubierta antipolvo（M8 x 4） 3. Comprimir el resorte de freno con herramienta especial 4. Extraer el pasador de posicionamiento del forro de fricción 5. Retirar el forro de fricción viejo（Prestar atención a la orientación (lado correcto/incorrecto)） 6. Instalar el forro de fricción nuevo（Verificar que el espesor sea uniforme） 7. Liberar el resorte，Restaurar la cubierta antipolvo 8. Ajustar la holgura de freno（valor característico0.5~1.0mm） 9. Energizar y probar el funcionamiento：Elevación en modo de impulso3veces，Confirmar que no haya ruido anormal

3.3 Análisis del historial de fallas y tendencias

La IA puede procesar los registros de fallas del último año e identificar los problemas más frecuentes. Al integrarse con la interfaz de datos de la plataforma de monitoreo remoto del puente grúa, cuando un técnico consulta una avería, la IA complementa automáticamente: "Este puente grúa ha registrado 4 fallas similares en los últimos 3 meses; se recomienda contactar al fabricante para una revisión sistemática".

Tabla de selección de tecnologías clave

5. Puntos Clave de la Implementación

1. La calidad de la base de conocimiento lo es todo. El modelo de lenguaje es solo el motor; quien realmente hace el trabajo es la base de conocimiento. Antes de empezar, dedique al menos una semana a recopilar toda la documentación del puente grúa: Manual de Operación, Esquema Eléctrico, comentarios del programa PLC e Historial de fallas. Si los registros de mantenimiento históricos no están en formato digital, asigne a una persona para transcribir las órdenes de reparación en papel a Markdown. La calidad de la base de conocimiento determina directamente la precisión de las respuestas de la IA; cualquier tiempo invertido en ello es tiempo bien empleado.

2. Los plantillas de Prompt requieren ajustes iterativos. Para una misma pregunta, la diferencia de calidad entre una respuesta sin instrucciones de sistema y una con un prompt bien diseñado es de dos niveles. Formato recomendado: el System Prompt del asistente de IA para puentes grúa debe incluir la definición del rol ("Eres un ingeniero de mantenimiento de puentes grúa con 15 años de experiencia") + las reglas de respuesta ("Indica primero la causa más probable, luego enumera los pasos de inspección, anotando el tiempo estimado para cada uno") + el aviso legal ("Esta es una recomendación asistida por IA; las operaciones finales de mantenimiento deben ser confirmadas por personal certificado").

3. La implementación local no es tan cara como se piensa. Muchos creen que un modelo de lenguaje grande requiere sí o sí una tarjeta gráfica A100, pero lo cierto es que Qwen2.5 7B cuantizado funciona fluidamente en una RTX 3060. Un PC industrial es más que suficiente para manejar la concurrencia de 20 a 30 terminales. Si los requisitos de confidencialidad de la planta no son muy estrictos, también se puede considerar una solución en la nube — Qwen a través de la API de Alibaba Cloud o la API de DeepSeek, con facturación por token. No obstante, para entornos industriales, recomiendo la implementación local: los datos no salen de la red, y la latencia se mantiene estable entre 1 y 3 segundos.

4. No espere que la IA reemplace a las personas. El rol del modelo de lenguaje en el mantenimiento de puentes grúa es el de una "herramienta de asistencia" — reducir el tiempo de búsqueda de información, ofrecer enfoques de diagnóstico y disminuir la dependencia de la experiencia. La manipulación real y la decisión final siempre recaen en el técnico de mantenimiento. Si esta función se comunica claramente en la fábrica, la aceptación será mucho mayor.

5. Empiece por escenarios sencillos; no pretenda abarcarlo todo desde el principio. Se recomienda que la primera fase se centre únicamente en dos funciones: "consulta de Código de alarma del Variador de Frecuencia" y "búsqueda inteligente en el Manual de Operación". Dedique 1 o 2 semanas a ponerlas en marcha, recopilar comentarios y optimizar la base de conocimiento. Para una visión más amplia del marco de Mantenimiento Predictivo en grúas, puede consultar nuestro artículo anterior sobre Mantenimiento Predictivo y sistema PHM para grúas. En la segunda fase, se ampliará al Diagnóstico de Fallas del Puente y del Carro. En la tercera fase, se añadirá el análisis de datos históricos. Implementar el sistema por fases, con resultados visibles en cada etapa, es la clave para que los usuarios lo adopten.

Conclusión

El modelo de lenguaje grande en el mantenimiento de puentes grúa no es un adorno: cuando un técnico saca el móvil en plena avería para fotografiar la alarma del variador de frecuencia y, 30 segundos después, la IA le devuelve la causa y los pasos a seguir, el valor de este sistema no necesita explicación. Hemos realizado una prueba piloto de tres meses en dos Talleres, y el tiempo medio de localización de averías se ha reducido de 40 a 15 minutos. En el caso de las fallas comunes del Variador de Frecuencia, la respuesta es prácticamente instantánea.

El nivel técnico requerido para todo el sistema no es alto: un PC industrial con tarjeta gráfica, un Ollama, una base vectorial y una base de conocimiento bien organizada. Lo que más tiempo lleva no es instalar el software, sino transferir la experiencia de mantenimiento de la cabeza de los técnicos veteranos a la base de conocimiento — pero eso es precisamente la parte más valiosa.

preguntas frecuentes