# RAG de punta a punta: un tutorial práctico

Idea clave: el valor de RAG no está en “enchufar un vector store”: está en leer bien los documentos, buscar de forma híbrida, reordenar (reranking) y, sobre todo, medir el retrieval y las respuestas por separado.

En las pruebas de Anthropic (2024), agregar contexto a los chunks, BM25 y un reranker redujo en 67% las fallas de recuperación. Las herramientas comerciales de RAG legal alucinan el 17–33% de las veces (Stanford, 2024), y en el benchmark CRAG de Meta (2024) los mejores sistemas RAG industriales responden sin alucinar solo el 63% de las veces. Para medir todo esto, un juez LLM coincide con los humanos más del 80% de las veces (Zheng et al., 2023).

Verifiqué casi todo lo que aparece aquí contra la documentación oficial y los papers citados el 23 de septiembre de 2026. Algunos detalles de herramientas marcados con † vienen de la experiencia general y no los volví a comprobar. Las funciones marcadas como (preview) existen, pero el proveedor todavía no las recomienda para producción. Las siglas se explican la primera vez que aparecen y están reunidas en el glosario del final; los papers se citan por su nombre en el texto (SPLADE, ColBERT, RAGAS), con autores, año y enlace en las referencias.

Parte I · Conceptos

1. Qué es RAG, explicado con una biblioteca

RAG (Retrieval-Augmented Generation) significa que, antes de responder, un modelo de lenguaje busca en tus documentos y responde a partir de lo que encontró, citando la fuente.

¿Para qué lo necesitas? Un modelo de lenguaje no conoce los documentos internos de tu empresa, su conocimiento se detiene en una fecha de corte y puede inventar cosas (“alucinar”). Con RAG la respuesta se apoya en documentos concretos que cualquiera puede revisar, y actualizar el conocimiento no obliga a reentrenar el modelo.

La forma más fácil de ver cómo encajan las piezas es pensar en una biblioteca y en alguien que llega al mostrador con una pregunta:

1. La biblioteca son tus documentos: todo aquello de lo que el sistema puede sacar respuestas, como PDFs, wikis o políticas internas.
2. Las fichas son los chunks. Nadie relee un libro entero por cada pregunta, así que cada documento se corta en fichas pequeñas, cada una con un trozo de información que se entiende por sí solo.
3. El catálogo es el índice. Cada ficha se archiva de dos maneras: por las palabras que contiene y por lo que significa. Eso es lo que después permite buscar tanto por palabra clave como por significado.
4. El bibliotecario es la búsqueda. Cuando llega una pregunta, trae rápido unas 50 fichas que parecen relevantes, sin leerlas a fondo.
5. El experto es el reranker. Lee la pregunta junto a cada una de esas fichas y se queda con las 5 mejores.
6. El redactor es el modelo de lenguaje. Solo ahora alguien escribe la respuesta, usando esas 5 fichas y citando la ficha de la que sale cada frase. Si las fichas no contienen la respuesta, lo honesto es decir “no lo sé”.
7. El profesor es la evaluación. Califica dos cosas por separado: si el bibliotecario trajo las fichas correctas y si la respuesta es fiel a ellas.

El resto del tutorial sigue el mismo orden: preparar los documentos (etapas 1 a 3), búsqueda (4), reranking (5), generación (6) y evaluación (7).

No todos los sistemas RAG tienen las siete etapas. Gao et al. (2023/24) distinguen tres generaciones:

En términos de la biblioteca, el Naive RAG es un bibliotecario que le pasa las primeras k fichas directamente al redactor, sin el experto de por medio. Este tutorial describe un Advanced RAG, con piezas modulares donde compensan (sección 10).

2. Los tres circuitos de un sistema RAG en producción

Un sistema RAG en producción funciona con tres circuitos. El primero prepara los documentos una sola vez, fuera de línea: fuentes, parsing y chunking, embeddings e índice (etapas 1 a 3 de la biblioteca). El segundo se ejecuta con cada pregunta: búsqueda híbrida, reranker y el modelo que responde con citas (etapas 4 a 6). El tercero evalúa, antes del despliegue con un golden dataset y en producción con muestras del tráfico real, y devuelve mejoras a los otros dos (etapa 7). Las partes II a VI los recorren en ese orden.

