Torna al blog AI Infrastructure

È possibile ricostruire in seguito un’esecuzione di un LLM? Una checklist pratica sulla provenienza

Una risposta, da sola, raramente spiega come ci è arrivato un LLM. Scopri cosa registrare per esaminarla o confrontarla in seguito e come rendere visibili le informazioni di provenienza mancanti e le scelte sulla gestione dei dati.

Un team esamina la cronologia di un’esecuzione di un LLM con registrazioni di prompt, modello, recupero, strumenti e output

Perché una risposta, da sola, non basta

Una risposta salvata indica cosa ha restituito il sistema, ma non necessariamente il contesto che l’ha influenzata. Lo stesso testo può essere interpretato diversamente a seconda del prompt di sistema, dei documenti recuperati, della versione del modello e dei parametri di generazione. La ricerca sui sistemi mediati da strumenti osserva che conservare soltanto il testo della risposta potrebbe non bastare per interpretarla o esaminarla in seguito ([Tool-mediated systems also complicate attribution and reconstruction, Politecnico di Torino](https://webthesis.biblio.polito.it/41347/1/tesi.pdf)).

Per una risposta importante, valuta una registrazione che distingua il materiale di input, i vincoli di sistema, le istruzioni dell’utente, il materiale recuperato, le trasformazioni assistite da strumenti, l’output del modello, l’interpretazione generata, l’incertezza e l’elaborazione successiva. Sono elementi proposti da FIELD COMPUTE ATLAS per una registrazione dell’esecuzione; costituiscono una checklist di progettazione, non una garanzia che ogni sistema possa conservarli tutti ([FIELD COMPUTE ATLAS, versione 2.1](https://zenodo.org/records/23014733/files/FIELD_COMPUTE_ATLAS_v2_1_FULL_INTEGRATED_20260926.pdf?download=1)).

  • È possibile identificare il flusso di lavoro che ha prodotto la risposta?
  • È possibile distinguere l’output del modello dalle modifiche successive apportate dall’applicazione?
  • Quali parti del contesto della richiesta sono presenti e quali mancano?
Perché una risposta, da sola, non basta

Scegli l’obiettivo: ripetizione, ricostruzione o confronto

Decidi quale obiettivo deve supportare la registrazione prima di scegliere cosa conservare. Ripetizione, diagnosi e confronto sono obiettivi diversi: una registrazione utile a spiegare un’esecuzione precedente non consente necessariamente di riprodurre esattamente lo stesso output.

Lo stato interno preciso del modello potrebbe non essere disponibile, come osserva FIELD COMPUTE ATLAS. Tienine conto quando descrivi cosa può consentire una registrazione ([FIELD COMPUTE ATLAS, versione 2.1](https://zenodo.org/records/23014733/files/FIELD_COMPUTE_ATLAS_v2_1_FULL_INTEGRATED_20260926.pdf?download=1)).

  • Per ripetere un’esecuzione, conserva gli input e la configurazione che ti servono e che sei autorizzato a conservare; indica le dipendenze che non puoi ripristinare.
  • Per la diagnosi, dai priorità al contesto e alle trasformazioni necessari per interpretare ciò che è accaduto.
  • Per il confronto, identifica cosa è cambiato tra le esecuzioni e cosa non è stato possibile verificare.
  • Non promettere una ripetizione esatta quando gli input rilevanti o lo stato del modello non sono disponibili.
Scegli l’obiettivo: ripetizione, ricostruzione o confronto

Registra il prompt e il contesto dell’applicazione

Il solo nome di un modello di prompt potrebbe non mostrare le istruzioni e gli input utilizzati per una specifica richiesta. Se il sistema lo consente, conserva il prompt assemblato, o le sue parti rilevanti, insieme a un identificativo di revisione del prompt o dell’applicazione. La ricerca sui sistemi mediati da strumenti raccomanda di conservare il contesto della richiesta e le informazioni sulla provenienza insieme all’artefatto della risposta ([Tool-mediated systems also complicate attribution and reconstruction, Politecnico di Torino](https://webthesis.biblio.polito.it/41347/1/tesi.pdf)).

Rendi espliciti i limiti della registrazione: se un campo o una dipendenza non è stato conservato, segnalalo come non disponibile.

  • Se il sistema li rappresenta separatamente, mantieni distinguibili i vincoli di sistema, le istruzioni dell’utente e i valori delle variabili pertinenti.
  • Quando disponibile, registra la revisione del prompt o dell’applicazione e conserva la revisione corrispondente solo se le tue regole di governance lo consentono.
  • Annota le attività rilevanti di pre-elaborazione o post-elaborazione che possono influire sull’interpretazione della risposta.

Acquisisci la provenienza del modello, del recupero e degli strumenti

Registra i dettagli del modello e della richiesta che la tua integrazione può osservare, distinguendo i valori osservati dalle supposizioni. Le interfacce dei fornitori differiscono: consulta la documentazione del servizio specifico per verificare quali campi siano disponibili.

Nei flussi di lavoro con generazione aumentata dal recupero o che utilizzano strumenti, un riferimento a una fonte potrebbe non mostrare il materiale o il risultato effettivamente utilizzato. Se consentito, conserva i passaggi recuperati pertinenti, gli input e i risultati degli strumenti e le trasformazioni che li collegano. FIELD COMPUTE ATLAS propone di distinguere nella registrazione dell’esecuzione il materiale recuperato, le trasformazioni assistite da strumenti e l’interpretazione generata ([FIELD COMPUTE ATLAS, versione 2.1](https://zenodo.org/records/23014733/files/FIELD_COMPUTE_ATLAS_v2_1_FULL_INTEGRATED_20260926.pdf?download=1)).

  • Registra i dettagli del modello e della richiesta disponibili al tuo sistema.
  • Per il materiale recuperato, conserva identificativi utili o i contenuti pertinenti, se consentito, e specifica se la registrazione non conserva ciò che è stato fornito al modello.
  • Per le attività degli strumenti, distingui l’input e il risultato dello strumento dall’interpretazione che ne ha dato il modello.

Collega gli eventi correlati e dichiara le lacune

Un riferimento all’esecuzione o alla traccia può aiutare a organizzare nel tuo sistema input, output e attività degli strumenti correlati. Consideralo un collegamento alle registrazioni, non un loro sostituto. Una checklist per i repository di ricerca richiede la provenienza del modello, del prompt, degli strumenti e della traccia, compresa la dichiarazione dell’eventuale assenza di informazioni sulla provenienza ([The design cannot distinguish these explanations, Zenodo](https://zenodo.org/records/21711582/files/can-an-ai-assisted-research-repository-preserve-a-no-v0.5.0.pdf?download=1)).

Scegli una sequenza di eventi e identificativi adatti alla tua implementazione. Se un componente non può fornire un collegamento o un evento, registra la lacuna invece di inventare una connessione. Le fonti citate non stabiliscono convenzioni specifiche dei fornitori per gli ID di traccia.

  • Usa un riferimento all’esecuzione per organizzare le registrazioni correlate, se è utile nel tuo sistema.
  • Se disponibili, mantieni distinti gli identificativi generati dal fornitore da quelli creati dalla tua applicazione.
  • Indica nella registrazione quali informazioni di provenienza sono mancanti, oscurate o non disponibili.

Usa con attenzione le registrazioni strutturate

Quando registri prompt, documenti recuperati, output degli strumenti o risposte, una serializzazione strutturata può rendere espliciti i confini tra i campi. La ricerca sui sistemi mediati da strumenti tratta anche la canonicalizzazione, l’escape dei contenuti non attendibili e l’hashing su una rappresentazione canonica come meccanismi di registrazione ([Tool-mediated systems also complicate attribution and reconstruction, Politecnico di Torino](https://webthesis.biblio.polito.it/41347/1/tesi.pdf)).

Un hash può aiutare a verificare se un artefatto conservato corrisponde a una registrazione precedente; non può recuperare contenuti che sono stati eliminati. Se usi hash, documenta la rappresentazione verificata e non presentarli come sostituti dei contenuti sottostanti.

  • Definisci confini chiari tra i campi registrati.
  • Se usi canonicalizzazione o hashing, documenta la rappresentazione e le scelte di escape.
  • Specifica se i contenuti sottostanti sono conservati, trasformati o non disponibili.

Definisci regole di accesso e conservazione

Prompt, passaggi recuperati, risultati degli strumenti e risposte possono contenere informazioni che non dovrebbero essere accessibili a tutti. Nell’ambito delle tue scelte di governance dei dati, decidi cosa raccogliere, chi può accedervi e per quanto tempo conservarlo. La policy appropriata dipende dal contesto: questa checklist non prescrive un periodo di conservazione specifico.

Valuta se escludere, oscurare o archiviare separatamente i campi sensibili. Se i contenuti vengono omessi o trasformati, rendilo visibile, affinché chi legge la registrazione possa capire cosa consente e cosa non consente di fare.

  • Classifica i campi della traccia in base alle tue esigenze di analisi e alle regole sui dati.
  • Limita l’accesso in base alle scelte di governance della tua organizzazione.
  • Documenta le decisioni relative a oscuramento, conservazione ed eliminazione.
  • Specifica cosa è stato conservato, trasformato, oscurato o reso non disponibile.

Domande frequenti

È possibile riprodurre esattamente in seguito una risposta di un LLM?

Non necessariamente. La riproduzione esatta dipende dalla disponibilità degli input e del contesto pertinenti e dal fatto che il servizio del modello esponga o conservi lo stato necessario per ripetere la richiesta. FIELD COMPUTE ATLAS osserva che lo stato interno preciso del modello potrebbe non essere disponibile. Una registrazione può comunque supportare un’analisi senza garantire un output identico.

Cosa è utile conservare per esaminare un’esecuzione di un LLM?

Valuta di conservare il contesto della richiesta, i dettagli pertinenti del modello e dell’applicazione, il materiale recuperato, le attività degli strumenti e l’output, se consentito. Gli elementi proposti da FIELD COMPUTE ATLAS includono materiale di input, vincoli di sistema, istruzioni dell’utente, materiale recuperato, trasformazioni assistite da strumenti, output del modello, incertezza e post-elaborazione.

Un ID di traccia basta per esaminare una risposta?

No. Un riferimento all’esecuzione o alla traccia può aiutare a organizzare registrazioni correlate, ma non sostituisce il prompt, il materiale recuperato, i risultati degli strumenti o l’output.

I team dovrebbero conservare prompt completi e documenti recuperati?

Dipende dalle esigenze di analisi e dalle regole sui dati. Conservare i contenuti può fornire più contesto, ma occorre decidere cosa raccogliere, chi può accedervi e per quanto tempo conservarlo. Indica chiaramente quando i contenuti sono stati omessi o trasformati.

Gli hash rendono riproducibili prompt o contenuti contestuali eliminati?

No. Un hash calcolato su una rappresentazione canonica può aiutare a verificare se un artefatto conservato corrisponde a una registrazione precedente, ma non può recuperare contenuti che non sono stati conservati.

Fonti e approfondimenti

  1. FIELD COMPUTE ATLAS, version 2.1 — Zenodo
  2. Tool-mediated systems also complicate attribution and reconstruction — Politecnico di Torino thesis repository
  3. The design cannot distinguish these explanations — Zenodo