Traitement des requêtes et reranking

Regarder la vidéo

1 · La compétence

Choisissez q24, q46, q52 ou q63 et formulez une seule hypothèse sur la normalisation de la requête qui pourrait corriger le problème — c’est la technique que vous pouvez réellement tester en conditions réelles contre cette pile de démonstration, à la section 2. Le réordonnancement et la déduplication sont présentés séparément ci-dessous, et de façon plus honnête que d’habitude : ce sont de vrais morceaux de code dans cette base, mais aucun des deux ne fonctionne comme son nom le laisse supposer, et cet écart mérite d’être compris avant de faire confiance à l’un ou l’autre en production.

• Normalisation de la requête : transformer une question utilisateur en plusieurs formes recherchables — la question brute, les identifiants de documents qu’elle contient, les acronymes développés ou les termes traduits.
• Réordonnancement : un vrai service de réordonnancement existe dans cette base de code (aperag/llm/rerank/rerank_service.py, aperag/flow/runners/rerank.py) — il encode même une politique de repli documentée selon laquelle les résultats du graphe sont de « meilleure qualité » et doivent être priorisés en premier. Mais rien dans le chemin de récupération réellement emprunté par /api/v1/search pour cette démonstration (qa_service.py, search.py) ne l’appelle jamais. La récupération vous donne aujourd’hui une première sélection approximative, un point c’est tout — il n’y a aucune étape de réordonnancement ensuite. Avant de faire confiance au réordonnancement en production, il faudrait vérifier : cette politique de repli correspond-elle à vos propres priorités, quelle latence l’appel de réordonnancement ajoute-t-il, et que devient la réponse si cet appel échoue lui-même ?
• Déduplication : également plus limitée que son nom ne le laisse entendre. Aujourd’hui, la déduplication ne s’applique qu’à la liste des citations affichées à l’utilisateur, par correspondance de nom de fichier. Le texte des fragments réellement placé dans le contexte du prompt du LLM n’est jamais dédupliqué — deux fragments qui se chevauchent, issus du même document, peuvent tous deux entamer votre budget de preuves même si une seule citation apparaît finalement à l’écran.

Lecture principale : Learning to Rank avec Elasticsearch

2 · Exécuter la boucle de preuve

cd demo
python3 eval.py run --mode retrieval --workspace meridian_demo --category reference_lookup --tag lesson-08-baseline

Notez la source attendue, si la base de référence l’a effectivement fait apparaître, la variante de requête testée et l’évolution du même indicateur ensuite.

Augmenter top-k ne fait qu’enfouir un échec de récupération sous davantage de bruit : cela n’indique pas ce qui s’est réellement passé.

3 · Fiche de décision

4 · Exercice de récupération

5 · Livrable et prochaine action

1. Conservez une copie de la sortie de commande ou du rapport.
2. Complétez la fiche de décision.
3. Notez un cas d’échec et ce que vous vérifierez ensuite.

Une fiche d’expérience de récupération réfutable : hypothèse, indicateur, référence, contrôle de régression et condition d’arrêt, tous explicitement définis.

Prochaine étape : leçon 9 — assemblage du contexte et budgets de preuves.

Posez-moi vos questions sur les preuves, l’indicateur, le cas d’échec ou l’expérience que vous souhaitez tenter ensuite. Je suis votre enseignant pour cette formation : n’hésitez pas.