Measuring LLM Trust Allocation Across Conflicting Software Artifacts

1. El Problema

Los asistentes de ingeniería de software basados en Modelos de Lenguaje Grande (LLM) no solo fallan al generar salidas incorrectas, sino que también fallan al asignar confianza a los artefactos equivocados cuando existen discrepancias entre el código, la documentación y las pruebas.

• La brecha actual: Las evaluaciones existentes se centran principalmente en los resultados de tareas posteriores (por ejemplo, si una afirmación de prueba generada es correcta). Esto oculta el proceso de razonamiento: no revela si el modelo reconoció evidencia degradada, identificó la fuente no fiable o calibró su confianza adecuadamente entre artefactos contradictorios.
• El riesgo: Un modelo puede producir una salida que parece razonable basándose en la fuente incorrecta (por ejemplo, confiar en una documentación obsoleta en lugar del código real), haciendo que estos fallos sean difíciles de detectar solo observando el resultado final.

2. Metodología: El Marco TRACE

Para abordar este problema, los autores presentan TRACE (Trust Reasoning over Artifacts for Calibrated Evaluation), un marco diseñado para elicitar y evaluar trazas de razonamiento estructuradas a nivel de artefacto.

Diseño del Experimento

• Conjunto de Datos: Se construyó un banco de pruebas con 456 bundles de métodos Java curados de 25 sistemas reales.
• Perturbaciones Controladas: Para cada muestra base, se generaron 6 variantes de degradación (perturbaciones) para crear un total de 3,192 instancias de evaluación. Estas incluyen:
  • Eliminación de partes de la documentación (descripción, etiquetas @return).
  • Inyección de errores semánticos en la documentación (bug_doc).
  • Inyección de errores en la implementación (bug_MUT).
  • Creación de contradicciones directas entre la documentación y la implementación.
  • Niveles de severidad: Pesado (H), Normal (N) y Sutil (S).
• Modelos Evaluados: Se probaron 7 modelos de diferentes proveedores (Anthropic, OpenAI, DeepSeek, xAI) bajo un protocolo de perturbación ciega (el modelo no sabe qué artefacto fue alterado ni la severidad).
• Salidas Estructuradas (Trazas): En lugar de pedir solo código, se solicitó al modelo que generara una traza JSON que incluyera:
  1. Evaluación de calidad por artefacto: Puntuación de fiabilidad para Javadoc, firma, implementación (MUT) y prefijo de prueba.
  2. Análisis de inconsistencias: Detección de conflictos y atribución del artefacto culpable.
  3. Priorización de fuentes: Un ordenamiento de qué fuente confiar más.

3. Contribuciones Clave

1. Formalización del Razonamiento de Confianza: TRACE trata el razonamiento sobre la calidad de los artefactos como un objetivo de predicción de primer nivel, no solo como un paso intermedio para una tarea final.
2. Benchmarks de Perturbación con Proveniencia: Creación de un conjunto de datos anotado con "proveniencia" de los errores, permitiendo evaluar si el modelo no solo detecta el error, sino que lo atribuye correctamente a la fuente modificada.
3. Estudio a Gran Escala: Análisis de 22,339 trazas válidas a través de 7 modelos, revelando patrones de sensibilidad asimétrica y puntos ciegos sistemáticos.

4. Resultados Principales

RQ1: Sensibilidad a la Calidad de Entrada

• Localización: Las penalizaciones en las puntuaciones de calidad se concentran principalmente en el artefacto perturbado, con poco "desbordamiento" a otros artefactos.
• Asimetría Documentación vs. Código: Los modelos son mucho más sensibles a los errores en la documentación natural (Javadoc) que a los errores sutiles en el código.
  • La brecha entre errores "pesados" y "sutiles" es de 0.152–0.253 para bugs de documentación, frente a solo 0.049–0.123 para bugs de implementación.
• Conclusión: Los LLM actúan como auditores más efectivos de especificaciones en lenguaje natural que de defectos de código finos.

RQ2: Detección de Inconsistencias (Javadoc vs. MUT)

• Detección de Errores Explícitos: Los modelos detectan bien los errores explícitos en la documentación (67–94%) y las contradicciones directas (50–91%).
• El "Punto Ciego" de Implementación (MUT_Only): Existe una falla sistemática grave: cuando solo la implementación cambia y la documentación sigue siendo plausible, la tasa de detección cae entre 7 y 42 puntos porcentuales en comparación con cuando ambos cambian. Los modelos tienden a confiar ciegamente en la documentación si esta parece correcta.
• Calibración de Confianza: La confianza expresada por los modelos está mal calibrada en 6 de los 7 modelos. Una alta confianza no garantiza una detección correcta.

RQ3: Comprensión Semántica del Código

• La variación en la fidelidad de las trazas entre modelos se explica principalmente por su comprensión semántica del código.
• Modelos Robustos: Sonnet, DeepSeek-V3.2 y Haiku mantienen un rendimiento estable incluso cuando las pistas superficiales desaparecen (errores sutiles).
• Modelos Superficiales: GPT-4o muestra un colapso drástico (caída de 44 pp) en errores sutiles, indicando que depende de coincidencias de patrones superficiales en lugar de razonamiento profundo sobre el comportamiento del código.
• Caso Opus: A menudo entiende la contradicción semánticamente pero falla al localizar el artefacto culpable (atribuye el error a la documentación cuando el código es el problema).

5. Significado e Implicaciones Prácticas

• Auditoría vs. Detección de Drift: Los LLM actuales son herramientas fiables para auditar la calidad de la documentación y detectar desviaciones de esta, pero no son confiables como detectores autónomos de cambios sutiles en el código (code drift) si la documentación no se actualiza.
• Uso en Pipelines de IA:
  • Fase de Triage: TRACE es útil como una etapa de pre-vuelo para filtrar artefactos de baja calidad antes de tareas críticas.
  • Selección de Modelos:
    • Para detección de contradicciones generales: Sonnet es la mejor opción.
    • Para errores sutiles de implementación: Sonnet, DS-V3.2 y Haiku son los más robustos.
    • Para explicación de errores (una vez detectados): Opus es superior, aunque falla en la localización inicial.
    • Para triaje basado en confianza: DeepSeek-V3.2 es el único con calibración significativa.
• Necesidad de Verificación Cruzada: Dado el "punto ciego" en la detección de cambios solo en el código, los flujos de trabajo de ingeniería de software no deben depender exclusivamente de la documentación para validar la corrección del código. Se requieren mecanismos explícitos de verificación de consistencia entre artefactos.

En resumen, el trabajo demuestra que la capacidad de un LLM para "saber en qué confiar" es asimétrica y depende fuertemente de su capacidad de comprensión semántica del código, sugiriendo que la evaluación de LLMs en ingeniería de software debe ir más allá de la precisión de la salida final para incluir el razonamiento sobre la calidad de los inputs.