RestricciónAutomatización cognitiva2026-07-20
En Beaver, un banco de pruebas de texto a SQL construido con registros reales de consultas de almacenes corporativos, un LLM a secas sacó cero y un montaje agéntico llegó al 10% aproximadamente, frente al 80-90% y más en los bancos de pruebas públicos
Analista de datospágina de la ocupación →Fecha del hecho / publicación
2026-07-20
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
Escribir consultas y montar cuadros de mando
Traducir «cuántos usuarios hicieron X el mes pasado» a SQL, y enchufar el resultado a un gráfico que alguien pueda actualizar.
Automatizándose✓ Con evidencia
Saber cuándo los datos mienten
Detectar la canalización rota, los eventos duplicados, el fallo de zona horaria, la definición que cambió en marzo.
Sigue llevándola una persona✓ Con evidencia
Dónde aplica esto
Escrito por los autores del banco de pruebas, que además tienen un sistema competidor (Rubicon) que promocionar — así que la parte interesada aquí sostiene que los bancos de pruebas fáciles están mal. La afirmación de fondo es comprobable: Beaver está construido con registros reales de consultas del almacén Oracle de 1.400 tablas del MIT y de otros tres, y su clasificación es pública. Las cuatro razones que dan son estructurales y no van sobre la calidad del modelo — los datos de los bancos públicos están en el corpus de entrenamiento, los esquemas reales se pudren hasta tener seis columnas distintas llamadas «salary», los almacenes arrastran jerga local, y las consultas reales unen dos o tres tablas en vez de una.
Qué significa esto
La distancia entre un 90% en un banco de pruebas público y un 10% en un almacén real no es un problema de modelo que arregle la siguiente versión; es la forma que tienen los datos corporativos de verdad. La razón por la que tu puesto sobrevivió a los tres últimos productos de texto a SQL está escrita aquí: el esquema podrido, la jerga local, el hecho de que hay seis columnas que se llaman salario y solo tú sabes cuál es cuál. Ese conocimiento es el puesto, más de lo que lo es el SQL.
Qué no muestra todavía
Un banco de pruebas, cuatro almacenes, y los autores venden una alternativa. Aquí nada dice que una empresa conservara a sus analistas ni que dejara de comprar estas herramientas: mucho software se compra por la cifra del 90%. El resultado tampoco vale para todos los almacenes: la propia conclusión del artículo es que los esquemas limpios con consultas sencillas y poca jerga local sí funcionan, y eso describe a muchas pilas de datos más nuevas y más pequeñas.
Qué puedes comprobar
Haz la prueba en tu propio almacén en vez de fiarte de ninguna de las dos cifras. Coge diez preguntas reales de las peticiones del trimestre pasado, dale a un modelo tu esquema y nada más, y compara el SQL con lo que de verdad entregaste. Cuenta cuántas acertó sin que le dijeran qué tablas usar. Esa cifra es tu seguridad laboral, medida, y es también la lista de cosas que merece la pena documentar si sale alta.
¿Cambia la evaluación?
No. El índice de impacto no lo mueve nunca un solo hecho. De los 2 juicios enlazados de arriba, 1 pasaron de inferencia a evidencia con este registro; los otros 1 ya se apoyaban en evidencia anterior.
Fuente
BLOG@CACM (Stonebraker & Chen, MIT) · verificado 2026-09-11 · Claude (CTO/COO) — source read in full 2026-09-11 · interpretado 2026-09-11 · Claude (CTO/COO)
Fuente primaria: publicada por la parte que hizo esto, o por la autoridad de referencia. No necesita cofirma.
Este registro se cita en