10. Que changent les documents, la recherche et les outils ?

Pourquoi le nombre de bénévoles de Passerelle est-il passé de 27 à 41 ? Le chapitre précédent a établi une limite : notre note donne les effectifs, mais pas les causes de leur évolution. Demander au modèle de développer davantage sa réponse ne fait pas apparaître l’information manquante.

Nous pouvons cependant changer les conditions du travail. Supposons que nous disposions d’un rapport sur le recrutement. Nous pouvons le fournir à l’application, lui demander de retrouver un passage pertinent, puis vérifier ce que ce passage permet de conclure. Pour calculer le taux d’augmentation, nous pouvons aussi utiliser un outil de calcul.

Ces opérations n’ajoutent pas la même chose. Un document apporte un contenu ; une recherche retrouve des informations ; un outil exécute une opération. Elles peuvent se combiner : la recherche elle-même est généralement accessible à l’application sous la forme d’un outil.

L’objectif de ce chapitre est de comprendre qui fait quoi entre le modèle, l’application et ces ressources. Les documents et les résultats de Passerelle ci-dessous sont des exemples fictifs rédigés pour le cours, pas des observations obtenues sur un service.

Fournir un document change les informations disponibles

Comparons deux demandes :

Résume le rapport de recrutement de Passerelle.

Résume le rapport de recrutement de Passerelle reproduit ci-dessous. Distingue ses constats de ce qu’il ne permet pas d’établir.

Dans la première, le nom du rapport ne fournit pas son contenu. Si le modèle ne dispose d’aucun moyen d’y accéder, il peut reconnaître le type de document demandé, mais cela ne lui donne pas le rapport particulier de Passerelle.

Dans la seconde, le texte est effectivement présent. Le modèle peut utiliser les informations fournies, même si ce rapport n’a jamais figuré dans ses données d’entraînement. Ses capacités apprises servent à lire, rapprocher et reformuler un contenu nouveau.

Karpathy illustre cette différence avec le résumé d’un chapitre de roman, à partir de 1 h 40 min 15 s. Fournir le texte rend possible une comparaison directe entre la source et le résumé, au lieu de s’appuyer seulement sur les connaissances apprises du modèle.

Un nouvel élément, pas une preuve de tout

Ajoutons à notre dossier ce passage fictif :

Rapport de recrutement de Passerelle, section « Entretiens d’accueil » : plusieurs nouveaux bénévoles déclarent avoir découvert l’association pendant les ateliers. Aucun questionnaire systématique sur les motifs d’inscription n’a été réalisé.

Nous disposons maintenant d’un élément que la note initiale ne contenait pas. Une réponse étayée pourrait préciser :

Selon le rapport, plusieurs nouveaux bénévoles déclarent avoir découvert Passerelle pendant les ateliers. Cela apporte une piste sur le recrutement. Toutefois, l’absence d’enquête systématique ne permet pas d’attribuer toute la hausse des effectifs aux ateliers, ni d’en mesurer la contribution exacte.

L’apport du document est réel, mais limité à ce qu’il contient. Il permet de rapporter des déclarations et leurs limites ; il ne transforme pas ces déclarations en démonstration causale complète.

Utiliser le document ne réentraîne pas le modèle

Dans cet usage, le texte est ajouté aux informations disponibles pour la génération : le contexte. Le calcul s’appuie sur ce contexte et sur les paramètres déjà appris. Il n’est pas nécessaire de modifier ces paramètres pour résumer le rapport.

L’application peut conserver le fichier pour le retrouver plus tard. Ce stockage reste différent d’un entraînement du modèle. Comme nous l’avons vu au chapitre sur le contexte et la mémoire, conserver un fichier, le fournir à une demande et modifier des paramètres sont trois opérations distinctes.

Cette distinction technique ne décrit pas, à elle seule, la politique de conservation ou de réutilisation des données d’un service. Avant de transmettre un document confidentiel, il faut vérifier les règles applicables au service et les autorisations dont on dispose.

Un fichier joint n’est pas nécessairement lu intégralement

