Búsqueda híbrida y reranking para chatbots de IA: mejores resultados RAG

Los chatbots para sitios web rara vez fallan porque la base de conocimientos no contenga información. Con mayor frecuencia, el paso de recuperación (retrieval) no encuentra el pasaje que se adapta a la pregunta y al contexto específico. Los visitantes utilizan nombres de productos, mensajes de error y números de artículo, pero también se expresan de forma libre: “¿Por qué el chatbot muestra la tarifa incorrecta?” o “¿Puedo modificar un pedido que ya ha sido enviado?”. Para esta mezcla, ni la búsqueda exclusiva por palabras clave ni la búsqueda vectorial pura bastan como respuesta general. La búsqueda híbrida combina ambas señales para que un chatbot RAG reciba fuentes más sólidas en su contexto de respuesta.

La búsqueda por palabras clave y la búsqueda vectorial cumplen funciones distintas

La búsqueda por palabras clave es muy eficaz cuando las palabras deben coincidir de forma exacta. Esto se aplica a números de pedido, denominaciones de productos, mensajes de error concretos, nombres de contratos o versiones como “2.4”. Permite mostrar de forma transparente por qué coincide un documento: la palabra buscada aparece en el título, en un encabezado o en el pasaje. Su debilidad se manifiesta con el lenguaje cotidiano, los sinónimos y las formulaciones incompletas. Una pregunta de un visitante buscando una “copia de factura” no encontrará necesariamente una página que solo hable de “descargar recibo”.

La búsqueda vectorial complementa esta carencia. Representa la pregunta y el contenido como una proximidad semántica y, por lo tanto, puede encontrar solicitudes similares aunque falten los mismos términos. Esto ayuda con preguntas de soporte formuladas de forma natural, variantes multilingües y diferentes denominaciones para un mismo proceso. Sin embargo, la proximidad semántica por sí sola no es una garantía total: un pasaje puede ser similar al tema, pero referirse a otra versión del producto, a otro mercado o a una regla caducada. Es exactamente por eso que la verificación del contexto pertenece a la canalización de recuperación y no debe postergarse hasta el modelo de lenguaje.

Por qué la búsqueda híbrida es un punto de partida lógico

Microsoft describe la búsqueda híbrida como una consulta conjunta que consta de una parte de texto completo y una parte vectorial. Ambas consultas se ejecutan en paralelo y sus listas de resultados se combinan a continuación. Esto resulta muy atractivo para los sitios web corporativos porque se conservan los términos exactos y, al mismo tiempo, se vuelve accesible el contenido relacionado y bien formulado. Un chatbot no tiene por qué hacer elegir a los usuarios entre una búsqueda “técnica” y una “semántica”. La selección se realiza en segundo plano y se puede verificar para todas las preguntas con el mismo proceso de calidad.

La búsqueda híbrida mejora el conjunto de candidatos; no genera verdades absolutas. El chatbot solo debe utilizar contenidos autorizados para la situación concreta. Las páginas web públicas, los borradores internos y los datos protegidos de clientes no deben formar parte de un contexto común no controlado. Igualmente importante es definir un comportamiento claro cuando no hay una fuente adecuada disponible: realizar una repregunta, ofrecer un enlace a la página de contacto o una transferencia a un agente humano es mucho más seguro que una suposición redactada con fluidez.

Comprender RRF: combinar clasificaciones

Las puntuaciones (scores) de la búsqueda de texto completo y de la búsqueda vectorial tienen significados y escalas diferentes. Súmalas directamente o inventar un umbral fijo suele conducir a resultados inestables. Por ello, Reciprocal Rank Fusion, o RRF, trabaja con la posición de un documento en cada lista de clasificación. Un documento que aparece en los primeros puestos de ambas listas recibe una señal combinada fuerte. Un documento que solo es visible en una lista también puede tenerse en cuenta, pero sin desplazar automáticamente a todos los demás.

RRF no es un valor estándar mágico ni una fórmula sustitutiva para pruebas técnicas. Cuántos candidatos de cada búsqueda entran en la fusión, qué filtros se aplican previamente y cuándo se considera útil un resultado son aspectos que dependen del contenido y del riesgo. Para preguntas frecuentes sobre productos, una ventana pequeña y enfocada puede ser conveniente. Para guías complejas o diagnósticos de errores, se pueden requerir más candidatos. Lo decisivo es comparar los cambios con preguntas reales frente a un conjunto de prueba, en lugar de adoptar un parámetro universal tomado de un ejemplo.

