Informes de incidencias a partir de registros con LLM: agrupar antes de leer y separar hechos de hipótesis

Durante una caída de 40 minutos, un servicio puede escribir millones de líneas de registro, casi todas repeticiones de unos pocos mensajes con distintos identificadores y marcas de tiempo. Pasar esas líneas tal cual a un modelo es imposible por tamaño y, aunque cupieran, el modelo vería sobre todo ruido. El trabajo útil se hace antes: reducir los registros a patrones con conteos y a una línea temporal construida en código. Con eso, un LLM redacta en minutos un borrador de informe de incidencia que a una persona le llevaría horas.

Paso 1: de líneas a patrones

La mayoría de las líneas de registro son plantillas con variables: «Timeout al conectar con db-3 tras 5000 ms», «Timeout al conectar con db-1 tras 5012 ms». Sustituir las partes variables por marcadores convierte millones de líneas en decenas de patrones con su número de apariciones:

import re
from collections import Counter, defaultdict

VARIABLES = [
    (re.compile(r"\b[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}\b"), "<UUID>"),
    (re.compile(r"\b\d{1,3}(?:\.\d{1,3}){3}\b"), "<IP>"),
    (re.compile(r"\b[\w-]+-\d+\b"), "<HOST>"),
    (re.compile(r"\b\d+(?:\.\d+)?\b"), "<NUM>"),
]

def plantilla(mensaje):
    for patron, marcador in VARIABLES:
  mensaje = patron.sub(marcador, mensaje)
    return mensaje

def resumir(lineas):
    """lineas: lista de (timestamp, nivel, mensaje)"""
    conteo, primera, ultima = Counter(), {}, {}
    for ts, nivel, msg in lineas:
  clave = (nivel, plantilla(msg))
  conteo[clave] += 1
  primera.setdefault(clave, ts)
  ultima[clave] = ts
    return [(n, c, primera[c], ultima[c]) for c, n in conteo.most_common()]

Para registros con formatos variados, algoritmos de agrupación de logs como Drain (con implementaciones en bibliotecas como drain3) descubren las plantillas automáticamente. El resultado, una tabla de patrones con nivel, número de apariciones, primera y última vez, cabe de sobra en el contexto y es lo que el modelo necesita.

Paso 2: la línea temporal en código

Las horas exactas no deben salir del modelo. Construye en código la cronología a partir de los patrones y de otras fuentes (despliegues, cambios de configuración, alertas): cuándo apareció por primera vez cada error, cuándo se disparó cada alerta, cuándo se desplegó la última versión. Pasa esa cronología al modelo ya ordenada. Así el informe no puede equivocarse en el orden de los hechos, que es justo lo que más importa para encontrar la causa.

Paso 3: el borrador, con hechos e hipótesis separados

Redacta un borrador de informe de incidencia con estas secciones:
1. Resumen (qué falló, impacto, duración)
2. Cronología (usa solo las horas de la cronología proporcionada)
3. Hechos observados en los registros (cita el patrón y su conteo)
4. Hipótesis sobre la causa, marcadas como hipótesis, con la evidencia
   a favor y en contra de cada una
5. Preguntas abiertas que habría que verificar
No afirmes una causa como confirmada si los datos no la demuestran.

La separación entre hechos e hipótesis es lo que hace útil el borrador. Un modelo tiende a construir una explicación coherente aunque los datos no la sostengan del todo; obligarle a marcar las hipótesis y las preguntas abiertas evita que una suposición acabe en el informe final como causa probada.

Los registros contienen a menudo datos sensibles: tokens de acceso, contraseñas en cadenas de conexión, correos y direcciones IP de clientes. Ocúltalos en el paso de plantillas antes de enviar nada a un proveedor externo, y revisa las reglas con el equipo de seguridad.

Revisión y formato sin culpables

El borrador lo revisa y completa quien gestionó la incidencia. Muchos equipos siguen el formato de informe sin culpables (blameless): describir qué falló en el sistema y en los procesos, no quién se equivocó. Pide al modelo ese enfoque explícitamente; si no, tiende a redactar en términos de errores personales cuando los registros muestran una acción manual.

Errores frecuentes y limitaciones

Confundir correlación con causa. Que un error aparezca justo antes de la caída no lo convierte en su causa; puede ser otro síntoma. La sección de hipótesis con evidencia a favor y en contra existe para eso.

Plantillas demasiado agresivas. Si la sustitución de variables convierte en el mismo patrón mensajes que significan cosas distintas, el resumen oculta información. Revisa los patrones más frecuentes al configurar las reglas.

Usar solo los errores. Los registros de nivel informativo muestran qué estaba haciendo el sistema justo antes del fallo: despliegues, reinicios, cambios de carga. Incluye los patrones relevantes de todos los niveles en la ventana de la incidencia.

Flujo recomendado

Filtra la ventana temporal y los servicios afectados, convierte líneas en patrones con conteos y oculta datos sensibles, construye la cronología en código con despliegues y alertas, pide un borrador que separe hechos, hipótesis y preguntas abiertas, y revísalo con el formato sin culpables.