Pourquoi une réponse assurée peut être pire qu'une absence de réponse
Vous terminez la construction du chatbot interne. Vous le nourrissez de chaque politique RH, spécification technique et document d'intégration de votre entreprise. Un nouvel employé pose une question sur la limite de frais de déplacement pour les dîners d'affaires. Le bot répond instantanément. Il semble sûr de lui. La limite qu'il indique est de 75 $ par personne.
La politique réelle indique 50 $. Le bot a inventé la réponse. Il n'a jamais ouvert vos fichiers. Il a simplement deviné, en s'appuyant sur des schémas enfouis dans ses données d'entraînement datant d'il y a des années. C'est la dure réalité de l'utilisation de modèles de langage de grande taille (LLM) bruts sur des documents privés. Ils n'ont pas accès à vos connaissances internes. Lorsque les faits dont ils ont besoin se situent en dehors de leurs poids d'entraînement, ils inventent au lieu d'admettre leur ignorance. En production, cela cesse d'être amusant pour devenir un risque.
La génération augmentée par récupération, ou RAG (Retrieval-Augmented Generation), a été conçue précisément pour résoudre ce problème. Au lieu de demander au modèle de tout mémoriser, vous le laissez effectuer des recherches.
Passer de la supposition à la lecture
Considérez un LLM brut comme un collègue brillant doté d'une mémoire photographique, mais qui aurait quitté votre entreprise avant votre arrivée. Il peut rédiger une prose éloquente, résoudre des énigmes logiques et expliquer des concepts en termes simples. Demandez-lui cependant les changements d'API du dernier trimestre, et il inventera simplement quelque chose qui semble plausible. Il n'a pas d'autre option.
Le RAG donne à ce collègue accès à un classeur. Lorsqu'un utilisateur pose une question, le système ne lance pas la question aveuglément au modèle. Il récupère d'abord les documents pertinents, les insère dans le prompt comme contexte, et seulement ensuite demande au modèle de lire et de répondre. Le modèle passe de la mémorisation de faits à la compréhension de faits qui se trouvent littéralement devant lui.
Ce flux se divise clairement en deux parties : le travail préparatoire hors ligne et la réponse en ligne.
Phase 1 : La phase de préparation (Hors ligne)
Bien avant que quiconque ne tape une question, vous devez transformer votre collection de documents désordonnée en une base de connaissances consultable. Ce travail de fond détermine si votre système RAG prospère ou échoue silencieusement.
Les chargeurs de documents (document loaders) sont votre point de départ. Ces connecteurs extraient le texte brut de PDF, d'espaces de travail Notion, de dossiers SharePoint, de pages web et de wikis internes. C'est ici que la réalité frappe en premier. Un chargeur peut extraire un texte propre d'un document Word, mais échouer sur un PDF scanné qui n'est en fait qu'une image sans couche de texte intégrée. Le chargeur renvoie une chaîne vide, votre base de données ne stocke rien, et votre utilisateur reçoit plus tard une réponse « Je ne sais pas » sans avertissement. Vérifiez toujours ce que vos chargeurs ont réellement extrait. Effectuez des contrôles ponctuels sur une poignée de documents de chaque source avant de faire confiance au pipeline.
Vient ensuite la division de texte (text splitting), également appelée découpage (chunking). Vous ne pouvez pas injecter une politique de sécurité de quatre-vingts pages dans un prompt en un seul bloc ; vous dépasseriez les limites de contexte et noieriez le signal dans le bruit. Au lieu de cela, vous découpez les documents en morceaux (chunks). L'astuce consiste à choisir la bonne taille. Des morceaux trop petits, comme des phrases isolées, perdent souvent un contexte critique. Un morceau lisant « Toutes les demandes doivent être approuvées par le responsable » oublie de mentionner que cette règle ne s'applique qu'aux voyages internationaux. Des morceaux trop grands, comme des chapitres entiers, diluent l'embedding et perturbent la récupération car ils couvrent quinze sujets différents à la fois. En pratique, de nombreuses équipes commencent avec des morceaux compris entre 300 et 500 tokens, avec un chevauchement de 50 tokens afin que les phrases s'étendant sur la coupure ne soient pas déformées. Ajustez cela en fonction de votre contenu. La documentation d'API tolère des morceaux plus petits. Les contrats juridiques nécessitent souvent des morceaux plus grands pour préserver la logique conditionnelle.
Une fois découpé, chaque morceau est converti en un embedding (plongement lexical). Cela signifie que le texte est passé dans un modèle qui produit une liste de nombres, un vecteur, représentant la signification sémantique du morceau. Des idées similaires se retrouvent proches les unes des autres dans cet espace mathématique. « politique de l'abondance 401k » et « règles de contribution à la retraite » seront plus proches l'un de l'autre que « politique de l'abondance 401k » et « configuration de l'imprimante du bureau ». Ces vecteurs sont stockés dans une base de données vectorielle (vector database), telle que Pinecone, Weaviate ou une alternative open-source comme Chroma. Le magasin de vecteurs n'est pas qu'un simple lieu de stockage. C'est un index optimisé pour la recherche de plus proches voisins approximatifs, vous permettant de trouver les morceaux les plus pertinents en quelques millisecondes, même parmi des millions de documents.
Phase 2 : Le chemin en direct (En ligne)
Lorsqu'un utilisateur finit par demander : « Quelle est notre politique de remboursement des frais de déplacement pour les dîners avec les clients ? », le pipeline en temps réel se déclenche.
Le