Wer hat eigentlich die Bedeutung von Kreditvertrag geändert?

Eine neue Fachdefinition ist kein Textupdate. Sie kann das Verhalten einer ganzen Datenplattform verändern.

Montag, 09:15 Uhr. Ein Team verbessert die Dokumentklassifikation einer Bank. Bisher gab es „Kreditvertrag“ und „Nachtrag“. Die neue Fachsprache unterscheidet jetzt Kreditvertrag, Rahmenkreditvereinbarung und Kreditabruf.

Die neue Version besteht die Tests. Das Team veröffentlicht sie.

Dienstag fragt das Kreditgeschäft, warum weniger Kreditverträge gefunden werden. Compliance wundert sich über neue Auswertungszahlen. Der RAG-Chat beantwortet dieselbe Frage plötzlich anhand anderer Dokumente.

Drei Systeme verhalten sich anders – obwohl kein einziger PDF-Scan geändert wurde.

Die Bank und der Vorfall sind fiktiv. Sie zeigen ein Risiko, das bei versionierter Semantik bewusst behandelt werden sollte.

Die gefährliche Annahme: Wir haben doch nur einen Begriff geändert

Eine Taxonomie ist für mich nicht bloß ein Glossary, das jemand gelegentlich pflegt. Sobald Klassifikatoren, Suchfilter, APIs und Auswertungen diese Begriffe verwenden, werden ihre Definitionen zu Contracts zwischen Systemen.

Stell dir vor, Version 1.3 kennt nur loan_agreement. In Version 1.4 kommt credit_facility hinzu. Einige Dokumente, die früher als Kreditvertrag galten, sollen nun als Rahmenkreditvereinbarung geführt werden.

Die YAML-Datei ist schnell angepasst. Die Folgen nicht.

Welche bestehenden Klassifikationen sind noch korrekt? Müssen RAG-Indizes angepasst werden? Welche Reports vergleichen historische Zahlen? Und darf ein Consumer die neue Definition automatisch übernehmen?

Das sind Release- und Migrationsfragen. Keine Kosmetik.

Ein fachlicher Contract braucht eine Identität

Ein mögliches versioniertes Vocabulary sieht so aus:

grammar:
  id: enterprise-banking
  version: "1.4"

  concepts:
    loan_agreement:
      label: Kreditvertrag
      parent: contractual_document

    credit_facility:
      label: Rahmenkreditvereinbarung
      parent: contractual_document

    loan_drawdown:
      label: Kreditabruf
      parent: financial_transaction

„Grammar“ ist hier ein Name für eine eigene Konfigurationssprache, keine EBNF-Grammatik. Entscheidend sind stabile IDs, dokumentierte Bedeutungen, fachliche Owner und unveränderliche veröffentlichte Versionen.

Wenn sich nur die Beschriftung „Darlehensvertrag“ zu „Kreditvertrag“ ändert und die Konzept-ID gleich bleibt, ist das häufig ein kompatibles Update. Wenn wir die Definition der ID ändern, ist es eine andere Art von Veränderung.

Deshalb reicht ein Versionsstring allein nicht. Wir brauchen einen semantischen Diff.

Ein Diff, der mehr sagt als „drei Zeilen geändert“

Für einen Release-Kandidaten würde ich explizit festhalten, welche Konzepte hinzugefügt, umbenannt, neu abgegrenzt oder abgekündigt werden:

release:
  vocabulary: enterprise-banking
  from: "1.3"
  to: "1.4"

  changes:
    - concept: credit_facility
      type: added
    - concept: loan_agreement
      type: definition_narrowed

  expected_impact:
    - semantic_classification
    - retrieval_metadata
    - reporting

Das ist ein Beispiel für einen eigenen Change Contract. Er kann automatisiert validiert werden, ersetzt aber keine fachliche Prüfung.

Wichtig ist die Unterscheidung: Eine neue Bezeichnung lässt sich häufig über Aliase oder Labels behandeln. Eine neue Abgrenzung verändert möglicherweise, welche Dokumente eine Klasse erhalten. Diese Änderungen sollten nicht denselben Freigabeprozess durchlaufen.

Welche Dokumente müssen neu bewertet werden?

Unsere Bank hat eine Milliarde Dokumente. Müssen wir nun alles neu klassifizieren?

Nicht zwangsläufig. Und vor allem müssen wir nicht jedes PDF erneut extrahieren, wenn das vorhandene Markdown dafür ausreicht.

Die Basisextraktion bleibt erhalten. Semantische Klassifikationen sind eigene, versionierte Ableitungen:

Original PDF
     ↓
Immutable Markdown (EXT-002)
     ├── Classification C-13 → Grammar 1.3
     └── Classification C-14 → Grammar 1.4

Ein Diff erlaubt eine Impact Analysis: Vielleicht sind zunächst alle Dokumente mit loan_agreement, unknown und einige verwandte Kategorien Kandidaten. Aber genau hier liegt eine Falle.

Wenn wir ausschließlich die bisher als Kreditvertrag klassifizierten Dokumente neu prüfen, übersehen wir möglicherweise eine Rahmenkreditvereinbarung, die bislang als Korrespondenz abgelegt wurde.