Dans une interface, joindre un PDF semble être une seule action. Pour l’application, plusieurs traitements peuvent être nécessaires avant que le modèle reçoive des informations utilisables.

Un PDF contenant du texte peut faire l’objet d’une extraction. Un document numérisé peut nécessiter une reconnaissance optique de caractères, souvent appelée OCR, qui convertit l’image des caractères en texte. Certaines applications transmettent aussi des images de pages à un modèle capable de les traiter. Le chemin dépend du produit et du fichier.

Ces traitements peuvent perdre ou déformer une information. Une colonne peut être séparée de son en-tête, une note de bas de page omise ou un chiffre mal reconnu. Le modèle pourrait alors produire un résumé fidèle au texte extrait, mais incorrect par rapport au document original.

Microsoft décrit ces opérations de préparation, notamment l’extraction, l’OCR et le découpage, dans sa documentation sur la préparation des contenus pour le RAG. Ce sont des possibilités d’une chaîne documentaire, pas des étapes obligatoires de tout assistant.

La question utile devient donc : quelles parties du fichier ont effectivement été rendues disponibles pour cette réponse ? Le nom du fichier visible dans l’interface ne suffit pas à le déterminer. Pour vérifier un point précis, demander le passage et son emplacement permet de revenir à l’original.

Pourquoi rechercher des passages plutôt que tout fournir ?

Un rapport court peut tenir entièrement dans le contexte. Mais imaginez plusieurs années de rapports, des comptes rendus et des tableaux d’activité. Transmettre tout le dossier à chaque question peut dépasser la capacité du modèle, augmenter le coût et rendre plus difficile la sélection des informations utiles.

Une autre approche consiste à chercher d’abord les passages susceptibles de répondre à la question, puis à les fournir au modèle. On appelle cette approche génération augmentée par récupération d’informations, ou Retrieval-Augmented Generation, abrégé RAG.

Pour Passerelle, une question sur les motifs d’inscription pourrait conduire à sélectionner la section « Entretiens d’accueil ». Une question sur les effectifs pourrait conduire à sélectionner un tableau de suivi. Le modèle ne reçoit donc pas nécessairement les mêmes extraits pour deux questions portant sur le même dossier.

Un schéma courant est le suivant :

Votre question
      ↓
Recherche dans les documents
      ↓
Sélection de passages et de leurs sources
      ↓
Ajout des passages au contexte
      ↓
Génération d’une réponse

Ce schéma distingue deux tâches : retrouver des informations pertinentes, puis construire une réponse à partir de ces informations. Les confondre empêcherait de comprendre où une erreur peut apparaître.

Préparer la recherche

Une application peut découper les documents en passages, appelés aussi chunks, et construire un index : une structure qui facilite leur recherche. Elle peut conserver avec chaque passage le titre du document, sa section, sa date ou un repère de page.

Le découpage a des conséquences. Si la phrase « aucun questionnaire systématique n’a été réalisé » est séparée du passage sur les entretiens et n’est pas retrouvée, la réponse risque de perdre une réserve essentielle. Les passages doivent rester assez complets pour conserver le sens utile à la question.

Un index ne garantit pas non plus que le contenu soit à jour. Si un rapport est corrigé, la version utilisée pour la recherche doit être actualisée. Mettre à jour ce dossier documentaire n’est toujours pas la même chose que réentraîner le modèle de langage.

Retrouver un sens proche, pas seulement les mêmes mots

Une recherche peut utiliser des mots-clés. Elle peut aussi comparer des représentations numériques de la question et des passages, appelées embeddings, afin de retrouver des formulations proches par leur sens.

Par exemple, la question « Comment les bénévoles ont-ils connu Passerelle ? » pourrait conduire à un passage intitulé « Origine des inscriptions », même sans reprendre exactement les mêmes mots. Cette proximité dépend du modèle de représentation et de la méthode de recherche ; elle n’est pas garantie.

Le principe des représentations numériques rappelle le chapitre sur l’intérieur du modèle. Ici, les représentations numériques servent à comparer des passages et des requêtes. Elles se distinguent des représentations de tokens utilisées à l’intérieur du modèle qui rédige la réponse. Les modèles utilisés pour ces deux fonctions peuvent être différents.

