YADRO prohíbe a su LLM tocar las cifras y publica más de 10 informes al día sin intervención humana

En YADRO, el equipo que gestiona el parque de equipos de TI construyó en tres meses un servicio que publica a diario más de una decena de informes analíticos para cinco departamentos. No hay personas en el proceso. La regla de ingeniería principal es esta: todos los números los calcula el código, y el modelo de lenguaje solo escribe comentarios de texto y no ve ningún indicador en bruto. El proyecto lo hicieron Egor Shliupikov, analista sénior de negocio, y su colega Egor Katáev, aunque nadie en el equipo GRID había llevado antes un desarrollo de nivel industrial.

Del experimento con una exportación a un servicio independiente

Todo empezó con una tarea de abril: evaluar las existencias de uno de los almacenes y proponer cómo dar salida a los equipos que llevaban tiempo parados. En aquel momento, la compañía seguía la métrica aged, es decir, la proporción de activos que llevan almacenados más de uno o dos años. Shliupikov tomó una exportación de Naumen.ITAM, eliminó los datos sensibles (personas jurídicas, nombres de almacenes) y pidió a una red neuronal que montara un informe en HTML. Salieron muchos cortes de datos; cada uno aislado aportaba poco, pero juntos respondían a una gran cantidad de preguntas. La dirección aprobó seguir desarrollando la idea dentro del perímetro de la compañía.

La primera versión funcionaba en la plataforma low-code Dify: se conectó el contexto de negocio como base de conocimiento y, por las limitaciones de contexto, se empezó a pasar al modelo no los datos en bruto, sino un resumen preparado por un script de Python. Pero incluso con el resumen el modelo se equivocaba. Trasladaba los números al texto siguiendo las reglas del prompt, y en los comentarios aparecían una y otra vez las mismas cifras fuera de lugar. Resultó que eran valores del corte de activos del día en que se conectó la base de conocimiento, no datos actuales.

Marcadores en lugar de números

De ahí surgió una separación estricta. El script prepara dos conjuntos de datos: uno completo, con el que se construyen los gráficos y la plantilla, y otro comprimido, con unas pocas decenas de números clave. El modelo solo ve el comprimido. Devuelve observaciones, interpretaciones y señales de alerta, y en lugar de cifras coloca marcadores. Los valores se insertan al ensamblar el informe, con las mismas reglas que se usan en la plantilla. Que el modelo distorsione un indicador es físicamente imposible.

En la economía de tokens también es una ventaja: al contexto llegan decenas de números, no arrays de filas. La llamada al modelo está aislada en un cliente aparte, de modo que se puede sustituir sin tocar el pipeline. El aspecto de los informes está separado en plantillas. Si el modelo no está disponible o responde de forma incorrecta, el informe sale a tiempo y con los números correctos, solo que sin conclusiones en texto.

Hubo que abandonar Dify por la separación de accesos, por el almacenamiento de los parámetros de conexión a la base en la configuración del pipeline y por la falta de programación de ejecuciones, estadísticas y notificaciones.

Trino como unión en el tiempo y entre sistemas

Cuando las fuentes se multiplicaron, toda la capa de datos pasó a una máquina virtual aparte con Trino. Los autores admiten que entonces era excesivo, pero lo hicieron para dejar margen de seguridad. Trino resuelve dos problemas.

• Unión en el tiempo. En Naumen.ITAM, el estado actual está en la réplica de la base de producción, mientras que el historial llega a ClickHouse en snapshots diarios. Una sola consulta federada toma el punto de hoy de la réplica, y el de ayer y todo el historial, de ClickHouse. Limitación: el paso del historial es de un día, de modo que no se ven los estados que cambian a lo largo de la jornada, y por eso la velocidad de los procesos se calcula con cautela.
• Unión entre sistemas. Naumen.ITAM sabe a qué equipo está asignado un servidor, y NetBox sabe en qué rack del centro de datos está. La consulta los cruza y muestra cómo se reparten entre los equipos los costes de cada rack.

Los generadores de informes no saben de dónde proceden los datos, así que conectar una fuente nueva no obliga a reescribir los informes. Las fuentes actuales son Naumen.ITAM, ClickHouse DWH, 1C, la plataforma BI/CPM (número de nuevos empleados y presupuesto), Jira (solicitudes de equipos) y NetBox.

Pipeline y protección frente a los propios errores

La cadena es esta: Airflow (abandonaron cron) lanza el DAG, los datos se leen a través de Trino, Python calcula los indicadores, Dify devuelve los comentarios, la plantilla renderiza el HTML, el informe se guarda con una marca de tiempo y se reasigna el enlace a la última versión. El acceso pasa por el Keycloak corporativo y una comprobación de permisos en validator; hay roles de propietarios, administradores, usuarios y superusuarios. Desde Mattermost se puede solicitar acceso, actualizar los informes y consultar estadísticas.

El código está en el GitLab corporativo, y los cambios solo se aceptan mediante merge request aprobado por alguien que no sea el autor. Cada actualización funciona un día en un entorno de pruebas aparte y, si no supera la aceptación, se revierte automáticamente.

Datos que no existían

La llegada del servicio dejó al descubierto vacíos en los datos. Nadie había calculado antes el valor operativo de las existencias de almacén, y el precio en Naumen.ITAM no está rellenado en todas las posiciones. La solución es la imputación por cohortes (tipo de equipo, modelo, fabricante, año de fabricación). El precio medio de las posiciones que tienen precio se extiende al resto. En el informe, el coste real y la estimación se muestran por separado. Si en una cohorte no hay ningún precio, se agrupa con otra más amplia o se deja sin estimación, con una nota. La conciliación con contabilidad dio cifras comparables.

Qué se puede aplicar en la práctica

El patrón se puede trasladar a cualquier tipo de informe: calcula un código determinista, y el modelo recibe agregados y devuelve texto con marcadores de posición. Es más barato en tokens, más sencillo de auditar y no rompe el informe si el modelo falla. El siguiente paso del equipo es un constructor de informes en el que el usuario describe un corte de datos con palabras, el modelo genera la descripción de las métricas y el SQL lo genera la capa semántica Cube a partir de medidas definidas de antemano. Tampoco aquí el modelo toca las consultas ni los números.