Verifikations-Pipelines sind parametrisierte Prüfungen. Sie analysieren Dateien, müssen aber auch wissen, womit sie eine Datei vergleichen sollen. Wurde behauptet, dieses Bild sei an einem bestimmten Datum aufgenommen worden? Soll diese Audioaufnahme von einer bestimmten Organisation stammen? Gibt dieses Dokument vor, ein bestimmtes Ereignis zu behandeln? Ohne Antworten auf Fragen wie diese kann eine Verifikations-Pipeline nur allgemeine Beobachtungen liefern – sie kann nicht mit einer behaupteten Grundwahrheit vergleichen.
Verification Contexts sind der Mechanismus, der diese Grundwahrheit bereitstellt. Ein Context ist eine benannte Menge von Behauptungen, die einem Projekt zugeordnet ist. Man erstellt so viele Contexts, wie man für ein Projekt benötigt, und befüllt sie mit den relevanten Behauptungen, bevor eine Verifikations-Pipeline gestartet wird. Wenn die Pipeline läuft, liest sie diese Behauptungen und prüft den Inhalt dagegen.
Jeder Verification Context ist eine benannte Menge einfacher Key-Value-Behauptungen. Die Keys sind frei wählbar, aber es gibt konventionelle Namen, die in mehreren Pipeline-Definitionen auftauchen:
| Key | Typischer Inhalt |
|---|---|
claimed_source | Die Organisation oder das Medium, dem der Inhalt zugeschrieben wird |
claimed_date | Das Datum, an dem der Inhalt angeblich erstellt wurde |
claimed_location | Geografischer Ort, der mit dem Inhalt assoziiert wird |
claimed_topic | Thema oder Ereignis, mit dem sich der Inhalt befasst |
claimed_author | Benannte Person, die als Ersteller angegeben wird |
original_language | Deklarierte Quellsprache des Inhalts |
Pipeline-Definitionen geben an, welche Context-Felder sie benötigen und welche optional sind. Fehlt ein Pflichtfeld beim Starten eines Runs, lehnt die Plattform den Request von vornherein ab und teilt mit, welche Felder fehlen. Dieser Vertrag zwischen Pipeline und Context wird geprüft, bevor überhaupt eine Analyse stattfindet – ein Run muss also nie raten, wenn ein Wert fehlt.
Beim Start eines Verifikations-Runs liest die Plattform den relevanten Context und schreibt ihn für diesen Run fest. Jede Stage der Pipeline prüft den Inhalt gegen diesen festgeschriebenen Snapshot – nicht gegen das, was der live aktuelle Context in diesem Moment gerade sagt.
Dieses Snapshot-Verhalten ist eine bewusste Designentscheidung. Sie bedeutet: Wird ein Kontextwert nach dem Start eines Runs aktualisiert, ist der laufende Run davon unberührt. Außerdem lässt sich eine Verifikation Wochen oder Monate später erneut betrachten, um die exakten Behauptungen einzusehen, die bei diesem Run galten – was für Audit-Trails und für das Verständnis wichtig ist, warum ein Run das gelieferte Urteil erzeugt hat.
Der Snapshot dient auch als Dokumentation. Beim Review eines abgeschlossenen Runs in der Plattform-UI können Operatoren den Context aufklappen und die exakten Behauptungen sehen, gegen die die Pipeline geprüft hat. Es gibt keine Unklarheit darüber, wovon die Pipeline zum Zeitpunkt des Runs ausgegangen ist.
Stellen wir uns ein Projekt vor, das für die Verifikation von Nachrichtenartikeln eingerichtet wurde. Vor dem Start der Pipeline zur Nachrichtenartikel-Verifikation für einen bestimmten Artikel erstellt (oder aktualisiert) ein Operator einen Context mit:
{
"claimed_source": "Reuters",
"claimed_date": "2024-03-15",
"claimed_topic": "EU-Parlamentsabstimmung zum AI Act",
"claimed_author": "Jane Smith"
}
Die Pipeline erhält diesen Context zusammen mit dem Artikeltext und analytischen Anweisungen. Sie prüft, ob das Veröffentlichungsdatum im Artikel mit claimed_date übereinstimmt, ob die Autorenzeile mit claimed_author übereinstimmt und ob der Inhalt mit dem bekannten Stil und Themenspektrum der angegebenen Quelle konsistent ist. Ohne diese Ankerpunkte hätte die Pipeline keine Baseline zum Vergleich. Mit ihnen kann sie ein strukturiertes Urteil liefern, das spezifische Unstimmigkeiten benennt.
Das gleiche Projekt könnte Dutzende von Artikeln ansammeln, jeder mit leicht unterschiedlichen Behauptungs-Metadaten. Operatoren können separate Contexts pro Artikel pflegen oder einen einzigen wiederverwendbaren Context vor jedem Run aktualisieren. Da der Context beim Start des Runs festgeschrieben wird, bleibt die Integrität historischer Runs in beiden Fällen erhalten.
Contexts werden auf Projektebene verwaltet: Man kann sie auflisten, erstellen, aktualisieren und entfernen, wie es die eigenen Verifikationsanforderungen erfordern. Für Operatoren, die die Context-Abdeckung über alle Projekte einer Organisation hinweg prüfen möchten, gibt es zusätzlich eine organisationsweite Übersicht.
Aktualisierungen wirken sich sofort auf jeden neuen Run aus, der danach gestartet wird – es gibt keinen Publish-Schritt oder ein Versions-Gate am Context selbst, da der Snapshot-Mechanismus laufende Runs bereits von späteren Änderungen isoliert. Das hält den Arbeitsalltag einfach: die gewünschten Behauptungen festlegen, dann den Run starten.
Die genaue API-Referenz zum programmatischen Erstellen und Verwalten von Verification Contexts findest du unter docs.crowdee.ai.
Artikel teilen: