RAG y expansión de contexto: integrar el archivo de artículos del laboratorio en el "cerebro" del LLM

Al finalizar este tema

El asistente de resumen de artículos creado en el episodio 7 tiene una limitación fundamental: el modelo desconoce los materiales internos de nuestro laboratorio. Las 30 publicaciones de los últimos cinco años, los 200 protocolos del wiki del laboratorio, las 100 diapositivas de presentaciones en congresos... es imposible que estos materiales estén incluidos en los datos de entrenamiento del LLM.

La RAG (Generación Aumentada por Recuperación) que trataremos en este episodio es la arquitectura que resuelve este problema. Consiste en crear un almacén de conocimiento externo e inyectar el contexto relevante al LLM mediante búsquedas cuando sea necesario para generar respuestas. Es el punto natural donde podemos ver cómo se reutilizan en la práctica los embeddings del episodio 5 y la atención del episodio 6.

Los dos lugares del conocimiento del LLM

En el episodio 1 entendimos el LLM como una "máquina probabilística", y en los episodios 5 y 6 vimos que esta máquina comprime y almacena los patrones estadísticos de los datos de entrenamiento en decenas de miles de millones de parámetros. Sin embargo, si observamos con más detalle dónde reside este conocimiento, encontramos dos lugares.

Primer lugar: parámetros. Lo aprendido durante el proceso de entrenamiento. El hecho de que GPT-4 pueda generar la frase "las mitocondrias son las centrales eléctricas de la célula" se debe a que esta frase apareció repetidamente en los datos de entrenamiento, dejando una huella en los parámetros. Este conocimiento está fijado al propio modelo y se consulta independientemente del contexto.

Segundo lugar: ventana de contexto. La información contenida en el prompt en cada llamada. Los ejemplos few-shot del episodio 7, el nombre del tutor, el texto del artículo en revisión, etc. Este conocimiento solo se consulta a través de la atención. Cuando el modelo predice el siguiente token, la atención se centra en las partes relevantes del contexto y esa información se refleja en la respuesta.

Las características de estos dos lugares son completamente diferentes.

Para que el LLM consulte las 30 publicaciones de nuestro laboratorio, existen dos opciones.

• Opción A: Reentrenar y ajustar finamente el LLM con estos artículos. Incrustar el conocimiento en los parámetros.
• Opción B: Insertar los artículos relevantes en la ventana de contexto en cada llamada.

La opción A requiere decenas de GB de GPU y semanas de tiempo de entrenamiento. Además, sería necesario reentrenar cada vez que se añada un nuevo artículo. La opción B permite actualizaciones inmediatas sin entrenamiento. En la práctica, la mayoría de los casos utilizan variantes de la opción B.

El problema radica en cómo implementar la opción B. Incluir 30 artículos completos en el contexto supera con creces los 200 000 tokens. Además, si se aumenta a 100 o 1000 artículos, ningún modelo de contexto de 200 000 tokens podría contenerlos.

Aquí es donde entra en juego la idea de RAG: buscar e incluir solo las partes necesarias. Para cada pregunta, se buscan y se inyectan en el contexto solo algunos artículos relevantes y sus párrafos correspondientes.

Estructura básica del flujo de trabajo RAG

El flujo completo de RAG.

[Preparación: una sola vez]
30 artículos, 200 protocolos, 100 diapositivas
   ↓
Fragmentación (por párrafos y secciones)
   ↓
