Comment construire une base de connaissances IA sans hallucination

Le problème de l'hallucination en IA

L'hallucination est probablement le frein numéro un à l'adoption des agents IA en entreprise. Un LLM (Large Language Model) hallucine lorsqu'il génère une réponse plausible en apparence mais factuellement incorrecte — une date inventée, un chiffre fictif, une procédure qui n'existe pas dans vos documents. Pour un chatbot de support client ou un tuteur IA de formation, une seule hallucination peut entraîner une erreur métier, une plainte client, voire un incident de conformité.

La bonne nouvelle : l'hallucination n'est pas une fatalité. Elle est le symptôme d'un modèle qui « répond de mémoire » parce qu'il n'a pas accès à l'information spécifique dont il a besoin. La solution n'est pas de changer de modèle — c'est de lui donner les bonnes données au bon moment. C'est exactement ce que fait le RAG.

Comprendre le RAG (Retrieval Augmented Generation)

Le RAG est une architecture qui combine deux composants :

1. Un système de récupération (Retrieval) : quand un utilisateur pose une question, le système cherche dans votre base de connaissances les documents ou fragments les plus pertinents.
2. Un modèle de génération (Generation) : le LLM reçoit la question de l'utilisateur PLUS les fragments pertinents récupérés, et génère sa réponse à partir de ce contexte enrichi.

En pratique : si un utilisateur demande à votre chatbot « Quelle est la procédure de nettoyage du dispositif X ? », le système RAG récupère le topic correspondant dans votre KB, l'injecte dans le prompt, et le LLM répond à partir de ce contenu exact — pas de sa mémoire générique. Il ne peut pas inventer une procédure qui n'existe pas dans votre documentation.

Les trois piliers d'une KB sans hallucination

1. Granularité des chunks

La qualité de la récupération dépend directement de la taille et de la cohérence des chunks dans votre KB. Un chunk trop long dilue le signal sémantique et récupère trop d'informations hors sujet. Un chunk trop court manque de contexte et produit des réponses incomplètes.

Le sweet spot se situe entre 200 et 600 tokens par chunk, avec un recouvrement de 50 à 100 tokens entre les chunks adjacents pour préserver la cohérence contextuelle. Chaque chunk doit répondre à une question précise et pouvoir être compris de façon autonome.

2. Attribution des sources

Une KB anti-hallucination est une KB traçable. Chaque chunk doit être associé à sa source : nom du document, section, date de mise à jour, auteur. Quand l'agent IA génère une réponse, il peut — et doit — citer ses sources. Cette traçabilité a deux effets : elle réduit l'hallucination (le modèle reste ancré dans le contexte fourni) et elle permet de vérifier la fiabilité de la réponse.

Dans notre format JSON normalisé, chaque topic inclut un champ source avec le nom du document original, la section et la date de dernière mise à jour. Cette information est systématiquement incluse dans le contexte fourni au LLM.

3. Scoring et filtrage du contenu

Une KB qui contient des informations contradictoires ou obsolètes est une fabrique à hallucinations. Si votre base contient deux versions d'une même procédure — l'une de 2020 et l'une de 2024 — le modèle risque de mélanger les deux, ou de répondre à partir de la version obsolète.

Le scoring de priorité (Essential / Important / Optional / Exclude) permet d'éliminer ce bruit avant qu'il ne contamine votre KB. Les topics classés Exclude sont retirés de la base vectorisée. Les topics classés Essential bénéficient d'un boost de score lors de la recherche sémantique, ce qui garantit qu'ils sont récupérés en priorité.

Architecture technique d'une KB anti-hallucination

Voici l'architecture que nous mettons en place pour nos clients :

• Base vectorielle : stockage des embeddings avec métadonnées (source, priorité, date, type)
• Index hybride : combinaison de recherche vectorielle (sémantique) et de recherche par mots-clés (BM25) pour maximiser la précision de récupération
• Re-ranking : un modèle de re-classement évalue la pertinence des chunks récupérés avant de les injecter dans le prompt
• Prompt structuré : le prompt fourni au LLM inclut une instruction explicite de ne répondre qu'à partir du contexte fourni et de signaler quand l'information n'est pas disponible
• Garde-fous : détection des tentatives de « jailbreak » ou des questions hors périmètre

Ce que ça change concrètement

Chez un de nos clients dans le secteur de la formation professionnelle, le taux d'hallucination de leur chatbot de support est passé de 23 % (avec un LLM générique sans RAG) à moins de 2 % après mise en place de la KB structurée et du pipeline RAG. Les 2 % restants correspondent à des questions hors périmètre de la KB — le chatbot répond désormais « Je ne dispose pas de l'information pour répondre à cette question » plutôt que d'inventer une réponse.

Ce n'est pas de la magie — c'est de l'ingénierie de données. La qualité de la KB détermine la fiabilité de l'agent. Investissez dans la base, et l'agent sera fiable. Économisez sur la base, et vous aurez un agent éloquent mais imprévisible.

Par où commencer ?

La construction d'une KB anti-hallucination commence toujours par un audit. Inventaire de vos documents, évaluation de leur qualité, identification des gaps et des contradictions. C'est le travail préalable incontournable — et c'est précisément ce que couvre notre Audit Data & Knowledge Base.