Por qué RAG no es suficiente: una capa semántica para consultas de gráfico, SQL y vectores
RAG falla en preguntas empresariales de múltiples saltos, numéricas y ambiguas. Una capa semántica se encarga de la descomposición, el enrutamiento y el mapeo de esquemas, con Apache Ossie para garantizar portabilidad.
Los modelos de lenguaje han facilitado la expresión de preguntas empresariales en palabras sencillas. Obtener una respuesta es algo distinto a comprender el significado de la pregunta en varios sistemas de datos. Tomemos esta:
Imagínese a un analista preguntando: ¿qué fondos cotizados en bolsa poseen empresas que son socias estratégicas de NVIDIA, gestionan más de mil millones de dólares y reciben una evaluación positiva en los últimos informes de investigación?
Parece una sola pregunta, pero en realidad implica tres tipos de tareas:
- NVIDIA, socio estratégico, fondos ETF: representar las relaciones en un grafo.
- Valor total de activos superior a 1 mil millones de dólares: filtrado numérico preciso.
- Informes de investigación recientes positivos: comprensión de texto no estructurado.
Debajo de esto hay un problema más profundo. ¿Qué significa AUM en el modelo de datos subyacente, y qué fuente es la autoridad al respecto? Antes de que un sistema pueda responder correctamente, debe comprender el significado de los datos y no solo los datos en sí. La ingeniería semántica busca cerrar esa brecha.
Dónde termina RAG
El flujo típico de RAG recupera pasajes relevantes y permite que el modelo responda a partir de ellos. Esto es excelente cuando la tarea consiste en encontrar texto relevante y responder a partir de él. Las preguntas empresariales suelen requerir algo más que similitud, y la recuperación vectorial pura falla de cuatro maneras reconocibles.
Recuperación fragmentada
Imagínese un manual de producto dividido en tres partes:
Chunk 1: Atlas Enterprise — vendor, category
Chunk 2: Pricing — base fee, usage fee
Chunk 3: Risks — lock-in, migration, data residency
Alguien pregunta por los precios y riesgos de Atlas Enterprise. El nombre del producto puede aparecer solo en el primer fragmento. El segundo y el tercero contienen la respuesta, pero tras su división ya no conservan el contexto de la entidad. El enriquecimiento de metadatos, la recuperación de relaciones padre-hijo y el reordenamiento son útiles, pero la fragmentación sigue siendo una debilidad fundamental.
Sin trazabilidad de relaciones
Ahora, pregúntese qué ETFs contienen empresas que son socias de NVIDIA. La ruta lógica para encontrar la respuesta no se basa en una sola coincidencia de palabras clave:
NVIDIA
↓ HAS_STRATEGIC_PARTNER
Company
↓ HELD_BY
ETF
La búsqueda vectorial encontrará documentos que mencionen a NVIDIA, a sus socios o a ETFs. Lo que no puede hacer de manera fiable es concluir que esas menciones forman una relación de múltiples pasos específica. Un grafo puede recorrer el camino de forma explícita:
?nvidia corp:hasStrategicPartner ?company .
?etf etf:hasConstituent ?company .
El texto similar no es lo mismo que una conexión entre entidades.
Ambigüedad de entidad
Un nombre como “NVIDIA” puede referirse a varias cosas:
NVIDIA → Company
NVIDIA International → Subsidiary
NVIDIA AI Enterprise → Product
Sus embeddings pueden estar cerca uno del otro, pero son entidades diferentes de tipos distintos. Una ontología proporciona identidad, tipo y relaciones, algo que la similitud de texto no puede hacer.
Sin filtrado numérico exacto
Una solicitud como “clientes con ingresos anuales superiores a 1 millón de dólares y probabilidad de abandono inferior al 5%” es un SQL simple:
SELECT customer_id
FROM customer_metrics
WHERE annual_revenue > 1000000
AND churn_probability < 0.05;
Los embeddings capturan la similitud. No realizan de manera fiable operaciones como mayor que, menor que, BETWEEN, agregación o clasificación.
Una pregunta, varios motores
La pregunta planteada requiere más de una estrategia de recuperación, y cada motor se adapta a un tipo diferente de razonamiento:
Vector → meaning and unstructured text
BM25 → exact lexical matching
Graph → relationships and multi-hop traversal
SQL → filters, numbers and aggregation
La tarea ha dejado de ser una recuperación de datos y se ha convertido en la ejecución de consultas federadas. La federación plantea tres problemas más difíciles: la descomposición, el enrutamiento y el mapeo.
Descomposición
El sistema debe dividir la pregunta en lenguaje natural en unidades que pueda ejecutar:
1. Resolve NVIDIA as a Company
2. Find its strategic partners
3. Find ETFs holding those companies
4. Filter AUM > $1B
5. Retrieve the latest research reports
6. Identify positive views
Ruteo
Cada unidad debe dirigirse a la fuente que sea autoritativa para ella:
relationships → Graph
AUM → SQL
research view → Vector Search
Conectar las bases de datos no es suficiente. El sistema debe saber qué fuente responde a cada parte.
Mapeo
A menudo este es el paso más difícil. Un usuario indica AUM, mientras que la base de datos puede contener campos como estos:
NET_ASSET_AMT
AUM_USD
FUND_NET_ASSET
¿Cuál es el concepto gobernado? De manera similar, un ETF podría ser fund:ETF en el grafo, dim_fund.fund_id en SQL y metadata.product_id en el índice vectorial. El sistema necesita un puente entre el vocabulario empresarial y los esquemas físicos. Esto se denomina anclaje de esquemas, y sin él un LLM puede generar SQL perfectamente creíble contra columnas que no existen.
La capa semántica
Una capa semántica se sitúa entre lo que las personas quieren expresar y cómo se almacenan los datos. En lugar de mostrarle a un LLM cientos de tablas y propiedades en bruto, se exponen los conceptos:
Company
Strategic Partner
ETF
Constituent
Assets Under Management
Research Report
y asignarle un significado a cada uno:
Assets Under Management
├─ business definition
├─ currency / unit
├─ effective date
├─ authoritative source
└─ physical column
La capa puede entonces participar directamente en el ciclo de vida de la consulta. Eso cambia la función de una ontología: deja de ser una documentación estática para convertirse en un contexto ejecutable para el sistema de IA.
Cómo podría organizarse
En un sistema que combina una base de datos relacional, un grafo de conocimiento y búsqueda vectorial, la capa podría estructurarse de la siguiente manera:
semantic_layer/
├── ontology/
│ ├── tbox.ttl # classes and relationships
│ └── vocabulary.yaml # business terms and synonyms
├── schemas/
│ ├── rdb.yaml # tables, columns, types
│ ├── graph.yaml # entities, predicates, graph paths
│ └── vector.yaml # indexes and document metadata
├── semantics/
│ ├── metrics.yaml # governed metrics such as AUM
│ ├── mappings.yaml # concept → physical source mapping
│ └── relationships.yaml # cross-domain relationships
├── query/
│ ├── routing.yaml # Graph vs SQL vs Vector routing
│ └── examples.yaml # representative query plans
└── validation/
└── rules.yaml # allowed fields and business rules
En ese esquema, tbox.ttl es donde se declaran clases como Company y ETF, junto con el enlace HAS_STRATEGIC_PARTNER entre ellas, mientras que rdb.yaml documenta las tablas y columnas reales. mappings.yaml relaciona el concepto de Activos bajo gestión con la columna fund_metrics.net_asset_amt. Finalmente, routing.yaml permite al planificador decidir si un paso se dirige al grafo, a SQL o a la búsqueda vectorial.
Los archivos exactos dependen de la implementación. Lo importante es escribir de forma explícita el significado, las asignaciones físicas y los caminos de ejecución válidos, en lugar de dejar que el LLM los descubra nuevamente en cada consulta. Cuatro tareas se benefician directamente:
- Disambiguación: la empresa y los productos con nombres similares pertenecen a clases de entidad diferentes.
fund_metrics.net_asset_amt.Por eso la ingeniería semántica es más amplia que simplemente dibujar una ontología. El objetivo es hacer que el significado empresarial sea utilizable en tiempo de ejecución, a través de un vocabulario compartido, una ontología, definiciones de métricas, relaciones, mapeos de esquemas, reglas de negocio, metadatos de origen y verificaciones de validación. Visto de esta manera, una capa semántica se asemeja mucho más a una etapa de compilador para datos empresariales que a un glosario.
De la capa al tiempo de ejecución
Muchos diseños de agentes hoy en día se parecen a esto:
User → LLM → Tools
El LLM recibe descripciones de las herramientas y decide cómo nombrarlas. Una arquitectura semántica puede estar más restringida:
User
↓
Semantic Resolution
↓
Logical Query Plan
↓
Validated Execution
↓
Evidence
↓
LLM
El modelo se evita tener que adivinar cómo manejar cada tabla, métrica, predicado gráfico y regla de negocio. Funciona dentro de un entorno semántico delimitado. El objetivo es lograr una mejor interfaz entre el modelo y los datos empresariales, no simplemente un modelo más grande.
Por qué es importante un formato de intercambio abierto
Las propias definiciones semánticas tienden a fragmentarse. Una empresa podría definir la Ingresos Netos de manera separada en su plataforma de datos, herramienta de BI, catálogo, aplicación de análisis y agente de IA, y con el tiempo las definiciones se van alejando entre sí.
Open Semantic Interchange (OSI) tiene como objetivo solucionar esto. La iniciativa se unió al Apache Incubator en junio de 2026 y continúa como Apache Ossie (en fase de incubación). Su propósito es proporcionar a los sistemas una forma neutral de intercambiar metadatos semánticos. La especificación principal está escrita en YAML y abarca conjuntos de datos, campos, relaciones, métricas y contexto de IA. Un modelo simplificado se ve así:
version: "0.2.0.dev0"
semantic_model:
- name: investment_products
datasets:
- name: etf
source: analytics.dim_etf
fields:
- name: aum
datatype: Decimal
ai_context:
synonyms: ["assets under management", "net assets"]
metrics:
- name: total_aum
expression:
dialects:
- dialect: ANSI_SQL
expression: SUM(etf.aum)
La sintaxis importa poco. Lo que realmente cuenta es que aum reciba una definición que incluya su origen físico, tipo de dato, lógica métrica y sinónimos adecuados para la IA, y que dicha definición se transmita como metadatos portátiles en lugar de ser reescrita dentro de cada herramienta.
┌→ BI
├→ Analytics
Semantic Model ───┼→ AI Agents
├→ Data Catalogs
└→ Data Applications
Un catálogo podría mostrar la definición oficial y el linaje de AUM, y un agente de IA podría leer los mismos metadatos para asignar la expresión “activos bajo gestión” al campo correcto en lugar de adivinarlo a partir de esquemas brutos.
Más allá de eso, Ossie valida los modelos contra un JSON Schema, permite varios dialectos de expresión y define un modelo de conversor para pasar entre formatos de diferentes proveedores. Las tareas planificadas incluyen métricas más detalladas, mayor composibilidad, integración con catálogos, semántica de relaciones más precisa y representación ontológica.
La dirección orientada a la ontología es especialmente interesante para la IA, ya que las métricas y dimensiones por sí solas no le proporcionan a un agente hechos como estos:
Customer is an Organization
Company HAS_SUBSIDIARY Company
Company OWNS_PRODUCT Product
Document DESCRIBES Entity
Si los modelos semánticos y las ontologías más complejas convergen, los sistemas de IA podrían recibir un significado empresarial portable y no solo esquemas portables.
Volver a la pregunta de NVIDIA
Un sistema de consultas semánticas puede procesar la pregunta inicial paso a paso, con cada decisión basada en metadatos explícitos. Sin una capa semántica, el LLM debe inferir el significado, la fuente, el esquema y las relaciones en cada paso, y una sola suposición errónea puede romper toda la cadena.
El cambio más amplio
La IA empresarial ha pasado por varias etapas:
LLM + Prompt
↓
LLM + RAG
↓
LLM + Tools
↓
LLM + Federated Data
↓
Semantic Layer + Federated Execution + LLM
La recuperación indica qué documentos parecen relevantes. Un grafo muestra cómo están relacionadas las entidades. SQL determina qué registros cumplen con condiciones exactas. La capa semántica se ocupa de la pregunta inicial: ¿cómo se traduce esta pregunta al vocabulario de nuestros datos?
Los sistemas seguirán incorporando bases de datos, grafos, documentos, APIs y herramientas, y solo conectar más datos no será suficiente. También es necesario conectar el significado. La IA empresarial podría depender menos de proporcionarle a un modelo datos adicionales y más de darle una comprensión clara de lo que representan esos datos.
Leer más
- Corrigiendo RAG con una ontología y un grafo de conocimiento en documentos de semiconductores — Cómo un conjunto de documentación EDA basado en DITA obtuvo una ontología RDF/OWL, un grafo Neo4j y una recuperación restringida por la ontología, reduciendo las consultas posteriores en un 30%.
- Manteniendo un almacén de vectores fiable: ciclo de vida, arrendamiento, metadatos, búsqueda híbrida — Cómo operar un almacén de vectores para RAG en producción: estados del ciclo de vida de los documentos, actualización de embeddings, filtrado por arrendatarios, búsqueda híbrida, esquema de metadatos y seguimiento de las recuperaciones.