Los agentes necesitan un significado interpretable: capas semánticas, ontologías y métricas reguladas.

Imagínense la reunión diaria de lunes. Un compañero pega la respuesta del agente en Slack: los ingresos por cliente del trimestre anterior, presentados de forma ordenada, explicados brevemente y transmitidos con total seguridad. Con solo una mirada por parte del departamento financiero, toda la reunión se detiene. Esa cifra corresponde a reservas, mientras que los ingresos reconocidos se almacenan en otro dato con una estructura diferente y su propia lista de exclusiones. No había nada malo con el SQL. Nadie había acordado qué significaba realmente la pregunta.

Después de ver suficientes escenas como estas, “el modelo generó SQL válido” deja de considerarse un éxito. Los modelos de lenguaje grande han hecho que casi todos los datos de los almacenes sean legibles por máquinas. Ser legible es algo sencillo. Lo difícil es ser interpretable: qué significan “cliente”, “ingresos”, “activo”, “abandono” y “trimestre anterior” en esta empresa en particular, para esta decisión concreta.

Antes de los agentes, una persona se encargaba de interpretar antes de escribir cualquier consulta. Al delegarla a un agente en tiempo de ejecución, este improvisará una historia plausible a menos que se le proporcione una ya elaborada. La solución permanente consiste en gestionar el significado empresarial como un producto: darle una identidad, versionarlo, probarlo, mapearlo a datos físicos y permitir que tanto los humanos como el software lo utilicen de manera idéntica.

Para la mayoría de los equipos, el paso necesario para poder desplegarlo es contar con una capa semántica o de métricas bien regulada. El objetivo a largo plazo es un modelo basado en ontologías que compile las proyecciones posteriores, ya sean LookML, vistas SQL, contratos de API o herramientas de agentes, de modo que ningún producto tenga que inventar su propia “verdad” privada.

Por qué una respuesta segura representa un riesgo

La BI basada en chat suele describirse como la conversión del lenguaje natural a SQL, una etiqueta que oculta la parte más difícil. Lo complicado es interpretar una pregunta desde un marco de referencia y transferir su significado a otro.

Considere la pregunta “¿Cuál fue el ingreso por cliente el último trimestre?”. Para un almacén, ejecutar una consulta precisa es sencillo. El esfuerzo radica en elegir qué consulta representa la pregunta. El ingreso podría referirse a reservas, facturación o ingresos reconocidos. El cliente podría ser la parte a la que se vendió, la parte a la que se factura o cualquier nodo de la jerarquía de cuentas que las ventas muestren en sus revisiones trimestrales. El último trimestre podría corresponder a meses calendario, al año fiscal o a un período dinámico que prefieran las operaciones.

En un panel de control, un analista ya ha tomado esas decisiones. Una ficha etiquetada como “Ingresos” parece fiable porque la decisión semántica está integrada en el propio elemento. En las conversaciones, el orden cambia: la decisión ahora se toma en tiempo real, para preguntas arbitrarias, dentro del software, lo que convierte la semántica de una página wiki en una infraestructura de ejecución en tiempo real.

La consecuencia problemática es que cuanto mejor logra un modelo generar SQL plausible, más peligrosas se vuelven sus ошибías. La corrección sintáctica no dice nada sobre la validez semántica. Una explicación bien redactada puede responder a la pregunta incorrecta de manera tan fluida que nadie se da cuenta hasta que un informe contradice el registro de chat. Los equipos que solo se preguntan si una consulta se ejecutó se están entrenando para confiar en una incorrectitud presentada de forma convincente.

Los modelos dimensionales ya contienen cierto significado

Nada de esto convierte a un almacén en una hoja en blanco. El modelado dimensional al estilo Kimball ha pasado décadas compensando por lo poco que dicen los esquemas relacionales de uso general. Hechos, dimensiones, mediciones, nivel de detalle, jerarquías y dimensiones conformadas escriben todo el significado empresarial en estructuras que las personas pueden consultar.

Un esquema estrella bien estructurado ya funciona como una capa semántica informal. Las capas semánticas actuales añaden más elementos, como definiciones de métricas, reglas de cálculo, terminología, relaciones permitidas y reglas de negocio que los nombres de las columnas no pueden revelar. Una ontología formal va aún más allá, separando el modelo conceptual de su implementación relacional y mapeando intencionadamente ambos.

