Más allá de un único camino de recuperación: conocimiento canónico, RAG y consultas en tiempo real para agentes empresariales

Un titular que afirma que un nuevo formato abierto está reemplazando la base de datos vectorial suscita escepticismo. Lo que realmente merece atención de esa afirmación no es la historia del reemplazo, sino una pregunta arquitectónica más importante: ¿se están tratando demasiados tipos diferentes de conocimiento empresarial a través del mismo mecanismo de recuperación?

Dentro de una empresa, el “conocimiento” abarca cosas muy distintas. Una solicitud de soporte cuenta como conocimiento, al igual que un documento de diseño de 60 páginas, un esquema de base de datos, una definición de métricas o un manual de procedimientos para incidentes. También cuenta el número actual de envíos retrasados. Estos elementos se comportan de manera diferente, por lo que resulta extraño que un agente de IA pueda acceder a todos ellos de la misma forma.

El enfoque útil no es comparar OKF con RAG, ni tampoco significa que las bases de datos vectoriales estén obsoletas. Se trata de una triaje práctica con tres categorías: conocimiento a recuperar, conocimiento a conservar como versión canónica y conocimiento para consultas en tiempo real.

Un problema empresarial común

Imaginemos una empresa ficticia de logística tipo SaaS con unos 120 ingenieros. Al igual que muchas firmas que prueban agentes, ha conectado documentos internos, flujos de trabajo de soporte, sistemas operativos, métricas y manuales de procedimientos a una plataforma de agentes. Para la mayoría de las preguntas, esto funciona bien.

Luego alguien pregunta por la tasa de entregas a tiempo, y el sistema muestra tres definiciones diferentes:

• El equipo de datos cuenta los envíos que llegan en la fecha prometida.
• El panel de control del producto aplica un cálculo ligeramente distinto.
• La documentación dirigida a clientes omite los pedidos cancelados y las devoluciones.

Ninguno de estos es absurdo. Diferentes equipos los crearon por razones distintas. El problema surge cuando un agente debe decidir cuál es la versión autoritativa. Una base de datos vectorial puede indicar qué elementos son semánticamente similares, pero no tiene forma de saber qué versión la empresa ha declarado como la definición oficial. Eso es un problema aparte.

La relevancia no equivale a la autoridad

Un flujo RAG estándar devuelve todos los documentos que coinciden. Si tres documentos describen una misma métrica de tres maneras diferentes, todos aparecerán en el resultado. Una mejor clasificación, metadatos adicionales, un nuevo proceso de clasificación, un valor top_k mayor o una ventana de contexto más amplia pueden ser de ayuda. Ninguno de estos métodos responde a la pregunta organizacional sobre cuál es la definición oficial.

Por lo tanto, la verdadera debilidad no radica simplemente en que RAG genere ilusiones. La relevancia y la autoridad son propiedades diferentes, y los agentes empresariales necesitan cada vez más ambas.

Cuando la estructura es el significado

Otra razón por la cual no todo el conocimiento encaja en un único proceso de recuperación tiene que ver con su forma. Tome una tabla con diez filas y siete columnas: su significado no reside únicamente en las palabras, sino en la forma en que los encabezados, las etiquetas de las filas, los valores, las unidades y el contexto circundante se relacionan entre sí.

Si se divide esa tabla en fragmentos de 256 tokens, uno de ellos podría contener solo un par de encabezados, como “región” y “ingresos”, mientras que otro podría incluir “Este: 2.1M” y “Oeste: 1.8M”. El modelo podría reconstruir correctamente esa relación o no hacerlo.

En el caso de la prosa, generalmente se desea dividirla en fragmentos. Pero para el conocimiento estructurado, esto se convierte en un desvío extraño:

1. empezar con la estructura
2. convertirla en texto
3. dividir el texto en fragmentos
4. incorporar los fragmentos
5. recuperar algunos de ellos
6. pedir al modelo que reconstruya la estructura original

