No puedes enviar un feature LLM sin evals, pero tampoco puedes justificar una plataforma de evals de $40k para un feature que maneja cuarenta queries a la semana. Hay un camino intermedio. Esto es lo que enviamos por defecto en Bamboo.
El test de cuatro buckets
Para cualquier feature LLM, queremos saber:
- ¿Dio la respuesta correcta? Precisión sobre un conjunto held-out de pares Q&A conocidos.
- ¿Rechazó cuando debía? Tasa de rechazo sobre entradas adversariales / fuera de scope.
- ¿Mantuvo la voz? Adherencia de tono/formato — usualmente un pase LLM-as-judge.
- ¿Costó lo que esperábamos? Tokens por request, p50 y p95.
Si cualquiera de estos regresiona más de un 10% entre dos releases, no enviamos.
Cómo se ve el “mínimo viable”
- 30–50 casos por bucket. No 30,000. Los primeros 30 atrapan el 80% de las regresiones; el resto son retornos decrecientes hasta que tengas usuarios reales quejándose.
- Un archivo JSON plano por feature, committeado en git. Sin base de datos, sin plataforma de evals. Versionado junto al prompt mismo, porque el conjunto de evals ES parte del contrato del prompt.
- Un script
npm run evalsque corre todos los buckets en paralelo e imprime un diff contra la última corrida committeada. Agregamos una GitHub Action que lo corre en cada PR que toca el prompt.
Lo que NO hacemos en esta etapa
- Dashboards de evals en tiempo real
- Voting de consenso multi-juez
- Tests de significancia estadística
- Cualquier cosa que requiera un frontend
Tienen valor. También son problemas de Fase 3, no de Fase 1. Envía el feature, ve si alguien lo usa, después vuelves por el dashboard.
La única cosa que no puedes saltar
Los 30 casos de test curados a mano. No generados por LLM, no scrapeados de logs — tú te sientas con el product owner por dos horas y escribes los casos que ellos realmente querrían ver pasar. Este es el paso más subvalorado y más importante. Sáltalo y tus evals estarán midiendo ruido.