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_chunkeren 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.*