GraphEval évalue les hallucinations des LLM en transformant leurs réponses en triples vérifiables, puis en testant chaque affirmation avec un modèle NLI. J’aime cette approche parce qu’elle ne dit pas juste “c’est faux”, elle montre où ça dérape, affirmation par affirmation.
Pourquoi les LLM hallucinent ?
Les LLM hallucinent pour une raison assez simple : ils ne “savent” pas au sens humain du terme. Ils prédisent la suite la plus probable d’un texte, à partir de ce qu’ils ont appris et du contexte qu’on leur donne. Quand le contexte est incomplet, ambigu, trop long, ou mal exploité, ils peuvent produire une réponse très fluide, très crédible, mais fausse.
Une hallucination, ce n’est pas forcément une énormité visible à 10 mètres. C’est souvent plus subtil. Une date légèrement inventée. Une condition contractuelle mal reformulée. Une cause ajoutée alors qu’elle n’est pas dans le document source. Une conclusion logique en apparence, mais pas vraiment soutenue par les informations disponibles.
Et c’est là que le sujet devient intéressant. Le vrai problème, ce n’est pas juste de dire “la réponse est bonne” ou “la réponse est mauvaise”. Dans un usage sérieux, surtout en data, juridique, finance, RH ou support client, j’ai besoin de savoir quelle affirmation pose problème.
Une note globale aide un peu, mais elle masque souvent l’essentiel :
- Une partie de la réponse peut être parfaitement fidèle à la source.
- Une autre partie peut être neutre, parce qu’elle reformule sans ajouter grand-chose.
- Une dernière partie peut contredire le document ou inventer une information.
Si je donne 7/10 à une réponse, ça ne me dit pas quoi corriger. Ça ne me dit pas si le risque est mineur ou critique. Ça ne me dit pas non plus si le modèle a raté une phrase importante ou s’il a ajouté une affirmation qui n’existe nulle part.
Je l’ai vu plusieurs fois chez des clients qui testent l’IA sur leurs documents internes. Au début, tout le monde est impressionné parce que la réponse est propre, bien écrite, rapide. Puis quelqu’un relit avec le document source à côté, et là on se rend compte qu’une réponse fluide n’est pas forcément une réponse vérifiable. C’est un moment un peu froid, mais très utile.
C’est encore plus vrai quand on demande à un LLM de résumer, expliquer ou reformuler une connaissance source. Dans ces cas-là, l’enjeu n’est pas d’être créatif. L’enjeu, c’est de rester fidèle.
C’est exactement là que GraphEval devient intéressant. Au lieu d’évaluer une réponse comme un bloc, la méthode la découpe en affirmations élémentaires. Chaque petite affirmation peut alors être comparée à la source. On ne juge plus seulement une impression générale, on regarde précisément ce qui est soutenu, ce qui est douteux, et ce qui ne tient pas.
Comment fonctionne GraphEval ?
GraphEval part d’une idée assez simple : une réponse de LLM est difficile à juger en bloc. Quand un modèle écrit cinq phrases, il peut avoir raison sur trois points, être flou sur un autre, et inventer le dernier. Donc GraphEval découpe la réponse en petites affirmations vérifiables.
La première étape, c’est la transformation de la sortie du LLM en graphe de connaissances, ou Knowledge Graph. Un graphe de connaissances représente l’information sous forme de triples Sujet Relation Objet. C’est très pratique, parce qu’on passe d’un texte parfois long à des unités factuelles simples.
Par exemple, la phrase “GraphEval uses Knowledge Graphs” devient :
GraphEval — uses — Knowledge Graphs
La phrase “GraphEval is evaluation framework” devient :
GraphEval — is — evaluation framework
Ce découpage change beaucoup de choses. Au lieu de dire “La réponse est fiable à 72%”, GraphEval peut pointer précisément l’affirmation qui pose problème. C’est ce que j’aime bien dans cette approche. Sur des cas clients, c’est souvent ça qui manque dans les évaluations LLM classiques : elles donnent une note, mais elles ne disent pas vraiment où le modèle a dérapé.
La deuxième étape, c’est la vérification avec un modèle NLI, pour Natural Language Inference. En français, on peut dire inférence en langage naturel. Le principe est simple : on donne au modèle une source de vérité, appelée prémisse, puis une affirmation à vérifier, appelée hypothèse.
Dans GraphEval, le contexte source sert de prémisse. Chaque triple du graphe est transformé en phrase, puis testé comme hypothèse. Le modèle NLI renvoie généralement trois types de résultats :
- Entailed : L’affirmation est soutenue par la source.
- Contradictory : L’affirmation contredit la source.
- Neutral : L’affirmation n’est pas prouvée par la source.
Dans GraphEval, les triples qui ne sont pas entailed peuvent être signalés comme des hallucinations, ou au minimum comme des affirmations non vérifiées. C’est une nuance importante. Une affirmation neutral n’est pas forcément fausse, mais si elle n’est pas dans la source, le LLM n’avait peut-être pas le droit de l’ajouter.
| Élément | Rôle | Intérêt |
| Triples KG | Découpent la réponse en faits Sujet Relation Objet | Permettent une évaluation précise et localisable |
| Contexte source | Sert de prémisse pour vérifier les faits | Fournit la base de vérité attendue |
| Modèle NLI | Compare chaque affirmation à la source | Classe les faits en entailed, contradictory ou neutral |
| Hallucination détectée | Correspond à un triple non soutenu par la source | Aide à identifier exactement où le LLM invente ou extrapole |
Comment tester GraphEval en code ?
Pour tester GraphEval sans lancer une grosse machine, je préfère commencer par une simulation propre. On garde la logique complète, mais on évite le coût d’un vrai pipeline avec extraction automatique, modèle NLI lourd et graphe massif. C’est souvent comme ça que je valide l’idée chez un client avant de brancher ça sur une infra sérieuse.
Dans cet exemple, le contexte source est écrit à la main. Il sert de vérité terrain. La sortie du LLM est simulée. L’extraction des triples est simulée aussi. Un triple, c’est une petite affirmation sous forme sujet-relation-objet, par exemple “GraphEval uses Knowledge Graphs”. Le but ici, c’est juste de vérifier si chaque affirmation est supportée par le contexte.
- Transformers sert normalement à charger un modèle NLI, pour Natural Language Inference, c’est-à-dire un modèle qui vérifie si une phrase implique une autre phrase.
- Networkx sert à représenter les triples sous forme de graphe.
- Matplotlib sert à visualiser ce graphe si besoin.
- Torch sert de backend de calcul pour les modèles.
import torch
from transformers import pipeline
import networkx as nx
import matplotlib.pyplot as plt
source_context = """
GraphEval is an evaluation framework for checking LLM outputs.
GraphEval uses Knowledge Graphs to compare generated claims with a trusted source.
"""
llm_output = """
GraphEval is an evaluation framework.
GraphEval uses Knowledge Graphs.
GraphEval requires an expensive enterprise server farm.
"""
triples = [
"GraphEval is evaluation framework",
"GraphEval uses Knowledge Graphs",
"GraphEval requires expensive enterprise server farm"
]
def evaluate_triple(triple, context):
# Version simplifiée pour valider la logique avant d'utiliser un vrai modèle NLI.
supported_triples = {
"GraphEval is evaluation framework",
"GraphEval uses Knowledge Graphs"
}
if triple in supported_triples:
return "entailed"
return "neutral"
graph = nx.DiGraph()
edges = [
("GraphEval", "evaluation framework", "is"),
("GraphEval", "Knowledge Graphs", "uses"),
("GraphEval", "expensive enterprise server farm", "requires")
]
for subject, object_, relation in edges:
graph.add_edge(subject, object_, label=relation)
suspected_triples = []
for triple in triples:
verdict = evaluate_triple(triple, source_context)
if verdict != "entailed":
suspected_triples.append((triple, verdict))
print("Triples suspectés :")
for triple, verdict in suspected_triples:
print(f"- {triple} => {verdict}")
Le troisième triple est le point important ici. Le contexte ne dit pas que GraphEval nécessite une ferme de serveurs entreprise coûteuse. Donc il ne doit pas être marqué comme “entailed”. Il sort en “neutral”, ce qui veut dire “non prouvé par la source”. Pas forcément faux dans l’absolu, mais non soutenu par le contexte donné.
C’est exactement l’intérêt de GraphEval. Je ne cherche pas juste une ressemblance de texte. Je transforme les affirmations en faits vérifiables, puis je regarde lesquels tiennent vraiment face à la source. Une fois que cette logique marche sur un exemple simple, je peux remplacer la fonction factice par un vrai modèle NLI chargé avec Transformers, automatiser l’extraction des triples, et industrialiser proprement.
Que révèle l’exemple GraphEval ?
Ce que j’aime dans l’exemple GraphEval, c’est qu’il montre un point très concret. Une réponse de LLM peut être globalement correcte, mais contenir une phrase qui part complètement hors piste. Et c’est souvent là que les ennuis commencent dans un vrai projet.
Le contexte source dit simplement que GraphEval est un cadre d’évaluation qui utilise des Knowledge Graphs, donc des graphes de connaissance qui structurent les faits sous forme d’entités et de relations, et des modèles NLI, pour Natural Language Inference, c’est-à-dire des modèles qui vérifient si une affirmation est soutenue, contredite ou non couverte par une source.
La réponse simulée du LLM est partiellement correcte. Elle dit que GraphEval est un framework d’évaluation. C’est soutenu par le contexte. Elle dit aussi qu’il utilise des Knowledge Graphs. C’est soutenu aussi. Puis elle ajoute que GraphEval nécessite une ferme de serveurs entreprise coûteuse. Là, problème. Le contexte ne dit pas ça.
| Triple extrait | Statut NLI attendu | Interprétation |
| GraphEval — est — un framework d’évaluation | Entailed | Le contexte affirme bien que GraphEval est un cadre d’évaluation. L’affirmation est donc justifiée. |
| GraphEval — utilise — des Knowledge Graphs | Entailed | Le contexte mentionne explicitement l’usage de Knowledge Graphs. Rien à signaler ici. |
| GraphEval — nécessite — une ferme de serveurs entreprise coûteuse | Neutral ou Contradiction selon le contexte | Si le contexte ne parle pas d’infrastructure, l’affirmation est neutral. Si le contexte dit que GraphEval est léger et ne nécessite pas d’infrastructure coûteuse, elle devient contradictoire. |
La nuance est importante. Une contradiction, c’est quand la réponse dit l’inverse de la source. Une affirmation neutral, c’est quand la réponse ajoute quelque chose que la source ne permet pas de vérifier. Dans les deux cas, ce n’est pas entailed, donc ce n’est pas soutenu par le contexte.
Et pour moi, c’est exactement là que GraphEval devient intéressant. Il ne dit pas juste “la réponse est mauvaise”. Il isole le morceau précis qui pose problème. Cette granularité change tout quand on audite des sorties LLM dans des projets sérieux, parce qu’on peut garder ce qui est correct, remonter ce qui est douteux, et éviter de jeter toute une réponse à cause d’une seule hallucination.
Quand utiliser GraphEval ?
GraphEval devient vraiment utile quand je ne veux plus juste “avoir l’impression” qu’une réponse LLM est correcte, mais que je veux la confronter à une source. C’est surtout intéressant quand il faut comprendre où le modèle a inventé, déformé ou extrapolé.
Je l’utilise bien dans des cas où la réponse est censée rester collée à un contexte précis. Par exemple un résumé de contrat, une synthèse de compte-rendu, une réponse générée depuis une base de connaissance interne, ou un assistant métier qui répond à partir de procédures RH, support, juridique, finance. Dans ces situations, GraphEval peut découper les affirmations en triples, du type “Sujet – relation – objet”, puis vérifier si chaque affirmation est supportée par la source.
Dans un workflow data ou automatisation, ça devient une brique assez pratique. On peut scorer une réponse avant affichage, annoter les passages douteux, router une réponse vers validation humaine, ou bloquer une automatisation si une affirmation clé n’est pas suffisamment soutenue. J’ai déjà vu ce besoin chez des équipes qui voulaient automatiser des réponses client. Le vrai sujet n’était pas seulement “Le texte est-il joli ?”, mais plutôt “Est-ce que je peux assumer ce qui est écrit ?”.
Mon point de vue est assez simple. GraphEval est une brique d’audit, pas une baguette magique. Il aide à structurer le contrôle, mais il ne remplace pas une bonne architecture IA. Si le contexte envoyé au LLM est mauvais, incomplet ou mal récupéré, GraphEval ne va pas deviner la vérité cachée dans un autre document.
Il faut aussi rester lucide sur ses limites. Une mauvaise extraction de triples peut créer un faux diagnostic. Par exemple, si “Le client peut résilier après 30 jours” est mal extrait en “Le client doit résilier après 30 jours”, l’évaluation part déjà de travers. Le modèle NLI, pour Natural Language Inference, c’est-à-dire le modèle qui juge si une phrase est supportée, contredite ou neutre par rapport au contexte, peut aussi se tromper. Surtout sur des formulations juridiques, médicales ou très métier.
- GraphEval est pertinent quand une réponse LLM doit être vérifiée contre une source claire, comme un document, une base interne ou un contexte RAG.
- Il faut rester prudent quand le contexte source est incomplet, quand l’extraction des affirmations est fragile, ou quand le domaine demande une précision forte.
- Son intérêt principal est de passer d’un avis subjectif sur la qualité d’une réponse à une vérification plus structurée, traçable et exploitable dans un workflow.
Et si on arrêtait de juger les réponses IA au feeling ?
GraphEval apporte une idée simple et vraiment utile. Au lieu de juger une réponse LLM en bloc, je la découpe en affirmations, je les structure en triples, puis je les vérifie une par une avec un modèle NLI et un contexte source. C’est plus lisible, plus auditable, et surtout plus actionnable.
La méthode n’est pas magique. Elle dépend du contexte, de l’extraction des triples et du modèle NLI. Mais pour auditer des réponses générées, repérer les affirmations non justifiées et fiabiliser un workflow IA, c’est une base solide. Le bénéfice pour vous est clair, vous gardez la puissance des LLM sans piloter leur fiabilité à l’instinct.
FAQ
- Qu’est-ce que GraphEval ?
GraphEval est un cadre d’évaluation des hallucinations des modèles de langage. Il transforme une réponse générée en triples de graphe de connaissances, puis vérifie chaque triple par rapport à un contexte source avec un modèle NLI. - Pourquoi utiliser des Knowledge Graphs pour détecter les hallucinations ?
Les Knowledge Graphs permettent de découper une réponse en affirmations simples sous forme Sujet Relation Objet. C’est beaucoup plus pratique pour savoir exactement quelle affirmation est correcte, non prouvée ou fausse. - Quel est le rôle du NLI dans GraphEval ?
Le NLI compare une affirmation avec un contexte source. Il peut indiquer si l’affirmation est soutenue, contradictoire ou neutre. Dans GraphEval, les affirmations non soutenues par la source sont signalées comme hallucinations ou comme points à vérifier. - GraphEval donne-t-il une note globale de fiabilité ?
L’intérêt principal de GraphEval n’est pas seulement de donner une note. Sa vraie valeur est de localiser les erreurs au niveau des triples. On voit précisément quelle partie de la réponse pose problème. - GraphEval suffit-il à garantir qu’un LLM ne se trompe jamais ?
Non. GraphEval aide à auditer et repérer les affirmations non vérifiées, mais il dépend de la qualité du contexte source, de l’extraction des triples et du modèle NLI. Je le vois comme une brique de contrôle, pas comme une garantie absolue.
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. J’accompagne des équipes qui veulent utiliser l’IA sérieusement, avec des données propres, des workflows fiables et des contrôles mesurables. J’ai travaillé avec des organisations comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor. Je dirige l’agence webAnalyste et l’organisme Formations Analytics. Si vous voulez mettre en place des usages IA fiables dans votre business, contactez-moi.
⭐ Analytics engineer, Data Analyst et Automatisation IA indépendant ⭐
- Ref clients : Logis Hôtel, Yelloh Village, BazarChic, Fédération Football Français, Texdecor…
Mon terrain de jeu :
- Data Analyst & Analytics engineering : tracking avancé (GTM server, e-commerce, CAPI, RGPD), entrepôt de données (BigQuery, Snowflake, PostgreSQL, ClickHouse), modèles (Airflow, dbt, Dataform), dashboards décisionnels (Looker, Power BI, Metabase, SQL, Python).
- Automatisation IA des taches Data, Marketing, RH, compta etc : conception de workflows intelligents robustes (n8n, App Script, scraping) connectés aux API de vos outils et LLM (OpenAI, Mistral, Claude…).
- Engineering IA pour créer des applications et agent IA sur mesure : intégration de LLM (OpenAI, Mistral…), RAG, assistants métier, génération de documents complexes, APIs, backends Node.js/Python.






