Réécriture des requêtes et HyDE

La qualité de la récupération est limitée par la requête. Les requêtes brutes des utilisateurs sont souvent courtes, ambiguës, pleines de pronoms ou formulées différemment des documents. La transformation de requête remodèle la requête avant la récupération afin d’améliorer le rappel et la précision.

C’est l’une des améliorations les moins coûteuses et les plus efficaces par rapport à un RAG naïf : corrigez la requête et toutes les étapes en aval en bénéficieront.

Il s’agit de la transformation la plus simple : un LLM réécrit la requête de l’utilisateur sous une forme plus claire, autonome et adaptée à la récupération. Il corrige les fautes de frappe, développe les abréviations et supprime le bruit conversationnel.

C’est particulièrement important dans une conversation à plusieurs tours, lorsque le dernier message est incompréhensible sans contexte (Et le deuxième ?).

Dans un RAG conversationnel, condensez le dialogue et le nouveau tour en une seule question autonome. Sans cette étape, les pronoms et les ellipses rendent la représentation vectorielle dépourvue de sens et la récupération s’effondre.

Transmettez les tours précédents afin que le réécrivain puisse convertir « cela », « celui-là » et « le précédent » en entités explicites que le moteur de récupération pourra retrouver.

L’expansion génère des synonymes, des termes associés ou des formulations différentes afin d’élargir la couverture lexicale et sémantique. Elle lutte contre le décalage de vocabulaire : le document dit « invalider », tandis que l’utilisateur dit « révoquer ».

Développez la requête pour la récupération, puis récupérez avec l’union des résultats ; n’affichez pas la forme développée à l’utilisateur. Méfiez-vous de l’expansion excessive, qui peut faire remonter des résultats hors sujet.

Générez plusieurs reformulations différentes, récupérez des résultats pour chacune, puis fusionnez les listes de résultats (fusion des rangs réciproques). Des formulations différentes font apparaître des segments pertinents différents ; la fusion combine leurs points forts et stabilise le rappel.

Cette méthode échange des appels de récupération supplémentaires contre une meilleure robustesse face à une formulation défaillante unique.

Les questions complexes à plusieurs étapes nécessitent une décomposition en sous-questions, chacune étant récupérée séparément avant d’être combinée. Demander quel CEO de l’entreprise ayant acquis X est plus âgé que... ne peut pas être résolu par une seule récupération.

Décomposez la question, récupérez les résultats pour chaque sous-question et laissez le générateur combiner les éléments de preuve rassemblés.

HyDE (représentations vectorielles de documents hypothétiques, Gao et al., 2022) inverse le problème. Au lieu de représenter vectoriellement la courte requête, il demande au LLM de générer un document-réponse hypothétique, puis représente celui-ci vectoriellement et l’utilise pour la récupération.

Le document hypothétique emploie le même registre que les documents réels. Sa représentation vectorielle est donc plus proche de celles des véritables réponses, ce qui corrige le décalage entre la requête et le document.

Une question et sa réponse sont formulées différemment ; une question et une réponse fausse mais plausible sont formulées de manière similaire à la véritable réponse. HyDE exploite l’a priori génératif du LLM pour combler cet écart, même si le contenu hypothétique comporte des erreurs factuelles.

L’exactitude du document hypothétique importe peu : celui-ci doit seulement avoir le vocabulaire et la structure adéquats pour se situer près des vrais documents dans l’espace des représentations vectorielles.

HyDE ajoute une génération par LLM avant la récupération, ce qui augmente la latence et les coûts, et peut halluciner un contenu hypothétique qui s’écarte du sujet. Cela nuit au rappel pour les requêtes de niche ou hors distribution, sur lesquelles le modèle ne dispose d’aucune connaissance.

Atténuez ce risque en combinant la récupération par vecteur HyDE avec la récupération à partir de la requête brute au moyen d’une fusion, afin qu’un mauvais contenu hypothétique ne puisse pas faire chuter complètement le rappel.

Ces transformations sont complémentaires. Utilisez la condensation pour les conversations, l’expansion et les requêtes multiples pour combler les lacunes de vocabulaire, la décomposition pour les questions à plusieurs étapes et HyDE en cas de décalage de registre entre la question et le document. De nombreuses architectures de production enchaînent la condensation, puis HyDE, puis la fusion avec la requête brute, avant le réordonnancement.

Chaque transformation supplémentaire coûte un appel à un LLM ; activez-les donc selon le type de requête plutôt que de les exécuter systématiquement toutes.

Mesurez chaque transformation en fonction de son gain en rappel@k de la récupération et en exactitude de la réponse finale par rapport à la requête brute, sur un ensemble exempt de fuites. Suivez la latence ajoutée et le coût des LLM afin de ne conserver que les transformations qui sont rentables.

Attention : une transformation qui améliore le rappel tout en ajoutant des éléments distrayants peut réduire l'exactitude de la réponse, sauf si elle est associée à un réordonnancement et à une compression.

Points essentiels :

• La récupération est limitée par la requête ; la transformer constitue une mise à niveau RAG peu coûteuse et à fort effet de levier.
• La réécriture et la condensation rendent les requêtes de conversation autonomes ; l'expansion et les requêtes multiples comblent les lacunes de vocabulaire.
• La décomposition traite les questions à sauts multiples en récupérant des résultats pour chaque sous-question.
• HyDE intègre une réponse hypothétique pour combler le décalage de registre entre la question et le document ; l'exactitude de l'hypothèse n'est pas requise.
• Combinez les transformations selon le type de requête, fusionnez-les avec la requête brute pour plus de robustesse, puis évaluez le rappel, l'exactitude de la réponse, la latence et le coût.