El reranking semántico como segunda etapa limitada

Tras una buena preselección, un reranker puede evaluar de nuevo el conjunto reducido de candidatos respecto a la pregunta completa. Microsoft sitúa la clasificación semántica como un ranking secundario sobre una lista de resultados previamente clasificada. Amazon Bedrock describe de forma similar el reranking como la evaluación de documentos de texto según su relevancia respecto a la consulta. Esta segunda etapa es idónea para preguntas con múltiples condiciones: por ejemplo, si es posible cambiar de tarifa después de que un pedido ya haya sido enviado y cuando existe un tipo de contrato determinado.

El reranking debe limitarse conscientemente. Consume latencia adicional y, según el servicio, puede implicar costes. Por lo tanto, no envíe toda la base de conocimientos a un reranker, sino únicamente el grupo superior ya filtrado y fusionado. Defina un presupuesto de tiempo y una solución de reserva (fallback). Si se supera el presupuesto, el chatbot puede mostrar la lista de fuentes más fiable, solicitar una aclaración o transferir la conversación a un equipo de soporte. Un reranker no repara contenidos desactualizados, inexistentes o no autorizados.

Los filtros de metadatos protegen el contexto

Los metadatos suelen influir más en la calidad de la respuesta que una opción de modelo adicional. Mantenga por cada fuente al menos el idioma, el producto o servicio, la versión, el mercado, el público objetivo y la validez, en la medida en que estos datos sean relevantes para su uso. Un filtro para el cliente (tenant) o área de permisos correctos debe aplicarse antes de la generación. En un sitio web público, un chatbot solo puede recuperar contenidos públicos; para un área privada con sesión iniciada se aplican además permisos verificables.

El tiempo también es una cuestión de metadatos. Las listas de precios, las condiciones de entrega y las instrucciones deben contar con una fecha de actualización clara o un estado de validez controlado. Si la fuente ya no es confiable, debe retirarse del índice o enviarse a una ruta de revisión separada. Los filtros deben responder a requisitos comprensibles para los visitantes, no manipular secretamente el orden de clasificación. Documente por lo tanto qué filtros se aplican a cada clase de pregunta y cómo verifica los cambios su equipo.

Una canalización concreta desde la consulta hasta el contexto

1. Normalizar la pregunta: Identifique el idioma y el contexto evidente sin almacenar ni modificar datos personales innecesariamente.
2. Verificar accesos y metadatos: Determine antes de la recuperación qué fuentes están permitidas para el producto, el mercado, el rol y el periodo de validez.
3. Recuperar en paralelo: Ejecute la búsqueda de texto completo y la búsqueda vectorial sobre el mismo conjunto de fuentes autorizadas.
4. Fusionar clasificaciones: Combine las listas mediante RRF y conserve las señales de origen de cada candidato para el depurado (debugging).
5. Reclasificar de forma limitada: Realice la evaluación de relevancia únicamente sobre el grupo superior reducido y mida la latencia.
6. Asegurar el contexto: Verifique duplicados, estado de las fuentes y una longitud adecuada antes de enviar los pasajes al modelo de respuesta.
7. Respuesta con límites: Indique las fuentes, marque la incertidumbre y utilice una transferencia segura si es necesario.

Ejemplo práctico: estado del envío y cambio de tarifa

Supongamos que un visitante pregunta: “¿Puedo cambiar mi tarifa aunque el paquete ya esté en camino?”. La búsqueda por palabras clave puede encontrar una página sobre “cambiar tarifa” y un artículo de soporte sobre “paquete en camino”. La búsqueda vectorial encuentra una guía que describe el proceso como un cambio posterior al envío. RRF posiciona en los primeros lugares los documentos que combinan ambos aspectos. A continuación, un reranker puede verificar si el pasaje relevante contiene realmente la combinación de tarifa y envío.

Antes de responder, aplique un filtro por el mercado afectado, la línea de producto y el estado de validez actual. Si las fuentes son contradictorias o faltan detalles requeridos, el chatbot no debe deducir la respuesta basándose en casos similares. Puede explicar de forma transparente qué condición está pendiente y dirigir al visitante a una opción de contacto verificada y adecuada. De este modo, la conversación sigue siendo útil sin inventar un compromiso no respaldado.

Casos sin resultado y depuración de puntuaciones

