Resumen Técnico: LibEvoBench

Declaración del Problema

El desarrollo de software moderno depende en gran medida de librerías de terceros que evolucionan de forma independiente, lo que a menudo resulta en bases de código de producción ancladas a versiones antiguas mientras las API continúan cambiando. Esto crea un "contexto de desarrollo específico de la versión" donde la corrección de una llamada a una API no depende de la librería en general, sino de la versión exacta especificada en el manifiesto de dependencias del proyecto.

Los Grandes Modelos de Lenguaje (LLM) actuales son entrenados con corpus temporalmente mixtos que agregan código y documentación de múltiples versiones de una librería simultáneamente. El objetivo de entrenamiento comprime este material heterogéneo en un único conjunto de pesos sin mecanismos explícitos de estratificación temporal. En consecuencia, los LLM tienen dificultades con el razonamiento específico de la versión, lo que conduce a errores anacrónicos: generar código que es válido para una versión de la librería diferente a la solicitada. Si bien trabajos previos han abordado el conocimiento temporal en dominios fácticos generales, la generación de código consciente de la versión plantea un desafío distinto: los modelos deben distinguir entre múltiples versiones coexistentes de la misma API para evitar producir código que sea sintácticamente válido pero semánticamente incorrecto para el entorno objetivo.

Metodología

Benchmark LibEvoBench

Los autores introducen LibEvoBench, un benchmark multitarea diseñado para evaluar el conocimiento de API consciente de la versión en librerías de Python ampliamente utilizadas (PyTorch, NumPy y SciPy). El benchmark abarca 29 versiones de librerías e incluye más de 125,000 instancias de evaluación.

El pipeline de construcción del benchmark es totalmente automatizado:

1. Recolección de Datos: Minería de repositorios públicos de GitHub con archivos requirements.txt anclados para recolectar contextos de código del mundo real.
2. Reconstrucción de la Superficie de la API: Reconstruye la superficie de la API pública para cada versión utilizando dos fuentes complementarias: inventarios oficiales de documentación Sphinx y la introspección directa en tiempo de ejecución. Una API se considera presente solo si ambas fuentes coinciden, creando una verdad fundamental determinista.
3. Clasificación de la API: Basándose en matrices de compatibilidad, las API se clasifican como Estables (firma sin cambios a través de las versiones) o Evolutivas (añadidas, eliminadas o modificadas).

Tareas de Evaluación

LibEvoBench evalúa tres modalidades distintas de conocimiento:

1. Llamada de API (API-C): Dado un fragmento de código incompleto, el modelo debe generar la llamada a la API faltante. Esta tarea utiliza cuatro niveles de reducción de ruido (L0–L3) para aislar diferentes capacidades:
   • L0: Solo contexto de código bruto.
   • L1: Código + docstring redactado (aísla la recuperación de la extracción).
   • L2: Código + docstring + restricción de versión explícita (prueba la conciencia de la versión).
   • L3: Nombre de la API + versión (prueba la recuperación de parámetros de grano fino).
2. Identificación de API (API-I): Dada una ruta de módulo y una descripción redactada, el modelo debe identificar el nombre correcto de la API. Esto aísla el conocimiento declarativo del razonamiento compositivo.
3. Recuperación de Firma (SR): Dado únicamente el nombre de la API plenamente calificado y una versión objetivo, el modelo debe reproducir la firma completa de la función de memoria. Esto sondea el conocimiento paramétrico de argumentos, valores por defecto y orden.

Taxonomía de Alucinaciones

Se introduce un nuevo sistema de clasificación determinista para categorizar los errores del modelo basándose en la superficie de la API indexada por versión:

• Correcto: Coincide con la verdad fundamental en la versión objetivo.
• Desconocido: El símbolo predicho nunca apareció en ninguna versión observada (fabricación).
• Inválido: El símbolo existe en la versión objetivo pero no es el pretendido (confusión de recuperación).
• Anacrónico: El símbolo existe en la historia de la librería pero no en la versión solicitada (confusión temporal). Esta categoría aísla específicamente los errores donde el modelo confunde versiones en lugar de alucinar símbolos inexistentes.

