Entre 2023 y 2024, la narrativa RAG decía que embeddings y una vector DB eran suficientes. Entre 2024 y 2025, los equipos descubrieron que no bastaba. En 2026, tras el polvo asentado, el patrón que sobrevive en sistemas serios es el híbrido: búsqueda densa + búsqueda léxica + reranking, con chunking bien pensado y evaluación continua. Ya lo documenté con detalle en el caso de RAG con Postgres y pgvector en producción: la lección se repite en cada stack que reviso.

Puntos clave

  • La búsqueda solo densa falla en términos técnicos exactos; la solo léxica falla en consultas semánticas. La combinación con RRF gana.

  • Stacks maduros: Qdrant, Weaviate, Elasticsearch con vectores, pgvector+FTS o Vespa para escala grande.

  • Un reranker cross-encoder reordena los top-50 y mejora la precisión en top-5, y solo puntúa los candidatos que ya devolvió la búsqueda inicial, no el corpus entero.

  • Chunks de 500 tokens con overlap son el default «aceptable»; los sistemas maduros van a chunking semántico con metadatos enriquecidos.

  • RAG sin evaluación automatizada es fe: Ragas y TruLens miden recall@k, precisión y ausencia de alucinación.

Búsqueda híbrida densa + BM25

La búsqueda puramente densa (embeddings) falla en consultas con:

  • Términos técnicos exactos.

  • Nombres propios.

  • Identificadores o códigos.

BM25 (léxico) falla en:

  • Consultas semánticas.

  • Vocabulario distinto al del corpus.

La combinación gana. La fusión habitual es Reciprocal Rank Fusion (RRF), que mezcla los dos rankings sin hiperparámetros críticos.

Stacks típicos 2026 con soporte híbrido nativo:

Reranking con cross-encoder

La búsqueda inicial devuelve 50–100 candidatos. Un reranker con cross-encoder (Cohere Rerank, BGE Reranker, Voyage Rerank) reordena los top-N antes de pasar al LLM. El cross-encoder:

  • Es más caro por documento que el bi-encoder.

  • Pero procesa solo los top-50, no el corpus entero.

  • La precisión en el top-5 mejora.

Chunking consciente de estructura

Chunks de 500 tokens con 50 de overlap son el default que funciona «de forma aceptable». Los sistemas maduros van más allá:

  • Chunking semántico que respeta límites de sección.

  • Chunks de tamaño variable según el tipo de documento.

  • Metadatos enriquecidos: fuente, fecha, sección padre, tipo de contenido.

Los metadatos se usan después para filtrado antes de la fusión, reduciendo el ruido en los candidatos.

Evaluación continua del pipeline

RAG sin evaluación es fe. Las métricas que importan:

  • Recall@k: ¿recuperamos los chunks relevantes?

  • Precisión en las respuestas generadas.

  • Ausencia de alucinación medida contra ground truth.

Herramientas como Ragas[6] y TruLens[7] automatizan la medición. La evaluación debe correr en CI, no solo manualmente. Cuando la métrica de precisión requiere juicio (¿la respuesta generada es realmente correcta?), conviene apoyarse en un LLM juez con la disciplina que describo en LLM-as-judge: evaluación madura. Sin ground truth de referencia, el juez automatizado también se equivoca.

Antipatrones a evitar

Tres antipatrones recurrentes:

  • Tune de hiperparámetros sin evaluación: cambiar top-K a ojo sin medir impacto no es ingeniería.

  • Corpus sin refresh: el conocimiento evoluciona, el índice no, y las respuestas envejecen silenciosamente.

  • Dependencia excesiva del reranker para compensar chunking pobre: si los chunks son malos, ni el mejor reranker rescata el resultado.

Conclusión

RAG en 2026 es una arquitectura madura con decisiones bien estudiadas. La receta ganadora: híbrido denso+léxico con RRF, reranking con cross-encoder sobre los top-50, chunking consciente de estructura, evaluación automatizada en CI. Equipos que siguen esta receta obtienen precisión alta con coste razonable; equipos que «solo usan embeddings» siguen peleando con resultados irregulares.

Versión en inglés: Hybrid RAG in 2026: the patterns that keep winning.

Fuentes:

  1. Qdrant: documentación de Hybrid Queries[8]
  2. Weaviate: documentación de búsqueda híbrida[9]
  3. pgvector: README en GitHub[4]
  4. Ragas: documentación del framework de evaluación[6]
  5. TruLens: documentación de evaluación de LLM[7]

Preguntas frecuentes

¿Por qué no basta con embeddings y una vector DB para un RAG serio?

Porque la búsqueda puramente densa falla en términos técnicos exactos, nombres propios e identificadores o códigos, mientras que la léxica con BM25 falla en consultas semánticas y en vocabulario distinto al del corpus. La combinación de ambas gana, fusionando los dos rankings con Reciprocal Rank Fusion (RRF), que no depende de hiperparámetros críticos. Qdrant, Weaviate, Elasticsearch con vectores, pgvector con FTS y Vespa ofrecen soporte híbrido nativo.

¿Cuánto cuesta añadir un reranker con cross-encoder al pipeline?

Menos de lo que parece: el cross-encoder es más caro por documento que el bi-encoder, pero solo procesa los 50-100 candidatos que devuelve la búsqueda inicial, no el corpus entero. Además, mejora la precisión en el top-5 antes de pasar los resultados al LLM. Opciones habituales son Cohere Rerank, BGE Reranker y Voyage Rerank. Eso sí, si los chunks son malos ni el mejor reranker rescata el resultado.

¿Cómo mido si mi RAG funciona de verdad?

Con métricas automatizadas: recall@k para saber si recuperas los chunks relevantes, precisión de las respuestas generadas y ausencia de alucinación medida contra ground truth. Herramientas como Ragas y TruLens automatizan la medición, y la evaluación debe correr en CI, no solo a mano. Cambiar top-K a ojo sin medir el impacto no es ingeniería, y un corpus sin refresh hace que las respuestas envejezcan silenciosamente.

Fuentes

  1. Qdrant
  2. Weaviate
  3. Elasticsearch
  4. pgvector
  5. Vespa
  6. Ragas
  7. TruLens
  8. Qdrant: documentación de Hybrid Queries
  9. Weaviate: documentación de búsqueda híbrida