Stack de rendimiento para MCP + RAG: herramientas, benchmarks y guía de decisiones

TL;DR

• Esta es la continuación técnica de Cómo hacer que los datos de una aplicación sean públicos y estén listos para producción con MCP y RAG. La parte 1 cubrió la seguridad y la arquitectura. Esta cubre qué elegir y por qué.
• No elijas herramientas basándote solo en capturas de rankings. Usa las tareas de retrieval de MTEB para seleccionar embeddings, el retrieval zero-shot al estilo BEIR para comparar arquitecturas y tu propio conjunto de evaluación para las decisiones finales.
• Para la mayoría de los stacks MCP + RAG sobre documentación pública en 2026, mi opción predeterminada es: retrieval híbrido (BM25 + dense), BGE-M3 o un modelo de embeddings sólido vía API, pgvector o Qdrant según el modelo operativo, FlashRank o BGE-Reranker-v2-m3, caché de conjuntos de retrieval + caché de prompts y RAGAS + herramientas de trazas para pruebas de regresión.
• Los benchmarks ofrecen resultados distintos según la carga de trabajo. El estudio de Timescale con 50M vectores que compara pgvector con Qdrant muestra que pgvectorscale gana en throughput, mientras que Qdrant gana en latencia de cola. Trata las afirmaciones de los proveedores como hipótesis hasta que vuelvas a ejecutar las pruebas con el tamaño de tu corpus, tus filtros y tu hardware.
• Las optimizaciones de mayor impacto suelen ser poco llamativas: reducir top-k, regenerar embeddings según hashes, almacenar conjuntos de retrieval en caché, aplicar reranking en cascada y medir recall@k antes de ajustar el LLM.

Qué aprenderás aquí

• Qué benchmarks realmente te ayudan a elegir componentes de retrieval
• Un flujo de decisión para embeddings, backends de búsqueda, rerankers, cachés y herramientas de evaluación
• Librerías de código abierto que vale la pena conocer en 2026
• Tablas comparativas con contexto de benchmarks y advertencias para producción
• Tres stacks de referencia: MVP, producción equilibrada y gran escala
• Cómo afectan las decisiones de serving de MCP a la latencia y al diseño de caché
• Un harness mínimo de benchmarks que puedes ejecutar sobre tu corpus público

Cómo se relaciona esto con la parte 1

La parte 1 respondió: ¿Qué debería ser público? ¿Cómo encajan MCP y RAG? ¿Dónde están los límites de seguridad?

Este artículo responde: Dada esa arquitectura, ¿qué componentes la hacen rápida, económica y medible?

Si no has leído la parte 1, revisa primero sus secciones de caché y checklist. Todo lo que sigue presupone un corpus público con una lista de elementos permitidos y una ruta de retrieval compartida por las herramientas MCP y las respuestas RAG.

El flujo de decisión

Empieza por las restricciones, no por las marcas.

Constraints
  corpus size, QPS, p95 budget, budget $/1k queries,
  self-host vs managed, metadata filters, languages
        |
        v
Retrieval quality target
  recall@20 on your eval set
        |
        v
Pick first-stage retrieval
  BM25 only? dense only? hybrid? BGE-M3 multi-function?
        |
        v
Pick search backend
  pgvector, Qdrant, OpenSearch, in-memory FAISS for MVP
        |
        v
Pick reranker tier
  none -> FlashRank CPU -> BGE-v2-m3 GPU -> managed API
        |
        v
Pick cache layers
  CDN, embedding cache, retrieval-set cache, semantic cache, prompt cache
        |
        v
Pick eval + tracing
  RAGAS, custom recall@k, LangWatch/Langfuse/Phoenix
        |
        v
Load test + cost model
  p50/p95 latency, $/query, cache hit rate, recall drift

El resto de este artículo recorre ese árbol con herramientas, cifras y tradeoffs.

Benchmarks en los que puedes confiar y cómo interpretarlos mal

Los benchmarks sirven para crear una lista de candidatos, no para tomar la decisión final.

MTEB y BEIR

MTEB (Massive Text Embedding Benchmark) es la referencia estándar para comparar embeddings. Las tareas de retrieval de BEIR están incluidas en MTEB como pruebas de transferencia zero-shot entre dominios. El ranking de MTEB en Hugging Face es el lugar más práctico para comparar modelos, pero filtra por las tareas de Retrieval al elegir modelos de embeddings. Las puntuaciones agregadas de MTEB ocultan debilidades en retrieval.