Es mejor considerarlo como un continuum y no como un proceso de conversión:

• esquema relacional operativo
• modelo dimensional
• capa semántica
• ontología formal

Al avanzar en la lista se añaden más significados y se pide al modelo que adivine menos. Cada elemento que se deja implícito representa una apuesta a que la inferencia llegue a la definición que el director financiero confirmaría sin dudar.

Lo que siguen mostrando las investigaciones

Los estudios recientes sobre conversión de texto a SQL arrojan siempre el mismo resultado: especificar el significado empresarial aumenta la precisión, y esto es válido incluso para esquemas ya creados para análisis.

En una prueba realizada por Figueiredo y sus colegas, se utilizó GPT-4 Turbo con un esquema en forma de estrella. El esquema por sí solo generó aproximadamente un 58% de consultas correctas, y al añadir semántica contextual esa cifra subió al 89%. Rumiantsau y Fokeev incorporaron un breve documento semántico a un modelo de almacén analítico basado en Contoso, lo que elevó la precisión de aproximadamente un 48% a un 52%, situándola en los altos sesenta por ciento. Estas mejoras son significativas porque los puntos de referencia no eran esquemas transaccionales desorganizados.

Cuando el esquema físico proporciona menos información sobre el negocio, el efecto se intensifica. Painter y sus colegas trabajaron en una base de datos operativa con más de 500 tablas y lograron elevar la generación de SQL validado del 8% aproximadamente al 78% al proporcionar terminología, reglas, relaciones y mapeos. Nascimento y sus colegas observaron cómo la precisión en la ejecución en una base de datos industrial compleja aumentaba del 41% al 65% simplemente al utilizar nombres conceptuales orientados al negocio, y llegaba al 74% una vez que también se especificaban las semánticas de las relaciones útiles.

Los modelos formales siguen la misma tendencia. En un estudio realizado por Sequeda, Allemang y Jacob, hacer preguntas directamente a una base de datos relacional empresarial arrojó una precisión de aproximadamente el 17%, mientras que utilizar un grafo de conocimiento respaldado por una ontología alcanzó un 54% aproximado. Un estudio posterior de Nascimento mantuvo SQL para la ejecución a través del almacenamiento relacional, pero primero utilizó un grafo de conocimiento para conectar los conceptos empresariales con el esquema físico. Medido mediante el F1 de enlace de esquemas, un modelo LLM por sí solo obtuvo una puntuación de alrededor de 0,85. El enfoque basado en grafos alcanzó 0,90, el enfoque con grafos y LLM 0,93, y el pipeline completo de enlace semántico con recordación perfecta 0,996.

La interpretación razonable es de tipo arquitectónico, no promocional: hacer explícita la correspondencia entre conceptos y estructuras relacionales, quitarle al modelo la capacidad de improvisación semántica y dejar la ejecución en el motor relacional, donde ya funciona bien.

Lo que sí y lo que no logró el modelo relacional

El modelo relacional de Codd proporcionó independencia de datos: las aplicaciones no deben depender de cómo se almacenan físicamente los datos. Ese logro sigue siendo importante.

El BI conversacional exige algo más específico y difícil. Un esquema analítico relacional por sí solo no detalla todos los significados empresariales necesarios para responder a una pregunta. Los nombres, las claves, las restricciones y los comentarios ayudan, y los modelos dimensionales ayudan aún más. Sin embargo, las definiciones de métricas, los roles que desempeñan los términos, las convenciones temporales, el origen de los datos y las reglas que relacionan conceptos con objetos físicos suelen quedar en la mente de las personas o en diapositivas.

Por eso han surgido glosarios, almacenes métricos, capas semánticas y catálogos alrededor de los almacenes de datos. Poco a poco, dejan claro lo que un analista o un LLM de otro modo improvisarían. Una capa semántica moderna es una solución práctica en el punto donde se consume la información empresarial. Permanece más limitada que un modelo conceptual general de la empresa, y tratar ambos como idénticos es lo que hace que los equipos terminen sorprendiéndose posteriormente.

Agregar una ontología manteniendo el almacén

En la práctica informática, una ontología describe lo que existe en el dominio de interés, es decir, entidades, relaciones y restricciones, redactadas de tal manera que el software pueda utilizarlas. Comparte su origen con el modelo relacional en la lógica predicativa: declaraciones sobre cosas y las relaciones entre ellas.