Parte II · Preparar los documentos

3. Leer bien el documento (parsing)

El parsing influye más que cualquier otro paso, y es el que los equipos más descuidan. Si conviertes un PDF a “texto plano”, pierdes los títulos, las tablas se desordenan y cada chunk pierde su contexto.

Los estudios coinciden en esto:

• Los autores de ColPali (ICLR 2025) “suelen encontrar que optimizar el pipeline de ingesta da mejoras mucho mayores que optimizar el modelo de embeddings”. ColPali mismo se salta la extracción de texto y el chunking, e indexa directamente imágenes de las páginas; en el benchmark ViDoRe obtuvo 81.3 nDCG@5 frente a ~65–67 de los pipelines basados en parsing.
• En el estudio de Unstructured sobre FinanceBench (2024), hacer chunking por elementos del documento (títulos, tablas) alcanzó 53.2% de exactitud frente a 48.2% con chunks fijos de 512 tokens, y usó la mitad de chunks.
• Un estudio en turco (2026) encontró que el chunking que tiene en cuenta el layout ayuda mucho más en documentos con tablas que en documentos que solo tienen texto.

Las herramientas habituales son el Document Layout skill (Azure), Document AI Layout Parser (Google) y Docling (IBM, código abierto). La sección 22 las compara.

4. Chunking

El chunking divide cada documento en pedazos pequeños (chunks) que se indexan por separado.

4.1 Las estrategias

4.2 Lo que dice la evidencia: el chunking semántico está sobrevalorado

• Vectara (2024) se preguntó “Is Semantic Chunking Worth the Computational Cost?” y concluyó que “los costos computacionales del chunking semántico no se justifican con mejoras de rendimiento consistentes”. El chunking de tamaño fijo ganó en los 4 datasets de documentos reales (en HotpotQA, por ejemplo, F1@5 fue 90.59 con fijo vs 87.37 con semántico). El modelo de embeddings importó más que el chunking.
• Chroma (2024) encontró que la estrategia de chunking mueve el recall hasta un 9%. Su chunker semántico por defecto quedó un poco por debajo del promedio (83.6% de recall), mientras que un chunker recursivo de 200 tokens sin solapamiento llegó a 88.1%. El mejor resultado (91.9%) usó un modelo de lenguaje y costó mucho más.
• NVIDIA (junio de 2025) obtuvo la mejor exactitud promedio (0.648) y la menor varianza entre datasets con chunking por página.
• En biomedicina (2026), el chunking semántico ganó +8.4 puntos de F1 en un dataset, pero en los demás el chunking de tamaño fijo “sigue siendo competitivo o mejor”. Depende del dominio.

4.3 Lo que sí funciona: agregar contexto a cada chunk

La Contextual Retrieval de Anthropic (sep. 2024) pone a un modelo a escribir 50–100 tokens de contexto y los antepone a cada chunk. Medido como la tasa de fallas de recuperación dentro de los 20 primeros resultados, partiendo de una línea base de 5.7%:

• contexto solo en los vectores: 3.7% (−35%)
• contexto en los vectores y en BM25: 2.9% (−49%)
• todo lo anterior más un reranker: 1.9% (−67%)

El costo, que se paga una sola vez, es de ~$1.02 por millón de tokens de documento con prompt caching. Ten cuidado al citar estas cifras: los tres porcentajes son reducciones respecto a la línea base de 5.7%, así que el aporte propio del reranker es el paso de 2.9% a 1.9%.

El late chunking (Jina, 2024) calcula primero el embedding del documento completo y solo después lo divide, así que cada vector “sabe” de qué documento viene. Mejora nDCG@10 entre +2.7% y +3.6% sin reentrenar.

4.4 Tamaños para empezar

Bhat et al. (2025) sugieren 64–128 tokens para preguntas factuales cortas y 512–1024 tokens para preguntas que necesitan un contexto amplio. Azure recomienda empezar con 512 tokens y 25% de solapamiento, y agregar el título del documento a los chunks intermedios.

Un punto de partida razonable: empieza con chunking recursivo o por sección/página de 256–512 tokens, no partas las tablas, agrega contexto y ajusta midiendo (Parte VI).

5. Convertir el texto en vectores (embeddings)

