QuantCode-Bench: A Benchmark for Evaluating the Ability of Large Language Models to Generate Executable Algorithmic Trading Strategies

Resumen Técnico: QuantCode-Bench

1. Planteamiento del Problema

Aunque los Modelos de Lenguaje Grandes (LLM) han demostrado un rendimiento superior en tareas de programación de propósito general, su capacidad para generar estrategias de trading algorítmico ejecutables sigue siendo poco explorada. A diferencia de los benchmarks de código estándar (como SWE-Bench o LiveCodeBench), la generación de estrategias financieras presenta desafíos únicos:

• Complejidad de Dominio: Requiere no solo sintaxis correcta, sino la integración de lógica financiera específica, conocimiento de una API especializada y la capacidad de producir código que genere señales de trading reales en datos históricos.
• Fallo de Evaluación Estándar: En tareas de codificación tradicionales, la compilación exitosa y la aprobación de pruebas unitarias suelen ser suficientes. En trading, un código puede ser sintácticamente correcto y ejecutar una backtest sin errores, pero ser funcionalmente inútil si no genera operaciones (trades) o si la lógica no coincide con la descripción natural del usuario.
• Brecha Semántica: Existe una desconexión entre la descripción textual de una idea de trading y su implementación lógica correcta dentro de un entorno de ejecución específico.

2. Metodología y Diseño del Benchmark

2.1. Definición de la Tarea
El benchmark evalúa la capacidad de un modelo para generar una estrategia de trading utilizando el framework Backtrader a partir de descripciones textuales en inglés. El éxito se define mediante una tubería de evaluación de cuatro etapas anidadas:

1. Compilación: El código debe ser sintácticamente correcto y ejecutable.
2. Backtest: La estrategia debe ejecutarse correctamente en un entorno de prueba con datos históricos de diversos activos y marcos temporales, sin errores de tiempo de ejecución.
3. Trade (Operación): La estrategia debe colocar al menos una operación (compra o venta) en los datos históricos.
4. Juez (Judge): Un LLM actúa como juez para validar la alineación semántica entre el código generado y la descripción original de la tarea (verificando indicadores, condiciones de entrada/salida y lógica de gestión de posiciones).

2.2. Dataset (QuantCode-Bench)

• Volumen: 400 tareas de generación de estrategias.
• Fuentes: Recopiladas de Reddit (183), TradingView (100), StackExchange (90), GitHub (19) y fuentes sintéticas (8).
• Dificultad: Clasificadas en fácil, media y difícil.
• Enfoque: Se seleccionó Backtrader debido a su complejidad no trivial (manejo de líneas de datos, índices, ejecución de órdenes), lo que reduce la probabilidad de que el éxito se deba a la reproducción superficial de plantillas.

2.3. Configuraciones de Evaluación
El benchmark compara los modelos en dos escenarios:

• Single-turn (Un solo intento): El modelo debe generar la estrategia correcta en el primer intento, sin retroalimentación. Mide el conocimiento inicial y la capacidad de generación one-shot.
• Agentic Multi-turn (Interacción agente): El modelo recibe retroalimentación estructurada tras cada fallo (tipo de error y mensaje del sistema) y puede corregir el código hasta 10 veces. Mide la capacidad de reparación iterativa y búsqueda local.

2.4. Métricas Principales
La métrica central es el "Judge Pass", que representa la proporción de tareas donde la estrategia pasa exitosamente las cuatro etapas de la tubería.

3. Contribuciones Clave