En algún momento surge la pregunta de si ese elemento debería haberse fragmentado en absoluto. Lo mismo aplica a los esquemas de bases de datos, las rutas de unión, las reglas de configuración, las fórmulas de métricas, los SLA y los procedimientos operativos. El contenido estructurado no está prohibido en RAG. El punto es que la estructura merece un tratamiento especial cuando su pérdida cambia el significado.

La base de datos vectorial nunca fue la fuente de verdad

La empresa ficticia tenía otro problema familiar: el conocimiento estaba disperso. Los esquemas se describían en comentarios de la base de datos, wikis de GitHub, Confluence y archivos de migración. Las definiciones de métricas se encontraban en paneles de análisis, especificaciones de productos, documentos del equipo de datos y antiguas presentaciones. Los manuales de operaciones estaban repartidos en Notion, tickets de incidentes, Slack y GitHub. Parte de la lógica de unión residía principalmente en la memoria de quien había estado más tiempo en el proyecto.

Construir una base de datos vectorial sobre esa estructura no generó una fuente de verdad. En su lugar, creó un índice buscable de las inconsistencias existentes. Eso tiene valor, pero no constituye gobernanza.

Qué añade OKF

Lo que destaca del Formato de Conocimiento Abierto no es Markdown, que ya existe. Se trata de la idea de hacer que el conocimiento empresarial sea explícitamente legible por máquinas, al mismo tiempo que se mantiene fácil de usar para los humanos. En concepto, un archivo de conceptos comienza con metadatos estructurados:

type: metric
name: on_time_delivery_rate
owner: data-platform
reviewer: product
trust_tier: verified
stale_after: 1 day
related:
- shipments
- sla_definition

y continúa con una explicación escrita para las personas:

# On-Time Delivery Rate
Percentage of shipments delivered on or before the current
promised delivery date.
## Excludes
- cancelled shipments
- test orders
- returns

El agente ya no recibe simplemente algún texto sobre la entrega a tiempo. También puede aprender quién es el responsable de la definición, si está actualizada, si ha sido verificada, de qué depende y qué otros conceptos están relacionados con ella. La pregunta pasa de saber qué fragmento se parece más a qué concepto es canónico y si es seguro utilizarlo.

OKF no reemplaza a RAG

Aquí la conclusión difiere del título. Una imagen más precisa es una progresión: el conocimiento canónico se encuentra en OKF, el conocimiento exploratorio en RAG, y el estado actual en los sistemas en tiempo real.

Conocimiento canónico abarca esquemas de bases de datos, definiciones de métricas, SLA, reglas de negocio, guías de operación e información sobre responsabilidades. La pregunta que se le hace suele ser cuál es la definición oficial y actual.

Conocimiento exploratorio abarca informes históricos, historial de incidentes, conversaciones de soporte, documentos de diseño, estudios de caso y comentarios de los clientes. La pregunta aquí es qué información es relevante para lo que se está buscando. Aquí es exactamente donde RAG demuestra su fortaleza.

Estado en tiempo real incluye la tasa de puntualidad actual, el saldo actual del cliente, incidentes activos, pedidos pendientes y niveles de inventario. La pregunta es qué es cierto en este momento, y un índice vectorial probablemente no sea el lugar adecuado para responderla. El sistema operativo que gestiona esos datos debe proporcionarlos.

Algunos datos no deben ser recuperados

Aquí es donde la arquitectura se vuelve más interesante. Supongamos que un usuario solicita los cinco mejores clientes por ingresos de este trimestre. Un diseño determinado extrae documentos y datos al índice y permite que el modelo los ordene. Eso es posible, pero existe un flujo mejor: el agente busca el significado canónico de “ingresos”, crea una consulta y la ejecuta contra el sistema de registros. Por ejemplo:

SELECT
customer_name,
SUM(revenue) AS total_revenue
FROM sales_data
WHERE quarter = 'Q3_2026'
GROUP BY customer_name
ORDER BY total_revenue DESC
LIMIT 5;

El agente ahora obtiene dos cosas de dos fuentes diferentes. El significado proviene de la capa de conocimiento canónica, mientras que los valores actuales provienen del sistema que realmente posee los datos. El agente ya no recupera datos directamente; primero obtiene la estructura necesaria y luego consulta el sistema en tiempo real.

