Si tu modelo "empezó a comportarse diferente" de la noche a la mañana sin cambio de modelo, probablemente es drift de tokenización. Mismo tokenizer, entrada semánticamente idéntica, secuencias de tokens completamente diferentes. Un ejemplo GPT-2 del artículo de MarkTechPost: `" classify"` con espacio adelante tokeniza a un solo ID, `[36509]`; `"classify"` sin el espacio tokeniza a dos IDs, `[4871, 1958]`. Para el modelo, esas no son la misma palabra — son entradas distintas aterrizando en regiones distintas del espacio de tokens. Que tu prompt sea "casi el mismo" que lo que el modelo vio durante fine-tuning no es lo mismo que ser igual.

El artículo cuantifica el modo de fallo. Usando el tokenizer de GPT-2 y un clasificador fine-tuneado, el formato de prompt alineado-SFT alcanza ~83% de accuracy. Quita los saltos de línea y caes a 40-50%. Reformula la instrucción y el solapamiento Jaccard de tokens con el formato de entrenamiento cae a ~50%, empujando la entrada fuera-de-distribución y hundiendo la accuracy. El arreglo propuesto es APO (Automated Prompt Optimization): probar cinco-plus variantes de template, puntuar cada una por solapamiento Jaccard de conjuntos de tokens contra el template SFT original, escalar accuracy de validación por una penalización OOD proporcional al solapamiento, y escoger el template ganador en la métrica combinada. La implementación es unas líneas de HuggingFace `AutoTokenizer.encode()` más comparación de conjuntos.

El patrón mayor es que las regresiones de prompt en producción usualmente no son regresiones de modelo — son desajustes a nivel de tokenizer entre lo que el modelo aprendió durante instruction tuning y lo que tu aplicación está enviando ahora. Este es el tipo de bug que sobrevive a cada test que tienes a menos que estés revisando explícitamente secuencias de tokens contra una distribución de referencia. También es por qué "el mismo prompt" copiado de un Notion a un editor de código puede degradar silenciosamente — el editor normalizó tu whitespace o quitó un salto de línea final, y ahora estás a una distancia diferente de los datos de entrenamiento. Modelos RLHF e instruction-tuned son extra sensibles porque el formato se vuelve parte de la representación de la tarea, no solo decoración alrededor.

Qué hacer lunes: registra secuencias de tokens crudas para prompts de producción (no compares strings, compara IDs de token) y dífalas contra el prompt original que probaste al desplegar. Añade un test de regresión Jaccard-overlap en tu pipeline CI de prompts. Si corres fine-tunes, guarda la tokenización exacta de tu formato de entrenamiento y valida entradas de inferencia contra eso. Para devs en modelos de pesos cerrados que no puedes reentrenar, el movimiento práctico es el bucle APO del artículo: busca empíricamente variantes de prompt que maximicen el solapamiento de tokens con formatos que el modelo claramente ha visto antes. La pregunta "¿está funcionando mi prompt?" se vuelve una pregunta a nivel de tokenizer, no a nivel de redacción.