Qu'est-ce que le RAG ? La Retrieval-Augmented Generation expliquée pour le Mittelstand
Le RAG couple un modèle de langage à vos propres documents, pour que les réponses restent vérifiables et à jour.
Traduction produite automatiquement par IA. La version allemande est l'original vérifié par la rédaction.
La Retrieval-Augmented Generation, en abrégé RAG, relie un modèle de langage à une collection consultable de vos propres documents. Plutôt que de produire la réponse à partir du seul savoir d'entraînement, le système recherche d'abord les passages pertinents dans vos données et formule la réponse à partir d'eux. Pour le Mittelstand, c'est la manière la plus pratique d'appliquer un modèle de langage à son propre savoir, sans réentraîner un modèle et sans que les documents internes ne quittent votre infrastructure.
Cet article explique ce qu'est le RAG, comment une pipeline est construite, pourquoi le retriever est généralement plus important que la taille du modèle et quand l'effort en vaut la peine.
01. Le problème que le RAG résout
Un modèle de langage généraliste ne connaît pas vos documents internes. Il a été entraîné sur des données publiques et s'arrête à une date de coupure. Si un collaborateur demande quelle est l'entente de livraison actuelle avec un fournisseur précis, le modèle a deux possibilités : il dit qu'il ne connaît pas la réponse, ou il en invente une qui sonne plausible. La seconde possibilité est la dangereuse.
Le RAG comble cette lacune. Avant chaque réponse, le système parcourt vos propres sources, par exemple des contrats, des manuels, des tickets ou un wiki, et transmet les passages pertinents au modèle. Le modèle formule alors une réponse qui repose sur ces passages précis et peut les citer. D'un modèle qui doit deviner, on passe à un système qui va consulter. Nous avons décrit l'intérêt commercial plus large dans Discover the Potential of AI in Business.
02. Comment fonctionne une pipeline RAG
Une pipeline RAG comprend cinq étapes qui se séparent proprement les unes des autres.
- Indexation. Vos documents sont découpés en petits passages et traduits en vecteurs numériques qui représentent leur sens. Ces vecteurs résident dans une base de données vectorielle.
- Récupération. Pour une question, le système calcule le vecteur correspondant et va chercher les passages les plus similaires dans la base. C'est ici que se joue la qualité de la réponse ultérieure.
- Augmentation. Les passages trouvés sont placés, avec la question, dans le prompt du modèle.
- Génération. Le modèle formule la réponse à partir du contexte fourni, pas de sa mémoire.
- Citation des sources. Le système nomme les documents dont provient la réponse, afin qu'un humain puisse les vérifier.
Le troisième point de séparation est important : vous pouvez changer de modèle sans retraiter vos données, et vous pouvez mettre à jour vos données sans toucher au modèle.
03. Pourquoi le retriever est souvent plus important que la taille du modèle
Dans la pratique, l'essentiel de l'énergie va au choix du modèle. D'après notre expérience, le levier se trouve plus souvent du côté du retrieval. Nous avons posé la même question métier à un grand modèle hébergé et à un modèle local plus petit doté d'un retriever soigneusement réglé. Sur les questions sans ambiguïté, les deux étaient à égalité. Sur les cas ambigus, c'est-à-dire la minorité qui compte vraiment, c'est la qualité du retrieval qui a décidé de la réponse utilisable, pas la taille du modèle.
La raison est simple : un modèle plus grand ne fait que formuler une réponse fausse avec plus d'éloquence lorsqu'il lui manque le bon passage. Un retriever bien réglé fournit en revanche le passage pertinent, et un modèle plus petit suffit alors. Nous avons décrit plus en détail la même observation dans notre article précédent sur la Retrieval-Augmented Generation.
04. Le RAG, la protection des données et le cas on-premise
Le RAG s'accorde bien avec une architecture respectueuse de la protection des données, car tous les composants peuvent être exploités en interne. Le retriever, la base de données vectorielle et le modèle peuvent tourner on-premise, de sorte que ni la question ni les documents trouvés ne partent vers un service externe. Pour les entreprises qui travaillent avec des données personnelles, des contrats ou des documents de conception, c'est souvent la condition pour qu'un projet démarre.
Quel modèle convient au fonctionnement local et avec quel matériel, nous le traitons dans Lokales LLM im Unternehmen: Hardware, Kosten, Realität. L'arbitrage de fond entre fonctionnement local et cloud figure dans On-Premise vs. Cloud-LLM: Wann lokale KI die richtige Wahl ist.
05. Quand le RAG en vaut la peine et quand il n'en vaut pas la peine
Le RAG en vaut la peine lorsque votre savoir réside dans des documents, change régulièrement et est interrogé par de nombreuses personnes. Les cas typiques sont les bases de connaissances internes, le support, l'examen des offres et la recherche dans la documentation technique.
Le RAG en vaut moins la peine lorsque la réponse est un calcul exact issu d'une base de données, car une requête classique est alors plus précise. Il ne remplace pas non plus une gestion soignée des données : si les documents sources sont contradictoires ou obsolètes, même un bon retrieval fournira des réponses contradictoires. La première étape d'un projet RAG est donc le plus souvent l'examen honnête du savoir existant, pas le choix du modèle.