Un agente, tres vías de conocimiento

Teniendo en cuenta esta distinción, algunas preguntas de ejemplo se enrutan de manera diferente:

• ¿Qué significa la entrega a tiempo? Consulte la definición canónica de la métrica.
• ¿Cuál es la tasa de entrega a tiempo de hoy? Utilice la lógica de cálculo de la definición canónica y luego consulte el almacén en tiempo real.
• ¿Por qué disminuyó la tasa el último trimestre? Combine la definición canónica con datos históricos del almacén, y posiblemente con información extraída de informes de incidentes y notas de los transportistas mediante técnicas como RAG.

¿Qué sucedió con el cliente X en el primer trimestre? Realice una búsqueda entre los tickets, notas e informes anteriores.

Hay una interrupción en la base de datos, ¿qué hacer ahora? Utilice el manual de procedimientos canónico.

El agente es el mismo, pero los caminos difieren. Eso es algo más productivo de discutir que si se están reemplazando las bases de datos vectoriales.

El enrutador se traslada al centro

Con varios caminos de conocimiento, algo debe elegir entre ellos. Un primer enrutador puede ser deliberadamente simple.

class HybridKnowledgeRouter:
    def __init__(self, okf, rag):
        self.okf = okf
        self.rag = rag

    def classify(self, query: str) -> str:
        q = query.lower()

        if any(word in q for word in [
            "schema", "column", "definition",
            "metric", "sla", "runbook"
        ]):
            return "canonical"

        if any(word in q for word in [
            "history", "report", "example",
            "case study", "what happened"
        ]):
            return "exploratory"

        if any(word in q for word in [
            "today", "current", "now",
            "latest value", "how many"
        ]):
            return "live"

        return "hybrid"

Su método de contexto sigue este procedimiento:

def get_context(self, query: str):
    query_type = self.classify(query)

    if query_type == "canonical":
        return self.okf.lookup(query)

    if query_type == "exploratory":
        return self.rag.search(query)

    if query_type == "live":
        concept = self.okf.lookup_relevant_schema(query)
        return {
            "concept": concept,
            "requires_live_query": True
        }

    return {
        "okf": self.okf.search(query),
        "rag": self.rag.search(query)
    }

Esto no es una clasificación de nivel de producción, lo cual es aceptable. El primer objetivo es simplemente averiguar si la separación es útil.

¿Por qué no simplemente BM25 o metadatos mejores?

Antes de añadir otro mecanismo, la idea merece una prueba adecuada.

BM25. Para texto estructurado puede ser excelente. Los nombres exactos de los campos son importantes, lo mismo que las palabras clave, y un ranking determinista ayuda. En consultas similares a esquemas puede superar a los embeddings. Pero deja la arquitectura subyacente sin cambios. Una tabla colocada en un índice de búsqueda debe seguir representándose y recuperándose de alguna manera, y el resultado son fragmentos mejores, que siguen siendo fragmentos. BM25 mejora la recuperación. No crea autoridad, propiedad, actualidad ni semántica canónica.

Más metadatos de RAG. Esto también es razonable. Se pueden adjuntar campos como los siguientes, con un filtrado estricto aplicado encima:

document_type
owner
version
effective_date
trust_tier
source

Eso puede ser suficiente para muchos sistemas. Pero una vez que los metadatos se convierten en el mecanismo que indica al agente qué información es autoritativa, actual, relevante y segura, ya se está creando una capa de conocimiento estructurada. Para entonces, expresar el concepto directamente resulta más ordenado que mantenerlo como un documento extraño enterrado en un índice de uso general.

Las consultas en tiempo real plantean un problema de seguridad

En el momento en que se permite a un LLM generar consultas contra sistemas operativos, los riesgos aumentan drásticamente. Nadie quiere esto:

DROP TABLE shipments;

Ni esto:

SELECT * FROM shipments;

