Le hice a mi RAG una pregunta que se hace en cualquier empresa cien veces al mes: ¿cómo calculamos los ingresos?

Me respondió con una definición obsoleta desde hacía tres meses. Con IVA incluido y contando los pedidos cancelados, cuando la definición vigente es justo lo contrario. Un error del 20% en periodos con muchas cancelaciones.

Lo interesante no es el fallo. Es que el modelo hizo su trabajo perfectamente: le pedí que respondiera solo con el contexto recibido y que citara la fuente, y eso hizo. Citó el documento del que sacó la información. El documento equivocado. Fui a mirar dónde estaba el documento correcto en el ranking de similitud. Puesto 15. De 85.

Por delante iban seis de los siete fragmentos del documento antiguo, un glosario, el esquema de la tabla de clientes y —en el puesto nueve— un ticket de soporte sobre gastos de envío a Canarias. Un ticket sobre envíos a Canarias se parece más a «cómo calculamos los ingresos» que el documento que define cómo calculamos los ingresos.

Este post va de eso: del problema estructural que tiene ahí debajo un RAG, y de si Open Knowledge Format —el formato abierto que Google Cloud publicó el 12 de junio de 2026— lo arregla. Lo he medido con siete preguntas, tres montajes distintos y todo el código publicado.

Por qué un RAG falla aunque el modelo acierte

Un RAG hace dos cosas: trocea tus documentos, los convierte en vectores y, cuando preguntas, recupera los fragmentos más parecidos a tu pregunta.

Ahí está todo el problema:

Parecido no es lo mismo que correcto. Parecido no es lo mismo que vigente. Parecido no es lo mismo que autoritativo.

En el ejemplo de arriba, el documento fundacional de 2023 tiene 4.000 caracteres con justificaciones, ejemplos y hasta un apartado de preguntas frecuentes. La ficha vigente de 2026 tiene 500 caracteres y una tabla. El primero se trocea en siete fragmentos, todos densamente centrados en el concepto de ingresos. El segundo, en uno, compartido además con otras cinco métricas.

Siete papeletas contra una. Y no hay ningún truco: es lo que pasa en cualquier empresa con más de dos años de documentación. El documento fundacional se escribió cuando había que justificarlo todo; la ficha buena es escueta porque ya nadie discute nada.

«Pues sube el top-k»

Es la objeción inmediata, y no funciona. Con k=15 el documento correcto sí entraría en el contexto… acompañado de los seis fragmentos que dicen lo contrario. Seis contra uno.

Y por el mismo motivo tampoco lo arregla un reranker: reordena lo que le llega, tendría que acertar contra la mayoría, y no hay nada en el texto que le indique cuál está vigente. La fecha no está en el fragmento.

Los otros fallos que encontré

Con el mismo corpus —60 ficheros de una tienda online ficticia con tres años de historia— aparecieron cinco patrones más:

Entidades homónimas. pedidos, pedidos_staging, pedidos_v2 y pedidos_legacy_shopify son casi el mismo documento para un embedding.
Tablas partidas. Pregunté si la tabla de pedidos tenía un campo de canal. Respondió «NO LO SÉ». El fichero correcto sí estaba en el contexto: lo que no estaba era la tabla, porque el troceador la había cortado y las columnas vivían en otro fragmento.
Composición imposible. La definición completa del MRR necesita tres reglas repartidas en tres ficheros. Ninguno las tiene juntas. El RAG trajo dos de tres, y devolvió una respuesta impecable, con dos fuentes citadas, sin avisar en ningún momento de que pudiera faltarle algo.
Vigencia. Preguntado explícitamente por cuál de las definiciones estaba vigente, eligió la obsoleta y afirmó que se aplicaba a todos los informes. No tenía ni un dato de fecha para decidirlo.
Ausencia. Un RAG siempre devuelve k fragmentos, haya respuesta o no.

Hay un patrón detrás de todos, y es el que me hizo escribir este post:

Un RAG avisa cuando le falta mucho. Se calla cuando le falta poco.

Cuando le llegó basura evidente, dijo que no lo sabía. Cuando le llegaron dos reglas de tres, construyó una respuesta que sonaba completa. Y le falta poco justo cuando más caro sale: no hay error, no hay excepción, no hay nada rojo en ninguna pantalla. Hay un número que se lleva a un comité.

