Evals antes que prompts: mide o no mejores

El prompt que “se siente mejor”

Cambiar un prompt y notar que responde mejor es la forma más cara de autoengañarse en ingeniería con LLMs. Mejora un caso, rompe tres que no miraste. La salida es tratar los prompts como código con tests: un set de evaluación fijo que puntúa cada cambio antes de desplegarlo.

El set dorado

Reúne entre 30 y 50 casos reales de tu dominio (no inventados): entradas difíciles, ambiguas y típicas, cada una con la respuesta esperada o con criterios de aceptación escritos. Cúbrelos una vez a mano para fijar la línea base. Este set es tu especificación ejecutable; todo lo demás es decoración.

El harness mínimo

Un script que, ante un cambio de prompt, modelo o temperatura, ejecuta el set completo y reporta: tasa de acierto, costo total y latencia p95. Guarda cada corrida con fecha y commit para comparar en el tiempo. No necesitas plataforma de evals para empezar; necesitas el hábito de correr el script antes de cada deploy.

La puerta en CI

Cuando el harness existe, la regla es mecánica: ningún cambio de prompt llega a producción si baja la tasa de acierto del set dorado o si dispara el costo por encima del presupuesto de la lección 1. Las regresiones dejan de ser sustos de lunes para convertirse en builds en rojo que nadie mergea.

Versiona los prompts

Cada prompt lleva versión, fecha y el resultado de su última corrida. Cuando un proveedor actualiza el modelo por debajo de ti (ocurre cada pocas semanas), reejecutas el set y sabes en minutos si algo cambió, en lugar de descubrirlo por quejas de usuarios.

Ejercicio

Escribe 10 casos de tu dominio hoy mismo, con su respuesta esperada. Mañana, otros 10. En una semana tienes un set que vale más que cualquier framework de prompting.

Con esto cierras el módulo 1: presupuesto que elige modelo, secretos que nunca tocan tu servidor y cambios medidos en vez de intuídos. Los módulos 2 y 3 (RAG y producción) abren con la lista de espera.