BEIR planteó originalmente el retrieval como algo comparable entre arquitecturas léxicas, sparse, dense, de interacción tardía y de reranking bajo un mismo formato de tarea. Ese sigue siendo el modelo mental correcto, aunque nunca ejecutes por tu cuenta la suite completa de 18 datasets.

Regla práctica:

BRIGHT, RAGBench, CRAG, RGB

Úsalos cuando MTEB/BEIR sean demasiado optimistas:

• BRIGHT — retrieval con alto nivel de razonamiento; útil si los usuarios hacen preguntas de producto que requieren varios pasos.
• RAGBench / RAGChecker — diagnóstico del pipeline a nivel de componentes.
• CRAG / RGB — preguntas y respuestas factuales de extremo a extremo y comportamiento de rechazo; bien resumidos en Aplicaciones RAG en la práctica.

Mi criterio editorial: la documentación pública de productos suele fallar en coincidencia de entidades, desfase de versiones y falta de evidencia antes que en razonamientos complejos y poco comunes. Ejecuta primero pruebas de retrieval similares a BEIR y luego agrega 20 casos adversariales de la checklist de la parte 1.

retrieval-pareto y HAKARI-Bench

Dos recursos de 2026 son especialmente útiles para ingenieros que buscan tradeoffs entre calidad, latencia y almacenamiento, no solo nombres de modelos:

• retrieval-pareto — harness abierto de benchmarks que compara HNSW dense, OPQ-IVF-PQ, RaBitQ, ScaNN, BM25, interacción tardía y sistemas híbridos RRF en tareas al estilo BEIR/BRIGHT, con latencia p50/p99 y uso de almacenamiento.
• HAKARI-Bench — benchmark ligero diseñado para comparar arquitecturas de retrieval y configuraciones de eficiencia en condiciones unificadas, incluidos rerankers sobre un conjunto fijo de candidatos.

Una advertencia importante del propio retrieval-pareto: en algunos corpus de escala BEIR, la búsqueda dense exacta y plana puede superar a HNSW porque, a escala moderada, las operaciones matriciales son más eficientes que el costo de recorrer el grafo. No supongas que HNSW es automáticamente más rápido.

Leaderboard score                Your production question
-------------------              ---------------------------
MTEB retrieval nDCG@10     ->    recall@20 on *your* docs
BEIR average               ->    zero-shot on *your* domain
Vendor p50 latency chart   ->    p95 with *your* filters + reranker
Blog "73% cost reduction"  ->    cache hit rate on *your* traffic

Capa 1: modelos de embeddings

Qué sugieren los benchmarks

Para documentación pública de productos en inglés, entre las opciones sólidas de 2025–2026 están:

El paper de BGE-M3 (Chen et al., 2024) es la fuente principal sobre retrieval híbrido en un solo modelo de embeddings: dense, sparse léxico y multivector al estilo ColBERT, combinados mediante un ranking híbrido ponderado:

s_rank = w1 * s_dense + w2 * s_lex + w3 * s_mul

Para documentación pública con SKU, rutas de API, códigos de error y números de póliza, el retrieval híbrido suele valer la pena. Dense por sí solo no encuentra algunos tokens exactos; sparse por sí solo no encuentra algunas paráfrasis.

Guía de decisión

Corpus < 100k chunks, English, budget-sensitive
  -> e5-base or embedding-3-small + BM25 hybrid

Corpus multilingual or long docs (8k tokens)
  -> BGE-M3 self-host or strong multilingual API embedder

Need best quality, low eng time
  -> API embedder + BM25 side index

Need lowest $ at scale
  -> small open embedder + hash skip on unchanged chunks + retrieval cache

Librerías de código abierto

Ejemplo mínimo de BGE-M3 híbrido:

from FlagEmbedding import BGEM3FlagModel

model = BGEM3FlagModel("BAAI/bge-m3", use_fp16=True)

def embed_for_index(texts: list[str]):
    return model.encode(
        texts,
        return_dense=True,
        return_sparse=True,
        return_colbert_vecs=False,  # enable only if you need multi-vector
    )

Capa 2: backends de búsqueda y tipos de índices

Aquí es donde más divergen los benchmarks. Tu modelo operativo importa tanto como la velocidad bruta.

pgvector vs Qdrant vs otras opciones

