Comment la profondeur du reranker affecte-t-elle la latence de la recherche privée ?
La profondeur du reranker augmente la latence de la recherche privée à peu près proportionnellement au nombre de candidats évalués, même si le batching, la longueur des séquences, l'architecture du modèle et le matériel rendent cette courbe non linéaire.
Un récupérateur de première étape peut renvoyer 20, 100 ou 500 segments candidats avant qu'un cross-encoder ou un LLM local ne les réordonne. Un reranking plus profond donne au passage pertinent davantage de chances de survivre à un classement initial médiocre, mais chaque candidat ajoute du travail de tokenisation et d'inférence. Une fois que le rappel des documents pertinents atteint un plateau, augmenter la profondeur consomme surtout des ressources de calcul et peut allonger les requêtes interactives les plus lentes.
La profondeur correspond au nombre de candidats entrant dans la deuxième étape
La profondeur du reranking diffère du top-k final. Un pipeline peut évaluer cent candidats et en renvoyer cinq : la latence dépend donc de cent comparaisons requête-document, même si le modèle de langage n'en voit que quelques-unes. La longueur du texte des candidats détermine le nombre de tokens traités par comparaison.
L'expérience d'Elastic sur la profondeur du reranking mesure la qualité de la recherche lorsque la profondeur du reranking varie et fournit des recommandations propres à chaque modèle. Les résultats montrent que la profondeur utile dépend du récupérateur de première étape et du reranker, plutôt que d'un nombre fixe. Cet effet doit rester mesurable dans les conditions de charge prévues sur un serveur domestique.
Une première étape peu performante peut nécessiter une plus grande profondeur pour inclure la réponse, tandis qu'un récupérateur hybride performant peut présenter plus tôt de bons candidats. La profondeur du reranking ne peut donc pas compenser des candidats qui n'ont jamais été récupérés. Cette distinction est importante lorsque plusieurs étapes du pipeline partagent le même budget de stockage et de mémoire.
Le coût de l'inférence augmente avec le nombre de candidats et leurs tokens
Les cross-encoders traitent conjointement la requête et chaque candidat : doubler la profondeur double donc approximativement le nombre de paires évaluées, avant de tenir compte des effets du batching. De plus grands lots peuvent améliorer l'utilisation de l'accélérateur, mais ils nécessitent aussi davantage de mémoire et peuvent retarder le premier résultat jusqu'à la fin du traitement d'un lot.
Une étude sur le reranking pair à pair fait état de fortes réductions de latence en limitant l'ensemble réordonné, en choisissant des modèles plus petits, en réduisant la précision et en contrôlant le travail de génération. Elle montre que la profondeur est l'un des nombreux choix de service qui se multiplient entre eux. Cette limite doit être testée avec des données domestiques représentatives plutôt que supposée.
Le reranking sur CPU peut présenter une courbe presque linéaire, tandis que les courbes sur GPU peuvent comporter des plateaux efficaces, suivis de brusques dégradations dues à la mémoire ou à la mise en file d'attente. La latence de queue augmente également lorsque la longueur des candidats varie, car les segments longs dominent le travail des lots. Cet effet doit rester mesurable dans les conditions de charge prévues sur un serveur domestique.
Les gains de qualité atteignent un plateau avant les coûts
Augmenter la profondeur n'est utile que tant que des éléments pertinents se trouvent sous la limite actuelle et que le reranker peut les identifier. Une fois le rappel de la première étape saturé, davantage de candidats ajoutent des éléments distrayants et des coûts, réduisant parfois la stabilité du classement pour les requêtes ambiguës.
Une évaluation de bout en bout contrôlée compare des configurations de récupérateurs et de rerankers selon leur efficacité, la qualité de génération, le coût et la latence. Elle plaide pour le choix de la profondeur à partir d'un compromis de bout en bout, plutôt que pour l'optimisation isolée des scores de classement. Cette distinction est importante lorsque plusieurs étapes du pipeline partagent le même budget de stockage et de mémoire.
La limite problématique consiste à choisir une profondeur à partir de la latence moyenne de requêtes uniformes exécutées sur des modèles déjà chauds. Les modèles froids, les segments longs, les utilisateurs simultanés et les lectures depuis un NAS peuvent faire largement dépasser la médiane au p95 ou au p99, même lorsque la pertinence moyenne ne progresse que légèrement.
FAQ sur la profondeur des candidats du reranker
Le reranking de 100 candidats est-il deux fois plus lent que celui de 50 candidats ?
Le travail d'évaluation peut approcher le double, mais le temps réel peut être inférieur ou supérieur selon l'utilisation des lots, la longueur des tokens, les limites de mémoire et la mise en file d'attente. Mesurez le modèle déployé plutôt que de supposer un rapport parfaitement linéaire.
Un top-k final plus grand nécessite-t-il une plus grande profondeur de reranking ?
En général, le pool de candidats doit dépasser le nombre de résultats finaux, mais le multiplicateur nécessaire dépend du rappel de la première étape et de la diversité des résultats. Renvoyer davantage de passages ne justifie pas automatiquement l'évaluation de centaines de candidats peu pertinents. Cette limite doit être testée avec des données domestiques représentatives plutôt que supposée.
La mise en cache des scores du reranker peut-elle réduire la latence ?
La mise en cache aide pour les paires requête-candidat répétées ou les requêtes normalisées stables, mais la recherche privée contient souvent des formulations uniques et des documents qui changent. L'invalidation du cache doit suivre les versions des documents et les changements de modèle afin d'éviter un classement obsolète. Cet effet doit rester mesurable dans les conditions de charge prévues sur un serveur domestique.
Trouvez la plus petite profondeur située sur le plateau de qualité
Constituez un ensemble de requêtes annotées comprenant des termes exacts, des paraphrases, des noms ambigus et des négatifs difficiles. Testez des profondeurs de reranking telles que 10, 25, 50, 100 et 200, tout en mesurant le rappel de la première étape, le nDCG ou le MRR final, la couverture des citations, le temps CPU ou GPU, la mémoire, ainsi que les latences p50, p95 et p99.
Comparez la courbe aux facteurs de décision présentés dans les facteurs de décision relatifs au reranker. Maintenez constants la génération des candidats de première étape, la longueur des segments, le modèle de reranking, le top-k final, la concurrence et l'état du cache, afin que la profondeur soit la seule variable modifiée. Cette distinction est importante lorsque plusieurs étapes du pipeline partagent le même budget de stockage et de mémoire.
Choisissez la plus petite profondeur dont la qualité est statistiquement indiscernable du plateau et dont la latence de queue respecte l'objectif interactif. Orientez les recherches en arrière-plan vers un profil plus profond uniquement lorsque le gain de rappel supplémentaire a une valeur mesurée. Cette limite doit être testée avec des données domestiques représentatives plutôt que supposée.
Produits recommandés
Centre Tech & IA
Plus à lire
Un modèle de langage local peut-il reprendre la génération après le redémarrage de son processus ?
Une explication de la reprise de génération des LLM axée sur les mécanismes, de ses compromis en matière de ressources partagées, de trois FAQ...
Un serveur domestique peut-il exécuter des embeddings et du transcodage vidéo sur le même GPU intégré ?
Une explication axée sur les mécanismes des embeddings partagés de l’iGPU et du transcodage, de leurs compromis en matière de ressources partagées, de trois...
Quel est l’impact de la durée de vie des jetons d’accès sur la sécurité et les contraintes au sein du foyer ?
Une explication fondée sur les mécanismes de la durée de vie des jetons d’accès, de ses compromis en matière de ressources partagées, de trois...
