Brancher un modèle de langage sur les documents de l’entreprise paraît simple. Un utilisateur pose une question, le système retrouve quelques passages et rédige une réponse. La démonstration fonctionne parfois dès le premier jour. L’exploitation révèle ensuite les difficultés : contrat périmé, tableau mal extrait, document interdit ou réponse assurée malgré une information absente.
Le RAG, pour retrieval-augmented generation, combine recherche d’informations et génération. Il peut fournir au modèle un contexte adapté à la question sans intégrer toutes les connaissances dans ses paramètres. Mais il ne transforme pas automatiquement une bibliothèque désordonnée en source fiable. La qualité de la réponse dépend de toute une chaîne, depuis le document d’origine jusqu’à l’autorisation de l’utilisateur.
En bref — Commencez par un usage limité et un corpus maîtrisé. Préservez les versions, les métadonnées et les droits. Évaluez séparément la récupération des passages et la réponse finale. Une citation ne prouve pas que l’affirmation est correcte ; l’extrait doit réellement la soutenir. Le système doit savoir signaler une information absente ou contradictoire.
Le bon cas d’usage possède une question et une autorité
« Répondre à toutes les questions de l’entreprise » ne constitue pas un premier périmètre réaliste. Cherchez une tâche dont la réponse existe dans un corpus identifié : retrouver une procédure d’assistance, expliquer une règle interne validée ou préparer une réponse à partir d’un catalogue technique.
Le document faisant autorité doit être identifiable. Deux fichiers portant le même titre peuvent contenir des règles différentes, valables à des dates ou pour des populations distinctes. Le système doit disposer de cette information, plutôt que laisser le modèle décider quelle version paraît la plus plausible.
Définissez également ce que l’assistant ne doit pas faire. Retrouver une procédure n’équivaut pas à autoriser une opération sensible. Résumer un contrat ne remplace pas une décision juridique. Si la réponse déclenche une action, la chaîne d’autorisation et de validation dépasse le simple RAG.
Le cahier des charges à critères vérifiables est utile pour exprimer ces limites : questions couvertes, documents utilisés, droits attendus, délais de mise à jour et comportement en cas d’incertitude. Vous obtenez alors des critères de recette, pas seulement une promesse de conversation naturelle.
Préparer les documents avant de chercher des vecteurs
L’ingestion commence par l’identification des sources, de leurs propriétaires et de leurs dates. Inventoriez les formats : pages, fichiers bureautiques, PDF, tableaux, scans et tickets. Un PDF texte et une page numérisée ne demandent pas le même traitement. Une extraction incorrecte peut sembler lisible tout en inversant des colonnes ou en séparant un montant de sa condition.
Conservez un identifiant stable du document, un identifiant de version et une empreinte permettant de repérer les modifications. Ajoutez au minimum titre, origine, propriétaire, langue, statut, date d’effet lorsque nécessaire et référence permettant de retourner au document. Ces métadonnées deviennent des éléments de recherche et de contrôle.
Les documents obsolètes demandent une politique explicite. Certains doivent rester consultables pour répondre à des questions historiques ; d’autres ne devraient plus être proposés pour une décision actuelle. Une date de fichier ne suffit pas toujours à déterminer la validité métier. Un responsable du corpus doit pouvoir confirmer le statut.
Prévoyez les suppressions dès le début. Retirer le fichier d’un dossier ne supprime pas automatiquement ses fragments, vecteurs, caches, journaux ou copies de travail. La chaîne doit savoir propager la suppression et vérifier sa prise en compte. La rapidité de cette propagation devient particulièrement importante pour les données confidentielles ou les changements de droits.
Découper sans perdre les conditions
Le chunking divise les documents en passages utilisables par la recherche et le modèle. Une taille arbitraire appliquée partout peut séparer une règle de son exception. Un passage trop grand dilue la recherche et occupe le contexte ; un passage trop petit manque de sens.
Commencez par les structures du document : titres, sections, listes et tableaux. Un fragment relatif à un délai doit conserver l’objet concerné et les conditions qui changent ce délai. Un tableau doit rester associé à son en-tête, à son unité et, si elle est pertinente, à sa note de bas de page.
Un chevauchement entre fragments peut préserver la continuité, mais il augmente le volume et les doublons. Il doit être évalué sur des questions concrètes. Le nombre de caractères ou de tokens n’est pas un objectif métier ; la récupération d’une information complète l’est.
Dans une simulation documentaire, la phrase « intervention sous 24 heures » n’est correcte que pour des incidents bloquants reçus pendant la plage de service. Un fragment contenant seulement la durée produit une réponse trompeuse. L’assistant peut citer honnêtement ce fragment et pourtant donner une instruction inexacte, car l’extraction a déjà perdu les conditions.
Une recherche hybride répond à des besoins différents
La recherche vectorielle utilise des représentations numériques pour retrouver des contenus sémantiquement proches. Elle peut rapprocher une question et un passage qui n’emploient pas les mêmes mots. Cette propriété aide sur des formulations naturelles, mais ne garantit pas le bon résultat pour un code produit, une référence de contrat ou un nom précis.
La recherche lexicale reste donc utile. Une recherche hybride combine des signaux lexicaux et vectoriels ; un mécanisme de fusion ou de classement organise ensuite les résultats. Selon la solution retenue, un reclassement supplémentaire peut affiner l’ordre des passages.
Ces étapes ajoutent des coûts et de la latence. Elles doivent améliorer une mesure de pertinence, pas simplement enrichir un schéma d’architecture. Comparez les réponses à des questions métier avec une recherche lexicale seule, une recherche vectorielle seule et une combinaison. Certains corpus très structurés demandent surtout de bons filtres.
Les filtres par produit, version, langue, région ou période réduisent les confusions. Ils peuvent provenir du contexte applicatif ou d’un choix explicite de l’utilisateur. Une interprétation automatique de la question doit rester testable : si elle choisit le mauvais produit avant la recherche, le meilleur classement ne sauvera pas la réponse.
Renvoyez au modèle un ensemble de passages limité et pertinent. Empiler tout ce qui ressemble vaguement à la question augmente les contradictions et les coûts. Un score de proximité élevé n’est pas une probabilité universelle de vérité ; ses seuils se règlent sur le corpus et la méthode utilisés.
Les droits doivent agir avant que le contenu arrive au modèle
La recherche doit respecter l’identité de l’utilisateur, son organisation et ses autorisations actuelles. Les permissions du document doivent être propagées aux fragments et appliquées à la sélection. Un passage interdit ne devrait pas entrer dans le contexte pour être ensuite censuré par une consigne.
Les environnements multi-clients exigent une séparation explicite des données. Un filtre oublié sur une requête, un cache partagé ou une référence réutilisée peut traverser cette séparation. Testez le cas d’un utilisateur autorisé dans un espace et interdit dans un autre, puis celui d’un droit retiré après une première consultation.
Le cache mérite une attention particulière. Une réponse construite pour une personne ne doit pas être servie à quelqu’un d’autre uniquement parce que les questions se ressemblent. Sa clé et sa politique de validité doivent tenir compte du périmètre d’autorisation, des versions et des règles de conservation.
Les documents constituent aussi une entrée non fiable. Un passage peut contenir une instruction visant à détourner le modèle. Le système doit traiter ce texte comme une donnée à examiner, pas comme une consigne supérieure aux règles de l’application. Cette précaution devient plus importante encore si l’assistant possède des outils capables d’écrire, d’envoyer ou de modifier des informations.
L’isolation des contenus, le contrôle des sources et la restriction des actions possibles réduisent le risque. Une phrase dans le prompt demandant d’ignorer les instructions malveillantes ne remplace pas ces contrôles techniques. Les droits sont une propriété de l’application, pas une opinion du modèle.
Mesurer deux étapes au lieu d’un sentiment général
Constituez un jeu de questions représentatives, avec les sources attendues et les éléments nécessaires à une bonne réponse. Incluez les formulations courtes, ambiguës, les références exactes, les tableaux et les informations absentes. Une personne compétente sur le métier doit pouvoir juger le résultat.
Évaluez d’abord la récupération : les passages nécessaires se trouvent-ils dans les résultats proposés au modèle ? Puis évaluez la génération : la réponse utilise-t-elle correctement ces passages, conserve-t-elle les conditions et évite-t-elle les affirmations non soutenues ? Sans cette séparation, vous ne saurez pas où corriger l’erreur.
Dans un exemple fictif, 100 questions possèdent une réponse dans le corpus. Pour 82 d’entre elles, le contexte contient les informations utiles. Soixante-dix réponses finales sont acceptables. Le taux global est de 70 %. Sur les questions dont la récupération est satisfaisante, le taux de réponse acceptable est de 70 ÷ 82, soit environ 85,37 %.
Ce diagnostic montre deux familles de travail. Améliorer seulement le modèle ne résoudra pas les dix-huit questions dont le bon contexte manque. Modifier uniquement la recherche ne corrige pas toutes les erreurs de synthèse. Ajoutez un groupe de questions sans réponse attendue pour évaluer la capacité à s’abstenir, séparément de ce premier groupe.
| Risque | Test utile | Attendu à définir |
|---|---|---|
| Document absent | Question volontairement hors corpus | Information manquante signalée |
| Versions contradictoires | Ancienne et nouvelle règle présentes | Version applicable identifiée |
| Source interdite | Même question avec deux profils | Aucun contenu non autorisé |
| Tableau complexe | Valeur avec condition et unité | Ensemble correctement restitué |
| Injection documentaire | Instruction hostile dans un passage | Règles applicatives conservées |
Une citation doit être cliquable dans l’application interne lorsque les droits l’autorisent, mais son existence ne suffit pas. Le passage cité doit soutenir l’affirmation concernée. Vérifiez les références au niveau des phrases importantes, pas uniquement le nombre de documents listés.
Calculer le coût par réponse utilisable
La facture de génération n’est qu’une partie du coût. Ajoutez ingestion, OCR éventuel, calcul des embeddings, stockage, recherche, reclassement, supervision et temps de vérification. Les volumes de mise à jour peuvent peser davantage que les consultations dans certains projets.
Voici une simulation tarifaire fictive, sans lien avec une offre commerciale. Une requête comporte 600 tokens de consignes et de question, puis quatre passages de 500 tokens : 2 600 tokens en entrée. La réponse contient 400 tokens. Avec des hypothèses de 2 euros par million de tokens entrants et de 8 euros par million sortant, la génération coûte 0,0052 + 0,0032 = 0,0084 euro par demande.
Dix mille demandes représenteraient 84 euros de génération dans cette hypothèse. Ce montant ne finance ni le reste de l’architecture ni le travail humain. Il ne dit pas non plus combien de réponses sont effectivement utiles. Si la vérification prend plusieurs minutes, elle peut dominer l’économie du service.
Mesurez donc coût complet, latence et qualité sur les mêmes catégories de questions. Un modèle moins coûteux mais nécessitant davantage de corrections peut perdre son avantage. Le calcul du retour sur investissement doit distinguer temps disponible, économies encaissables et coût supplémentaire de contrôle.
Passer du pilote à un service entretenu
Un RAG en production possède un responsable du corpus, un responsable technique et une procédure de remontée des erreurs. L’utilisateur doit pouvoir signaler une mauvaise réponse avec son contexte, sans que le journal collecte inutilement des informations sensibles.
Versionnez les composants qui modifient le résultat : corpus, découpage, recherche, prompt et modèle. Rejouez le jeu de tests à chaque modification significative. Conservez une possibilité de retour à une version connue et une manière de suspendre une source problématique.
La mise à jour des documents devrait être surveillée comme une opération de production. Un connecteur en panne peut laisser l’assistant répondre à partir d’une version ancienne pendant des semaines. Afficher une date de synchronisation aide, mais ne remplace pas une alerte lorsqu’un délai acceptable est dépassé.
Avant l’ouverture à un nouveau service, vérifiez les termes métier qu’il utilise. La même abréviation peut désigner un produit, une équipe ou une procédure selon le département. Un glossaire contrôlé et les métadonnées du corpus aident à lever ces ambiguïtés. Le jeu d’évaluation doit inclure les questions dont l’interprétation change selon ce contexte, avec un comportement prévu lorsque la précision manque.
Préparez aussi une réponse de repli utile. « Je ne sais pas » est préférable à une invention, mais peut laisser l’utilisateur bloqué. L’assistant peut préciser quelle information manque, proposer une clarification ou orienter vers le propriétaire du document, sans exposer une ressource interdite. Cette sortie doit être dessinée comme un vrai parcours, pas comme un message d’erreur oublié.
Enfin, comparez régulièrement les signalements des utilisateurs avec le jeu de tests. Une nouvelle famille de questions ou un changement de vocabulaire peut révéler que le périmètre réel a évolué. Ajoutez alors des cas validés avant de modifier le système : cette étape transforme les incidents en amélioration contrôlable.
Le premier succès n’est pas de construire l’assistant le plus général. C’est de fournir des réponses traçables sur un périmètre où les utilisateurs savent quand lui faire confiance, quand vérifier et quand revenir au responsable métier. Cette discipline documentaire constitue souvent la partie la plus durable de l’investissement.
Je suis Romain, rédacteur passionné par tout ce qui touche au high-tech, à la crypto, et à l’innovation. Diplômé d’une école de marketing à Paris, je mets ma plume au service des dernières tendances et avancées technologiques.