La comparación abierta más citada en 2025–2026 es el benchmark de Timescale/Tiger Data con 50M vectores de 768 dimensiones, que usa un fork de ANN-Benchmarks:

Fuente: Comparación de pgvector y Qdrant de Timescale.

Interpretación para MCP + RAG sobre documentación pública:

• Elige pgvector (+ pgvectorscale a gran escala) cuando ya operas Postgres, quieres hacer joins SQL con metadatos, necesitas ACID y una sola base de datos para chunks + tablas de evaluación + datos de la aplicación, y el throughput alto es importante.
• Elige Qdrant cuando quieres un servicio vectorial dedicado, menor latencia de cola, escalado horizontal más sencillo para cargas exclusivamente vectoriales o patrones avanzados de filtrado y payload sin lidiar con las particularidades del planificador SQL.
• Elige OpenSearch/Elasticsearch cuando la búsqueda léxica es esencial y la búsqueda híbrida en un solo clúster es innegociable.
• Elige FAISS dentro del proceso solo para MVP, trabajos offline o búsqueda embebida en un solo worker, no como tu capa de serving multi-tenant.

                    OPS PREFERENCE
                          |
         +----------------+----------------+
         |                                 |
    Already on Postgres              Vector-first team
         |                                 |
         v                                 v
   pgvector HNSW                   Qdrant / Weaviate
   + pgvectorscale @ 10M+          + FastEmbed
         |                                 |
         +----------------+----------------+
                          |
                   Need lexical in one box?
                          |
                    OpenSearch hybrid

Guía rápida de tipos de índices

Según retrieval-pareto y el enfoque de ANN-Benchmarks:

Mi recomendación práctica para documentación pública de menos de ~2M chunks: BM25 + pgvector HNSW o índice híbrido de payload de Qdrant, seguido de reranking de los 20–50 mejores resultados.

Capa 3: rerankers

La primera etapa de retrieval debería optimizar recall@50–100. Los rerankers optimizan precision@3–5.

Opciones respaldadas por benchmarks

Los cross-encoders suelen agregar ~5–15 puntos de nDCG frente al retrieval basado solo en bi-encoders en tareas al estilo BEIR. Eso coincide con el patrón de dos etapas de la configuración original de reranking de BEIR (reranking de los 100 mejores resultados de BM25).

El README de FlashRank es explícito: no requiere Torch, modelo predeterminado de ~4MB, diseñado principalmente para CPU. Eso lo convierte en la mejor opción de código abierto cuando los presupuestos de p95 son ajustados y puedes aceptar una reducción de calidad.

BGE-Reranker-v2-m3 es el mejor cross-encoder autohospedado de propósito general para equipos con una GPU pequeña o un worker de reranking por lotes.

Reranking en cascada: el patrón de rendimiento que la mayoría de los equipos omite

Stage 0: hybrid retrieve top 100   (~20-80 ms)
Stage 1: FlashRank -> top 20       (~15-30 ms CPU)
Stage 2: BGE-v2-m3 -> top 5        (~40-90 ms GPU)
Stage 3: pack 3-4 chunks into LLM  (~5 ms)

Esto suele superar en costo y latencia a «un solo reranker enorme sobre 100 pares», mientras conserva la mayor parte de las mejoras de calidad. Valídalo con recall@5 y fidelidad de las respuestas, no solo con la puntuación del reranker.

from flashrank import Ranker, RerankRequest

ranker = Ranker(model_name="ms-marco-MiniLM-L-12-v2", cache_dir="/tmp/flashrank")

def rerank_stage1(query: str, passages: list[dict], top_n: int = 20):
    req = RerankRequest(query=query, passages=passages)
    return ranker.rerank(req)[:top_n]

Capa 4: caché, donde realmente se va el dinero

La parte 1 presentó cuatro capas de caché. Aquí están las herramientas correspondientes.

Matriz de capas de caché

GPTCache (MIT, Zilliz) sigue siendo la librería de caché semántica de código abierto más flexible: modelo de embeddings intercambiable, base de datos vectorial, política de desalojo e integraciones con LangChain/LlamaIndex. Referencia principal: paper de GPTCache en ACL.

Detalle importante de implementación, repetido de la parte 1 porque los benchmarks lo ignoran: almacena en caché conjuntos de retrieval o paquetes de respuestas fundamentadas, no solo texto libre del LLM, si te importa la estabilidad de las citas.

Comparación de cachés semánticas

Orden sugerido del stack para tráfico de documentación pública:

