Más allá de Top-K: umbrales de relevancia, búsqueda híbrida y reclasificación en RAG
Descubra por qué una base de datos vectorial junto con un LLM no constituye un sistema RAG listo para producción, y cómo el fragmentado, los umbrales de similitud, la búsqueda híbrida, el reclasificado y la evaluación cierran esa brecha.
La generación mejorada por recuperación de información suele presentarse como un proceso en tres pasos: encontrar documentos relacionados con la pregunta, entregárselos a un modelo de lenguaje y dejar que este escriba la respuesta. El diagrama es sencillo; hacer que sea fiable, no lo es. Un pipeline que conecte directamente una búsqueda de embeddings con un LLM dará respuestas confiadas incluso con poco contexto, omitirá identificadores exactos y fingirá saber algo cuando la base de conocimientos no tiene información al respecto. Aquí es donde falla ese diseño ingenuo y qué etapas, desde el particionamiento consciente de la estructura hasta la evaluación medible, lo convierten en una arquitectura de recuperación en la que se puede confiar.
El pipeline ingenuo y sus suposiciones ocultas
La base de la mayoría de los tutoriales es la siguiente: dividir los documentos en fragmentos, incrustarlos, almacenar los vectores y, al momento de realizar una consulta, incrustar la pregunta, obtener los top_k fragmentos más cercanos y pegarlos en el prompt. Funciona en una demostración, pero asume silenciosamente que cada fragmento es una unidad significativa y que “más cercano” significa “relevante”.
Fragmentación según la estructura del documento
Considere un manual para empleados. El enfoque deficiente lo divide en trozos arbitrarios de 1,000 caracteres, lo que provoca que una política se divida por la mitad y que el final de un tema se une al inicio de otro. El enfoque más sólido sigue el esquema propio del documento, generando fragmentos como Trabajo remoto, Seguridad, Vacaciones pagadas y Gastos.
Una sección autónoma proporciona al modelo de incrustación suficiente contexto para comprender de qué trata realmente el texto y cómo se relacionan sus afirmaciones. Los vectores resultantes son más limpios, y la búsqueda semántica devuelve resultados más relevantes.
Top-K muestra los resultados más cercanos, no los relevantes
Los fragmentos mejor estructurados conducen directamente al siguiente concepto erróneo. Establecer top_k = 5 a menudo se interpreta como “dame los cinco resultados relevantes”. En realidad, lo que se solicita son los cinco resultados más cercanos, independientemente de si alguno de ellos es bueno o no. Una distribución típica de puntuaciones para una pregunta sobre trabajo remoto podría ser:
Remote Work 0.62
Paid Time Off 0.36
Security 0.30
Expenses 0.28
Other Policy 0.24
El primer resultado es probablemente lo que necesita el usuario. Los otros cuatro son coincidencias débiles que solo aparecen en la lista porque había que llenar los espacios disponibles. Al pasarlos todos a el modelo, se mezcla información útil con texto posiblemente útil pero poco relacionado e irrelevante. Ahora el modelo debe separar por sí mismo la señal del ruido, lo que aumenta el costo en tokens y hace que la respuesta sea menos predecible.
Las preguntas sin respuesta requieren un comportamiento específico
Un caso particularmente importante es una pregunta a la que la base de conocimientos simplemente no puede responder, como “¿Cuál es el deducible del seguro médico de la empresa?”, cuando el manual nunca lo menciona. Top-K seguirá devolviendo cinco fragmentos, y un proceso ingenuo tratará al más cercano como evidencia para hacer una conjetura.
El comportamiento adecuado en un entorno empresarial es indicar que los documentos disponibles no contienen suficiente información. Un sistema bien diseñado debería poder devolver algo como:
No sufficiently relevant context was found.
Agregar un filtro de relevancia entre la recuperación y el modelo
Manejar tanto coincidencias débiles como preguntas sin respuesta requiere una etapa adicional. El flujo básico es:
Vector Search
↓
Top-K
↓
LLM
El flujo mejorado trata a Top-K como una lista de candidatos e inserta un filtro antes del modelo:
Vector Search
↓
Top-K candidates
↓
Relevance Filter
↓
LLM
El filtro más simple es un umbral de similitud. Los candidatos que alcanzan o superan dicho umbral sobreviven:
score >= threshold
→ keep
y todo lo que está por debajo de él es descartado:
score < threshold
→ discard
Si no queda nada, el sistema devuelve la respuesta “no hay contexto relevante” en lugar de llamar al modelo con datos defectuosos.
Elegir el umbral a partir de mediciones
El umbral debe basarse en los datos. Un pequeño experimento con un conjunto de datos de manuales empresariales comparó la tasa de recuperación en consultas respondibles (“conocidas”) con la tasa de rechazo en las no respondibles (“desconocidas”) para varios valores:
| Threshold | Known-query recall | Unknown-query rejection |
| --------: | -----------------: | ----------------------: |
| 0.20 | 100% | 0% |
| 0.25 | 100% | 0% |
| 0.30 | 100% | 50% |
| 0.35 | 100% | 50% |
| 0.40 | 100% | 50% |
| **0.45** | **100%** | **100%** |
| 0.50 | 100% | 100% |
| 0.55 | 100% | 100% |
En este conjunto de datos, 0.45 fue el primer umbral que mantuvo todas las consultas conocidas mientras rechazaba todas las desconocidas, lo que lo convirtió en la mejor separación entre los valores probados. Ese número no es portable. Las puntuaciones de similitud dependen del modelo de embedding, del corpus, de la redacción de las consultas y de la configuración de recuperación; los diferentes modelos distribuyen sus puntuaciones en rangos muy distintos. La tasa de rechazo, que aumenta en pasos del 50%, también sugiere un conjunto muy pequeño de consultas desconocidas, por lo que una implementación real necesita un conjunto más grande y etiquetado antes de poder confiar en ese umbral. Lo que sí se puede transferir es el método: medir el comportamiento de recuperación en preguntas conocidas y desconocidas, y elegir el umbral basándose en evidencias, no en intuición.
La recuperación y el ranking son tareas diferentes
Supongamos que la recuperación devuelve 20 candidatos. Ha cumplido su función: encontró 20 fragmentos de texto que probablemente estén relacionados. Queda una segunda pregunta: ¿cuáles de ellos son los cinco mejores contextos para esta pregunta en particular? Esa es la tarea del reclasificación.
La recuperación está optimizada para la precisión en un conjunto grande, reduciendo algo como 10,000 fragmentos a un conjunto de candidatos manejable:
10,000 chunks
↓
retrieval
↓
50 candidates
Luego, la reclasificación vuelve a calificar ese pequeño conjunto con más cuidado, generalmente mediante un modelo que lee la pregunta y cada candidato juntos, y mantiene los más sólidos:
50 candidates
↓
reranker
↓
5 strongest candidates
El flujo ahora se ve así:
Question
↓
Embedding
↓
Vector / Hybrid Search
↓
Candidate Set
↓
Reranking
↓
Best Context
↓
LLM
La búsqueda semántica no detecta términos exactos
Los embeddings son excelentes para el significado, pero los datos empresariales están llenos de tokens cuyo valor radica en su escritura exacta:
INC-48271
ERR_CONNECTION_RESET
POL-104
AWS us-east-1
customer_12345
Un modelo de incrustación puede darse cuenta de que una consulta se refiere a un error de conexión al clasificar el fragmento que contiene el código exacto ERR_CONNECTION_RESET por debajo de un párrafo genérico sobre redes.
La recuperación híbrida combina ambos indicadores
La solución estándar es la recuperación híbrida, que ejecuta simultáneamente búsquedas semánticas y léxicas:
Semantic Search
+
Keyword / Lexical Search
Las dos búsquedas se realizan para la misma pregunta y sus resultados se fusionan en un único conjunto de candidatos, a menudo mediante un método de fusión que combina las dos clasificaciones:
Question
│
┌─────────┴─────────┐
↓ ↓
Semantic Search Keyword Search
│ │
└─────────┬─────────┘
↓
Candidate Set
El sistema logra una similitud semántica para preguntas parafraseadas y una coincidencia exacta de términos para identificadores.
El pipeline orientado a la producción
Con cada etapa implementada, el flujo completo es:
Documents
↓
Semantic Chunking
↓
Embeddings
↓
Vector / Hybrid Retrieval
↓
Relevance Filtering
↓
Reranking
↓
LLM
↓
Answer + Sources
↓
Evaluation + Observability
El modelo ya no se encuentra directamente detrás de una base de datos vectorial. Ahora, una verdadera arquitectura de recuperación se interponga entre el usuario y el LLM. Para conocer más sobre la etapa de clasificación y cuándo su latencia resulta útil, consulte nuestro artículo sobre por qué el reranking debe justificar su latencia.
Una línea de base que vale la pena crear primero
Una buena forma de aprender sobre estos equilibrios es desarrollando el sistema de manera incremental. Una pequeña línea de base podría combinar Python, FastAPI, embeddings de OpenAI y LLMs, además de Pinecone como almacén vectorial, junto con:
- fragmentación sensible a los encabezados y metadatos de los fragmentos
- recuperación semántica con un
top_kconfigurable - filtrado por similitud
- atribución de la fuente
- evaluación de la recuperación
Su flujo es:
Question
↓
Embedding
↓
Pinecone Retrieval
↓
Top-K Candidates
↓
Similarity Threshold
↓
Relevant Context
↓
LLM
↓
Answer + Sources
El siguiente paso lógico es añadir recuperación híbrida y reclasificación, y compararlos con esta línea de referencia utilizando el mismo conjunto de evaluación, de modo que cada mejora se mida en lugar de suponerse.
Midiendo si el sistema es fiable
“¿Funciona el chatbot?” no es una pregunta útil. Desgúzala en dimensiones que se puedan medir:
- Calidad de la recuperación: ¿Se obtuvo información correcta?
- Calidad de la clasificación: ¿El contexto más útil aparece cerca del principio?
- Sustentación: ¿La respuesta está respaldada por el contexto recuperado?
- Exactitud de las citaciones: ¿Las fuentes citadas respaldan las afirmaciones?
- Gestión de consultas desconocidas: ¿El sistema reconoce cuando la respuesta no está en la base de conocimientos?
El objetivo cambia de “¿puede la aplicación responder preguntas?” a “¿podemos medir si la arquitectura de recuperación es fiable?”
Puntos clave
- RAG va más allá de darle a un LLM acceso a documentos; las decisiones difíciles son qué recuperar, en qué confiar, qué transmitir y cuándo rechazar.
top_kgarantiza la cantidad, no la relevancia, por lo que se deben filtrar los candidatos con un umbral calibrado según sus propios datos.- La búsqueda híbrida identifica los identificadores exactos que los embeddings difuminan, y el reordenamiento convierte un conjunto amplio de candidatos en un contexto preciso.
- La calidad de la respuesta se determina en gran medida antes de que el modelo vea cualquier contexto: un mejor contexto conduce a mejores respuestas y sistemas más fiables.
- Trate el RAG de producción como un problema arquitectónico con etapas medibles, y no como una simple integración de LLM.
Lecturas relacionadas
- Retrieval híbrido con pgvector, BM25 y un reclasificador de codificadores — Aprenda por qué la búsqueda vectorial pura omite números de pieza y códigos de error, y cómo combinar pgvector, BM25 y el reclasificador en LangChain para una recuperación RAG precisa.
- Elegir el tamaño adecuado de LLMs: enrutamiento, recuperación y evaluación según el tamaño del modelo original — Aprenda cómo elegir entre modelos de lenguaje pequeños y grandes según la carga de trabajo, medir el costo por tarea exitosa, y utilizar primero el enrutamiento, RAG, caché y validación.
- Diseñando un pipeline RAG fundamentado en la realidad: fragmentación, filtrado seguro de tokens, filtrado de recuperación en tres etapas, reensamblaje de elementos relacionados, diseño de prompts y transmisión. — Una guía paso a paso sobre las bases de un pipeline RAG fundamentado en la realidad: fragmentación consciente de la estructura, división segura de tokens, filtrado de recuperación en tres fases, reensamblaje de elementos relacionados, diseño de prompts y transmisión.