¿Qué ocurre cuando menos del 3% de las solicitudes consume casi la mitad del tiempo de procesamiento? No hablamos de un servidor caído ni de una consulta especialmente compleja. Hablamos de modelos de lenguaje que entran en un bucle de repetición y continúan generando texto hasta alcanzar el límite máximo de tokens.
Este fenómeno, conocido como text degeneration o degeneración de texto, suele tratarse como un problema de calidad. Sin embargo, un análisis aplicado a sistemas de OCR demuestra que también es un problema de rendimiento, costos y capacidad operativa.
Cuando una respuesta se queda atrapada
Un modelo autoregresivo genera texto token por token. En condiciones normales, produce la respuesta y emite un token especial llamado EOS, que indica que la secuencia terminó.
Una solicitud degenerada nunca llega correctamente a ese punto. El modelo comienza a repetir un token, una frase o un fragmento completo. La secuencia continúa hasta que el servidor activa el límite de max_tokens y detiene la generación de manera forzada.
El problema no es solo que el resultado sea inútil. Una respuesta que debía terminar en pocos segundos puede mantener ocupada la GPU durante mucho más tiempo que una solicitud saludable con una entrada similar.
La solicitud defectuosa no paga todo el costo por sí sola. El resto de la cola también lo termina pagando.
Un fallo pequeño que ralentiza todo el sistema
El equipo detrás de DharmaOCR observó este comportamiento mientras evaluaba un modelo especializado en OCR para documentos PDF. En uno de los experimentos, menos del 3% de las páginas generó secuencias degeneradas, pero esas solicitudes consumieron cerca de la mitad del tiempo total de procesamiento.
Al reemplazar las solicitudes degeneradas por otras de duración promedio, el tiempo total de inferencia bajó de 7,3 minutos a 4,2 minutos. Según el análisis, los bucles habían inflado el tiempo de ejecución del lote en 42,47%.
La explicación está en cómo funcionan los servidores modernos de inferencia. Herramientas como vLLM agrupan múltiples solicitudes en lotes dinámicos y utilizan memoria paginada para servirlas en paralelo. A medida que una secuencia genera más tokens, también ocupa más memoria.
Cuando una solicitud entra en un bucle y se acerca al límite de tokens, consume una parte desproporcionada de los recursos disponibles durante demasiado tiempo. El planificador tiene menos espacio para incorporar nuevas solicitudes al lote. Disminuye el paralelismo y cae el rendimiento general.
En las pruebas con tres conjuntos de datos, la duración promedio de las solicitudes saludables aumentó al menos 15% cuando compartían la máquina con una secuencia degenerada. En uno de los conjuntos, el aumento superó el 71%.
La solicitud saludable no se había vuelto más difícil. El sistema que la atendía se había vuelto más lento.
Por qué ocurre la degeneración de texto
La causa está relacionada con el objetivo de entrenamiento más común en los modelos de lenguaje: la máxima verosimilitud. Durante el entrenamiento, el modelo aprende a asignar una alta probabilidad al token que aparece después en los datos de referencia.
Este proceso funciona muy bien para aprender continuaciones. Pero el modelo no evalúa directamente si la secuencia completa que generará es coherente o si terminará de forma natural. Solo intenta predecir el siguiente token en cada paso.
En ciertas regiones de la distribución de probabilidad, los tokens o fragmentos que ya aparecieron en el contexto reciente pueden volverse todavía más probables. El modelo repite una parte, esa repetición refuerza la probabilidad de volver a producirla y el ciclo continúa.
El token EOS, que permitiría cerrar la respuesta, queda con una probabilidad muy baja frente al fragmento repetido. El resultado es un bucle que solo termina cuando interviene algo externo, como el límite de tokens, una interrupción del streaming o el agotamiento de la memoria disponible para la secuencia.
La investigación de Holtzman y sus colaboradores describió este fenómeno en 2020. Desde entonces, distintas estrategias de decodificación han intentado reducirlo: ajustar la temperatura, usar top-p, aplicar penalizaciones de repetición o modificar la búsqueda de haces.
Estas técnicas pueden disminuir la probabilidad de entrar en un bucle. Pero no eliminan la región problemática de la distribución que el modelo aprendió durante su entrenamiento.
Los benchmarks no están midiendo este costo
El análisis plantea una pregunta incómoda: si la degeneración puede reducir de manera importante el rendimiento de producción, ¿por qué no aparece como métrica estándar en las evaluaciones de modelos?
La respuesta probable es que la mayoría de los benchmarks se concentra en la calidad promedio de las respuestas. Miden precisión, reconocimiento o similitud con una referencia, pero suelen dejar fuera los casos patológicos y sus consecuencias sobre el sistema.
Eso puede llevar a comparaciones incompletas. Dos modelos pueden obtener puntuaciones de calidad muy parecidas y, aun así, tener tasas de degeneración completamente diferentes. El modelo con la puntuación ligeramente superior no necesariamente será la mejor opción para producción si consume mucho más tiempo y memoria.
En el experimento, la versión base de Qwen2.5-VL-7B-Instruct registró una tasa de degeneración de 2,42%. Aunque parece una cifra pequeña, fue suficiente para causar un impacto considerable en el tiempo total de procesamiento.
Por eso, la propuesta es tratar la tasa de degeneración como una métrica de primera clase, junto con:
- Calidad de salida.
- Latencia.
- Throughput o solicitudes procesadas por unidad de tiempo.
- Consumo de memoria y costo de inferencia.
- Porcentaje de solicitudes que alcanzan el límite máximo de tokens con repetición al final.
Detectarlo en tiempo real ayuda, pero no basta
Una respuesta común consiste en detectar la repetición mientras se genera el texto, cancelar la solicitud y volver a intentarlo con otra configuración o modelo. Esta estrategia puede proteger al sistema frente a los casos más visibles.
Sin embargo, tiene límites. El detector debe ejecutarse sobre todas las salidas, incluidas las que son normales, así que añade consumo de cómputo y puede aumentar la latencia. Además, los reintentos multiplican el costo de las solicitudes afectadas.
Hay otro riesgo: no toda repetición es un error. Un documento puede contener listas, términos legales o frases repetidas de forma legítima. Una regla demasiado agresiva puede cancelar respuestas correctas, mientras que una regla demasiado flexible puede dejar pasar un bucle.
La capa de inferencia puede contener el problema, pero no elimina el cómputo que ya se gastó ni modifica la causa que lo produce. Si el fallo nace en la distribución aprendida por el modelo, una solución más completa debe actuar durante el entrenamiento.
DPO reduce los bucles desde el modelo
El trabajo evaluó un proceso de dos etapas. Primero, se aplicó supervised fine-tuning, o SFT, con ejemplos alineados al dominio del OCR. Esta etapa mejora la capacidad del modelo para resolver la tarea, pero no siempre elimina los patrones degenerados heredados del preentrenamiento.
Después se utilizó Direct Preference Optimization, conocido como DPO. En lugar de usar pares de respuestas generales, el equipo construyó ejemplos donde la respuesta rechazada era una generación degenerada del propio modelo y la respuesta elegida era una salida saludable.
Así, el entrenamiento no solo enseñó al modelo qué respuesta preferir. También lo empujó lejos de las regiones probabilísticas asociadas con sus propios fallos.
Los resultados fueron relevantes: en cinco familias de modelos de entre 3.000 y 7.000 millones de parámetros, DPO redujo la degeneración entre 37% y 87% frente a utilizar SFT por sí solo.
El caso más destacado correspondió a un modelo de 3.000 millones de parámetros, Nanonets-OCR2, cuya tasa bajó de 1,61% a 0,20%, una reducción del 87,6%. En modelos generales de alrededor de 7.000 millones de parámetros, las reducciones estuvieron entre 37% y 56%, con un promedio de 59,4% entre las familias evaluadas.
El historial de entrenamiento importa más que el tamaño
Una de las conclusiones más interesantes es que el modelo más grande no fue necesariamente el más estable. El modelo especializado más pequeño obtuvo la menor tasa de degeneración entre los modelos probados.
Esto sugiere que la estabilidad depende menos del número de parámetros y más de la distancia entre la historia de entrenamiento del modelo y la tarea que debe resolver. La especialización puede modificar no solo la calidad promedio, sino también la forma en que aparecen los fallos.
Para quienes despliegan modelos de lenguaje, la lección es práctica: no basta con preguntar cuál modelo obtiene la mejor puntuación en un benchmark. También hay que medir cuántas solicitudes entrañan bucles, cuánto tiempo ocupan y cómo afectan a las demás solicitudes que comparten la GPU.
La degeneración de texto no es un problema futurista ni una rareza académica. Puede aparecer en sistemas reales de OCR, asistentes, extracción estructurada y generación de contenido. Si no se registra, se convierte en un costo invisible dentro de la cola de procesamiento.
Medirla requiere datos que los servidores ya suelen producir. Reducirla puede requerir mejores estrategias de entrenamiento, no solo ajustes del decodificador. Y evaluarla junto con la calidad permitiría tomar decisiones de despliegue mucho más cercanas a la realidad operativa.
Fuente original
https://huggingface.co/blog/Dharma-AI/text-degeneration-a-production-failure-mode-that-m