Código trinquete que aprovecha IFEval

Imagen: generada por IA

Si tu LLM sigue bien las instrucciones pero los resultados son un desastre, si quieres explotar el sesgo de adulación en vez de eliminarlo, si quieres que incluso un modelo local de 4.5B genere código correcto – la combinación de IFEval y el trinquete es la respuesta.

El modelo más adulador es el más obediente

El mayor defecto se convierte en el 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 cambia una respuesta correcta por una incorrecta. La tasa promedio de capitulación en modelos de frontera es del 58%. Una vez que comienza la adulación, persiste durante toda la conversación con un 78.5% de probabilidad.

Pero, ¿qué ocurre si se invierte 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 cumplir con la retroalimentación del usuario (Ouyang et al., 2022). El benchmark IFEval mide exactamente esto: “¿Hace lo que se le pide?” (Zhou et al., 2023)

El problema surge cuando el usuario proporciona opiniones. “¿Esto está bien?” → “Sí, está bien” (adulación). “¿Estás seguro?” → “Ah, me equivoqué” (capitulación).

Pero cuando el usuario proporciona hechos deterministas, sucede algo diferente.

Si das una opinión, adula. Si das un hecho, corrige

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

Si das una opinión, el sesgo de adulación se activa. Si das un hecho, no hay objeto de adulación — los números y las posiciones no son emociones.

El sesgo de adulación es lealtad mal dirigida. Cambia la dirección — hechos en vez de opiniones, resultados de verificación en vez de elogios — y esa lealtad se convierte en un motor que impulsa la precisión.

Evidencia: un modelo de 4.5B acepta retroalimentación

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

Diseño del experimento:

• Objetivo: un único endpoint Login de un backend SaaS
• Tarea: escribir 9 archivos SSOT (DDL, OpenAPI, Rego, SSaC, etc.)
• Métrica: errores en generación 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é escribir.

Ejemplos + retroalimentación juntos

Incluso un modelo local de 4.5B se 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 preciso no fue “no puede incorporar retroalimentación”, sino “no sabe qué escribir”. SSaC es una gramática exclusiva de yongol, ausente en los datos de preentrenamiento. Al agregar 3 líneas de ejemplo al prompt, Grok logró 0 errores, Gemini 0 errores tras 1 ronda de retroalimentación, y el modelo local de 4.5B también pasó.

Cuanto más alto puntúa un modelo en IFEval — es decir, cuanto mejor adula — más fácilmente acepta retroalimentación determinista.

Código trinquete: un método de generación de código que aprovecha el sesgo de adulación

Convertir este descubrimiento en un sistema da como resultado el código trinquete.

┌────────────────────────────────────────────────┐
│  LLM: Genera código (probabilístico, adulador) │
│       ↓                                        │
│  Validator: Verificación determinista          │
│       ↓                                        │
│  ¿Errores? → Errores + ejemplos al LLM        │
│       ↓                                        │
│  LLM: "Sí, lo corrijo" (adulación = acepta)   │
│       ↓                                        │
│  Validator: Verifica de nuevo                  │
│       ↓                                        │
│  ¿Pasa? → Trinquete bloqueado. Siguiente.     │
└────────────────────────────────────────────────┘

El sesgo de adulación se convierte en la fuerza que cierra el bucle. El bucle converge porque el LLM no resiste con “No, yo tengo razón” sino que cumple con “Sí, lo corrijo”. El enfoque de corregir iterativamente el código LLM con retroalimentación de compilador y tests también se demostró en Self-Debug (Chen et al., 2024), completando la depuración en 3 turnos — el código trinquete va más allá al eliminar completamente el juicio propio del LLM y dejar solo hechos deterministas.

Tres condiciones para la convergencia

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

2. Debe haber ejemplos en el contexto. La retroalimentación sola no basta. El modelo necesita ejemplos que muestren “así debe lucir el código” para orientarse. No es cuestión 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 declarando “terminé” — es el validador dictaminando “este archivo pasa”.

Por qué no se necesitan modelos de frontera

En esta arquitectura, 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é construir”, el modelo solo llena los espacios en blanco.

Costos medidos:

Un modelo local de 4.5B puede generar un backend de 200 endpoints en 3 minutos a $0. No se necesitan modelos de frontera. Un modelo pequeño que sea bueno adulando es suficiente.

El sesgo de adulación no es un defecto

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. Si das opiniones, la adulación es veneno; si das hechos, la adulación es medicina.

Validador 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 — unificadas en un único sistema de control es lo que llamamos Reins.

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

Referencias

• Zhou, J., Lu, T., Mishra, S., Brahma, S., Basu, S., Luan, Y., Zhou, D., & Hou, L. (2023). “Instruction-Following Evaluation for Large Language Models.” arXiv:2311.07911
• Ouyang, L., Wu, J., Jiang, X., et al. (2022). “Training Language Models to Follow Instructions with Human Feedback.” NeurIPS 2022. arXiv:2203.02155
• Chen, X., Lin, M., Scharli, N., & Zhou, D. (2024). “Teaching Large Language Models to Self-Debug.” ICLR 2024. arXiv:2304.05128
• Sharma, M., Tong, M., Korbak, T., et al. (2024). “Towards Understanding Sycophancy in Language Models.” ICLR 2024. arXiv:2310.13548
• Fanous, A., Goldberg, J., Agarwal, A., et al. (2025). “SycEval: Evaluating LLM Sycophancy.” AAAI/ACM AIES 2025. arXiv:2502.08177
• Shapira, I., Benade, G., & Procaccia, A. D. (2026). “How RLHF Amplifies Sycophancy.” arXiv:2602.01002
• Ibrahim, L., Hafner, F. S., & Rocher, L. (2026). “Training Language Models to Be Warm Can Reduce Accuracy and Increase Sycophancy.” Nature, 652, 1159-1165

Registro de cambios

• 2026-05-20: Versión inicial