Operar redes RAG a escala: caché, contrapresión y aislamiento de fallos para pipelines de recuperación

La guía anterior, Arquitectura de red para sistemas RAG, estableció la arquitectura de referencia: colocar la base de datos vectorial cerca de la aplicación, mantener las llamadas de embedding, búsqueda vectorial, reranking y LLM dentro de una ruta crítica medida, reutilizar conexiones de larga duración mediante pooling y ejecutar BM25 junto con la recuperación vectorial en paralelo cuando el producto necesita tanto recall como precisión. Esa arquitectura basta para construir un sistema de producción funcional. No basta para mantenerlo estable cuando aumenta la concurrencia, el proveedor de embeddings se ralentiza, el índice vectorial se reconstruye o un tenant ruidoso envía mil solicitudes de recuperación en un minuto.

A escala, las redes RAG dejan de ser un problema de ubicación y se convierten en un problema de plano de control. La pregunta ya no es solo "¿Dónde vive Qdrant, Pinecone o Weaviate?" La pregunta pasa a ser: ¿cómo descarta carga la red de recuperación, reutiliza embeddings costosos, aísla dominios de fallo, evita que los pools de conexiones se estampen y previene que una dependencia lenta consuma todos los workers de agentes? Un pipeline RAG es una cadena de saltos de red, y la cadena falla operativamente cuando un salto no tiene presupuesto, cola, circuit breaker ni fallback local.

Esta guía es el manual operativo para esa siguiente capa: topología de caché, contrapresión, colas, pooling de conexiones de bases de datos vectoriales, fanout de búsqueda híbrida, aislamiento de rerankers, optimización del egreso de embeddings y runbooks de fallo. Asume que el pipeline central ya existe: embed → search → rerank → LLM → response. El objetivo es hacer que ese pipeline sea predecible bajo carga.

El presupuesto de latencia en producción

Un sistema RAG saludable tiene un presupuesto de latencia explícito antes de que el LLM empiece a generar. Como punto de partida ilustrativo, no como estándar universal, los flujos interactivos pueden apuntar a una recuperación por debajo de 500 ms en p95, con un presupuesto extendido cercano a 800 ms cuando se requiere reranking o búsqueda en múltiples índices. Valide estos presupuestos con pruebas de carga específicas de la carga de trabajo, expectativas de los usuarios y SLOs del producto. Si la recuperación tarda dos segundos antes del primer token, los usuarios perciben todo el sistema de IA como lento aunque el modelo transmita rápidamente después.

# Ejemplo de presupuesto de latencia RAG interactivo, p95
query validation/authz        10-25ms
embedding service             50-180ms  # SaaS; 15-60ms con GPU self-hosted
vector search                 20-120ms  # depende de filtros, conteo de shards y tamaño del índice
BM25 search                   15-80ms   # rama paralela, no aditiva si se fusiona correctamente
result merge/fusion            5-25ms
reranker                      60-220ms  # opcional, pero a menudo crítico para la precisión
context assembly              10-40ms
---------------------------------------
retrieval before LLM         170-690ms

Los números importan porque las decisiones de arquitectura de red cambian qué etapas son secuenciales y cuáles pueden ejecutarse en paralelo. El embedding suele ser secuencial: el sistema no puede buscar en un índice vectorial hasta que tiene un vector de consulta. BM25 puede ejecutarse en paralelo con el embedding si solo necesita el texto bruto de la consulta. El reranking es secuencial después de recuperar candidatos, pero puede aislarse en un conjunto más pequeño de candidatos. La generación con LLM queda aguas abajo de todo, salvo que la aplicación transmita una respuesta parcial antes de que termine la recuperación, algo riesgoso para flujos de trabajo factuales.

La red RAG más rápida no es la que tiene menos servicios. Es aquella en la que cada servicio tiene un presupuesto medido, cada llamada costosa se reutiliza y cada dependencia lenta queda impedida de capturar el pool de workers.

Topología: dónde debería vivir cada servicio RAG

