Capa semántica frente a capa de contexto¶
«Ya tenemos dbt» —o Cube, o MetricFlow— es la objeción más razonable a una capa de contexto, y merece una respuesta de verdad y no la misma idea con otro nombre.
La versión corta: la capa semántica modela tus métricas; la capa de contexto gobierna todo lo que tus métricas no saben decir. Son capas adyacentes, no competidoras: Renbase lee tu proyecto de dbt como fuente y sirve sus definiciones junto al conocimiento que nunca llegó al YAML. Nadie tira una capa semántica para adoptar una capa de contexto.
Qué hace bien la capa semántica¶
Primero el mérito, porque son herramientas serias:
- dbt Semantic Layer / MetricFlow define las métricas una vez, en código, junto a los modelos que las materializan — revisadas en pull requests, versionadas en git, consistentes en cualquier herramienta de BI que las consulte.
- Cube añade una capa universal con caché, control de acceso y APIs, pensada para servir las mismas métricas gobernadas a dashboards, analítica embebida y, cada vez más, agentes de IA.
Si una pregunta puede formularse como «agrega esta medida por estas dimensiones» sobre tablas modeladas, la capa semántica la responde bien y de forma repetible. Para eso existe.
Dónde se queda corto el YAML¶
El conocimiento que rompe a los agentes de datos en producción rara vez es una definición de métrica que falta. Es la parte que no tiene campo donde vivir:
El conocimiento tribal condicional. «Para CRM, los deals nuevos de USCAN desde 2025 están en Affinity; los leads globales anteriores siguen en Salesforce.» Eso es una regla con ámbito y caducidad, no una medida con dimensiones. No hay clave de YAML para ella, así que se queda en Slack — y todo agente que no lea Slack se equivoca.
Los documentos. La política que explica por qué la métrica excluye los créditos promocionales vive en un PDF, una wiki, un acta. La capa semántica no ingiere documentos; para la capa de contexto son contenido de primera, indexado y citable junto a las definiciones.
Las disputas y la deriva. Cuando finanzas y producto tienen cada uno una definición aprobada de active_user, la capa semántica guarda la que se mergeó. Renbase devuelve las dos, marcadas como conflicto y con su procedencia — y cuando la fuente de una definición cambia o desaparece, la entrada queda marcada como caducada y las respuestas lo dicen.
Un contrato de respuesta para agentes. La capa semántica devuelve resultados de consulta. No tiene el concepto de abstenerse, de citar a quien aprobó, ni de decirle a un agente «esta definición ha caducado». Ese contrato —citar o declinar, y exponer los conflictos— es lo que los agentes necesitan para dejar de inventar cifras con seguridad.
Lado a lado¶
| Capa semántica (dbt SL, Cube) | Capa de contexto (Renbase) | |
|---|---|---|
| Objeto central | Métricas y dimensiones sobre tablas modeladas | Definiciones y documentos en un corpus gobernado |
| Reglas condicionales | No tienen sitio | Entradas de primera clase con ámbito, versión y aprobación |
| Documentos | Fuera de alcance | Ingeridos, indexados y citables |
| Definiciones en conflicto | La que esté en el repo | Se devuelven ambas, marcadas, con procedencia |
| Caducidad | No se rastrea al responder | Marcada; la frescura viaja con cada respuesta |
| Interfaz para agentes | SQL/API para consultas de métricas | Herramientas MCP: resolución exacta, recuperación, respuestas citadas, abstención |
| Ciclo de autoría | Ingenieros, vía pull requests | Los conectores proponen borradores; cualquier aprobador revisa en el panel |
| Relación con tu dbt | Es tu dbt | Lo lee como fuente; nunca lo sustituye |
Cuándo basta la capa semántica sola¶
La honestidad corta en los dos sentidos. No necesitas una capa de contexto si:
- Todas las preguntas de tus agentes son consultas de métricas sobre tablas modeladas, y las respuestas no dependen de documentos ni de excepciones condicionales.
- Tus definiciones son estables, indiscutidas y están completas en el repo — sin ningún «depende de la región y del año».
- Los consumidores son dashboards y analistas, no agentes que deben justificar sus respuestas ante clientes o auditores.
Si, en cambio, tus agentes siguen fallando por cosas que no están escritas en ningún sitio —o están escritas en cuatro sitios contradictorios—, ese es el hueco que la capa de contexto viene a cerrar. La página de la capa de contexto describe la categoría al completo, y frente al RAG gestionado cubre el lado de recuperación de la misma pregunta.
Fuentes¶
- Documentación del dbt Semantic Layer
- Semantic layer for AI agents (Cube) — la visión del contexto de agentes desde la capa semántica
- Your Data Agents Need Context (a16z) — la tesis de la capa de contexto a la que responde esta página