Unsere KI spricht fünf Sprachen. Leider alle fachlich unterschiedlich.

Warum ein Sprachmodell zwar unsere Sätze versteht, aber nicht automatisch unsere Unternehmensbegriffe.

Stell dir eine Bank vor. Ein Mitarbeiter aus dem Kreditgeschäft sucht alle Kreditverträge mit variabler Verzinsung. Eigentlich eine Frage, die ein modernes AI-System problemlos beantworten müsste.

Der erste Treffer kommt aus dem Kreditarchiv. Das zweite System liefert Darlehensvereinbarungen. Compliance hat dieselben Dokumente als rechtliche Unterlagen abgelegt. Im Data Warehouse liegen sie unter loan_agreements, im Dokumentenmanagementsystem unter DOC_TYPE_17.

Fünf Teams. Fünf Sprachen. Ein gemeinsamer Kunde.

Und dann die überraschende Erkenntnis: Alle haben Daten. Aber niemand hat verbindlich definiert, welche fachliche Bedeutung diese Daten gemeinsam haben.

Die Bank und die Situation sind fiktiv. Sie dienen als durchgehendes Architekturbeispiel.

Die Frage, an der unsere Suche scheitert

„Zeige mir alle Kreditverträge mit variabler Verzinsung.“

Bevor wir an Vektoren, Agents oder ein neues Modell denken, müssen wir fragen: Was ist ein Kreditvertrag?

Ist eine Rahmenkreditvereinbarung ein Kreditvertrag? Ist ein Nachtrag ein eigenständiger Vertrag? Gilt eine unterschriebene Offerte bereits als Vertrag? Und muss eine variable Verzinsung ausdrücklich im Dokument stehen oder kann sie über ein referenziertes Produktmodell abgeleitet werden?

Das sind keine Prompt-Engineering-Fragen. Es sind Fachentscheidungen.

Ein LLM kann plausible Antworten generieren. Was es nicht allein festlegen sollte, ist die für alle Teams verbindliche Definition. Sonst bekommen wir fünf überzeugende Antworten und noch immer keine gemeinsame Wahrheit.

Wir brauchen drei verschiedene Bausteine

Ein Business Glossary definiert einen Begriff: „Kreditvertrag“ bezeichnet in unserem Beispiel eine rechtsverbindliche Vereinbarung zur Kreditgewährung und Rückzahlung. Die Definition muss fachlich geprüft werden; sie ist hier illustrativ.

Eine Taxonomy ordnet Konzepte ein: document → contractual_document → loan_agreement.

Eine Ontology beschreibt Beziehungen: loan_amendment → amends → loan_agreement.

Wer das alles „Grammatik“ nennen möchte, darf das als Arbeitsbegriff tun. Technisch ist es genauer, von einem Semantic Vocabulary mit Taxonomie und möglichen Ontologie-Regeln zu sprechen. EBNF beispielsweise beschreibt die Syntax einer formalen Sprache – nicht von selbst die Bedeutung eines Kreditvertrags.

Für den Anfang muss niemand einen riesigen Knowledge Graph bauen. Eine kleine versionierte Definition reicht, um eine wichtige Grenze zu ziehen:

vocabulary:
  id: banking-documents
  version: "1.0"

  concepts:
    loan_agreement:
      label: Kreditvertrag
      parent: contractual_document
      synonyms: [Darlehensvertrag, Loan Agreement]
      definition: "Verbindliche Vereinbarung zur Kreditgewährung."

    loan_amendment:
      label: Kreditvertragsnachtrag
      parent: contractual_document

    variable_interest:
      label: Variable Verzinsung

  relations:
    - subject: loan_amendment
      predicate: amends
      object: loan_agreement

Das ist ein eigenes YAML-Beispielformat, kein offizielles SKOS- oder OWL-Dokument. Wer standardisierte Wissensmodelle benötigt, kann SKOS für Konzepte und OWL für ausgewählte logische Beziehungen einsetzen. Entscheidend sind stabile IDs, klare Abgrenzungen und fachliche Verantwortliche.

Die AI übersetzt Dokumente in diese Sprache

Nehmen wir einen gescannten Kreditvertrag. Die Plattform erzeugt zunächst einen qualitätsgeprüften Text. Danach prüft eine Klassifikationskomponente den Inhalt gegen das zulässige Vocabulary.