Las bases de datos han estado trabajando en esto desde hace tiempo. W3C Direct Mapping y R2RML definen cómo los datos relacionales se convierten en vocabularios RDF. El acceso a datos basado en ontologías lleva esta idea aún más lejos: un usuario realiza consultas al modelo conceptual y el sistema las traduce a SQL utilizando las fuentes ya existentes. Ontop, un gráfico de conocimiento virtual de código abierto maduro, hace precisamente eso mediante mapeos R2RML y ontologías OWL 2 QL ligeras.

La elección de OWL 2 QL tiene una justificación poco llamativa pero útil. Pertenece a la familia DL-Lite, cuyos límites son intencionales para que las consultas mediadas por la ontología sigan siendo manejables frente a grandes bases de datos relacionales. Se sacrificó el poder expresivo a cambio de la posibilidad de reescribirlo en SQL. Los trabajos sobre ontologías para almacenes y modelos multidimensionales también existían antes, representando dimensiones, mediciones y jerarquías, y derivando estructuras analíticas a partir de modelos conceptuales.

Lo que aún tiene poca adopción visible es un lenguaje de ontologías orientado directamente a las herramientas de BI modernas, uno que integra entidades empresariales, relaciones, mediciones, nivel de detalle, agregación, tiempo, procedencia y mapeos de almacenes en un único modelo regulado.

Adoptar esto no implica trasladar el almacén a una base de datos gráfica. El significado puede describirse en la ontología, mientras que los hechos permanecen en tablas relacionales y los cálculos en SQL. La materialización de un grafo es opcional, útil para cargas de trabajo que se benefician de ella, y no constituye una prueba decisiva.

Hechos almacenados y su significado

Las filas y los triples RDF están más relacionados de lo que sugieren las disputas entre herramientas. Una fila indica que una tupla pertenece a una relación nombrada, y un triple divide una proposición en sujeto, predicado y objeto. La normalización estricta ya orienta los diseños relacionales hacia hechos más pequeños. Aunque los dos no son formalmente equivalentes, su similitud resulta útil.

Para los agentes, la distinción importante no es entre tabla y gráfico, sino entre datos extensionales y significado intensional: los hechos que se almacenan y las reglas que determinan el significado de dichos hechos. Una ontología puede establecer que una clase incluye a otra, que dos predicados son inversos, que una relación es transitiva, o que una combinación específica es imposible. OWL proporciona una semántica formal para tales afirmaciones, SHACL valida las estructuras de los gráficos, y existen marcos lógicos más avanzados para cuando se necesitan.

No toda ontología se puede reescribir de manera adecuada en SQL, ya que algunos lenguajes son más expresivos de lo que pueden manejar los fragmentos de reescritura eficientes. La investigación en OBDA aborda este problema abiertamente, ofreciendo opciones para limitar la expresividad, realizar aproximaciones, materializar datos o razonar en un paso separado. Esta restricción es útil, ya que obliga a especificar claramente qué semánticas son válidas en el camino de ejecución, cuáles se compilan por adelantado y cuáles quedan fuera del perfil elegido. Hoy en día pocas empresas registran esta pérdida, por lo que se manifiesta como disputas en los canales de chat.

El contexto de un proveedor no es tu ontología

Los proveedores ya están tomando medidas al respecto. Google Cloud es un ejemplo claro, ya que varias de sus versiones de 2026 están orientadas a contextos empresariales que las máquinas pueden utilizar. Dataplex Universal Catalog fue reestructurado como Knowledge Catalog y funciona más como un grafo de contexto en tiempo real que como un registro estático. Ofrece búsqueda semántica, descripciones enriquecidas, grafos de relaciones, patrones SQL verificados, APIs de contexto y rutas de acceso para los agentes. Mientras tanto, la Interfaz Open SQL de Looker permite a los clientes JDBC consultar modelos LookML como si fueran esquemas, reutilizando las dimensiones, agregados, cálculos y relaciones ya definidos allí.

Tales lanzamientos respaldan un punto fundamental: un agente necesita algo más que acceso a filas. Necesita un contexto cuidadosamente seleccionado, modelos semánticos, relaciones, ejemplos verificados e interfaces reguladas.

