Comment GraphEval détecte les hallucinations des LLMs ?

GraphEval détecte les hallucinations en transformant une réponse de LLM en triplets, puis en vérifiant chaque fait avec un modèle NLI. C’est intéressant parce qu’on ne se contente plus d’un score flou. On voit précisément quelle affirmation tient, laquelle contredit la source, et laquelle sort de nulle part.

Pourquoi les LLMs hallucinent ?

Les LLMs hallucinent parce qu’ils génèrent du texte plausible sans garantir que chaque affirmation soit soutenue par une source de vérité.

C’est ça le point important. Un LLM ne “sait” pas au sens humain du terme. Il prédit la suite la plus probable d’un texte, en fonction de ce qu’il a appris et du contexte qu’on lui donne. Le résultat peut être fluide, cohérent, bien formulé, avec le bon ton, et pourtant contenir un fait faux, une date inventée, une citation approximative, une règle métier mal interprétée ou une conclusion qui n’est écrite nulle part dans les documents.

Et côté business, c’est là que ça devient dangereux. Si vous utilisez un LLM pour résumer des contrats, répondre à des clients, produire de la documentation interne ou aider à automatiser une décision, le problème n’est pas seulement d’avoir une phrase “un peu fausse”. Le problème, c’est qu’elle peut être crédible. Elle peut passer les contrôles humains rapides, surtout quand la réponse est bien écrite. J’ai souvent vu des équipes tester une IA avec trois prompts, être rassurées par le style, puis découvrir plus tard que le problème n’était pas la forme mais les petites affirmations inventées.

Dire “la réponse est bonne” ou “la réponse est mauvaise” ne suffit pas. Dans la vraie vie, une réponse peut être correcte à 80 %, avec deux détails critiques qui posent problème. Il faut donc localiser précisément les affirmations douteuses. Qu’est-ce qui est vérifiable ? Qu’est-ce qui vient vraiment du document ? Qu’est-ce qui est déduit trop vite ? Qu’est-ce qui est complètement inventé ?

C’est là que GraphEval devient intéressant. Au lieu de juger une réponse comme un bloc, il la découpe en faits contrôlables. Une affirmation devient une unité qu’on peut comparer à une source de vérité. C’est beaucoup plus utile qu’un simple score global, parce qu’on voit où le modèle décroche.

Pour évaluer correctement une hallucination, il faut donc transformer le texte en unités factuelles simples.

Comment GraphEval structure les faits ?

GraphEval structure les faits sous forme de triplets Sujet, Relation, Objet, comme dans un Knowledge Graph. C’est simple, mais très efficace, parce qu’on sort d’un texte flou pour obtenir des affirmations qu’on peut vérifier une par une.

Un triplet, c’est juste une petite phrase découpée en trois morceaux. Le Sujet, c’est ce dont on parle. La Relation, c’est le lien ou l’action. L’Objet, c’est ce qu’on affirme à propos du sujet. Par exemple : GraphEval, is, evaluation framework. Ici, on dit que GraphEval est un framework d’évaluation. Autre exemple : GraphEval, uses, Knowledge Graphs. Là, on affirme que GraphEval utilise des Knowledge Graphs.

Ces deux affirmations peuvent être soutenues par le contexte de référence si le document source dit bien que GraphEval est un framework d’évaluation et qu’il s’appuie sur des Knowledge Graphs. Mais si le modèle génère un triplet comme GraphEval, requires, expensive enterprise server farm, là je deviens méfiant. Si rien dans la source ne parle d’une énorme infrastructure serveur coûteuse, c’est une affirmation suspecte. Typiquement le genre de détail inventé qui sonne crédible, mais qui n’est pas justifié.

Ce format est pratique parce qu’il force le modèle à isoler les affirmations atomiques. Une affirmation atomique, c’est une idée minimale, difficile à découper davantage. Dans un paragraphe normal, on peut avoir du vrai, du faux, du vague et du marketing dans la même phrase. J’ai déjà vu ça chez un client sur des réponses générées pour de la documentation produit : 80% était correct, mais une seule précision inventée changeait complètement le sens. Avec des triplets, on peut séparer chaque morceau et le contrôler proprement.

Le Knowledge Graph, sans jargon inutile, c’est une manière de représenter des entités et leurs relations. Une entité peut être GraphEval, un LLM, une méthode, un document. Une relation explique le lien entre deux entités. Dans GraphEval, le graphe sert surtout à rendre les affirmations lisibles, comparables et auditables.

