Faites en sorte que les termes exacts et leur signification collaborent dans la recherche.
Combinez les listes de candidats lexicaux et sémantiques sans considérer que des scores de recherche incompatibles sont interchangeables.
ERR_CACHE_STALE s’attend à obtenir le code d’erreur correspondant. Un autre développeur pourrait décrire le même problème comme « l’application affiche constamment les données d’hier ». Une recherche de connaissances utile doit pouvoir gérer ces deux types de requêtes.
Pour couvrir un plus grand nombre de candidats, appliquez les deux méthodes de récupération sur le corpus éligible et fusionnez leurs résultats. Utilisez les mêmes règles et filtres d’éligibilité que dans les deux approches. Un document exclu en raison de son identité incertaine ne doit pas réapparaître grâce au deuxième outil de récupération.
Cela s’appuie directement sur l’inventaire des sources : la récupération doit se baser sur des éléments que vous êtes prêt à utiliser.
Fusionnez les classements avant d’inventer une arithmétique de scores
Un score BM25 et un score de similarité cosinus décrivent des calculs différents. Leur addition directe donne un nombre, mais ce dernier n’a pas d’interprétation automatique en tant que pertinence combinée.
La fusion des classements par réciproque offre une base simple. Chaque liste classée contribue une valeur en fonction de la position du candidat :
fused_score(document) = sum(1 / (c + rank_in_list))
Les classements commencent à un. Une liste ne contribue rien pour un document qu’elle n’a pas récupéré. La constante positive c contrôle la rapidité avec laquelle la contribution varie d’une position à l’autre.
L’avantage réside dans la simplicité d’exploitation : le fusionnement ne nécessite pas que les échelles de scores sous-jacentes soient identiques. L’inconvénient, c’est que cela élimine l’amplitude du score. Deux résultats adjacents reçoivent des contributions similaires, même lorsque l’un des outils de recherche les a considérés comme très différents.
Gardez la constante ainsi que le nombre de candidats dans la configuration, puis évaluez-les. Il s’agit de choix de conception, et non de garanties de pertinence.
Dédupliquer par identité, et non par titre
Deux outils de recherche peuvent retourner le même fragment. Fusionnez ce fragment à l’aide de son identifiant stable afin que les deux classements contribuent au même candidat. Ne le comptez pas comme deux éléments de preuve indépendants.
Les titres sont des identifiants faibles. Différents articles peuvent partager un même titre, et un article peut changer de titre. Une clé de segment utile inclut l’identité de la source, la version du contenu et l’emplacement du segment.
Il convient également de distinguer les candidats à duplication exacte des segments voisins au sein d’une même section. Ces derniers pourraient nécessiter une consolidation ultérieure, comme expliqué dans le chunking permettant de préserver les preuves.
Tester les types de requêtes séparément
Utilisez au moins trois groupes de questions : des identifiants exacts, des descriptions conceptuelles, ainsi que des combinaisons des deux. Comparez la recherche lexicale seule, la recherche sémantique seule et le résultat obtenu en fusionnant les deux méthodes.
Vérifiez si les preuves pertinentes parviennent au pool de candidats avant d’évaluer la qualité des réponses. Si la fusion améliore les requêtes conceptuelles mais nuit aux requêtes basées sur des codes d’erreur exacts, la moyenne globale peut masquer une régression importante.
Fournir une liste restreinte utile en aval
L’étape suivante peut reclasser les candidats en utilisant un signal de pertinence plus fort. Mais aucune étape de classement ultérieure ne peut sauver des éléments qui n’ont jamais fait partie de la liste restreinte. Mesurez d’abord la couverture des candidats ; sinon, vous risquez d’optimiser l’ordre de matériaux incorrects.