Un embedding es una lista de números que representa el significado de un texto. Los textos con significados parecidos quedan cerca unos de otros:

Mide con tus propios datos. Los leaderboards públicos (como MTEB) cambian cada mes y no siempre reflejan tu dominio. Y fija la versión del modelo: si mezclas vectores de modelos distintos, las búsquedas dejan de tener sentido.

6. Índice y permisos

El índice guarda cada chunk con su texto, su vector y sus metadatos:

Sin allowed_groups y un filtro de seguridad en cada búsqueda, un pasante podría recibir chunks de documentos del comité ejecutivo.

Parte III · Recuperación

7. BM25: búsqueda por palabras clave

BM25 es el algoritmo clásico de búsqueda por palabras clave (léxica) y el que viene por defecto en Elasticsearch, OpenSearch y Azure AI Search. Funciona sobre un índice invertido, que se parece al índice alfabético al final de un libro:

El puntaje tiene tres partes:

BM25 es rápido, no necesita modelo, se puede explicar y es excelente para términos exactos como códigos, siglas y nombres propios. Su debilidad son los sinónimos: “laptop barata” no encuentra “notebook económica”.

8. Búsqueda semántica: por significado

8.1 Vectores densos (búsqueda de vecinos más cercanos)

Aquí la pregunta se convierte en un vector y recuperas los chunks más cercanos. Hacerlo rápido sobre millones de vectores requiere un índice aproximado, normalmente HNSW (un grafo de vecinos).

La búsqueda densa entiende sinónimos, paráfrasis e idiomas distintos. En cambio, es una caja negra (no puedes explicar por qué algo coincidió), puede confundir códigos casi idénticos (ORA-00942 vs ORA-00943) y usa más memoria. La cuantización reduce la memoria comprimiendo los números, por ejemplo a 8 bits o a binario.

8.2 Disperso aprendido (SPLADE, ELSER)

El disperso aprendido (learned sparse) queda entre los dos. Un modelo amplía el texto con términos relacionados y sus pesos, y luego la búsqueda corre sobre un índice invertido, como con BM25:

"cheap laptop" → { laptop: 2.1, notebook: 1.8, computer: 1.2, cheap: 1.9, budget: 1.5, price: 0.9 }

Es más fácil de explicar que los vectores densos y aun así encuentra sinónimos. El problema es que depende del idioma del modelo (ELSER se recomienda solo para inglés) y tiene un límite de tokens (ELSER codifica los primeros 512 tokens de cada campo).

8.3 Cuál gana

Ninguno gana siempre, y por eso se combinan.

9. Búsqueda híbrida y RRF

9.1 El problema

Las dos búsquedas devuelven puntajes en escalas incompatibles:

Sumar 12.4 + 0.81 tiene tanto sentido como sumar euros y kilos.

9.2 La solución: RRF (Reciprocal Rank Fusion)

RRF ignora los puntajes y usa solo la posición de cada documento en cada lista:

RRF(doc) = Σ  1 / (k + position of doc in that list)      with k = 60 typically
       over each list

Tomemos los mismos rankings de arriba:

doc_A gana porque está arriba en las dos listas. RRF premia el acuerdo entre los dos métodos.

9.3 ¿Por qué k = 60?

El valor viene del paper original (Cormack, Clarke y Büttcher, SIGIR 2009), donde se eligió de forma empírica, y Azure AI Search documenta que funciona mejor con valores pequeños como 60.

9.4 Ventajas, límites y variantes

RRF no necesita calibrar escalas ni entrenar nada, y acepta N listas (BM25, varios vectores, varias reformulaciones de la pregunta). Tiene dos debilidades. Ignora la magnitud, así que ser primero “por mucho” vale lo mismo que ser primero “por poco”. Y una lista mala cuenta igual: si la búsqueda vectorial devuelve basura, esa basura también suma puntos.

Hay dos variantes comunes:

• El RRF ponderado le da más peso a una de las listas (por ejemplo, la vectorial ×2). Está disponible en Azure (vector weighting), en el EnsembleRetriever de LangChain † y en Google Vector Search con rrf_ranking_alpha.
• La combinación lineal normaliza los puntajes y los suma con pesos. Aprovecha la magnitud, pero hay que calibrarla con datos. Ejemplos son el retriever linear de Elasticsearch y DBSF en Qdrant †.

Ten en cuenta que RRF no es un reranker. Solo fusiona listas, y el reranker viene después.

10. Estrategias avanzadas de recuperación

11. Caso de estudio: Elasticsearch

Elasticsearch tiene cuatro piezas “semánticas” distintas, y es fácil confundirlas:

• A. Denso: dense_vector + consulta knn, con cuantización int8, int4 y BBQ. Puedes usar E5 (multilingüe), Jina (a través del Elastic Inference Service) o modelos externos (OpenAI, Azure OpenAI, Cohere, Bedrock, Vertex AI, Hugging Face).
• B. ELSER expande términos. Lo que aporta son asociaciones aprendidas, no sinónimos. En el benchmark BEIR de la propia Elastic mejora nDCG@10 sobre BM25 en un 18% en promedio (10 victorias, 1 empate, 1 derrota). Se recomienda para inglés, lee 512 tokens por campo y requiere una suscripción de pago.
• C. Reranker: el retriever text_similarity_reranker o el comando RERANK en ES|QL.
• D. semantic_text (GA desde la versión 9.0). Si no fijas inference_id, los índices nuevos pueden usar otro modelo después de actualizar de versión, así que fija siempre el modelo en producción.

Así se ve una búsqueda híbrida con reranker en una sola llamada:

{
  "retriever": {
    "text_similarity_reranker": {
      "retriever": {
        "rrf": {
          "retrievers": [
            { "standard": { "query": { "match":    { "content": "remote work days manager Spain" } } } },
            { "standard": { "query": { "semantic": { "field": "content_semantic",
                                                     "query": "remote work days manager Spain" } } } }
          ],
          "rank_window_size": 50,
          "rank_constant": 60
        }
      },
      "field": "content",
      "inference_id": "my-rerank-endpoint",
      "inference_text": "remote work days manager Spain",
      "rank_window_size": 50
    }
  }
}

También puedes fusionar con el retriever linear (normalizadores minmax o l2_norm) o, en ES|QL, con FORK + FUSE (RRF o LINEAR) + RERANK. En el formato multi-field, Elastic normaliza los campos léxicos y los semánticos para que cada grupo aporte el 50%.

Ojo con el vocabulario. En Elastic, “semantic search” significa buscar con embeddings; en Azure, el “semantic ranker” es un reranker.

Parte IV · Reranking

12. Reranking

12.1 Qué es

Un reranker toma los ~50–150 candidatos de la búsqueda y los reordena leyendo juntos la pregunta y cada chunk. Eso es más preciso que comparar vectores, pero más lento, así que solo se aplica a unos pocos candidatos.

La arquitectura típica tiene dos etapas: una búsqueda híbrida (que prioriza la cobertura), luego un reranker sobre 100–150 candidatos y, al final, entre 10 y 20 chunks que pasan al modelo que escribe la respuesta.

12.2 Tipos

12.3 Modelos destacados (verificados)

12.4 Reglas prácticas

Un reranker es la mejora más barata y más probada que puedes hacer. En las cifras de Anthropic, agregar solo eso lleva la tasa de fallas de 2.9% a 1.9%.

Pero el reranker solo reordena lo que la búsqueda encontró. Si el documento correcto no está entre los candidatos, no te puede salvar, y por eso primero se mide la cobertura de la recuperación (recall).

Lo que hoy distingue a unos rerankers de otros es que siguen instrucciones: les puedes dar reglas de negocio como “prioriza el contenido reciente”. Cada proveedor dice ser el mejor, así que mide con tus propios datos.

Algunos complementos valen la pena. MMR elimina chunks redundantes. La compresión con LongLLMLingua da +21.4% de calidad con ~4× menos tokens. Y la posición en el prompt importa: pon lo más relevante al principio o al final (“Lost in the Middle”).

Parte V · Generación y guardrails

13. Generación con citas y guardrails

El prompt se ve así:

System:   Answer ONLY from the context. Cite every claim as [n].
          If the context does not contain the answer, say "I don't know".
Context:  [1] Remote Work Policy §3.2 Spain, p. 4: "Manager: 2 days/week..."
          [2] 2026 Annex, p. 1: "...starting January 2026, 3 days for..."
Question: remote work days for a manager in Spain

Los guardrails actúan antes, durante y después de la generación:

1. Antes, detectar intentos de manipular el modelo (“jailbreak” o prompt injection).
2. Durante, si el reranker no deja ningún chunk por encima del umbral, responder “No encontré esa información” en vez de inventar algo.
3. Después, verificar que cada oración de la respuesta esté respaldada por los chunks. Si la verificación falla, regenerar o responder con cautela.

Parte VI · Evaluación

14. Dos pruebas separadas

Si solo miras la respuesta final, no sabes qué arreglar. Microsoft llama process evaluation a la evaluación del paso de recuperación y system evaluation a la evaluación de la respuesta.

15. El golden dataset (la “clave de respuestas”)

El golden dataset es un conjunto de 100 a 300 preguntas, cada una con su respuesta correcta y los documentos que deberían aparecer:

{"query": "Remote work days, manager, Spain?",
 "ground_truth": "2 days per week; 3 from January 2026 according to the annex",
 "relevant_docs": [{"document_id": "teletrabajo_p4", "query_relevance_label": 4},
                   {"document_id": "anexo2026_p1",  "query_relevance_label": 3}]}

16. Métricas de recuperación, con números

Digamos que para una pregunta los documentos correctos son A y C, y el buscador devolvió [B, A, D, C, E].

Estos números te dicen dónde buscar. Si Recall@50 es bajo, el problema está en la recuperación (chunking, embeddings, falta de BM25), y el reranker no lo va a arreglar. Si Recall@50 es alto pero nDCG@5 es bajo, el problema está en el reranker.

17. Métricas de respuesta, con números

Supón que el sistema responde: “Tienes 2 días por semana [1], 3 a partir de enero de 2026 [2], y puedes elegir los viernes.”

Microsoft lo plantea igual: la fidelidad al contexto es el lado de la precisión (no agregar nada) y la completitud es el lado de la cobertura (no dejar fuera nada crítico).

Otra opción es la evaluación por “nuggets” (TREC 2024): defines los hechos atómicos que debe contener una buena respuesta y cuentas cuántos aparecen.

18. El LLM como juez

Nadie revisa 10,000 respuestas a mano, así que otro modelo hace de profesor. Ese juez tiene sesgos conocidos. Prefiere la primera opción que ve (posición), prefiere las respuestas largas (verbosidad) y prefiere el texto de su propia familia de modelos (autopreferencia).

Para montar un juez, apóyate en esto:

1. Una persona etiqueta 50–100 casos.
2. Mide el acuerdo entre juez y humano (kappa de Cohen, exactitud, F1).
3. El juez debe ser de una familia de modelos distinta a la del generador.
4. El juez debe explicar su puntaje.
5. Puntuar afirmación por afirmación (RAGChecker) o por nuggets es mejor que dar un solo puntaje global.

¿Cuánto puedes confiar en él? GPT-4 como juez alcanza más del 80% de acuerdo con humanos, el mismo nivel que entre dos humanos (Zheng et al., 2023). En TREC 2024, el acuerdo perfecto entre humanos y GPT-4o fue de 56%, y de 72% cuando el humano corregía la etiqueta del modelo. Así que el juez LLM es confiable para comparar sistemas y menos confiable pregunta por pregunta. ARES combina unos cientos de etiquetas humanas con el juez automático para producir intervalos de confianza estadísticamente válidos.

19. Evaluación antes del despliegue y en producción

Un quality gate en integración continua podría exigir que Recall@10 no baje más de 2 puntos, que faithfulness se mantenga ≥ 95% y que las respuestas “no sé” correctas se mantengan ≥ 90%. Esos umbrales son solo ejemplos; los reales los fija el negocio. En producción se muestrea un porcentaje del tráfico real y se evalúa sin respuesta de referencia (faithfulness, answer relevance, context relevance), junto con los votos de pulgar arriba/abajo, la latencia y el costo.

Microsoft recomienda un barrido de parámetros: probar combinaciones y medir cuál gana. Los números de abajo son ilustrativos, no resultados reales:

DeepEval sugiere no pasar de unas 5 métricas por aplicación. MLflow / Databricks recomiendan usar los mismos evaluadores en desarrollo y en producción. Y en producción solo puedes usar métricas que no necesiten una respuesta correcta.

