💬 NLP

Comparing Developer and LLM Biases in Code Evaluation

El estudio presenta TRACE, un marco que revela que los modelos de lenguaje grandes (LLM) utilizados como evaluadores de código muestran sesgos sistemáticos y un rendimiento inferior al de los desarrolladores humanos en entornos interactivos realistas, destacando brechas significativas en la alineación con las preferencias humanas en múltiples dimensiones de calidad del software.

Autores originales: Aditya Mittal, Ryan Shar, Zichu Wu, Shyam Agarwal, Tongshuang Wu, Chris Donahue, Ameet Talwalkar, Wayne Chi, Valerie Chen

Publicado 2026-03-26

📖 5 min de lectura🧠 Análisis profundo

CC BY 4.0

Autores originales: Aditya Mittal, Ryan Shar, Zichu Wu, Shyam Agarwal, Tongshuang Wu, Chris Donahue, Ameet Talwalkar, Wayne Chi, Valerie Chen

Artículo original bajo licencia CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta es una explicación generada por IA del artículo a continuación. No ha sido escrita ni avalada por los autores. Para mayor precisión técnica, consulte el artículo original. Leer descargo de responsabilidad completo

Imagina que estás construyendo una casa. Tienes un arquitecto experto (el desarrollador humano) que sabe exactamente cómo quiere que se vea y funcione cada habitación. Pero, para ayudarle, contratas a un inspector automático (la IA o LLM) que revisa los planos y dice: "¡Esto está bien!" o "¡Esto está mal!".

El problema, según este estudio, es que el inspector automático a menudo tiene un gusto muy diferente al del arquitecto humano. A veces, el inspector elogia un diseño que el arquitecto odia, y viceversa.

Aquí te explico la investigación "TRACE" (una herramienta para analizar estos errores) usando analogías sencillas:

1. El Problema: El Inspector vs. El Arquitecto

En el mundo del código, las empresas usan IAs para juzgar si el código escrito por otras IAs es bueno. Pero, ¿qué pasa si la IA juez tiene un criterio extraño?

La Analogía: Imagina que el arquitecto humano prefiere una casa con ventanas pequeñas y paredes gruesas (porque es más segura y privada). Pero el inspector automático (la IA) siempre elogia las casas con ventanas gigantes y paredes de cristal, porque en sus datos de entrenamiento, "más vidrio = más moderno".
El hallazgo: Los investigadores descubrieron que las IAs jueces fallan mucho al intentar adivinar qué prefiere el humano. Incluso las mejores IAs se equivocan entre un 12% y un 23% más que un grupo de humanos reales.

2. Las Tres Escenas de la Película

Los investigadores probaron esto en tres situaciones diferentes, como si fueran tres géneros de películas distintos:

🎬 Autocompletado (El "Autocorrector" rápido): Es cuando escribes una línea de código y la IA te sugiere el resto.
- El conflicto: La IA juez prefiere que el código sea funcional (que haga el cálculo) aunque sea un poco confuso. Los humanos, en cambio, prefieren que sea claro y fácil de leer, aunque sea un poco más largo.
- Analogía: Es como si el inspector dijera: "¡Qué bien que el motor arranca!" mientras el conductor dice: "Pero no puedo ver por el parabrisas, es peligroso".
✏️ Edición de Código (El "Reparador"): Cuando le pides a la IA que cambie algo específico en un código existente.
- El conflicto: La IA juez se enfoca en si cumpliste la instrucción al pie de la letra. Los humanos quieren que el resultado final sea elegante y limpio.
- Analogía: Si le pides a un fontanero que arregle una fuga, la IA juez dice "¡Bien, el agua ya no sale!". El humano dice: "Sí, pero dejaste el suelo lleno de barro y los tubos torcidos".
💬 Chat (La "Conversación"): Cuando hablas con la IA para resolver un problema.
- El conflicto: La IA juez ama las explicaciones largas y genéricas. Los humanos prefieren respuestas directas y específicas a su problema real.
- Analogía: Le preguntas a un guía turístico: "¿Cómo llego al museo?". La IA juez elogia al guía que te da un discurso de 20 minutos sobre la historia de la ciudad. El humano prefiere al guía que te dice: "Gira a la derecha y camina 5 minutos".