La topología recomendada separa el stack RAG en cinco zonas de red: ingreso, runtime de agentes, datos de recuperación, inferencia y egreso. Los límites son importantes porque los sistemas de recuperación manejan documentos sensibles y porque las APIs de embedding a menudo transmiten texto bruto a proveedores externos.

Internet / users
  → ingress gateway / WAF
  → agent runtime zone
      → embedding gateway / cache
      → vector DB zone (Qdrant / Weaviate / Pinecone private endpoint)
      → keyword search zone (OpenSearch / Elasticsearch / Postgres FTS)
      → reranker service zone
      → LLM gateway
  → response stream

Qdrant o Weaviate self-hosted deberían ubicarse en la zona de datos de recuperación, accesibles solo desde runtimes de agentes, trabajos de indexación y sondas de observabilidad. En Kubernetes, esto normalmente implica un namespace dedicado con NetworkPolicies de denegación por defecto e ingreso explícito en los puertos HTTP y gRPC de Qdrant. Para clústeres de alto rendimiento, mantenga la aplicación y los nodos vectoriales en la misma región y, preferiblemente, en la misma zona de disponibilidad, salvo que el requisito de disponibilidad del negocio justifique latencia cross-AZ. Una penalización cross-AZ de 2 a 5 ms parece pequeña hasta que se aplica a cada búsqueda, cada scroll, cada fanout de shard y cada reintento.

Pinecone y Weaviate Cloud deberían alcanzarse mediante conectividad privada cuando esté disponible: PrivateLink, VPC peering o un endpoint privado compatible con el proveedor. Si el acceso por internet público es la única opción, enrute el tráfico a través de un gateway NAT controlado o un proxy de egreso con destinos en allowlist y seguimiento de conexiones separado del egreso general de la aplicación. No permita que el tráfico de recuperación de documentos comparta la misma ruta de salida indiferenciada que descargas de paquetes, automatización de navegador y herramientas arbitrarias de agentes.

BM25 o búsqueda sparse no debería ser una ocurrencia tardía. Si la búsqueda por palabras clave se ejecuta en OpenSearch o Elasticsearch, colóquela cerca de la base de datos vectorial y del runtime de la aplicación. La recuperación híbrida a menudo duplica el número de llamadas backend por consulta de usuario, pero no debería duplicar la latencia si las ramas se ejecutan de forma concurrente y fusionan los resultados después de que ambas devuelvan respuesta.

Pooling de conexiones entre runtimes de agentes y bases de datos vectoriales

Los runtimes de agentes son irregulares. Una sola tarea de usuario puede disparar una llamada de recuperación, mientras que un flujo autónomo puede disparar decenas de llamadas a herramientas, búsquedas de memoria y recuperaciones de seguimiento. Sin pooling, cada recuperación paga establecimiento TCP, negociación TLS, autenticación y calentamiento de conexión. Con pooling agresivo pero sin límites, una ráfaga de agentes puede abrir cientos de streams hacia la base de datos vectorial y hacer que la base parezca poco saludable incluso cuando CPU y disco están bien.

Un punto de partida práctico para un despliegue self-hosted de Qdrant es un cliente compartido por proceso de runtime, keepalive HTTP/2 o gRPC habilitado y un pool dimensionado por concurrencia en lugar de por conteo de CPU:

# Pseudoconfiguración ilustrativa; ajuste con pruebas de carga
max_vector_connections = min(concurrent_agent_workers * 2, 100)
max_inflight_searches_per_worker = 4
connect_timeout_ms = 300
read_timeout_ms = 900
keepalive_time_s = 30
keepalive_timeout_s = 10
retry_budget = 1 retry only for idempotent reads

Para Pinecone y otras bases de datos vectoriales SaaS, el SDK puede ocultar el pool, pero el comportamiento de red sigue existiendo. Inspeccione la reutilización de conexiones en el proxy de egreso o el gateway NAT. Si cada consulta crea una nueva conexión TCP saliente, el SDK está mal configurado, el ciclo de vida del proceso es demasiado corto o la aplicación está instanciando clientes por solicitud. En runtimes de agentes serverless, los cold starts pueden hacerlo inevitable; compénselo agrupando recuperaciones en lotes, usando workers calientes para tenants de alto volumen o añadiendo un servicio gateway de recuperación que mantenga conexiones upstream persistentes.

