Capítulo 5 — Arquitectura de la pipeline de recuperación

Quinta entrega del recorrido capítulo por capítulo de LLM Primer III: Enhancing Enterprise AI with RAG. Una sola búsqueda vectorial es donde se quedan la mayoría de los prototipos, y donde empiezan la mayoría de los fallos en producción. El capítulo recorre el camino completo desde una consulta a medio formular hasta los candidatos finales que llegan al generador — y por qué cada etapa existe.

Por qué existe este capítulo

Los capítulos 2 a 4 produjeron un almacén vectorial: documentos parseados, troceados con cuidado, embebidos, indexados. El siguiente paso ingenuo es embeber la consulta del usuario, lanzar una búsqueda de vecino más cercano y darle el top-k al generador. Para corpus triviales esto funciona. Para producción casi nunca. Las consultas llegan subespecificadas y llenas de nombres propios que el embedder nunca ha visto; los corpus contienen cuasi-duplicados que abarrotan el tope de cualquier ranking; los identificadores y códigos cargan significado que el embedder suaviza.

El Capítulo 5 trata sobre la arquitectura hacia la que convergen los sistemas maduros. No es un artefacto de investigación. Es la forma que los equipos realmente corren cuando recall, precisión y latencia tienen que aguantar a la vez.

5.1 Por qué una sola búsqueda vectorial no basta

La recuperación densa reescribe la economía de la búsqueda, pero la misma tolerancia a la paráfrasis que vuelve útiles a los embeddings los hace también frágiles. Tokens numéricos, citas de artículos legales, códigos de transacción, números de pieza — cualquier cosa donde la forma superficial es el significado — aterriza en rincones arbitrarios del espacio vectorial. BM25, que simplemente cuenta lo que hay, no tiene ese problema.

Los dos métodos fallan en entradas disjuntas. Esa única observación es todo el argumento a favor de la recuperación híbrida, y es el primer principio sobre el que descansa el capítulo. El resto se sigue: si ningún retriever por sí solo es suficiente, la pipeline tiene que combinar varios, fusionar sus rankings con honestidad, gastar cómputo de verdad en una pasada final precisa y preparar la consulta antes de que nada de eso empiece.

5.2 Búsqueda híbrida: vectores densos y BM25 en paralelo

Dos índices sobre los mismos chunks: un índice denso HNSW o IVF del embedder, y un índice invertido disperso de BM25 o SPLADE. Los dos se consultan, los dos devuelven listas ordenadas, y la pipeline de ingesta escribe en ambos al mismo tiempo. BM25 no es legado; es la función de ranking por palabras clave más fiable jamás diseñada, con pocos parámetros pero no exenta de ellos, y a través del banco BEIR la recuperación híbrida supera a la sólo densa en la mayoría de las tareas fuera de dominio. La distancia se amplía a medida que el dominio se aleja de la distribución de entrenamiento del embedder.

Un modo de fallo concreto que vale la pena nombrar: BM25 tiene que tokenizarse correctamente para cada idioma en alcance. Servir un corpus japonés con el analizador inglés por defecto convierte en silencio la pata BM25 en puro ruido, y el sistema parece funcionar sólo porque la pata densa está haciendo todo el trabajo. La recuperación dispersa también ha evolucionado — los modelos dispersos aprendidos al estilo SPLADE heredan la simplicidad operativa de BM25 con el comportamiento de recall de un retriever denso.

5.3 Reciprocal rank fusion y reranking con cross-encoder

La forma ingenua de combinar dos listas ordenadas es sumar sus puntuaciones. No funciona — las magnitudes de BM25 son no acotadas y dependientes del corpus; las similitudes coseno viven más o menos en [-1, 1]. No son conmensurables, y cualquier ponderación fija es un problema de tuning perpetuo. Reciprocal Rank Fusion esquiva el problema tirando las puntuaciones. Para cada candidato, la puntuación fusionada es la suma de 1/(k + rank) a través de los retrievers, con k = 60. La forma es empinada arriba y plana en la cola, los resultados son insensibles a k, y el algoritmo compone de forma natural con la expansión multi-consulta — seis listas de tres paráfrasis contra dos retrievers se fusionan con la misma línea de código.

RRF no puede rescatar un documento que ningún retriever sacó a la luz; ese trabajo le toca a la reescritura de consultas. Lo que hace, barato y sin hiperparámetros, es reconciliar retrievers que se actualizan e intercambian de forma independiente — una pipeline cuya fusión no necesita reajustarse cuando una pata cambia es dramáticamente más barata de mantener.

Los bi-encoders que produjeron esos rankings nunca vieron la consulta y el chunk juntos. Un reranker cross-encoder sí — concatena el par y los pasa juntos por un transformer afinado para emitir una puntuación de relevancia. Cada cabeza de atención ve ambos lados a la vez, y el modelo puede atender a la frase concreta de la consulta que debería casar con una frase concreta del chunk. No se puede precomputar, así que es demasiado lento como retriever primario, pero es perfecto sobre los 50 a 200 candidatos que la recuperación híbrida saca a la luz. La mejora en NDCG@10 es típicamente de 5 a 15 puntos — mayor que cambiar el modelo de embedding dentro de la familia de bi-encoders.

5.4 Comprensión de la consulta: reescritura, expansión, HyDE

Todo lo de arriba asumía que la consulta venía bien formulada. Rara vez lo está. Un usuario de help-desk teclea "vacaciones"; la política habla de "derecho a permiso anual". Un desarrollador teclea "auth falla 500"; el runbook describe "el servicio de autenticación devuelve HTTP 500 con fallo de validación de token". El trabajo tiene que ocurrir en el lado de la consulta. Tres patrones componen: reescritura para que la consulta sea autocontenida (resolver pronombres, expandir acrónimos, cambiar el idioma para que case con el corpus); expansión a un puñado de paráfrasis que se reparten a ambos retrievers; y HyDE, que le pide a un modelo pequeño que escriba una respuesta hipotética y embebe eso en lugar de la pregunta. El corpus está lleno de respuestas, y las respuestas se parecen más a otras respuestas que a preguntas.

El patrón defensivo es mantener la consulta original junto a la reescrita y despachar ambas. La salida del reescritor es una hipótesis, no un reemplazo. La mayoría de las "regresiones de recuperación" en sistemas agénticos son en realidad regresiones de reescritura, y son invisibles sin telemetría por etapa.

Lo que prepara el Capítulo 5

La pipeline tal y como queda dibujada es también toda la superficie que un atacante necesita subvertir. Cada etapa toma entrada, produce salida y confía en los datos sobre los que opera. El corpus puede envenenarse en la ingesta; el embedder puede manipularse con chunks adversariales; el reranker puede sesgarse; el generador puede engañarse con instrucciones escondidas en el contenido recuperado. Desde aquí el libro abre la Parte IV, y el encuadre cambia de cómo recuperar bien a qué pasa cuando se ataca la recuperación.

Próximamente — Capítulo 6: Modelos de amenazas y vulnerabilidades en RAG. La misma apertura que hace útil a RAG es también la superficie que explotan los adversarios — envenenamiento del corpus, recuperación adversarial, inyección indirecta de prompts, inversión de embeddings y el confused deputy.