Une réponse qui cite ses sources, ou qui se tait

Pourquoi j'ai posé mon premier système complet sur le terrain le plus exigeant que je connaisse.

Série « Brique après brique », Épisode 2/5 · 1. L'Auditeur de code · 3. La passerelle FHIR · 4. ITFacto · 5. Le modèle est la dernière question

L'expérience que je vous invite à faire

Prenez l'assistant conversationnel de votre choix. Posez-lui une question dont la réponse n'existe nulle part : une statistique inventée, une recommandation qui n'a jamais été publiée, un détail sur un document qui n'existe pas.

Il vous répondra.

Pas toujours, pas systématiquement, les modèles ont progressé. Mais suffisamment souvent, et surtout avec le même aplomb, la même syntaxe assurée, la même absence de signal que lorsqu'il a raison. C'est ce dernier point qui pose problème. Ce n'est pas qu'il se trompe : c'est que rien ne distingue extérieurement le moment où il se trompe du moment où il sait.

Un système qui répond toujours est un système qu'il faut toujours vérifier. Et un système qu'il faut toujours vérifier ne fait pas gagner de temps, il en fait perdre, avec une interface agréable.

C'est le problème que je voulais attaquer de front. Alors je suis allé le poser là où il fait le plus mal.

Pourquoi la santé

D'abord la raison la moins technique : c'est aussi le secteur où j'espère évoluer. L'exigence et l'impact sont ce que je cherche dans un travail, et peu de domaines en demandent autant des deux à la fois.

Les trois autres se vérifient sans me croire sur parole. Dans l'ordre où elles ont compté.

Le corpus existe, et il fait autorité. Peu de domaines disposent d'un référentiel à la fois public, gratuit, en français, daté, et que les praticiens citent réellement dans leur travail. Les publications de la Haute Autorité de Santé réunissent ces cinq conditions : 6 504 documents, 214 629 pages, découpés en 796 019 passages. Sur un corpus de procédures internes ou un catalogue produit, j'aurais construit une démonstration que personne n'aurait pu ouvrir, ni vérifier, ni contredire.

Le domaine impose la règle au lieu de me laisser la choisir. Une réponse plausible mais fausse n'y coûte pas une correction : elle coûte la confiance de toute une profession, durablement, et à juste titre. Ailleurs, « le système doit citer ses sources » est une bonne intention qu'on négocie à la première contrainte de délai. Ici, c'est la condition d'entrée. Je voulais un terrain qui ne me laisse pas la possibilité de tricher avec ma propre exigence.

Et il y a une suite. La santé est l'un des rares secteurs à s'être doté d'une norme ouverte pour l'échange des données elles-mêmes - FHIR. Documenter une réponse, puis la brancher sur un dossier réel, est un chemin qui n'existe presque nulle part ailleurs. C'est la brique suivante, et c'est pour ça que celle-ci commence ici.

Une question de pratique, donc, et quelque part dans ces 796 019 passages, celui qui y répond. Ou pas.

Le « ou pas » est le sujet de cet article.

La règle qui a tout structuré

Une seule contrainte, posée avant toute conception, et à laquelle rien n'a eu le droit de déroger :

Chaque affirmation cite l'extrait qui la fonde. Sinon, le système se tait.

Pas de synthèse générale sans ancrage. Pas de réponse composée de souvenirs d'entraînement recouverts d'un vernis de sources. Phrase par phrase, l'extrait retrouvé dans le corpus, avec sa provenance. Et si la recherche ne ramène rien de suffisant, une absence de réponse assumée plutôt qu'un contournement poli.

Cette règle paraît restrictive. Elle est libératrice, et c'est le renversement que je voulais démontrer.

Parce qu'un système qui sait dire « je ne trouve rien dans ce corpus qui réponde à votre question » rend crédibles toutes ses autres réponses. Le silence devient le garant de la parole. L'utilisateur n'a plus besoin de tout vérifier : il a besoin de vérifier ce qui l'intéresse, et il sait où regarder, puisque l'extrait est là.

Le refus n'est pas une panne. C'est une fonctionnalité, probablement la plus difficile à obtenir et la plus rentable.

Et il ne suffit pas de deux issues. Il en faut trois. Répondre, refuser - et constater une absence, c'est-à-dire rapporter que la source elle-même écrit qu'il n'existe pas de donnée établie sur la question. Sans cette troisième voie, « la HAS n'a pas tranché » se compterait comme une réponse ordinaire, et rapporter fidèlement une absence passerait pour une régression.

Ce qu'un système comme celui-ci coûte vraiment

Je passe sur la mécanique, elle est documentée partout et ce n'est pas le sujet de cette série. Deux constats de terrain, en revanche, valent d'être partagés parce qu'ils déterminent le budget bien plus que le choix du modèle.