Élément	Rôle	Exemple
Sujet	Ce dont on parle	GraphEval
Relation	Le lien ou l’action	Uses
Objet	Ce qui est affirmé	Knowledge Graphs

Structurer les faits ne suffit pas. Une fois les triplets extraits, il faut encore comparer chaque triplet à une source de vérité, sinon on a juste une belle liste d’affirmations, pas une détection fiable des hallucinations.

Comment le NLI vérifie les triplets ?

Le NLI vérifie chaque triplet en comparant l’affirmation au contexte de référence pour savoir si elle est entailée, contradictoire ou neutre.

Le NLI, pour Natural Language Inference, c’est une tâche assez simple à comprendre : on donne au modèle une phrase de référence, puis une affirmation, et il doit dire si l’affirmation est soutenue par cette référence. Dans GraphEval, l’affirmation prend souvent la forme d’un triplet, par exemple sujet, relation, objet. C’est pratique parce qu’on ne juge pas toute une réponse d’un bloc, on vérifie les faits un par un.

Entailment	Le contexte soutient l’affirmation. Le fait est établi.
Contradiction	Le contexte dit l’inverse. Le fait est faux par rapport à la source.
Neutral	Le contexte ne permet pas de valider l’affirmation. On ne sait pas.

Dans GraphEval, les triplets qui ne sont pas établis par le contexte sont signalés comme hallucinations, ou au minimum comme faits non supportés. C’est une nuance importante. Un fait peut être vrai dans le monde réel, mais s’il n’est pas présent dans la source utilisée, il ne doit pas être présenté comme certain.

Prenons un exemple. Le LLM répond que GraphEval nécessite une infrastructure lourde, et l’extraction produit le triplet : GraphEval, requires, expensive enterprise server farm. Si le contexte de référence explique seulement que GraphEval utilise des graphes et du NLI, sans parler de ferme de serveurs coûteuse, le modèle NLI doit classer ce triplet comme neutral. Si le contexte dit explicitement que GraphEval peut tourner sur une infrastructure standard, il doit plutôt le classer comme contradiction. Dans les deux cas, GraphEval marque ce triplet comme hallucination ou fait non supporté.

C’est là que la méthode devient utile. Au lieu de dire “la réponse est mauvaise”, on sait exactement quelle relation pose problème. Pas besoin de jeter tout le texte si une seule phrase dérape. On peut corriger ce triplet, le filtrer, demander une régénération ciblée, ou afficher une alerte à l’utilisateur. J’ai vu ça chez un client sur des réponses métier longues, ça change tout : on passe d’un jugement flou à une liste de points vérifiables.

Il faut quand même rester prudent. La qualité dépend de l’extraction des triplets, de la qualité du contexte de référence et du modèle NLI utilisé. GraphEval rend l’évaluation plus explicable, mais ce n’est pas une baguette magique.

À quoi ressemble un test GraphEval ?

Un test GraphEval ressemble à une petite chaîne d’évaluation qui part d’un contexte fiable, analyse une réponse générée, extrait des triplets, puis vérifie chaque triplet avec un modèle NLI.

Dans un exemple simple, je pars d’un contexte de référence qui dit que GraphEval est un framework d’évaluation des hallucinations basé sur des structures de Knowledge Graph. Un Knowledge Graph, c’est juste une façon de représenter l’information sous forme de relations entre entités, comme “GraphEval” → “utilise” → “Knowledge Graph”.

Ensuite, je prends une réponse de LLM. Elle dit des choses correctes, puis elle ajoute une affirmation inventée : GraphEval aurait besoin d’une ferme de serveurs enterprise coûteuse. C’est typiquement le genre de phrase qui a l’air crédible, mais qui n’est pas supportée par le contexte.

# Dépendances possibles dans une vraie version :
# transformers, networkx, matplotlib, torch

source_context = """
GraphEval is a framework for evaluating hallucinations in LLM outputs.
It uses Knowledge Graph structures to represent claims and compare them
against a reliable reference context.
"""

llm_output = """
GraphEval is a framework for hallucination evaluation.
It uses Knowledge Graph structures to check generated claims.
GraphEval requires expensive enterprise server farm.
"""

