💬 NLP

Spider 2.0-AIFunc: Extending Real-World Text-to-SQL to AI-Native SQL Workflows

Este artículo presenta Spider 2.0-AIFunc, un nuevo benchmark de 465 instancias verificadas a través de 125 bases de datos del mundo real diseñado para evaluar la capacidad de los grandes modelos de lenguaje para generar consultas SQL nativas de IA en la plataforma Snowflake, revelando que, si bien los principales modelos propietarios alcanzan una precisión del 67-70%, los marcos de agentes actuales optimizados para tareas tradicionales de text-to-SQL no se transfieren eficazmente a este entorno emergente.

Autores originales: Tianyang Liu, Canwen Xu, Fangyu Lei, Nikki Lijing Kuang, Jixuan Chen, Tao Yu, Julian McAuley, Zhewei Yao, Yuxiong He

Publicado 2026-07-08

📖 5 min de lectura🧠 Análisis profundo

CC BY 4.0

Autores originales: Tianyang Liu, Canwen Xu, Fangyu Lei, Nikki Lijing Kuang, Jixuan Chen, Tao Yu, Julian McAuley, Zhewei Yao, Yuxiong He

Artículo original bajo licencia CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta es una explicación generada por IA del artículo a continuación. No ha sido escrita ni avalada por los autores. Para mayor precisión técnica, consulte el artículo original. Leer descargo de responsabilidad completo

Imagina que tienes una biblioteca masiva y de alta tecnología (una base de datos en la nube) donde la gente almacena de todo, desde reseñas de clientes hasta registros de ventas. Durante años, hacer preguntas sobre esta biblioteca requería un lenguaje muy estricto y robótico llamado SQL. Era como intentar pedir una comida compleja en un restaurante hablando únicamente mediante un código de números y símbolos.

Recientemente, los dueños de la biblioteca (como Snowflake) añadieron una nueva función: Funciones de IA. Piensa en ellas como "asistentes inteligentes" integrados directamente en el sistema de pedidos. Ahora, en lugar de solo pedir "todas las manzanas rojas", puedes pedirle al sistema que "lea las reseñas de estas manzanas y me diga si la gente está feliz o enojada", o "encuentra reseñas que sean similares a esta". Esto convierte a la base de datos en un sistema Nativo de IA, donde puedes mezclar comandos de datos estándar con un pensamiento basado en el lenguaje y la inteligencia en una sola frase.

El Problema: El Mapa Antiguo No Funciona

Los investigadores notaron que, aunque estos nuevos "asistentes inteligentes" son poderosos, las pruebas utilizadas para entrenar y verificar los cerebros computacionales (modelos de IA) estaban obsoletas. Las pruebas antiguas solo verificaban si la computadora podía hablar el estricto lenguaje robótico. No verificaban si la computadora podía usar estos nuevos "asistentes inteligentes". Era como probar a un conductor solo en una carretera recta y vacía, cuando el mundo real ahora tiene tráfico, peatones y zonas de construcción.

La Solución: Spider 2.0-AIFunc

Para solucionar esto, el equipo creó una nueva y más difícil prueba de conducción llamada Spider 2.0-AIFunc.

La Transformación: Tomaron 513 "pruebas de conducción" existentes (preguntas sobre datos) y las reescribieron. Obligaron a que las preguntas requirieran el uso de los nuevos "asistentes inteligentes".
- Pregunta Antigua: "Muestra todas las reseñas negativas". (Requiere que un humano las lea primero).
- Nueva Pregunta: "Muestra todas las reseñas donde el asistente de IA dice que el sentimiento es negativo". (La IA realiza la lectura dentro de la base de datos).
El Equipo de Construcción: Utilizaron un equipo de agentes de IA (trabajadores digitales) para reescribir estas preguntas. Estos agentes actuaron como editores y mecánicos:
- Verificaron que las instrucciones fueran claras (por ejemplo, "¿Qué quieres decir exactamente con 'negativo'?").
- Se aseguraron de que el "asistente inteligente" tuviera todas las herramientas (parámetros) adecuadas para hacer el trabajo.
- Ejecutaron las pruebas una y otra vez para asegurarse de que las respuestas fueran estables y no cambiaran solo porque el asistente de IA tuviera un mal día.
El Examen Final: El resultado es un benchmark de 465 preguntas verificadas a través de 125 bases de datos diferentes. Cubre seis tipos de tareas de "asistentes inteligentes", como clasificar reseñas por emoción, encontrar textos similares o extraer detalles específicos de un párrafo.

