La Auditoría Diaria de Prompts de 5 Minutos: Mantén los Costos de LLM Bajo Control

Cada producto con LLM que he lanzado tiene la misma historia: funciona bien por unas semanas, alguien ajusta un prompt o agrega una herramienta, y tres lunes después el equipo de finanzas hace una pregunta incómoda en Slack. El diff siempre parecía inofensivo. La factura no.

Lo arreglé con un ritual de cinco minutos que hago antes de mi primer café.

El Ritual

Cuatro números. Comparados contra ayer. Eso es todo.

1. Tokens por request (input y output, separados)
2. Tasa de cache hit — para prompt caching o cache semántico
3. Tasa de reintentos — cuántas veces el primer call falló validación o parseo
4. Costo por resultado exitoso — en la unidad que tu producto define

Si cualquiera de estos se desvía más del 15% respecto a ayer, abro un issue antes del almuerzo. Por debajo del 15% es ruido; por encima es una señal.

Qué Te Dice Cada Número

Tokens por request

Este es el canario. Un edit al prompt, un nuevo few-shot, un context window más grande — todos aparecen aquí primero. Input tokens subiendo usualmente significa que alguien agregó contexto. Output tokens subiendo usualmente significa que el modelo se volvió más parlanchín, lo que a menudo significa que el prompt dejó de restringirlo bien.

┌─────────────────────────────────────────────────────┐
│  Tokens por request — qué significa la desviación   │
├─────────────────────────────────────────────────────┤
│                                                      │
│  Input sube, output igual   → prompts/context       │
│                               más grandes            │
│  Input igual, output sube   → modelo explicando     │
│                               de más                 │
│  Ambos suben juntos         → alguien "mejoró" el   │
│                               prompt el fin de      │
│                               semana                 │
│  Input baja, output sube    → el contexto se cortó, │
│                               el modelo llena huecos│
│                                                      │
└─────────────────────────────────────────────────────┘

Tasa de cache hit

Si estás usando prompt caching (y deberías, para cualquier cosa con system prompt estable), tu hit rate te dice si el borde de tu cache está saludable. Una caída usualmente significa que algo dinámico se coló en lo que debería ser un prefijo estático — un timestamp, un user ID, un Date.now() en un template.

He visto cache hit rates caer de 94% a 11% porque alguien interpoló la hora actual en un system prompt "para debuggear." Eso costó cerca de $4,000 antes de que alguien lo notara.

Tasa de reintentos

Parses fallidos, violaciones de schema, rechazos de guardrails. Cada reintento es un request completo que pagaste y tiraste. Una tasa de reintentos subiendo es a menudo la primera señal de que una versión del modelo cambió sin avisar, o que un prompt se desvió del schema de output que solía producir de forma confiable.

Costo por resultado exitoso

Esta es la única métrica que le importa al negocio. Todo lo de arriba es un indicador líder; esta es la que realmente tienes que defender.

Define "resultado exitoso" en el borde del producto: un ticket resuelto sin escalación, un borrador aprobado sin ediciones, un flujo que llegó al final. Luego divide el gasto total en LLM entre ese conteo. Si este número está estable o bajando mientras crece el tráfico, estás ganando. Si está subiendo, algo upstream está mal aunque el modelo se esté comportando bien.

El Setup Mínimo Viable

No necesitas una plataforma. Necesitas una query y un lugar para poner la respuesta.

-- Query de auditoría diaria de prompts (simplificada)
SELECT
  date_trunc('day', created_at) AS day,
  endpoint,
  avg(input_tokens) AS avg_input,
  avg(output_tokens) AS avg_output,
  sum(case when cache_hit then 1 else 0 end)::float
    / count(*) AS cache_hit_rate,
  sum(case when retry_count > 0 then 1 else 0 end)::float
    / count(*) AS retry_rate,
  sum(cost_usd) / sum(case when outcome = 'success' then 1 else 0 end)
    AS cost_per_success
FROM llm_requests
WHERE created_at > now() - interval '2 days'
GROUP BY 1, 2
ORDER BY 1 DESC, 2;

Manda el output a Slack a las 7am. Léelo con tu café. Si algo está raro, abre un issue con el delta en el título para que tu yo futuro pueda encontrarlo.

Por Qué Funciona

La mayoría de los desastres de costo de LLM que he visto no fueron causados por malas decisiones. Fueron causados por pequeñas decisiones razonables tomadas sin un feedback loop. Alguien agrega un ejemplo útil a un prompt. Alguien interpola un valor de debug en un system message. Alguien apaga el caching mientras prueba y olvida prenderlo de vuelta.

Un ritual diario de cinco minutos es más barato que cualquier plataforma de observabilidad y atrapa el 90% de estos. El 10% restante es para lo que existe la plataforma — y para entonces sabrás exactamente qué necesitas de ella.

La disciplina es la herramienta. El dashboard es solo donde lo escribes.