20. Por qué importa: la alucinación en sistemas reales

Varias de estas cifras son de 2023–2024 y vienen de modelos más viejos, así que cítalas siempre con año y modelo.

Parte VII · Un ejemplo en producción sobre Azure

21. Copiloto de políticas internas, paso a paso

El caso es una empresa de 20,000 empleados, con documentos de recursos humanos, legal y compras en SharePoint y Blob Storage. Necesita permisos por usuario, citas en cada respuesta y un “no sé” cuando no hay información.

21.1 Arquitectura

Si conoces el stack LangChain + Chroma/Qdrant, las piezas se corresponden así:

21.2 Una pregunta, de punta a punta

Ana, gerente en Madrid, preguntó antes en el chat por su contrato. Ahora escribe “entonces, ¿cuántos días puedo teletrabajar?”

1. El modelo reescribe la pregunta usando el historial del chat: “días de teletrabajo permitidos para un gerente en España”.

2. BM25 y la búsqueda vectorial corren en paralelo y se fusionan con RRF (k=60). Antes de puntuar, el filtro de seguridad elimina lo que Ana no tiene permiso de ver.

3. El semantic ranker toma solo el top 50 y los puntúa de 0 a 4:

   Puntaje	Significado
   4	Responde por completo
   3	Relevante pero incompleto
   2	Parcial
   1	Relacionado, responde muy poco
   0	Irrelevante

   Los chunks con puntaje < 2 se descartan. Si no queda ninguno, la respuesta es “No encontré esa información”. Microsoft advierte que la distribución de puntajes puede variar un poco, así que los umbrales no deberían ser demasiado finos.

4. El modelo genera la respuesta con citas, usando la estructura de prompt de la sección 13.

5. Una verificación de fidelidad comprueba que cada oración esté respaldada por los chunks. Si falla, la respuesta se regenera o se da con cautela.

Una pregunta compleja (“compara el teletrabajo en España vs México y dime cuál aplica si me mudo”) va al agentic retrieval de Azure AI Search, que la divide en subconsultas, las ejecuta en paralelo, reordena cada una con el semantic ranker y combina los resultados. La planificación de consultas y la síntesis de respuestas basadas en LLM todavía están en preview.

Una pregunta global (“¿qué temas se repiten en todas las políticas de 2026?”) es donde GraphRAG vale la pena.

21.3 Evaluación en Azure (Microsoft Foundry)

Los puntajes usan una escala de 1 a 5 y aprueban con 3 por defecto. La evaluación continua corre sobre muestras de tráfico real (porcentaje configurable, hasta 1000 solicitudes por hora) y envía los resultados a Application Insights, vinculados a las trazas.

Parte VIII · Comparación: Azure vs Google Cloud vs código abierto

22. Azure vs Google Cloud vs código abierto

Algunos productos cambiaron de nombre hace poco (verificado el 2026-09-23):

• En Google, Vertex AI ahora aparece como Gemini Enterprise Agent Platform, Vertex AI Search se está renombrando a Agent Search y Vector Search 2.0 ahora se llama Agent Retrieval.
• En Microsoft, Azure AI Foundry ahora es Microsoft Foundry.

Fase 1: Preparar los documentos

Fase 2: Responder una pregunta

Fase 3: Generación y guardrails

Fase 4: Evaluación y monitoreo

Resumen en una imagen

Tres diferencias que importan

1. Búsqueda híbrida: Azure AI Search incluye la búsqueda por palabras clave. En Google Vector Search tienes que generar tú mismo el vector disperso; si quieres que Google lo administre, usa Agent Search. En código abierto depende de la base de datos.
2. Reranker: el de Azure reordena solo el top 50. La Ranking API de Google acepta hasta 1000 chunks y funciona con cualquier buscador, incluso uno externo. En código abierto controlas el modelo, el costo y la latencia, pero también te toca operarlo.
3. Evaluación: las dos nubes ya ofrecen evaluación offline y evaluación continua sobre tráfico real, con trazas estándar (OpenTelemetry). En código abierto, RAGAS o DeepEval (offline) más Phoenix, MLflow o Langfuse (producción) cubren lo mismo, pero la integración la haces tú.