Aun así, no logran alcanzar una ontología empresarial coherente y unificada. La semántica de LookML, los términos del catálogo, las definiciones de gráficos de BigQuery y el contexto escrito por los agentes son representaciones relacionadas pero distintas. A menos que la organización cuente con identificadores canónicos y mapeos explícitos entre ellas, la promesa de definir una sola vez se reduce a tener que definirlo por cada producto.

Se han perdido trimestres enteros debido a esa trampa. El gráfico de contexto de un proveedor puede ser muy valioso sin constituir la fuente formal de la verdad semántica. Úselo libremente, recordando que adoptarlo no significa poseerlo.

Seis principios de diseño

La regla que prevalece sobre todas las demás es que el significado debe ser legible tanto para los humanos como para las máquinas al mismo tiempo, y mantenerse consistente en todas las representaciones.

Proporcione significado e identidad. Cada concepto, relación, métrica, política y afirmación de calidad debe contar con un identificador estable. Un nombre es solo una etiqueta, mientras que un identificador es lo que constituye al objeto en sí. El término “cliente” aparece en paneles de control, APIs, tablas de almacén y mensajes para agentes, y todos ellos deben referirse a un mismo objeto semántico, o intencionadamente a diferentes uno si la empresa realmente maneja conceptos separados. Soporte y finanzas pueden definir al cliente activo de manera diferente, siempre y cuando nunca compartan un ID sin indicarlo.

Haga que las definiciones sean ejecutables. El texto en prosa sirve a las personas y a los modelos, pero todo lo que influye en los cálculos necesita estructura: tipos, relaciones, cardinalidades, unidades, fórmulas, nivel de detalle, tiempo válido, restricciones, reglas de mapeo y políticas. Un párrafo descriptivo en un catálogo es en gran medida una convención humana.

En las arquitecturas basadas en Google Cloud, una asignación viable es la siguiente: Knowledge Catalog almacena la identidad, las definiciones, las unidades, el propietario, el período de validez, las políticas, las relaciones y las correspondencias. LookML contiene la fórmula ejecutable, las dimensiones, las uniones y la generación de consultas. Conversational Analytics interpreta el lenguaje natural dentro de ese contexto, utilizando consultas verificadas como puntos de referencia para la regresión. Este arreglo solo es posible si los IDs cruzan intencionadamente cada uno de esos límites.

Asigne explícitamente la semántica de los mapas a los datos físicos. Supongamos que la ontología indica que un Cliente posee una Cuenta. La implementación debe entonces nombrar la relación o derivación que hace verdadera esa afirmación, y el mapeo debe versionarse junto con sus dos extremos. Ninguna herramienta de un solo clic puede transformar OWL en cada producto del catálogo. Alguien tiene que crear y mantener ese puente, de lo contrario la palabra semántica no significa mucho más que un simple branding.

Trate las relaciones como algo de primera importancia. Un rol adquiere significado por sus conexiones con procesos, organizaciones, actividades, capacidades y costos, no por una columna llamada role_type. Lo mismo ocurre con clientes, productos, contratos, cuentas y métricas. Un nombre y un texto poco precisos ya ayudan en la conversión de lenguaje natural a SQL, pero son las semánticas formales de las relaciones las que diferencian la conveniencia relacional de la claridad ontológica. Definirlas requiere un esfuerzo real, y una ontología que ignora ese costo fracasa durante su fase piloto.

Mantenga las métricas dentro del mismo modelo. Las mediciones dimensionales ya incluyen identidad, fórmula, nivel de detalle y comportamiento de agregación, y las capas semánticas permiten aprovechar aún más estas características. El significado más amplio, que abarca la propiedad, las unidades, las exclusiones, el origen, las políticas, las fechas de vigencia y los vínculos con conceptos empresariales, tiende a dispersarse en otros sistemas. La fragmentación suele ser el verdadero problema arquitectónico: una medida dimensional, una medida LookML y un término de catálogo describen cada uno una parte superpuesta de una misma idea de negocio, pero bajo tres identidades distintas.

Compila una vez, sirve de muchas maneras. Un modelo canónico debe generar o regular sus proyecciones, como LookML, vistas SQL, esquemas de API, entradas de catálogo, formas de gráfico, contratos de herramientas para agentes, documentación y pruebas de validación. Las plataformas pueden mantener su propia sintaxis, pero el significado no debe ser algo que ellas inventen.

