Dans le quotidien des mises en œuvre de projets RAG, l’un des problèmes les plus sous-estimés n’est ni la qualité du modèle, ni la méthode de fragmentation, ni même le choix de la base vectorielle.
Il s’agit du contrôle et de la gouvernance des documents.
Dans la phase initiale des projets, nous téléchargeons habituellement des PDFs, des politiques internes, des procédures, des contrats, des manuels et des présentations afin de constituer une base de connaissances de l’entreprise. Tout fonctionne bien jusqu’à ce que quelqu’un pose une question et obtienne une réponse fondée sur un document qui aurait dû être retiré des mois plus tôt.
À ce moment-là, nous réalisons que le problème ne vient pas du LLM. C’est la gouvernance de l’information.
Le paysage des documents d’entreprise a été construit pendant des décennies pour l’usage humain. Lorsqu’une nouvelle version d’une politique est publiée, les gens apprennent à ignorer l’ancienne. Lorsqu’un procédé est mis à jour, on attend des collaborateurs qu’ils consultent la version la plus récente.
Mais un système RAG n’a pas ce contexte. Si des versions anciennes et récentes sont indexées simultanément, les deux peuvent apparaître dans les résultats de récupération. Et selon la similarité sémantique, une version erronée peut même être jugée plus pertinente.
Pire encore, le problème n’est pas toujours seulement le versionnement. Dans de nombreuses organisations, il existe des documents différents affirmant des choses différentes sur le même sujet: politiques d’entreprise, procédures locales, FAQ, supports de formation et communications internes. Tous peuvent être théoriquement en vigueur, mais lequel détient l’autorité suprême ?
Il est intéressant de noter que l’IA ne délire pas. Elle répond exactement en se fondant sur les connaissances qui lui ont été fournies. Le problème réside dans l’incohérence des connaissances stockées.
Beaucoup d’entreprises traitent les documents comme des archives. Peut-être devraient-elles commencer à les traiter comme du code.
Cela signifie introduire des pratiques déjà courantes dans le développement logiciel: gestion formelle des versions, identifiants uniques par version, dates de mise en vigueur, statut de publication, chaînes d’approbation, contrôle de l’obsolescence, hiérarchie des autorités et pistes d’audit.
De plus, il ne suffit pas de contrôler les documents. Il faut gouverner le pipeline d’ingestion. Les changements doivent être détectés automatiquement, les documents réindexés, les versions obsolètes supprimées et les morceaux anciens éliminés. Sinon, le système continuera à récupérer des connaissances qui ne devraient théoriquement plus exister.
Concrètement, chaque chunk indexé devrait porter des métadonnées capables de répondre à des questions telles que: de quel document provient cette information? Quelle est la version? Est-elle toujours en vigueur? Existe-t-il une version plus récente? Quelle est la source officielle qui prévaut en cas de conflit?
Il existe aussi la question réglementaire. Dans de nombreux secteurs, les documents anciens ne peuvent pas être simplement supprimés. Ils doivent rester disponibles pour l’audit, la conformité et la traçabilité. Le défi consiste à distinguer clairement entre contenu en vigueur, historique, archivé ou révoqué.
Je constate de nombreuses discussions sur quel modèle utiliser, quel embedding produit la meilleure récupération ou quel cadre d’agents est le plus sophistiqué. Tout cela est important. Mais dans les environnements d’entreprise, une réponse fondée sur une version erronée d’une politique peut faire plus de dégâts qu’une réponse incomplète.
Peut-être que la principale leçon est que le RAG n’engendre pas de problèmes de gestion des connaissances. Il ne fait que rendre visibles des problèmes qui existaient depuis des années. Ce qui était autrefois compensé par la capacité humaine à interpréter le contexte est désormais exposé de façon explicite.
En fin de compte, la qualité d’un système d’IA dépend moins de l’intelligence du modèle que de la fiabilité des connaissances qu’il reçoit.