Apéndice · Glosario

Apéndice · Referencias

Documentación oficial (consultada el 2026-09-23)

Microsoft Azure

• Semantic ranker: https://learn.microsoft.com/en-us/azure/search/semantic-search-overview
• RRF en la búsqueda híbrida: https://learn.microsoft.com/en-us/azure/search/hybrid-search-ranking
• Búsqueda agéntica: https://learn.microsoft.com/en-us/azure/search/agentic-retrieval-overview
• Document Layout skill: https://learn.microsoft.com/en-us/azure/search/cognitive-search-skill-document-intelligence-layout
• Chunking en Azure AI Search: https://learn.microsoft.com/en-us/azure/search/vector-search-how-to-chunk-documents
• Evaluadores de RAG: https://learn.microsoft.com/en-us/azure/foundry/concepts/evaluation-evaluators/rag-evaluators
• Evaluación continua: https://learn.microsoft.com/en-us/azure/ai-foundry/how-to/continuous-evaluation-agents

Google Cloud

• Ranking API: https://cloud.google.com/generative-ai-app-builder/docs/ranking
• Check Grounding: https://cloud.google.com/generative-ai-app-builder/docs/check-grounding
• Document AI Layout Parser: https://cloud.google.com/document-ai/docs/layout-parse-chunk
• RAG Engine: https://docs.cloud.google.com/gemini-enterprise-agent-platform/build/rag-engine/rag-overview
• Búsqueda híbrida en Vector Search: https://docs.cloud.google.com/gemini-enterprise-agent-platform/build/vector-search/about-hybrid-search
• Embeddings de texto: https://docs.cloud.google.com/gemini-enterprise-agent-platform/models/embeddings/get-text-embeddings
• Online Monitors: https://docs.cloud.google.com/gemini-enterprise-agent-platform/optimize/evaluation/evaluate-online

Elastic

• Búsqueda semántica: https://www.elastic.co/docs/solutions/search/semantic-search
• Búsqueda vectorial: https://www.elastic.co/docs/solutions/search/vector
• semantic_text: https://www.elastic.co/docs/reference/elasticsearch/mapping-reference/semantic-text
• ELSER: https://www.elastic.co/docs/explore-analyze/machine-learning/nlp/ml-nlp-elser
• Retrievers: https://www.elastic.co/docs/reference/elasticsearch/rest-apis/retrievers

Papers e informes

Recuperación

• Gao et al., RAG for LLMs: A Survey, 2023/24 — https://arxiv.org/abs/2312.10997
• Cormack, Clarke, Büttcher, Reciprocal Rank Fusion, SIGIR 2009 — https://dl.acm.org/doi/10.1145/1571941.1572114
• Formal et al., SPLADE, 2021 — https://arxiv.org/abs/2107.05720
• Chen et al., BGE-M3, 2024 — https://arxiv.org/abs/2402.03216
• Khattab & Zaharia, ColBERT, 2020 — https://arxiv.org/abs/2004.12832
• Faysse et al., ColPali, ICLR 2025 — https://arxiv.org/abs/2407.01449
• Gao et al., HyDE, 2022 — https://arxiv.org/abs/2212.10496
• Zheng et al., Step-Back Prompting, ICLR 2024 — https://arxiv.org/abs/2310.06117
• Sarthi et al., RAPTOR, 2024 — https://arxiv.org/abs/2401.18059
• Edge et al., GraphRAG, 2024 — https://arxiv.org/abs/2404.16130
• Microsoft Research, LazyGraphRAG, 2024 — https://www.microsoft.com/en-us/research/blog/lazygraphrag-setting-a-new-standard-for-quality-and-cost/
• Gutiérrez et al., HippoRAG 2, ICML 2025 — https://arxiv.org/abs/2502.14802
• Han et al., RAG vs. GraphRAG, 2025/26 — https://arxiv.org/abs/2502.11371
• Asai et al., Self-RAG, 2023 — https://arxiv.org/abs/2310.11511
• Yan et al., Corrective RAG, 2024 — https://arxiv.org/abs/2401.15884
• Jeong et al., Adaptive-RAG, NAACL 2024 — https://arxiv.org/abs/2403.14403
• Singh et al., Agentic RAG Survey, 2025/26 — https://arxiv.org/abs/2501.09136
• Jin et al., Search-R1, 2025 — https://arxiv.org/abs/2503.09516
• Liu et al., Lost in the Middle, TACL — https://arxiv.org/abs/2307.03172
• Li et al., Self-Route, EMNLP 2024 — https://arxiv.org/abs/2407.16833
• Li et al., LaRA, 2025 — https://arxiv.org/abs/2502.09977

