RAG et LLM : Révolutionner l'accès aux connaissances en entreprise

L'insuffisance des LLM pour la gestion des connaissances en entreprise

Dans les entreprises de taille moyenne à grande, la gestion des connaissances est un défi majeur. Ces organisations possèdent souvent des milliers de documents internes, tels que des manuels d'ingénierie, des politiques de ressources humaines, des directives de conformité, des guides d'intégration et des spécifications de produits. Ces documents sont dispersés sur des plateformes variées comme Confluence, SharePoint, Notion, ainsi que dans des lecteurs partagés et des fils de discussion par email qui n'ont pas été consultés depuis trois ans.

Cette dispersion entraîne une inefficacité notable : l'employé moyen consacre deux à trois heures par semaine à chercher des informations qui existent déjà quelque part. Cette situation transforme souvent les ingénieurs seniors en agents de support accidentels, et les nouveaux arrivants mettent des mois à devenir productifs de manière autonome. Ce n'est pas un manque de capacité qui est en cause, mais bien l'éparpillement et l'inaccessibilité des connaissances institutionnelles.

Une solution apparente pourrait être d'utiliser un modèle de langage (LLM) pour centraliser ces connaissances. Cependant, les LLM présentent une limitation majeure : leur nature statique. Une fois entraînés, ils ne peuvent pas intégrer les mises à jour récentes, comme une nouvelle version de produit ou une politique modifiée. Le fine-tuning, bien qu'utile pour ajuster le style et le ton, est coûteux, lent à mettre à jour et ne permet pas de savoir d'où provient une réponse, ce qui est crucial dans les industries réglementées.

L'architecture RAG : une solution innovante

Pour pallier les limites des LLM, l'architecture RAG (Récupération Augmentée par Génération) propose une approche combinant deux pipelines distincts mais complémentaires. Le pipeline d'indexation est exécuté une fois lors de la configuration initiale du système, puis de manière incrémentielle chaque fois que des documents sont ajoutés ou modifiés. Il prend des documents bruts, les divise en morceaux significatifs, les convertit en représentations vectorielles et les stocke.

Le pipeline de récupération et de génération s'exécute à chaque requête utilisateur. Il prend la question posée, trouve les morceaux les plus pertinents, les assemble en une invite et demande au LLM de générer une réponse ancrée dans ce contexte. Ces deux pipelines partagent un magasin de vecteurs comme point de rencontre, permettant une mise à jour continue sans réentraînement complet.

Mise en œuvre du pipeline d'indexation

Chargement et découpage des documents

La première étape du pipeline d'indexation consiste à rendre les documents utilisables. Avec LlamaIndex, qui propose plus de cent connecteurs pour divers systèmes, les documents sont synchronisés de manière incrémentale, garantissant que seuls les fichiers modifiés sont réindexés. Cette synchronisation est essentielle pour une base de connaissances en constante évolution.

Le découpage des documents est une étape cruciale souvent mal exécutée. La qualité du découpage a un impact plus important sur les performances du système que le choix du LLM ou même du modèle d'embedding. Un découpage simple de taille fixe, par exemple en coupant chaque 512 tokens sans tenir compte des limites de phrases ou de paragraphes, est rapide à mettre en œuvre mais reste médiocre pour le contenu d'entreprise. Pour améliorer la précision, le SentenceWindowNodeParser de LlamaIndex indexe au niveau de la phrase, permettant une récupération chirurgicale sans perdre le contexte nécessaire à une réponse cohérente.

Conversion en vecteurs et stockage

Chaque morceau de document doit être converti en un vecteur numérique pour mesurer la similarité entre une requête et un document. Le modèle d'embedding choisi est crucial. Nous utilisons BAAI/bge-large-en-v1.5, un modèle open-source de l'Académie de Pékin en IA, qui est parmi les plus performants sur le benchmark MTEB. Ce modèle fonctionne entièrement localement, ce qui est non seulement optionnel mais souvent obligatoire pour les entreprises, car envoyer des documents internes à une API d'embedding externe soulève des préoccupations en matière de résidence des données.

Pour le stockage, Weaviate est privilégié pour sa capacité à combiner recherche sémantique et par mots-clés. La recherche hybride native de Weaviate, qui combine des vecteurs sémantiques denses avec une recherche par mots-clés BM25, est essentielle car les utilisateurs d'entreprise recherchent souvent avec des termes précis comme des noms de produits exacts, des ID de tickets internes ou des abréviations d'équipe. Une requête pour « liste de contrôle de conformité à l'article 17 du RGPD » contient un terme spécifique que la similarité sémantique pourrait diluer, mais que BM25 trouve immédiatement.

En outre, Weaviate est auto-hébergé et offre une multi-tenance native, permettant de partitionner l'index par département. Ainsi, une requête RH ne fera jamais remonter accidentellement des documents d'architecture d'ingénierie, et le contrôle d'accès est appliqué au niveau de la base de données plutôt que d'être ajouté dans le code de l'application.