Resumen Técnico: Cuando los LLM inventan crates de Rust

Declaración del Problema

Los Grandes Modelos de Lenguaje (LLM) se utilizan cada vez más para la generación de código, sin embargo, siguen siendo propensos a las "alucinaciones": producir salidas plausibles pero fácticamente incorrectas o fabricadas. Un subconjunto crítico de este problema es la alucinación de paquetes, donde un LLM recomienda o importa una dependencia que no existe. En lenguajes como Python y JavaScript, esto representa un grave riesgo de seguridad para la cadena de suministro, ya que los adversarios pueden pre-registrar paquetes maliciosos bajo nombres alucinados.

Aunque investigaciones previas han estudiado extensamente la alucinación de paquetes en ecosistemas populares (Python, JavaScript), existe una brecha significativa con respecto a Rust. Rust es ampliamente adoptado para la programación de sistemas de nivel crítico de seguridad (por ejemplo, sistemas operativos, blockchain). Aunque la gestión de dependencias de Rust (a través de Cargo.toml) difiere de otros lenguajes —requiriendo la declaración explícita antes de que se descargue un crate—, las referencias a crates alucinadas en el código fuente siguen siendo un problema directo de fiabilidad. Causan fallos de compilación, importaciones no resueltas y confusión de namespaces. Además, en muchos flujos de trabajo asistidos por LLM, los fragmentos de código fuente se generan sin manifiestos de proyecto completos, lo que hace que las referencias a crates a nivel de código fuente sean la señal más temprana observable de errores relacionados con dependencias.

Metodología

Para abordar la falta de datos empíricos sobre Rust, los autores realizaron el primer estudio a gran escala sobre la alucinación de crates en código Rust generado por LLM.

1. Construcción del Conjunto de Datos

Los autores construyeron un conjunto de datos de múltiples fuentes que comprende 2.794 tareas de codificación derivadas de tres fuentes:

• Stack Overflow: 1.001 preguntas únicas de Rust, altamente votadas, que representan consultas reales de desarrolladores.
• GitHub: 793 tareas extraídas de los 100 repositorios de Rust más importantes (por estrellas), filtradas por calidad para excluir la estructura interna del compilador, tareas vagas y restricciones específicas de plataforma.
• Tareas Generadas por LLM: 1.000 tareas creadas transformando descripciones de crates populares (de lib.rs y crates.io) en solicitudes de implementación utilizando un modelo Qwen2.5-32B.

2. Evaluación de Modelos

El estudio evaluó 14 modelos a través de seis familias, incluyendo:

• Comerciales: GPT-5, Gemini 2.5 Pro, Claude 4 Opus.
• Código Abierto: Qwen2.5-Coder (varios tamaños), DeepSeek-Coder-V2, OpenCoder.
  Los modelos fueron probados bajo configuraciones por defecto y varios decodificadores de temperatura (de 0 a 5).

3. Mecanismo de Detección

Se construyó un inventario exhaustivo de crates válidos de Rust mediante el raspado de crates.io, la Biblioteca Estándar de Rust y los crates del compilador rustc. Los autores también minaron archivos Cargo.toml de repositorios para capturar alias de crates.

• Extracción: El sistema extrajo nombres de crates del código generado utilizando tres patrones: declaraciones use, prefijos de ruta directa y declaraciones extern crate.
• Métrica: La Tasa de Alucinación de Crates (CHR) se calculó como la relación entre los nombres extraídos ausentes del inventario válido y el total de nombres extraídos.

4. Evaluación de Mitigación

Se probaron dos estrategias de ingeniería de prompts para mitigar las alucinaciones sin reentrenar los modelos:

• Auto-refinamiento (Self-Refinement): Un proceso de múltiples turnos donde el modelo revisa su propia salida, verifica el uso de la biblioteca estándar y valida los nombres de los crates antes de finalizar.
• Generación Aumentada por Recuperación (RAG): Se proporcionó al modelo un índice de recuperación de los 10.000 crates principales de crates.io y una lista de módulos de la biblioteca estándar para fundamentar su generación.

Resultados Clave

RQ1: Prevalencia y Factores Influyentes