Chunking

• Qu, Tu, Bao (Vectara), Is Semantic Chunking Worth the Computational Cost?, 2024 — https://arxiv.org/abs/2410.13070
• Smith & Troynikov (Chroma), Evaluating Chunking Strategies for Retrieval, 2024 — https://research.trychroma.com/evaluating-chunking
• NVIDIA, Finding the Best Chunking Strategy, 2025 — https://developer.nvidia.com/blog/finding-the-best-chunking-strategy-for-accurate-ai-responses/
• Jimeno Yepes et al., Financial Report Chunking, 2024 — https://arxiv.org/abs/2402.05131
• Günther et al. (Jina), Late Chunking, 2024 — https://arxiv.org/abs/2409.04701
• Anthropic, Contextual Retrieval, 2024 — https://www.anthropic.com/engineering/contextual-retrieval (cifras verificadas en una copia espejo; la página original bloqueó el acceso automatizado)
• Bhat et al., Rethinking Chunk Size, 2025 — https://arxiv.org/abs/2505.21700
• IBM, Docling, 2024 — https://arxiv.org/abs/2408.09869

Reranking

• Nogueira & Cho, monoBERT, 2019 — https://arxiv.org/abs/1901.04085
• Thakur et al., BEIR, 2021 — https://arxiv.org/abs/2104.08663
• Sun et al., RankGPT, 2023 — https://arxiv.org/abs/2304.09542
• Pradeep et al., RankZephyr, 2023 — https://arxiv.org/abs/2312.02724
• Su et al., BRIGHT, 2024 — https://arxiv.org/abs/2407.12883
• Abdallah et al., How Good are LLM-based Rerankers?, 2025 — https://arxiv.org/abs/2508.16757
• Agentset, Cohere Rerank 4, 2025 — https://agentset.ai/blog/cohere-reranker-v4
• Qwen, Qwen3 Embedding & Reranker, 2025 — https://qwenlm.github.io/blog/qwen3-embedding/
• Jina, jina-reranker-v3.5, 2026 — https://arxiv.org/abs/2607.18152
• Mixedbread, mxbai-rerank-v2, 2025 — https://www.mixedbread.com/blog/mxbai-rerank-v2
• Jiang et al., LongLLMLingua, ACL 2024 — https://arxiv.org/abs/2310.06839

Evaluación

• Es et al., RAGAS, 2023 — https://arxiv.org/abs/2309.15217
• Saad-Falcon et al., ARES, NAACL 2024 — https://arxiv.org/abs/2311.09476
• Ru et al. (Amazon), RAGChecker, NeurIPS 2024 — https://arxiv.org/abs/2408.08067
• Gao et al., ALCE, EMNLP 2023 — https://arxiv.org/abs/2305.14627
• Zheng et al., Judging LLM-as-a-Judge, NeurIPS 2023 — https://arxiv.org/abs/2306.05685
• Thakur et al., Support Evaluation TREC 2024, SIGIR 2025 — https://arxiv.org/abs/2504.15205
• Yang et al. (Meta), CRAG benchmark, NeurIPS 2024 — https://arxiv.org/abs/2406.04744
• Islam et al., FinanceBench, 2023 — https://arxiv.org/abs/2311.11944
• Magesh et al. (Stanford), Hallucination-Free?, 2024 — https://arxiv.org/abs/2405.20362
• Vectara, Hallucination Leaderboard — https://github.com/vectara/hallucination-leaderboard
• Bao et al., FaithBench, 2024 — https://arxiv.org/abs/2410.13210
• Vectara, Open RAG Eval — https://github.com/vectara/open-rag-eval
• DeepEval, Metrics — https://deepeval.com/docs/metrics-introduction
• Databricks, Scorers and LLM judges — https://docs.databricks.com/aws/en/mlflow3/genai/eval-monitor/concepts/scorers