Un caso de sin resultado (no-result) suele ser una señal de un vacío de conocimiento, no de una búsqueda defectuosa. Por lo tanto, diferencie al menos cuatro casos: no existe una fuente autorizada, existen fuentes pero no hay un resultado suficientemente relevante, la pregunta es ambigua o un error técnico impide la recuperación. Cada caso requiere una reacción propia y comprensible. “No encuentro una respuesta fiable sobre esto en la información autorizada” es más honesto que una frase genérica sin un siguiente paso.

Para la depuración, las puntuaciones finales por sí solas no son suficientes. Para cada pregunta de prueba, los equipos deben poder ver qué filtros se aplicaron, qué documentos provinieron de la búsqueda por palabras clave y vectorial, cómo se fusionaron y si el reranking cambió el orden. Guarde únicamente los datos necesarios para la calidad y procesados con minimización de datos. Busque patrones: ¿faltan ciertos sinónimos? ¿Un contenido antiguo está superponiéndose al nuevo? ¿Un idioma rompe la lógica de metadatos? Solo identificando la causa concreta se puede decidir si se debe modificar el fragmentado (chunking), los metadatos, el mantenimiento de fuentes o la clasificación.

Conjunto de prueba, métricas y presupuesto de costes

Un conjunto de prueba reducido (Golden Set) con 30 a 50 preguntas reales es un buen punto de partida. Defina para cada pregunta las fuentes esperadas, las fuentes no permitidas y la reacción deseada ante la falta de conocimiento. Mida por separado si una fuente correcta se encuentra entre los candidatos, si se clasifica lo suficientemente alto y si la respuesta final solo utiliza información fundamentada. Añada intencionadamente erratas, términos exactos, formulaciones naturales, variantes multilingües y casos negativos críticos.

Modifique únicamente una variable por cada ejecución de prueba: un filtro, el número de candidatos, la profundidad del reranking o la estructura de los fragmentos. Anote también el tiempo de respuesta y el número de llamadas a modelos externos. Un valor de relevancia más alto puede ser inservible si la respuesta llega demasiado tarde o si los costes aumentan para preguntas frecuentes estándar. Por ello, defina un presupuesto de latencia y costes para cada clase de pregunta. Respuestas estándar rápidas y bien fundamentadas, junto con transferencias conservadoras, son más valiosas para muchos sitios web que un sistema de clasificación de máxima complejidad.

Errores típicos durante la implementación

• Comparar directamente puntuaciones brutas de palabras clave y vectores cuando sus escalas no son equivalentes.
• Indizar borradores, listas de precios antiguas o contenidos protegidos sin aplicar filtros de estado y permisos.
• Aplicar reranking a demasiados candidatos, perdiendo el control sobre la latencia y los costes.
• Tratar una demostración con pocas preguntas acertadas como una prueba de calidad suficiente.
• Generar una respuesta plausible cuando falta la fuente, en lugar de prever incertidumbre, repreguntas o transferencia humana.
• No registrar versiones de los cambios en fuentes, fragmentado o clasificación, impidiendo su explicación posterior.

Lista de comprobación para la implementación

• Establecer las fuentes permitidas y los límites de permisos antes de realizar la indización.
• Mantener los metadatos de idioma, producto, versión, mercado y validez.
• Recuperar texto completo y búsqueda vectorial en paralelo para fusionarlos posteriormente con RRF.
• Utilizar el reranking únicamente para un conjunto reducido y permitido de candidatos.
• Evaluar enlaces a fuentes, respuestas sin resultado y transferencia a agentes humanos en el conjunto de prueba.
• Medir la latencia, los costes y las respuestas erróneas críticas tras cada cambio.

Conclusión

La búsqueda híbrida es un punto de partida robusto para chatbots de sitios web que enfrentan diversos tipos de preguntas. La búsqueda por palabras clave conserva las señales exactas, la búsqueda vectorial abre la puerta a solicitudes similares, RRF fusiona sus clasificaciones y un reranker limitado puede perfeccionar la selección final. No obstante, la mejora sostenible de la calidad se logra mediante fuentes cuidadas, metadatos adecuados, pruebas comprensibles y una lógica de respuesta que muestre abiertamente sus límites. De este modo, la recuperación se vuelve verificable en lugar de ser únicamente impresionante desde el punto de vista técnico.

Fuentes y referencias adicionales

• Microsoft Learn: Búsqueda híbrida
• Microsoft Learn: Relevancia y RRF en la búsqueda híbrida
• Microsoft Learn: Clasificación semántica
• Amazon Bedrock: Reranking
• ChatReact: Chunking RAG para chatbots de IA
• ChatReact: Medir la calidad de respuesta con Golden Set
• ChatReact: Mantener actualizada la base de conocimientos