1. CDN for static docs + MCP read-only resources
2. Retrieval-set cache (15 min TTL, corpus-version keyed)
3. Provider prompt caching on stable system prefix
4. Semantic cache for top 100 FAQ queries
5. LLM generation

La versión del corpus en la clave de caché no es opcional:

CACHE_KEY = f"{corpus_version}:{hash(query)}"

Capa 5: librerías de orquestación

No necesitas un framework pesado, pero sí necesitas trazas de retrieval consistentes.

Mi criterio práctico: para los handlers de herramientas MCP que deben mantenerse rápidos, mantén la orquestación ligera dentro de la herramienta:

MCP tool -> retrieval service -> cache -> vector store
          (no LLM in the tool path unless explicitly requested)

Ubica la síntesis del LLM en un endpoint RAG separado o en otra herramienta MCP (answer_public_question) para que los agentes puedan elegir entre solo buscar o generar una respuesta completa.

Capa 6: herramientas de evaluación y observabilidad

Trabajar en rendimiento sin métricas se convierte en ajustar por intuición.

Librerías de evaluación

RAGAS es el punto de partida predeterminado de código abierto porque separa la utilidad del retrieval de la calidad de generación sin requerir respuestas de referencia para cada métrica. Fuente principal: Es et al., demo de EACL 2024.

Harness mínimo de benchmark de retrieval:

from dataclasses import dataclass

@dataclass
class RetrievalExample:
    question: str
    gold_chunk_ids: set[str]

def recall_at_k(ex: RetrievalExample, retrieved_ids: list[str], k: int = 20) -> float:
    if not ex.gold_chunk_ids:
        return 1.0
    return len(ex.gold_chunk_ids & set(retrieved_ids[:k])) / len(ex.gold_chunk_ids)

def benchmark_retriever(retriever, examples: list[RetrievalExample], k: int = 20) -> dict:
    scores = [recall_at_k(ex, retriever.search(ex.question, k=k), k) for ex in examples]
    return {"recall_at_k": sum(scores) / len(scores), "k": k, "n": len(examples)}

Ejecuta esto cada vez que cambies el modelo de embeddings, los parámetros del índice, los pesos de la búsqueda híbrida o el reranker.

Métricas que importan para MCP + RAG

Decisiones de rendimiento específicas de MCP

Los detalles del serving de MCP afectan al stack de retrieval.

Mantén las herramientas de búsqueda deterministas y aptas para caché

Según la versión candidata de MCP del 2026-07-28 (publicación del blog):

• las sesiones a nivel de protocolo desaparecerán en Streamable HTTP
• las respuestas de listado y lectura incorporan las indicaciones de caché ttlMs y cacheScope

Implicaciones para el diseño:

search_public_docs(query, product, limit)
  -> cacheable, deterministic, no LLM
  -> set short ttlMs on tool list/metadata
  -> key cache by (corpus_version, normalized_query, filters)

answer_public_question(query)
  -> higher cost, lower cache hit rate
  -> separate tool with stricter rate limits

Handlers sin estado, IDs explícitos

Pasa corpus_version, product y locale como argumentos normales de la herramienta. No dependas de la memoria de sesión del servidor para seleccionar el tenant o el corpus.

Transporte

Para MCP público remoto:

• prefiere Streamable HTTP detrás de un proxy inverso
• configura timeouts agresivos en las llamadas a herramientas
• ubica el servidor MCP y el servicio de retrieval en la misma región que la base de datos vectorial

Tres stacks de referencia

Son plantillas, no mandamientos. Ejecuta el harness de benchmarks en tu corpus antes de comprometerte con una opción.

Stack A — MVP (rápido de lanzar)

Static docs + llms.txt
Postgres + pgvector HNSW
BM25 via Postgres FTS or Meilisearch sidecar
e5-base-v2 or embedding-3-small
No reranker (or FlashRank on top 30 only)
In-memory retrieval-set cache
RAGAS offline eval on 50 examples

Ideal para: documentación pública de startups, <200k chunks, bajo QPS, un ingeniero.

Limitaciones con: alto QPS, contenido multilingüe, alta tasa de búsquedas fallidas de SKU/códigos.

Stack B — Producción equilibrada (mi opción predeterminada)

