Por qué preguntarle a tus datos funciona (y cuándo no)
La capa semántica, el benchmark que lo demuestra y lo que un data engineer tiene que construir antes de abrir el chat.
La promesa lleva una década rondando: que cualquiera pueda preguntarle a los datos en lenguaje natural, sin escribir SQL ni navegar por un dashboard. La diferencia es que ahora, por fin, funciona bastante bien. Y ese «bastante» es exactamente el problema que este artículo intenta desmontar.
Porque Conversational Analytics (analítica conversacional) no es simplemente «text-to-SQL con una interfaz de chat». Es una decisión de arquitectura que determina cómo falla tu sistema, y esa es la propiedad que de verdad importa cuando el número acaba en un comité de dirección. Un sistema fiable responde desde métricas gobernadas; uno frágil adivina contra tablas en crudo.
El motivo por el que adivinar sale caro es que el lenguaje de negocio es ambiguo por naturaleza. Cuando alguien pregunta por «ingresos», ¿se refiere a brutos o netos? Cuando dice «clientes», ¿son cuentas o usuarios individuales? Un esquema de base de datos no codifica esa información. Si nadie se la ha dado al modelo, el modelo elige. Y elige en silencio.
Las tres ideas clave de Conversational Analytics
- El cuello de botella no es el modelo: es el contexto de negocio que le das.
- La métrica que importa no es la precisión media, sino la forma del fallo: error visible frente a número plausible y equivocado.
- La capa semántica ha dejado de ser un debate de fabricantes: en septiembre de 2025 nació un estándar abierto y neutral respaldado por Snowflake, Salesforce, dbt Labs y BlackRock, entre otros.ç
Las dos arquitecturas de Conversational Analytics
Hay dos formas de que un LLM conteste una pregunta sobre datos, y conviene entender bien cómo funciona cada una porque fallan de maneras opuestas.
En text-to-SQL directo, le das al modelo información del esquema y le pides que escriba la consulta. El modelo tiene que inferir la semántica de tus datos a partir de pistas estructurales —nombres de tablas, de columnas, relaciones— y escribe una consulta nueva cada vez. Es flexible: cualquier pregunta es válida mientras el dato exista. Pero también es frágil, porque no hay ninguna barandilla entre la pregunta y el SQL generado. El modelo puede unir tablas mal, malinterpretar el significado de una columna o producir una consulta que se ejecuta perfectamente y devuelve resultados incorrectos.
En el enfoque de capa semántica, defines una ontología: métricas, dimensiones, entidades y las relaciones entre ellas. El trabajo del LLM se reduce entonces a descomponer la pregunta en la combinación correcta de métricas y dimensiones, y un motor determinista se encarga de generar el SQL. La consecuencia es decisiva: si el modelo elige la métrica correcta, la consulta es correcta por construcción. No puede inventarse un join ni una agregación. Y tampoco puede producir números que parezcan correctos pero varíen sutilmente entre ejecuciones, porque la lógica está codificada.
Conversational Analytics: qué dicen los benchmarks de dbt Labs
En abril de 2026, dbt Labs republicó un benchmark que había ejecutado por primera vez en 2023, con la pregunta obvia: dado que los modelos han mejorado enormemente escribiendo SQL, ¿se ha cerrado la brecha? Usaron el dataset ACME Insurance, con once preguntas ejecutadas veinte veces cada una. Los resultados, sobre el proyecto correctamente modelado, son estos:
Con Claude Sonnet 4.6, text-to-SQL alcanza un 90,0 % y la capa semántica un 98,2 %. Con GPT-5.3 Codex, un 84,1 % frente a un 100 %. Y en la comparación histórica sobre el conjunto completo de preguntas, la precisión de text-to-SQL casi se dobló, pasando del 32,7 % en 2023 al 64,5 % actual. Los modelos han mejorado muchísimo. Ese es un hecho, y conviene no negarlo.
Pero el hallazgo importante no está en los porcentajes. Las preguntas que la capa semántica no podía responder en 2023 siguen sin poder responderse hoy sin modelado adicional. La diferencia crítica es qué hace cada sistema cuando no sabe: la capa semántica te dice que no puede responder y nunca devuelve datos inválidos; text-to-SQL te dará alegremente un número equivocado. Dicho de forma más contundente: con text-to-SQL, el fallo tiene aspecto de respuesta plausible; con la capa semántica, el fallo tiene aspecto de mensaje de error. Para un consejo, un auditor o un KPI de empresa, esa diferencia lo es todo.
Tres detalles del estudio que merecen atención por parte de quien vaya a montar esto. El primero: mejorar el modelado subió la precisión de ambos métodos —bastaron tres modelos dbt adicionales para que la capa semántica respondiera todas las preguntas—, así que el trabajo de modelado nunca es tiempo perdido. El segundo: el modelo más grande no siempre gana, y de hecho Sonnet 4.6 superó a Opus 4.6 en esta tarea; además, subir el esfuerzo de razonamiento no mejoró la precisión y sí empeoró la latencia. Y el tercero, un aviso metodológico honesto de los propios autores: para que text-to-SQL funcionara cargaron el esquema completo como contexto, algo poco práctico en datasets grandes. En un warehouse real, las cifras de text-to-SQL probablemente serían peores.
Cómo implementar Conversational Analytics: el trabajo de verdad
La conclusión práctica es que el cuello de botella no es el modelo, sino el contexto. Y ese contexto se construye. En un stack de dbt, la capa semántica se declara como código, se versiona y se revisa en pull request igual que cualquier otro modelo:
| semantic_models:
– name: pedidos model: ref(‘fct_pedidos’) entities: – name: pedido type: primary expr: order_id – name: cliente type: foreign expr: customer_id dimensions: – name: fecha_pedido type: time type_params: { time_granularity: day } – name: region type: categorical measures: – name: importe_bruto agg: sum expr: amount – name: descuentos agg: sum expr: discount_amount
metrics: – name: ingresos_netos description: > Ingresos despues de descuentos. Definicion oficial de negocio: es la cifra que se reporta a direccion. NO usar importe_bruto. type: derived type_params: expr: importe_bruto – descuentos metrics: – name: importe_bruto – name: descuentos |
Fíjate en la descripción de la métrica: no es documentación decorativa. Es el contexto que lee el modelo para decidir qué usar, y es donde se resuelve de una vez la ambigüedad entre «ingresos» brutos y netos. En Conversational Analytics, la descripción de una métrica no es documentación decorativa. Escribir buenas descripciones y sinónimos es, literalmente, ingeniería de precisión.
En el mundo Snowflake el equivalente son las semantic views, que Cortex Analyst lee para generar el SQL contra las tablas físicas. Y en Tableau, la lógica de negocio que muchos equipos llevan años acumulando en fuentes de datos y cálculos cumple el mismo papel. El patrón es idéntico en los tres casos: definir el significado una vez, en un sitio gobernado, y que todas las superficies de consumo lo hereden.
Open Semantic Interchange: el estándar para Conversational Analytics
Durante años, cada fabricante tuvo su propia forma de declarar semántica, lo que obligaba a redefinir las métricas en cada herramienta. Eso está cambiando. En septiembre de 2025 se lanzó el Open Semantic Interchange (OSI): una especificación de modelo semántico común y neutral respecto al fabricante, que estandariza cómo se define y comparte la metadata semántica para garantizar una lógica de negocio consistente entre aplicaciones de IA y de BI.
Lo relevante es quién está detrás: la iniciativa está co-liderada por Snowflake, Salesforce, BlackRock, dbt Labs y RelationalAI, con el apoyo de Alation, Atlan, Cube, Hex, Mistral AI, Omni, Sigma y ThoughtSpot, entre otros. Competidores directos poniéndose de acuerdo, igual que ocurrió con MCP. Tableau lo describió como «la piedra Rosetta de los datos de negocio» y dbt Labs como un lenguaje universal de definiciones. Ya existe una especificación v0.1 publicada, y la propuesta incluye algo especialmente útil para este caso de uso: soporte nativo de contexto para IA, que permite embeber sinónimos —que «ventas» y «compras» signifiquen lo mismo— e instrucciones dentro de la propia definición.
La idea de fondo es un flujo de métricas como código: definir «ingresos» una vez, versionado y gobernado de forma central, en lugar de dejarlo enterrado en cálculos de dashboard, prompts de IA o scripts sueltos.
En el terreno de producto, el movimiento va en la misma dirección. Tableau lanzó en julio su Tableau Agent en dashboards con analítica conversacional (en beta en Tableau Cloud), integraciones para consultar datos gobernados desde Claude o ChatGPT, y un Slackbot que se conecta al entorno de Tableau Cloud a través de MCP para llevar métricas gobernadas y visualizaciones directamente a la conversación. El patrón que se repite en todo el sector: el contexto de negocio vive en un sitio, y las interfaces de conversación lo consumen desde ahí.
Cómo desplegar Conversational Analytics sin perder la confianza
Aquí va el consejo más valioso de todo el artículo, y no es técnico. La forma más rápida de hundir un despliegue de analítica con IA es lanzarlo sobre definiciones de métricas en las que nadie está de acuerdo. La IA resumirá con total seguridad unos números que dos directivos interpretan de dos maneras distintas, y el equipo de datos se pasará los seis meses siguientes discutiendo de quién es el cálculo correcto en lugar de actuar sobre los resultados.
Un orden de trabajo que funciona:
- Empieza por el dominio donde las definiciones ya están cerradas. Si «ingresos netos» todavía se discute, ese no es tu piloto. Elige un área con métricas acordadas y dueño claro.
- Modela ese dominio y solo ese. Cobertura estrecha y profunda vence a cobertura amplia y superficial: la primera genera confianza, la segunda genera anécdotas de errores que circulan por la oficina.
- Construye un conjunto de evaluación. Reúne entre veinte y cincuenta preguntas reales de negocio con su respuesta correcta verificada, y ejecútalas de forma repetida —el benchmark de dbt corrió cada pregunta veinte veces— porque un acierto aislado no dice nada sobre la consistencia.
- Muestra siempre el SQL y la definición usada. La trazabilidad es lo que convierte una respuesta en algo auditable. Un analista que puede revisar la consulta detecta el error; uno que solo ve el número, no.
- Deja que el sistema diga «no lo sé». Suena a defecto y es la mejor característica que puede tener. Resiste la tentación de poner un text-to-SQL como red de seguridad silenciosa detrás de la capa semántica: si lo haces, recuperas exactamente el modo de fallo que querías evitar.
Y la recomendación de arquitectura, que no es excluyente: capa semántica cuando la precisión importa —datos de consejo, auditoría, OKRs, KPIs, informes recurrentes— y text-to-SQL para exploración ad hoc, preguntas puntuales y descubrimiento, comprobando primero si la capa semántica podía responder y si un pequeño cambio de modelado cerraría el hueco.
Conclusión
Conversational Analytics o la analítica conversacional ha cruzado el umbral de lo utilizable, pero no por donde se esperaba. Lo que la hace fiable no es un modelo más grande ni más tokens de razonamiento: es el contexto de negocio que alguien se ha tomado la molestia de codificar. Los datos del benchmark lo dicen sin ambigüedad —más razonamiento no mejoró la precisión; mejor modelado la mejoró para todos los enfoques.
Para un data engineer, eso es una buena noticia disfrazada de trabajo aburrido. El valor no está en integrar el chat, que es la parte fácil, sino en definir métricas, documentar dimensiones, escribir sinónimos y mantener todo eso vivo en control de versiones. Es exactamente la disciplina que muchos equipos llevan años practicando con dbt. La analítica conversacional no la sustituye: la convierte en la interfaz que consume toda la organización. Empieza por un dominio donde las definiciones estén cerradas, evalúa con preguntas reales y deja que el sistema admita cuándo no sabe. La confianza se construye así, y se pierde con un solo número plausible y equivocado.
Nota: las cifras del benchmark proceden del estudio publicado por dbt Labs en abril de 2026 sobre el dataset ACME Insurance; son específicas de ese conjunto de datos y no deben leerse como precisión garantizada en otros entornos. El código es abierto y reproducible sobre tus propios datos. Los productos y disponibilidades citados corresponden a julio de 2026 y evolucionan con rapidez.
Preguntas frecuentes de Conversational Analytics
¿Qué es Conversational Analytics?
Conversational Analytics es un enfoque de analítica que permite consultar datos utilizando lenguaje natural en lugar de escribir SQL o navegar manualmente por dashboards. Para que las respuestas sean fiables, el sistema debe interpretar las preguntas de negocio utilizando métricas, dimensiones, entidades y definiciones gobernadas. Por eso, Conversational Analytics no consiste únicamente en conectar un LLM con una base de datos, sino en proporcionar al modelo el contexto de negocio necesario para interpretar correctamente las preguntas.
¿Cómo funciona Conversational Analytics?
Conversational Analytics transforma una pregunta formulada en lenguaje natural en una consulta sobre los datos. Existen diferentes arquitecturas para hacerlo. En un enfoque basado en text-to-SQL, el modelo genera directamente la consulta a partir del esquema disponible. En un enfoque basado en una capa semántica, el modelo selecciona las métricas y dimensiones adecuadas y un motor determinista genera el SQL, reduciendo el riesgo de joins o agregaciones incorrectas.
¿Cuál es la diferencia entre Conversational Analytics y text-to-SQL?
Conversational Analytics es un concepto más amplio que text-to-SQL. Text-to-SQL se centra en convertir una pregunta en lenguaje natural en una consulta SQL, mientras que Conversational Analytics busca ofrecer una experiencia de análisis completa y fiable sobre los datos. Una arquitectura de Conversational Analytics puede utilizar text-to-SQL, pero también puede apoyarse en una capa semántica que gobierne las métricas, dimensiones y relaciones antes de generar la consulta.
¿Por qué es importante una capa semántica para Conversational Analytics?
La capa semántica proporciona al modelo el contexto de negocio que no está presente en el esquema técnico de una base de datos. Define métricas, dimensiones, entidades y relaciones, además de descripciones y sinónimos. De esta forma, cuando un usuario pregunta por conceptos ambiguos como «ingresos» o «clientes», el sistema puede utilizar una definición de negocio previamente gobernada en lugar de inferir su significado.
¿Qué ventajas tiene Conversational Analytics?
Conversational Analytics permite que usuarios de negocio consulten información mediante lenguaje natural, reduciendo la dependencia de SQL y de la navegación manual por dashboards. Su principal ventaja aparece cuando las respuestas se generan a partir de métricas gobernadas: el usuario puede obtener información de forma conversacional manteniendo una lógica de negocio consistente y trazable.
¿Qué papel tiene dbt en Conversational Analytics?
dbt permite definir la semántica de los datos como código mediante modelos semánticos, métricas, entidades y dimensiones. Esta información puede versionarse y revisarse mediante pull requests, proporcionando al sistema de Conversational Analytics un contexto de negocio estructurado y gobernado. El benchmark analizado en el artículo muestra además que mejorar el modelado puede aumentar significativamente la precisión de las respuestas.
¿Qué es Open Semantic Interchange (OSI)?
Open Semantic Interchange (OSI) es una especificación de modelo semántico común y neutral respecto al fabricante que busca estandarizar cómo se define y comparte la metadata semántica entre aplicaciones de IA y BI. Su objetivo es evitar que las organizaciones tengan que redefinir las mismas métricas y reglas de negocio en diferentes herramientas.
¿Cómo implementar Conversational Analytics en una empresa?
La recomendación es comenzar con un dominio donde las métricas estén claramente definidas y tengan un propietario. Después conviene modelar ese dominio, crear un conjunto de preguntas reales con respuestas verificadas y evaluar repetidamente el sistema. También es importante mostrar al usuario el SQL y la definición utilizada para generar la respuesta y permitir que el sistema indique cuándo no puede responder con suficiente confianza.
¿Es fiable Conversational Analytics?
La fiabilidad depende principalmente de la arquitectura y del contexto de negocio disponible. El benchmark analizado en el artículo muestra mejores resultados para la capa semántica que para text-to-SQL directo en las configuraciones evaluadas. Además, una diferencia fundamental es cómo gestiona cada enfoque aquello que no puede responder: la capa semántica puede indicar que no tiene capacidad para responder, mientras que un sistema text-to-SQL puede generar una respuesta aparentemente válida pero incorrecta.
¿Qué debe construir un data engineer para Conversational Analytics?
El trabajo principal no consiste en integrar una interfaz de chat, sino en construir y mantener el contexto de negocio que utilizará el sistema. Esto incluye definir métricas, dimensiones y entidades, documentar sus significados, establecer sinónimos, mantener la lógica en control de versiones y crear conjuntos de evaluación con preguntas reales. La calidad de este modelado determina en gran medida la fiabilidad de Conversational Analytics.