# Ici, je simule l'extraction pour éviter de lancer un modèle coûteux.
extracted_triples = [
    ("GraphEval", "is", "hallucination evaluation framework"),
    ("GraphEval", "uses", "Knowledge Graph structures"),
    ("GraphEval", "requires", "expensive enterprise server farm")
]

results = []

for subject, relation, obj in extracted_triples:
    claim = f"{subject} {relation} {obj}"

    if claim == "GraphEval requires expensive enterprise server farm":
        status = "hallucination"
    else:
        status = "supported"

    results.append({
        "triple": (subject, relation, obj),
        "status": status
    })

print(results)

Dans une version réelle, cette boucle serait remplacée par un modèle NLI, pour Natural Language Inference. Ce modèle compare chaque triplet au contexte et décide si l’affirmation est supportée, contredite, ou non vérifiable. Là, je simule volontairement le verdict pour garder l’exemple lisible.

Étape	Ce qu’on fait	Ce que ça apporte
Contexte	On définit une source fiable sur GraphEval.	On fixe la vérité de référence.
Réponse LLM	On analyse le texte généré.	On repère les affirmations à vérifier.
Triplets	On transforme les phrases en relations simples.	On rend l’évaluation plus précise.
Vérification NLI	On valide ou rejette chaque triplet.	On sait exactement où la réponse dérape.

GraphEval rend l’évaluation plus actionnable parce qu’il ne dit pas juste “cette réponse hallucine”, il montre précisément quelle relation pose problème.

Alors, est-ce que GraphEval suffit pour fiabiliser vos LLMs ?

GraphEval apporte une réponse propre à un problème très concret : comment repérer les hallucinations sans se perdre dans un score global impossible à interpréter. J’aime bien cette approche parce qu’elle ramène le texte à des faits simples, sous forme de triplets, puis elle les confronte à une source fiable avec du NLI. C’est lisible, auditable, et surtout exploitable dans un vrai workflow IA. Il faut rester lucide : la méthode dépend de la qualité du contexte, de l’extraction et du modèle de vérification. Mais pour sécuriser vos usages LLM, vous gagnez une chose essentielle : savoir exactement quoi corriger.

FAQ

• Qu’est-ce que GraphEval ?
  GraphEval est un cadre d’évaluation des hallucinations des LLMs. L’idée est simple : transformer une réponse générée en triplets Sujet, Relation, Objet, puis vérifier chaque triplet avec un contexte de référence et un modèle NLI.
• Pourquoi utiliser des Knowledge Graphs pour évaluer un LLM ?
  Les Knowledge Graphs permettent de découper une réponse en faits précis. Au lieu d’évaluer un bloc de texte complet, on vérifie chaque relation. C’est beaucoup plus explicable, parce qu’on voit exactement quelle affirmation est vraie, non prouvée ou contradictoire.
• Quel est le rôle du NLI dans GraphEval ?
  Le NLI, pour Natural Language Inference, compare une affirmation avec un contexte de référence. Il classe cette affirmation comme entailée si elle est soutenue, contradictoire si elle s’oppose au contexte, ou neutre si le contexte ne permet pas de la confirmer.
• GraphEval détecte-t-il toutes les hallucinations ?
  Non, pas automatiquement. GraphEval améliore l’explicabilité et la localisation des erreurs, mais sa fiabilité dépend de trois choses : la qualité du contexte de référence, la qualité de l’extraction des triplets et la performance du modèle NLI utilisé.
• GraphEval est-il utile en entreprise ?
  Oui, surtout dès qu’un LLM produit des réponses utilisées dans un process métier : support client, résumé documentaire, génération de contenu, analyse interne. GraphEval aide à repérer les affirmations non supportées avant qu’elles ne créent un problème de confiance ou de décision.

 

 

A propos de l’auteur

Je suis Franck Scandolera, expert et formateur en tracking avancé server-side, Analytics Engineering, automatisation No/Low Code avec n8n, intégration de l’IA en entreprise et SEO/GEO. Avec mon agence webAnalyste et mon organisme Formations Analytics, j’accompagne des équipes qui veulent utiliser la data et l’IA sérieusement, sans boîte noire inutile. J’ai travaillé avec des clients comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor. Si vous voulez fiabiliser vos automatisations IA, vos workflows LLM ou vos systèmes d’évaluation, contactez-moi.