¿Por qué la observabilidad en LLMs es distinta?

• Composición: hay varias etapas (entrada → recuperación → LLM → herramientas → salida).
• Calidad depende del contexto y del prompt, no solo del código.
• Costos varían por tokens, modelo y longitud de contexto.
• Privacidad: debes evitar PII cruda en logs y respetar contratos de salida.

Trazas que explican qué pasó

Crea un trace por request con spans por etapa:

1. input (normalización, idioma, tenant)
2. retrieval (query, filtros, topK, colecciones)
3. llm (modelo, tokens, temperatura, p95)
4. tools (nombre, args válidos, éxito/fallo)
5. output (validez JSON, longitud, política)

{
  "trace_id":"abc-123",
  "spans":[
    {"name":"retrieval","attrs":{"top_k":3,"collections":["policies"],"recall_k":0.67}},
    {"name":"llm","attrs":{"model":"slm-1","prompt_tokens":620,"completion_tokens":210,"cost_usd":0.0042,"lat_ms":820}},
    {"name":"tools/crear_ticket","attrs":{"ok":true,"lat_ms":340}},
    {"name":"output","attrs":{"json_valid":true,"groundedness":0.8,"abstained":false}}
  ]
}

Tip: usa un estándar de trazas (p.ej., OpenTelemetry) y añade request_id en toda la cadena.

Métricas que importan (por capa)

• Entrada: idioma, longitud, categoría de riesgo, % inputs con PII redaccionada.
• Recuperación: recall@K, nDCG, tamaño de contexto, % colecciones allowlist.
• LLM: tokens prompt/salida, costo por request, latencia p50/p95/p99, % abstención.
• Herramientas: tasa de éxito, latencia p95, fail/abort rate por herramienta.
• Salida: % JSON válido, groundedness medio, % respuestas “safe”.
• Negocio: resolución en primer intento, CSAT/feedback, conversión.

Dashboards esenciales

• Performance: latencia por etapa (retrieval/LLM/tools), errores por endpoint.
• Calidad: groundedness, % JSON válido, win-rate de variantes (si hay A/B).
• Costos: costo p50/p95 por tenant/modelo, distribución de tokens y tamaño de contexto.
• RAG: recall@K por colección, topK efectivo, reranker on/off.

Alertas que de verdad ayudan

• Latencia p95 > objetivo (N min).
• % JSON inválido > umbral.
• Groundedness < umbral (posible corpus roto o ingestión defectuosa).
• Costo p95 > presupuesto.
• Recall@K cae por debajo de X (índice o filtros mal configurados).

Privacidad y cumplimiento en observabilidad

• Redacción de PII en el borde; guarda hashes/metadatos, no textos crudos.
• Allowlist de campos en logs; nada de prompts completos sin máscara.
• Retención y acceso por rol; separa prod de debug.

Micro-workflow en n8n: “Colector y alertas LLM”

1. Webhook → recibe {request_id, spans, metrics} del backend.
2. Function → normaliza, añade tenant, pipeline_version, modelo.
3. IF → si falta request_id → genera y notifica.
4. Database → inserta métricas agregadas por minuto y por modelo.
5. Notifier → alerta si % json_invalid, groundedness, p95 o cost_p95 superan umbrales.

Tips para Laravel/PHP

• Propaga request_id y trace_id con Log::withContext(), Jobs y HTTP client.
• Logs estructurados (JSON) por canal: app, llm, rag, tools; sin PII.
• Métrica por request: {tokens_in, tokens_out, cost_usd, lat_ms, json_valid, groundedness}.
• Tabla llm_metrics con índices por tenant, modelo, pipeline_version y fecha.
• Middleware de redacción: máscara emails, teléfonos y claves antes de loggear.

Operación diaria

• Revisión de p95 y costos cada mañana; drill-down por modelo/tenant.
• Canary para cambios en prompts o topK, con eval gate previo (ver post #19).
• Runbooks con acciones ante caída de groundedness o subida de % JSON inválido.

Conclusión

La observabilidad convierte un sistema con IA en algo predecible y gobernable. Con trazas, métricas y alertas específicas para LLMs podrás detectar regresiones, controlar costos y mejorar calidad sin adivinar.

← Anterior: Del notebook al producto: llevando tu proyecto de IA a producción

Siguiente: Evaluación continua: asegurando que tu modelo no empeore con el tiempo →