Un acheteur interroge l’assistant interne sur les pénalités de retard d’un contrat fournisseur. Réponse, pleine d’assurance : « 0,5 % par jour, plafonnée à 10 % ». C’est faux. La clause réelle dit 0,1 %, sans plafond. L’assistant n’a pas menti ; il a recousu une réponse vraisemblable à partir de bouts de documents mal retrouvés. Voilà l’hallucination en RAG : pas un bug spectaculaire, une erreur calme et bien tournée.
Le Retrieval-Augmented Generation était censé régler ça : on branche le LLM sur vos documents, il répond à partir d’eux, fini les inventions. Sur le papier. En production, les assistants se trompent toujours avec aplomb, et la cause est presque toujours la même : ce n’est pas le modèle qui hallucine, c’est la recherche qui lui sert mal le contexte. Le « G » de RAG marche bien. C’est le « R » qui pèche.
Le vrai coupable, c’est le retrieval
Un LLM moderne ne demande qu’à raisonner sur ce qu’on lui donne. Passez-lui les trois bons paragraphes, il répond juste. Le problème se joue avant l’appel au modèle, dans la phase de récupération, où les défauts s’accumulent sans se voir : la réponse sonne bien, donc personne ne creuse.
Un découpage naïf qui coupe le sens en deux
La majorité des projets découpent par tranches de N caractères, fenêtre glissante, point final. Résultat : un tableau coupé en plein milieu, une clause détachée de la condition qui la rendait vraie. Le fragment récupéré est « pertinent » au sens cosinus, mais incomplet. Le modèle reçoit la moitié d’une idée et complète l’autre tout seul. Terreau classique de l’hallucination.
Des embeddings qui ne parlent pas votre langue métier
Les embeddings génériques rapprochent les mots sémantiquement proches « en général ». Mais dans votre domaine, « avenant » et « annexe » ne sont pas synonymes, « provision » n’a pas son sens de dictionnaire, et une référence comme « PR-204-B » est, pour un embedding standard, à peu près du bruit. La recherche vectorielle excelle sur le sens diffus et trébuche sur l’exact : codes, sigles, numéros de version, noms propres.
Un top-k trop court, ou trop long
Récupérer les 3 passages les plus proches paraît raisonnable. Sauf que le bon est parfois en sixième position, et vous ne le verrez jamais. Élargir à top-20 noie alors le modèle sous le contexte : il s’accroche au passage le plus présent, pas au plus juste. Régler le top-k au doigt mouillé, c’est jouer la fiabilité aux dés.
Et votre base, elle, dit-elle la vérité ?
Admettons la recherche parfaite. Elle ne vaudra jamais mieux que ce qu’elle indexe. Or les bases documentaires d’entreprise sont un capharnaüm sédimenté : v1, v2 et « v2_finale_OK » d’une même procédure coexistent, deux notes RH se contredisent sur les congés, un PDF de 2019 traîne à côté de sa refonte de 2024. Quand la recherche remonte les deux, le LLM tranche. Mal, en général, et sans le dire.
Le RAG amplifie la dette documentaire au lieu de la masquer. Un humain qui tombe sur deux versions hésite et recoupe. Le modèle, lui, fusionne les deux en une réponse lisse et confiante. C’est pire qu’une absence de réponse : une fausse certitude, livrée avec le ton de l’évidence.
Pourquoi le modèle comble les trous
Un LLM est entraîné à produire une suite plausible, pas à dire « je n’ai pas l’information ». Face à un contexte partiel et une question précise, il complétera : c’est sa nature. Sans instruction ni garde-fou, le silence n’est pas dans ses options par défaut.
S’ajoutent trois angles morts qu’on retrouve dans presque tous les projets en difficulté :
- Aucune citation vérifiable. Si la réponse ne pointe pas vers le passage source exact, personne ne peut la contrôler. Et une affirmation invérifiable finit par être crue sur parole.
- Aucun plancher de pertinence. Quand le meilleur résultat a un score de similarité médiocre, beaucoup de pipelines l’envoient quand même au modèle. Le LLM, poliment, brode dessus.
- Aucune métrique de succès. On mesure le nombre de questions posées, jamais le taux de réponses justes. Sans chiffre, l’hallucination reste une anecdote d’utilisateur agacé, pas un défaut suivi.
Ce dernier point est le plus coûteux. On ne corrige pas ce qu’on ne mesure pas. Beaucoup d’équipes passent des semaines sur leur prompt système alors que leur recherche rate une question sur trois. Un effort sur le mauvais maillon, faute de l’avoir mesuré.
Comment fiabiliser, concrètement
La bonne nouvelle : aucune de ces causes n’exige un modèle plus gros. Tout se joue dans le pipeline.
Découper en respectant la structure
Découpez selon la logique du document (titres, sections, articles, lignes de tableau) plutôt qu’au compteur de caractères. Gardez un léger recouvrement entre fragments et attachez à chacun ses métadonnées : source, date, version, droits, section parente. LlamaIndex et LangChain fournissent des découpeurs conscients de la structure ; sur des contrats ou des PDF complexes, un parsing qui préserve la mise en page paie vite.
Chercher en hybride : BM25 + vecteurs
Combinez recherche lexicale (BM25) et recherche vectorielle. BM25 rattrape l’exact que les embeddings ratent : codes produits, références de procédure, sigles. Les vecteurs rattrapent le sens que les mots-clés ratent. Elasticsearch et OpenSearch font les deux nativement ; côté PostgreSQL, pgvector et le full-text intégré couvrent l’essentiel sans empiler les briques. Fusionnez les deux classements au lieu de choisir.
Reclasser avant d’envoyer au modèle
Récupérez large (30 à 50 candidats), puis passez-les à un reranker de type cross-encoder qui note la pertinence de chaque passage pour la question posée, et ne gardez que le haut du panier. Souvent le meilleur rapport effort/résultat du pipeline : un re-tri bien placé corrige des erreurs que ni le découpage ni l’embedding ne réglaient.
Filtrer par fraîcheur et par droits
Les métadonnées posées au découpage servent ici. À l’exécution, écartez les versions périmées, gardez la plus récente quand deux documents se recoupent, et n’exposez que ce que l’utilisateur a le droit de voir. Citer une procédure abrogée, ce n’est pas seulement se tromper : c’est dangereux, justement parce que la réponse a l’air crédible.
Imposer les citations et le « je ne sais pas »
Deux règles non négociables. Chaque affirmation renvoie à son passage source, cliquable, vérifiable d’un coup d’œil. Et quand le meilleur score de pertinence reste sous un seuil, l’assistant répond « je n’ai pas trouvé d’information fiable » plutôt que de broder. Un assistant qui sait se taire vaut mieux qu’un assistant qui a réponse à tout. Contre-intuitif pour les sponsors, mais c’est la condition de la confiance dans la durée.
Mesurer, à chaque changement
Constituez un jeu d’évaluation : 50 à 200 questions réelles, avec leur réponse attendue et le passage qui la justifie. Rejouez-le à chaque modification (modèle, découpage, seuil, index) et suivez deux choses séparément : la recherche a-t-elle ramené le bon passage, et la réponse finale est-elle exacte. Distinguer ces deux mesures vous dit quel maillon réparer. Sans ce jeu rejoué, chaque « amélioration » est un pari.
Ce que ça change côté architecture
Mis bout à bout, ces correctifs ne forment pas un prompt magique mais une chaîne aux étapes nettes : ingestion et découpage structuré, double index lexical et vectoriel, recherche hybride, reranking, filtres de fraîcheur et de droits, génération avec citations et seuil de refus, puis évaluation en boucle. Orchestrer tout ça à la main devient vite ingérable. C’est là qu’un outil comme N8N et l’exposition des sources et outils via MCP gardent le pipeline lisible, versionné et auditable — au lieu d’un script que personne n’ose plus toucher.
Le RAG n’est pas en cause. Le RAG bâclé l’est. La différence entre un assistant qui invente une clause et un assistant qui cite la bonne tient rarement au modèle, presque toujours à la qualité de la recherche et aux garde-fous. C’est ce que nous industrialisons dans l’offre industrialisation & automatisation ; pour l’orchestration, le guide N8N, MCP & agents LLM détaille l’architecture cible.