32 Embeddings, búsqueda semántica y RAG
Dónde estamos. En el Cap. 30 vimos que el prompting elicita lo que el modelo sabe, pero no le añade conocimiento. ¿Y si necesita hechos que no tiene —datos recientes, documentos privados—? La respuesta es recuperarlos y metérselos en el contexto: la generación aumentada por recuperación (RAG). Este capítulo construye sobre los embeddings y bi/cross-encoders del Cap. 26 para montar el sistema completo: recuperar → leer → generar, con su evaluación honesta.
32.1 La idea en una frase
En vez de confiar en lo que el modelo memorizó, le buscas la evidencia relevante y se la das en el contexto para que responda a partir de ella —como un examen a libro abierto—.
🧩 Analogía — el examen a libro abierto. En vez de memorizar todo el temario, el estudiante busca la página relevante y responde a partir de ella. RAG hace eso: no le pide al modelo que lo sepa todo de memoria, sino que consulte una base de documentos y conteste apoyándose en lo que encuentra.
32.2 Conceptos clave y su papel en el transformer
Antes de entrar en detalle, definimos los términos de este capítulo y para qué sirve cada uno dentro de un transformer:
- Embedding. Definición: un vector que representa el significado de un texto. En el transformer: es la moneda común de la búsqueda semántica —textos parecidos caen cerca en el espacio—.
- Recuperación densa vs dispersa (BM25). Definición: buscar por significado (vectores) o por solapamiento de palabras (BM25). En el transformer: el denso capta paráfrasis; BM25 atrapa términos exactos → el híbrido suele ganar.
- ANN (vecinos aproximados). Definición: hallar los vectores más cercanos sin comparar contra todos (HNSW, FAISS). En el transformer: hace viable la búsqueda a escala de millones, sacrificando algo de recall por velocidad.
- Reranking (bi- vs cross-encoder). Definición: recuperar muchos candidatos barato y reordenar el top con un modelo caro y preciso. En el transformer: el cross-encoder mira consulta y documento juntos → más precisión donde importa.
- Chunking. Definición: trocear los documentos en fragmentos antes de indexarlos. En el transformer: un fragmento enfocado se embebe mejor y cabe en el contexto.
- RAG. Definición: recuperar evidencia y condicionar la generación sobre ella. En el transformer: añade memoria no-paramétrica consultable frente a la paramétrica de los pesos.
- Memoria paramétrica vs no-paramétrica. Definición: lo que está en los pesos vs lo que está en un índice externo. En el transformer: la no-paramétrica se actualiza sin reentrenar —de ahí RAG—.
- Fidelidad (groundedness). Definición: en qué grado la respuesta se deriva de los documentos recuperados. En el transformer: eje aparte de la fluidez —RAG reduce, no elimina la alucinación—.
- “Lost in the middle”. Definición: los modelos usan mejor la información de los extremos del contexto que la del medio. En el transformer: dicta colocar los fragmentos relevantes al principio o al final.
Con esto en mente, montamos el sistema.
32.3 Por qué existe RAG
Cuatro problemas que el preentrenamiento solo no resuelve:
- Corte de conocimiento: los pesos congelan lo visto al entrenar; no conocen lo posterior.
- Datos privados/cambiantes: documentos de tu empresa, precios de hoy… no están en los pesos.
- Alucinación: sin saber, el modelo inventa con fluidez.
- El prompting no añade conocimiento (techo del Cap. 30): reorganiza lo que ya hay.
La distinción clave (de (Lewis et al. 2020)): el modelo es memoria paramétrica (lo que está en los pesos); el índice de documentos al que accede el recuperador es memoria no-paramétrica (lo que está fuera, consultable y actualizable). RAG condiciona la generación sobre evidencia recuperada en lugar de recitar de los pesos.
32.4 El pipeline canónico
El término lo acuñó Lewis et al. (Lewis et al. 2020): un recuperador denso (estilo DPR, Cap. 26) + un generador seq2seq (BART), de modo que los documentos recuperados condicionan la salida. Dos variantes: RAG-Sequence (usa el mismo documento para toda la respuesta) y RAG-Token (puede usar uno distinto por token). Precursores a recordar: REALM (Guu et al. 2020) (recuperación durante el preentrenamiento) y kNN-LM (Khandelwal et al. 2020) (interpola el LM con un datastore de vecinos —ayuda en lo raro/de cola larga—).
El patrón práctico de hoy es “recuperar y leer” (retrieve-then-read), normalmente con recuperador y generador congelados:
- Indexar el corpus (trocear + embeber cada fragmento).
- Embeber la consulta del usuario.
- Recuperar los top-k fragmentos más parecidos.
- Insertarlos en el prompt.
- Generar la respuesta condicionada a esa evidencia.
32.5 La mitad de recuperación (sobre el Cap. 26)
32.5.1 Denso vs disperso, e híbrido
- Denso: embeddings semánticos (DPR, E5 del Cap. 26). Recupera por significado, aunque no coincidan las palabras exactas.
- Disperso/léxico — BM25 (Robertson y Zaragoza 2009): puntúa por solapamiento de palabras ponderado (frecuencia saturada + rareza del término + longitud). Sigue siendo un baseline fuerte, sobre todo para nombres propios, códigos y términos exactos.
- Híbrido: combinar ambos suele ganar —el denso aporta semántica; el disperso atrapa coincidencias exactas y raras que el denso pierde—.
🧩 Analogía — buscar por significado, no por título. La recuperación densa es un bibliotecario que entiende lo que quieres decir y te trae libros del tema, aunque no uses sus palabras exactas; BM25 es el catálogo de palabras clave que solo casa cadenas literales. Cada uno acierta donde el otro falla → por eso se combinan.
32.5.2 Bases vectoriales: búsqueda aproximada (ANN)
Comparar la consulta contra todos los vectores es O(N) —inviable con millones—. La solución es vecinos aproximados (ANN): se sacrifica un poco de recall por muchísima velocidad. Dos piezas habituales:
- HNSW (Malkov y Yashunin 2016): un grafo navegable por el que la búsqueda “salta” hasta el vecino en tiempo casi logarítmico. Es el estándar de las bases vectoriales.
- FAISS (Johnson et al. 2017): librería con IVF (particiona el espacio en celdas y solo busca en las cercanas) y PQ (comprime los vectores para que quepan en memoria).
La idea común: estructuras que evitan comparar contra todo.
32.5.3 Reranking: la ojeada y la lectura atenta
Aquí enlaza con bi- vs cross-encoder (Cap. 26). Patrón de dos etapas: recuperar muchos candidatos barato con un bi-encoder (vectores precalculados), y luego reordenar el top con un cross-encoder caro (consulta + documento juntos → más preciso). Ejemplos: monoBERT (Nogueira et al. 2019) y monoT5 (Nogueira et al. 2020) (rerankers cross-encoder); ColBERT (Khattab y Zaharia 2020) (interacción tardía — punto medio: vectores por token, precalculables, con una comparación barata en consulta).
🧩 Analogía — agarrar 50 y leer 5. El reranking es como coger del estante 50 libros candidatos de una ojeada rápida (bi-encoder) y luego leer con cuidado el resumen de los 5 mejores (cross-encoder) para quedarte con los realmente relevantes.
32.6 Chunking e indexación
- Por qué trocear: el contexto es limitado, y un fragmento enfocado se embebe mejor que un documento entero (que diluye el tema).
- Tamaño y solapamiento: fragmentos pequeños = recuperación precisa pero pierden contexto; grandes = más contexto pero embedding borroso y ruido. El solapamiento evita cortar ideas a mitad de frase. (Son heurísticas, no teoremas: es un compromiso.)
- “Lost in the middle” (Liu et al. 2023): los modelos usan mejor la información que está al principio o al final del contexto, y peor la del medio (curva en U). Implicación para RAG: no metas un k enorme y coloca los fragmentos más relevantes en los extremos.
- Filtrado por metadatos: acotar por fecha, fuente o permisos antes/junto a la búsqueda.
🧩 Analogía — fichas de índice. El chunking es arrancar el libro en fichas para sacar solo la ficha relevante, en vez de cargar el libro entero —más fácil de encontrar y de meter en el contexto—.
32.7 Variantes y avances
- Fusion-in-Decoder (FiD) (Izacard y Grave 2021): codifica cada pasaje por separado y los fusiona en el decoder → escala a muchos pasajes sin el coste cuadrático de concatenarlos.
- REPLUG (Shi et al. 2023): recuperación para LMs caja negra (congelados); opcional, entrenar el recuperador usando el propio LM como señal.
- Self-RAG (Asai et al. 2024): el modelo decide cuándo y qué recuperar y critica sus propias salidas y los pasajes (autoevaluación).
- FLARE (Jiang et al. 2023): recuperación iterativa/activa —anticipa la siguiente frase y, si duda, recupera y regenera— frente al RAG de un solo disparo.
Con ventanas de 100k-1M+ tokens, ¿basta con meter todo y olvidarse de recuperar? El debate está abierto, pero el consenso actual es que son complementarios: (1) “lost in the middle” muestra que más contexto no se aprovecha por igual; (2) el coste/latencia crecen con el contexto; (3) RAG da atribución (de dónde sale la respuesta) y datos frescos. RAG selecciona qué meter en una ventana que sigue costando.
32.8 Evaluar RAG (honesto)
Dos ejes, y conviene no confundirlos:
- Calidad de recuperación (métricas clásicas de IR): Recall@k (¿está el documento bueno entre los k?), MRR (a qué posición media llega el primer acierto) y nDCG (premia tener lo relevante arriba del ranking).
- Calidad de generación + FIDELIDAD (groundedness): ¿la respuesta se deriva de los documentos recuperados? RAGAS (Es et al. 2024) lo evalúa sin referencia con un LLM-juez en tres ejes: faithfulness (soporte en el contexto → caza alucinaciones), relevancia de la respuesta y relevancia del contexto.
Tres cautelas: (1) el modelo puede alucinar aun con recuperación correcta —ignorar o contradecir el contexto—; por eso existe la métrica de faithfulness. (2) Los errores de recuperación se propagan: si traes basura, el generador construye sobre basura. (3) Envenenamiento de contexto: documentos erróneos, contradictorios o maliciosos degradan o secuestran la respuesta. RAG es una mejora grande pero no una garantía de verdad.
El efecto “lost in the middle” es, en el fondo, un fenómeno de atención a lo largo de la distancia —justo nuestra Parte II—. tafagent te da el γ y el horizonte efectivo de un modelo: cuánto “ve” de verdad a lo largo del contexto. Útil para decidir cuántos fragmentos tiene sentido recuperar (un modelo de horizonte corto no aprovechará un top-k enorme) y dónde colocarlos.
32.9 Resumen
- RAG (Lewis et al. 2020): recuperar evidencia y condicionar la generación sobre ella — memoria paramétrica (pesos) + no-paramétrica (índice consultable)—.
- Pipeline: indexar → embeber consulta → recuperar top-k → insertar → generar (retrieve-then-read). Precursores: REALM, kNN-LM.
- Recuperación: denso (semántico) + BM25 (léxico) → híbrido gana; ANN (HNSW, FAISS) para escalar; reranking bi→cross (ColBERT a medio camino).
- Chunking: trocear para precisión; cuidado con tamaño/solapamiento y con “lost in the middle” (relevante a los extremos).
- Variantes: FiD, REPLUG (caja negra), Self-RAG, FLARE (activo). Contexto largo vs RAG: complementarios (debate abierto).
- Evaluar: recuperación (Recall@k/MRR/nDCG) y generación + fidelidad (RAGAS). Honesto: RAG reduce, no elimina la alucinación; los errores de recuperación se propagan.
Siguiente (Capítulo 32): si en vez de solo recuperar texto el modelo puede actuar —usar herramientas, llamar APIs, planear en varios pasos—, entramos en los agentes.
32.10 Ejercicios
- Paramétrico vs no. Explica la diferencia entre memoria paramétrica y no-paramétrica. ¿Cuál actualizas sin reentrenar?
- Denso vs BM25. Da un caso donde BM25 gane a la recuperación densa y otro al revés. ¿Por qué el híbrido suele ser mejor?
- ANN. ¿Por qué no se usa kNN exacto a escala de millones de vectores? ¿Qué se sacrifica con HNSW/FAISS?
- Reranking. ¿Por qué recuperar con bi-encoder y reordenar con cross-encoder, y no usar el cross-encoder para todo?
- Lost in the middle. Si recuperas 10 fragmentos, ¿dónde colocas los más relevantes y por qué?
- Honestidad. Cita dos razones por las que RAG puede dar una respuesta equivocada aunque la recuperación funcione.