Resumen Técnico: Razonamiento Guiado por Código para Modelos de Lenguaje Pequeños

Enunciado del Problema

Los Modelos de Lenguaje Pequeños (SLM) se despliegan frecuentemente en sistemas prácticos no como respondedores aislados, sino como componentes dentro de andamios que involucran herramientas externas, ejecución de código y llamadas repetidas al modelo. Sin embargo, los estándares de evaluación de Preguntas de Opción Múltiple (MCQA) evalúan a los SLM principalmente a través de interacciones directas de solicitud-respuesta, sin capturar el rendimiento bajo estas condiciones "andamiadas".

La pregunta central abordada por este trabajo es: ¿Se comporta de manera diferente el mismo pequeño solucionador cuando se traslada de una solicitud de opción en lenguaje natural directa a un andamio de Python ejecutable, y puede auditarse esta diferencia? Los autores señalan que, aunque el código por sí solo no garantiza la fiabilidad, los LLM actuales funcionan tanto como generadores de código como razonadores de dominio. Los flujos de trabajo desplegados suelen combinar estos roles, pero los protocolos de evaluación rara vez distinguen entre la capacidad directa de un modelo y su rendimiento cuando está mediado por un controlador ejecutable generado.

Metodología: Razonamiento Guiado por Código (CGR)

El artículo introduce el Razonamiento Guiado por Código (CGR), un protocolo de evaluación y paquete de trazas diseñado para medir el impacto de los andamios de razonamiento ejecutables en los SLM.

El Protocolo CGR

Para cada ítem de MCQA, el sistema genera una salida de tres canales:

1. Línea Base Directa: El solucionador objetivo responde a la pregunta directamente, emitiendo una sola letra de opción.
2. Solucionador Asistido: Un LLM generador escribe un andamio de Python específico para el ítem. Este andamio almacena variables, ramifica la lógica, llama al helper del solucionador objetivo múltiples veces, extrae respuestas y aplica desempates. La "respuesta asistida" final es la opción seleccionada por esta lógica ejecutable.
3. Respuesta del Lado del Generador: El LLM generador también selecciona una respuesta dentro de la lógica del andamio (independientemente de la salida del solucionador). Esto sirve como un canal de diagnóstico para distinguir entre la mejora del solucionador andamiado y el conocimiento del lado del generador.

Flujo de Ejecución

• Entrada: Un ítem de MCQA (pregunta, opciones, etiqueta dorada).
• Generación: Un LLM generador produce una función de Python con un contrato de retorno fijo: (respuesta_solucionadorLLM, respuesta_genLLM, dificultad_genLLM).
• Ejecución: El andamio se ejecuta, llamando al solucionador objetivo a través de una interfaz de helper (llm_model). Puede realizar múltiples llamadas (por ejemplo, para análisis y verificación) y utiliza un extractor para analizar la primera letra mayúscula independiente (A–Z) de las respuestas.
• Puntuación: Los tres canales (Directo, Asistido, Lado del Generador) se puntúan por separado contra la etiqueta dorada.

Conjuntos de Datos y Modelos

La evaluación utiliza un paquete de MCQA normalizado y preparado localmente que contiene 20,498 filas de resultados retenidos a través de nueve configuraciones de conjuntos de datos (incluyendo MMLU-Pro, OpenBookQA, SuperGPQA, MedQA, Time-MQA, AIME y otros). Se evaluaron seis modelos solucionadores distintos, que van desde modelos recientes compactos (Gemma 4 E2B, Nemotron-3-Nano-4B) hasta modelos anteriores ajustados con instrucciones y orientados al código (Granite 4H Small, Granite 8B Code, Llama 3.2 11B, Mistral Small 3.1 24B).

Estrategia de Particionamiento

Para garantizar la interpretabilidad, los autores definen una partición de línea base no nula. Esto incluye solo los pares conjunto de datos–solucionador donde el solucionador logró al menos una respuesta correcta en la línea base directa. Los pares con precisión directa cero se tratan como una "partición de diagnóstico de línea base cero" separada, ya que las grandes ganancias allí pueden reflejar rescate del formato de solicitud o desajustes de extracción en lugar de una mejora genuina del solucionador.