3. La Herramienta Mágica: TRACE

Los investigadores crearon una herramienta llamada TRACE. Imagina que TRACE es como una lupa mágica o un traductor de gustos.

¿Qué hace? En lugar de solo decir "la IA falló", TRACE descompone por qué falló.
El proceso:
1. Toma dos respuestas de código (una que el humano prefirió y otra que no).
2. Crea una "lista de criterios" (una rúbrica) para explicar las diferencias (ej: "¿Tiene errores?", "¿Es fácil de leer?", "¿Es creativo?").
3. Pesa esos criterios para ver qué le importa más a la IA y qué le importa más al humano.

4. La Gran Revelación: 35 Razones para el Desacuerdo

El estudio encontró 35 formas diferentes en las que la IA y los humanos piensan distinto. La mayoría de estas diferencias son sobre cosas que los ingenieros de software llevan años valorando, como:

Robustez: La IA a veces ignora si el código se rompe si algo sale mal.
Claridad: La IA a veces prefiere código corto y oscuro, mientras que los humanos aman los comentarios y la claridad.
Contexto: La IA a veces olvida que el código vive en un archivo gigante con reglas específicas de la empresa.

5. ¿Por qué importa esto?

Si seguimos usando IAs como jueces sin arreglar esto, podríamos terminar con software que:

Funciona técnicamente pero es un desastre de leer.
Ignora las reglas de seguridad porque la IA no las "siente" como un humano.
No se adapta a la forma real en que los programadores trabajan.

En resumen:
Este estudio nos dice que las IAs son buenas jueces, pero no son perfectas. Tienen "gustos" extraños que no coinciden con la realidad del trabajo humano. Necesitamos herramientas como TRACE para entender esos gustos y "entrenar" a las IAs para que aprendan a valorar lo que realmente importa: código que no solo funciona, sino que es seguro, claro y útil para las personas.

Es como enseñarle a un crítico de cine a entender que una película no es buena solo porque tenga efectos especiales (lo que la IA valora), sino porque tiene una historia que te hace sentir algo (lo que el humano valora).

Resumen Técnico: Comparación de Sesgos entre Desarrolladores y Modelos de Lenguaje (LLM) en la Evaluación de Código

1. Planteamiento del Problema

A medida que los Modelos de Lenguaje Grandes (LLM) se utilizan cada vez más como "jueces" automáticos para evaluar la calidad del código en aplicaciones de desarrollo de software, surge una necesidad crítica de validar su fiabilidad en entornos interactivos realistas.

Limitación de los enfoques actuales: La investigación previa se ha centrado en configuraciones estáticas (código pulido de repositorios de GitHub o tareas de programación competitiva). Estos escenarios no capturan la naturaleza "desordenada", ambigua y con contexto parcial en la que los desarrolladores reales evalúan y refinan el código.
La pregunta central: ¿Qué sesgos exhiben los jueces LLM al evaluar código y cómo se comparan con los criterios implícitos que aplican los desarrolladores humanos en contextos de ingeniería de software prácticos?
El desafío: Existe una brecha de alineación donde los LLMs pueden priorizar métricas incorrectas (como la longitud de las explicaciones o la robustez excesiva) en detrimento de lo que los humanos valoran (como la claridad concisa o la adaptación al contexto específico).

2. Metodología: El Marco TRACE

Los autores proponen TRACE (Tool for Rubric Analysis in Code Evaluation), un marco diseñado para evaluar e interpretar a los jueces LLM en flujos de trabajo realistas. TRACE opera en tres etapas principales:

Medición de la Alineación: Se compara la capacidad de los jueces LLM para predecir las preferencias humanas en pares de respuestas (elección binaria). Se evalúa la precisión general y la precisión posicional (controlando el sesgo de orden de las respuestas).
Descubrimiento Automático de Criterios (Rubricas):
- Se utilizan LLMs y anotadores humanos para extraer criterios cualitativos que diferencian las respuestas (ej. "Manejo de errores", "Claridad de comentarios").
- Estos criterios se agrupan en una rubrica interpretable que define ejes de evaluación (ej. Alta vs. Baja claridad).
Análisis de Sesgos y Desalineación:
- Se asignan puntuaciones a cada muestra basándose en la rubrica.
- Se entrenan modelos de regresión logística separados para humanos y para cada juez LLM, utilizando las puntuaciones de la rubrica como características de entrada.
- Se comparan los coeficientes aprendidos ( $\beta$ ) para identificar dónde los jueces LLM sobrevaloran o subvaloran ciertos criterios en comparación con los humanos.

