Cómo consultar datos de monitoreo de infraestructura con lenguaje natural

El lenguaje natural puede funcionar como interfaz para el monitoreo de infraestructura y los datos de operaciones. El sistema convierte la pregunta de un operador en consultas estructuradas sobre series temporales, consumo, inventario, alarmas y datos de relaciones, y luego devuelve el resultado en un formato legible junto con el origen de los datos, qué métrica se utilizó, qué rango temporal se analizó y cómo se calculó el resultado.

El operador formula la pregunta operativa directamente en lugar de tener que averiguar primero qué panel, métrica, filtro o informe debe abrir. El sistema de monitoreo sigue proporcionando la información; el lenguaje natural solo cambia la forma en que el usuario llega a ella.

¿Qué hace exactamente una consulta de operaciones en lenguaje natural?

Traduce la petición de un operador en una o más solicitudes legibles por máquina contra los datos operativos. El diseño original del asistente de operaciones ofrece un ejemplo concreto: "¿Qué nodos superaron el 90% de utilización en las últimas 24 horas y qué tareas se estaban ejecutando en ellos?".

Esa sola frase contiene varios elementos de intención de consulta. El usuario busca nodos, la métrica es la utilización, el umbral es el 90%, la ventana temporal son las últimas 24 horas y la respuesta también necesita las relaciones de tareas o cargas de trabajo. Un asistente útil debe extraer esos elementos, consultar los datos de monitoreo y consumo, cruzar las relaciones correspondientes y devolver un resultado estructurado. La plataforma de monitoreo permanece en su sitio; la capa de lenguaje natural convierte una duda de operaciones en una petición de monitoreo para ella.

¿Qué tipos de datos de infraestructura se pueden consultar de este modo?

El diseño de referencia permite el acceso en lenguaje natural a conocimientos de monitoreo, consumo, configuración, alarmas y operaciones, lo que abre varios tipos de consultas:

• Estado de recursos: ¿qué nodos presentan fallos?, ¿qué tarjetas aceleradoras están degradadas?, ¿qué racks están cerca de su límite de potencia?
• Utilización: ¿qué nodos superaron un nivel de uso determinado?, ¿qué recursos aceleradores han permanecido inactivos durante un período concreto?, ¿qué proyectos consumen más cómputo?
• Operaciones: ¿qué alarmas siguen abiertas?, ¿qué órdenes de trabajo se relacionan con este equipo?, ¿qué ocurrió durante el incidente anterior en este servidor?
• Capacidad: ¿cuándo alcanzará el grupo actual de recursos un umbral de asignación determinado?, ¿en qué puntos la fragmentación de recursos impide iniciar tareas?
• Conocimiento: ¿qué función cumple este componente de arquitectura?, ¿qué runbook se aplica a este tipo de incidente?

Lo que hace que valga la pena implementarlo es que todos estos tipos diferentes de datos operativos se encuentran detrás de un único punto de entrada conversacional.

¿Por qué es mejor que pedir a los usuarios que conozcan los nombres de las métricas?

Los operadores suelen pensar en términos de dudas operativas, no en identificadores internos de métricas. Un ingeniero de guardia puede saber que una carga de trabajo va lenta sin conocer el nombre exacto de la métrica de rendimiento de almacenamiento. Un responsable puede querer saber cuándo escaseará la capacidad sin saber qué tabla de asignación de recursos impulsa la previsión.

Una capa de lenguaje natural puede traducir esas preguntas en las consultas operativas correctas, de modo que no todos los usuarios tengan que memorizar nombres de métricas, ubicaciones de paneles, sintaxis de filtros, identificadores de objetos ni definiciones de informes.

El diseño original considera al asistente como el lugar para preguntar, mientras que el centro de mando de operaciones sigue siendo el lugar para mirar. Ambas interfaces utilizan los mismos datos subyacentes.

¿Cómo debe traducir el asistente una pregunta en solicitudes de datos?

La traducción debe identificar el objeto, la métrica, la condición, el rango temporal, la agrupación y la relación que el usuario solicitó. Tomemos esta pregunta: "¿Qué nodos GPU tuvieron una utilización superior al 90% ayer y qué proyectos los estaban utilizando?".

El asistente necesita resolver:

• Objeto: nodos GPU
• Métrica: utilización
• Condición: superior al 90%
• Tiempo: ayer
• Relación: del nodo a la tarea o carga de trabajo, y luego de la carga de trabajo al proyecto
• Salida: nodos que cumplen el criterio y el contexto de su proyecto

Una pregunta diferente, como "¿Qué servicios podrían pasar de una asignación de tarjeta completa a recursos compartidos?", requiere una ruta de datos distinta. Aquí el asistente necesita el historial de asignación de recursos, el comportamiento de utilización, la especificación del recurso y la política utilizada para detectar posible fragmentación o sobreasignación. El modelo de referencia incluye explícitamente la identificación de fragmentación y las recomendaciones de optimización como capacidades del asistente.