Puntuación de Comprensión de la Evolución del Software (SEUS)

Para agregar el rendimiento, los autores proponen SEUS, una métrica compuesta que penaliza la inconsistencia y el anacronismo. Se calcula como la media armónica de las puntuaciones en las API Estables y Evolutivas, ajustada por:

• Penalización de Estabilidad: Penaliza la varianza en el rendimiento a través de diferentes versiones de las API Evolutivas.
• Penalización de Anacronismo: Penaliza la tasa de predicciones anacrónicas.

Resultados Clave

Los autores evaluaron modelos propietarios de frontera (OpenAI GPT-4.1 a través de GPT-5.5, Anthropic Claude Sonnet 4/4.6, Google Gemini 2.0/2.5/3 Flash) y la familia de pesos abiertos Qwen-3.5 (35B, 122B, 397B).

1. Olvido de Versión: Los modelos de vanguardia son mayoritariamente ajenos a la versión. El rendimiento en las API Evolutivas se degrada significativamente a medida que las versiones de la librería son más nuevas, mientras que el rendimiento en las API Estables permanece plano. Incluso los modelos más fuertes (ej. GPT-5.5, Sonnet 4.6) exhiben una brecha de precisión persistente de 7 a 10 puntos entre las API Estables y las Evolutivas.
2. Limitación Estructural: La degradación es una propiedad estructural del proceso de entrenamiento, no una limitación de la escala del modelo. Dentro de la familia Qwen-3.5, aumentar el tamaño del modelo mejora el rendimiento absoluto pero no altera la tendencia descendente en las API Evolutivas.
3. Ineficacia de las Restricciones Explícitas: Proporcionar una restricción de versión de la librería explícita en el prompt (L1→L2) no produce una mejora medible en la precisión. Esto sugiere que, aunque la etiqueta de versión dispara una respuesta, el modelo carece del conocimiento diferenciado por versión subyacente para respaldarla.
4. Beneficio de la Documentación: Proporcionar la documentación relevante (L0→L1) resulta en una mejora consistente de 10 a 20 puntos, lo que indica que los modelos pueden recuperar y usar la información cuando se les hace explícita, pero fallan en interiorizarla durante el entrenamiento.
5. Análisis de Errores: Los errores son impulsados principalmente por la confusión en lugar de la fabricación. Los modelos frecuentemente producen símbolos válidos pero incorrectos de la misma librería (Inválido) o símbolos de diferentes versiones (Anacrónico). Los errores anacrónicos constituyen una fracción sustancial de los errores a nivel de parámetros (6–14% en la Recuperación de Firma), intensificándose con las versiones objetivo más nuevas.

Significancia y Contribuciones

El artículo realiza tres contribuciones principales:

1. LibEvoBench: Un nuevo benchmark a gran escala para evaluar qué tan bien los LLM navegan por las API en evolución, presentando una verdad fundamental indexada por versión y determinista que evita las limitaciones heurísticas de trabajos previos.
2. Métrica SEUS: Una métrica unificada diseñada para rastrear el progreso en la comprensión de la evolución del software, penalizando explícitamente el conocimiento inconsistente específico de la versión y los errores anacrónicos.
3. Evidencia Empírica de una Brecha de Capacidad: La evaluación establece que los LLM actuales son fundamentalmente ajenos a la versión. Los hallazgos resaltan que ni la escala del modelo ni los datos de entrenamiento recientes han sido suficientes para cerrar la brecha en la estratificación del conocimiento temporal.

Los autores concluyen que la estratificación del conocimiento temporal en la generación de código es una brecha de capacidad persistente y de primer orden. Los resultados motivan la necesidad de nuevos enfoques de entrenamiento y recuperación que puedan fundamentar la generación de código en contextos temporalmente específicos, yendo más allá de la generación de código estático para dominar la evolución continua y diferenciada por versiones de los ecosistemas de software del mundo real.