La similarité mesure une forme de proximité, pas la vérité du passage ni sa capacité certaine à répondre à la question. On peut combiner recherche par mots-clés et recherche par représentations numériques ; on parle alors de recherche hybride. Une base de données vectorielle particulière n’est pas une obligation pour comprendre ou appliquer le principe du RAG.

Le RAG n’est pas une recette unique

L’article Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, présenté par Patrick Lewis et ses collègues en 2020, décrit une architecture associant un système de récupération de passages et un modèle génératif. Les auteurs étudient notamment un index de Wikipédia et un entraînement conjoint de composants du système.

Dans les applications, le terme RAG couvre aussi des chaînes qui récupèrent des documents et les transmettent à un modèle existant sans le réentraîner. Microsoft décrit ce fonctionnement dans son schéma de RAG classique.

Retenons la distinction : le RAG peut faire intervenir des composants entraînés pour mieux chercher ou répondre, mais ajouter un passage récupéré à une demande ne modifie pas, à lui seul, les paramètres du modèle.

La recherche sur le Web apporte des sources, pas une mise à jour générale

La recherche documentaire peut porter sur un dossier choisi, comme celui de Passerelle. Une recherche sur le Web utilise un ensemble de pages potentiellement plus large et évolutif. Dans les deux cas, l’application doit récupérer des informations pour les rendre utilisables par le modèle.

Selon le système, elle peut envoyer une requête à un moteur de recherche, recevoir une liste de résultats, ouvrir certaines pages et extraire des passages. D’autres services renvoient directement des extraits. Le modèle ne reçoit pas soudainement l’ensemble du Web.

Une recherche peut ainsi apporter une information publiée après son entraînement. L’ajout de ces résultats au contexte actualise les éléments disponibles pour cette réponse ; il ne modifie pas les paramètres du modèle. Karpathy montre l’insertion de résultats de recherche dans le contexte à partir de 1 h 33 min 44 s.

Retrouvé aujourd’hui ne signifie pas actuel

Une page consultée aujourd’hui peut contenir un ancien règlement. Une copie peut conserver une version dépassée. Le premier résultat peut traiter d’une autre association portant le même nom.

Il faut donc distinguer la date de consultation, la date de publication et, lorsque c’est pertinent, la période à laquelle l’information s’applique. Pour connaître les modalités actuelles d’une activité, une page officielle datée et applicable vaut davantage qu’un extrait dont on ne connaît pas l’origine.

Un résultat absent n’établit pas non plus l’inexistence d’une information. La page peut être inaccessible, mal indexée ou formulée autrement. « Je n’ai pas trouvé de source dans cette recherche » est une conclusion plus précise que « cette source n’existe pas ».

Un outil fait exécuter une opération par un autre logiciel

Nous avons surtout parlé d’apporter des informations. Un outil peut aussi accomplir une opération : calculer une expression, lire un tableau ou interroger une base de données autorisée.

Dans le mécanisme courant d’appel d’outil, ou tool calling, l’application présente au modèle les outils disponibles, leur rôle et les données qu’ils attendent. Le modèle peut alors produire une demande structurée désignant un outil et ses arguments, c’est-à-dire les valeurs à lui transmettre.

Produire cette demande n’est pas l’exécuter. C’est le logiciel de l’application qui interprète l’appel, effectue les contrôles prévus et, si l’appel est accepté, exécute l’opération. Le résultat est ensuite fourni au modèle pour poursuivre la réponse.

Microsoft expose cette séparation dans How LLMs learn to use tools. Les formats diffèrent selon les systèmes. Le point essentiel n’est pas la syntaxe d’un appel particulier, mais la répartition des responsabilités.

Suivre un calcul de Passerelle

Demandons de nouveau le taux d’augmentation entre 27 et 41 bénévoles. Dans une application disposant d’un outil de calcul, le chemin pourrait être :

