API rerank : trier les résultats par pertinence, traitée dans l'UE

POST /v1/rerank reçoit un model, une query et un tableau documents de chaînes. Un modèle de reclassement comme bge-reranker-v2-m3 lit la requête et chaque document ensemble, ce qui lui permet de juger la pertinence bien plus finement qu'une comparaison entre deux embeddings calculés séparément. La contrepartie est la vitesse : on reclasse une courte liste de candidats, pas tout un corpus.

La réponse contient un tableau results trié du plus pertinent au moins pertinent. Chaque résultat donne l'index du document dans votre tableau d'origine et un relevance_score. L'index vous permet de retrouver le document et ses métadonnées de votre côté.

top_n limite le nombre de résultats renvoyés ; sans ce champ, vous obtenez un score pour chaque document. Avec return_documents: true, chaque résultat inclut aussi le texte du document, ce qui évite une recherche mais alourdit la réponse.

Le format de requête suit le schéma de reclassement qu'utilisent la plupart des bibliothèques de recherche et des frameworks RAG. Une intégration qui accepte un point de terminaison rerank personnalisé se branche donc généralement sur inference.eu en changeant l'URL, la clé et le modèle. bge-reranker-v2-m3 est multilingue : une question en français peut classer correctement des passages en allemand ou en anglais.

D'abord, vectorisez la question et récupérez les 30 à 50 morceaux les plus proches dans votre base vectorielle : c'est rapide, le rappel est élevé, mais l'ordre est approximatif. Ensuite, envoyez la question et ces morceaux au point de terminaison rerank et gardez les trois à huit meilleurs. Enfin, placez-les dans le prompt d'un modèle de chat en lui demandant de citer ses sources.

Le score peut aussi servir de seuil. Si même le meilleur résultat obtient un score faible, indiquez à l'utilisateur que la base documentaire ne contient pas de bonne réponse, plutôt que de laisser le modèle deviner. Ajustez ce seuil sur un jeu de vraies questions.

Chaque paire requête-document doit tenir dans la longueur d'entrée du modèle. Les documents plus longs sont tronqués côté modèle : reclassez des morceaux de taille comparable à ceux que vous avez vectorisés, pas des fichiers entiers. Un tableau documents vide ou une requête vide renvoient une erreur 400.

Les scores ne sont comparables qu'au sein d'un même modèle ; ne transposez pas un seuil d'un modèle à l'autre. Une très longue liste de candidats ralentit la requête sans grand bénéfice, car une bonne recherche initiale place déjà la réponse dans les 50 premiers. Le nombre de documents par requête dépend de votre offre et nous vous le confirmons.