Inkling 2 Small solto 316 palabrotas, pero casi no ayudaron a predecir los fallos

A veces un modelo se rompe de una forma casi humana: comete varios errores, declara que “nada funciona”, suelta palabrotas y sigue generando texto. Los investigadores de Vals AI encontraron exactamente este comportamiento en los registros internos de Inkling 2 Small, de Thinking Machines. El detalle divertido se convierte rapidamente en una cuestion de ingenieria: ¿pueden las palabras con carga emocional revelar de antemano que el modelo ha perdido el rumbo hacia la solucion?

La respuesta corta es no. Las palabrotas llaman la atencion, pero funcionan mal como senal de fallo. Para un desarrollador es mas util observar la repeticion de frases, la longitud de la generacion, el consumo de tokens y la falta de avance hacia el resultado que el vocabulario del modelo.

Lo que revelaron los registros

Los investigadores revisaron 2.655 ejecuciones en 13 pruebas. La palabra “fuck” y sus variantes aparecieron en 50 ejecuciones, 316 veces en total. De esos casos, 241 correspondieron unicamente a dos generaciones que quedaron atrapadas en bucles.

El episodio mas ilustrativo surgio en una tarea sobre el calculo de la trayectoria de un asteroide. En vez de ofrecer una solucion compacta, el modelo genero unos 500.000 caracteres: repitio las mismas frases y uso el insulto 158 veces. Esto ya no era un problema de tono. Una respuesta asi desperdicia recursos de computacion, aumenta la latencia y puede ocupar el contexto de la siguiente etapa de un proceso basado en agentes.

El efecto fue especialmente frecuente en ProgramBench: aparecio en 20 de 200 ejecuciones. Normalmente, el modelo soltaba palabrotas despues de cometer su propio error, durante un supuesto avance o antes de abandonar nuevos intentos. El patron resulta reconocible: la solucion no encaja, el monologo interno se vuelve mas brusco y despues la generacion se interrumpe o entra en repeticion.

Por que es un mal detector de errores

A primera vista, la correlacion parece fuerte: 46 de las 48 ejecuciones evaluadas que contenian palabrotas terminaron en fracaso. Pero la tasa general de fallos ya rondaba el 75%. Y hay un dato aun mas importante: el 96% de todas las ejecuciones fallidas no contenia ninguna palabrota.

Imaginemos un servicio que marca una respuesta como sospechosa cuando aparece lenguaje malsonante en el registro interno. En efecto, detectaria varios accidentes llamativos, pero dejaria pasar la inmensa mayoria de los errores. Es como vigilar el sobrecalentamiento de un servidor por el olor a plastico: cuando aparece, es una senal grave, pero esperar a percibirla significa monitorizar demasiado tarde.

Las palabrotas pueden conservarse como senal diagnostica adicional, pero no se puede construir la proteccion alrededor de ellas. Tambien dependen del idioma, los datos de entrenamiento y la configuracion del modelo. Tras actualizar el modelo, este indicador puede desaparecer aunque los bucles permanezcan.

Que deben hacer los desarrolladores

En produccion hacen falta senales relacionadas con el propio fallo. Limite el numero maximo de tokens y el tiempo de ejecucion. Cuente los fragmentos repetidos, vigile el crecimiento brusco de la respuesta y detenga la generacion si el modelo pasa varios pasos consecutivos sin acercarse a un resultado verificable. En sistemas basados en agentes, establezca un limite de intentos y guarde el motivo de la detencion por separado del texto de razonamiento.

Tambien conviene verificar el resultado por medios externos: ejecutar pruebas para el codigo, validar cifras, exigir una respuesta estructurada o recurrir a un evaluador independiente. El registro interno puede ayudar a analizar un incidente, pero no debe ser la unica fuente de verdad.

La conclusion practica es sencilla: el vocabulario inusual del modelo es un sintoma interesante, no una metrica fiable. Si un sistema puede producir 500.000 caracteres repetidos, lo primero que hay que reparar es el control de la generacion. Un diccionario de palabras prohibidas es cosmetica; los limites, el detector de bucles y la verificacion del resultado son la proteccion real.