Los Resultados: ¿Quién Pasó la Prueba?

Los investigadores sometieron a 10 modelos de IA diferentes (los "conductores") a este nuevo examen para ver qué tan bien podían escribir estas consultas complejas potenciadas por IA.

Los Mejores Conductores (Modelos Propietarios): Los grandes modelos de código cerrado (como Claude Opus y Gemini) fueron los mejores. Obtuvieron entre un 67% y un 70% de las respuestas correctas. Fueron buenos para determinar qué "asistente inteligente" usar y cómo hacerle la pregunta adecuada.
Los Conductores de Código Abierto: Los mejores modelos de código abierto (como Kimi K2.5) puntuaron alrededor del 58%. Eran decentes, pero cometieron más errores.
La Brecha: La razón principal por la que los modelos de código abierto tuvieron dificultades no fue que no pudieran escribir el código básico. Tropezaron con las partes "inteligentes":
- Malentendidos de las reglas: Elegir la tabla o columna incorrecta.
- Instrucciones deficientes: Olvidar decirle al asistente de IA exactamente qué buscar (por ejemplo, no enumerar todas las categorías posibles para una tarea de clasificación).
- Errores de lógica: Confundir el orden de las operaciones (por ejemplo, filtrar datos después de preguntarle a la IA en lugar de hacerlo antes).

El Descubrimiento Sorprendente: Menos es Más

Los investigadores también probaron si el uso de "frameworks de agentes" complejos (kits de herramientas elaborados que ayudan a la IA a planificar sus pasos) ayudaba.

El Hallazgo: Sorprendentemente, los kits de herramientas más complejos no ayudaron mucho. De hecho, una configuración mínima —solo una herramienta simple para mirar la base de datos y una herramienta para ejecutar la consulta— funcionó tan bien como, o incluso mejor que, los frameworks sofisticados.
La Metáfora: Es como darle a un maestro chef un cuchillo pequeño y simple frente a un enorme y complicado cuchillo suizo. Para este tipo de cocina específica (SQL Nativo de IA), el maestro chef no necesitaba los accesorios extra; solo necesitaba saber cómo usar el cuchillo. Los frameworks complejos diseñados para tareas de datos de la vieja escuela en realidad estorbaban o no aportaban valor para estas nuevas tareas inteligentes.

Resumen

Este artículo presenta un nuevo y realista test para modelos de IA que verifica si pueden utilizar las funciones modernas de las bases de datos "potenciadas por IA". Encontró que, si bien los mejores modelos de IA se están volviendo buenos en esto, todavía hay una brecha entre los modelos de alto nivel y los de código abierto. La clave del éxito no es usar herramientas de planificación más complejas, sino obtener las instrucciones básicas y los parámetros para las funciones de IA de manera exacta.

Resumen Técnico: Spider 2.0-AIFunc

Planteamiento del Problema

Las principales plataformas de datos en la nube (por ejemplo, Snowflake, BigQuery, Databricks) han comenzado a exponer capacidades de Modelos de Lenguaje Extensos (LLM) como funciones SQL nativas. Estas funciones "nativas de IA" permiten a los analistas realizar operaciones semánticas —como clasificación, análisis de sentimiento, búsqueda de similitud y extracción de información— directamente dentro de consultas SQL estándar. Sin embargo, los benchmarks de Text-to-SQL existentes (por ejemplo, Spider 1.0, Spider 2.0, BIRD) evalúan únicamente SQL convencional sobre datos estructurados. No proporcionan ninguna señal sobre la capacidad de un modelo para generar SQL nativo de IA, el cual requiere no solo la construcción de consultas estándar, sino también la selección, parametrización e integración correctas de las llamadas a funciones de IA.