Le premier : la difficulté n'est pas de trouver, elle est de savoir qu'on n'a pas trouvé. Ramener les dix passages les plus proches d'une question est aujourd'hui presque banal. Décider que ces dix passages, en réalité, ne répondent pas, et l'assumer, voilà le travail. C'est là que se joue la différence entre une démonstration et un outil.

Le second : la qualité de la réponse dépend d'abord de la préparation du corpus. Des documents datés, découpés proprement, dont on sait de quoi ils parlent. Ce travail ingrat détermine l'essentiel du résultat final, et il ne fait jamais l'objet d'une seule capture d'écran dans les présentations commerciales.

Le chiffre que j'aurais pu ne pas publier

Le système est mesuré sur un étalon de 162 questions. Rappel à dix passages : 80 %. Latence à chaud : 16 millisecondes.

Reste la mesure de qualité de classement, le nDCG. Et là, j'ai dû faire un choix que je crois plus instructif que le résultat lui-même.

Ce chiffre dépend entièrement de ce qu'on accepte comme succès. Si l'on n'accepte que la page exacte dont la question est tirée, il vaut 0,322. Si l'on accepte n'importe quel document du dossier HAS traitant du sujet, il vaut 0,693.

Publier le second seul aurait été très confortable. Il se compare avantageusement aux 0,314 du meilleur modèle standard sur R2MED, un banc d'essai reconnu. Sauf que ce banc est conçu pour exiger un raisonnement, là où mes questions sont tirées des documents qu'elles doivent retrouver - une tâche plus facile. La comparaison flatteuse aurait été une comparaison malhonnête.

Alors les deux bornes voyagent ensemble, partout où l'une est citée. C'est moins spectaculaire et c'est la seule chose que je sache défendre devant quelqu'un qui n'est pas d'accord.

L'étalon a servi d'abord contre moi

L'épisode précédent racontait un outil qui ne construit rien : il analyse du code existant et dit par quoi commencer. Une grille en six axes, une note calibrée, ma définition écrite de ce qu'est un code bien construit.

Ce système de recherche documentée est le premier que j'ai bâti sous cette grille. Elle a servi contre moi avant de servir à qui que ce soit d'autre, et c'était exactement l'intention.

Il y a une cohérence que je n'avais pas anticipée en commençant, et qui est devenue le fil de toute cette série : exiger d'un système qu'il montre ses sources et exiger de soi qu'on mesure son propre travail sont le même geste. Dans les deux cas, on refuse qu'une affirmation non fondée vaille au seul motif qu'elle est bien formulée.

Ce qui se transpose ailleurs

Vous ne travaillez sans doute pas en santé. La règle vous concerne quand même, et elle se traduit en une question à poser au premier rendez-vous de n'importe quel projet :

Que doit faire ce système quand il ne sait pas ?

Je ne me la suis jamais entendu poser spontanément. Pourtant elle décide de l'adoption plus sûrement que la performance brute. Un outil qui se trompe une fois sur dix sans prévenir sera abandonné en trois semaines. Un outil qui répond huit fois sur dix et déclare forfait les deux autres sera utilisé pendant des années.

La confiance ne se gagne pas en ayant raison souvent. Elle se gagne en étant prévisible.

Et remarquez le sens de la démonstration : ce qui tient en santé tient partout ailleurs. L'inverse n'a jamais été vrai. Un système validé sur un corpus indulgent ne prouve rien sur un corpus exigeant, alors qu'un système conçu pour l'exigence se relâche sans effort.

Le mot de la fin

Deux briques posées. La première dit comment mesurer la qualité de ce qu'on construit. La seconde dit comment produire une réponse qui se prouve, et savoir se taire quand elle ne le peut pas.

Il manquait pourtant quelque chose, et je l'ai compris en montrant le système à des professionnels.

Leurs questions n'étaient jamais générales. Elles portaient sur un dossier précis, avec un contexte précis, et une réponse juste dans l'absolu ne les avançait qu'à moitié. Ils ne cherchaient pas ce que dit la littérature. Ils cherchaient ce qu'elle dit pour ce cas-là.

Ce qui déplace tout le problème : non plus la qualité de la réponse, mais ce à quoi on branche le système pour qu'il sache de quoi on lui parle.

C'est l'épisode 3.

📖 Dans la même série - Épisode 1 : l'Auditeur de code (mon premier projet ne construit rien) · Épisode 3 : la passerelle FHIR (brancher la connaissance sur le réel) · Épisode 4 : ITFacto (vingt mois, cinq applications, des utilisateurs) · Épisode 5 : le modèle est la dernière question (les quatre questions du premier rendez-vous).

Les trois systèmes évoqués dans cette série sont en ligne et publics. Je conçois des systèmes d'IA traçables et vérifiables, du cas d'usage au déploiement - en savoir plus sur mon parcours, ou écrire à contact@lamoulinette.ai.

← Retour au blog