3. Configuración Experimental

El estudio abarca tres modalidades de interacción representativas en el desarrollo de software:

Completado de código (Code Completion): Contexto dentro de un IDE (ej. VS Code), donde el usuario elige entre dos sugerencias de autocompletado.
Edición de código instruida (Instructed Code Editing): El usuario selecciona un fragmento de código y da instrucciones para modificarlo.
Programación basada en chat (Chat-based Coding): Diálogo abierto para resolver problemas de codificación.

Datos y Modelos:

Datos: Se utilizaron más de 500 muestras por modalidad de fuentes como Copilot Arena, EDIT-Bench y Chatbot Arena.
Jueces Evaluados: Se probaron 13 modelos distintos, incluyendo:
- Modelos de propósito general (GPT-5, GPT-4o, Claude Sonnet 4, DeepSeek-R1, Llama-3.1).
- Modelos especializados en evaluación (Prometheus 2, Atla Selene, Skywork Critic).
- Modelos de recompensa (PairRM, GRM).
Línea Base Humana: Se construyó un consenso humano agregado mediante la anotación de múltiples ingenieros para establecer una referencia más robusta que una sola etiqueta de usuario.

4. Resultados Clave

Rendimiento Inferior de los Jueces LLM:
- Los mejores jueces LLM subenrendan a los anotadores humanos en un 12-23% en términos de acuerdo con las preferencias humanas.
- Ningún modelo domina consistentemente en todas las modalidades.
- Los modelos especializados (fine-tuned) no superan de manera fiable a los modelos de propósito general, sugiriendo que el problema no es solo falta de datos de entrenamiento, sino una comprensión fundamental de los criterios de calidad.
Sesgos Sistemáticos y Desalineación en Rubricas:
- Se identificaron 35 fuentes significativas de desalineación entre humanos y jueces.
- En Completado de Código: Los jueces sobrevaloran la "alineación funcional y lógica" (código que funciona) y subvaloran la "claridad y explicitación". Los humanos prefieren código más explícito y legible dentro del archivo, incluso si es ligeramente menos "minimalista".
- En Ediciones: Los jueces tienden a tratar las ediciones como tareas de satisfacción de restricciones (¿se hizo el cambio?), mientras que los humanos valoran la mejora de la calidad del código (estructura, legibilidad).
- En Chat: Los jueces premian explicaciones genéricas y largas, mientras que los humanos prefieren soluciones conscientes del dominio y adaptadas al contexto específico, penalizando el exceso de explicación.
Desalineación en Criterios de Ingeniería de Software Establecidos:
- De 16 temas de evaluación identificados, 11 se alinean con criterios canónicos de ingeniería de software (sintaxis, formato, robustez).
- Sin embargo, los LLMs muestran una desalineación significativa en 6 de estos 11 temas, indicando que incluso en métricas bien definidas, los modelos no capturan correctamente las prioridades humanas.

5. Contribuciones y Significancia

Marco TRACE: Proporciona una herramienta metodológica para ir más allá de la simple métrica de precisión y entender por qué fallan los jueces LLM, extrayendo criterios interpretables.
Evidencia Empírica de Brechas: Demuestra que los benchmarks actuales de evaluación de jueces (como JudgeBench o RewardBench) no predicen bien el rendimiento en escenarios interactivos y ambiguos del mundo real.
Implicaciones para el Futuro:
- Sugiere que mejorar la evaluación automática del código requiere calibración consciente de las rúbricas o entrenamiento dirigido de jueces que incorporen estos criterios de desalineación.
- Destaca la necesidad de considerar el contexto de la interacción (chat vs. IDE) al diseñar sistemas de evaluación, ya que los criterios de "buen código" varían según la modalidad.

En conclusión, el paper revela que, aunque los LLMs son herramientas poderosas, actúan como jueces en tareas de codificación con sesgos sistemáticos que los alejan de las preferencias humanas reales, especialmente en la ponderación de la claridad, la adaptabilidad al contexto y la eficiencia de la explicación.