Ejecutar una consulta contra una tabla con 50 millones de filas solo porque el modelo se mostró curioso. La mejor estrategia es no otorgar al agente acceso a la base de datos, sino darle la capacidad de realizar consultas restringidas. Un concepto de esquema puede describir la forma permitida de una consulta:

data_source: analytics.shipments
allowed_columns:
  - shipment_id
  - customer_id
  - carrier_id
  - status
  - promised_delivery_date
  - actual_delivery_date

required_filters:
  - tenant_id

max_result_rows: 1000
access_mode: read_only

Luego, la consulta generada se valida en relación con esa política:

def validate_query(query, policy):
    checks = [
        uses_allowed_table(query, policy),
        selects_allowed_columns(query, policy),
        contains_required_filters(query, policy),
        respects_row_limit(query, policy),
        is_read_only(query),
    ]

    if not all(checks):
        raise UnsafeQueryError()

    return True

En producción, aquí deben incluirse pasos adicionales: credenciales de ejecución separadas, aislamiento de usuarios aplicado fuera del modelo, permisos a nivel de base de datos, límites de filas y costos, y registro de cada consulta que se ejecuta. El principio rector es que el modelo propone y la infraestructura decide si dicha propuesta puede ejecutarse.

El conocimiento canónico necesita un responsable

Una única fuente de verdad suena maravillosa hasta que nadie la actualiza. La responsabilidad y la actualidad son más importantes que el formato del archivo. Un concepto podría contener campos como estos:

owner: data-platform@company.io
reviewer: product-analytics@company.io
stale_after: 7 days

Cada vez que se edita una definición de métrica, la actualización de conocimiento correspondiente debe formar parte de ese mismo documento. Cuando cambia un esquema, su forma canónica debe ser regenerada o revisada. No se debe volver a escribir lo que ya conoce la base de datos; por eso se generan los hechos conocidos por la máquina:

for table in database.tables():
  generated = generate_okf_schema(table)
  save(generated)

Los seres humanos luego revisan qué necesita ser evaluado: el significado comercial, la propiedad, las columnas sensibles, el uso permitido, las relaciones y las reservas. Si se omite esto, la única fuente de verdad se convierte en otro repositorio que ya no está actualizado.

La versionado es más importante de lo que parece

Lo canónico no significa atemporal. Imagine que la empresa cambia la definición de entrega a tiempo de “envíos a tiempo divididos por el total pedido” a “envíos a tiempo divididos por el total entregado”. Si la definición antigua se sobrescribe simplemente, un agente que responda a una pregunta histórica podría aplicar la lógica actual al informe del año pasado. Por lo tanto, los conceptos necesitan versiones o fechas de vigencia:

versions:
  - version: "2.0"
    active: true
    effective_from: 2026-06-10
    change: "Denominator changed to delivered shipments"

  - version: "1.0"
    active: false
    effective_from: 2025-01-01
    effective_to: 2026-06-09

Ahora dos preguntas reciben respuestas diferentes. Una pregunta sobre la definición de OTD utiliza la versión actual, mientras que otra pregunta sobre por qué el informe del primer trimestre de 2026 lo calculó de manera distinta emplea la versión en vigor en ese momento. “Canónico” no significa inmutable; significa controlado.

Cuando RAG y el conocimiento canónico difieren

Pronto o tarde, el agente recuperará un documento antiguo que indica que OTD es la suma de los envíos puntuales sobre el total de envíos pedidos, mientras que el concepto canónico habla de los envíos entregados a tiempo sobre el total de envíos entregados. El sistema necesita una regla de precedencia explícita, y ante una contradicción, una respuesta como esta:

if contradiction(okf_context, rag_context):
  log_conflict(…)
  prefer(okf_context)

Incluso puede indicarle al usuario que un documento más antiguo entra en conflicto con la definición métrica actual, y que se utilizó la definición verificada actual. De este modo, el agente hace algo más que simplemente responder; está revelando deudas de conocimiento, lo cual podría considerarse uno de los efectos secundarios más valiosos de este diseño.

Midiendo más que la respuesta final

En esta arquitectura no basta con solo hacer un seguimiento de la tasa de alucinaciones. También se debe medir cómo llegó el sistema a una respuesta, por ejemplo:

