Voy a empezar por lo que no sé, que en esta guía importa.
No he montado RAG en producción. En Barner y en DigitalBrain resuelvo con MCP y con conexión directa por API, y hasta hoy no me ha hecho falta otra cosa. Así que aquí no vas a leer mi experiencia con bases vectoriales, porque no la tengo.
Lo que sí puedo darte es la comparativa bien hecha, con lo que dice la ingeniería de quien sí los usa, y un criterio de decisión que te ahorre dinero. Empezando por el detalle que casi nadie menciona: la comparación está mal planteada.
No son la misma categoría de cosa
RAG es una arquitectura. MCP es un protocolo de transporte.
RAG (Retrieval-Augmented Generation) es una técnica: troceas tus documentos, los conviertes en vectores, los guardas en una base de datos y recuperas los trozos relevantes cuando alguien pregunta.
MCP (Model Context Protocol) es un estándar para conectar la IA con sistemas externos. La analogía oficial de Anthropic es un puerto USB-C para aplicaciones de IA.
Compararlos es parecido a comparar "base de datos" con "HTTP". Y de hecho puedes servir un sistema RAG a través de un MCP server. No son alternativas.
La forma más útil que he encontrado de resumirlo: RAG hace que el modelo sepa más. MCP hace que el modelo pueda hacer más.
Que se comparen tanto es un artefacto de cómo se busca en Google, no de cómo se construye software.
Antes de nada: puede que no necesites ninguno
Este es el dato más útil de toda la guía y viene de la propia Anthropic.
Si tu base de conocimiento cabe por debajo de 200.000 tokens (unas 500 páginas), no montes RAG. Metes todo en el prompt, activas prompt caching y listo. Sale más barato, más rápido y más exacto.
Piénsalo un momento: 500 páginas. La mayoría de las empresas que están a punto de pagar una base vectorial no llegan ni de lejos a ese volumen con la documentación que de verdad usan para decidir.
Yo he acabado en ese sitio sin buscarlo. Mi información de decisión vive donde está (el correo, las hojas, la tienda) y Claude la va a buscar cuando la necesita. Nunca he tenido que indexar nada.
RAG: qué gana y qué pierde
A favor. El índice se construye una vez y servirlo sale barato. Va bien con corpus grande, no estructurado y quieto: PDFs, wikis, FAQs, manuales. Y encuentra conexiones semánticas que una búsqueda literal se pierde.
Además se puede afinar de forma medible. Anthropic publicó que con embeddings contextuales el fallo de recuperación baja de 5,7% a 3,7%, y con reranking encima llega a 1,9%. El coste de preparar esos trozos: 1,02 dólares por millón de tokens de documento.
En contra. Recupera lo parecido, que no siempre es lo correcto ni lo actual. En cuanto el dato cambia, tu índice miente hasta el siguiente reindexado. Parece sencillo al principio y se complica después. Y solo lee: RAG no puede escribir nada en tu ERP.
Hay un caso en contra que pesa mucho. Las primeras versiones de Claude Code usaban RAG con una base vectorial local, y lo quitaron. Boris Cherny, su creador, ha contado que la búsqueda agéntica funcionaba mejor en general. Otro ingeniero del equipo dijo que la superó por mucho y que fue sorprendente. Razones: precisión con símbolos exactos, frescura (lee el disco vivo) y simplicidad.
MCP: qué gana y qué pierde
A favor. El dato siempre está fresco, porque llama a la API viva en lugar de a un índice rancio. Es estándar y hay adopción real. Puede actuar, que es la diferencia gorda. Y permite permisos granulares: marcar qué herramientas solo leen y cuáles pueden romper algo.
En contra. Come tokens. Anthropic ha publicado que ha visto definiciones de herramientas consumiendo 134.000 tokens antes de afinarlas, y que los resultados intermedios pasan por el modelo (un transcript de dos horas moviéndose entre dos herramientas puede suponer 50.000 tokens extra).
Sobre esto hay que ser justo: la crítica es real pero está fechada. Anthropic ya publicó las mitigaciones (carga diferida de herramientas, Tool Search Tool, ejecución por código). Y lo interesante es que recortar tokens también sube la precisión: con Tool Search Tool, Opus 4 pasó de 49% a 74% de acierto. Menos herramientas cargadas, mejores resultados.
Cuándo usar cada uno
| Si... | Apunta a |
|---|---|
| El corpus es grande (más de 200k tokens) y quieto | RAG |
| El corpus es pequeño | Ninguno: métele todo al prompt |
| El dato cambia cada segundo (stock, precios, saldo) | MCP |
| Son PDFs, wikis, manuales sin estructura | RAG |
| Está detrás de la API de un tercero que no puedes indexar | MCP |
| Solo necesitas leer | RAG |
| Necesitas escribir o ejecutar algo | MCP |
La versión corta: si el dato es tuyo, grande y quieto, RAG. Si es de otro, vivo, o hay que tocarlo, MCP. Si es pequeño, ninguno de los dos.
Se combinan más de lo que se enfrentan
En producción la arquitectura normal usa los dos. El ejemplo típico es un soporte al cliente que saca los pasos de resolución de la base de conocimiento (RAG) y el estado actual de la suscripción de ese cliente concreto (MCP).
Los errores que más veo contados por quien construye esto: montar RAG cuando el corpus cabía en el prompt, creer que "semánticamente parecido" significa "correcto", y mapear la API 1 a 1 como herramientas MCP en lugar de diseñar desde el flujo de trabajo real.
Si estás decidiendo hoy, empieza midiendo cuánta documentación de verdad usas para decidir. Si son menos de 500 páginas, ahórrate la base vectorial y conecta lo que ya tienes vivo.
Cada día resumo lo que importa en IA en digitalbrain.email, y los miércoles va una formación práctica a fondo.
Relacionado