LinkML demuestra que un modelo independiente de la tecnología puede generar DDL de SQL, DDL de BigQuery, JSON Schema, OpenAPI, OWL, SHACL, documentación y validadores. Lo que no puede hacer es elegir hechos, dimensiones, mediciones, nivel de detalle o dimensiones conformadas en nombre de nadie. Existen investigaciones sobre cómo convertir ontologías en esquemas en forma de estrella, pero no existe ninguna cadena principal que abarque todo el proceso, desde la ontología canónica pasando por un almacén dimensional gestionado y un modelo semántico ejecutable hasta la conversión de lenguaje natural a SQL basada en la ontología. Ese proceso faltante es donde radica el desafío de ingeniería, y la generación de DDL es solo una demostración sencilla.

Dos rutas y la necesidad de convergencia

La mayoría de las empresas no pueden detener el programa de almacén y reconstruirlo primero sobre una ontología. Eso está bien. La tarea consiste en lograr que el agente resuelva de manera fiable el significado de lo que se puede enviar, y en diseñar el camino táctico para que pueda evolucionar.

Bajo el Plan A, una ontología empresarial canónica posee autoridad semántica, con identificadores estables y semántica lógica explícita. Los datos físicos no se mueven, y la ontología se mapea a representaciones relacionales y de otro tipo. Las métricas analíticas se convierten en proyecciones compiladas. Los agentes obtienen conceptos formales, relaciones, políticas y orígenes, y los cambios se versionan y lanzan de la misma manera que el código. Las representaciones dentro de los productos se generan a partir de, o se mapean a, la semántica que posee la empresa.

El Plan B comienza desde el nivel ya ocupado: una capa de métricas gestionada junto con un catálogo y un modelo de contexto, a los cuales se añaden intencionadamente identificadores canónicos estables. El almacén mantiene su autoridad, y la correspondencia entre objetos semánticos y tablas, columnas, uniones y filtros se registra por escrito. Los agentes seleccionan campos y métricas certificadas en lugar de tablas en bruto, obteniendo contexto de servicios de contexto, consultas verificadas y búsquedas que respetan los permisos. Las métricas, las correspondencias, las preguntas clave y las pruebas de regresión semántica se integran en el pipeline CI/CD. Los identificadores propios de un producto nunca se convierten en identidades empresariales, y los enlaces cruzados mantienen posible la migración.

Un Plan B concreto en Google Cloud combina Knowledge Catalog, que proporciona contexto y posibilidades de búsqueda, con Looker, donde un modelo semántico regulado limita el análisis conversacional a objetos semánticos certificados, mantiene las consultas verificadas como puntos de referencia para la detección de regresiones y almacena los identificadores empresariales fuera de cualquier producto en particular. Knowledge Catalog es similar a una ontología solo en un sentido restringido, ya que ofrece contexto y relaciones tipificados para los agentes, pero no constituye un sistema ontológico formal completo. Considérelo como un material de referencia y no como una norma sagrada.

El riesgo radica en una capa semántica táctica cuyos identificadores y lógica nunca pueden trasladarse a un modelo más formal. Un Plan B que no puede converger es un callejón sin salida adornado con paneles de control.

Resuelva primero, luego trabaje con tablas

Un enfoque sólido de BI conversacional no debería comenzar con la selección de tablas, sino con la resolución semántica.

Tomemos la pregunta “¿Ha aumentado la rotación entre los clientes minoristas de alto valor este trimestre?”. Los términos rotación, cliente minorista de alto valor y este trimestre deben convertirse primero en objetos gestionados antes que nada más. Dichos objetos contienen la definición de la métrica, su clasificación, la convención de tiempo, las dimensiones permitidas, las asignaciones de origen y las políticas aplicables. Solo después de eso debería la capa de ejecución escribir la consulta física.

Los equipos responsables de los ciclos deberían poder describir los procesos en ocho pasos:

1. Pregunta y contexto del usuario
2. Resolución semántica en conceptos y métricas gestionadas
3. Recuperación de contexto filtrada por políticas y permisos
4. Asignación de objetos semánticos a datos físicos
5. Generación de la consulta o del plan de herramientas
6. Ejecución y conciliación
7. Respuesta respaldada por evidencias y origen

