J'hallucine avec Langchain
Posté le 7 avril 2025 • 4 min de lecture • 669 motsMême les meilleurs LLMs sont sujets à un phénomène d' hallucination. Ces erreurs de génération — souvent très convaincantes mais totalement fausses — peuvent avoir des conséquences importantes selon les cas d’usage.

Une hallucination désigne une réponse générée par un modèle de langage qui est factuellement incorrecte, inventée, ou qui interprète mal la réalité. Cela peut aller d’un détail erroné à une citation fictive, en passant par une pure invention technique ou historique.
Exemple :
“Einstein a découvert la relativité générale en 1975.”
C’est faux (c’était en 1915), mais le modèle peut produire ce type d’assertion s’il n’a pas la bonne contrainte contextuelle ou s’il est trop confiant dans son raisonnement.
LangChain est un orchestrateur, pas une solution miracle. Il permet d’enchaîner des prompts, d’interfacer des bases de données (via des retrievers), de faire du question-answering ou de la génération de code.
Mais si:
Les données de contexte sont insuffisantes ou mal formatées : si le retriever ne trouve pas l’information pertinente, le LLM “brode”.
Les prompts sont mal construits : un prompt flou ou trop permissif laisse le modèle libre d’inventer.
Il y a une mauvaise gestion de la provenance : certaines chaînes ne distinguent pas clairement les données extraites de la base des inférences du modèle.
Le système ne vérifie pas les réponses : sans garde-fous, la sortie du modèle est prise comme vérité.
… alors le LLM comble les vides comme il peut — souvent en hallucinant.
Cas 1 : QA sur une documentation technique Une application QA LangChain interroge une base de documents techniques (comme des fichiers Markdown de doc interne). Si le retriever ne ramène que des extraits vagues, le modèle peut inventer des options de configuration ou des flags qui n’existent pas.
Cas 2 : Agent avec outils Un agent LangChain capable d’utiliser une calculatrice ou une API peut halluciner la syntaxe d’un appel d’API s’il ne connaît pas la structure exacte, ou s’il n’a pas été “éduqué” via le prompt à demander la documentation avant de l’utiliser.
Voici quelques bonnes pratiques pour réduire drastiquement ce phénomène :
Le couple Retriever-Augmented Generation est la clé. Assurez-vous que :
les documents sont bien chunkés (pas trop longs, pas trop courts),
vous utilisez un bon modèle d’embedding (ex : text-embedding-ada-002 ou bge-base),
le retriever est performant (MultiQueryRetriever, ParentDocumentRetriever, etc.),
vous filtrez les résultats avec un seuil de similarité.
Utilisez des chaînes comme ConversationalRetrievalChain avec l’option return_source_documents=True. Cela permet à l’utilisateur de vérifier d’où vient l’information.
Ajoutez des instructions claires dans le prompt système :
“Si vous ne savez pas, dites que vous ne savez pas.”
“Ne répondez que sur la base des documents fournis.”
“Ne faites pas de suppositions.”
from langchain.prompts
import PromptTemplate
prompt_template = PromptTemplate.from_template(
"""Répond uniquement à partir des documents fournis.
Si la réponse ne se trouve pas dans les sources, réponds : "Je ne sais pas."
Question : {question}
Documents : {context}
Réponse :"""
)Ajoutez une étape où un second modèle ou un script vérifie la cohérence des réponses avec la source. Certains vont jusqu’à faire du fact-checking automatique via un autre LLM.
Si l’utilisateur peut signaler une hallucination, enregistrez-la. Elle pourra servir à améliorer le système via des boucles RLHF ou de fine-tuning local.
On ne va pas se mentir : aucune méthode ne garantit zéro hallucination. Mais vous pouvez :
informer l’utilisateur des limites du système,
toujours afficher les sources,
fournir des niveaux de confiance ou d’incertitude dans la réponse.
LangChain est un outil puissant, mais il ne rend pas les LLMs infaillibles. Les hallucinations sont un défi fondamental de cette technologie. En mettant en place les bonnes pratiques — un RAG bien configuré, un prompt strict, une vérification post-hoc — vous pouvez considérablement réduire leur occurrence.
L’important est de construire des applications fiables, transparentes et responsables.