Lässt sich ein LLM-Lauf später rekonstruieren? Eine praktische Checkliste zur Provenienz

Warum eine Antwort allein nicht genügt

Eine gespeicherte Antwort zeigt, was das System ausgegeben hat, aber nicht unbedingt, welcher Kontext sie geprägt hat. Derselbe Antworttext kann je nach System-Prompt, abgerufenen Dokumenten, Modellversion und Generierungsparametern unterschiedlich zu verstehen sein. Eine Arbeit zu toolvermittelten Systemen weist darauf hin, dass das Speichern des Antworttexts allein für eine spätere Interpretation oder Untersuchung möglicherweise nicht ausreicht ([Toolvermittelte Systeme erschweren auch Zuordnung und Rekonstruktion, Politecnico di Torino](https://webthesis.biblio.polito.it/41347/1/tesi.pdf)).

Für wichtige Antworten lohnt es sich, einen Datensatz zu erwägen, der Eingabematerial, Systemvorgaben, Nutzeranweisungen, abgerufenes Material, toolgestützte Umformungen, Modellausgabe, generierte Interpretation, Unsicherheit und Nachbearbeitung unterscheidbar macht. Diese Elemente sind im FIELD COMPUTE ATLAS als Bestandteile eines vorgeschlagenen LLM-Laufdatensatzes aufgeführt. Die Checkliste ist ein Entwurfsrahmen, keine Garantie, dass jedes System alle Elemente speichern kann ([FIELD COMPUTE ATLAS, Version 2.1](https://zenodo.org/records/23014733/files/FIELD_COMPUTE_ATLAS_v2_1_FULL_INTEGRATED_20260926.pdf?download=1)).

• Welcher Workflow hat die Antwort erzeugt?
• Lässt sich die Modellausgabe von späteren Änderungen der Anwendung unterscheiden?
• Welche Teile des Aufrufkontexts sind vorhanden und welche fehlen?

Legen Sie das Ziel fest: erneute Ausführung, Rekonstruktion oder Vergleich

Entscheiden Sie vorab, wofür der Datensatz dienen soll. Eine erneute Ausführung, eine Fehlerdiagnose und ein Vergleich sind unterschiedliche Ziele. Ein Datensatz, der hilft, einen früheren Lauf zu erklären, ermöglicht nicht unbedingt die exakte Reproduktion der Ausgabe.

Der genaue interne Modellzustand ist möglicherweise nicht verfügbar. Machen Sie diese Einschränkung deutlich, wenn Sie beschreiben, wozu ein Datensatz dienen kann ([FIELD COMPUTE ATLAS, Version 2.1](https://zenodo.org/records/23014733/files/FIELD_COMPUTE_ATLAS_v2_1_FULL_INTEGRATED_20260926.pdf?download=1)).

• Für eine erneute Ausführung sollten Sie die Eingaben und Konfiguration aufbewahren, die Sie benötigen und speichern dürfen. Benennen Sie Abhängigkeiten, die sich nicht wiederherstellen lassen.
• Bei einer Fehlerdiagnose sollten Sie den Kontext und die Umformungen priorisieren, die zum Verständnis des Ablaufs nötig sind.
• Bei einem Vergleich sollten Sie festhalten, was sich zwischen den Läufen geändert hat und was sich nicht überprüfen ließ.

Prompt- und Anwendungskontext erfassen

Ein Vorlagenname allein zeigt möglicherweise nicht die Anweisungen und Eingaben, die für einen bestimmten Aufruf verwendet wurden. Bewahren Sie, soweit Ihr System dies zulässt, den zusammengesetzten Prompt oder relevante Teile davon zusammen mit einer Kennung für die Prompt- oder Anwendungsversion auf. Für spätere Untersuchungen empfiehlt eine Arbeit zu toolvermittelten Systemen, Aufrufkontext und Provenienz zusammen mit dem Antwortartefakt zu sichern ([Toolvermittelte Systeme erschweren auch Zuordnung und Rekonstruktion, Politecnico di Torino](https://webthesis.biblio.polito.it/41347/1/tesi.pdf)).

Kennzeichnen Sie nicht gespeicherte Felder oder Abhängigkeiten als nicht verfügbar, statt den Eindruck zu erwecken, der Datensatz sei vollständig.

• Halten Sie Systemvorgaben, Nutzeranweisungen und relevante Variablenwerte unterscheidbar, sofern Ihr System sie getrennt darstellt.
• Erfassen Sie nach Möglichkeit die Prompt- oder Anwendungsversion und bewahren Sie sie nur auf, wenn Ihre Governance-Regeln dies zulassen.
• Vermerken Sie wesentliche Vor- oder Nachbearbeitungsschritte, die die Interpretation der Antwort beeinflussen können.

Provenienz von Modell, Abruf und Tools erfassen

Erfassen Sie die Modell- und Anfragedetails, die Ihre Integration beobachten kann, und unterscheiden Sie beobachtete Werte von Annahmen. Welche Felder verfügbar sind, hängt vom jeweiligen Dienst ab; die hier genannten Quellen legen keine anbieterübergreifenden Vorgaben für Anfragedetails fest.

Bei RAG-Workflows (Retrieval-Augmented Generation, also retrieval-gestützter Generierung) oder Tool-Workflows zeigt ein Verweis auf eine Quelle möglicherweise nicht das genaue verwendete Material oder Ergebnis. Bewahren Sie, soweit zulässig, relevante abgerufene Textpassagen, Tool-Eingaben und -Ergebnisse sowie die Umformungen zwischen ihnen auf. Der FIELD COMPUTE ATLAS schlägt vor, abgerufenes Material, toolgestützte Umformungen und generierte Interpretation in einem Laufdatensatz getrennt auszuweisen ([FIELD COMPUTE ATLAS, Version 2.1](https://zenodo.org/records/23014733/files/FIELD_COMPUTE_ATLAS_v2_1_FULL_INTEGRATED_20260926.pdf?download=1)).

• Erfassen Sie verfügbare Modell- und Anfragedetails; vermerken Sie, wenn ein Wert fehlt.
• Halten Sie bei abgerufenem Material nützliche Kennungen oder, sofern zulässig, relevante Inhalte fest. Geben Sie an, wenn der Datensatz nicht zeigt, was dem Modell bereitgestellt wurde.
• Unterscheiden Sie Tool-Eingabe und -Ergebnis von der Interpretation durch das Modell.

Ereignisse verknüpfen und Lücken offenlegen

Eine Trace-Referenz (Kennung einer Ablaufspur) kann helfen, zusammengehörige Eingaben, Ausgaben und Tool-Aktivitäten in Ihrem System zu ordnen. Sie ist ein Verweis auf Datensätze, kein Ersatz für diese. Eine Checkliste für Forschungsrepositorien fordert Provenienz zu Modell, Prompt, Tools und Trace sowie die Offenlegung, wenn Provenienz fehlt ([Das Design kann diese Erklärungen nicht unterscheiden, Zenodo](https://zenodo.org/records/21711582/files/can-an-ai-assisted-research-repository-preserve-a-no-v0.5.0.pdf?download=1)).

Wählen Sie Ereignisabfolgen und Kennungen, die zu Ihrer Implementierung passen. Wenn eine Komponente keinen Verweis oder kein Ereignis bereitstellen kann, halten Sie diese Lücke fest, statt eine Verbindung zu erfinden. Die zitierten Quellen legen keine anbieterübergreifenden Konventionen für Trace-IDs fest.

• Nutzen Sie eine Laufreferenz, um zusammengehörige Datensätze zu ordnen, sofern das hilfreich ist.
• Halten Sie vom Anbieter erzeugte Kennungen, sofern verfügbar, getrennt von Kennungen, die Ihre Anwendung erstellt.
• Machen Sie fehlende, geschwärzte oder nicht verfügbare Provenienz im Datensatz sichtbar.

Strukturierte Datensätze mit Bedacht verwenden

Wenn Sie Prompts, abgerufene Dokumente, Tool-Ausgaben oder Antworten aufzeichnen, kann eine strukturierte Serialisierung Feldgrenzen eindeutig machen. Eine Arbeit zu toolvermittelten Systemen behandelt außerdem Kanonisierung, das Escaping nicht vertrauenswürdiger Inhalte und Hashing auf Grundlage einer kanonischen Darstellung als Protokollierungsmechanismen ([Toolvermittelte Systeme erschweren auch Zuordnung und Rekonstruktion, Politecnico di Torino](https://webthesis.biblio.polito.it/41347/1/tesi.pdf)).

Ein Hash kann helfen zu prüfen, ob ein aufbewahrtes Artefakt mit einem früheren Datensatz übereinstimmt. Er kann keine verworfenen Inhalte wiederherstellen. Dokumentieren Sie bei der Verwendung von Hashes die geprüfte Darstellung und stellen Sie den Hash nicht als Ersatz für den zugrunde liegenden Inhalt dar.

Prompts, abgerufene Passagen, Tool-Ergebnisse und Antworten können Informationen enthalten, auf die nicht alle Personen Zugriff haben sollten. Legen Sie im Rahmen Ihrer Datenverwaltung fest, welche Daten Sie erheben, wer darauf zugreifen darf und wie lange Sie sie aufbewahren. Die passende Regelung hängt vom jeweiligen Kontext ab.

• Definieren Sie klare Grenzen zwischen den aufgezeichneten Feldern und dokumentieren Sie Entscheidungen zu Kanonisierung und Escaping.
• Klassifizieren Sie Trace-Felder entsprechend Ihrem Untersuchungsbedarf und Ihren Datenregeln.
• Dokumentieren Sie Schwärzung, Aufbewahrung und Löschung; geben Sie an, welche Inhalte umgewandelt oder nicht verfügbar sind.