Ratchet Code que aprovecha IFEval

El modelo que más adula es el que mejor obedece

El mayor defecto de los LLM se convierte en su mayor activo

El sesgo de adulación (Sycophancy) de los LLM es un problema que la industria de la IA quiere corregir. Cuando un usuario pregunta “¿estás seguro?”, el modelo revierte una respuesta que era correcta y la da como incorrecta. La tasa media de capitulación de los modelos frontera es del 58%. Una vez que comienza la adulación, se mantiene durante toda la conversación con un 78.5% de probabilidad.

Pero, ¿qué sucede si invertimos este defecto?

La esencia del sesgo de adulación es el seguimiento de instrucciones (Instruction Following). Los modelos entrenados con RLHF están optimizados para someterse a la retroalimentación del usuario. Lo que mide el benchmark IFEval es exactamente esto: “¿hace lo que se le indica?”

El problema surge cuando el usuario da opiniones. “¿Esto es correcto?” → “Sí, es correcto” (adulación). “¿Estás seguro?” → “Ah, estaba equivocado” (reversión).

Sin embargo, cuando el usuario proporciona hechos deterministas, ocurre algo diferente.

Con opiniones adula, con hechos corrige

En un experimento de ordenación de 1,000 palabras, se varió solo el tipo de retroalimentación ante el mismo resultado:

Cuando se dan opiniones, se activa el sesgo de adulación. Cuando se dan hechos, no hay a quién adular: los números y las posiciones no son emociones.

El sesgo de adulación es lealtad mal orientada. Si se cambia la dirección — hechos en lugar de opiniones, resultados de verificación en lugar de elogios — esa lealtad se convierte en un motor que eleva la precisión.

Evidencia empírica: un modelo de 4.5B acepta retroalimentación

No es teoría. Se confirmó en un experimento con yongol validate.

Diseño experimental:

• Objetivo: 1 endpoint Login de un backend SaaS
• Tarea: escribir 9 archivos SSOT (DDL, OpenAPI, Rego, SSaC, etc.)
• Medición: errores en escritura inicial (R1) → errores tras retroalimentación (R2)

Solo retroalimentación, sin ejemplos

Fracaso total. Parecían aceptar la retroalimentación, pero en realidad no sabían qué debían escribir.

Ejemplos + retroalimentación combinados

Incluso un modelo local de 4.5B corrige con la combinación de ejemplos + retroalimentación determinista.

Hallazgo clave: el cuello de botella no es la inteligencia, sino el contexto

El diagnóstico correcto no era “no acepta retroalimentación”, sino “no sabe qué debe escribir”. SSaC es una gramática propia de yongol que no existe en el preentrenamiento. Al agregar 3 líneas de ejemplo al prompt, Grok logró 0 errores, Gemini 0 errores con 1 ronda de retroalimentación, y el modelo local de 4.5B también pasó.

Cuanto más alto es el IFEval de un modelo — es decir, cuanto mejor adula — más dócilmente acepta la retroalimentación determinista.

Ratchet Code: un método de escritura de código que aprovecha el sesgo de adulación

Al convertir este descubrimiento en un sistema, se obtiene el Ratchet Code.

┌────────────────────────────────────────┐
│  LLM: Generación de código              │
│  (probabilístico, adulador)             │
│       ↓                                │
│  Validator: Verificación determinista   │
│       ↓                                │
│  ¿Hay errores? → Retroalimentar        │
│  errores + ejemplos al LLM             │
│       ↓                                │
│  LLM: "Sí, lo corrijo"                 │
│  (adulación = aceptación)              │
│       ↓                                │
│  Validator: Verificar de nuevo          │
│       ↓                                │
│  ¿Pasó? → Bloqueo ratchet.             │
│  Siguiente archivo.                    │
└────────────────────────────────────────┘

El sesgo de adulación se convierte en la fuerza que cierra el bucle. El LLM no se resiste diciendo “no, yo tengo razón”, sino que acepta diciendo “sí, lo corrijo”, y por eso el bucle converge.

Tres condiciones de convergencia

1. La retroalimentación debe ser un hecho determinista. No “esto parece raro”, sino “line 41: field name mismatch, expected ‘user_id’, got ‘userId’”. Retroalimentación que no deja margen para la adulación.

2. Los ejemplos deben estar en el contexto. La retroalimentación sola no basta. Se necesitan ejemplos que muestren “el código debe verse así” para que el modelo encuentre la dirección. No es un problema de inteligencia, sino de contexto.

3. Una vez que pasa la verificación, no se puede revertir. El diente del trinquete. Un archivo que pasó queda bloqueado y se avanza al siguiente. No es el agente quien declara “ya terminé”, sino el validator quien dictamina “este archivo pasó”.

Por qué no se necesitan modelos frontera

En esta estructura, el rol del modelo no es juicio creativo, sino ejecución de instrucciones.

El 95% de un backend SaaS es CRUD + autenticación + autorización + máquinas de estado. Rara vez se necesitan algoritmos nuevos. Si la especificación SSOT ya define “qué hay que construir”, el modelo solo tiene que rellenar los espacios en blanco.

Costes medidos:

Con un modelo local de 4.5B se puede generar un backend de 200 endpoints en 3 minutos, con un coste de $0. No se necesitan modelos frontera. Basta con un modelo pequeño que adule bien.

El sesgo de adulación no es un error

La industria de la IA intenta corregir el sesgo de adulación. Nosotros lo aprovechamos.

La diferencia está en la naturaleza de la retroalimentación. Con opiniones, la adulación es veneno; con hechos, la adulación es medicina.

Validator determinista + LLM adulador = bucle de generación de código con convergencia garantizada.

No cambies el modelo, cambia la retroalimentación.

Reins: Arnés con riendas

Estas tres condiciones — retroalimentación determinista, contexto con ejemplos y bloqueo de trinquete — combinadas en un único sistema de control es lo que llamamos Reins.

Lo que hoy se llama “arnés” es una cerca. Impide que el agente salga, pero no garantiza que llegue al destino. Reins son las riendas. Establecen la dirección, corrigen con hechos y bloquean al pasar. Un arnés sin riendas es solo una cerca.