Reranking des résultats

L’approche de retrieval hybride fonctionne bien, mais il reste des imperfections : quand vous cherchez des termes spécifiques ou utilisez des abréviations, les résultats peuvent ne pas être parfaitement ordonnés — le bon segment est dans la liste, mais pas forcément en tête. Or l’ordre compte : c’est lui qui décide quels segments entreront dans le prompt final. La dernière marche de qualité s’appelle le reranking.

Reranking par LLM

Le reranking ajoute une étape de post-traitement après la fusion des résultats. Le concept : prendre vos résultats de recherche et demander à Claude de les réordonner selon leur pertinence réelle par rapport à la question de l’utilisateur. L’intuition qui justifie l’étape : BM25 compte des termes, les embeddings compriment le sens en vecteurs — mais aucun des deux ne lit les candidats à la lumière de la question. Un LLM, si.

Le processus :

1. Exécuter la recherche hybride (vectorielle + BM25) normalement
2. Fusionner les résultats comme d’habitude
3. Passer les résultats fusionnés à une fonction de reranking
4. La fonction envoie le tout à Claude avec un prompt spécifique
5. Claude renvoie une liste réordonnée des documents les plus pertinents

Notez l’économie du dispositif : la recherche hybride, rapide et bon marché, a déjà réduit le corpus entier à une poignée de candidats ; Claude n’arbitre qu’entre ces finalistes — jamais sur le corpus complet.

Le prompt de reranking

Vous etes charge de trouver les documents les plus pertinents
par rapport a la question d'un utilisateur.

<user_question>
Que s'est-il passe avec INC-2023-Q4-011 ?
</user_question>

Voici des documents potentiellement pertinents :
<documents>
<document>Section 10...</document>
<document>Section 2...</document>
</documents>

Renvoyez les 3 documents les plus pertinents, par ordre decroissant de pertinence.

Un prompt d’ingénierie classique : balises XML pour séparer la question des candidats, consigne de sortie explicite. Claude lit chaque document en entier, comprend que la question porte sur un incident précis, et classe en connaissance de cause — y compris sur les cas qui piégeaient les scores, comme les abréviations.

Optimisation : utiliser des IDs

Demander à Claude de renvoyer le texte complet des chunks serait inefficace — des milliers de tokens recopiés à chaque recherche, lentement et à vos frais. Assignez plutôt un ID unique à chaque chunk, puis demandez à Claude de ne renvoyer que ces IDs dans le bon ordre : la réponse tient en une ligne, c’est beaucoup plus rapide, et votre code retrouve les contenus par ID instantanément. Règle générale : quand la sortie d’un LLM référence des données que vous détenez déjà, faites produire des références, jamais des copies.

Implémentation

def reranker_fn(docs, query_text, k):
    joined_docs = "\n".join([
        f"<document><document_id>{doc['id']}</document_id>"
        f"<document_content>{doc['content']}</document_content></document>"
        for doc in docs
    ])

    # Créer le prompt avec la question et les documents
    # Obtenir la réponse de Claude et parser les IDs
    result = chat(messages, stop_sequences=["```"])
    return json.loads(result["text"])["document_ids"]

Chaque candidat est enveloppé avec son identifiant dans des balises dédiées, puis le tout rejoint le prompt. La sortie utilise les techniques d’extraction du début du cours — pré-remplissage et séquence d’arrêt — pour obtenir un JSON nu, immédiatement parsable ; result["text"] est le texte agrégé que renvoie notre fonction chat depuis la boucle à outils, et il contient la liste ordonnée des IDs que la fonction retourne au pipeline.

Compromis

Le reranking a un prix explicite : il augmente la latence — il faut attendre la réponse de Claude à chaque recherche — et ajoute un appel API facturé. En échange, il améliore significativement la précision en exploitant ce qu’aucun score n’offre : la compréhension du contexte et de la pertinence par un modèle qui a réellement lu les candidats. L’arbitrage se fait par application : un assistant documentaire où chaque réponse compte absorbe volontiers la demi-seconde supplémentaire ; une recherche interactive à la frappe, non. L’essentiel est que l’étape reste optionnelle et locale — on l’active ou la retire sans toucher au reste du pipeline.

Points clés à retenir

• Le reranking fait relire les finalistes par Claude — l’ordre final décide de ce qui entre dans le prompt
• La recherche hybride présélectionne à bas coût ; le LLM n’arbitre que la poignée de candidats
• Sortie en IDs, jamais en texte recopié : réponse courte, rapide, économique
• Extraction du classement en JSON via pré-remplissage + séquence d’arrêt
• Compromis latence/coût contre précision : une étape optionnelle, à activer là où la qualité prime