Regresiones en prompts: cuando un cambio de texto rompe lo que ya funcionaba
Una regresión en un prompt ocurre cuando un cambio de texto o de modelo empeora casos que ya funcionaban. Cómo detectarla y migrar sin sorpresas.
¿Por qué un prompt puede regresar?
Un prompt no es código con líneas independientes. Cada palabra afecta a todas las respuestas posibles. Cuando agregas una regla para corregir un caso, puedes cambiar el peso de otras instrucciones, y el modelo empieza a aplicar la regla donde no correspondía.
Hay dos fuentes frecuentes de regresión:
- El cambio de texto. Agregar “siempre confirma antes de responder” para un caso de reservas, y de pronto el asistente pide confirmación para preguntas de menú.
- El cambio de modelo. Una versión nueva se comporta distinto aunque el prompt no haya cambiado.
La segunda suele sorprender más, porque nadie tocó nada. Una guía de migración independiente de Claude abre diciendo que migrar una carga de producción “rara vez” es cambiar el identificador del modelo y publicar. La documentación oficial de Anthropic apunta en la misma dirección: su guía de Claude Sonnet 5.5 pide repetir el barrido de nivel de esfuerzo contra tus propias evaluaciones, en vez de conservar el ajuste que usabas con Claude Sonnet 5.
¿Qué puede cambiar al migrar un modelo?
La guía oficial de migración a Claude Sonnet 5.5 es un buen ejemplo concreto. Estos son algunos de los cambios que documenta, según el modelo de partida:
| Aspecto | Qué dice la documentación | Qué revisar en tu producto |
|---|---|---|
| Parámetros de muestreo | temperature, top_p y top_k devuelven error 400 | Cualquier llamada que los envíe |
| Prefill | Rellenar el último turno del asistente devuelve error 400 | Prompts que forzaban formato con un prefill |
| Tokens | Frente a Sonnet 4.6, 4.5 y Haiku 4.5, el mismo texto produce alrededor de un 30 % más de tokens | Límite de salida, margen de contexto y costo |
| Razonamiento | El texto del razonamiento viene omitido por defecto | Código o interfaz que mostraba ese texto |
| Rechazos | Aparece el motivo de parada refusal | Código que asume texto en el primer bloque |
| Esfuerzo | Los niveles se recalibran: el mismo nivel no produce la misma cantidad de razonamiento | Calidad, latencia y costo en cada nivel |
Una guía independiente añade que los modelos nuevos tienden a seguir las instrucciones de forma más literal y que la frecuencia con que usan herramientas puede cambiar. Eso no está en la documentación oficial consultada, así que trátalo como una hipótesis que tu set de pruebas debe confirmar o descartar.
La lección no depende del modelo concreto: cada fila es algo que se mide, no que se supone.
¿Cómo se detecta una regresión?
El método es el de cualquier prueba de regresión, adaptado al lenguaje. Hamel Husain lo resume así: como las pruebas unitarias, los evals pueden detectar problemas que vuelven después de un arreglo. También advierte que cuestan bastante más de mantener y ejecutar que una prueba unitaria.
- Fija el conjunto de casos. Un golden dataset versionado, con casos representativos, casos que ya fallaron y casos de borde.
- Corre la versión actual y la candidata sobre el mismo conjunto, lado a lado.
- Califica por propiedades, no por texto exacto. Si el resultado debe ser un JSON válido, revisa que lo sea. Si debe llamar a una herramienta, revisa esa decisión. Comparar frases palabra por palabra da falsas alarmas. Para criterios subjetivos, usa un juez modelo validado contra etiquetas humanas.
- Revisa los cambios de signo. Los casos que pasaban y ahora fallan son la señal más importante. Los que mejoran también merecen una mirada, porque a veces mejoran por una razón que no esperabas.
- Guarda las salidas crudas. Cuando algo falla, necesitas ver qué respondió el modelo para diagnosticar.
Husain recomienda que el análisis parta de trazas reales y no de métricas genéricas. Langfuse lo traduce en una regla práctica: cada error que se escapa a producción se convierte en un caso nuevo del set.
¿Cómo se automatiza?
Langfuse propone mover la comparación a la integración continua, de modo que cada cambio que toque un prompt corra el golden dataset automáticamente. Para que la revisión de cada cambio sea rápida, sugiere una compuerta con un subconjunto de decenas a pocos cientos de casos, y reservar la suite completa para cambios grandes o antes de publicar.
En un equipo pequeño, esto puede empezar siendo un script que corre el set y muestra los casos que cambiaron de pasar a fallar. Lo importante es que el prompt viva en un archivo versionado, para que cada cambio de texto deje rastro y se pueda revertir.
¿Cómo se despliega sin sorpresas?
Una secuencia que reduce el riesgo:
- Inventario: encuentra cada lugar donde aparece un identificador de modelo, incluidos configuraciones y fixtures de prueba.
- Fija la versión durante la migración, para que las comparaciones sean reproducibles, y deja la anterior disponible como respaldo.
- Compara sin tráfico real, offline, y revisa tasas de error, latencia y costo.
- Despliega por etapas: primero una porción pequeña, luego más. El identificador del modelo debe estar en configuración para poder revertir sin redeploy.
- Define los umbrales de reversión antes: límites de calidad, errores y costo. Si se cruzan, se revierte.
- Ajusta el prompt aparte, después de migrar y medir, para que cada efecto tenga una causa identificable.
¿Cuándo NO conviene?
- Cuando el prompt es corto, el caso de uso es simple y el set de pruebas costaría más que los errores que evita. Pero un set de 20 casos ya suele valer la pena.
- Cuando no hay forma de comparar versiones. Sin set fijo, cada cambio es una opinión.
- Cuando la migración se hace y el prompt se reescribe en la misma semana. Pierdes la capacidad de atribuir efectos.
Ejemplo
Ejemplo ilustrativo: un asistente de citas médicas tiene 120 casos en su golden dataset. El equipo agrega una regla en mayúsculas para que el asistente siempre confirme el horario antes de cancelar. La compuerta rápida pasa, pero al correr la suite completa aparece una regresión: 9 casos de consultas de precios ahora piden confirmación de horario, sin sentido. Quitan el énfasis, reformulan la regla como condición (“si el usuario pide cancelar”) y vuelven a correr. Ese mismo trimestre migran de modelo: el set detecta que la tasa de herramientas innecesarias subió de 2 % a 7 %. Revierten el modelo en configuración, ajustan el prompt en un cambio aparte y migran de nuevo cuando las cifras cuadran.
Para entender cómo armar el conjunto de casos, lee golden datasets. Para la idea de evals como prueba continua, qué son los evals. Y para medir resultados con criterios, LLM-as-judge.
Errores comunes
- Cambiar el identificador del modelo sin correr ningún caso.
- Corregir un fallo con un énfasis fuerte que afecta otros comportamientos.
- Comparar texto exacto y concluir que hay regresión por una palabra diferente.
- Migrar modelo y prompt en el mismo cambio, sin poder atribuir efectos.
- Conservar el nivel de esfuerzo del modelo anterior sin repetir la medición.
- No revertir cuando un umbral se cruza, porque “el nuevo modelo es mejor en general”.
Fuentes
- Claude Sonnet 5.5 migration guide (documentación de Anthropic): parámetros que devuelven error, prefill, tokens, razonamiento omitido, rechazos y esfuerzo.
- Prompting Claude Sonnet 5.5 (documentación de Anthropic): repetir el barrido de esfuerzo contra tus propias evaluaciones.
- Anthropic Claude Model Migration Guide (Hidekazu Konishi, blog independiente): “rara vez” basta con cambiar el identificador; instrucciones más literales y frecuencia de herramientas.
- LLM Evals: Everything You Need to Know (Hamel Husain): evals como pruebas de regresión, análisis de errores sobre trazas reales.
- Golden dataset evaluation: build and maintain LLM test sets (Langfuse): compuerta en integración continua, subconjunto rápido, casos nuevos desde fallos.