Améliorer les réponses RAG : une modification mesurée à la fois

Il est facile de mettre en place une première pipeline RAG : charger des documents, les incorporer, stocker leurs vecteurs, récupérer quelques extraits et les transmettre à un LLM. Le processus fonctionne, mais les réponses sont souvent fausses, même lorsque le document contient clairement les informations correctes. Dans la plupart de ces cas, le modèle n’est pas la cause ; l’étape de récupération ne lui a jamais fourni le contexte adéquat. Ce guide présente les paramètres de récupération qui ont généralement le plus d’impact et, ce qui est encore plus important, une méthode structurée pour déterminer lesquels d’entre eux aident réellement votre système.

Considérez d’abord les mauvaises réponses comme des problèmes de récupération

Au lieu de modifier les prompts ou les modèles, vérifiez ce qui a été récupéré pour une question qui échoue. Si le passage pertinent fait défaut dans le contexte, aucune adaptation des prompts ne pourra corriger la réponse.

Découpez en extraits selon des limites significatives

La taille des blocs a un effet surprenantement important sur la qualité de la récupération. Les blocs trop grands mélangent plusieurs sujets, ce qui rend leurs embeddings vagues et les amène à inclure du texte non pertinent. Les blocs trop petits séparent des phrases de leur contexte qui leur confère un sens. Plutôt que de diviser aveuglément tous les 500 caractères, conservez les paragraphes ou sections liés ensemble, et utilisez les titres ainsi que les sauts de paragraphe comme points de séparation naturels.

Ajustez top_k plutôt que de le deviner

De nombreux pipelines récupèrent les cinq extraits les plus similaires simplement parce que c’est une valeur par défaut courante. Cependant, le passage pertinent peut se trouver à la sixième ou septième position. Augmenter la valeur de top_k peut améliorer le taux de rappel, mais chaque extrait supplémentaire ajoute également du bruit et des tokens au prompt. Considérez top_k comme un paramètre à tester en fonction de vos propres questions, et non comme une valeur constante à copier. Les seuils de pertinence constituent une autre option, abordée dans aller au-delà de top-k avec des seuils, recherche hybride et réclassement.

Ajouter une étape de réclassement

La recherche vectorielle est rapide mais peu précise : elle excelle à trouver des candidats plausibles, mais est moins efficace pour déterminer lequel est véritablement le meilleur. Un module de réclassement effectue une deuxième étape. D’abord, la recherche vectorielle renvoie un ensemble plus large, par exemple dix fragments. Ensuite, un modèle de réclassement, généralement un encodeur croisé qui lit la requête ainsi que chaque fragment ensemble, les évalue et conserve les trois ou quatre meilleurs. Le modèle dispose ainsi d’un contexte plus clair, au prix d’une latence supplémentaire et d’un coût par requête plus élevé.

Combiner la recherche sémantique et celle par mots-clés

Les embeddings capturent bien le sens, mais parfois les tokens exacts ont plus d’importance que le sens. Une requête telle que ERROR_CODE_4291 ne contient que peu de contenu sémantique, si bien que la recherche par similarité peut manquer le seul document qui en fait mention. La classification par mots-clés, comme BM25, gère bien ce cas. De nombreux systèmes utilisent donc à la fois une recherche vectorielle et une recherche par mots-clés, puis fusionnent les résultats, une approche connue sous le nom de recherche hybride.

Compléter le manque de vocabulaire dans les requêtes

Les utilisateurs formulent rarement leurs questions de la même manière que les documents sont rédigés. Quelqu’un peut demander pourquoi un paiement échoue, tandis que la page correspondante parle d’un échec d’autorisation de carte. La réécriture des requêtes, MultiQuery (génération de plusieurs formulations et récupération pour chacune) et HyDE (génération d’une réponse hypothétique et recherche à l’aide de son embedding) peuvent toutes combler ce manque. Cependant, elles ajoutent des appels à des LLM et une certaine complexité, il convient donc de les utiliser uniquement après avoir essayé les méthodes plus simples mentionnées ci-dessus.

Évaluer chaque changement par rapport à une référence

L’habitude la plus importante est de refuser de supposer. « Nous avons ajouté un réclassement, donc la récupération est meilleure » n’est qu’une hypothèse tant qu’elle n’a pas été mesurée. Créez un petit ensemble de questions réelles accompagnées de passages pertinents connus, puis suivez des indicateurs tels que :

• Recall@K : la question de savoir si les informations correctes apparaissent parmi les K premiers extraits récupérés.

Précision du contexte : quelle partie du contexte obtenu était réellement utile.

Fidélité : la réponse reste-t-elle ancrée dans le contexte obtenu ?

Rélevance de la réponse : la réponse répond-elle à la question posée ?

Enregistrez d’abord une valeur de référence. Dans un exemple, cela pourrait ressembler à ceci :

Baseline Recall@5: 68%

Ensuite, apportez un changement à la fois, relancez les mêmes questions et enregistrez chaque résultat. Une série d’améliorations pourrait ressembler à ceci :

Better chunking: 74%
Hybrid search: 82%
Reranking: 89%

Ces chiffres sont un exemple, pas une référence de performance ; vos propres données se comporteront différemment. L’idée est qu’un journal des changements vous indique quelles étapes ont entraîné une complexité accrue et lesquelles non. Pour en savoir plus sur la détection des échecs, consultez l’évaluation de RAG par étape d’échec.

Conclusion

Partez du pipeline le plus simple : de la requête à la récupération des données, en passant par le contexte et l’LLM, puis améliorez une étape à la fois : apportez un changement, mesurez ses effets, évaluez sa latence et son coût, puis répétez l’opération. Un système RAG modeste que vous comprenez et pouvez mesurer vaut généralement plus qu’un système complexe rempli de techniques que personne ne peut justifier par des chiffres.