¿Por qué una API es más eficiente que un MCP para RAG?
Ok, el título puede ser algo controversial, lo entiendo. Por eso mismo quiero dedicar este post a brindar un argumento basado en variables que son relevantes al momento de desplegar un sistema RAG y sus casos de uso.
¿Qué es RAG?
RAG son las siglas de Retrieval Augmented Generation. Es una forma de mejorar el output del LLM añadiéndole contexto fuera de la información con la que fue entrenado, muchas veces es información de alto grado confidencial que debe estar sujeta a cumplimiento, dependiendo del lugar.
Caso de uso en el mundo real
Tienes un equipo de desarrolladores, todos utilizan agentes para trabajar en el mismo proyecto y generalmente utilizan archivos markdown para almacenar el progreso utilizando spec-driven development.
¿El problema?
Este flujo funciona perfectamente para desarrolladores independientes o equipos pequeños; no obstante, mientras más crece el proyecto debemos afinar el criterio de filtrado para no inyectar contexto poco útil o incluso perjudicial. No olvidemos que el contexto es un activo preciado y cargarlo innecesariamente puede tener una repercusión tanto financiera (los tokens no son gratis) como de eficiencia (garbage-in, garbage-out).
Se hace imperativo centralizar en una fuente de verdad donde el LLM pueda buscar el contexto a demanda; es aquí donde RAG empieza a ser una solución interesante.
Visualicemos el flujo
En lugar de consultar archivos locales, los agentes deben ser capaces de hacer consultas que además sean semánticas. Este flujo puede verse así si decidimos desplegar toda la infraestructura en Google Cloud.
- Un desarrollador se autentica utilizando su API key; dependiendo del nivel de acceso que tenga, puede acceder a ciertos proyectos o features.
- El agente hace las consultas en queries semánticas. En la imagen superior se está utilizando una instancia de Cloud SQL con Postgres con la extensión pg_vector habilitada.
- Cada cadena de texto se convierte en un embedding utilizando Vertex AI.
- Se calcula matemáticamente la distancia entre el vector y los vectores almacenados en la base de datos y se devuelven los resultados más relevantes.
- Cuando el desarrollador implementa la feature en la que está trabajando, le pide al agente que almacene los detalles en la base de datos.
- El ciclo se repite con todo el equipo.
Ok, entonces ¿API o MCP?
Aparentemente, podrían ser intercambiables, ¿no? ¿Qué los diferencia realmente? Encuentro principalmente dos variables importantes:
El flujo de comunicación
Una diferencia fundamental entre los dos enfoques es cómo se comunican.
-
La API requiere que el cliente envíe una solicitud HTTP a un endpoint; idealmente, esta solicitud debe estar autenticada para que el servidor evalúe si autoriza o no. Cuando desarrollamos con IA, será el agente quien haga las llamadas, por lo que una SKILL bien implementada no es negociable.
-
El MCP establece una conexión bidireccional utilizando SSE; esto garantiza que si existen cambios en el servidor, este puede notificar al cliente. Para el desarrollo con IA, este es nuestro agente, por lo que puede decidir qué hacer en consecuencia.
La eficiencia financiera
En cualquiera de los dos casos, el flujo de trabajo y los servicios desplegados serán los mismos, pero hay algo crítico a considerar en la instancia de Cloud Run que hace más atractiva la API para RAG, al menos en este caso de uso.
- El escalado a cero. - Si hay periodos en los que la API no será utilizada intensamente, aplicando esta configuración. Sí, habrá coldstarts, pero eso puede resolverse en la configuración de la SKILL. El MCP demanda un túnel abierto, por lo que no escalará a cero.
- Request-based vs. instance-based. - Para optimizar incluso más las FinOps, se puede optar por request-based en la configuración de Cloud Run. Esto cambia el ciclo de vida de la instancia. Es muy eficiente en costos, pues solo se reciben cargos por las solicitudes procesadas. En este caso, las consultas semánticas u operaciones de escritura concretas.
- Si utilizáramos instance-based, con mínimo una instancia al mes, con la configuración más básica tendríamos 25 USD adicionales (siempre ajustables al uso, esto es solo una referencia).
Conclusión
Podría argumentarse que un agente puede utilizar un servidor MCP local que se conecte directamente a una base de datos vectorial remota. No obstante, eso haría que la base de datos sea pública y que los clientes puedan conectarse a ella, incrementando el vector de ataque.
No porque los MCPs se hayan convertido en un estándar, que para otros casos de uso es innegociable, significa que debamos diseñar nuestra arquitectura tomándolo como default. Siempre hay que pensar en los casos de uso.
Escribí este artículo para dar perspectiva; creo que hay situaciones en las que el MCP brilla, especialmente cuando se quiere evitar polling, pero este es un caso interesante que quería compartir.