1. Nuevo Benchmark Especializado: Introducción de QuantCode-Bench, diseñado específicamente para evaluar la generación de estrategias de trading ejecutables, llenando un vacío en la literatura de benchmarks de finanzas (que se centran mayormente en NLP financiero o extracción de información).
2. Marco de Evaluación Multinivel: Propuesta de una metodología que distingue entre corrección técnica, comportamiento de trading real y alineación semántica, evitando métricas agregadas que ocultan fallos cualitativos.
3. Análisis Comparativo Amplio: Evaluación de modelos de vanguardia (incluyendo GPT-5, Claude Opus, Gemini, Qwen, DeepSeek) en ambos modos (single-turn y agente).
4. Análisis de Errores Detallado: Identificación de los modos de fallo dominantes, demostrando que los errores no son principalmente sintácticos, sino lógicos y semánticos.
5. Recurso Abierto: Liberación del código, dataset y materiales para fomentar la investigación en generación de código específico de dominio.

4. Resultados Principales

4.1. Rendimiento en Single-turn (Un solo intento)

• Compilación: Los modelos líderes alcanzan tasas de compilación cercanas al 100%. La sintaxis ya no es el cuello de botella.
• Degradación en etapas posteriores: Existe una divergencia significativa entre la compilación y el éxito final.
  • Los mejores modelos (ej. claude-opus-4.6) alcanzan un 75.8% de Judge Pass.
  • Los modelos medianos caen drásticamente (ej. qwen3-8b al 18.5%).
• Hallazgo: La dificultad principal no es escribir código Python, sino operacionalizar la lógica de trading dentro del entorno de Backtrader.

4.2. Rendimiento en Agentic Multi-turn (Iterativo)

• Mejora Significativa: La retroalimentación iterativa permite a los modelos reparar errores locales.
  • Los mejores modelos alcanzan un 95–98% de Judge Pass en este modo.
• Limitaciones Persistentes: Aunque la mayoría de los errores técnicos se corrigen, un porcentaje de fallos finales se debe a malentendidos semánticos profundos sobre la tarea original, los cuales son difíciles de corregir solo con retroalimentación de errores de código.

4.3. Análisis de Fallos

• Causas de error más frecuentes:
  1. Condiciones de señal no activadas (17.8%): El código compite y hace backtest, pero las condiciones de entrada/salida nunca se disparan en los datos (umbrales demasiado estrictos o lógica incorrecta).
  2. Errores de objetos Line y __bool__ (13.1%): Manejo incorrecto de los objetos de datos de Backtrader en contextos booleanos (falta de indexación [0]).
  3. Falta de alineación semántica: La estrategia es ejecutable y opera, pero no coincide con la descripción del usuario (ej. usar una media móvil en lugar de un RSI solicitado).
• Tendencia en modo Agente: Los errores puramente sintácticos o de API desaparecen rápidamente con las iteraciones, mientras que los errores de lógica de señal y alineación semántica persisten hasta el último intento.

5. Significado e Implicaciones

• Cambio de Paradigma en la Evaluación: El éxito en la generación de código para dominios específicos ya no se mide por la compilación, sino por la ejecutabilidad lógica y la alineación semántica.
• Valor de la Interactividad: La capacidad de un modelo para reparar errores de forma iterativa es tan crítica como su precisión inicial. Los benchmarks estáticos subestiman el potencial real de los modelos en entornos de desarrollo asistido.
• Especialización vs. Generalidad: Contrario a la intuición, los modelos especializados en código no siempre superan a los modelos de propósito general en esta tarea. Los modelos con mejores capacidades de seguimiento de instrucciones y comprensión semántica tienden a rendir mejor, ya que la tarea requiere una interpretación precisa de la intención financiera.
• Necesidad de Validación Semántica: Las métricas técnicas (compilación, ejecución) son insuficientes. La inclusión de un "Juez LLM" es vital para evitar que los modelos generen plantillas genéricas que funcionan técnicamente pero fallan en resolver el problema financiero planteado.

En conclusión, QuantCode-Bench establece que la generación de estrategias de trading es una clase de tarea distinta que requiere una combinación de disciplina técnica, comprensión de lógica de dominio y capacidad de traducción semántica, marcando un nuevo estándar para la evaluación de LLMs en aplicaciones financieras.