La mayoría de las implementaciones de RAG funcionan mal. El modelo no es el problema: Claude o GPT-5 pueden responder a partir de los documentos recuperados. Lo que falla es la recuperación. El usuario formula una pregunta, el sistema devuelve fragmentos equivocados y el modelo produce una respuesta categórica basada en información incorrecta.
Este artículo ofrece una guía práctica sobre los tres elementos que corrigen una recuperación deficiente: estrategia de fragmentación, reranking y búsqueda híbrida. Si los implementas bien, desaparecerán la mayoría de las quejas del tipo «RAG no funciona para nuestro caso de uso».
Omitiremos las matemáticas avanzadas para centrarnos en las acciones concretas.
Por qué falla la recuperación
La canalización RAG predeterminada:
- Divide los documentos en fragmentos.
- Crea un embedding de cada fragmento.
- Cuando llega una pregunta, crea su embedding y busca los fragmentos más similares (mediante similitud del coseno).
- Envía esos fragmentos al LLM.
Cada paso tiene sus propios modos de fallo:
Una fragmentación deficiente produce fragmentos demasiado breves para resultar útiles, demasiado largos para ser coherentes o divididos en medio de una idea, de modo que ninguna de las partes se recupera bien.
Una similitud simple encuentra fragmentos que comparten vocabulario con la consulta, pero no son pertinentes. La pregunta «¿cómo cancelo mi suscripción?» podría recuperar cualquier fragmento que mencione «suscripción», incluido texto comercial sin relación.
La ausencia de reranking implica que el LLM recibe directamente los resultados de similitud. El fragmento más similar no siempre es el más pertinente.
La búsqueda exclusivamente semántica puede omitir coincidencias exactas importantes. Una consulta sobre el «código de error 503» podría pasar por alto un fragmento que contiene exactamente «código de error 503» porque el vector semántico de la consulta no coincide con el tema general del fragmento.
Las tres soluciones —mejor fragmentación, reranking y búsqueda híbrida— abordan estos problemas.
Solución 1: Mejor fragmentación
La fragmentación es la decisión individual con mayor impacto en la canalización RAG y la que muchas personas no consideran hasta que aparecen malos resultados.
La configuración predeterminada de la mayoría de las herramientas sin código divide el contenido según un número fijo de tokens (por ejemplo, 500 tokens con una superposición de 50). Puede funcionar razonablemente bien, pero falla con frecuencia.
Estrategias mejores:
Fragmentación semántica
Divide los documentos por límites semánticos —puntos en los que cambia el tema— en lugar de utilizar cantidades arbitrarias de tokens. La mayoría de los frameworks modernos (LangChain, LlamaIndex) incluyen fragmentadores semánticos que detectan estos cambios.
La ventaja es que los fragmentos contienen ideas completas. El modelo recibe contexto coherente en lugar de razonamientos partidos.
Fragmentación basada en la estructura
Si los documentos tienen una estructura natural —encabezados de Markdown, secciones HTML, capítulos de PDF o límites de funciones en el código—, utilízala. Divide por secciones, no por tokens.
Para Markdown:
- Cada sección H2 constituye un fragmento (con el contexto de H1 antepuesto).
- Las secciones H2 largas se subdividen y repiten el encabezado H2 como contexto.
Para código:
- Cada función o clase constituye un fragmento.
- El fragmento incluye la ruta del archivo y las importaciones.
Este método ofrece resultados muy superiores a una fragmentación ciega de tamaño fijo en contenidos estructurados.
Fragmentación jerárquica
Un patrón procedente de investigaciones recientes sobre RAG crea fragmentos en varios niveles:
- Fragmentos pequeños (200-500 tokens) para una recuperación precisa.
- Fragmentos medianos (1000-2000 tokens) para aportar contexto.
- Resúmenes de documentos (50-100 tokens) para coincidencias de alto nivel.
Durante la recuperación, busca en fragmentos pequeños, pero devuelve el fragmento mediano circundante. Así, el LLM recibe resultados pertinentes y suficiente contexto para interpretarlos.
Elegir el tamaño del fragmento
Una heurística aproximada por tipo de contenido:
| Tipo de contenido | Tamaño del fragmento | Motivo |
|---|---|---|
| Documentos técnicos / manuales | 500-1000 tokens | Conceptos autocontenidos, densidad moderada |
| Código | Una función/clase por fragmento | Unidades lógicas, no cortes arbitrarios |
| Artículos / libros largos | 1000-2000 tokens | Ideas que se desarrollan en varios párrafos |
| Tickets de soporte al cliente | Un ticket = un fragmento | No dividir el contenido de un ticket |
| Legal / contratos | Por sección, a menudo 500-1500 tokens | Unidades lógicas; preservar límites de cláusulas |
| Datos de hojas de cálculo | Fila + encabezados | Cada fila es un fragmento e incluye los encabezados de las columnas |
Si utilizas una herramienta sin código que oculta la fragmentación, formula 10 preguntas cuyas respuestas sepas que están en el corpus. Si el sistema no recupera con regularidad el fragmento adecuado, la fragmentación es el problema.
Un patrón eficaz: «página o sección y, después, preguntas»
Para la mayoría de los casos de uso personales de RAG, el patrón que funciona:
- Divide por secciones del documento (encabezado H2 de Markdown, capítulo de PDF, etc.).
- En los fragmentos de más de ~2000 tokens, subdivide por párrafos.
- Antepón a cada fragmento el título del documento y el encabezado de la sección.
- Añade una descripción breve de los tipos de preguntas que responde el fragmento (generada automáticamente por un LLM rápido durante la indexación).
La técnica de generar automáticamente «qué preguntas responde este fragmento» se utiliza poco, pero puede ser muy eficaz. Funciona porque las consultas suelen formularse como preguntas y compararlas con metadatos en forma de pregunta resulta más preciso que hacerlo directamente con el texto original.
Solución 2: Reranking
Después de la recuperación inicial —que normalmente devuelve 20-50 fragmentos según su similitud vectorial—, utiliza un reranker para reordenarlos por su pertinencia real respecto a la consulta.
El reranker es un modelo independiente —normalmente más pequeño y especializado— que recibe pares (consulta, fragmento) y devuelve una puntuación de pertinencia. Se aplica a los 20-50 resultados iniciales, que se ordenan según la nueva puntuación antes de enviar los 3-5 primeros al LLM.
La ventaja es una precisión considerablemente mayor. La similitud vectorial es rápida, pero menos precisa; los rerankers son más lentos, pero mucho más exactos. La combinación permite recuperar con rapidez y ordenar con precisión.
Opciones de reranking en 2026:
- Cohere Rerank: el reranker consolidado basado en una API. $2.00 por 1,000 búsquedas (precio de lista, verificado 2026-07-10).
- Voyage AI rerank-2: una opción comercial sólida que a menudo supera a Cohere en ámbitos especializados.
- bge-reranker-v2-m3: código abierto; se ejecuta localmente o en un alojamiento económico.
- Jina Reranker: otra opción sólida de código abierto.
En una canalización típica:
- La búsqueda vectorial devuelve los 50 fragmentos principales (es económica y rápida).
- El reranker puntúa los 50 frente a la consulta (es más caro y lento).
- Los 5 primeros según la puntuación de reranking se envían al LLM.
Latencia total añadida: ~200-500ms. Mejora de calidad: con frecuencia, 20-40% en pruebas comparativas de precisión de recuperación.
En herramientas sin código que no incluyen reranking de forma predeterminada —NotebookLM y la mayoría de las configuraciones básicas de n8n—, esta es la mejora con mayor impacto. n8n tiene un nodo Cohere Rerank; LangChain y LlamaIndex incluyen integraciones nativas con rerankers.
Solución 3: Búsqueda híbrida
La similitud vectorial encuentra coincidencias semánticas. La búsqueda por palabras clave (BM25 o similar) encuentra coincidencias exactas. Cada método detecta elementos que el otro omite.
Una consulta para “cómo solucionar errores HTTP 503 en nuestro gateway”:
- La búsqueda vectorial encuentra fragmentos sobre errores HTTP, problemas de gateway y diagnóstico.
- La búsqueda por palabras clave encuentra fragmentos que mencionan específicamente «503», donde podría estar la respuesta.
La búsqueda híbrida ejecuta ambos métodos y combina los resultados. Para ello utiliza Reciprocal Rank Fusion (RRF): a partir de las clasificaciones de cada método, RRF genera otra que tiene en cuenta ambas señales.
La implementación en la mayoría de herramientas es simple:
- Ejecutar la búsqueda vectorial → obtener la lista ordenada A.
- Ejecutar BM25 / búsqueda por palabras clave → obtener lista B ordenada.
- Para cada fragmento, calcular su puntuación RRF = 1/(k + rank_in_A) + 1/(k + rank_in_B) (con k normalmente igual a 60).
- Ordenar por la puntuación combinada y devolver los primeros resultados.
En 2026, la búsqueda híbrida está disponible de forma nativa en:
- Weaviate (almacén vectorial): búsqueda híbrida lista para usar.
- Qdrant — búsqueda híbrida mediante filtrado.
- Pinecone — búsqueda híbrida mediante vectores dispersos.
- Elastic / OpenSearch — combinación de palabras clave + vector.
- La mayoría de las plantillas RAG de n8n: la búsqueda híbrida es la opción predeterminada en las plantillas modernas.
La ventaja es una recuperación considerablemente mejor en consultas que contienen identificadores, códigos, nombres o jerga específicos. Para contenido técnico —código, códigos de error, nombres de productos o referencias normativas—, la búsqueda híbrida resulta prácticamente imprescindible.
Si tus consultas suelen incluir términos que deben coincidir exactamente —números, nombres, códigos o frases concretas—, activa la búsqueda híbrida. El coste es bajo y la mejora, importante.
Cómo combinarlo todo
La canalización RAG de vanguardia en 2026:
Query
↓
Query rewriter (optional — clean up the query, expand abbreviations)
↓
Hybrid retrieval: vector + keyword search
↓
Top 30-50 results
↓
Reranker
↓
Top 5 by reranker score
↓
LLM with retrieved chunks + query
↓
Cited answer
Cada paso es económico por separado. En conjunto, producen una calidad de recuperación muy distinta de «similitud vectorial → 5 primeros → LLM».
Un par de adiciones menos comunes pero poderosas:
Expansión de consulta. Reescribe la consulta del usuario en varias variaciones y busca cada una. Captura diferentes formulaciones.
Recuperación en varios pasos. Para preguntas complejas, realiza varias recuperaciones. La primera identifica subpreguntas; la segunda obtiene respuestas para cada una.
Recuperación conversacional. En una conversación de varios turnos, utiliza el historial para orientar la recuperación («antes preguntaron sobre X; en esta pregunta, prioriza el contenido relacionado con X»).
Filtrado por fuente. Usa filtros de metadatos para delimitar la recuperación. “Solo busca documentos etiquetados ‘regulaciones de la UE’ y fechados después de 2023.”
Estas funciones están cada vez más disponibles en herramientas RAG sin código, pero comprueba primero que los tres elementos básicos —buena fragmentación, reranker y búsqueda híbrida— funcionan correctamente.
Cómo medir la calidad de RAG
No puedes mejorar lo que no mides. Estas son algunas estrategias de evaluación prácticas:
La prueba de «preguntas de referencia». Elige 20 preguntas cuyas respuestas correctas conozcas. Ejecútalas en el RAG y evalúa si se recuperaron los fragmentos adecuados y si el modelo produjo la respuesta correcta. Repite la prueba cada mes.
Recall de recuperación en K. Para cada pregunta de referencia, identifica qué fragmentos contienen la respuesta. Después comprueba si el sistema devolvió alguno entre los K primeros (5, 10, 20) y mide la proporción.
Evaluación con un LLM como juez. En una versión más avanzada, un modelo potente (Claude Opus, GPT-5) puntúa si la respuesta es correcta, completa, está bien fundamentada y utiliza citas precisas. Ejecútala sobre un lote de preguntas representativas. Disponemos de un artículo completo sobre evaluaciones.
Calidad percibida por el usuario. En un RAG de equipo o producción, añade controles de «me gusta» y «no me gusta» a cada respuesta. Analiza los patrones de valoraciones negativas: suelen agruparse en tipos concretos de preguntas, que podrás corregir.
El mayor error es omitir por completo la medición. «Parece funcionar» no es una métrica. Sin datos no sabrás si las mejoras dan resultado.
Un ejemplo práctico: mejorar un RAG con problemas
Supón que has creado un RAG personal para la documentación interna de tu empresa. La calidad es mediocre: alrededor del 60% de las preguntas obtiene una respuesta útil. Aplica estas mejoras en orden:
Audita primero la recuperación. Examina los fragmentos recuperados en diez respuestas deficientes. Si el fragmento correcto aparece, el problema está en el modelo o el prompt; si no, está en la recuperación.
Si el problema es la recuperación:
-
Revisa la fragmentación. ¿Los fragmentos son coherentes? ¿El fragmentador divide ideas importantes? Cambia a una fragmentación semántica o basada en la estructura.
-
Añade un reranker. Si utilizas una búsqueda vectorial básica y los 5 primeros resultados, añade Cohere Rerank o bge-reranker-v2-m3 entre la recuperación y el LLM. La mejora suele ser visible de inmediato; mídela con tu propio conjunto de evaluación en lugar de confiar en porcentajes universales.
-
Añade búsqueda híbrida. Especialmente si tus consultas contienen términos específicos (nombres de productos, códigos de error, jerga).
-
Revisa la indexación. ¿Los fragmentos incluyen metadatos (tipo de documento, sección y fecha)? Utiliza filtros de metadatos durante la recuperación.
Si el problema es el modelo (se recuperaron los fragmentos correctos, pero la respuesta es incorrecta):
-
Ajusta el prompt. Indica expresamente al modelo: «responde únicamente a partir del contexto proporcionado. Si el contexto no cubre la pregunta, dilo».
-
Añade citas. Exige que el modelo cite el fragmento concreto utilizado. Esto facilita la depuración y reduce las alucinaciones.
-
Usa un modelo más fuerte. Si usas un modelo pequeño y rápido, prueba con Claude Sonnet 4.5 o GPT-5.
Después de dos o tres rondas de este proceso de investigación y corrección, la mayoría de las implementaciones de RAG alcanza una tasa de respuestas útiles del 85-90%, el umbral a partir del cual los usuarios suelen adoptar el sistema y confiar en él.
Errores comunes
Estos son algunos errores recurrentes:
Indexar el contenido equivocado. Páginas comerciales, documentos obsoletos y artículos de baja calidad. El modelo no puede distinguirlos: trata todo lo incluido en el índice como fuente canónica. Selecciona el contenido con rigor.
Olvidar actualizar el índice cuando cambian los documentos. Un RAG con contenido obsoleto ofrece respuestas categóricas pero incorrectas. Vuelve a indexar con regularidad o utiliza un sistema con sincronización automática.
Ignorar la evaluación. La mayoría de los RAG se despliega sin medición y nunca mejora. La fase de «parece funcionar» se prolonga indefinidamente. Incorpora la evaluación desde el primer día.
Tratar la recuperación como una caja negra. «No funciona» no es un diagnóstico. Inspecciona los resultados recuperados. El problema suele resultar evidente cuando puedes verlos.
Diseñar una solución excesivamente compleja desde el principio. No necesitas empezar con la canalización más avanzada. Empieza con NotebookLM o una búsqueda vectorial básica y añade complejidad solo cuando identifiques un cuello de botella concreto.
Cuando esto importa
Las tres soluciones —mejor fragmentación, reranking y búsqueda híbrida— importan más cuando:
- El corpus es técnico, con terminología específica.
- Las consultas contienen requisitos de coincidencia exacta (códigos, nombres, IDs).
- Los usuarios necesitan precisión (ámbito jurídico, cumplimiento normativo o soporte al cliente).
- El sistema se usa a gran escala (un pequeño aumento de calidad importa mucho cuando se aplica 10,000 veces al día).
Importan menos cuando:
- El corpus es pequeño (menos de 100 documentos) y bien organizado.
- Las consultas son abiertas («¿cuál es nuestra postura sobre X?»).
- Los usuarios toleran cierta imprecisión y pueden iterar hasta encontrar la respuesta.
- El caso de uso es exploratorio en lugar de preciso.
Para la mayoría de los RAG personales y de equipos pequeños, pasar de una similitud vectorial básica a vector + reranker es la mejora con mayor impacto. La búsqueda híbrida es el siguiente paso. La fragmentación importa a cualquier escala.
Idea principal
Un RAG deficiente casi siempre se debe a una recuperación deficiente, que suele reducirse a tres elementos: fragmentación, reranking y método de búsqueda. Corrígelos y desaparecerán la mayoría de los problemas de calidad.
No necesitas especializarte en motores de búsqueda para aplicar estas técnicas. Herramientas como Weaviate, Pinecone y Qdrant, las plantillas de n8n y las integraciones de LangChain las han hecho accesibles. El principal obstáculo consiste ahora en conocerlas y aplicarlas de forma deliberada.
Si tu RAG no funciona, no culpes al modelo. Examina los fragmentos recuperados, corrige la recuperación y vuelve a evaluar.
