Knowledge base et LLM : la méthode complète

Nous avons, dans l'article précédent, vu comment il était possible d'intégrer l'usage d'un LLM lors de vos travaux d'audit stratégique avec un gain réel d'efficacité et de profondeur d'analyse.

Ce travail repose cependant sur une base plus complexe qu'il faut mettre en place et cette même base repose sur une mécanique de fonctionnement des LLM que nous allons détailler ici. Comme je l'avais précisé, la compréhension du fonctionnement des LLM est la clé dans la réussite de ce type de projet.

Nous parlons bien ici de la « knowledge base », à savoir le corpus de documents que vous placez dans un projet Claude et qui pose le référentiel du projet. Sans ce référentiel, vous travaillez littéralement sans contexte et la conséquence directe est une perte de temps et d'efficacité considérable.

Dans mon cas, je pratique la knowledge base depuis que j'ai intégré l'intelligence artificielle dans mes process et je dois avouer que je ne travaille plus sans aujourd'hui.

Qu'est-ce qu'une knowledge base, mécaniquement ?

Avant de développer sur la pratique de la knowledge base, nous allons revenir sur son fonctionnement de base et ce qui la caractérise.

Un des fonctionnements de l'intelligence artificielle qui peut nous aider à mieux comprendre le rôle de la knowledge base est la récupération ancrée, qui désigne l'action par laquelle l'intelligence artificielle va récupérer des passages issus d'un corpus de texte pour formuler sa réponse. Ce mécanisme est par définition déterministe et mesurable car nous avons l'entière maîtrise sur celle-ci en respectant des critères d'éligibilité que nous verrons un peu plus loin, ce sont d'ailleurs des critères que nous connaissons assez bien du SEO classique.

Ce processus de récupération ancrée s'oppose à la génération probabiliste, procédé par lequel le LLM génère une réponse à partir des connaissances issues de son entraînement sans faire appel à un contenu. On dit que cette génération est probabiliste car la réponse est non reproductible et la source de la réponse n'y est pas remontée.

Vous l'aurez compris la knowledge base correspond bien au premier cas présenté, à savoir la récupération ancrée. C'est l'ensemble du contenu que vous servirez au LLM pour qu'il y retrouve les réponses nécessaires pour répondre correctement et qualitativement aux problématiques soumises. Plus votre knowledge base est exhaustive et bien structurée, plus le LLM pourra améliorer son efficacité globale à vous répondre.

Il faut savoir que la knowledge base agit directement sur la capacité du projet du LLM, qui désigne sa capacité maximale à traiter de l'information et selon Anthropic, cette fenêtre est multipliée par 10 avec la knowledge base. Vous l'aurez probablement compris, elle requiert une optimisation pour que son impact soit augmenté et nous verrons justement comment y arriver.

On peut enfin constater que ce fonctionnement se rapproche fortement du fonctionnement de la recherche classique avec plusieurs phases successives : recherche, indexation et score de pertinence.

Les 4 contextes de récupération

Pedro Dias, dans son article Filed Under Marketing. Sitting in the Wrong Room distingue 4 contextes de récupération et la knowledge base appartient à l'un d'entre eux.

• Les crawlers classiques tels que Googlebot qui indexe pour la recherche organique
• Les pipelines RAG, la catégorie qui nous intéresse ici justement
• Les agents, la nouvelle catégorie de bots qui simule la navigation d'un utilisateur
• Les bots d'entraînement, ceux qui parcourent le web pour alimenter la connaissance globale des modèles LLM

C'est la catégorie des pipelines RAG (« génération augmentée par la recherche ») qui nous intéresse ici car ce qui définit le pipeline RAG, c'est l'analyse de contenus pour répondre à une question en temps réel. Un mécanisme de récupération sur des contenus s'opère et sert à formuler la réponse. On est donc bien à l'opposé de la réponse instantanée issue de la génération probabiliste.

Inutile donc de développer ce qu'on doit savoir ici, la correspondance entre la pipeline RAG et la knowledge base est directe avec cette mécanique, la seule différence ici est qu'on agit au niveau local et non à l'échelle du web.

Que doit-on mettre dans la knowledge base ?

La question qui peut se poser dès le départ est que mettre dans cette knowledge base au lancement d'un projet.