• Alta Prevalencia: La CHR general en todos los modelos fue del 20,23%. Se observaron alucinaciones en todos los modelos evaluados.
• Sensibilidad del Modelo: Aunque modelos específicos tuvieron un mejor desempeño (por ejemplo, Gemini 2.5 Pro con 16,18% frente a Claude 4 Opus con 26,90%), la diferencia entre modelos comerciales y de código abierto no fue estadísticamente significativa en promedio.
• Independencia de Parámetros: A diferencia de los hallazgos en Python/JavaScript, el tamaño del modelo (conteo de parámetros) no mostró una correlación estadísticamente significativa con las tasas de alucinación dentro de las familias de modelos (por ejemplo, variantes de Qwen2.5-Coder).
• Independencia de la Temperatura: El aumento de la temperatura de decodificación no condujo a un incremento sistemático de las alucinaciones. La CHR se mantuvo estable en las configuraciones de temperatura (0–5), contrastando con trabajos previos donde las temperaturas más altas aumentaban las tasas de alucinación.

RQ2: Patrones de Alucinación

El estudio identificó cuatro patrones distintos específicos de Rust:

1. Confusión Módulo-Crate: Más del 45% de las alucinaciones fueron en realidad módulos válidos de la biblioteca estándar de Rust (por ejemplo, std::thread, std::io) referenciados incorrectamente como crates externos. Los modelos a menudo fallaron al calificarlos con std:: o core::.
2. Consistencia entre Modelos: Las alucinaciones de módulos mostraron una alta superposición entre diferentes modelos (similitud de Jaccard ≈ 0,44), lo que sugiere limitaciones compartidas en los datos de entrenamiento, mientras que las alucinaciones que no eran módulos fueron más únicas de cada modelo específico.
3. Variantes de "Casi Acierto" (Near-Miss): Los nombres alucinados fueron predominantemente variaciones menores de crates reales. El 86,48% de las alucinaciones estaban dentro de cinco ediciones de Levenshtein de un crate válido. Un patrón prominente fue el uso incorrecto de guiones, donde los modelos generaron nombres en camelCase (por ejemplo, httpresponse) en lugar de la convención kebab-case de Rust (por ejemplo, http-response).
4. Transferencia de Ecosistema Cruzado: Aproximadamente el 39% de las alucinaciones frecuentes reutilizaron nombres de otros ecosistemas (por ejemplo, Python o APIs de Windows), indicando una transferencia de conocimiento estructurada pero desalineada.

RQ3: Efectividad de la Mitigación

• Ganancias Limitadas: Ambas estrategias de mitigación redujeron las tasas de alucinación, pero las mejoras fueron modestas.
• Auto-refinamiento: Redujo consistentemente la CHR en 2 a 3 puntos porcentuales (aproximadamente una reducción relativa del 10–15%).
• RAG: Proporcionó mejoras limitadas e inconsistentes; en algunos casos, aumentó ligeramente la tasa.
• Conclusión: Las intervenciones simples a nivel de prompt son insuficientes para eliminar sustancialmente las alucinaciones de crates.

Significancia y Contribuciones

El documento afirma las siguientes contribuciones:

1. Primer Estudio Empírico: Proporciona la primera investigación sistemática sobre las alucinaciones de crates en el código Rust generado por LLM, llenando un vacío en la literatura dominada por estudios de Python y JavaScript.
2. Patrones Distintos: Revela que las alucinaciones de Rust siguen un patrón distinto comparado con otros lenguajes: son altamente estructuradas (a menudo involucrando confusión de módulos y errores de convención de nombres) y son sorprendentemente insensibles al tamaño del modelo y la temperatura de decodificación.
3. Liberación de Conjunto de Datos: Los autores liberaron un conjunto de datos de 2.794 tareas de codificación de Rust para facilitar futuras investigaciones.
4. Implicaciones de Seguridad y Fiabilidad: El estudio destaca que, si bien el modelo de dependencias de Rust mitiga los ataques inmediatos a la cadena de suministro (al requerir actualizaciones de Cargo.toml), las referencias alucinadas siguen causando fallos de compilación significativos y problemas de fiabilidad. Sugiere que la mitigación futura requiere barreras de protección conscientes de Rust (por ejemplo, validación de namespaces, verificación consciente del registro y referencias cruzadas con Cargo.toml) en lugar de una ingeniería de prompts genérica.

Los autores concluyen que, si bien las estrategias ligeras ofrecen beneficios marginales, una mitigación robusta probablemente requiere una integración más estrecha con la verificación a nivel de toolchain y mejoras en los datos de entrenamiento específicas para el ecosistema de Rust.