Ein mögliches Ergebnis:

{
  "document_id": "DOC-123",
  "extraction_id": "EXT-002",
  "vocabulary_version": "1.0",
  "document_type": "loan_agreement",
  "concepts": ["variable_interest"],
  "evidence": [
    {
      "concept": "variable_interest",
      "page": 7,
      "quote": "Der Zinssatz wird periodisch angepasst."
    }
  ]
}

Mit einer JSON-Schema-Prüfung lässt sich sicherstellen, dass nur zulässige Felder und Konzept-IDs vorkommen. Eine fachliche Validierung prüft zusätzlich, ob Regeln eingehalten werden. Unsichere Zuordnungen werden markiert oder einer Prüfung zugeführt.

Dabei gilt: Eine formal gültige Antwort ist noch keine richtige Klassifikation. Und ein plausibel klingender Beleg muss mit dem tatsächlichen Extrakt übereinstimmen.

Das Ergebnis speichern wir als versionierte Metadatenreferenz, nicht als endgültige Wahrheit ohne Herkunft.

Jetzt kommt der Semantic Layer

Ein Glossary ist noch kein Semantic Layer. Eine gespeicherte Klassifikation auch nicht.

Der Semantic Layer stellt eine fachliche Schnittstelle zu Daten bereit. Er kann definieren, wie Begriffe auf konkrete Tabellen, Felder und Suchindizes abgebildet werden. So müssen Consumer nicht wissen, ob das betreffende Merkmal in MongoDB-Metadaten, einer BigQuery-Tabelle oder einem Retrieval-Index liegt.

Aus der ursprünglichen Frage kann ein kontrollierter, zunächst rein fachlicher Suchplan entstehen:

{
  "action": "find_documents",
  "filters": {
    "document_type": "loan_agreement",
    "concepts": ["variable_interest"]
  },
  "include_related": ["loan_amendment"]
}

Die Plattform prüft die Berechtigungen, übersetzt diese Konzepte in die unterstützten Abfragen und sucht nur in den passenden Dokumenten und Nachträgen. Erst danach kann ein Retriever relevante Passagen finden und ein LLM sie zusammenfassen.

Das ist der Unterschied zwischen „suche irgendwie nach ähnlichem Text“ und „suche gemäß gemeinsam definierten Fachbegriffen“.

Allerdings: Auch ohne vollständigen Semantic Layer können Metadatenfilter die Suche beschleunigen und verbessern. Ob ein Filter tatsächlich schneller ist, hängt vom Index, vom Datenvolumen und vom Query-Plan ab. Der eigentliche Zusatznutzen des Semantic Layers ist die einheitliche fachliche Bedeutung über mehrere Consumer und Datenquellen hinweg.

Zentral muss nicht bedeuten: alles wird zentral entschieden

Lending kennt Konzepte, die Payments nicht benötigt. Compliance stellt andere Fragen als Legal. Fachbereiche dürfen deshalb ihre eigenen Vokabulare erweitern.

Die zentrale Ebene verantwortet gemeinsame Begriffe und deren IDs. Domains definieren Erweiterungen, ohne eine zentrale Definition unbemerkt umzuschreiben. Consumer nutzen die versionierten Konzepte über klar definierte Schnittstellen.

Der erste Schritt ist erstaunlich unspektakulär: Zehn häufig gesuchte Dokumenttypen auswählen, Begriffe und Gegenbeispiele definieren und zwei Teams dieselben Dokumente unabhängig einordnen lassen. Wo die Ergebnisse auseinandergehen, fehlt nicht zwingend ein besseres Modell. Vielleicht fehlt eine gemeinsame Entscheidung.

Mein Fazit

AI kann Sprache beeindruckend gut verarbeiten. Aber ein Unternehmen muss selbst festlegen, was seine Begriffe bedeuten.

Das klingt weniger aufregend als der nächste Agent. Es verhindert aber, dass fünf Agenten fünfmal plausibel danebenliegen.

Eine gemeinsame Fachsprache ist kein Ersatz für AI. Sie ist der Vertrag, an den wir AI binden können.

Welche Begriffe verwendet ihr in mehreren Teams – obwohl sie dort nicht ganz dasselbe bedeuten?

Weiter in dieser Serie: Warum eine Bank mit einer Milliarde Dokumenten dieselben PDFs nicht für jede neue Anwendung erneut lesen sollte.