Interroger, récupérer et générer

Le pipeline de requête constitue la partie en ligne de RAG : c'est le code qui s'exécute en temps réel lorsqu'un utilisateur pose une question. Il relie tous les composants créés lors de l'indexation : le modèle de représentation vectorielle, le magasin de vecteurs, le modèle de prompt et le LLM. Un pipeline de requête correctement implémenté s'exécute en moins de 500 ms pour la plupart des charges de travail et produit des réponses étayées et accompagnées de citations. Dans cette leçon, nous construisons chaque étape à partir de zéro.

La première étape consiste à convertir la question formulée en langage naturel par l'utilisateur en une représentation vectorielle à l'aide du même modèle que celui utilisé lors de l'indexation. Cette représentation encode le sens sémantique de la question et sera comparée aux représentations vectorielles des segments de documents dans le magasin de vecteurs. Veillez à ce que cette étape soit rapide : utilisez un modèle léger comme text-embedding-3-small et mettez en cache les représentations des requêtes identiques répétées.

Envoyez le vecteur de requête au magasin de vecteurs afin de trouver les K segments les plus similaires sur le plan sémantique. Les correspondances renvoyées sont classées selon un score de similarité cosinus (généralement compris entre 0,0 et 1,0 ; plus le score est élevé, meilleur est le résultat). La valeur idéale de K établit un équilibre entre la richesse du contexte et le coût de la fenêtre de contexte : K=5 constitue un point de départ courant. Vous pouvez également appliquer ici des filtres de métadonnées pour limiter la récupération à un service, un type de document ou une plage de dates précis.

Les segments récupérés ne sont pas tous réellement pertinents : certains peuvent avoir de faibles scores de similarité tout en figurant parmi les K premiers parce que la requête se situe en dehors de la couverture de l'index. Appliquez un seuil de score minimal pour éliminer les correspondances peu fiables. Si tous les segments récupérés sont sous ce seuil, renvoyez une réponse indiquant qu'aucune information n'a été trouvée plutôt que d'envoyer un contexte non pertinent au LLM, ce qui produirait une réponse moins bonne qu'un refus formulé correctement.

Assemblez les segments récupérés dans un bloc de contexte structuré que le LLM pourra lire. Étiquetez chaque segment avec sa source afin que le modèle puisse le citer correctement. Ajoutez un séparateur entre les segments pour améliorer la lisibilité. Maintenez le contexte total dans les limites de votre budget de jetons : comptez les jetons avec tiktoken et tronquez ou supprimez les segments ayant les scores les plus faibles si vous dépassez la limite. Le bloc de contexte est inséré dans le prompt entre l'instruction système et la question de l'utilisateur.

Combinez le bloc de contexte, l'instruction système et la question de l'utilisateur dans le prompt final. Le message système indique au modèle d'utiliser uniquement le contexte fourni et de citer ses sources. Le message utilisateur contient le contexte mis en forme, suivi de la question. Cette séparation claire empêche le modèle de mélanger le contenu du contexte avec la question et rend la frontière entre les données récupérées et la saisie de l'utilisateur parfaitement explicite.

Envoyez le prompt assemblé au LLM à l'aide de l'API Chat Completions. Utilisez une température basse (de 0,0 à 0,3) pour les questions-réponses factuelles afin d'obtenir des réponses cohérentes et étayées. Des températures plus élevées produisent des réponses plus créatives, mais augmentent le risque que le modèle ajoute des informations absentes du contexte. Analysez la réponse et renvoyez à la fois le texte de la réponse et les sources récupérées afin que votre application puisse afficher les citations à l'utilisateur.

Le pipeline de requête complet exécute ces étapes dans l'ordre. Chaque étape est une fonction pure que vous pouvez tester indépendamment, et les données circulent proprement d'une étape à la suivante. L'ajout d'une journalisation à chaque étape rend le pipeline observable : vous pouvez voir précisément quels segments ont été récupérés, quel était leur score, comment le contexte a été assemblé et combien de jetons ont été utilisés. Cette visibilité est essentielle pour déboguer le système et améliorer la qualité de la récupération.

Le pipeline de requête comporte deux étapes limitées par les entrées-sorties : l'appel de représentation vectorielle et l'appel au LLM. Exécutez-les sans attentes inutiles : l'appel de représentation vectorielle est rapide (<100 ms), tandis que l'appel au LLM est lent (500 ms à 3 s). Pour réduire la latence perçue, diffusez la réponse du LLM en continu afin que les jetons apparaissent au fur et à mesure de leur génération, au lieu d'attendre la réponse complète. Mettez en cache la représentation des requêtes identiques répétées pour éviter les appels d'API redondants.

Les pipelines RAG utilisés en production ont besoin d'une journalisation structurée afin que vous puissiez diagnostiquer les échecs de récupération ou les mauvaises réponses du LLM. Journalisez pour chaque requête la requête, les ID et les scores des segments récupérés, le nombre de jetons du contexte, la réponse et la latence. Stockez ces journaux dans une base de données ou une plateforme d'observabilité. Lorsque des utilisateurs signalent de mauvaises réponses, vous pouvez rejouer la requête exacte et examiner quels segments ont été récupérés et pourquoi ils étaient insuffisants.

Si votre application reçoit de nombreuses requêtes répétées ou presque identiques — par exemple dans des robots FAQ où les utilisateurs posent souvent les mêmes questions — la mise en cache des représentations de requêtes constitue une optimisation simple et très efficace. Calculez une empreinte de la chaîne de requête, recherchez la représentation correspondante dans un cache Redis et n'appelez l'API de représentation vectorielle qu'en cas d'absence dans le cache. Dans les robots FAQ et d'assistance utilisés en production, les taux d'accès au cache des représentations atteignent couramment 30 à 60 %, ce qui élimine une part importante des coûts d'API et réduit la latence de 50 à 100 ms par requête mise en cache.

Vérifiez votre compréhension des concepts d'ingénierie de l'IA présentés dans cette leçon.

Dans cette leçon, vous avez appris les six étapes du pipeline de requête (vectoriser la requête, récupérer les segments, filtrer selon le score, mettre en forme le contexte, créer le prompt, générer la réponse), le filtrage selon un seuil de score pour gérer les requêtes situées en dehors de la couverture de l'index, ainsi que les améliorations destinées à la production, notamment la diffusion continue des réponses, la journalisation structurée et l'optimisation de la latence. Nous allons maintenant apprendre à évaluer si votre système RAG complet fonctionne réellement correctement.