Cálculo del embedding de cada fragmento (modelo del episodio #5)
   ↓
Almacenamiento en la base vectorial (embedding + texto original)

[Consulta: en cada llamada]
Pregunta: "¿Hubo en el laboratorio algún caso con baja eficiencia de edición CRISPR?"
   ↓
Cálculo del embedding de la pregunta (mismo modelo)
   ↓
Recuperación de los K fragmentos más cercanos por similitud coseno
   ↓
Inserción de los fragmentos recuperados en el prompt
   ↓
Llamada al LLM → generación de la respuesta

Se necesitan tres componentes: modelo de incrustaciones, base de datos vectorial y LLM. Los dos primeros se encargan de la recuperación, y el último de la generación. La combinación de Recuperación + Generación es, como su nombre indica, RAG.

BioUbi: un nuevo enfoque para la integración de señales celulares. En el episodio #6, vimos la atención como "el principio por el cual una célula se centra en la información relevante del entorno". RAG extiende este principio un nivel más: es como añadir un sistema que aumenta dinámicamente las células vecinas (contexto) a las que una célula (LLM) puede hacer referencia. Si el principio de la atención consiste en centrarse en la información dentro del contexto, el principio de RAG consiste en reconstruir ese contexto cada vez.

Fragmentación: el tamaño de los fragmentos determina la calidad de la búsqueda

Si se incrusta un documento completo, demasiados significados se agrupan en una sola incrustación, lo que reduce la precisión de la búsqueda. Por el contrario, si se divide en unidades de palabras, la falta de contexto hace que las incrustaciones carezcan de significado. Se necesita un tamaño de fragmento adecuado.

Directrices generales.

• Tamaño del fragmento: 200～800 tokens (aproximadamente 200～1000 palabras)
• Superposición entre fragmentos del 10～20% (para evitar la pérdida de información en los límites)
• Dividir en los límites de párrafos y secciones (evitar cortar forzadamente a mitad de una palabra)

Divisor de caracteres recursivo (estándar en LangChain y LlamaIndex). Primero se divide mediante delimitadores grandes (límites de párrafo); si el fragmento sigue siendo demasiado grande, se utiliza un delimitador siguiente (límites de oración), y así sucesivamente de forma recursiva hasta alcanzar unidades más pequeñas.

splitter = RecursiveCharacterTextSplitter(
    chunk_size=500,
    chunk_overlap=50,
    separators=["\n\n", "\n", ". ", " ", ""]
)
chunks = splitter.split_text(paper.text)

Fragmentación especializada para el dominio bio.

• Artículos: Cada sección (resumen, introducción, métodos, resultados, discusión) se convierte en un fragmento separado. Se adjunta el encabezado de la sección al inicio del fragmento (para preservar el contexto).
• Protocolos: Cada paso se convierte en un fragmento separado. La lista de reactivos se agrupa en un único fragmento.
• Diapositivas: Una diapositiva = un fragmento. Si hay notas del presentador, se incluyen junto con él.
• Tablas e imágenes: Se utiliza la leyenda como encabezado del fragmento. Los datos de las tablas se mantienen en formato CSV o tabla Markdown.

Adición de metadatos. Se almacenan los metadatos con la información del artículo original (autores, año, revista, DOI) en cada fragmento. Esto se utiliza más adelante para indicar las fuentes al generar respuestas.

Búsqueda por incrustaciones: reutilización del espacio vectorial del episodio #5

El espacio de incrustaciones mencionado en el episodio #5 reaparece aquí. Esta vez, no son palabras o frases individuales, sino las incrustaciones de todo el fragmento de documento. Esto se denomina incrustación de documento o incrustación de oración.

Modelo de incrustaciones. Una red neuronal que toma un fragmento como entrada y produce un vector (generalmente de 512 a 4096 dimensiones). El método de entrenamiento consiste en hacer que los vectores de fragmentos semánticamente similares estén cercanos entre sí, y los de fragmentos diferentes estén más alejados.

Principales modelos de incrustaciones:

• OpenAI text-embedding-3: Uno de los estándares de la industria. small (1536 dimensiones) y large (3072 dimensiones). Mediante llamada a la API.
• Cohere embed v3: Fuerte capacidad multilingüe, baja latencia.
• Voyage AI: Entre los primeros en las evaluaciones recientes.
• Familia Sentence-BERT: Código abierto. all-MiniLM-L6-v2 (384 dimensiones), all-mpnet-base-v2 (768 dimensiones), etc.
• Familias BGE y E5: Entre las mejores opciones de código abierto. Buen soporte multilingüe.

Especialización para el dominio bio. Los modelos de incrustaciones generales son relativamente débiles con la terminología biológica (nombres de genes, nombres de proteínas, siglas). Si es necesario:

• BioBERT y PubMedBERT: Familia BERT preentrenada con PubMed. Puede ajustarse finamente como incrustación de oración.
• SPECTER: Incrustación académica entrenada con relaciones de citación de artículos.
• Ajuste fino propio: Ajuste fino de sentence-transformers con datos del laboratorio. Ofrece el mejor rendimiento, pero requiere datos y entrenamiento.

Se mide la similitud entre dos vectores mediante la similitud del coseno.

similarity(u, v) = ⟨u, v⟩ / (||u|| · ||v||)

Si la dirección de dos vectores es la misma, el valor es 1; si son independientes, 0; y si son opuestas, -1. Los embeddings suelen almacenarse normalizados (norma 1), por lo que la similitud del coseno se reduce simplemente al producto escalar. Es una forma abreviada de los puntajes de atención del episodio #6.

Procedimiento de búsqueda.

1. Se introduce la pregunta en el modelo de embeddings para obtener el vector de la pregunta q.
2. Se calcula la similitud del coseno entre todos los vectores fragmentados de la base de datos vectorial y q.
3. Se devuelven los K fragmentos principales (por ejemplo, K=10).

Dado que recorrer manualmente decenas de miles o millones de fragmentos en cada consulta sería lento, se utiliza un índice de Búsqueda Vecinal Aproximada (Approximate Nearest Neighbor, ANN). HNSW (Hierarchical Navigable Small World) es el estándar. Consulte el Apéndice A.7.

Base de datos vectorial: el almacén para los embeddings

Base de datos vectorial. Infraestructura que almacena embeddings junto con metadatos y procesa rápidamente las búsquedas por similitud. Las principales opciones son:

• Chroma: de código abierto, local y ligera. Ideal para empezar.
• Qdrant: de código abierto, lista para producción. Admite tanto el autoalojamiento como la nube.
• Weaviate: de código abierto, con un esquema robusto y una interfaz GraphQL.
• Pinecone: un servicio administrado, de pago. Fácil de usar.
• pgvector: una extensión de PostgreSQL. Aprovecha la infraestructura SQL existente.
• Milvus: para grandes volúmenes y uso empresarial.

Consideraciones prácticas sobre el tamaño. Si se tienen 30 artículos (20 fragmentos cada uno), se obtienen 600 vectores; Chroma es suficiente para uso local. Con 100.000 artículos (2 millones de fragmentos), se requiere una solución de nivel de producción como Qdrant o Pinecone. Comience con Chroma y migre según el crecimiento del volumen.

Forma de almacenamiento. Para cada vector:

{
  "id": "paper_2023_smith_chunk_3",
  "vector": [0.024, -0.113, ..., 0.087],  // 1536 dimensiones, float
  "content": "In this study, we investigated CRISPR editing efficiency in HEK293T cells...",
  "metadata": {
    "paper_id": "2023_Smith_Nature",
    "section": "Results",
    "authors": ["Smith J", "Lee H"],
    "year": 2023,
    "doi": "10.1038/..."
  }
}

La fuerza de la búsqueda híbrida: Dense + Sparse

Las debilidades de la búsqueda por incrustaciones (dense retrieval). Es débil en el emparejamiento exacto de palabras. Si una pregunta contiene el nombre del gen "TP53" y el documento también lo tiene, en el espacio de incrustaciones podría mezclarse con otros nombres de genes. Los identificadores precisos como nombres de genes, nombres de medicamentos, fórmulas químicas y ecuaciones son fáciles de pasar por alto para la búsqueda densa.

Para subsanar esta debilidad está la búsqueda dispersa (sparse retrieval). Es un método tradicional de recuperación de información.

BM25 (Best Matching 25). Durante más de 20 años ha sido el estándar en los motores de búsqueda. Calcula la relevancia mediante la frecuencia de términos, la longitud del documento y la frecuencia inversa del documento. Es fuerte en el emparejamiento exacto de palabras.

Búsqueda híbrida (Hybrid Search). Combina los resultados de las búsquedas densas y dispersas.

• Busca los K primeros elementos con cada método.
• Fusiona los rangos de ambos resultados mediante Reciprocal Rank Fusion (RRF).

RRF_score(doc) = Σ_i 1 / (k + rank_i(doc))

k = 60 Valor predeterminado. Cuanto mayor sea la posición en cada método, mayor será el aumento de la puntuación.

Guía práctica. En dominios con muchos términos técnicos e identificadores (bioinformática, medicina, derecho, patentes), el enfoque híbrido ofrece mejoras significativas en comparación con el uso exclusivo de incrustaciones densas. En las pruebas comparativas de rendimiento de búsqueda, el enfoque híbrido suele ser superior.

Tendencias recientes. Han surgido incrustaciones dispersas entrenadas, como ColBERT y SPLADE, que combinan las ventajas de los enfoques densos y dispersos en un solo modelo. Estas incrustaciones obtienen buenos resultados en las pruebas comparativas más recientes.

Reordenación: el poder del filtro final

La búsqueda por incrustaciones es rápida, pero su precisión no es perfecta. Es posible que algunos de los diez primeros resultados de la búsqueda no sean realmente relevantes.

Reordenador (modelo de reordenación). Reevalúa los K candidatos recuperados mediante un modelo más preciso. El enfoque cross-encoder es el estándar.

Bi-encoder frente a Cross-encoder.

• Bi-encoder (búsqueda por incrustaciones): Convierte la pregunta y el documento en incrustaciones por separado y calcula la similitud. Es rápido, pero la interacción entre los dos textos se resume en un único valor de similitud.
• Cross-encoder (reordenador): Introduce la pregunta y el documento conjuntamente en un transformador para calcular directamente la puntuación de relevancia. Es preciso, pero más lento.

Dado que el cross-encoder calcula la atención entre todos los pares de palabras de ambos textos (véase la nota #6), permite juicios mucho más detallados. Sin embargo, esto implica un mayor costo computacional que impide procesar todos los documentos. El estándar es un pipeline de dos pasos: primero, filtrar 100 documentos mediante incrustaciones y, luego, reordenar los 10 mejores con el cross-encoder.

Principales reordenadores.

• Cohere Rerank v3: API gestionada.
• BGE-Reranker: Código abierto, multilingüe.
• Voyage Rerank: Destacado en las pruebas comparativas.

Efecto. Es común observar que la tasa de aciertos mejora del 60 % al 80 % al añadir un reordenador cuando se utilizan únicamente los 10 primeros resultados de las incrustaciones.

Limitaciones de RAG: ¿dónde falla?

RAG no es una solución universal. A continuación, se describen los tipos de fallo más frecuentes en la práctica.

Limitación 1: Si la búsqueda falla, la respuesta también. Aunque la base de datos vectorial contenga la evidencia necesaria para la respuesta, si la búsqueda no la encuentra, el LLM no podrá hacer referencia a ella. Esto ocurre cuando el fragmentado (chunking) es inadecuado, el modelo de incrustaciones es débil para el dominio o la pregunta utiliza una expresión que no se ajusta al sistema de búsqueda. → Reescritura de la consulta y búsqueda con múltiples consultas son estrategias de respuesta.

Limitación 2: Dificultad en el razonamiento combinado. Cuando la respuesta requiere integrar información dispersa en varios documentos. Por ejemplo, "lista de líneas celulares utilizadas por nuestro laboratorio de investigación en los últimos cinco años" exige consolidar información de las secciones de métodos de 30 artículos; no es posible responder basándose únicamente en cada documento individualmente. → RAG agéntico y recuperación multi-paso son estrategias de respuesta.

Limitación 3: Precisión de las citas. Aunque un LLM genere respuestas a partir de documentos recuperados, puede inventar información que no está en los documentos (alucinación, episodio #11). La presencia de resultados de búsqueda no garantiza una defensa completa. → Solicitar citas explícitas y forzar la indicación de las fuentes.

Limitación 4: Preguntas negativas. Si se pregunta por ausencias, como "¿qué líneas celulares no ha estudiado nuestro laboratorio?", RAG enfrenta dificultades. Esto se debe a que la búsqueda no puede encontrar lo que no existe. → Reformular la pregunta en forma afirmativa.

Limitación 5: Información reciente vs. retraso en la actualización del repositorio de búsqueda. Si la base de datos vectorial no es en tiempo real, se pierde información reciente. → Actualizaciones incrementales e indexación en tiempo real.

RAG en la era del contexto extenso: ¿sigue siendo necesario?

Los modelos de contexto de 1 millón de tokens que surgieron entre 2024 y 2025 (Gemini 1.5, Claude 3.5, GPT-4.1, etc.) han generado debate. Surge la pregunta: "Ahora que el contexto es tan grande, ¿sigue siendo necesario RAG?".

Razones por las que RAG sigue siendo necesario.

• Costo. Incluir 1 millón de tokens en cada llamada dispara los costos y la latencia. RAG introduce solo K fragmentos (~10K tokens), lo que resulta mucho más económico y rápido.
• Precisión. Incluso con un contexto de 1 millón de tokens, los modelos muestran el problema de "pérdida en el medio" (lost in the middle). Ignoran la información ubicada en posiciones intermedias. Al comprimir e incluir solo las partes relevantes mediante RAG, la precisión aumenta.
• Escalabilidad. 1 millón de tokens no son suficientes para 1000 artículos. El volumen real en la práctica supera constantemente esta cifra.
• Atribución y transparencia. Permite rastrear qué documentos se utilizaron para generar la respuesta. Es esencial en industrias reguladas.

Utilidad del contexto extenso. En tareas específicas donde el contexto completo es realmente necesario (por ejemplo, un análisis profundo de un artículo completo), el contexto extenso tiene ventaja. RAG y el contexto extenso no son sustitutos, sino que tienen una división de roles.

Arquitectura híbrida. En la práctica, es común extraer entre 100 y 1000 fragmentos relevantes mediante RAG e insertarlos en un modelo de contexto extenso. Se combinan así la capacidad de búsqueda de RAG con la potencia de integración del contexto extenso.

Escenarios de aplicación biológica

Escenario 1: Chatbot de conocimiento de artículos y protocolos de laboratorio

Indexar mediante RAG los 30 artículos, los 200 protocolos y las notas de clase del tutor de su laboratorio. Permitir realizar preguntas a través de un bot de Slack o una interfaz web.

# Preparación (una sola vez)
from langchain.text_splitter import RecursiveCharacterTextSplitter
from langchain_community.vectorstores import Chroma
from langchain_openai import OpenAIEmbeddings

splitter = RecursiveCharacterTextSplitter(chunk_size=500, chunk_overlap=50)
docs = load_lab_documents()  # papers, protocols, notes
chunks = splitter.split_documents(docs)

embeddings = OpenAIEmbeddings(model="text-embedding-3-large")
vectorstore = Chroma.from_documents(chunks, embeddings, persist_directory="./lab_db")

# Consulta (en cada llamada)
def ask_lab(question):
    docs = vectorstore.similarity_search(question, k=10)
    context = "\n\n".join([d.page_content for d in docs])

    prompt = f"""Eres un asistente que responde consultando los materiales de nuestro laboratorio.

Responde basándote en los materiales siguientes y cita cada fuente al final como [autor, año, sección].
Si la información no aparece, responde "No consta en los materiales de nuestro laboratorio".

Materiales:
{context}

Pregunta: {question}
Respuesta:"""

    return llm(prompt, temperature=0)

# Uso
ask_lab("¿Hubo algún caso con una eficiencia de edición CRISPR inferior al 20 %?")

Escenario 2: Asistente de búsqueda de literatura de ensayos clínicos

Realiza una búsqueda exhaustiva de los resultados de ensayos clínicos para enfermedades y tratamientos específicos.

• Fuentes de datos: ClinicalTrials.gov, PubMed, resúmenes de congresos.
• Fragmentación (Chunking): Cada ensayo se considera un documento. Los resúmenes, protocolos y resultados se dividen en fragmentos separados.
• Búsqueda híbrida: Los nombres de fármacos y genes se benefician mucho de BM25, por lo que la búsqueda híbrida es esencial.
• Reclasificador (Reranker): La precisión en la determinación de la relevancia clínica influye directamente en la calidad de la respuesta.
• Filtro de metadatos: Combina filtros como "Fase 3", "a partir de 2020" y "solo adultos" con la búsqueda vectorial.

Este tipo de asistente se está implementando actualmente en los equipos de investigación de las CRO y los hospitales.

Escenario 3: Sistema de preguntas y respuestas sobre conocimientos de genes y proteínas

Sistema de preguntas y respuestas sobre genes que utiliza incrustaciones de BioBERT y datos de UniProt y Ensembl.

• Divide la página de UniProt de un gen en varios fragmentos (función, estructura, enfermedad, PTM, etc.).
• Utiliza incrustaciones especializadas para el dominio (BioBERT).
• Pregunta del usuario: "¿Qué quinasa interactúa con TP53?" → Busca fragmentos relevantes → El LLM resume la información.

Esta categoría constituye la base tecnológica de las herramientas de biotecnología comerciales más recientes (como Elicit y Consensus).

Resumen clave

• Los dos pilares del conocimiento del LLM: los parámetros (fijos o que requieren un reentrenamiento) y la ventana de contexto (inmediata, pero limitada).
• RAG es una arquitectura que inyecta dinámicamente conocimiento externo en el contexto. Combina la búsqueda y la generación.
• Flujo de trabajo: fragmentación → incrustaciones → base de datos vectorial → búsqueda → inyección en el prompt → LLM.
• La fragmentación (Chunking) utiliza entre 200 y 800 tokens, con una superposición del 10% al 20%. Respeta los límites de las secciones.
• La búsqueda por incrustaciones es una extensión natural del espacio de incrustaciones descrito en el episodio #5. Utiliza la similitud del coseno.
• Base de datos vectorial: comienza con Chroma; para escalar, utiliza Qdrant o Pinecone.
• La búsqueda híbrida (densa + BM25) mejora la coincidencia exacta de los identificadores. Se combina mediante RRF.
• El reclasificador (Reranker) (codificador cruzado) mejora la precisión final. Flujo de trabajo de dos etapas.
• Limitaciones: fallos en la búsqueda, razonamiento combinado, errores de citación, preguntas negativas.
• RAG sigue siendo válido en la era del contexto largo. Debido a las ventajas en cuanto a coste, precisión (evita la "pérdida en el medio") y escalabilidad.

Próximos conceptos

• Episodio #9 agent-and-tool-use — Patrón de agente en el que el LLM llama a herramientas. RAG es una de las herramientas del agente.
• Episodio #10 context-window-management — Técnicas prácticas para gestionar eficazmente la ventana de contexto.
• Episodio #11 hallucination-and-alignment — Por qué RAG no logra eliminar por completo las alucinaciones.

📐 Apéndice — Fórmulas matemáticas para expertos

Dificultad: Muy alta Dirigido a: Lectores con conocimientos en recuperación de información, probabilidad y optimización

A.1 Similitud del coseno y producto escalar

Dos vectores u, v ∈ ℝ^d:

cos_sim(u, v) = ⟨u, v⟩ / (||u||_2 · ||v||_2)

Si el vector está normalizado (||u||_2 = 1), la similitud coseno es igual al producto escalar:

cos_sim(u, v) = ⟨u, v⟩ = Σ_i u_i v_i

Parte #6 Relación con la puntuación de atención. La ⟨Q_i, K_j⟩ de la atención también tiene la misma estructura interna. La búsqueda en RAG es conceptualmente análoga al cálculo de la primera puntuación de atención.

A.2 Aprendizaje por contraste para el entrenamiento del modelo de incrustaciones

Se utiliza la familia de modelos Sentence-BERT. Los pares similares se acercan y los pares diferentes se alejan.

Función de pérdida de tripletas:

L = max(0, ||f(a) - f(p)||^2 - ||f(a) - f(n)||^2 + margin)

a: Ancla, p: Positivo (similar), n: Negativo (irrelevante). Aumentar la distancia del negativo en una proporción de margin (por ejemplo, 0.5).

Función de pérdida InfoNCE (familia SimCLR, estándar de la industria):

L = -log[ exp(sim(f(a), f(p)) / τ) / Σ_k exp(sim(f(a), f(k)) / τ) ]

τ: temperatura. Las demás instancias del minibatch se utilizan automáticamente como ejemplos negativos.

A.3 Fórmula BM25

Documento D, consulta Q = {q_1, ..., q_n}:

BM25(D, Q) = Σ_i IDF(q_i) · TF(q_i, D) · (k_1 + 1) / (TF(q_i, D) + k_1 · (1 - b + b · |D| / avgdl))

• IDF(q_i) = log((N - n_i + 0.5) / (n_i + 0.5) + 1). N: número total de documentos, n_i: número de documentos que contienen q_i.
• TF(q_i, D): frecuencia del término q_i en el documento D.
• avgdl: longitud promedio de los documentos.
• Parámetros: k_1 = 1.2~2.0, b = 0.75.

Justificación. Las palabras que aparecen con frecuencia tienen un IDF bajo, lo que reduce su peso. Si una palabra se repite mucho en un documento, el TF es alto. Los documentos más largos se normalizan. Es el estándar de los motores de búsqueda desde hace 30 años.

A.4 Reciprocal Rank Fusion (RRF)

Combina las clasificaciones de múltiples métodos de búsqueda:

RRF_score(d) = Σ_{r ∈ R} 1 / (k + rank_r(d))

• R: Conjunto de métodos de búsqueda (por ejemplo, denso, disperso).
• rank_r(d): Clasificación del documento d en el método r (1 es el mejor).
• k = 60 (valor predeterminado empírico).

Ventajas: Se utiliza únicamente la clasificación, no la puntuación absoluta de cada método. Permite ignorar las diferencias de escala.

A.5 Fórmula de reordenamiento con Cross-Encoder

Entrada del cross-encoder:

[CLS] question [SEP] document [SEP]

Para toda esta secuencia, el transformador (de la familia BERT/RoBERTa) calcula la atención. La representación final del token [CLS] se procesa mediante una capa lineal para obtener la puntuación de relevancia:

score = W · h_{CLS} + b

Costo de computación. El Bi-encoder realiza cálculos independientes en dos encoders, por lo que al buscar K documentos, pasa por el encoder 2K veces. El Cross-encoder pasa por el encoder K veces para cada par (Q, D), pero es mucho más lento si K es grande.

Práctica: pipeline 100 candidatos con bi-encoder → top 10 con cross-encoder.

A.6 Índice HNSW

Hierarchical Navigable Small World. El estándar actual para la búsqueda de proximidad aproximada.

Estructura: Grafo multinivel. Las capas superiores son sparse (pocos nodos, aristas largas), las capas inferiores son dense (muchos nodos, aristas cortas). Durante la búsqueda, se establece una dirección aproximada en las capas superiores y se realiza una exploración precisa en las capas inferiores.

Complejidad temporal: O(log N) — muy rápido en comparación con la búsqueda exacta O(N).

Precisión: Ajustable según los parámetros (M, ef_construction, ef_search). Generalmente es posible mantener un recall de 95%+.

Memoria: El vector en sí + la estructura del grafo. El overhead del grafo es aproximadamente 1～2 veces el tamaño del vector.

A.7 Técnicas de Query Rewriting

HyDE (Hypothetical Document Embeddings):

1. Se introduce la pregunta en un LLM para generar primero un "documento de respuesta hipotético".
2. Se realiza la búsqueda embebiendo esta respuesta hipotética.

Razón. Las preguntas y las respuestas tienen formas de expresión diferentes, pero las respuestas entre sí tienen expresiones similares. Al buscar con una respuesta hipotética, se logra un mejor emparejamiento con los documentos que contienen la respuesta real.

Multi-Query:

1. Se reescribe la pregunta de diversas maneras usando un LLM (diferentes expresiones, diferentes ángulos).
2. Se realiza la búsqueda con cada consulta y luego se combinan los resultados.

A.8 Fenómeno "Lost in the Middle" en Long-Context

Observado por Liu et al. (2023). Los LLM tienden a encontrar bien la información al principio y al final de un contexto largo, pero pierden la información situada en el medio.

Curva de precisión. Si se grafica la posición del contexto en el eje x y la tasa de acierto en el eje y, se obtiene una forma de U. El inicio y el final están al 90%, mientras que el medio está al nivel del 60%.

Mitigación:

• Colocar la información importante al principio o al final del contexto.
• Utilizar un Reranker para colocar los fragmentos superiores al principio del contexto.
• Utilizar RAG para comprimir solo las partes relevantes en lugar de usar Long-context.

A.9 Formulación probabilística de RAG

Pregunta q, respuesta a, fragmento de documento d.

Perspectiva de Naive Bayes:

P(a | q) = Σ_d P(a | q, d) · P(d | q)

• P(d | q): Probabilidad de búsqueda (similitud de incrustaciones).
• P(a | q, d): Probabilidad de la respuesta dado el documento (LLM).

Fusion-in-Decoder (FiD). Codifica de forma independiente los K documentos recuperados y los combina en el decodificador. Las arquitecturas RETRO y Atlas utilizan este enfoque.

Retrieval-Augmented Language Model (RALM). Integra la búsqueda directamente en los parámetros del modelo. RETRO y REALM son ejemplos. Realiza búsquedas de referencia en cada paso de entrenamiento.

A.10 Métricas de rendimiento de RAG

Fase de recuperación:

• Recall@K: Proporción de respuestas correctas que se encuentran entre los K primeros resultados.
• Precision@K: Proporción de resultados verdaderamente relevantes entre los K primeros.
• MRR (Mean Reciprocal Rank): Promedio de los recíprocos de las posiciones de las respuestas correctas.
• NDCG (Normalized Discounted Cumulative Gain): Relevancia ponderada por posición, normalizada.

Fase de generación:

• Fidelidad: ¿Se basa la respuesta en los documentos recuperados?
• Relevancia de la respuesta: ¿Está relacionada la respuesta con la pregunta?
• Precisión y exhaustividad del contexto: ¿Contiene el contexto recuperado la información necesaria para la respuesta?

Herramientas. Marcos de trabajo como RAGAS y TruLens miden automáticamente estas métricas.

Referencias

El contenido, los escenarios, las analogías y los datos numéricos de esta sección son desarrollos propios de BioPlayground; a continuación, se presentan referencias externas que pueden ayudar en el aprendizaje conceptual:

• Artículo original sobre RAG: Lewis et al., "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks" (NeurIPS 2020)
• Dense Passage Retrieval: Karpukhin et al., "Dense Passage Retrieval for Open-Domain Question Answering" (EMNLP 2020)
• BM25: Robertson & Zaragoza, "The Probabilistic Relevance Framework: BM25 and Beyond" (2009)
• Sentence-BERT: Reimers & Gurevych, "Sentence-BERT: Sentence Embeddings using Siamese BERT-Networks" (EMNLP 2019)
• HNSW: Malkov & Yashunin, "Efficient and robust approximate nearest neighbor search using Hierarchical Navigable Small World graphs" (TPAMI 2020)
• Lost in the Middle: Liu et al., "Lost in the Middle: How Language Models Use Long Contexts" (TACL 2023)
• HyDE: Gao et al., "Precise Zero-Shot Dense Retrieval without Relevance Labels" (ACL 2023)
• Fusion-in-Decoder: Izacard & Grave, "Leveraging Passage Retrieval with Generative Models" (EACL 2021)
• RETRO: Borgeaud et al., "Improving language models by retrieving from trillions of tokens" (ICML 2022)
• BioBERT: Lee et al., "BioBERT: a pre-trained biomedical language representation model" (Bioinformatics 2020)
• Documentación de LangChain: python.langchain.com
• Documentación de LlamaIndex: docs.llamaindex.ai
• Recuperación contextual de Anthropic: anthropic.com/news/contextual-retrieval

En el episodio #8, aprendimos cómo incorporar conocimiento externo a un modelo de lenguaje grande (LLM). En el episodio #9, analizaremos el patrón de agente, en el que el LLM invoca de forma autónoma herramientas (búsqueda, cálculo, llamadas a API).