Peut-on reconstituer ultérieurement une exécution de LLM ? Liste de contrôle pratique de provenance
Une réponse ne suffit généralement pas à expliquer comment un LLM l’a produite. Découvrez quoi consigner pour mener une investigation ou une comparaison, et comment rendre visibles les informations de provenance manquantes et les choix de traitement des données.
Pourquoi une réponse ne suffit pas
Une réponse enregistrée indique ce que le système a renvoyé, mais pas nécessairement le contexte qui l’a façonnée. Un même texte de réponse peut être interprété différemment selon le prompt système, les documents récupérés, la version du modèle et les paramètres de génération. La thèse « Les systèmes médiés par des outils compliquent aussi l’attribution et la reconstitution », publiée dans le dépôt du Politecnico di Torino, indique que conserver uniquement le texte de la réponse peut ne pas suffire pour une interprétation ou une investigation ultérieure ([Politecnico di Torino](https://webthesis.biblio.polito.it/41347/1/tesi.pdf)).
Pour une réponse importante, envisagez un enregistrement qui distingue les données d’entrée, les contraintes système, les instructions utilisateur, les éléments récupérés, les transformations assistées par des outils, la sortie du modèle, l’interprétation générée, l’incertitude et le post-traitement. FIELD COMPUTE ATLAS propose ces éléments comme points à distinguer dans un enregistrement de LLM ; il s’agit d’une liste de contrôle de conception, et non d’une garantie que chaque système puisse conserver chaque élément ([FIELD COMPUTE ATLAS, version 2.1](https://zenodo.org/records/23014733/files/FIELD_COMPUTE_ATLAS_v2_1_FULL_INTEGRATED_20260926.pdf?download=1)).
- Pouvez-vous identifier le flux de travail qui a produit la réponse ?
- Pouvez-vous distinguer la sortie du modèle des modifications apportées ensuite par votre application ?
- Quelles parties du contexte de l’appel sont présentes, et lesquelles manquent ?
Choisir l’objectif : rejouer, reconstituer ou comparer
Avant de choisir ce que vous allez conserver, déterminez ce que l’enregistrement doit permettre. Le rejeu, le diagnostic et la comparaison sont des objectifs différents ; un enregistrement utile pour expliquer une exécution antérieure ne permet pas nécessairement de reproduire exactement la sortie.
L’état interne précis du modèle peut ne pas être disponible, comme l’indique FIELD COMPUTE ATLAS. Soyez explicite sur cette limite lorsque vous décrivez ce que l’enregistrement peut permettre ([FIELD COMPUTE ATLAS, version 2.1](https://zenodo.org/records/23014733/files/FIELD_COMPUTE_ATLAS_v2_1_FULL_INTEGRATED_20260926.pdf?download=1)).
- Pour le rejeu, conservez les entrées et la configuration nécessaires que vous êtes autorisé à garder ; indiquez toute dépendance que vous ne pouvez pas restaurer.
- Pour le diagnostic, privilégiez le contexte et les transformations nécessaires à l’interprétation de ce qui s’est passé.
- Pour la comparaison, indiquez ce qui a changé entre les exécutions et ce qui n’a pas pu être vérifié.
- Ne promettez pas un rejeu exact lorsque des entrées pertinentes ou l’état du modèle ne sont pas disponibles.
Consigner le prompt et le contexte de l’application
Le nom d’un modèle de prompt ne suffit pas toujours à révéler les instructions et les entrées utilisées lors d’un appel particulier. Lorsque votre système le permet, conservez le prompt assemblé ou les parties pertinentes, ainsi qu’un identifiant de révision du prompt ou de l’application. La thèse « Les systèmes médiés par des outils compliquent aussi l’attribution et la reconstitution » recommande de préserver le contexte de l’appel et sa provenance avec l’artefact de réponse ([Politecnico di Torino](https://webthesis.biblio.polito.it/41347/1/tesi.pdf)).
Rendez explicites les limites de l’enregistrement. Si un champ ou une dépendance n’a pas été conservé, indiquez qu’il est indisponible au lieu de laisser entendre que l’enregistrement est complet.
- Lorsque votre système les représente séparément, distinguez les contraintes système, les instructions utilisateur et les valeurs pertinentes des variables.
- Consignez la révision du prompt ou de l’application lorsqu’elle est disponible, et ne conservez la révision correspondante que si vos règles de gouvernance l’autorisent.
- Signalez tout prétraitement ou post-traitement important susceptible d’influencer l’interprétation de la réponse.
Capturer la provenance du modèle, de la récupération et des outils
Consignez les détails du modèle et de la requête que votre intégration peut observer, et distinguez les valeurs observées des suppositions. Les interfaces des fournisseurs diffèrent ; consultez donc la documentation du service concerné au lieu de vous fier à une liste de contrôle générique pour déterminer les champs disponibles.
Dans les flux de travail utilisant la génération augmentée par récupération ou des outils, une référence à une source ne révèle pas nécessairement les éléments ou les résultats exacts qui ont été utilisés. Lorsque cela est autorisé, conservez les passages récupérés pertinents, les entrées et les résultats des outils, ainsi que les transformations effectuées entre eux. FIELD COMPUTE ATLAS propose de distinguer dans un enregistrement d’exécution les éléments récupérés, les transformations assistées par des outils et l’interprétation générée ([FIELD COMPUTE ATLAS, version 2.1](https://zenodo.org/records/23014733/files/FIELD_COMPUTE_ATLAS_v2_1_FULL_INTEGRATED_20260926.pdf?download=1)).
- Consignez les détails du modèle et de la requête accessibles à votre système ; indiquez lorsqu’une valeur est indisponible.
- Pour les éléments récupérés, conservez des identifiants utiles ou le contenu pertinent lorsque cela est autorisé, et précisez si l’enregistrement ne préserve pas ce qui a été transmis au modèle.
- Pour l’activité des outils, distinguez les entrées et les résultats de l’outil de l’interprétation que le modèle en a faite.
- Signalez les informations de provenance manquantes au lieu de laisser entendre que des liens vers des sources ou le nom d’un outil constituent un enregistrement complet.
Relier les événements associés et signaler les lacunes
Une référence d’exécution ou de trace peut aider à organiser les entrées, les sorties et l’activité des outils associés dans votre propre système. Considérez-la comme un lien vers les enregistrements, et non comme un substitut à ceux-ci. La publication « The design cannot distinguish these explanations » demande explicitement la provenance du modèle, du prompt, des outils et de la trace, ainsi que la mention de l’absence de provenance ([Zenodo](https://zenodo.org/records/21711582/files/can-an-ai-assisted-research-repository-preserve-a-no-v0.5.0.pdf?download=1)).
Choisissez une séquence d’événements et des identifiants adaptés à votre mise en œuvre. Si un composant ne peut pas fournir de lien ou d’événement, consignez cette lacune au lieu d’inventer une relation. Les sources citées ne définissent pas de conventions d’identifiants de trace propres aux fournisseurs.
- Utilisez une référence d’exécution pour organiser les enregistrements associés lorsque cela est utile dans votre système.
- Le cas échéant, distinguez les identifiants générés par le fournisseur de ceux créés par votre application.
- Rendez visibles dans l’enregistrement les informations de provenance manquantes, expurgées ou indisponibles.
Utiliser les enregistrements structurés avec précaution
Lors de l’enregistrement de prompts, de documents récupérés, de sorties d’outils ou de réponses, une sérialisation structurée peut rendre explicites les limites entre les champs. La thèse « Les systèmes médiés par des outils compliquent aussi l’attribution et la reconstitution » aborde également la canonicalisation, l’échappement du contenu non fiable et le calcul d’empreintes sur une représentation canonique comme mécanismes de journalisation ([Politecnico di Torino](https://webthesis.biblio.polito.it/41347/1/tesi.pdf)).
Une empreinte peut aider à vérifier si un artefact conservé correspond à un enregistrement antérieur ; elle ne permet pas de récupérer un contenu qui a été supprimé. Si vous utilisez des empreintes, documentez la représentation vérifiée et ne présentez pas l’empreinte comme un substitut au contenu sous-jacent.
- Définissez clairement les limites entre les champs enregistrés.
- Si vous utilisez la canonicalisation ou le calcul d’empreintes, documentez les choix de représentation et d’échappement.
- Indiquez si le contenu sous-jacent est conservé, transformé ou indisponible.
Définir les règles d’accès et de conservation
Les prompts, les passages récupérés, les résultats des outils et les réponses peuvent contenir des informations qui ne devraient pas être accessibles à tous. Dans le cadre de vos choix de gouvernance des données, déterminez quelles données collecter, qui peut y accéder et combien de temps les conserver. La politique appropriée dépend de votre contexte ; cette liste de contrôle ne prescrit aucune durée de conservation particulière.
Déterminez si les champs sensibles doivent être exclus, expurgés ou stockés séparément. Si du contenu est omis ou transformé, rendez-le visible afin que les lecteurs de l’enregistrement comprennent ce qu’il permet ou non d’établir.
- Classez les champs de trace en fonction de vos besoins d’investigation et de vos règles de gestion des données.
- Limitez l’accès conformément aux choix de gouvernance de votre organisation.
- Documentez les décisions d’expurgation, de conservation et de suppression.
- Indiquez ce qui a été conservé, transformé, expurgé ou rendu indisponible.
Questions fréquentes
Peut-on reproduire exactement une réponse de LLM ultérieurement ?
Pas nécessairement. Une reproduction exacte dépend de la disponibilité des entrées et du contexte pertinents, ainsi que de la possibilité pour le service du modèle d’exposer ou de préserver l’état nécessaire pour répéter la requête. FIELD COMPUTE ATLAS indique que l’état interne précis du modèle peut ne pas être disponible. Un enregistrement peut tout de même faciliter une investigation sans garantir une sortie identique.
Que peut-on utilement conserver pour examiner une exécution de LLM ?
Envisagez de conserver, lorsque cela est autorisé, le contexte de l’appel, les détails pertinents sur le modèle et l’application, les éléments récupérés, l’activité des outils et la sortie. Indiquez également ce qui manque. Les éléments d’enregistrement proposés dans FIELD COMPUTE ATLAS comprennent les données d’entrée, les contraintes système, les instructions utilisateur, les éléments récupérés, les transformations assistées par des outils, la sortie du modèle, l’incertitude et le post-traitement.
Un identifiant de trace suffit-il pour examiner une réponse ?
Non. Une référence d’exécution ou de trace peut aider à organiser les enregistrements associés, mais elle ne remplace ni le prompt, ni les éléments récupérés, ni les résultats des outils, ni la sortie. La publication « The design cannot distinguish these explanations » demande de consigner la provenance de la trace et de signaler l’absence de provenance.
Les équipes doivent-elles conserver les prompts complets et les documents récupérés ?
Cela dépend des besoins d’investigation et de vos règles de gestion des données. Conserver le contenu peut fournir davantage de contexte, mais vous devez déterminer quelles données collecter, qui peut y accéder et combien de temps les garder. Indiquez clairement lorsque du contenu a été omis ou transformé.
Les empreintes rendent-elles reproductible le contenu supprimé d’un prompt ou du contexte ?
Non. Une empreinte calculée sur une représentation canonique peut aider à vérifier si un artefact conservé correspond à un enregistrement antérieur, mais elle ne permet pas de récupérer un contenu qui n’a pas été conservé.
Sources et lectures complémentaires
- FIELD COMPUTE ATLAS, version 2.1 — Zenodo
- Tool-mediated systems also complicate attribution and reconstruction — Politecnico di Torino thesis repository
- The design cannot distinguish these explanations — Zenodo