Qué es Open Knowledge Format

Open Knowledge Format (OKF) es una especificación abierta que el equipo de Data Cloud de Google publicó el 12 de junio de 2026. Y lo mejor que se puede decir de ella es que es aburrida.

Un directorio de ficheros markdown con frontmatter YAML. Ese es el estándar entero.

okf-bundle/
├── index.md              # índice — divulgación progresiva
├── log.md                # historial de cambios
├── metricas/
│   ├── ingresos.md
│   └── mrr.md
├── reglas/
│   ├── divisas.md
│   └── marketplace.md
└── sources/
    └── corpus-operacion.md

Un concepto, un fichero. Así se ve uno real:

---
type: Metric
title: Ingresos
description: Definición oficial y vigente del cálculo de ingresos.
tags: [finanzas, ventas]
timestamp: 2026-05-04T09:00:00Z
---

# Definición

Suma de la base imponible de los pedidos completados en el periodo.

# Criterios

- Se usa `total_neto`, la base imponible. **Sin IVA.**
- Solo cuentan los pedidos en estado `completed`.
- Aplica la [regla de divisas](/reglas/divisas.md) a pedidos en otra moneda.

# Vigencia

Vigente desde el 4 de mayo de 2026. Sustituye a la definición de 2023, que
calculaba sobre el importe bruto con IVA. **Aquella ya no es válida.**

Hay cuatro cosas que importan de verdad:

1. El único campo obligatorio es type. No hay registro de esquemas, ni autoridad central, ni SDK que instalar. Si puedes hacer cat a un fichero, puedes leer OKF; si puedes clonar un repositorio, puedes distribuirlo.

2. La ruta del fichero es el identificador del concepto. metricas/ingresos es la definición. Acceso direccionable y determinista, no «el fragmento que más se parecía».

3. Los enlaces markdown son las relaciones. El agente los recorre para encadenar conceptos, sin el coste de montar un grafo de conocimiento con extracción de entidades.

4. Es git. Historial, diffs, autoría y pull requests sobre el conocimiento. Cada respuesta traza a una ruta de fichero y a un commit, con autor y fecha. En un RAG trazas a un identificador de fragmento en una base de datos vectorial, sin historia.

Y un detalle que cambia el patrón de acceso por completo: el index.md. En mi caso ocupa 255 tokens y cubre el cien por cien de lo que existe. El agente lo lee siempre primero, decide, y solo abre lo que necesita. Eso le permite hacer algo que un RAG no puede hacer nunca: saber que algo no existe.

https://www.youtube.com/watch?v=rtlDbb-q1pU

Lo probé: RAG, OKF y los dos juntos

Monté las tres capas sobre el mismo conocimiento, con el mismo modelo, el mismo hardware y las mismas siete preguntas. Todo en local con Ollama y ChromaDB, sin ninguna API de pago.

RAG — trocea 60 ficheros en 85 fragmentos y recupera los 5 más cercanos.
OKF — un agente con una herramienta, leer_concepto, que navega 9 conceptos curados partiendo del índice.
OKF + RAG — el mismo agente con las dos herramientas, y un concepto de tipo Corpus que le indica cuándo usar cada una.

Cada pregunta está elegida para disparar un fallo distinto:

#	Fallo	RAG	OKF	OKF+RAG
1	Documento deprecado	❌	✅	✅
2	Entidades homónimas	⚠️	⚠️	⚠️
3	Tabla partida	❌	✅	❌
4	Composición	❌	⚠️	✅
5	Vigencia	❌	⚠️	⚠️
6	Ausencia	✅	✅	✅
7	Cola larga	✅	❌	✅
	Aciertos	2/7	3/7	4/7
	Tokens	6.341	8.625	8.435

⚠️ significa respuesta correcta pero incompleta: da la ruta al concepto, no el contenido.

La capa combinada acierta el doble que el RAG solo. Y saca un cuatro sobre siete.

Tres cosas que salen de esos números:

El RAG no falla por recuperar poco, falla por recuperar lo que no toca. En las preguntas 1 y 5 el documento deprecado tiene mejor distancia coseno que el vigente. Subir el k mete más ruido del mismo sitio.