1. Le modèle formule l’opération : (41 − 27) ÷ 27 × 100.
2. L’application transmet cette expression à l’outil autorisé.
3. L’outil exécute le calcul et renvoie environ 51,85185.
4. L’application fournit ce résultat au modèle, qui peut répondre : une augmentation d’environ 51,9 %.

Cette séquence est une illustration, pas un protocole universel. Elle montre ce qui change : le résultat intermédiaire provient d’une opération effectivement exécutée, et non seulement d’une suite de chiffres produite dans le texte de la réponse.

Karpathy illustre un mécanisme semblable avec du code Python, à partir de 1 h 55 min 48 s. Le modèle produit le code ; un autre composant l’exécute et renvoie le résultat. Notre calculatrice est une adaptation pédagogique du même principe.

L’outil ne choisit pas forcément le bon problème

Si l’expression transmise est (41 − 27) ÷ 41 × 100, une calculatrice peut renvoyer correctement environ 34,1 %. Pourtant, ce n’est pas le taux d’augmentation par rapport aux 27 bénévoles de départ. L’exécution est correcte, mais la question a été mal traduite en calcul.

Il faut donc contrôler les données d’entrée, l’opération demandée et l’interprétation du résultat. Le modèle peut également recopier ou arrondir incorrectement une valeur renvoyée par un outil.

Enfin, un outil peut échouer : fichier inaccessible, service indisponible ou données manquantes. Une erreur d’outil n’est pas un résultat nul et ne doit pas devenir un chiffre inventé dans la réponse.

Ce que l’application contrôle, et ce que le modèle propose

Un modèle ne peut pas rendre un outil disponible en écrivant son nom. L’application détermine les ressources accessibles, les opérations proposées et les contrôles qui entourent leur exécution.

Toutes les recherches ne sont d’ailleurs pas déclenchées par une décision du modèle. Une application peut rechercher systématiquement dans un dossier avant chaque réponse. Une autre laisse le modèle demander une recherche lorsque cela paraît nécessaire. La même apparence de conversation peut donc recouvrir des organisations différentes.

Certains outils lisent ou calculent. D’autres modifient le monde extérieur : envoyer un message, créer une réservation ou modifier un fichier. Dans ce second cas, un appel erroné peut avoir des conséquences au-delà d’une mauvaise réponse. Les autorisations et les confirmations nécessaires relèvent de l’application et de son usage, pas de la seule formulation du modèle.

L’accès à des documents privés suit la même logique. Une demande bien formulée ne doit pas donner accès à un dossier interdit. Microsoft souligne cette nécessité de contrôler les documents accessibles lors de la récupération.

Comprendre cette séparation prépare à l’étude des agents IA. Mais utiliser un outil ne signifie pas automatiquement que le système organise de façon autonome une longue suite d’actions. Ce chapitre reste centré sur le mécanisme d’une réponse enrichie ; la conception des agents appartient à la formation dédiée.

Une réponse fondée sur des sources reste à vérifier

Les ajouts précédents permettent de localiser les erreurs avec plus de précision. Il ne suffit plus de demander si « le modèle a halluciné » : il faut examiner la chaîne qui a produit la réponse.

Pour Passerelle, une recherche pourrait retrouver le bon rapport, mais seulement la phrase sur les ateliers. Le modèle pourrait alors généraliser abusivement faute d’avoir reçu la réserve sur l’absence d’enquête. À l’inverse, il pourrait recevoir les deux phrases et malgré tout omettre cette limite dans sa synthèse. Le résultat visible se ressemble, mais la défaillance n’est pas située au même endroit.

La traçabilité consiste ici à pouvoir relier une affirmation aux éléments qui la soutiennent : passage, document, valeur d’entrée ou résultat d’outil. Elle facilite le contrôle ; elle ne rend pas ces éléments automatiquement exacts.

Une citation est utile si elle conduit au passage pertinent. Une longue liste de liens ne démontre ni que chaque page a été consultée ni que chaque affirmation en découle. De même, le texte « j’ai vérifié le calcul » n’est pas, à lui seul, une preuve qu’un outil a été exécuté. Il faut examiner les sources ou les indications d’exécution effectivement disponibles dans l’application.