Optimización del egreso del servicio de embeddings

Las llamadas de embedding son la fuente más común de costo de egreso evitable y latencia evitable. El embedding en tiempo de consulta suele ser pequeño, pero el embedding en tiempo de indexación puede transmitir millones de chunks. Si cada chunk se envía como una solicitud HTTPS individual, el costo de red queda dominado por el overhead de solicitud y el churn de conexiones en lugar de por los bytes del payload.

Use tres controles:

• Batching: agrupe entre 20 y 100 chunks por llamada a la API de embeddings donde los límites del proveedor lo permitan. Esto reduce el overhead de solicitud por chunk y hace que el seguimiento de conexiones NAT sea más predecible.
• Caché de embeddings: use como clave model_id + normalized_text_hash + chunking_version. Guarde embeddings de consulta con TTLs cortos (5-30 minutos) y embeddings de documentos indefinidamente hasta que cambie el documento o la versión del modelo.
• Separación de egreso: enrute el tráfico del proveedor de embeddings a través de un gateway NAT dedicado o un proxy de egreso con sus propios límites de tasa, métricas y alertas.

# Pseudocódigo ilustrativo; adáptelo a su implementación
sha256(
  model_id + "\n" +
  chunking_policy_version + "\n" +
  normalized_text
)

# Política de caché
query_embedding_ttl: 15m
document_embedding_ttl: until document_version or model_version changes
negative_cache_for_provider_429: 30-120s jittered

No ignore la selección de región. Un RTT de 70 ms hacia un proveedor de embeddings se paga antes de que pueda empezar la búsqueda vectorial. Si usa OpenAI, Cohere, Voyage u otro proveedor SaaS de embeddings, mida el RTT desde la subred de la aplicación, no desde su laptop. Si aloja embeddings por cuenta propia, coloque el servicio de embeddings cerca del runtime de agentes y dimensione el batching de GPU para que el tiempo de red no desaparezca solo para ser reemplazado por tiempo de cola.

Redes para búsqueda híbrida: paralelas, acotadas y fusionadas

La búsqueda híbrida mejora el recall al combinar coincidencia léxica sparse con similitud vectorial densa. La trampa de red es ejecutar BM25 después de la búsqueda vectorial, o la búsqueda vectorial después de BM25, simplemente porque el código de la aplicación se escribió de forma secuencial. En la mayoría de los sistemas, BM25 puede empezar de inmediato con la consulta en texto bruto mientras la solicitud de embedding está en curso. La búsqueda vectorial empieza tan pronto como vuelve el embedding. Las dos ramas se encuentran después en una etapa de fusión.

t=0ms    start BM25(query text)
t=0ms    start embed(query text)
t=90ms   embedding returns
t=91ms   start vector search(query vector)
t=130ms  BM25 returns
t=170ms  vector search returns
t=175ms  reciprocal-rank fusion
t=180ms  reranker top 40 → top 8
t=330ms  send context to LLM

El fanout debe estar acotado. Defina timeouts independientes para cada rama y fusione resultados parciales cuando una rama no crítica incumpla su presupuesto. Por ejemplo, si BM25 se usa como refuerzo de recall, una respuesta solo vectorial puede ser aceptable cuando OpenSearch está degradado. Si la búsqueda vectorial es la ruta principal de recuperación para preguntas semánticas, el fallback solo con BM25 debería estar claramente marcado o limitarse a flujos donde la evidencia por palabras clave sea suficiente.

Contrapresión y colas

El modo de fallo que derriba sistemas RAG no siempre es una caída. Con más frecuencia es una dependencia lenta que provoca acumulación de solicitudes. Los workers de agentes esperan al embedding. Los pools de conexiones se llenan. Los reintentos multiplican el tráfico. La base de datos vectorial ve búsquedas duplicadas. La cola del reranker crece. Al final, el LLM recibe menos solicitudes, pero la aplicación ya está saturada.

