Brancher une IA sur ses documents, les 3 solutions miracles qui ont échoué

Les mots changent tous les 6 mois, le problème ne bouge pas d’un millimètre.

Ce qu’on veut. Qu’une IA réponde avec VOS informations, votre catalogue, vos procédures, vos contrats, et non avec des généralités valables pour n’importe qui.

Pourquoi ce n’est pas trivial. Un modèle lit une quantité limitée de texte à chaque question. On ne peut donc pas lui donner toute l’entreprise. Il faut choisir, à chaque question, le bon extrait.

Les mots qu’on emploiera devant vous. RAG, mémoire, base de connaissances, second cerveau. Ce sont des habillages du même mécanisme, apporter un contexte extérieur au modèle avant qu’il réponde.

La conséquence, souvent mal comprise. Plus on donne, moins c’est précis. Envoyer 40 documents pour une question qui en concerne 2 dégrade la réponse et gonfle la facture. Envoyer peu et juste est tout le métier.

C’est la première vague, et celle que tout le monde a fini par appeler RAG tout court.

Le principe, et il est bon. Plutôt que de chercher un mot exact, on stocke le SENS. Une documentation qui parle de procédure d’annulation ressortira sur une question qui parle de résiliation, alors qu’une recherche par mot-clé n’aurait rien trouvé.

Là où ça calme. Le jargon métier et les termes exacts. Si votre secteur emploie une référence précise, la recherche par le sens la noie dans les approximations. D’où la combinaison désormais standard avec une recherche par mot-clé, qu’on appelle recherche hybride.

La limite plus sérieuse. Les questions à plusieurs critères. Le client X, signé en 2023, avec l’option Y. La recherche par le sens excelle à trouver le meilleur passage pour une question globale, elle rate régulièrement un des 3 éléments.

Et c’est là que ça devient dangereux. Avec 2 éléments sur 3, le modèle répond quand même, en comblant le manquant. C’est le mécanisme exact de l’invention, et il vient d’une récupération incomplète, pas d’un défaut du modèle.

Présenté comme la suite logique, et séduisant sur le papier. La production a été moins tendre.

Le problème qu’il résout vraiment. Récupérer des informations LIÉES entre elles mais qui ne se ressemblent ni par les mots ni par le sens. Sur une panne moteur, la réponse est parfois du côté des commandes qui pilotent le régime, et rien ne les rapprochait.

Ce qui casse, et vite. Quand on laisse l’IA créer elle-même les entités et les liens, chaque nouveau document en ajoute. On obtient des doublons, des entités approximatives, et un ensemble qui devient très difficile à maintenir dès que le volume monte.

Le piège de la récupération. L’usage courant consiste à prendre tout ce qui se trouve à 2 ou 3 relations de distance. Sur un graphe fourni, cela ramène beaucoup trop de choses, sature la fenêtre de lecture, et fait perdre la précision qu’on venait chercher.

Quand ça reste pertinent. Sur un domaine modélisé à la main, avec des entités contrôlées et un cas d’usage clair. Autrement dit quand quelqu’un maîtrise la donnée, ce qui est rarement l’argument de vente.

C’est la mode du moment, et c’est celle sur laquelle il faut être le plus vigilant.

L’idée. Une base de connaissances faite de fichiers liés entre eux, que le modèle parcourt comme il parcourt un projet de code, en suivant la structure pour retrouver ce qui est pertinent.

Ce pour quoi c’est fait. La mémoire d’un assistant personnel, un projet individuel, un usage solitaire. Dans ce cadre, ça fonctionne très bien.

Pourquoi ça tient mal en entreprise. Trois raisons cumulées. Les entités générées automatiquement rendent l’ensemble vite illisible. Le modèle doit lire beaucoup pour naviguer, donc le coût monte avec le volume. Et rien n’est prévu pour le travail à plusieurs, ni pour les droits d’accès, ni pour la gouvernance des données.

⚠ Le signal d’alerte. Ce sujet est actuellement vendu en formation comme un système de connaissances d’entreprise. Ce n’est pas ce qu’il est. Sur des données stratégiques ou sensibles, la question des permissions se pose dès le premier jour, et elle n’a pas de réponse ici.

Après 3 vagues, la réponse tient en une phrase, et c’est presque décevant.

La combinaison qui tient. Une base de données classique pour filtrer, la recherche par le sens pour rapprocher, à l’intérieur de la zone filtrée. Le praticien qui décrit cette approche l’appelle le composite retrieval, et il la déploie après plus de 20 systèmes en production.

Pourquoi le filtre change tout. Sur un gros volume, la base devient trop peuplée et la recherche perd en précision. Réduire d’abord la zone, par catégorie ou par type, retire le bruit avant même de chercher.

Ce que la base de données apporte en plus. Les relations, gratuitement et sans erreur. Si un symptôme est relié à ses causes possibles, retrouver la cause donne aussi le diagnostic et la solution, parce que la structure a été posée à l’avance et non devinée.

La reformulation de la question, détail qui compte. Dans une conversation, on dérive. On commence par les mots de passe et on finit sur le nomadisme. Reformuler la dernière question à la lumière des précédentes, avant de chercher, évite de ramener un contexte hors sujet.

Elle est citée comme la plus critique par celui qui fait ce métier tous les jours, et elle n’apparaît dans aucune démonstration.

L’ingestion. Prendre des documents PDF, des tableurs, des exports d’outils, et les normaliser avant quoi que ce soit d’autre. Formats différents, champs mal remplis, doublons, bruit.

Pourquoi c’est décisif. Aucune technique de récupération ne rattrape une donnée sale. Un système nourri de documents hétérogènes répondra mal, que vous ayez choisi les vecteurs, le graphe ou autre chose.

Ce que ça implique dans un budget. La partie visible, la conversation avec l’IA, se construit vite. La partie invisible, la mise au propre des sources, prend l’essentiel du temps. Un devis qui inverse ces proportions décrit une démonstration, pas un système.

Le test à faire poser à un prestataire. Demandez-lui de décrire son étape d’ingestion. S’il enchaîne directement sur le choix de la base vectorielle, il vous vend l’outil et pas le résultat, exactement comme sur le branchement d’une IA à un système d’information.

Il y en aura une, probablement dans les 6 mois. Voici de quoi la juger sans y passer un trimestre.

La question de volume. Que devient ce système avec 10 fois plus de documents. Les 3 approches précédentes tenaient parfaitement en démonstration et cédaient à l’échelle.

La question de maintenance. Qui entretient la structure, et que se passe-t-il quand c’est l’IA qui la génère seule. C’est là que les graphes se sont effondrés.

La question des droits. Qui a le droit de voir quoi. Un système qui n’y répond pas est un outil personnel, quel que soit le nom qu’on lui donne.

Et la question qui tranche le plus vite. Combien de personnes l’ont mis en production, et depuis combien de temps. Trois ans de recul valent mieux que n’importe quelle démonstration, et c’est aussi notre façon de travailler sur les logiciels métiers de nos clients.