Precision or Peril: A PoC of Python Code Quality from Quantized Large Language Models

Resumen Técnico: Precision or Peril

1. Planteamiento del Problema

Los Modelos de Lenguaje Grandes (LLMs) han demostrado capacidades avanzadas en la generación de código, automatizando tareas como la finalización de código, pruebas y documentación. Sin embargo, su despliegue en entornos reales enfrenta dos desafíos principales:

• Recursos Computacionales: Los modelos de última generación (ej. GPT-5, LLaMA-405B) requieren cantidades masivas de memoria y potencia de cálculo, lo que limita su uso en organizaciones más pequeñas.
• Calidad del Código: Existe el riesgo de que el código generado sea incompleto, ineficiente o contenga errores lógicos, de seguridad o de tiempo de ejecución.

Para mitigar los costos de hardware, se utiliza la cuantización (reducción de la precisión de los pesos del modelo a 8 bits o 4 bits). Aunque esto reduce la huella de memoria, el fenómeno conocido como "pérdida de calidad" sugiere que podría degradar la funcionalidad del código generado. El estudio identifica una brecha en la investigación: se desconoce cómo interactúa la compresión del modelo (cuantización) con la calidad del software, la mantenibilidad y la fiabilidad funcional, especialmente en modelos de código abierto de menor tamaño.

2. Metodología

El estudio se diseñó como una prueba de concepto (PoC) para evaluar cuatro LLMs de código abierto (todos con menos de 10 mil millones de parámetros) bajo tres condiciones: sin cuantizar, cuantizados a 8 bits y cuantizados a 4 bits.

• Modelos Evaluados:
  1. WizardCoder 7B: Ajustado finamente con Evol-Instruct.
  2. Mistral Instruct 7B: Entrenado para prompts generales, optimizado para eficiencia.
  3. StarCoder 2 7B: Entrenado en el dataset The Stack V2 (artefactos de GitHub).
  4. CodeLlama 7B: Ajustado finamente en 500 mil millones de tokens de código.
• Benchmarks (Pruebas):
  • HumanEvalPlus: 164 problemas de Python de dificultad media.
  • MBPP Plus (Mostly Basic Python Problems): ~800 problemas de Python fáciles.
  • Se utilizaron casos de prueba expandidos mediante gramáticas libres de contexto (CFG) y LLMs.
• Proceso Experimental:
  1. Generación de una solución por prompt sin ingeniería de prompts adicional.
  2. Evaluación funcional mediante tasa de aprobación de pruebas unitarias (pass@1).
  3. Cálculo de similitud con soluciones humanas usando CodeBLEU.
  4. Análisis estático de calidad de código utilizando SonarQube (Community Edition) para detectar "code smells", vulnerabilidades, problemas de fiabilidad y mantenibilidad.
  5. Cuantización realizada mediante AWQ (Activation Aware Weight Quantization).
• Hardware: Una sola máquina con GPU Nvidia RTX 3090 (24GB VRAM), CPU AMD Ryzen 16 núcleos y 64GB RAM.

3. Contribuciones Clave

• Evaluación Multidimensional: Integración de métricas de rendimiento de benchmark, similitud de código (CodeBLEU) y análisis estático (SonarQube) para una visión holística de la calidad.
• Análisis de Cuantización: Estudio explícito de cómo la cuantización a 4-bit y 8-bit afecta la corrección funcional y la mantenibilidad del código generado.
• Identificación de Defectos: Catalogación sistemática de problemas de calidad comunes en código Python generado por LLMs pequeños (ej. nombres inconsistentes, variables no utilizadas, bucles infinitos).
• Repositorio Público: Liberación de todos los datos y código fuente para reproducibilidad.

4. Resultados Principales

A. Rendimiento en Benchmarks (RQ1):

• El rendimiento general fue bajo. El mejor modelo (Mistral Instruct 7B) alcanzó solo un 34.1% de tasa de aprobación en MBPP Plus, y el mejor en HumanEvalPlus (WizardCoder 7B) alcanzó un 27.6%.
• Discrepancia en Métricas: Hubo una correlación débil entre las puntuaciones de CodeBLEU (similitud sintáctica, que osciló entre 0.20 y 0.30) y las tasas de aprobación de pruebas. Esto indica que los LLMs priorizan la similitud estructural y el patrón sobre la funcionalidad real y los casos límite. CodeBLEU no es un sustituto confiable de las pruebas unitarias.

B. Efecto de la Cuantización (RQ2):

• Los efectos fueron mixtos y dependientes del modelo:
  • Modelos CodeLlama y StarCoder 2: Poca variación (<2%) entre versiones cuantizadas y no cuantizadas.
  • Mistral Instruct y WizardCoder: Sensibilidad significativa. Mistral perdió un 13% de rendimiento en HumanEvalPlus al cuantizarse a 4-bit, pero mejoró un 7% en MBPP Plus.
• Conclusión: La cuantización tiene poco impacto en la sintaxis y estructura del código (los patrones se mantienen), pero afecta drásticamente la lógica y funcionalidad, ya sea positiva o negativamente según el modelo y la tarea.

C. Calidad del Código y Análisis Estático (RQ3):

• Se analizaron 6,756 archivos Python, detectando 1,848 problemas.
• Distribución de Problemas:
  • 85.2% fueron problemas de Mantenibilidad (code smells, estilo, estructura).
  • 15.2% de Fiabilidad (errores lógicos).
  • 0.2% de Seguridad (muy pocos).
• Atributos de Código Limpio: El 59.6% de los problemas se relacionaron con Intencionalidad (falta de claridad o lógica), seguido por Consistencia (31.2%) y Adaptabilidad (9.4%). No se detectaron problemas de Responsabilidad (ética/seguridad legal).
• Violaciones Comunes: Nombres de funciones no convencionales (404 casos), variables locales no utilizadas (262), código comentado (225), y pruebas de igualdad con números de punto flotante (170).
• Análisis Manual: Se observaron patrones recurrentes como definiciones de funciones repetidas, bucles de impresión infinitos, lógica incompleta (# TODO) y uso de valores codificados (hardcoded).

D. Impacto de la Cuantización en la Calidad (RQ3.5):

• Contrario a la intuición, los modelos cuantizados a 4 bits generaron más problemas (770) que los no cuantizados (571) o los de 8 bits (507).
• La cuantización a 8 bits pareció ofrecer el mejor equilibrio, a veces reduciendo los problemas de redundancia en comparación con los modelos no cuantizados.

5. Significado y Conclusiones

El estudio concluye que, aunque los LLMs pequeños pueden generar código funcional, no están listos para su integración directa en proyectos de software sin validación rigurosa.

• Riesgos: El código generado a menudo carece de las mejores prácticas de ingeniería de software, acumulando "deuda técnica" debido a problemas de mantenibilidad y estilo, más que a fallos de seguridad catastróficos.
• Recomendaciones:
  • No confiar en métricas de similitud (CodeBLEU) como único indicador de calidad; las pruebas unitarias son esenciales.
  • La cuantización debe evaluarse caso por caso; una reducción a 8 bits puede ser preferible a 4 bits para preservar la lógica, y en algunos casos, incluso puede mejorar la calidad al reducir el "ruido" de generación.
  • Es necesaria la ingeniería de prompts, técnicas de auto-reparación y múltiples rondas de generación para mejorar la fiabilidad.

Este trabajo sirve como una advertencia ("Peril") sobre la implementación ciega de LLMs cuantizados en producción, pero también destaca su potencial ("Precision") si se gestionan adecuadamente las expectativas y se aplican controles de calidad estrictos.