Un sistema de búsqueda puede fallar aunque utilice un reranker potente: si el documento correcto nunca entró en el conjunto inicial de candidatos, volver a ordenar ese conjunto no lo hará aparecer. Ese es el argumento central de una publicación de Vespa.ai difundida por The New Stack. El texto invita a revisar primero la recuperación y el coste de aplicar modelos caros a demasiados resultados.
La propuesta organiza la búsqueda como un embudo. Una primera fase utiliza métodos relativamente económicos, como coincidencia léxica, búsqueda vectorial o una combinación de ambas, para reunir candidatos. Después se reduce progresivamente el conjunto antes de aplicar un reranker basado en inferencia a los documentos con más posibilidades de responder a la consulta. Así se evita gastar cómputo en ordenar una lista inmensa y se reduce la latencia. La arquitectura debe equilibrar recall, relevancia, tiempo de respuesta y coste: recuperar muy pocos documentos puede excluir la respuesta, mientras que recuperar demasiados encarece las fases posteriores.
El mismo criterio se aplica a RAG. Primero deben encontrarse documentos útiles; luego hay que decidir qué fragmentos merecen ocupar el espacio limitado del contexto del modelo. El artículo es una invitación a un seminario de Vespa.ai, no un informe de resultados independientes. Su recomendación práctica es medir cada etapa del embudo antes de invertir en un reranker mayor y comparar si ese gasto mejora realmente las respuestas.
Glosario
- Reranker
- Modelo o algoritmo que vuelve a ordenar resultados ya recuperados según su relevancia para una consulta.
- Recuperación
- Primera fase de búsqueda que encuentra documentos candidatos dentro de un conjunto mayor.
- RAG
- Técnica que aporta información recuperada de fuentes externas al contexto de un modelo generativo.
- Recall
- Medida de cuántos resultados relevantes consigue incluir un sistema entre los candidatos recuperados.