La contrapresión debe existir en cada límite costoso:

• Antes del embedding: límites de concurrencia de consultas por tenant y límites de tasa con token bucket.
• Antes de la búsqueda vectorial: máximo de búsquedas en curso por runtime y por colección.
• Antes del reranking: límites de profundidad de cola y topes de candidatos.
• Antes de la generación con LLM: aplicación estricta del timeout de recuperación para que una recuperación lenta no consuma slots del modelo indefinidamente.

# Pseudoconfiguración ilustrativa; no son valores universales
tenant_default_qps: 5
premium_tenant_qps: 25
max_inflight_embeddings_per_tenant: 20
max_inflight_vector_searches_per_collection: 100
reranker_queue_max_depth: 500
retrieval_deadline_ms: 800
serve_partial_if_bm25_missing: true
serve_partial_if_vector_missing: false

Los reintentos necesitan presupuestos. Reintentar una vez cada salto fallido puede duplicar el tráfico durante una caída. Use un solo reintento únicamente para lecturas idempotentes, con jitter, y nunca reintente cuando queden menos de 150 ms en el deadline global de recuperación. Cuando el proveedor devuelva 429, trátelo como una señal de contrapresión, no como un error misterioso. Almacene brevemente esa señal negativa en caché y desacelere a los llamadores.

Patrones de aislamiento de fallos

Una red RAG en producción debería degradarse de forma deliberada. El gateway de recuperación o el runtime de agentes necesita una tabla de decisión para cada dependencia:

Dependency          Failure mode        Response
embedding API       429 / timeout       use cached query embedding if present; otherwise fail fast
vector DB           timeout             try read replica once; otherwise no-answer with explanation
BM25 search         timeout             continue vector-only if confidence threshold met
reranker            saturated           skip rerank; use RRF/top-k with lower confidence
LLM provider        timeout             preserve retrieval trace; retry answer generation only

Las réplicas de lectura de la base de datos vectorial deberían aislarse de la presión de indexación. Si los trabajos de ingesta comparten los mismos nodos y ruta de red que el tráfico de consultas, las operaciones masivas de embedding y upsert pueden degradar la búsqueda orientada al usuario. Use pools de workers separados, claves de API separadas y, cuando sea posible, políticas de red separadas para cargas de indexación y de consulta. En Qdrant, colecciones separadas o réplicas de shards pueden ayudar a aislar tenants; en Pinecone, considere índices separados para cargas ruidosas cuando el aislamiento a nivel de namespace sea insuficiente.

Observabilidad para la red de recuperación

Registre la traza de recuperación para cada solicitud. La traza debería incluir tiempos de embedding, búsqueda vectorial, BM25, fusión, rerank, ensamblaje de contexto y tiempo hasta el primer token del LLM. Agregue p50, p95 y p99 por tenant, colección, modelo, región y proveedor.

{
  "request_id": "rag_01J...",
  "tenant": "acme",
  "embedding_ms": 94,
  "vector_search_ms": 48,
  "bm25_ms": 31,
  "fusion_ms": 6,
  "rerank_ms": 126,
  "context_tokens": 6420,
  "retrieval_total_ms": 323,
  "vector_pool_wait_ms": 4,
  "egress_region": "us-east-1",
  "fallbacks": []
}

La alerta más útil no es "RAG va lento". Alerte sobre indicadores adelantados. Los umbrales iniciales ilustrativos incluyen tiempo de espera del pool de conexiones por encima de 50 ms, tasa de 429 en embeddings por encima del 1 %, profundidad de cola del reranker por encima del 70 % de su límite configurado, p95 de búsqueda vectorial por encima de su presupuesto durante cinco minutos y tasa de timeout de recuperación por encima del 2 %. Son ejemplos, no valores universales, y deberían calibrarse con líneas base observadas, presupuestos de error y SLOs específicos de la carga de trabajo.

