La analítica agentiva no es texto a SQL — es ingeniería del contexto
La respuesta corta
La publicación de Anthropic sobre analítica de autoservicio es el informe de producción más claro hasta ahora sobre por qué la analítica agentiva no es solo texto a SQL.
El titular: Anthropic automatiza aproximadamente el 95% de sus consultas analíticas de negocio con Claude con una precisión agregada de ~95%. Pero lo importante es cómo — y casi nada de eso es SQL. Los propios datos de Anthropic muestran que Claude obtuvo como máximo 21% en sus evaluaciones analíticas sin habilidades, y superó 95%+, hasta ~99% en algunos dominios, con ellas. El salto vino de la guía procedimental, no de una mejor generación de SQL.
Por qué "texto a SQL" es el marco equivocado
Texto a SQL es la parte que puedes demostrar en 30 segundos: preguntas en lenguaje natural, ver una consulta, obtener un número. Parece mágico. También crea una falsa sensación de precisión, porque nada de eso prueba que la pregunta de negocio fue respondida correctamente.
Toma "¿Cuál fue el ingreso de clientes activos el mes pasado?" El SQL es la parte fácil. Lo difícil es decidir: ¿qué cuenta como activo? ¿Cuál es la definición oficial de cliente? ¿Bruto o neto? ¿Qué campo de fecha usar? ¿Qué filtros de reembolsos y fraude aplicar? El modelo solo escribe SQL después de que se tomen todas esas decisiones.
Por eso el planteamiento de Anthropic — "los datos no son software" — es la tesis. El software tiene tests y pruebas deterministas. La analítica tiene una única respuesta correcta de una fuente correcta, sin forma determinista de probar la corrección a partir de la salida sola. El agente puede escribir SQL perfecto y aun así estar semánticamente equivocado.
Los tres modos de fallo
Anthropic atribuye la gran mayoría de errores a tres cosas:
- Ambigüedad de concepto/entidad — "usuarios activos" o "ingresos" pueden mapear a múltiples implementaciones plausibles, y la opción equivocada sigue pareciendo profesional.
- Datos desactualizados — esquemas, definiciones de negocio y documentación cambian; el procedimiento que ayer era correcto se vuelve silenciosamente incorrecto.
- Fallo de recuperación — la respuesta correcta existe pero el espacio de búsqueda es tan grande que el agente la pasa por alto y construye con confianza sobre un casi-acierto.
El warehouse por sí solo no soluciona esto. Los warehouses almacenan datos; no almacenan el significado del negocio.
La pila de cuatro capas
La respuesta de Anthropic es una pila donde el SQL está aguas abajo de todas las decisiones difíciles:
- Fundamentos de datos — conjuntos de datos canónicos y de fuente única, modelado dimensional, checks de frescura, metadatos tratados como un producto de primera clase. Menos candidatos plausibles antes de que empiece la recuperación.
- Fuentes de verdad — la capa semántica, linaje, corpus de consultas y contexto de negocio. Se obliga estructuralmente a los agentes a consultar la capa semántica primero; el SQL crudo es el recurso de respaldo.
- Habilidades — conocimiento procedimental: qué fuente consultar primero, cuándo recurrir a un fallback, qué aclarar, cómo revisar adversarialmente. Aquí es donde viene el salto de precisión.
- Validación — evaluaciones offline, corridas de ablación, revisión adversarial, pies de procedencia y bucles de mantenimiento.
Dos hallazgos contraintuitivos destacan:
- No dejes que el LLM construya la capa semántica. Anthropic intentó generar automáticamente definiciones métricas a partir de tablas crudas. Produjo definiciones con aspecto plausible que codificaban las mismas ambigüedades que intentaban eliminar, y fue netamente negativo en las evaluaciones frente a una capa humana y más pequeña. Genera documentación con Claude, pero que un humano sea el dueño de las definiciones.
- El historial bruto de consultas apenas ayuda. Dar al agente acceso directo a miles de consultas SQL previas movió la precisión menos de un punto. El ochenta por ciento del tiempo la respuesta estaba en el corpus — el agente incluso la leía — pero aun así no la usaba. El cuello de botella es la estructura, no el acceso.
La lección de mantenimiento
La advertencia más práctica: las habilidades se vuelven obsoletas. Los docs de habilidades describen un modelo de datos que cambia diariamente. Anthropic observó una deriva de la precisión offline de ~95% a ~65% en un mes antes de tratar el mantenimiento de habilidades como un problema de ingeniería.
Su solución fue aburrida y efectiva: colocar el markdown de la habilidad en el mismo repo que los modelos de datos, de modo que el PR que cambia un modelo sea el mismo PR que actualiza su documentación. Un hook de revisión de código marca cualquier cambio en un modelo de reporting que no toque un archivo de habilidad. Ahora aproximadamente el 90% de sus PRs de modelos de datos incluyen un cambio de habilidad en el mismo diff.
Empezar (no construyas una catedral)
El propio consejo de Anthropic: un puñado de conjuntos de datos canónicos, unas pocas docenas de evaluaciones offline y una habilidad delgada capturan la mayor parte del beneficio. Todo lo demás es lo que añadieron una vez que eso existía.
Una secuencia pragmática para empezar:
- Elige un dominio, no todo el warehouse.
- Crea una fuente de verdad gobernada — conjuntos de datos canónicos, definiciones métricas explícitas, propiedad, checks de frescura — antes de tocar los prompts.
- Pon la capa semántica primero, haz del SQL crudo un fallback.
- Escribe una habilidad/playbook delgada que codifique el procedimiento del analista: aclarar, sourcear, validar, reportar, citar procedencia.
- Construye un pequeño set de eval — 20–30 preguntas reales con respuestas esperadas superan a cien demos internos.
Conclusión
La misma trampa de la "falsa sensación de precisión" de la que advierte Anthropic se aplica a tu propio sistema: enchufar un modelo de vanguardia directamente a una base de datos y llamarlo analítica es la forma de acabar con números equivocadamente confiados. El hábito durable que conviene copiar es el pie de procedencia — toda respuesta analítica debería indicar su nivel de fuente (capa semántica › referencia curada › tabla cruda), frescura y propietario. Si no puedes generar ese pie, tu agente tampoco podrá, y esa es la señal de que falta la capa de contexto.
Fuente principal: How Anthropic enables self-service data analytics with Claude (Anthropic, June 3, 2026). Hechos (95%/~99%, 21%, tres modos de fallo, deriva 95%→65%) verificados contra la publicación primaria de Anthropic el 2026-08-07.