OKF sale más barato cuando se queda en el índice — y a veces por eso se queda corto. En tres preguntas gasta la mitad de tokens que el RAG, pero en dos de ellas responde con la ruta al concepto en lugar del contenido. El ahorro y la respuesta a medias son el mismo comportamiento, y se ajusta en el prompt del agente.

La capa combinada no es la suma de las dos. Gana la pregunta 7, que OKF solo no acierta, pero pierde la 3, que OKF solo sí acierta: con dos herramientas sobre la mesa, el agente a veces elige mal. Lo dejo publicado tal cual salió.

Cuándo usar cada capa

Después de medirlo, la regla que yo aplicaría:

Usa OKF cuando la respuesta tiene que ser exacta y es estable. Definiciones de métricas, contratos de API, esquemas de tablas, reglas de negocio, decisiones de arquitectura. Son decenas o cientos de conceptos, no millones de documentos. Y cuando la respuesta acaba en un informe, en una factura o en un comité.

Usa RAG cuando la pregunta es «busca dónde alguien mencionó X». Tickets de soporte, actas de reunión, hilos de chat, incidencias. Miles de documentos que cambian cada semana y que nadie va a curar jamás. Para eso no hay nada que sustituya a un RAG, y en mis pruebas lo resolvió a la primera.

Usa las dos capas cuando tengas las dos cosas, que es prácticamente siempre. La pieza que las une es un concepto OKF que no contiene conocimiento, sino enrutado: le dice al agente cuándo consultar el corpus, cuándo no, y que si el corpus contradice a un concepto curado, gana el concepto.

Los peros

No te voy a vender esto como una solución definitiva.

Cuesta más. Un 33% más de tokens que el RAG solo. Si tu caso es mucho volumen y poca criticidad, no compensa.

La curación no desaparece, se mueve. Antes ajustabas el troceado; ahora mantienes conocimiento. Esos nueve conceptos los revisé en minutos; en una empresa real son semanas, y mantenimiento continuo después. Un bundle abandonado seis meses miente igual que una wiki de 2023.

No es un grafo de conocimiento. La especificación dice que el tipo de relación lo transmite la prosa que rodea al enlace, no el enlace en sí. Son aristas sin tipar: no hay razonamiento sobre relaciones.

Es un borrador de hace unas semanas. El valor de un estándar es su adopción, y eso está por demostrar. Si no cuaja, te queda una carpeta de markdown en git. Que tampoco es mal sitio donde quedarse.

Y es un sistema no determinista. He ejecutado estas pruebas varias veces y no siempre sale igual. Toma los números como una señal, no como un veredicto.

Conclusión

Llevamos dos años arreglando el RAG desde dentro: mejor troceado, mejor reranking, mejores embeddings. Y parte del problema no se arreglaba desde dentro.

Había conocimiento que nunca debió estar en un vector. Debió estar en un fichero, con un nombre, en git, escrito por alguien que sabe. Juntar las dos capas es mejor que cualquiera por separado. Y son cuatro de siete. No te prometo que esto arregle tu RAG: te digo que lo mejora, y te enseño exactamente cuánto.

Lo que más ha cambiado no es el marcador. Es que ahora, cuando falla, sé por qué: veo qué concepto leyó el agente y cuál no. Con un RAG tenía cinco fragmentos y un embedding que decidía por mí.

Todo el código está publicado

Los 60 ficheros del corpus, los 9 conceptos del bundle, los scripts de las tres capas y la salida en crudo de la ejecución:

github.com/JoaquinRuiz/rag-vs-okf

git clone https://github.com/JoaquinRuiz/rag-vs-okf
cd rag-vs-okf && uv sync && uv run rag.py

Móntalo con tu documentación y cuéntame en los comentarios cuántas de siete te salen. Ese es el experimento de verdad.

Para seguir

Subo IA aplicada al desarrollo real en YouTube (@jokioki), siempre con el código delante y con los fallos incluidos.

Y tengo cuatro libros sobre IA en Amazon:

¡Que la IA te acompañe!

Qué es Open Knowledge Format (OKF) y qué arregla de tu RAG