Metodología

Los autores presentan Spider 2.0-AIFunc, un benchmark diseñado para evaluar las capacidades de Text-to-SQL en el contexto de flujos de trabajo nativos de IA. La metodología de construcción y evaluación involucra tres componentes principales:

1. Construcción del Benchmark mediante un Pipeline de Agentes

El benchmark se deriva de 513 instancias del conjunto de datos Spider2-Snow (un subconjunto de nivel empresarial de Spider 2.0 alojado en Snowflake). Los autores emplean un pipeline reutilizable basado en agentes (usando Claude Opus 4.5) para transformar estas tareas tradicionales en versiones nativas de IA:

Transformación: Los agentes reescriben el SQL objetivo para incorporar las funciones de Snowflake Cortex AI y, simultáneamente, refinan las instrucciones de lenguaje natural para hacer explícito el uso de la IA pretendida.
Reducción de Ambigüedad: Para tareas con múltiples SQL de oro válidos, las instrucciones se refinan para especificar la función de IA exacta y sus parámetros (por ejemplo, conjuntos completos de etiquetas de clase para la clasificación) para asegurar una única respuesta correcta.
Proceso de Dos Rondas:
- Ronda Principal: Los agentes seleccionan funciones de IA libremente, lo que resulta en una distribución dominada por AI_CLASSIFY, AI_FILTER y AI_SIMILARITY.
- Ronda de Diversidad: Se instruye a los agentes para que prioricen funciones subrepresentadas (AI_SENTIMENT, AI_EXTRACT, AI_AGG) para asegurar una amplia cobertura de los seis tipos de funciones de IA soportadas.

2. Verificación de Determinismo

Un desafío crítico al evaluar funciones de IA es el determinismo de ejecución, ya que los outputs de los LLM pueden exhibir inconsistencias menores incluso con temperatura cero. Para abordar esto:

Verificación de Multi-paso: Cada instancia candidata se somete a cuatro pasadas de ejecución (un total de $\ge$ 35 ejecuciones). Un agente de verificación repara las instancias con resultados inconsistentes ajustando el SQL, las instrucciones o las configuraciones de evaluación.
Estabilidad Temporal: Las instancias supervivientes se someten a una verificación final de estabilidad que involucra 30 ejecuciones a través de tres ventanas de tiempo separadas temporalmente. Las instancias que producen resultados inconsistentes a través de estas ventanas son descartadas.
Dataset Final: El proceso produce 465 instancias verificadas en 125 bases de datos reales.

3. Protocolo de Evaluación

Métrica: Exactitud de Ejecución (EX). A diferencia de los benchmarks tradicionales donde los resultados de oro son precomputados y estáticos, Spider 2.0-AIFunc requiere que tanto el SQL de oro ( $S_n$ ) como el SQL predicho ( $\hat{S}_n$ ) se ejecuten dentro de la misma ventana de tiempo para asegurar que sean evaluados contra el mismo estado subyacente del modelo.
Lógica de Comparación: Los resultados se comparan utilizando el emparejamiento de subconjuntos de columnas (las columnas de oro deben aparecer en los resultados predichos; las columnas predichas pueden contener extras).
Frameworks: Los modelos se evalúan utilizando el framework Spider-Agent con un conjunto mínimo de herramientas (bash para exploración de esquemas, ejecución de SQL y terminación de tareas). La configuración incluye documentación de referencia para las funciones de Snowflake Cortex AI.

Contribuciones Clave