% queries routed to correct source
% canonical lookups with stale concepts
% live queries rejected by policy
% RAG/OKF conflicts detected
% concepts past stale_after
% concepts with no active owne

Una respuesta final incorrecta puede surgir de fallos muy diferentes. El modelo podría haber razonado mal. El enrutador podría haber elegido RAG cuando se necesitaba conocimiento canónico. El concepto canónico podría estar desactualizado. La consulta en tiempo real podría ser correcta mientras que la definición de la métrica es errónea. Se trata de problemas de ingeniería distintos, y la capacidad de observabilidad debería ayudar a separarlos.

Cuándo se trata de sobreingeniería

Un equipo de ingeniería de cinco personas con solo unos pocos documentos internos probablemente no necesite una plataforma de gobernanza del conocimiento. Si el caso de uso consiste principalmente en encontrar información relevante entre miles de documentos, RAG podría ser suficiente. Si el conocimiento cambia rara vez, los mecanismos de actualización frecuente podrían no ser útiles. Si hoy en día nadie se encarga de la documentación, agregar información preliminar en YAML no creará una cultura de responsabilidad.

Este enfoque se vuelve atractivo cuando se cumplen varias de estas condiciones:

• Varios equipos definen cada uno los mismos conceptos
• Los agentes llevan a cabo acciones operativas
• Los esquemas y las métricas se modifican con frecuencia
• El conocimiento incorrecto cuesta al negocio algo real
• Las definiciones requieren responsables y un registro de auditoría
• Los datos en tiempo real deben combinarse con semántica canónica

Cuanto más se apliquen, mayor será el beneficio de la división.

Dónde encaja MCP

Cuando los agentes acceden a varias fuentes de conocimiento y datos, MCP se convierte en un punto de integración natural. Un agente podría encontrar capacidades como:

get_canonical_metric_definition
get_schema
search_historical_documents
query_warehouse
get_runbook

El router elige el adecuado. OKF describe conceptos y restricciones, MCP expone herramientas y recursos, los sistemas en tiempo real siguen siendo los propietarios de los datos actuales, y RAG permanece como la capa de descubrimiento para la historia no estructurada. Es mejor mantener estas responsabilidades separadas a menos que haya una razón sólida para fusionarlas.

Una primera versión sensata

Empezar con 300 conceptos sería un error. Diez es mejor, específicamente diez conceptos sobre los que la gente ya discute. Por ejemplo:

3 metrics
2 schemas
2 SLAs
2 runbooks
1 business rule

Luego, mida algunas cosas. ¿Puede el agente encontrar el concepto canónico? ¿Sabe cuándo ese concepto está desactualizado? ¿El enrutamiento elige el camino correcto? ¿Las consultas en tiempo real pueden ejecutarse de forma segura? ¿La gente realmente mantiene esos conceptos? Los buenos resultados justifican ampliar el alcance. Los malos justifican detenerse. Un experimento de arquitectura debe poder fracasar sin costar demasiado.

La lección más importante

La conclusión más útil no es un nuevo formato de archivo. Es que el conocimiento empresarial tiene diferentes modos de verdad. Alguno es autoritativo, otro es exploratorio y otro refleja el estado actual, y cada modo merece su propio patrón de acceso. Un mapa práctico relaciona cada pregunta con un modo:

• Definición oficial: conocimiento canónico.
• Información relevante: recuperación de datos.
• Verdad actual: una consulta en tiempo real.
• Qué debe hacer el agente: combinar todo lo anterior bajo una política.

RAG sigue siendo valioso, las bases de datos vectoriales también siguen siendo valiosas, y OKF puede serlo igualmente. El error arquitectónico radica en suponer que uno de ellos debería responder a todas las preguntas. El futuro no consiste en reemplazar a RAG, sino en saber cuándo RAG es la herramienta adecuada y cuándo no lo es. Una vez que los agentes realicen acciones reales dentro de las empresas, elegir la fuente de verdad deja de ser una cuestión de gestión del conocimiento y se convierte en una decisión arquitectónica.