Exercice : repérer où se situe la limite

Dans notre dossier fictif, nous disposons maintenant de deux textes :

Note d’activité : Passerelle comptait 27 bénévoles l’an dernier et en compte 41 cette année. Elle a organisé six ateliers gratuits cette année.

Rapport de recrutement : plusieurs nouveaux bénévoles déclarent avoir découvert l’association pendant les ateliers. Aucun questionnaire systématique sur les motifs d’inscription n’a été réalisé.

Une application reçoit la demande suivante :

Calcule l’augmentation relative du nombre de bénévoles et explique ce que le dossier permet de dire sur les raisons de cette progression.

Examinez trois situations avant de lire leur analyse.

1. La recherche ne retrouve que la note d’activité. La réponse annonce une hausse de 51,9 %, puis affirme qu’une campagne sur les réseaux sociaux en est la cause.
2. Les deux textes sont fournis. L’outil calcule correctement (41 − 27) ÷ 41 × 100 et la réponse présente le résultat comme le taux d’augmentation depuis l’an dernier.
3. Les deux textes sont fournis et le bon calcul est effectué. La réponse donne 51,9 %, mais affirme que les ateliers expliquent entièrement cette hausse.

Analyse des situations

Dans la première, le calcul est correct, mais la cause n’est pas étayée. L’application n’a pas retrouvé le rapport, et la réponse a ajouté une campagne absente des sources. Elle aurait dû limiter sa conclusion aux informations disponibles.

Dans la deuxième, les sources sont présentes et l’exécution arithmétique est correcte. Le défaut se situe dans le choix du dénominateur : le taux d’augmentation doit prendre comme référence l’effectif initial, soit 27.

Dans la troisième, les documents et le calcul sont appropriés. C’est l’interprétation qui dépasse les preuves : des déclarations de plusieurs bénévoles ne mesurent pas l’effet total des ateliers sur l’évolution des effectifs.

Une réponse suffisamment fondée serait :

Le nombre de bénévoles est passé de 27 à 41, soit 14 de plus et une augmentation d’environ 51,9 %. Selon le rapport de recrutement, plusieurs nouveaux bénévoles déclarent avoir découvert Passerelle pendant les ateliers. Le rapport ne permet toutefois pas de mesurer la contribution des ateliers à cette hausse : aucun questionnaire systématique sur les motifs d’inscription n’a été réalisé.

Cette réponse utilise les documents et le calcul sans leur faire dire davantage que ce qu’ils établissent.

Vérifier votre compréhension

1. Quelle différence faites-vous entre un fichier enregistré par l’application, un passage fourni au modèle et une information apprise dans ses paramètres ?
2. Pourquoi une application peut-elle rechercher des extraits plutôt que transmettre tout un dossier ? Quel risque apparaît lors de cette sélection ?
3. Que recherche une comparaison d’embeddings ? Que ne garantit-elle pas ?
4. Une recherche sur le Web met-elle à jour les paramètres du modèle ? Pourquoi faut-il vérifier la date du contenu retrouvé ?
5. Lors d’un appel d’outil, qui propose l’opération, qui l’exécute et comment le résultat intervient-il dans la réponse ?
6. Comment un calcul correctement exécuté peut-il conduire à une réponse incorrecte ?

Le repère à conserver est le suivant : documents, recherche et outils améliorent les informations disponibles et les opérations réalisables ; ils ne remplacent pas la vérification de la chaîne complète.

La prochaine question : comment conduire une demande de bout en bout ?

Vous pouvez maintenant distinguer les connaissances apprises, le contexte fourni, les informations récupérées et les opérations exécutées. Il reste à réunir ces notions dans une démarche de travail.

Le dernier chapitre montrera comment formuler une demande, fournir les éléments utiles, préciser les limites attendues et évaluer la réponse avant de l’utiliser.

Chapitre précédent : Pourquoi un modèle peut-il se tromper avec assurance ?

Chapitre suivant : Comment formuler une demande et évaluer la réponse ?

Revenir au sommaire de la formation