Observabilidad de LLMs: qué registro de cada llamada y por qué

Qué es observar un sistema con LLM

Es poder responder, después de que pasó, qué se llamó, con qué modelo y qué prompt, cuánto costó, cuánto tardó y cómo terminó. Sin esos datos no se puede explicar un gasto que sube, una latencia que empeora ni una respuesta mala.

AgendaGo: la tabla ai_usage_log (en producción)

Por cada llamada la tabla guarda: negocio, agente, usuario, modelo, versión del prompt, tokens de entrada, de salida y de caché, costo en dólares, latencia, intención, herramientas usadas y resultado. El resultado puede ser ok, fallback, derivación, error, presupuesto agotado, rechazo de un guardrail o rechazo del modelo.

• No guarda texto de clientes.
• Los prompts están versionados en el repositorio, y la versión se guarda en cada llamada.
• Un test exige que cada insert declare modelo y versión de prompt.
• El presupuesto mensual por negocio lo hace cumplir un único control en la base.

La decisión: si no se puede registrar, no se atiende

El registro es fail-closed: si el insert de uso falla, el turno se corta. Es un compromiso explícito. Se acepta que una falla del registro interrumpa una respuesta, a cambio de no tener nunca llamadas sin medir ni un presupuesto que no se puede controlar.

Langfuse y Nux: en construcción

La plataforma de agentes de IA para empresas está en construcción, en fase 0. Su diseño incluye Langfuse para trazas y costos, y evaluaciones sobre un conjunto de preguntas. Todavía no hay código ni datos.

Nux, el asistente de Bonuxo, tiene un registro de uso y topes de costo por plan, con la integración de Langfuse en curso. Su capa de LLM está construida pero apagada en producción.