Búsqueda híbrida RAG: BM25, vectores y reranking sin complicar tu stack

La búsqueda vectorial pura falla justo en consultas con IDs, nombres propios y términos raros. La búsqueda híbrida RAG combina BM25, embeddings y reranking para recuperar mejor evidencia antes de llamar al modelo.

Búsqueda híbrida RAG significa ejecutar recuperación léxica, normalmente BM25 o full-text search, junto a recuperación semántica por embeddings, fusionar rankings y pasar al LLM un contexto ordenado con evidencias citables.

BM25 y full-text search hacen lo contrario: premian coincidencias léxicas, frecuencia de términos y rareza de palabras. La búsqueda híbrida combina ambas señales para que el sistema no tenga que elegir entre significado y precisión.

Código: RRF simple para unir BM25 y vectores

<div style="margin:28px 0;border:1px solid #dbe3ef;border-radius:12px;overflow:hidden;background:#0f172a;"> <div style="padding:10px 14px;background:#111827;color:#cbd5e1;font:13px Consolas,monospace;">rrf.py</div> <pre style="margin:0;padding:18px;overflow:auto;color:#e5e7eb;font:13px/1.55 Consolas,monospace;"><code>from collections import defaultdict def reciprocal_rank_fusion(result_lists, k=60): scores = defaultdict(float) docs = {} for results in result_lists: for rank, item in enumerate(results, start=1): doc_id = item["id"] docs[doc_id] = item scores[doc_id] += 1.0 / (k + rank) ranked_ids = sorted(scores, key=scores.get, reverse=True) return [{**docs[doc_id], "rrf_score": scores[doc_id]} for doc_id in ranked_ids] query = "ERR_CONN_RESET al refrescar token OAuth" bm25_hits = bm25_search(query, limit=50) vector_hits = vector_search(embed(query), limit=50) candidates = reciprocal_rank_fusion([bm25_hits, vector_hits]) context = rerank(query, candidates[:80])[:12] answer = generate_with_citations(query, context)</code></pre> </div>

Implementación con PostgreSQL y pgvector

PostgreSQL es una opción muy razonable cuando tu corpus vive cerca de datos transaccionales, permisos por tenant o joins que no quieres duplicar en otro sistema. `tsvector` y `tsquery` cubren full-text search; pgvector añade almacenamiento y búsqueda de embeddings. Para muchos productos internos, esa combinación reduce sincronización y fugas entre sistemas.

El diseño típico guarda `content`, `metadata`, `tenant_id`, `tsv` y `embedding` en la misma tabla. La query aplica primero filtros obligatorios, ejecuta full-text y vector search por separado, calcula posiciones y fusiona con RRF en SQL o en aplicación. Lo importante es que los permisos no sean un filtro posterior decorativo: deben aplicarse antes de recuperar candidatos.

Postgres no siempre será el buscador más rápido para corpus enormes o requisitos avanzados de relevancia. Pero como baseline operable es fuerte: transacciones, backups, permisos, SQL, joins y menos piezas móviles. Si el equipo no puede operar dos índices con disciplina, una arquitectura más simple puede ganar aunque no sea la más glamourosa.

El reranking solo compensa si el candidato correcto está en el pool. Si context recall es bajo, no arregles con un reranker caro. Arregla chunking, filtros, normalización de query, sinónimos, indexación de campos o combinación sparse/dense.

Evaluación: no publiques híbrida sin comparar contra baseline

Antes de activar búsqueda híbrida, congela un dataset pequeño: preguntas reales, documentos esperados cuando existan, categoría de query y riesgo. Ejecuta vector-only, BM25-only e híbrida con el mismo corpus. Mide recall@k, MRR, nDCG si tienes qrels, groundedness de respuesta y coste por consulta.

La mejora que busco no es solo más score agregado. Quiero ver casos concretos: errores exactos que BM25 rescata, preguntas conceptuales que el vector mantiene, documentos irrelevantes que el reranker expulsa y respuestas que citan mejor evidencia.

No cambies embeddings, chunking, prompt, reranker y fusión en el mismo experimento. Si lo haces, no sabrás qué ayudó. La búsqueda híbrida es un cambio suficientemente grande como para merecer baseline propio.

Errores comunes que veo en RAG híbrido

• Fusionar scores BM25 y vectoriales como si estuvieran en la misma escala.
• Aplicar filtros de permisos después de recuperar, cuando el ranking ya fue contaminado.
• Usar `top_k` pequeño y culpar al reranker de no encontrar documentos que nunca recibió.
• Indexar chunks sin títulos, rutas, fechas, producto, versión o metadatos útiles para desempatar.
• No separar consultas exactas, conceptuales, negativas y multi-hop en la evaluación.
• Medir solo la respuesta final y no guardar los candidatos que llegaron al prompt.
• Añadir híbrida para tapar un problema de chunking obvio.

Plan de adopción en una semana

• Día 1: etiqueta 40-60 preguntas reales y separa consultas con IDs, errores, nombres propios, conceptos generales, permisos y preguntas sin respuesta.
• Día 2: ejecuta tu pipeline vector-only y guarda candidatos, respuesta, citas, latencia y coste.
• Día 3: añade recuperación BM25 o full-text con los mismos filtros de permisos.
• Día 4: fusiona con RRF y compara candidate pools antes de tocar prompts.
• Día 5: añade reranking solo sobre candidatos fusionados y mide si mejora precisión sin romper latencia.
• Día 6: ajusta top_k por tipo de consulta y crea un gate mínimo de regression retrieval.
• Día 7: despliega para un porcentaje pequeño de tráfico y revisa ejemplos, no solo promedios.

Conclusión

La búsqueda híbrida RAG no es una capa elegante para presumir de arquitectura. Es una corrección práctica a un defecto real de vector-only: confundir parecido semántico con evidencia suficiente.

Mi recomendación es empezar por el pipeline más aburrido que puedas operar: filtros duros, BM25, vectores, RRF, reranking opcional, citas y evaluación. Si eso mejora recall y groundedness en preguntas reales, ya tendrás permiso técnico para invertir en motores más sofisticados. Si no lo mide, es solo otro índice caro.