Regresión o evaluación semántica, además de acciones reguladas cuando sea aplicable

La mentalidad está lejos de consistir en pegar el esquema analítico en el prompt y esperar. El LLM aún puede aclarar la intención y elaborar un plan, pero lo hace a través de objetos semánticos regulados y contratos de herramientas, no decodificando el vocabulario del CFO de una tabla llamada fct_rev_v3.

Las consultas verificadas son valiosas como pruebas y ejemplos, pero no representan la semántica. Solo demuestran que una pregunta se resolvió con una implementación aceptada en un momento dado. El significado subyacente sigue necesitando su propia identidad y definición.

Qué no cuenta como arquitectura semántica

Un catálogo lleno de descripciones en prosa facilita el descubrimiento. No se trata de un sistema semántico ejecutable.

Apuntar por defecto a esquemas de almacén sin procesar y denominar eso como BI de autoservicio solo traslada el riesgo semántico a un modelo probabilístico.

Duplicar cada dato del almacén en un grafo de conocimiento “para IA”, sin un beneficio claro en su implementación, genera una segunda versión de la realidad empresarial que se retrasa debido a demoras en la sincronización.

Separar las métricas de la ontología de manera tan absoluta que un mismo concepto empresarial acabe teniendo identidades contradictorias tanto en el BI como en los modelos de conocimiento, crea conflictos futuros.

Confundir la representación con la semántica, por ejemplo al suponer que un grafo es intrínsecamente más semántico que un modelo dimensional, es un pensamiento basado en prácticas erróneas sin fundamento. Los modelos dimensionales, las capas semánticas, los grafos de conocimiento y las ontologías codifican el significado en diferentes grados, y elegir un grafo por sí solo no añade significado alguno.

Tratar los metadatos o relaciones generados por la IA como hechos, sin que se indique su origen ni su estado de revisión, es la forma en que la ficción plausible se convierte en política oficial.

El objetivo en una frase

La gente desea solicitar las cifras del mes pasado con la misma naturalidad con la que preguntan por el clima. Eso ya no es fantasía. Se está asignando a los software la tarea semántica que antes realizaban analistas e ingenieros sin que se notara, y obtener respuestas consistentes implica hacer explícita dicha tarea.

Ni un LLM integrado en un almacén ni un catálogo combinado con búsqueda vectorial constituyen el objetivo final. Se trata de un sistema semántico regulado en el que los conceptos, relaciones, métricas, restricciones, políticas, calidad y origen mantienen un mismo significado tanto para las personas como para las máquinas, vinculados mediante mapeos formales a los datos subyacentes.

Gran parte de los datos subyacentes sigue siendo mejor procesada en motores analíticos relacionales y SQL, y la tecnología semántica u ontológica no está destinada a reemplazarlos. Su función es completar el modelo a un nivel que un esquema relacional nunca estuvo diseñado para manejar por sí solo, incluso después de que el modelado dimensional y una nomenclatura cuidadosa hayan llevado el modelo tan lejos como es posible.

Cuando escribir y mantener una ontología analítica completa aún no es realista, implemente una capa semántica gestionada, pero mantenga el encabezado fijo. La semántica debe migrar hacia arriba, desde los paneles de control y las consultas, hacia un modelo empresarial de primera categoría, donde cada capa correspondiente a un producto se trate como una vista compilada.

El objetivo no es una única base de datos, herramienta o sintaxis. Se trata de un único significado que una persona, un panel de control, una aplicación y un agente de IA interpreten de la misma manera. Si los cuatro no están de acuerdo, el problema no es el LLM. Es un problema de identidad que se ha pospuesto.

Leer más

• Conceptos de LangGraph en lenguaje sencillo: estado, memoria y orquestación — Antes de escribir código: qué significan la orquestación, el tiempo de ejecución, los agentes con estado, la memoria a corto y largo plazo, los multiagentes y la intervención humana en LangGraph.
• Notas prácticas: Evaluación de agentes y detección de desviación — qué ofrece el nuevo coding-agent — Guía paso a paso de las Notas prácticas: Evaluación de agentes y detección de desviación — qué ofrece el nuevo coding-agent: contratos, verificaciones y espacios para código adicional para los equipos que implementan este patrón.