Public corpus in Postgres metadata + pgvector
BM25 + BGE-M3 dense hybrid
FlashRank cascade -> BGE-Reranker-v2-m3
Retrieval-set cache in Redis (corpus-version keyed)
Semantic cache via GPTCache for top queries
MCP tools: search_public_docs + answer_public_question
RAGAS + custom recall@k in CI
Langfuse or LangWatch traces in prod
Provider prompt caching on stable system prefix

Ideal para: documentación pública de productos, catálogos de integraciones, portales para desarrolladores.

Limitaciones con: escala de miles de millones de vectores sin un plan de sharding de pgvectorscale/Qdrant.

Stack C — Gran escala / p95 estricto

Qdrant hybrid + payload filters
BGE-M3 or top API embedder
Two-stage rerank: FlashRank -> mxbai-rerank-large-v2 or Cohere API
Redis retrieval-set cache + CDN for MCP resources
Dedicated rerank GPU workers
retrieval-pareto-style load tests before launch
Component evals + canary corpus versions

Ideal para: búsqueda pública con alto QPS, filtros para múltiples productos, SLO globales de latencia.

Limitaciones con: equipos pequeños sin capacidad operativa para otra base de datos.

Tablas comparativas de un vistazo

Embeddings (prioridad al retrieval)

*combínalo con BM25 u OpenSearch para búsqueda híbrida.

Bases de datos vectoriales (escala de documentación pública)

Rerankers

Checklist de pruebas de carga

Antes de considerar que el stack de rendimiento está listo para producción:

• recall@20 >= tu objetivo en 50+ preguntas etiquetadas
• el reranker mejora precision@5 de forma medible frente a no usar reranker
• p95 de MCP search_public_docs dentro del SLO con el QPS esperado
• tasa de aciertos de caché medida después de 1 semana de tráfico en sombra
• la reindexación del corpus no bloquea las consultas (blue/green o índice versionado)
• costo de embeddings por ejecución de reindexación documentado con la omisión por hash habilitada
• CI de regresión falla si la caída de una métrica de retrieval supera el umbral acordado

Qué no debes afirmar de más

• El nDCG del ranking no equivale a la precisión de tu FAQ.
• El ahorro de la caché semántica depende de la repetición de consultas; la documentación para desarrolladores suele tener consultas de cola larga con bajas tasas de aciertos de caché.
• Un reranker no puede corregir fallas de recall: si los chunks de referencia quedan fuera de los 50 mejores, corrige primero el retrieval.
• Las indicaciones de caché de MCP (ttlMs) ayudan a los clientes, pero aún necesitas almacenar conjuntos de retrieval en caché del lado del servidor para lograr ahorros reales.
• Las APIs gestionadas de reranking pueden ganar benchmarks y aun así perder en p95 cuando se incluye la variabilidad de la red; mide de extremo a extremo desde el cliente MCP si esa es la ruta del usuario.

Fuentes

• Cómo hacer que los datos de una aplicación sean públicos y estén listos para producción con MCP y RAG — base de arquitectura y seguridad (parte 1)
• Aplicaciones RAG en la práctica: conocimiento estructurado, mejor retrieval y evaluaciones reales — diseño de cadenas RAG y contexto de CRAG/RGB
• Ranking de MTEB — comparaciones de embeddings y reranking
• BEIR: un benchmark heterogéneo para la evaluación zero-shot de modelos de recuperación de información — Thakur et al., 2021
• Paper de BGE M3-Embedding — Chen et al., 2024; retrieval híbrido dense/sparse/multivector
• Documentación de BGE-M3 — fórmula de ranking híbrido y uso
• retrieval-pareto — benchmarks abiertos de calidad, latencia y almacenamiento para retrieval
• HAKARI-Bench — benchmark ligero y unificado de arquitecturas de retrieval
• Timescale: pgvector vs Qdrant con 50M vectores — comparación de throughput y latencia de cola
• FlashRank — librería de reranking para CPU
• Ficha del modelo BGE-Reranker-v2-m3 — cross-encoder autohospedado predeterminado
• GPTCache — librería de caché semántica de código abierto
• Paper de GPTCache en ACL — caché semántica para aplicaciones con LLM
• RAGAS — framework de evaluación de RAG
• RAGAS: evaluación automatizada de RAG — Es et al., EACL 2024
• La versión candidata de la especificación de MCP del 2026-07-28 — HTTP sin estado, indicaciones de caché
• Anthropic: caché de prompts — ahorro de tokens de entrada del lado del proveedor
• OpenAI: caché de prompts — ahorro de tokens de entrada del lado del proveedor