Ein Kandidatenfilter ist also keine Garantie auf Vollständigkeit. Wir sollten seine Trefferquote anhand repräsentativer Stichproben messen und den Suchraum bei Bedarf erweitern. Bei grundlegenden Änderungen kann auch eine vollständige Reclassification notwendig werden.

Das ist unbequem, aber ehrlicher als die Behauptung, Versionierung mache jede Migration automatisch kostenlos.

So würde ich ein Upgrade durchführen

Ein kontrollierter Versionswechsel könnte aus fünf Stationen bestehen:

1. Candidate veröffentlichen. Version 1.4 wird als unveränderlicher Release-Kandidat registriert. Version 1.3 bleibt produktiv.

2. Shadow Classification ausführen. Auf einer repräsentativen Stichprobe und auf ausgewählten potenziell betroffenen Dokumenten laufen alte und neue Klassifikation nebeneinander. Wir vergleichen ihre Ergebnisse, einschließlich unerwarteter Veränderungen außerhalb der geplanten Kategorien.

3. Auswirkungen sichtbar machen. Wie viele Dokumente wechseln die Klasse? Wie verändern sich wichtige Suchfragen? Welche Reports oder Datenprodukte sind betroffen? Und wo sinkt die Qualität?

4. Domain-Freigabe einholen. Fachliche Owner entscheiden anhand der Ergebnisse, ob die neue Version freigegeben und welche Consumer wann migriert werden. Gemeinsame Definitionen benötigen zentrale Governance, spezialisierte Erweiterungen können Domain-Verantwortung bleiben.

5. Kontrolliert aktivieren. Die Consumer bekommen einen versionierten Zugriff oder einen expliziten Pointer auf die neue freigegebene Projektion. Bei einem Problem kann der Pointer zurückgesetzt werden – vorausgesetzt, die alte Projektion und die kompatiblen Indizes wurden erhalten.

Grammar 1.3 (Production) ────────────────────────┐
                                                  │
Grammar 1.4 (Candidate) → Shadow → Impact → Approve
                                                  │
                                        Versionierter Switch
                                                  │
                                          Grammar 1.4 (Active)

Ein Rollback der Auswahl ist nicht dasselbe wie ein Rollback aller externen Nebenwirkungen. Reports, Exporte und bereits getroffene Entscheidungen brauchen eigene Konsistenz- und Nachvollziehbarkeitsregeln.

Was passiert mit unseren RAG-Daten?

Das ist die gute Nachricht: Ein neues fachliches Label verändert nicht automatisch den Dokumententext.

Wenn sich nur Klassifikationen und Metadatenfilter ändern, können bestehende Chunks und Embeddings normalerweise erhalten bleiben. Dann aktualisieren wir die betroffene Metadatenprojektion beziehungsweise den Suchindex.

Wenn wir dagegen das Vocabulary verwenden, um zusätzlichen Text vor dem Embedding anzureichern, kann eine Grammar-Änderung die Eingabe des Embedding-Modells verändern. Dann müssen die betroffenen Vektoren erneut erzeugt werden.

Deshalb würde ich Extraction-Version, Classification-Version und RAG-Index-Version getrennt erfassen. Wer sie auf dieselbe Versionsnummer zwingt, koppelt drei unterschiedliche Lebenszyklen unnötig zusammen.

GitOps, aber mit fachlicher Verantwortung

Ich würde Semantic Contracts über Git verwalten: Pull Request, automatisierte Schema- und Referenzprüfung, dokumentierter Diff und ein fachlicher Review.

Die CI erkennt ungültige IDs, zirkuläre Beziehungen oder unzulässige Strukturänderungen. Sie kann auch Regressionstests auf einem kuratierten Dokumentensatz starten.

Aber kein grüner Build beweist, dass die neue Bedeutung fachlich richtig ist. Dafür brauchen wir die Personen, die das Geschäft und die Folgen kennen.

Zentral würde ich nur gemeinsame Begriffe und verbindliche Regeln regeln. Domains sollen eigene Konzepte hinzufügen, Versionen testen und einen passenden Migrationszeitpunkt wählen können. Föderation bedeutet nicht Freiheit von gemeinsamen Contracts; sie bedeutet Autonomie innerhalb dieser Contracts.

Ein machbarer erster Schritt

Versioniere zehn häufig verwendete Konzepte. Ändere bewusst eine Definition und beantworte dann drei Fragen: Welche Dokumente wechseln die Klasse? Welche Suche verändert ihr Ergebnis? Und wie würde ein Consumer auf den bisherigen Stand zurückgehen?

Wenn ihr diese Fragen beantworten könnt, habt ihr mehr als ein Glossary. Ihr habt den Anfang eines kontrollierbaren semantischen Lifecycles.

Die zentrale Plattform sollte gemeinsame Bedeutung schützen. Sie muss nicht jede fachliche Veränderung selbst entscheiden.

Und wenn am Dienstag wieder jemand fragt, wer „Kreditvertrag“ geändert hat, sollte die Antwort in der Release-Historie stehen – inklusive der Auswirkungen.

Wie testet ihr heute Änderungen an fachlichen Definitionen, bevor sie mehrere Systeme gleichzeitig erreichen?