[!NOTE] Traducción automática Este artículo se tradujo automáticamente a partir de la versión original en inglés.
Mejor stack de clasificación de búsquedas para productos AI
Un buen stack de búsqueda funciona como un embudo. Los métodos económicos recopilan primero un conjunto amplio de candidatos; los métodos costosos refinan posteriormente un conjunto mucho más reducido. Los problemas suelen surgir cuando los equipos reemplazan la búsqueda de texto exacto por embeddings en lugar de combinar ambas técnicas.
Comience con filtros y BM25, un método de clasificación por texto exacto muy eficaz. Añada una recuperación densa para identificar coincidencias semánticas y, a continuación, fusione las dos listas de resultados mediante Reciprocal Rank Fusion (RRF) u otro método similar. Realice una nueva clasificación de la lista reducida usando un cross-encoder. Utilice un LLM únicamente en un pequeño conjunto final, cuando la mejora en calidad justifique el aumento adicional de latencia y costes.
Stack recomendado
| Etapa | Valor predeterminado | Tarea |
|---|---|---|
| Filtrado | Filtros estructurados | Aplicar restricciones por arrendatario, permisos, producto, idioma, hora y disponibilidad. |
| Recuperación léxica | BM25 | Nombres exactos, identificadores, códigos de error, términos legales y tokens de alta precisión. |
| Recuperación densa | Embeddings | Sinónimos, paráfrasis, intención difusa y recuperación semántica. |
| Fusión | Fusión de rangos recíprocos o composición de recuperadores ponderados | Fusionar los candidatos dispersos y densos sin pretender que sus puntuaciones sean comparables. |
| Reranking | Codificador cruzado | Reordenar de 20 a 100 candidatos mediante la interacción consulta-documento. |
| Precisión final | LLM reranker o responder al modelo | Solo se debe resolver la relevancia matizada una vez que la lista esté reducida. |
| Evaluación | Recall@k, nDCG, MRR, etiquetas de clic, etiquetas humanas | Demuestre que cada etapa mejora a la anterior. |
Valores predeterminados de casos de uso
| Superficie del producto | Buena configuración predeterminada | ¿Por qué? |
|---|---|---|
| Búsqueda de documentación | BM25 más embeddings más codificador cruzado | Los nombres exactos de API y las cuestiones semánticas son igualmente importantes. |
| RAG recuperación | Recuperación híbrida junto con reranker y verificaciones de citación | La falta de evidencias suele ser un problema peor que una generación lenta. |
| Búsqueda de productos | Filtros léxicos junto con recuperación híbrida más funcionalidades empresariales | La disponibilidad, el precio, la popularidad y las facetas exactas son factores cruciales. |
| Soporte para búsquedas | Recuperación híbrida junto con información de frescura y metadatos de ticket | Tanto la redacción similar como la política actual son importantes. |
| Base de conocimiento interna | Línea de referencia BM25, seguida de recuperación densa a partir de los registros de consultas | Comience a medir los resultados antes de incorporar el costo del modelo. |
| Búsqueda legal o de cumplimiento normativo | Una línea de base léxica sumada a filtros estrictos, seguida de una expansión semántica cuidadosa. |
Por qué BM25 sigue formando parte del stack
Embeddings localizar texto con un significado similar, aunque no sustituyen de forma fiable a una coincidencia exacta. Los códigos de error, los nombres de funciones, las SKU de productos, las frases legales y los nombres de personas suelen transmitir la intención del usuario a través de su escritura exacta. BM25 sigue siendo una base sólida, ya que premia a aquellos términos que el usuario escribió realmente.
La recuperación densa mejora el recuerdo cuando los usuarios no conocen el vocabulario exacto. El patrón adecuado no es BM25 ni embeddings. Se debe utilizar BM25 para el recuerdo léxico, embeddings para el recuerdo semántico, y la fusión para combinarlos.
Cuándo añadir un reranker
Se debe añadir un codificador cruzado cuando los documentos relevantes aparezcan en alguna posición de las 50 primeras pero no cerca del inicio de la lista. Ese es el indicador más claro de que la generación de candidatos funciona correctamente y de que el sistema de clasificación necesita ser mejorado.
No se debe incluir un LLM reranker antes de un cross-encoder, a menos que el conjunto de candidatos sea muy reducido. Además, este necesita un criterio de relevancia lo suficientemente preciso como para justificar el costo asociado. LLM reranking pueden ser útiles, pero resultan costosos y más lentos. Es recomendable compararlos con un reranker más económico.
Secuencia de evaluación
- Etiquetar un conjunto reducido de consultas reales.
- Medir únicamente el índice BM25.
- Incorporar la recuperación densa y medir el cambio en la tasa de recuperación.
- Añadir la fusión de resultados y medir el nDCG así como la tasa de recuperación @k.
- Integrar el codificador cruzado reranking y evaluar la precisión @1 junto con el nDCG.
- Incluir LLM reranking solo si su adición mejora la calidad, teniendo en cuenta los costes y la latencia.
- Monitorear las métricas en producción: tasa de resultados nulos, tasa de reformulación, tasa de clics, correcciones de respuestas, latencia p95 y costes.
Lectura adicional
- La arquitectura de clasificación de búsquedas en 2026 proporciona una guía completa paso a paso sobre la implementación. RAG Métricas de evaluación explica la recuperación de información y la evaluación de las citaciones.