La génération augmentée par récupération (RAG) est une méthode où un modèle de langage recherche d’abord dans vos propres documents, puis rédige une réponse basée sur ce qu’il a trouvé. Elle surpasse la recherche traditionnelle sur site, les FAQ statiques et les chatbots basés sur des règles lorsque les questions sont variées et que votre contenu est volumineux. Elle perd lorsque les questions sont rares et prévisibles, lorsque les réponses doivent être exactes, ou lorsque votre contenu source est désordonné et obsolète.
Comment fonctionne le RAG en termes simples ?
Un système RAG comporte trois parties. Premièrement, vos documents sont divisés en morceaux et transformés en embeddings, qui sont des représentations numériques du sens, stockées dans une base de données vectorielle ou un index de recherche. Deuxièmement, lorsqu’un utilisateur pose une question, le système trouve les morceaux qui lui sont les plus similaires. Troisièmement, ces morceaux sont transmis à un modèle de langage avec des instructions pour répondre en utilisant uniquement ce matériel.
L’attrait est que le modèle peut répondre à partir d’informations actuelles et privées sur lesquelles il n’a jamais été entraîné, comme vos manuels de produits, documents de politique ou centre d’aide. La réponse peut également citer le document dont elle provient, ce qui facilite la vérification.
Quels sont les outils traditionnels qu’il remplace ?
Avant de comparer, il est utile de nommer ce que la plupart des entreprises utilisent déjà.
- Recherche par mots-clés sur le site, comme la recherche WordPress, Algolia ou Elasticsearch, qui renvoie une liste de pages correspondantes.
- Pages FAQ statiques et centres d’aide construits dans Zendesk, Intercom ou un CMS.
- Chatbots basés sur des règles ou des arbres de décision qui suivent des flux scriptés avec des boutons.
- Agents de support humain travaillant à partir d’une base de connaissances interne.
Chacun de ces outils est moins cher à exploiter et plus facile à prévoir que le RAG. La question est de savoir si vos utilisateurs obtiennent ce dont ils ont besoin grâce à eux.
Quand devriez-vous passer au RAG ?
Le RAG est rentable lorsque l’écart entre ce que les utilisateurs demandent et la façon dont votre contenu est organisé est important. Quelques signes :
Les utilisateurs posent des questions avec leurs propres mots
Si vos journaux de recherche montrent de nombreuses requêtes qui ne renvoient rien ou la mauvaise page, la recherche par mots-clés échoue sur le vocabulaire. Le RAG fait correspondre le sens, donc “puis-je retourner un canapé après deux semaines” trouve la politique de retour même s’il n’utilise jamais le mot canapé.
Les réponses sont réparties dans les documents
Lorsqu’une réponse correcte nécessite une phrase de la garantie, une autre de la page d’expédition et un chiffre d’une fiche produit, une liste de résultats de recherche oblige l’utilisateur à faire l’assemblage. Le RAG peut les combiner.
Votre contenu est volumineux et change souvent
Les bots basés sur des règles ont besoin de quelqu’un pour mettre à jour chaque flux manuellement. Le RAG lit la dernière version de vos documents une fois qu’ils sont réindexés, donc la maintenance passe de l’écriture de scripts au maintien de la correction du contenu source.
Quand ne devriez-vous pas changer ?
Il existe des cas clairs où les outils traditionnels sont le meilleur choix.
Si vos 20 questions principales couvrent la majeure partie de votre trafic, une page FAQ bien rédigée et un bot scripté y répondront plus rapidement, moins cher et sans risque de réponse inventée. Regardez vos tickets de support avant de construire quoi que ce soit.
Si les réponses doivent être exactes et juridiquement contraignantes, comme les taux tarifaires, les dosages de médicaments ou les conditions contractuelles, une paraphrase générée est une responsabilité. Liez plutôt à la page faisant autorité ou affichez le texte source textuellement.
Si vos documents se contredisent, le RAG reflétera la contradiction, choisissant parfois la mauvaise version. Le nettoyage du contenu est un prérequis, pas un extra optionnel.
Et si personne ne possède le contenu, le système se dégradera. Les documents obsolètes dans l’index produisent des réponses obsolètes délivrées avec confiance.
Comment les options se comparent-elles ?
Une vue côte à côte aide lorsque vous présentez la décision aux autres.
- Effort de configuration : page FAQ faible ; recherche par mots-clés faible à moyenne ; bot scripté moyen ; RAG moyen à élevé.
- Coût de fonctionnement : FAQ proche de zéro ; recherche faible ; bot scripté faible ; RAG plus élevé, car chaque réponse appelle un modèle.
- Gestion des formulations variées : FAQ médiocre ; recherche par mots-clés correcte ; bot scripté médiocre ; RAG bon.
- Risque de mauvaises réponses : FAQ faible ; recherche faible ; bot scripté faible ; RAG modéré sans test.
- Maintenance : les FAQ et les bots nécessitent des mises à jour manuelles ; le RAG nécessite un contenu source propre et une réindexation.
À quoi ressemble un projet RAG solide ?
Commencez par l’évaluation, pas par l’architecture. Collectez 50 à 100 questions réelles à partir des journaux de recherche, des tickets de support et des appels de vente, et écrivez la réponse correcte pour chacune. Cet ensemble est la façon dont vous jugerez chaque version du système.
Ensuite, construisez le pipeline le plus simple qui pourrait fonctionner : une option gérée comme la recherche de fichiers d’OpenAI, Google Vertex AI Search, Azure AI Search ou une base de données vectorielle hébergée comme Pinecone avec un modèle courant. Mesurez combien de questions de test il répond correctement et combien il en refuse alors qu’il devrait. N’ajoutez de la complexité, comme le re-ranking ou la recherche hybride mots-clés plus vecteur, que lorsque l’ensemble de test montre un échec spécifique.
Gardez une solution de secours. Lorsque le système n’est pas confiant, il doit le dire et proposer un lien ou un humain, pas deviner.
Comment Alien Road applique le RAG
Dans un engagement typique, nous commençons par un audit de contenu et de questions : nous extrayons les journaux de recherche du site, les thèmes des tickets de support et les documents qui devraient y répondre. De nombreux projets s’arrêtent ici, car l’audit montre que la réécriture de dix réponses FAQ résout la majeure partie du problème. Lorsque le RAG est justifié, nous nettoyons et balisons les documents sources, construisons l’ensemble de questions de test avec l’équipe de support du client et mettons en place un pipeline de récupération géré connecté à un widget de chat ou à un outil interne.
Avant le lancement, le système doit passer le seuil de précision convenu sur l’ensemble de test. Après le lancement, les rapports couvrent les questions répondues et non répondues, les transferts aux humains et les nouvelles questions à ajouter au plan de contenu. Par exemple, l’assistant d’un client e-commerce pourrait répondre aux questions sur la livraison et les retours à partir des pages de politique actuelles, chaque réponse renvoyant à sa source.
Par où commencer cette semaine
Exportez les requêtes de recherche du site et les sujets des tickets de support des trois derniers mois. Regroupez-les par sujet et marquez ceux auxquels vos pages actuelles répondent déjà bien. Si la plupart sont couverts, améliorez d’abord ces pages. Si de nombreuses questions tombent entre les documents ou utilisent des formulations que votre contenu n’a pas, vous avez un cas réel pour le RAG et un ensemble de test prêt à l’emploi pour le construire.
Continuez à lire : Optimisation par IA · Optimisation par IA