Benchmark Spider 2.0-AIFunc: El primer benchmark específicamente para Text-to-SQL nativo de IA, que cubre 465 instancias verificadas, 125 bases de datos y seis tipos de funciones de IA (Clasificación, Filtrado, Sentimiento, Similitud, Extracción, Agregación).
Pipeline de Construcción Basado en Agentes: Un pipeline automatizado y novedoso que transforma tareas existentes de Text-to-SQL empresarial en versiones nativas de IA, mientras refina simultáneamente las instrucciones y verifica el determinismo de la ejecución.
Análisis Empírico de SQL Nativo de IA: Una evaluación exhaustiva de 10 modelos de última generación (5 propietarios, 5 de código abierto) y 3 frameworks de agentes, revelando modos de falla específicos y las limitaciones de las estrategias tradicionales de Text-to-SQL en este nuevo entorno.

Resultados

La evaluación de 10 modelos en Spider 2.0-AIFunc arroja los siguientes hallazgos:

Brecha entre Modelos Propietarios y de Código Abierto: Los modelos propietarios superan significativamente a los modelos de código abierto.
- Top Propietario: Claude Opus 4.6 (70.3%), Claude Sonnet 4.6 (69.0%) y Gemini 3.1 Pro (67.1%).
- Top Código Abierto: Kimi K2.5 (58.1%).
- La brecha es impulsada principalmente por errores en la especificación de predicados, el anclaje al esquema (schema grounding) y la parametrización de funciones de IA.
Éxito de Ejecución: La mayoría de los modelos logran tasas de "Exec." altas (90–99%), lo que indica que pueden generar SQL nativo de IA sintácticamente válido que se ejecuta sin errores. La brecha reside en la corrección semántica.
Transferibilidad de Frameworks de Agentes: Los frameworks de agentes diseñados para desafíos tradicionales de Text-to-SQL (por ejemplo, recuperación de esquemas, selección de tablas) no se transfieren efectivamente al SQL nativo de IA.
- Los frameworks complejos (AutoLink, ReFoRCE, DSR-SQL) igualaron pero no superaron el rendimiento de una configuración mínima de Spider-Agent cuando se utilizó el mismo modelo base (Claude Sonnet 4.6).
- Esto sugiere que las estrategias para el andamiaje (scaffolding) de SQL tradicional son menos críticas que la capacidad de tomar decisiones semánticas precisas respecto al uso de funciones de IA (por ejemplo, la parametrización correcta, el orden de filtrado).
Comportamiento de Interacción: Los modelos de código abierto requieren significativamente más rondas de interacción (19–30 frente a 10–12 para los propietarios) y más intentos de ejecución de SQL para alcanzar un resultado correcto, fallando a menudo en la terminación correcta.

Significado y Reivindicaciones

El artículo afirma que Spider 2.0-AIFunc representa una evolución necesaria en la evaluación de Text-to-SQL, pasando de la manipulación puramente de datos estructurados a flujos de trabajo nativos de IA que integran operaciones semánticas directamente en SQL.

Los autores enfatizan que:

Los Benchmarks Actuales son Insuficientes: Los benchmarks existentes no logran capturar la complejidad de integrar capacidades de LLM en los pipelines de datos empresariales.
El Determinismo es Crítico: El protocolo de verificación resalta que evaluar funciones de IA requiere verificaciones de estabilidad rigurosas debido a la naturaleza inherente no determinista de los outputs de los LLM, incluso en entornos controlados.
Cambio de Estrategia: El hecho de que los frameworks de agentes complejos no superen a las configuraciones mínimas sugiere que el cuello de botella principal en el SQL nativo de IA no es la recuperación de esquemas o la descomposición, sino la especificación y parametrización precisa de las funciones de IA. A medida que los modelos mejoran, el valor de los andamiajes elaborados para los componentes de SQL tradicional disminuye en relación con la necesidad de una invocación de funciones semánticas precisas.

Este trabajo sirve como un paso fundacional para evaluar y mejorar los modelos capaces de construir flujos de trabajo de análisis de datos "nativos de IA", una capacidad cada vez más requerida por las plataformas de datos empresariales.