En RAG (Retrieval-Augmented Generation) la mayoría del esfuerzo de debug en 2026 se centra en los prompts del modelo y las system instructions. El cliente cambia el prompt 12 veces, dedica 4 días y la precisión de las respuestas pasa del 67 % al 70 %. Mientras tanto, tres ajustes en la capa de retrieval — chunking, embedding model, reranking — moverían la precisión al 84 % con medio día de trabajo. Este artículo va de esos tres ajustes.
Por qué decide retrieval, no el LLM
Asimetría básica de la arquitectura RAG: si retrieval devuelve **los trozos correctos de documentación**, incluso un modelo 7B medio dará respuesta de calidad. Si retrieval devuelve trozos irrelevantes o incompletos, ni Claude Opus 4.6 salva la respuesta — el modelo simplemente no tiene los hechos verdaderos en el contexto. «Garbage in, garbage out» es en RAG literalmente una ley física.
Ejemplo concreto: RAG jurídico sobre legislación eslovaca, 12 000 documentos, 8 M tokens. Con chunking por defecto (500 tokens fixed-size) y OpenAI text-embedding-ada-002 logramos precision@5 = 0,61, recall@10 = 0,72. Tras tres ajustes (document-aware chunking, upgrade de embedding a BGE-M3, Cohere Rerank 3) — precision@5 = 0,84, recall@10 = 0,93. **Sin cambio de LLM, sin cambio de prompt.**
Ajuste 1: chunk size + chunking strategy
Configuración más frecuente en proyectos PoC: `RecursiveCharacterTextSplitter(chunk_size=500, chunk_overlap=50)` por defecto de LangChain. Funciona en el 60 % de los casos de uso. Para el resto está mal.
**Dos dimensiones de decisión:**
A) Tamaño del chunk (tokens)
- **128–256 tokens** — alta precisión, retrieval encuentra exactamente el párrafo que responde. Riesgo: falta el contexto alrededor del párrafo, el modelo no ve el hilo argumental. Adecuado para FAQ, snippets de código, datos estructurados.
- **256–512 tokens** — el compromiso más común. Párrafo con contexto adyacente. Default para la mayoría de despliegues de knowledge base B2B.
- **512–1024 tokens** — contexto más amplio, el modelo recibe más conexiones, pero la precisión del retrieval cae (el embedding de un chunk de 1 024 tokens «diluye» el tema principal). Adecuado para documentos narrativos largos (resoluciones jurídicas, papers de investigación, manuales técnicos).
- **> 1024 tokens** — pocas veces correcto. Los modelos de embedding tienen una longitud efectiva real ~512 tokens — la mayoría de la información por encima de ese umbral se «disuelve» en un único vector. Excepción: long-context embedding models (Voyage-3-large, BGE-M3 en modo completo, NV-Embed-v2) manejan efectivamente hasta 8 192 tokens.
B) Estrategia de división (fixed vs. semantic vs. document-aware)
- **Fixed-size chunking** — sencillo, determinista, pero rompe párrafos, frases, incluso palabras en la frontera. Pérdida de contexto en ~15 % de los chunks, que se traduce en un 8–12 % de empeoramiento de precision@5.
- **Semantic chunking** — con embeddings detecta fronteras de segmentos con sentido (p. ej. `semantic_chunker` en LlamaIndex). Conserva mejor el contexto pero los chunks tienen tamaño variable — en inference hay que asumir rango 200–800 tokens. Mejora de precision@5 5–8 %.
- **Document-aware chunking** — aprovecha la estructura del documento (markdown headings, HTML `<section>`, PDF sections via Docling o Unstructured.io). Los chunks corresponden a las unidades lógicas del autor. **Mejor opción para el 80 % de casos B2B**, mejora de precision@5 12–18 % sobre fixed-size.
Configuración práctica para RAG jurídico: PDF parseado por Docling → split por `<heading>` en orden secuencial → si la heading section > 800 tokens, sub-split por párrafos (`\n\n`) → metadata por chunk: `{doc_id, section, page, jurisdiction, paragraph_number}`. 10–20 % de overlap entre chunks vecinos para continuidad.
**Benchmark concreto:** 12 000 documentos jurídicos, fixed 500-token vs document-aware chunking. - Fixed: 38 400 chunks, avg 487 tokens, precision@5 = 0,61 - Document-aware: 24 200 chunks, avg 612 tokens, precision@5 = 0,73
Ajuste 2: embedding model
La decisión más subestimada. El cliente elige OpenAI `text-embedding-ada-002` de 2022 porque «está en el LangChain quickstart», y pierde un 15–20 % de precisión que ganaría con un modelo más moderno.
Top opciones en 2026 — tradeoff coste/calidad/latencia
**OpenAI text-embedding-3-large** - Dimensión: 3 072 (reducible vía Matryoshka representation a 256/512/1 024) - MTEB score: ~64,6 - Precio: 0,13 USD / M tokens - Multilingual: bueno, pero no el mejor para SK/CZ — en pruebas con textos jurídicos eslovacos precision@5 = 0,77 - Latencia: ~80 ms por request (API) - **Cuándo:** setup all-in cloud, mezcla idiomática inglés + UE común
**Cohere embed-multilingual-v3.0** - Dimensión: 1 024 - MTEB score: ~63,8 (el benchmark multilingual sube) - Precio: 0,10 USD / M tokens - Multilingual: excelente para 100+ idiomas, especialmente fuerte para lenguas centroeuropeas (SK, CZ, HU, RO) - Latencia: ~60 ms por request - **Cuándo:** knowledge base multilingual, EU compliance (Cohere tiene endpoint EU region)
**sentence-transformers/all-mpnet-base-v2** - Dimensión: 768 - MTEB score: ~57,8 - Precio: self-hosted (CPU/GPU) - Multilingual: débil (primariamente EN) - Latencia: ~10 ms en CPU, ~3 ms en GPU - **Cuándo:** setup budget, EN-only, off-line
**BGE-M3 (BAAI/bge-m3)** - Dimensión: 1 024 (dense), más sparse + multivector colBERT-style - MTEB score: ~66,1 (multilingual benchmark) - Precio: self-hosted - Multilingual: excelente para 100+ idiomas incluyendo SK - Latencia: ~15 ms en RTX 4090 - **Cuándo:** opción SOTA para multilingual + self-hosted. **Nuestro default en 2026 para clientes UE.**
**Voyage AI voyage-3-large** - Dimensión: 1 024 - MTEB score: ~68,2 (uno de los más altos en 2026) - Precio: 0,18 USD / M tokens - Multilingual: excelente - **Cuándo:** premium cloud donde cada 1 % de precisión cuenta
**Benchmark concreto:** mismo corpus jurídico (8 M tokens), document-aware chunking, sin reranker. - OpenAI text-embedding-3-large: precision@5 = 0,77, latencia 80 ms - Cohere embed-multilingual-v3: precision@5 = 0,79, latencia 60 ms - BGE-M3 (self-hosted): precision@5 = 0,81, latencia 15 ms - Voyage-3-large: precision@5 = 0,82, latencia 95 ms
Para contenido jurídico eslovaco la diferencia entre `text-embedding-ada-002` (0,61) y BGE-M3 (0,81) son **20 puntos porcentuales de precisión** — el cambio más sencillo con mayor impacto.
Ajuste 3: reranker
El componente más subestimado de la pipeline. Arquitectura: el retrieval devuelve top-K candidatos (típicamente K = 20–50) por embedding similarity, **el reranker** los puntúa de nuevo con un modelo cross-encoder (más lento pero más preciso) y elige top-N (típicamente N = 5) para el contexto del LLM.
Por qué funciona: el bi-encoder embedding (retrieval rápido) es «lossy» — comprime el documento en un vector. El cross-encoder reranker (más lento) ve documento + query juntos y evalúa relevancia token a token. Reranking sobre top-20 añade 50–200 ms de latencia, pero precision@5 sube típicamente 12–18 %.
Top opciones en 2026
**Cohere Rerank 3** - Precio: 2,00 USD / 1 000 search units (1 unit = 1 query + hasta 100 documents) - Multilingual: excelente - Latencia: ~100–150 ms por query (top-20 rerank) - API: sencilla, endpoint UE disponible - **Cuándo:** setup cloud, contenido multilingual, calidad premium
**BAAI/bge-reranker-v2-m3 (BGE Reranker v2 M3)** - Precio: self-hosted - Multilingual: excelente (mismo training que BGE-M3) - Latencia: ~80–120 ms en RTX 4090 para top-20 - **Cuándo:** setup self-hosted, opción open-source SOTA para multilingual
**cross-encoder/ms-marco-MiniLM-L-6-v2** - Precio: self-hosted, modelo pequeño (66 M parameters) - Multilingual: débil (EN-trained) - Latencia: ~30 ms en GPU - **Cuándo:** setup budget, EN-only
**Ningún reranker (baseline)** - Precio: cero - **Cuándo:** PoC, volumen bajo, latencia bajo 200 ms es requisito
Benchmark concreto — añadir reranker a pipeline existente
RAG jurídico, retrieval BGE-M3, top-20 → top-5: - Sin reranker: precision@5 = 0,81, latencia 250 ms - Cohere Rerank 3: precision@5 = 0,88, latencia 380 ms - BGE-Reranker-v2-m3 (self-hosted): precision@5 = 0,89, latencia 340 ms
**El reranker sube la precisión 7–8 % al coste de 130–150 ms.** Para knowledge base regulada (derecho, medicina, finanzas) siempre se paga. Para un chatbot de bajo riesgo (FAQ) el reranker puede ser innecesario — depende del coste de una respuesta errónea.
Retrieval híbrido — cuando importan keywords y semántica
Para contenido donde **las palabras clave pesan por sí mismas** (números de leyes, párrafos, GUIDs, números de norma, nombres exactos de producto), el retrieval dense embedding predominante puede fallar. El embedding capta similitud semántica, pero un match literal a «§ 271 ods. 2» puede perderse en la norma semántica.
**Solución: retrieval híbrido** = paralelo BM25 (sparse, keyword-based) + dense embedding retrieval, los resultados se funden (típicamente `reciprocal_rank_fusion`).
Stack en 2026: Qdrant 1.10+ con sparse vectors + dense vectors nativos, u OpenSearch con pgvector layer, o Weaviate hybrid search API. Configuración: parámetro alpha decide el peso (0 = BM25 puro, 1 = dense puro, default 0,5).
**Benchmark de retrieval híbrido en corpus jurídico:** - BM25 only: precision@5 = 0,68 (excelente para «§ 271», débil para «qué aplica al despido por motivos de salud») - Dense (BGE-M3) only: precision@5 = 0,81 - Hybrid (alpha=0.5): precision@5 = 0,87
Para contenido jurídico / médico / técnico-normativo el híbrido es significativamente mejor. Para contenido FAQ conversacional la diferencia se reduce a 1–2 %.
Marco de decisión práctico
1. **¿Qué tipo de contenido?** FAQ conversacional / blogposts → basta dense embedding. Documento estructurado con secciones / párrafos → document-aware chunking obligatorio. 2. **¿Qué idioma?** EN-only → top performer MTEB (Voyage, BGE-M3, OpenAI). Multilingual UE → BGE-M3, Cohere multilingual-v3. 3. **¿Qué presupuesto?** Cloud-only → OpenAI 3-large + Cohere Rerank 3. Self-hosted → BGE-M3 + BGE-Reranker-v2-m3. 4. **¿Qué latencia tolera?** < 200 ms → sin reranker o cross-encoder pequeño. 200–500 ms → pipeline completa con reranker. 5. **¿Las keywords son críticas?** Sí → BM25 + dense híbrido. No → dense puro. 6. **¿Qué volumen de queries?** Con > 100 RPS el stack self-hosted se amortiza en 4–8 meses.
Iteración práctica
El tuning RAG no es proyecto «config y olvido». Stack de iteración que nos ha servido:
1. **Eval set:** 200+ queries realistas + documentos fuente «ideales» anotados manualmente. Sin esto no se mide la mejora. 2. **Baseline:** primero pipeline sencilla (fixed chunking + un embedding + sin reranker). Score = baseline. 3. **Cambie un parámetro cada vez:** chunking → embedding → reranker → hybrid. Tras cada cambio mida precision@5, recall@10, latencia. 4. **Pare cuando marginal cost > marginal benefit.** Típicamente precision@5 por encima de 0,90 requiere esfuerzo desproporcionado — fine-tuned embedding o custom reranker que no compensa en use-cases con calidad tolerante.
En el RAG jurídico para 12 000 documentos pasamos en 4 semanas de trabajo de precision@5 67 % al 88 %. Las siguientes 4 semanas probablemente lo habrían llevado al 90 %. El cliente decidió parar — 88 % era operativamente suficiente y otras 5 semanas de GPU + engineer time no se devolvían.
---
*Hacemos arquitectura RAG + tuning para knowledge base B2B con 1 k–10 M documentos. Si tiene pipeline existente y precision@5 se ha estancado bajo 75 %, en 90 minutos de auditoría revisamos los tres ajustes concretos para su contenido y le damos un baseline numérico para la roadmap de tuning.*