Ce qu'il faut bien comprendre, c'est que le LLM a accès aux données publiques sur lesquelles son crawl est permis, il peut donc récupérer l'ensemble des données publiques à tout moment..

Ce que la knowledge base doit contenir n'est donc pas surtout la donnée publique mais la donnée qui n'est pas disponible sur le web. C'est le cas également de la donnée issue d'expérience personnelle ou de l'expertise acquise. Aucune de ces informations n'est disponible par une recherche web et c'est là qu'entre en jeu la knowledge base.

On peut distinguer 3 types de données :

• Les informations non publiques : toutes les sources que l'on ne peut retrouver sur le web et auxquelles le LLM n'aura pas accès dans son entraînement ou lors d'une recherche en directe
• L'expertise métier : on parle ici de toutes les informations qui couvrent la spécialisation liée au projet, on y inclut aussi tous les apprentissages que l'on ne peut retrouver sur le web ;
• Les choix et les décisions prises : on parle ici de vos choix stratégiques qui ne sont pas des données partagées publiquement

Ce qui caractérise la knowledge base est donc la donnée spécifique qu'elle contient face aux données publiques du web et de la connaissance des modèles de langage.

C'est cette connaissance accumulée qui est la base de la performance de ces projets.

Pour mieux comprendre, voici un schéma récapitulatif de la question à la réponse et où se place la knowledge base dans ce processus.

2. La mécanique de la récupération

Nous avons vu ce qu'est la knowledge base et je propose maintenant d'approfondir la notion de récupération. L'idée est de comprendre comment le LLM interagit avec votre knowledge base, cela peut vous aider à mieux comprendre comment celle-ci doit être structurée. Tout sera plus clair au moment où l'on définira une structure type pour votre projet.

Parmi ces étapes clés de la récupération, on y retrouve le chunking (le découpage), où le LLM découpe le contenu en passages, car on peut s'en douter, le LLM ne conserve pas un texte dans son intégralité mais l'analyse en extrait. Chacun de ces passages devient une représentation vectorielle, c'est la phase d'embedding.

Chaque embedding est analysé et les plus proches de la question de l'utilisateur servent à former la réponse. Généralement, ce score de pertinence est fonction de l'autonomie du passage, il doit répondre à lui tout seul à la question.

Dans son article A Refutation of Misinformation about Chunking, Mike King a réalisé une analyse sur le chunking et révèle un impact fort sur le découpage d'un paragraphe sans modifier le moindre mot. 19% de gain de récupération constaté sur le paragraphe découpé.

3 critères d'éligibilité d'un passage influencent sa récupération par les modèles :

• Le passage doit être autonome : il doit pouvoir être compréhensible sans le reste du contenu
• Le sujet représenté par le passage doit être clairement identifié et explicité
• Le passage doit rester monothématique

On déduit de cette analyse des critères d'éligibilité évidents liés à la structure du contenu. La récupération est fortement influencée par la hiérarchie du contenu, les marqueurs de priorité que l'on attribue aux passages importants du texte.

Ces règles assez simples permettent de faciliter la récupération du passage par le LLM.

Pour en revenir à la knowledge base, il faut savoir que cette récupération fera l'objet des mêmes exigences mais la spécificité est qu'elle se fera par le format Markdown. On reviendra sur ce format qui est l'un des pivots de fonctionnement d'une knowledge base.

Le Markdown propose justement un système de balisage simple et structuré qui favorise la structuration des contenus. La structuration et la hiérarchisation des contenus en deviennent beaucoup plus simples.

3. La structure type d'une knowledge base

Je vous propose maintenant un exemple type de structure de knowledge base. Bien entendu cette structure reste entièrement arbitraire et peut être ajustée, je l'ai réfléchie pour qu'elle soit exhaustive, facile à maintenir tout au long du projet et enfin pour qu'elle soit optimale pour la récupération par le LLM.

Cette structure doit être pensée selon votre projet, il ne faut surtout pas noyer votre knowledge base de documents inutiles ou obsolètes.

J'illustre ci-dessous une structure d'exemple de knowledge base :