Contribuciones Clave

1. Entorno de Evaluación: El estudio establece el andamiaje de MCQA ejecutable como una condición de evaluación distinta, observando al mismo solucionador objetivo bajo solicitud directa y dentro de un andamio de Python generado, con puntuación separada para respuestas directas, asistidas y del lado del generador.
2. Paquete de Trazas: Los autores lanzan el paquete de trazas CGR, un recurso que contiene 20,498 filas de resultados, programas generados, metadatos de respuesta y campos de auditoría. Esto permite la inspección de contratos de andamio, conteos de llamadas, fallos de extracción y discrepancias en los canales de respuesta.
3. Resultados Cuantitativos: El artículo reporta una mejora cuantitativa específica y acotada: en la partición de línea base no nula, la precisión macro asistida aumenta de 38.11% (directa) a 66.21% (asistida), una diferencia de +28.10 puntos porcentuales. Bajo un umbral más estricto (precisión directa > 30%), la ganancia es de +14.11 puntos.

Resultados y Observaciones

• Ganancias de Rendimiento: La ruta asistida supera significativamente a la línea base directa en la partición de línea base no nula. La mejora es más pronunciada cuando la precisión de la línea base directa es baja pero no nula (por ejemplo, MedQA, AIME, MMLU-Pro).
• Disparidad de Presupuesto: La ruta de inferencia asistida utiliza aproximadamente 7.36 veces el presupuesto de tokens del solucionador de la línea base directa (media de 7.23 llamadas frente a 1.01 llamada por ítem).
• Fragilidad de Extracción: La extracción de respuestas es un punto de fallo significativo. La ruta asistida tiene una tasa de fallo de extracción del 15.67% (devolviendo 'X' para ninguna letra válida) en comparación con el 0.44% de la línea base directa.
• Casos Negativos (Time-MQA): El conjunto de datos Time-MQA muestra regresiones para solucionadores directos más fuertes. Para modelos con alta precisión directa en Time-MQA, el enfoque andamiado a veces reduce el rendimiento, lo que sugiere que descomponer preguntas de series temporales puede introducir inconsistencias o distraer de señales relevantes.
• Hallazgos de Auditoría:
  • Algunos programas generados violan la instrucción de "no codificación dura", conteniendo asignaciones literales de respuestas.
  • El límite de solicitud de 10 llamadas al solucionador no se aplica en tiempo de ejecución; algunas filas exceden este límite.
  • Las respuestas del lado del generador a menudo difieren de las respuestas del solucionador asistido, confirmando la necesidad de mantener los canales separados.

Significado y Afirmaciones

El artículo posiciona a CGR no como un método de mejora universal ni como una nueva arquitectura de modelo, sino como un protocolo de evaluación que hace medible y auditable la condición andamiada.

• Afirmaciones Modestas: Los autores declaran explícitamente que los resultados son descriptivos, no causales. Las ganancias observadas están asociadas con un presupuesto de inferencia más grande y comportamientos de extracción específicos, no necesariamente con la estructura ejecutable por sí sola. El artículo no afirma que CGR sea de igual costo, universalmente beneficioso o seguro para el despliegue clínico/operacional sin validación experta.
• Interpretabilidad: El valor principal de CGR es el "registro emparejado" que proporciona. Permite a los investigadores determinar por qué cambió una puntuación: ¿Se debió a una descomposición útil, reparación del formato de respuesta, llamadas adicionales o conocimiento del lado del generador?
• Direcciones Futuras: Los autores identifican la necesidad de que el trabajo futuro incluya líneas base de presupuesto coincidente (por ejemplo, autoconsistencia directa), validación de opciones más estricta, ejecución en entornos aislados (sandbox) y muestreo repetido para aislar el efecto causal del andamio del presupuesto de inferencia adicional.

En resumen, CGR demuestra que mover un SLM a un andamio ejecutable puede producir ganancias sustanciales de precisión en tareas de MCQA, pero estas ganancias conllevan costos computacionales aumentados, fragilidad de extracción y variabilidad específica del dominio que deben auditarse cuidadosamente.