El CoT visible no mejora de forma universal la generación de SQL y código pandas, según un nuevo estudio

Un grupo de investigadores ha puesto a prueba uno de los consejos de prompting más repetidos, «que el modelo piense en voz alta», en una tarea con verificación objetiva: generar código analítico que se pueda ejecutar. El preprint de arXiv 2610.10639 compara SQL y Python (pandas) con las mismas consultas. Los autores no encontraron ni una mejora universal de la precisión con la cadena de razonamiento visible (Chain-of-Thought), ni un beneficio estable al razonar «en el lenguaje de la tarea». El efecto depende de la persona del prompt, el lenguaje de destino, la configuración del modelo y el modo de razonamiento interno.

Cómo está montado el experimento

El código analítico es un buen banco de pruebas. La consulta en lenguaje natural es ambigua, el modelo debe ceñirse al esquema de datos y el resultado está sujeto a las reglas estrictas del lenguaje de destino. Una misma pregunta sobre los datos puede resolverse con una consulta SQL o con un script de pandas. Por eso los autores construyeron un benchmark en el que las consultas están emparejadas entre ambos lenguajes y comprobaron una suposición extendida: que el razonamiento visible funciona mejor si se escribe en la misma representación que la respuesta, es decir, «piensa en SQL» o «piensa en Python».

El experimento combinó varios factores:

• la formulación de la persona en el prompt;
• el lenguaje de destino: SQL o Python (pandas);
• el formato del CoT visible, incluido el razonamiento en la representación del lenguaje de destino;
• prefijos de control;
• la generación directa sin razonamiento visible;
• configuraciones de razonamiento interno del modelo.

La calidad se midió por la ejecución del código, no por la similitud del texto con una referencia. El resumen no incluye resultados numéricos ni nombres de modelos; habrá que buscarlos en el texto completo.

Qué muestran los resultados

La conclusión principal es negativa, pero práctica. El CoT visible no aporta una mejora general de la precisión. Alinear la representación del razonamiento con el lenguaje de destino tampoco funciona como regla: en algunos casos ayuda y en otros no. El signo y el tamaño del efecto dependen de la combinación de persona, lenguaje, modelo y ajustes de razonamiento interno.

Las ablaciones de control tienen un valor aparte, porque separan la influencia del contenido del razonamiento de la influencia del formato del prompt. Parte de los cambios en la calidad puede deberse a que una plantilla o un prefijo adicional simplemente desplaza el comportamiento del modelo, razone este bien o no. Los autores lo formulan así: el razonamiento visible a veces mejora la generación ejecutable y a veces se limita a perturbar el comportamiento del modelo. En varias configuraciones, el factor decisivo es el razonamiento interno, no lo que se muestra en la respuesta.

Qué deberían hacer los equipos que construyen text-to-SQL y agentes analíticos

No conviene tratar el prompt «think step-by-step» como valor por defecto. Hay que validarlo con los datos propios, igual que cualquier otro parámetro. Estas son las prácticas mínimas que se desprenden del trabajo:

• Mantengan la generación directa sin CoT visible como variante base obligatoria y compárenla con el resto según el resultado de la ejecución de las consultas.
• Prueben el prompt junto con el modelo, la persona, el lenguaje de destino y el modo thinking. Trasladar ajustes de una combinación a otra no es fiable.
• Añadan prefijos de control para distinguir el beneficio del razonamiento del efecto de una plantilla larga.
• En los modelos de razonamiento, comprueben por separado si el CoT visible interfiere con el razonamiento interno.
• No incrusten consejos como «piensa en SQL» en el prompt de sistema sin medir su efecto en su propio esquema.

Las limitaciones también son evidentes. Es un preprint en versión v1, sin revisión por pares, y con el resumen no se puede evaluar la magnitud de los efectos ni la cobertura de modelos. Aun así, como marco metodológico para responder dónde el CoT ayuda al código ejecutable, dónde solo mete ruido y dónde importan más los ajustes del modelo, el trabajo resulta útil para cualquier equipo que tenga un asistente analítico en producción.