Gauge dependence and structured-output corruption in sign-branched repetition penalties: measurements across models, inference stacks, and alternative repetition controls

Resumen Técnico: Dependencia de la Calibración y Corrupción de Salida Estructurada en las Penalizaciones de Repetición con Ramificación de Signo

Planteamiento del Problema
El artículo identifica un fallo fundamental en la penalización de repetición multiplicativa ampliamente desplegada en el ecosistema de inferencia de LLM (incluyendo Hugging Face, vLLM y llama.cpp). El operador estándar, heredado del modelo CTRL, aplica una penalización a los tokens previamente vistos mediante una ramificación basada en el signo de sus logits brutos: dividiendo los logits positivos por un factor $\theta$ y multiplicando los logits negativos por $\theta$.

El problema central es que la ubicación del punto cero del logit es arbitraria. La función softmax es invariante al desplazamiento ($\text{softmax}(z+c) = \text{softmax}(z)$), lo que significa que el objetivo de entrenamiento de un modelo restringe la distribución de probabilidad pero deja sin restringir los valores absolutos de los logits (la "calibración" o gauge). En consecuencia, la rama de signo de la penalización opera sobre una coordenada que el proceso de entrenamiento no fija. Esto conduce a dos consecuencias negativas medibles:

1. Comportamiento Indefinido: Un ajuste de penalización de repetición fijo (por ejemplo, $\theta=1.3$) realiza una operación matemática diferente en diferentes modelos (o incluso en el mismo modelo con un sesgo desplazado), ya que la fracción de tokens que caen en la rama de "división" frente a la de "multiplicación" varía drásticamente según el punto cero del logit del modelo.
2. Corrupción de Salida Estructurada: La penalización suprime indiscriminadamente tokens que son requeridos por la gramática (por ejemplo, llaves de cierre en JSON, indentación en código) simplemente porque han aparecido antes. Esto causa una caída catastrófica en la validez de las salidas estructuradas.

Metodología
Los autores llevan a cabo una serie de experimentos controlados a través de cinco modelos (que van desde gpt2 hasta Qwen2.5-7B, incluyendo variantes base y RLHF) y dos pilas de inferencia (vLLM y llama.cpp) para aislar el efecto de la ramificación de signo.

• Experimento de Cambio de Calibración (Consecuencia 1): Los autores decodifican el mismo modelo dos veces con semillas aleatorias e inputs idénticos, pero añadiendo una constante $c$ a todos los logits (simulando un desplazamiento en el sesgo del modelo). Para una intervención bien definida, la selección de tokens greedy debería permanecer idéntica. Miden la "tasa de cambio" (fracción de posiciones donde el token difiere) con $\theta=1.3$ en comparación con los controles (penalizaciones sustractivas y penalizaciones normalizadas).
• Evaluación de Salida Estructurada (Consecuencia 2): Los autores evalúan el impacto de la penalización en dos tareas:
  • HumanEval: Generación de código donde se requieren delimitadores específicos.
  • JSONSchemaBench: Generación de objetos JSON contra 200 esquemas del mundo real.
    Miden la tasa de salida válida y conforme al esquema y la frecuencia de "cambios de delimitador" (donde un token estructural requerido es suprimido incorrectamente).
• Verificación de la Interoperabilidad entre Pilas: Los experimentos se replican en vLLM y llama.cpp utilizando sus samplers nativos para confirmar que el problema es inherente a la implementación del operador en todo el ecosistema.
• Propuesta de Solución: Los autores prueban una variante donde la penalización se aplica a los log-probabilidades normalizadas ($\log p_i$) en lugar de a los logits brutos ($z_i$), eliminando efectivamente la ramificación de signo, dado que todas las log-probabilidades son no positivas.

Resultos Clave

• Dependencia de la Calibración: La penalización estándar de ramificación de signo es altamente sensible al punto cero del logit.
  • A través de cinco checkpoints reales, la fracción de tokens vistos con logits positivos (y, por tanto, divididos) varía de 0.17 (gpt2) a 0.95 (Qwen2.5-Coder-7B).
  • En el experimento controlado de cambio, desplazar el punto cero del logit por una constante de $\pm 5$ provoca que la penalización estándar cambie entre el 58% y el 96% de los tokens greedy con $\theta=1.3$. En contraste, las penalizaciones sustractivas y normalizadas muestran una tasa de cambio del 0%.
  • El "coste" de la intervención (medido en log-verosimilitud) varía por un factor de 4.1 dependiendo de la calibración, mientras que los controles permanecen constantes.
• Fallo de Salida Estructurada: La penalización degrada severamente la generación estructurada.
  • En JSONSchemaBench, aplicar $\theta=1.3$ reduce la tasa de salida JSON válida del 97% al 23%.
  • En HumanEval, la penalización causa cambios en tokens estructurales con una precisión equilibrada de 0.999 contra una predicción teórica, confirmando que el mecanismo es impulsado por la penalización que suprime los delimitadores necesarios.
• Prevalencia en el Ecosistema: Se encuentra la implementación de ramificación de signo en Hugging Face, vLLM, llama.cpp y otros doce motores (ej. TGI, SGLang, Ollama). El problema no es un caso aislado de una sola librería, sino un artefacto sistémico del diseño del operador.
• Efectividad de la Normalización: Aplicar la penalización a las log-probabilidades normalizadas ($\log \text{softmax}(z)$) elimina ambos efectos.
  • La tasa de cambio de calibración cae a 0.00.
  • La validez de JSON con $\theta=1.3$ se recupera al 97%.
  • La corrupción de delimitadores disminuye aproximadamente 80 veces.

Significancia y Reivindicaciones
El artículo argumenta que la penalización de repetición multiplicativa por defecto no es un "control escalar limpio", sino una intervención en tiempo de inferencia cuyo comportamiento está parcialmente determinado por un artefacto de entrenamiento no restringido (el punto cero del logit).

• Falta de Portabilidad: Un valor de $\theta$ fijo no representa la misma operación en diferentes modelos, lo que hace necesaria la sintonización por modelo y por tarea, incluso para un parámetro "estándar".
• Consecuencias No Deseadas: La penalización corrompe la salida estructurada al tratar las necesidades gramaticales (que deben repetirse) como repeticiones no deseadas, un modo de fallo que es particularmente agudo en la generación de código y JSON.
• Solución: Los autores demuestran que normalizar los logits antes de aplicar la penalización (o usar penalizaciones sustractivas) elimina tanto la dependencia de la calibración como la corrupción de la salida estructurada. Observan que Hugging Face ya incluye un operador de LogitNormalization, pero actualmente está desactivado por defecto y se aplica después de la penalización, lo que no resuelve el problema.

El artículo concluye que, si bien las penalizaciones de repetición son soluciones provisionales necesarias para el comportamiento del modelo, la implementación estándar actual introduce "bordes afilados" que comprometen la fiabilidad. Los autores instan a los mantenedores de las pilas a adoptar la familia de penalizaciones sustractivas o a reordenar la penalización multiplicativa para que opere sobre log-probabilidades normalizadas.