Ce qui est essentiel dans cet exemple et qui revient dans chaque cas, le « system prompt » qui cadre l'ensemble du projet. Ce fichier est rarement mis à jour et fournit les consignes globales de la knowledge base, c'est un peu comme un index de sitemaps, il ne livre pas lui-même les informations mais sert à dire où elles sont. Il oriente le LLM au bon endroit, son rôle est probablement le plus important.

Je précise que certains fichiers ne sont que très rarement mis à jour et d'autres seront régulièrement mis à jour. Cette structure est donc pensée pour proposer un socle de fichiers stables qui bougent peu et des fichiers servant davantage à consigner les avancements du projet.

4. Les cinq principes de formatage

Quelle que soit la structure mise en place et le nombre de fichiers que vous utiliserez, je propose 5 principes de formatage à respecter pour chacun des fichiers.

L'ensemble de ces principes de formatage fait le pont avec les critères de récupération que nous venons de voir.

• Des phrases et paragraphes autonomes : chacun porte son propre contexte et ne dépend pas du reste.
• Une hiérarchie Hn rigoureuse : même principe que l'on connaît bien en SEO classique appliqué ici dans un contexte assez proche.
• Des mises en avant explicités de priorités : Les impératifs et interdits du projet doivent être bien mis en avant car ce sont les consignes à ne pas manquer.
• Utilisation des verbes d'action pour l'ensemble des instructions envoyées
• Des métadonnées pour suivre les mises à jour de chaque document permettant de dater les changements effectués et de détecter les risques d'obsolescence

4. Mes conseils sur l'optimisation de la knowledge base

Une optimisation faite pour l'IA avant tout

Le contenu de la knowledge base sont des directives à usage exclusivement interne à un projet, ils peuvent donc être alimenter de données non publiques et sa structure doit être pensé pour une lecture par une IA.

Attention à l'obsolescence des données

Si un projet dure plusieurs mois ou années, il doit être mis à jour. Placez des dates en footer de chaque document pour annoter les dernières mises à jour. C'est recommandé de le faire à chaque fin de session.

Il faut se rappeler que la knowledge base s'oppose sur ce point à la recherche sur le web, il faut donc être attentif au contrôle des informations qu'elle propose que le LLM peut utiliser sans vérifier la bonne conformité.

Documenter ce qui est négatif

Ce qu'il ne faut pas faire est la consigne prioritaire. Je dirais même que cette consigne passe avant les impératifs.

Chaque erreur identifiée doit être documentée et consignée dans le fichier le plus approprié, généralement celui que le LLM doit impérativement lire avant toute exécution.

La knowledge base se construit progressivement

Ne cherchez pas à proposer la knowledge base parfaite dès le début, c'est pratiquement impossible, ce sont les allers-retours et les sessions qui se cumulent qui forment la knowledge base.

On avance donc par étapes et on la développe à l'issue de chaque session de travail.

5. La knowledge base doit être constamment relue

Un article de Lily Ray intitulé The AI Slop Loop explique une mécanique dans laquelle l'intelligence artificielle récupère une information fausse provoquant des republications de cette même erreur sur diverses sources et quand cette information se répand suffisamment, elle finit par faire consensus et provoque une hallucination de l'IA.

Ce phénomène qui se produit massivement à l'échelle du web peut se produire aussi dans votre knowledge base.

3 règles très simples peuvent réduire ces risques :

• Chaque information doit être relue
• Préciser systématiquement la source et la date des informations
• Chaque source doit être validée en amont

Le rythme des mises à jour doit être régulier :

• En fin de session de travail afin d'en extraire tous les apprentissages
• Après chaque décision prise ou étape franchie sur le projet
• En période de révision (mensuelle ou trimestrielle)

Que peut-on retenir sur l'usage de la knowledge base ?

La knowledge base ouvre donc de nombreuses possibilités avec le travail fait avec l'intelligence artificielle.

C'est l'endroit du projet où toutes les informations et tous les apprentissages doivent être consignés.

Avec une rigueur d'optimisation, de structuration et de maintenance, la knowledge base vous permet de réaliser un travail de suivi très poussé que les outils classiques ne permettent pas.

Ce n'est pas une pratique sans effort, elle requiert beaucoup de rigueur et de méthodologie mais les résultats qu'elle permet d'obtenir méritent qu'on s'y intéresse.