La optimización de prompts puede acabar optimizando el evaluador, no el prompt

Cuando un bucle de optimización de prompts deja que el candidato, la rúbrica de puntuación y los casos de prueba se muevan al mismo tiempo, el número que sube no significa nada. El optimizador está mejorando el examen, no el prompt. Al que le explota esto no es al que mira el gráfico cada iteración: es al usuario, que nota el bajón antes de que la métrica se entere.

El mecanismo es sencillo de describir y difícil de ver en marcha. El prompt se sobreajusta a los casos concretos que ha visto, y la rúbrica, que también se ha movido, deriva hacia premiar lo que no toca. Durante la optimización no hay señal de alarma: la puntuación sube en cada vuelta y el changelog parece una sucesión de mejoras. La regresión solo aparece después, con tráfico real.

La receta que circula para evitarlo viene de un patrón que el post atribuye al bucle de investigación automática de Karpathy, cifrado por su autor en 42.000 estrellas en GitHub: separar el sistema en cuatro roles. El archivo que cambia, la métrica que puntúa, la dirección que guía y la restricción que bloquea. Casi todo el mundo implanta los tres primeros y se salta el cuarto, que es justamente el que sostiene el invento.

Congelar lo que puntúa

Llevado a optimización de prompts, bloquear significa tres cosas concretas. La rúbrica de puntuación y los casos de prueba quedan congelados: el agente no puede reescribir sus propias condiciones de aprobado. Se mantiene aparte un conjunto de validación ciego, un holdout que el optimizador no ve nunca y que solo se usa al final. Y cada versión del prompt se registra junto a la versión del modelo y la configuración de herramientas, de forma que una caída de calidad se pueda rastrear hasta un cambio determinado y no hasta una sensación.

Aakash Gupta trasladó ese mismo bucle al terreno de la ingeniería de prompts y se encontró con lo de siempre: lo que hace funcionar el ciclo es el evaluador bloqueado. Sin él, el agente optimiza el test, el prompt se queda como estaba y el gráfico miente.

Future AGI, que firma el texto, tiene aquí interés comercial: vende herramientas de puntuación construidas sobre ese principio. Su argumento es razonable de todos modos. Un prompt candidato puede sonar convincente y fallar en casos que no ha visto nunca, así que puntúan la salida real y no la explicación que el propio candidato da de sí mismo. La explicación no es la condición de aprobado.

La pregunta que deja abierta es operativa y no tiene respuesta cerrada: cómo se protege el holdout cuando es un agente el que reescribe los prompts. En cuanto ese conjunto se filtre al bucle, aunque sea por una descripción intermedia, se vuelve al punto de partida.