Sea cual sea la pregunta, la conversión debe ser lo bastante precisa para que la respuesta final coincida con lo que el usuario realmente quiso decir.

¿Por qué importan los datos de relaciones de la CMDB?

Las consultas operativas en lenguaje natural suelen necesitar tanto relaciones como métricas. Una base de datos de monitoreo puede indicarte que el Nodo A tuvo una utilización elevada, pero el usuario también puede preguntar qué carga de trabajo se estaba ejecutando, qué proyecto es su propietario o qué servicio de negocio depende de ella. Esas respuestas provienen de los datos de relaciones.

La plataforma de referencia conecta tareas con contenedores, contenedores con GPUs, GPUs con nodos físicos, nodos con red y almacenamiento, y servicios con proyectos y propietarios. Eso permite que una sola pregunta en lenguaje natural recorra varias capas operativas.

Para conocer el modelo de relaciones en detalle, cómo una CMDB puede conectar servidores, GPUs, contenedores, aplicaciones, servicios de negocio y propietarios explica cómo esos vínculos respaldan las operaciones.

¿Cómo deben gestionarse los rangos de tiempo?

El asistente debe resolver el período solicitado de forma explícita y utilizar el mismo período en todas las fuentes de datos relacionadas. El período puede ser los últimos 15 minutos, las últimas 24 horas, ayer, esta semana o el intervalo del Incidente 1842. Si el usuario pregunta por la utilización y la asignación de cargas de trabajo dentro de la misma ventana de 24 horas, ambos conjuntos de datos deben evaluarse bajo el mismo criterio.

El diseño del asistente también da mucha importancia a definir el criterio estadístico, porque "utilización por encima del 90%" puede significar varias cosas. La utilización máxima puede haber superado el 90%, la utilización media puede haberse mantenido por encima del 90% o un percentil 95 puede haber superado el 90%. La respuesta debe indicar qué interpretación utilizó, y el significado estadístico nunca debe quedar oculto tras el lenguaje natural.

¿Qué atribución de fuentes debe mostrarse?

Toda respuesta operativa debe mostrar su origen con la claridad suficiente para poder verificarla. El diseño de referencia exige expresamente la atribución de fuentes de datos, nombres de métricas, definiciones estadísticas, alcance del escaneo y granularidad de los datos. Una respuesta útil podría indicar:

• Fuente de datos: telemetría de utilización de nodos
• Métrica: utilización de aceleradores
• Rango temporal: últimas 24 horas
• Agregación: promedio de cinco minutos
• Alcance del escaneo: 62 nodos en línea
• Fuente de relaciones: vinculaciones de tareas y proyectos

La presentación puede ser compacta. Lo relevante es que el operador pueda comprender cómo se obtuvo la respuesta, algo crítico en previsiones y recomendaciones. Si un asistente indica que la capacidad alcanzará un umbral crítico en 23 días, el usuario debe poder revisar los datos y las suposiciones detrás de esa estimación.

¿Cómo puede utilizarse el lenguaje natural para resolver incidentes?

El asistente puede combinar datos operativos en tiempo real con conocimiento operativo histórico. La base de conocimiento de referencia incluye órdenes de trabajo, eventos de alarma, documentos de arquitectura y runbooks de emergencia, que se ingieren y vectorizan de forma conjunta.

De este modo, un usuario puede preguntar: "¿Por qué este nodo presenta anomalías y hemos visto esto antes?". El asistente utiliza los datos de monitoreo activos para la condición actual y recupera órdenes de trabajo previas de incidentes parecidos. A continuación, puede mostrar la alarma actual, una causa probable o ruta de investigación, el incidente histórico, el runbook pertinente y una siguiente comprobación recomendada.

Para una visión más amplia sobre el diseño de este tipo de asistentes, cómo los asistentes de IA utilizan alarmas, órdenes de trabajo, runbooks y documentos de infraestructura explica cómo se integran las consultas en vivo con la recuperación de conocimiento.

¿Cómo puede respaldar el lenguaje natural la previsión de capacidad?

El asistente incluye previsión de capacidad y avisos de riesgo de vencimiento. Un usuario puede preguntar: "¿Cuándo alcanzará este grupo de recursos el 90% de asignación?". El asistente recupera la tendencia histórica de asignación y aplica la lógica de pronóstico de la plataforma.

El resultado debe mantenerse trazable, mostrando la asignación actual, la ventana de tendencia, el umbral, la fecha o intervalo proyectado y la fuente de datos.

La misma interfaz puede responder preguntas sobre fragmentación. Ante la duda "¿Por qué hay tareas en espera si hay GPUs libres?", el asistente puede revisar el formato de recurso solicitado, los dispositivos disponibles, la topología y el estado de planificación, para luego explicar si la causa radica en una cuota, fragmentación, exclusión por estado de salud u otra condición conocida.

