LO
RestricciónAutomatización cognitiva2024-11-12
Sobre 632 flujos de trabajo de datos de empresa sacados de almacenes reales, un agente de código resolvió el 21,3% — frente al 91,2% en la versión académica de la misma tarea
Ingeniero de datospágina de la ocupación →
Fecha del hecho / publicación
2024-11-12
Categoría de la evidencia
RestricciónUn fallo, una marcha atrás, una regulación o un coste están frenando la adopción. Puede bajar una evaluación o ensanchar su incertidumbre.
Tareas sobre las que incide
Construir la canalización
Extraer de una fuente, reformarlo, cargarlo en algún sitio consultable, y programar todo el conjunto.
Automatizándose✓ Con evidencia
Ser dueño de lo que significa un número
Definir usuario activo, ingresos, abandono — y sostener esa definición cuando dos equipos quieren que signifique cosas distintas.
Sigue llevándola una persona✓ Con evidencia
Dónde aplica esto
632 problemas construidos a partir de aplicaciones de datos reales sobre BigQuery y Snowflake, con bases que a menudo superan las 1.000 columnas. Lo que los hace difíciles lo dicen los autores y es exactamente el entorno diario de esta ocupación: la respuesta exige buscar en los metadatos de la base y en la documentación del dialecto, leer el propio código del proyecto, sostener un contexto muy largo, y emitir varias consultas en dialectos distintos que con frecuencia pasan de las 100 líneas. El 21,3% es un marco de agente sobre o1-preview a finales de 2024 y quedará desfasado; el hallazgo duradero es la distancia hasta el 91,2% en Spider 1.0 y el 73,0% en BIRD, que es una medición de cuánta dificultad vive en el almacén y no en el SQL. No dice nada sobre empleo, ni nada sobre canalizaciones que se construyen en vez de consultarse — mide producir la consulta, no operar el sistema que la sigue produciendo.
Qué significa esto
La dificultad de este puesto es medible y la mayor parte de ella no está en el SQL. Cuando la misma clase de tarea se plantea sobre un almacén real (mil columnas, varios dialectos, documentación que buscar, una base de código que leer) la tasa de acierto cae de alrededor de nueve de cada diez a alrededor de dos de cada diez. Esa distancia es una cifra para lo que la gente de datos dice y casi nunca se le cree: la consulta es la parte fácil, y saber cuál es la tabla buena es el puesto.
Qué no muestra todavía
La puntuación de un banco de pruebas no es la decisión de un empleador, y una puntuación baja no es seguridad. La cifra es de un solo marco de agentes sobre una generación de modelos a finales de 2024 y hay que dar por supuesto que se ha movido; lo que no se mueve tan rápido es por qué era baja. Además prueba producir una consulta correcta, que es solo una de las tareas de esta ocupación: aquí nada incide en construir una tubería, ni en qué pasa cuando cambia el esquema de origen, ni en a quién se llama cuando las cifras dejan de llegar.
Qué puedes comprobar
Elige una cifra con la que se gobierne tu empresa y síguela hacia atrás hasta las tablas de las que se calcula. Cuenta cuántas de las decisiones del camino están escritas en algún sitio. Ese recuento, y no el SQL, es lo que una herramienta tendría que reproducir.
¿Cambia la evaluación?
No. El índice de impacto no lo mueve nunca un solo hecho. Lo que sí hizo este registro: 2 juicios de tarea enlazados de arriba se apoyan ahora en evidencia en vez de en inferencia.
Fuente
Spider 2.0: Evaluating Language Models on Real-World Enterprise Text-to-SQL Workflows (arXiv:2411.07763) · verificado 2026-09-12 · Claude (VOLO agent) — arXiv abstract page read; the 632-problem count, the 1,000-column note and the 21.3% / 91.2% / 73.0% comparison taken from the authors' own abstract · interpretado 2026-09-12 · Claude (VOLO agent)
Fuente primaria: publicada por la parte que hizo esto, o por la autoridad de referencia. No necesita cofirma.
Este registro se cita en