Runbook operativo

Cuando la latencia de recuperación aumente bruscamente, siga un orden fijo. Primero, separe el problema por salto. Si el tiempo de embedding es alto, inspeccione el estado del proveedor, el RTT de egreso, el seguimiento de conexiones NAT y la reutilización de clientes. Si la búsqueda vectorial es alta, revise QPS específico de la colección, salud de shards, selectividad de filtros, tamaño de payload y tiempo de espera del pool. Si el reranking es alto, revise profundidad de cola y cantidad de candidatos. Si el LLM empieza tarde pero la recuperación parece normal, inspeccione el ensamblaje de contexto y el tamaño del payload de tokens.

# Lista de triaje
1. Compare retrieval_total_ms vs LLM time-to-first-token.
2. Break retrieval into embed/search/BM25/rerank/context timings.
3. Check pool_wait_ms before blaming the database.
4. Check NAT/egress connection counts before blaming SaaS providers.
5. Disable optional rerank for one tenant or one route, not globally.
6. Reduce top_k and candidate fanout before adding replicas.
7. Confirm indexer jobs are not sharing the query path.
8. Restore normal limits only after p95 is stable for 15 minutes.

Arquitectura de referencia

Una red RAG resiliente a escala moderada puede usar esta línea base:

• Runtime de agentes en subredes privadas con un cliente de recuperación compartido por proceso.
• Gateway de recuperación dedicado que posee deadlines, pooling, límites de tasa, fusión y decisiones de fallback.
• Qdrant o Weaviate self-hosted en un namespace de datos con ingreso de denegación por defecto y credenciales separadas de consulta/indexación, o base de datos vectorial SaaS mediante conectividad privada.
• OpenSearch o Elasticsearch para BM25 en la misma región que la base de datos vectorial.
• Gateway de embeddings con caché, batching, política de egreso específica del proveedor y manejo explícito de 429.
• Servicio de reranker aislado detrás de su propia cola y timeout para que no pueda privar de recursos a la recuperación.
• Trazas estructuradas de recuperación exportadas a OpenTelemetry y dashboards agrupados por tenant, colección, proveedor y modelo.

La arquitectura no es específica de un proveedor. Qdrant, Pinecone y Weaviate difieren en modelo de despliegue, comportamiento de indexación y detalles de SDK, pero las reglas de red son las mismas: ubicar conjuntamente los saltos secuenciales críticos, reutilizar conexiones de larga duración mediante pooling, ejecutar ramas independientes de recuperación en paralelo, acotar el fanout, cachear transformaciones costosas y aislar los fallos antes de que los reintentos los amplifiquen.

Referencias oficiales

• Interfaces de API y SDK de Qdrant — conectividad REST y gRPC.
• Despliegue distribuido de Qdrant — sharding, replicación y operaciones de clúster.
• Endpoints privados de Pinecone — AWS PrivateLink y Azure Private Link.
• Despliegue de Weaviate en producción — configuración de producción y guía operativa.
• Kubernetes NetworkPolicy — controles de tráfico para zonas de servicio aisladas.
• Convenciones semánticas de OpenTelemetry — atributos de telemetría estandarizados.

Preguntas frecuentes

Conclusión

Los sistemas RAG fallan a escala cuando sus supuestos de red permanecen implícitos. Un prototipo puede sobrevivir con un endpoint de base de datos vectorial, una clave de API de embeddings y unas pocas llamadas de función secuenciales. Un sistema de producción necesita deadlines, pools, cachés, colas y fallbacks. La arquitectura de red es la arquitectura de confiabilidad.

Para equipos que construyen sistemas RAG agénticos, el siguiente paso de madurez es tratar la recuperación como un componente de plataforma de primera clase. Ponga un gateway delante. Asígnele presupuestos. Trace cada salto. Separe el tráfico de consultas del tráfico de indexación. Mantenga visible el egreso de embeddings. Haga que la búsqueda híbrida sea paralela. Sobre todo, decida cómo se degrada el sistema antes de que el primer incidente fuerce la decisión.