Less Is More: Measuring How LLM Involvement affects Chatbot Accuracy in Static Analysis

1. Problema y Contexto

El análisis estático de software es fundamental para la seguridad y la calidad del código, pero su adopción está limitada por la usabilidad. Herramientas como Joern utilizan Gráficos de Propiedades de Código (CPG) y un lenguaje de consulta específico (CPGQL, basado en Scala) que es potente pero difícil de dominar. Los desarrolladores luchan para formular consultas correctas debido a la complejidad de la sintaxis, la semántica de recorrido de grafos y la necesidad de conocer el esquema del CPG.

Los Grandes Modelos de Lenguaje (LLM) se han propuesto como puentes para traducir solicitudes en lenguaje natural a estas consultas estructuradas. Sin embargo, existe un debate sobre cuánta autonomía debe otorgarse al LLM:

• ¿Debe generar directamente el código de la consulta (alto riesgo de errores sintácticos y semánticos)?
• ¿Debe generar una representación intermedia estructurada que luego se traduce determinísticamente?
• ¿Debe actuar como un agente que utiliza herramientas iterativamente?

El artículo identifica que los LLMs, aunque buenos en lenguaje natural, carecen de representaciones internas fiables para el "razonamiento cruzado" necesario en consultas de análisis estático (conectar identificadores con estructuras sintácticas específicas), lo que lleva a alucinaciones o consultas inválidas.

2. Metodología

Los autores compararon tres arquitecturas diferentes a lo largo de un espectro de participación del LLM, utilizando un conjunto de pruebas (benchmark) personalizado.

Las Tres Arquitecturas Comparadas:

1. A1: Generación Directa. El LLM genera directamente una cadena de texto en CPGQL. Se le proporciona contexto (documentación, ejemplos) y, en caso de error de ejecución, se le permite corregir la consulta (hasta 3 intentos).
   • Espacio de salida: Ilimitado y no estructurado.
2. A2: Representación Intermedia Estructurada. El LLM genera un objeto JSON que cumple con un esquema fijo (tipos de consulta, filtros, columnas de salida, etc.). Un mapeador determinista (código verificado) traduce este JSON a la consulta CPGQL correcta. El LLM nunca ve la sintaxis de la consulta.
   • Espacio de salida: Compacto, fuertemente tipado y restringido.
3. A3: Generación Agente Aumentada con Herramientas. El LLM opera en un bucle tipo ReAct (Observar, Pensar, Actuar). Se le exponen capacidades de análisis como herramientas (funciones) que puede invocar paso a paso para construir la respuesta.
   • Espacio de salida: Secuencia de llamadas a herramientas.

Configuración Experimental:

• Benchmark: 20 tareas de análisis de código en proyectos Java reales (Apache Commons Lang y OWASP WebGoat), divididas en tres niveles de complejidad: Estructural, Flujo de Datos y Compuesto.
• Modelos: Se probaron 4 modelos de código abierto (familias Llama y Qwen) en dos escalas: Pequeña (7-8B parámetros) y Grande (70-72B parámetros).
• Métricas: Tasa de coincidencia de resultados (comparación de la salida ejecutada vs. la verdad fundamental), tasa de éxito de ejecución, consumo de tokens y número de invocaciones.
• Diseño: 2x2 (familia x escala) con 3 repeticiones por combinación, totalizando 720 ensayos teóricos (660 datos utilizables).

3. Contribuciones Clave

1. Nuevo Benchmark: Un conjunto de 20 tareas de traducción de lenguaje natural a CPGQL, validado mecánicamente y disponible públicamente.
2. Comparación Controlada: Una evaluación rigurosa de tres arquitecturas de LLM con políticas de reintento uniformes para aislar el efecto de la arquitectura.
3. Evidencia Empírica: Demostración de que restringir la salida del LLM a una representación intermedia estructurada supera a la generación directa y a los enfoques agénticos en dominios formalmente estructurados.
4. Interacción Modelo-Tamaño: Evidencia de que el beneficio de las representaciones estructuradas es mayor en modelos grandes, mientras que los modelos pequeños enfrentan cuellos de botella en el cumplimiento del esquema.

4. Resultados Principales

A. La Representación Intermedia Estructurada (A2) es Superior

• Precisión: La arquitectura A2 obtuvo la mayor tasa de coincidencia de resultados en todos los modelos.
  • En modelos grandes (70B+), superó a la generación directa (A1) entre 15 y 25 puntos porcentuales.
  • En modelos pequeños, la mejora fue modesta (3-5 puntos), pero aún positiva.
• Razón: Al convertir la tarea de "generar código" a "clasificar/llenar campos en un JSON", se evita que el LLM tenga que razonar sobre la sintaxis compleja del DSL, un punto donde los modelos fallan frecuentemente.

B. El Enfoque Agéntico (A3) es el Peor

• Precisión: A3 tuvo el rendimiento más bajo en todos los modelos (ej. 25% en Qwen 72B vs. 58.3% de A2).
• Costo: Consumió aproximadamente 8 veces más tokens que A2 y tardó mucho más tiempo (latencia media de 32s vs. <5s).
• Fallo de Cobertura: Las tareas resueltas correctamente por el agente eran un subconjunto estricto de las resueltas por A2. No hubo tareas que A3 pudiera resolver y A2 no, lo que invalida la idea de que el enfoque agéntico ofrece cobertura complementaria que justifique su alto costo.
• Errores Compuestos: En tareas de múltiples pasos, los errores se acumularon rápidamente. Incluso con una precisión por paso alta, la probabilidad de éxito final caía drásticamente.

C. Interacción con el Tamaño del Modelo

• Modelos Grandes: Pueden cumplir con el esquema JSON de manera fiable (100% de éxito de ejecución en A2), aprovechando plenamente la arquitectura.
• Modelos Pequeños: Tienen dificultades para generar JSON válido (tasas de éxito de ejecución de A2 del 53-65%). El cuello de botella se desplaza de la "corrección de la consulta" al "cumplimiento del esquema". Sin embargo, A2 sigue superando a A1 incluso en estos casos.

D. Costo de Tokens vs. Precisión

No existe correlación positiva entre el consumo de tokens y la precisión. A3 consumió significativamente más recursos computacionales pero obtuvo resultados inferiores, demostrando que "más computación" no compensa una "arquitectura inadecuada" para dominios estructurados.

5. Significado y Conclusiones

El artículo concluye que en dominios con estructuras formales (como lenguajes de consulta de análisis estático), menos participación del LLM es mejor.

• Principio de Diseño: La estrategia óptima es delegar al LLM únicamente la comprensión del lenguaje natural y la clasificación dentro de un esquema bien definido (JSON). La construcción de la consulta final debe ser responsabilidad de código determinista.
• Implicación para la Industria: Los sistemas que intentan usar LLMs como agentes autónomos para tareas de análisis estático complejo pueden estar desperdiciando recursos y reduciendo la precisión. La restricción de la salida (output-space constraint) es más efectiva que la libertad de exploración.
• Limitaciones: El enfoque de esquema estructurado depende de que el dominio pueda ser capturado por un esquema suficientemente compacto. Para modelos muy pequeños, técnicas como la decodificación guiada podrían ser necesarias para asegurar el cumplimiento del esquema.

En resumen, el estudio valida que para tareas de traducción a DSLs en análisis estático, la arquitectura A2 (Intermedia Estructurada) es la más robusta, eficiente y precisa, superando tanto a la generación directa como a los enfoques agénticos modernos.