Versionar prompts y evaluar automatizaciones sin montar un laboratorio de investigación

El prompt que hay dentro de una automatización es la única parte de un sistema en producción que se edita habitualmente desde un navegador, sin diff, sin revisión y sin pruebas. Equipos que jamás permitirían un cambio de configuración en producción sin una tubería reescriben tan tranquilos un prompt de clasificación a las cuatro de la tarde porque un compañero se quejó de una salida.

Y entonces la calidad se mueve, en una dirección que nadie mide, y tres semanas después alguien pregunta qué cambió.

Saca el prompt del flujo

El paso uno es mecánico: los prompts viven en ficheros de un repositorio, no dentro de la configuración de un nodo. El flujo referencia una clave; un pequeño servicio o una tabla resuelve la clave a la versión vigente.

Eso compra cuatro cosas de golpe: un diff, un revisor, un histórico y la capacidad de volver atrás en segundos en vez de recordando qué decía el texto antes. Además hace que el hash de prompt que registras en cada ejecución signifique algo, que es lo que permite a la observabilidad responder a «qué cambió».

Versiona el modelo junto a él. Un prompt y una versión de modelo son una sola unidad; un prompt afinado contra un modelo no está validado contra otro, y poner «última» como ajuste de modelo significa que tu comportamiento en producción cambia cuando publica el proveedor.

La evaluación más pequeña que sirve

No necesitas un framework de evaluación. Necesitas cincuenta ejemplos y un script.

Construye el conjunto desde producción. Cincuenta entradas reales con su salida correcta al lado. La fuente más barata es tu cola de revisión humana: cada corrección que hizo un revisor es un ejemplo etiquetado, y por eso el campo de motivo del rechazo se paga solo. Incluye los raros a propósito: el proveedor cuyas facturas son fotos de una pantalla, el cliente cuyo nombre rompe tu parser. Un conjunto de casos fáciles no mide nada.

Puntúa lo que de verdad te importa. Para clasificación y extracción eso es coincidencia exacta por campo, y no admite discusión. Para texto generado, elige tres criterios que puedas enunciar como preguntas de sí o no —¿se mantuvo en el idioma pedido?, ¿evitó inventarse un número que no estaba en el origen?, ¿siguió el formato?— y comprueba esos. Una puntuación vaga de calidad, la ponga una persona o un modelo, produce números que se mueven sin significar nada.

Ejecútalo en cada cambio. Un script que tome versión de prompt y modelo, pase los cincuenta ejemplos, imprima una puntuación y un diff de qué ejemplos cambiaron de veredicto. Diez minutos de ejecución, céntimos de coste. Esto es todo.

El diff importa más que la puntuación. Un cambio que te lleva del 86 al 88 por ciento arreglando cuatro casos y rompiendo dos es una decisión distinta de uno que arregla dos y no rompe ninguno, y el agregado lo esconde.

Regresión, no perfección

El propósito de este conjunto no es demostrar que la automatización es buena. Es impedir que un cambio la empeore.

Ese replanteamiento baja el listón a algo que un equipo mantendrá de verdad. Cincuenta ejemplos en un CSV, un script y una regla: el prompt no cambia sin que el script se ejecute. En un año el conjunto crece a doscientos, casi todos procedentes de fallos que llegaron a producción una vez y no volverán, y en ese punto tienes algo genuinamente valioso que nadie tuvo que planificar como proyecto.

Las actualizaciones de modelo son el momento en que esto se paga

Cada pocos meses aparece un modelo mejor y más barato. Sin un conjunto de evaluación, migrar es un acto de fe seguido de un mes de anécdotas. Con él, es una prueba de veinte minutos y un número, y te enteras en el momento del caso concreto en que el modelo nuevo formatea las fechas de otra manera.

Ese único uso justifica toda la práctica, porque las actualizaciones de modelo no son opcionales para siempre: los proveedores retiran versiones, y el aviso de retirada no es el momento en el que quieres empezar a descubrir qué se rompe.

Qué hacer esta semana

Exporta a un CSV los últimos treinta elementos que corrigieron tus revisores, con la entrada y la salida corregida. Ese fichero es tu conjunto de evaluación y ya existe dentro de tu cola. El script que lo ejecuta es una hora de trabajo y lo vas a usar dentro del mes.