¿Cómo puede el lenguaje natural consultar el consumo del negocio?

El mismo enfoque sirve para los datos de facturación interna y métricas de consumo, con preguntas como estas:

• ¿Qué proyecto consumió más horas de tarjetas aceleradoras este mes?
• ¿Qué modelo generó la mayor cantidad de Tokens hoy?
• ¿Qué tenant tiene la mayor asignación ociosa?
• ¿Qué tipo de acelerador presenta el mayor coste unitario?

La plataforma de referencia reparte el consumo entre proyecto, tenant, modelo y tipo de acelerador, lo que proporciona al asistente dimensiones estables sobre las que consultar. Un usuario no necesita abrir primero el panel de costes; puede formular la pregunta y obtener el resultado agrupado. Ese resultado debe seguir utilizando las mismas definiciones que el panel oficial de consumo, ya que el lenguaje natural no debe crear una segunda versión de los números.

¿Cómo debe gestionar el asistente las preguntas ambiguas?

Cuando el modelo operativo aporta contexto suficiente, el asistente debe resolver la ambigüedad a partir de él y hacer visible la interpretación elegida.

Tomemos como ejemplo: "Muéstrame los nodos sobrecargados". La plataforma necesita una definición de sobrecarga. Si la política de operaciones la define como una utilización continuada por encima de un umbral específico, el asistente puede aplicar esa regla y detallarlo. La documentación de origen no fija un umbral universal, de modo que si no existe una definición, el asistente no debe inventar ninguna. Puede pedir un umbral o presentar los datos de utilización disponibles sin etiquetar nada como sobrecargado.

Lo mismo aplica para términos como "costoso", "con problemas" o "alto riesgo". El lenguaje operativo debe corresponderse con reglas definidas en la plataforma cuando estas existan.

¿Qué debe ocurrir cuando los datos solicitados no están disponibles?

El asistente debe indicar claramente que no puede obtener los datos solicitados. El diseño del asistente establece esto como una regla estricta: los datos ausentes no deben rellenarse con una respuesta verosímil inventada.

Una consulta puede fallar por varios motivos. Es posible que la métrica no se recolecte, que el rango temporal solicitado quede fuera del período de retención, que el usuario carezca de permisos, que falte la relación o que la fuente de datos esté caída. El asistente debe distinguir estos casos cuando la plataforma pueda identificarlos. Una respuesta explícita de "datos no disponibles" es operativamente más segura que una estimación confiada sin pruebas que la respalden.

¿Cómo deben aplicarse los permisos a las consultas en lenguaje natural?

El acceso mediante lenguaje natural debe respetar los mismos controles de organización, rol, tenant, proyecto y mínimo privilegio que el resto de la plataforma. El diseño de gobierno de referencia incluye una jerarquía de departamentos y equipos, una matriz de permisos por roles, pertenencia a tenants, pertenencia a proyectos, mínimo privilegio y autorización independiente para operaciones sensibles.

El asistente debe heredar todos esos controles. Un usuario que no pueda abrir los datos de monitoreo del Proyecto B a través de la interfaz habitual tampoco debe poder obtenerlos mediante una pregunta conversacional. La capa de lenguaje natural es una interfaz más hacia los mismos datos operativos y no debe convertirse en un atajo para eludir permisos.

¿Puede una consulta en lenguaje natural desencadenar un cambio?

El diseño de referencia mantiene un límite de ejecución claro. El asistente puede analizar y recomendar, pero las acciones de cambio siguen requiriendo la aprobación de un flujo de trabajo antes de ejecutarse.

Un usuario puede preguntar: "¿Qué nodos degradados deberían retirarse del grupo?", y el asistente puede devolver los candidatos junto con las evidencias. Si el usuario desea realizar el cambio a continuación, la acción entra en el proceso habitual de autorización.

Para revisar el modelo de gobierno, cómo las empresas automatizan las operaciones del centro de datos manteniendo aprobaciones, permisos, rollback y controles de auditoría explica cómo la recomendación y la ejecución se mantienen conectadas sin perder el control.

¿Qué hace fiable a una interfaz de operaciones en lenguaje natural?

Hay tres factores determinantes: la respuesta debe provenir de datos operativos reales, la ruta de razonamiento debe ser visible para poder verificarla y el asistente debe mantenerse dentro de sus permisos y límites de ejecución.

Un ejemplo de plataforma que utiliza conversión de consultas de lenguaje natural a monitoreo con atribución de origen es Sensaka.

Si tuviera que evaluar esta capacidad, probaría preguntas que requieran varias fuentes de datos al mismo tiempo. Preguntaría qué nodos superaron un umbral de utilización, qué cargas de trabajo se ejecutaban, qué proyectos eran sus propietarios y si existían incidentes relacionados. Si el asistente devuelve el resultado correcto con las fuentes de datos y el alcance temporal explícitos, la consulta en lenguaje natural está haciendo mucho más que parafrasear paneles.