Jenseits eines einzigen Abrufwegs: Kanonisches Wissen, RAG und Echtzeitabfragen für Unternehmensagenten

Ein Schlagzeile, die behauptet, ein neues offenes Format ersetze die Vektor-Datenbank, weckt Skepsis. Der Teil dieser Behauptung, den man beibehalten sollte, ist nicht die Geschichte vom Ersatz, sondern eine dringendere architektonische Frage: Werden zu viele verschiedene Arten von Unternehmenswissen über denselben Abrufmechanismus abgewickelt?

In einem Unternehmen umfasst „Wissen“ sehr unterschiedliche Dinge. Ein Support-Ticket zählt dazu, genauso wie ein 60-seitiges Designdokument, ein Datenbankschema, eine Metrikdefinition oder ein Notfallhandbuch. Auch die aktuelle Anzahl an verzögerten Lieferungen zählt dazu. Diese Dinge verhalten sich unterschiedlich, daher ist es seltsam, dass ein KI-Agent auf alle auf dieselbe Weise zugreifen sollte.

Die sinnvolle Einordnung liegt nicht darin, OKF gegen RAG abzuwägen, und es bedeutet auch nicht, dass Vektordatenbanken tot sind. Es handelt sich um eine praktische Einteilung in drei Kategorien: Wissen, das abgerufen werden soll, Wissen, das als Standard gespeichert werden soll, und Wissen, das in Echtzeit abgefragt werden soll.

Ein gewöhnliches Unternehmensproblem

Stellen Sie sich ein fiktives Logistik-SaaS-Unternehmen mit etwa 120 Ingenieuren vor. Wie viele Firmen, die mit Agenten experimentieren, hat es interne Dokumente, Support-Abläufe, Betriebssysteme, Metriken und Anleitungen mit einer Agentenplattform verbunden. Für den größten Teil der Fragen funktioniert das gut.

Dann fragt jemand nach dem Pünktlichkeitsgrad der Lieferungen, und das System liefert drei verschiedene Definitionen:

• Das Daten-Team zählt die Lieferungen, die bis zum versprochenen Datum ankommen.
• Das Produkt-Dashboard verwendet eine etwas andere Berechnungsmethode.
• Die für Kunden zugänglichen Dokumentationen berücksichtigen nicht stornierte Bestellungen und Rücksendungen.

Nichts davon ist Unsinn. Verschiedene Teams haben sie aus unterschiedlichen Gründen verfasst. Das Problem beginnt, wenn ein Agent entscheiden muss, welche Version als autoritativ gilt. Eine Vektordatenbank kann anzeigen, was semantisch ähnlich ist. Sie hat jedoch keine Möglichkeit, herauszufinden, welche Version das Unternehmen als Definition festgelegt hat. Das ist ein separates Problem.

Relevanz ist keine Autorität

Ein standardmäßiger RAG-Fluss liefert jedes Dokument zurück, das übereinstimmt. Wenn drei Dokumente eine Metrik auf drei verschiedene Arten beschreiben, werden alle drei zurückgegeben. Bessere Ranking-Methoden, zusätzliche Metadaten, erneutes Ranking, ein größeres top_k oder ein größeres Kontextfenster können alle helfen. Keines davon beantwortet die organisatorische Frage, welche Definition die offizielle ist.

Die eigentliche Schwäche liegt also nicht einfach darin, dass RAG Halluzinationen erzeugt. Relevanz und Autorität sind unterschiedliche Eigenschaften, und Unternehmensagenten benötigen zunehmend beide.

Wenn Struktur die Bedeutung ist

Ein weiterer Grund, warum nicht alle Kenntnisse in einen einzigen Abrufprozess passen, betrifft die Struktur. Nehmen wir eine Tabelle mit zehn Zeilen und sieben Spalten – ihre Bedeutung liegt nicht allein in den Wörtern, sondern entsteht aus der Beziehung zwischen Überschriften, Zeilenbezeichnungen, Werten, Einheiten sowie dem umgebenden Kontext.

Wenn man diese Tabelle in 256-Token-Blöcke aufteilt, kann ein Fragment beispielsweise nur ein Paar von Überschriften wie „Region“ und „Umsatz“ enthalten, während ein anderes „Ost 2,1 M“ und „West 1,8 M“ enthält. Das Modell kann die Beziehungen korrekt wiederherstellen – oder auch nicht.

Bei Prosa ist das Aufteilen in Blöcke in der Regel gewünscht. Bei strukturierten Kenntnissen wird daraus jedoch ein seltsamer Umweg:

1. mit der Struktur beginnen
2. sie in Text umwandeln
3. den Text in Fragmente aufteilen
4. die Fragmente einbetten
5. einige davon abrufen
6. vom Modell die ursprüngliche Struktur wiederherstellen lassen

Irgendwann stellt sich die Frage, ob das Ganze überhaupt in Teile aufgeteilt werden sollte. Dasselbe gilt für Datenbank-Schemata, Verknüpfungspfade, Konfigurationsregeln, Metrikformeln, SLAs und Betriebsverfahren. Strukturierte Inhalte sind in RAG nicht verboten. Der Punkt ist, dass Struktur einer besonderen Behandlung bedarf, wenn ihr Verlust die Bedeutung verändert.

Die Vektor-Datenbank war niemals die Quelle der Wahrheit

Das fiktive Unternehmen hatte ein weiteres bekanntes Problem: Das Wissen war verstreut. Schemata wurden in Datenbankkommentaren, GitHub-Wikis, Confluence und Migrationen beschrieben. Metrikdefinitionen befanden sich in Analyse-Dashboards, Produktbeschreibungen, Dokumenten des Daten-Teams und alten Präsentationen. Runbooks waren in Notion, Incident-Tickets, Slack und GitHub verteilt. Ein Teil der Verknüpfungslogik befand sich hauptsächlich im Kopf der Person, die am längsten an dem Projekt gearbeitet hatte.

Das Aufbauen einer Vektordatenbank darauf hat keine Quelle der Wahrheit ergeben. Es entstand lediglich ein suchbarer Index bestehender Inkonsistenzen. Das hat seinen Wert, aber es stellt keine Governance dar.

Was OKF hinzufügt

Was das Open Knowledge Format auszeichnet, ist nicht Markdown, das bereits existiert. Es geht vielmehr darum, Unternehmenswissen ausdrücklich maschinenlesbar zu machen, ohne dass es für Menschen unzugänglich wird. Konzeptionell beginnt eine Konzeptdatei mit strukturierten Metadaten:

type: metric
name: on_time_delivery_rate
owner: data-platform
reviewer: product
trust_tier: verified
stale_after: 1 day
related:
- shipments
- sla_definition

und setzt mit einer für Menschen verfassten Erklärung fort:

# On-Time Delivery Rate
Percentage of shipments delivered on or before the current
promised delivery date.
## Excludes
- cancelled shipments
- test orders
- returns

Der Agent erhält nicht länger nur einen Text über pünktliche Lieferung. Er kann außerdem erfahren, wer die Definition besitzt, ob sie aktuell ist, ob sie überprüft wurde, worauf sie beruht und welche anderen Konzepte damit verbunden sind. Die Frage ändert sich von der, welcher Textabschnitt am ähnlichsten ist, zu der, welches Konzept kanonisch ist und ob es sicher ist, es zu verwenden.

OKF ersetzt RAG nicht

Hier weicht die Schlussfolgerung vom Überschriftentext ab. Ein genauereres Bild ergibt sich aus einer Abfolge: Kanonisches Wissen befindet sich in OKF, exploratives Wissen in RAG und der aktuelle Zustand in Live-Systemen.

Kanonisches Wissen umfasst Datenbankschemas, Definitionen von Metriken, SLAs, Geschäftsregeln, Runbooks sowie Informationen zur Zuständigkeit. Die gestellte Frage dazu lautet in der Regel, welche offizielle, aktuelle Definition gilt.

Erkundungswissen umfasst historische Berichte, Vorgangsverläufe, Support-Gespräche, Designdokumente, Fallstudien sowie Kundenfeedback. Die Frage ist hier, welche Informationen für die gesuchten Informationen relevant sind. Genau hier ist RAG besonders stark.

Live-Zustand umfasst die heutige Pünktlichkeitsrate, den aktuellen Kundensaldo, aktive Vorfälle, offene Bestellungen sowie die Lagerbestände. Die Frage ist, was im Moment zutrifft – und ein Vektorindex ist vermutlich der falsche Ansatz, um sie zu beantworten. Das Betriebssystem, das die Zahlen bereitstellt, sollte sie liefern.

Einige Daten sollten nicht abgerufen werden

Hier wird die Architektur interessanter. Angenommen, ein Benutzer bittet um die fünf umsatzstärksten Kunden dieses Quartals. Eine solche Designvariante zieht Dokumente und Daten in den Index und lässt das Modell sie sortieren. Das ist möglich, doch es gibt einen besseren Ablauf: Der Agent sucht die kanonische Bedeutung von Umsatz heraus, erstellt eine Abfrage und führt sie gegen das Datensystem durch. Zum Beispiel:

SELECT
customer_name,
SUM(revenue) AS total_revenue
FROM sales_data
WHERE quarter = 'Q3_2026'
GROUP BY customer_name
ORDER BY total_revenue DESC
LIMIT 5;

Der Agent erhält nun zwei Dinge aus zwei Quellen. Die Bedeutung stammt aus der kanonischen Wissensschicht. Die aktuellen Werte stammen vom System, das die Daten tatsächlich besitzt. Der Agent holt keine Daten mehr ab. Er holt zunächst die Struktur ab und fragt anschließend das Live-System ab.

Ein Agent, drei Wissenswege

Angesichts dieser Unterscheidung werden einige Beispielfragen auf unterschiedliche Weise weitergeleitet:

• Was bedeutet pünktliche Lieferung? Konsultieren Sie die kanonische Definition der Metrik.
• Wie hoch ist die heutige Pünktlichkeitsrate? Nutzen Sie die Berechnungslogik aus der kanonischen Definition und fragen Sie anschließend das Live-Lager ab.
• Warum ist die Rate im letzten Quartal gesunken? Verknüpfen Sie die kanonische Definition mit historischen Lagerdaten sowie gegebenenfalls RAG-Daten aus Incidentsberichten und Frachtnotizen.

Was ist mit Kunden X im ersten Quartal passiert? Führen Sie eine Suche in früheren Tickets, Notizen und Berichten durch.

Es liegt ein Datenbankausfall vor – was jetzt? Verwenden Sie das offizielle Handbuch.

Der Ansprechpartner bleibt derselbe, nur die Pfade unterscheiden sich. Darüber zu diskutieren ist produktiver als darüber, ob Vektordatenbanken ersetzt werden.

Der Router rückt in den Mittelpunkt

Bei mehreren Wissenspfaden muss etwas daraus auswählen. Ein erster Router kann absichtlich einfach gestaltet werden.

class HybridKnowledgeRouter:
    def __init__(self, okf, rag):
        self.okf = okf
        self.rag = rag

    def classify(self, query: str) -> str:
        q = query.lower()

        if any(word in q for word in [
            "schema", "column", "definition",
            "metric", "sla", "runbook"
        ]):
            return "canonical"

        if any(word in q for word in [
            "history", "report", "example",
            "case study", "what happened"
        ]):
            return "exploratory"

        if any(word in q for word in [
            "today", "current", "now",
            "latest value", "how many"
        ]):
            return "live"

        return "hybrid"

Seine Context-Methode folgt:

def get_context(self, query: str):
    query_type = self.classify(query)

    if query_type == "canonical":
        return self.okf.lookup(query)

    if query_type == "exploratory":
        return self.rag.search(query)

    if query_type == "live":
        concept = self.okf.lookup_relevant_schema(query)
        return {
            "concept": concept,
            "requires_live_query": True
        }

    return {
        "okf": self.okf.search(query),
        "rag": self.rag.search(query)
    }

Es handelt sich hierbei nicht um eine für die Produktion geeignete Klassifizierung, was akzeptabel ist. Das erste Ziel besteht lediglich darin herauszufinden, ob die Trennung nützlich ist.

Warum nicht einfach BM25 oder bessere Metadaten?

Bevor ein weiteres Verfahren hinzugefügt wird, muss die Idee einer ordentlichen Überprüfung standhalten.

BM25. Für strukturierte Texte kann es hervorragend sein. Genaue Feldnamen sind wichtig, Schlüsselwörter spielen eine Rolle und eine deterministische Rangliste hilft. Bei abfragbaren Strukturen ähnlich einem Schema kann es Embeddings übertreffen. Allerdings bleibt die zugrunde liegende Architektur unverändert. Eine Tabelle, die in einem Suchindex gespeichert ist, muss weiterhin auf irgendeine Weise dargestellt und abgerufen werden, wodurch nur bessere Fragmente entstehen, die dennoch weiterhin Fragmente bleiben. BM25 verbessert die Suche, schafft aber keine Autorität, kein Eigentumsrecht, keine Aktualität oder kanonische Semantik.

Mehr RAG-Metadaten. Das ist ebenfalls angemessen. Es können Felder wie die folgenden hinzugefügt werden, wobei eine strenge Filterung angewandt wird:

document_type
owner
version
effective_date
trust_tier
source

Das mag für viele Systeme ausreichen. Doch sobald Metadaten das Mittel sind, das dem Agenten mitteilt, was autoritativ, aktuell, relevant und sicher ist, wird bereits eine strukturierte Wissensschicht aufgebaut. Zu diesem Zeitpunkt ist es übersichtlicher, das Konzept direkt zu formulieren, anstatt es als seltsames Dokument in einem allgemeinen Index zu verstecken.

Live-Abfragen bringen ein Sicherheitsproblem mit sich

Sobald einem LLM erlaubt wird, Abfragen an Betriebssysteme zu stellen, steigen die Risiken erheblich. Das will niemand:

DROP TABLE shipments;

Auch das nicht:

SELECT * FROM shipments;

Es wird gegen eine Tabelle mit 50 Millionen Zeilen gearbeitet, weil das Modell neugierig wurde. Die bessere Vorgehensweise besteht darin, dem Agenten keinen Zugriff auf die Datenbank zu gewähren, sondern ihm nur eingeschränkte Abfragemöglichkeiten zu bieten. Ein Schema-Konzept kann die zulässige Form einer Abfrage beschreiben:

data_source: analytics.shipments
allowed_columns:
  - shipment_id
  - customer_id
  - carrier_id
  - status
  - promised_delivery_date
  - actual_delivery_date

required_filters:
  - tenant_id

max_result_rows: 1000
access_mode: read_only

Die erzeugte Abfrage wird anschließend anhand dieser Richtlinie überprüft:

def validate_query(query, policy):
    checks = [
        uses_allowed_table(query, policy),
        selects_allowed_columns(query, policy),
        contains_required_filters(query, policy),
        respects_row_limit(query, policy),
        is_read_only(query),
    ]

    if not all(checks):
        raise UnsafeQueryError()

    return True

In der Produktion gehören hier weitere Schritte hinzu: getrennte Ausführungsberechtigungen, Isolierung der Nutzer außerhalb des Modells, Berechtigungen auf Datenbankebene, Limits für Zeilen und Kosten sowie Protokollierung jeder ausgeführten Abfrage. Das Leitprinzip ist, dass das Modell Vorschläge macht und die Infrastruktur entscheidet, ob ein Vorschlag ausgeführt werden darf.

Kanonisches Wissen benötigt einen Eigentümer

Eine einzige Quelle der Wahrheit klingt wunderbar – solange niemand sie aktualisiert. Eigentumsverhältnisse und Aktualität sind wichtiger als das Dateiformat. Ein Konzept kann Felder wie diese enthalten:

owner: data-platform@company.io
reviewer: product-analytics@company.io
stale_after: 7 days

Immer wenn eine Metrikdefinition geändert wird, muss die entsprechende Wissensaktualisierung in derselben Dokumentation enthalten sein. Wenn sich ein Schema ändert, sollte seine kanonische Form neu erzeugt oder überprüft werden. Die Nutzer sollten nicht das erneut eingeben, was die Datenbank bereits kennt, weshalb maschinenbekannte Fakten erzeugt werden:

for table in database.tables():
  generated = generate_okf_schema(table)
  save(generated)

Menschen prüfen anschließend, was beurteilt werden muss: geschäftliche Bedeutung, Eigentumsverhältnisse, sensible Spalten, zulässige Nutzung, Beziehungen sowie Einschränkungen. Wird dies übersprungen, wird die einzige Quelle der Wahrheit zu einem weiteren Archiv, das veraltet ist.

Versionierung ist wichtiger, als es scheint

Kanonisch bedeutet nicht zeitlos. Stellen Sie sich vor, das Unternehmen ändert die Definition der termingerechten Lieferung von „termingerechte Auslieferungen geteilt durch die Gesamtbestellung“ auf „termingerechte Auslieferungen geteilt durch die Gesamtzahl der gelieferten Artikel“. Wenn die alte Definition einfach überschrieben wird, könnte ein Mitarbeiter, der eine historische Frage beantwortet, die heutige Logik auf den Bericht vom letzten Jahr anwenden. Daher benötigen Konzepte Versionen oder Gültigkeitsdaten:

versions:
  - version: "2.0"
    active: true
    effective_from: 2026-06-10
    change: "Denominator changed to delivered shipments"

  - version: "1.0"
    active: false
    effective_from: 2025-01-01
    effective_to: 2026-06-09

Zwei Fragen erhalten nun unterschiedliche Antworten. Eine Frage zur Definition von OTD verwendet die aktuelle Version, während eine Frage dazu, warum der Bericht für Q1 2026 dies anders berechnet hat, die zu diesem Zeitpunkt gültige Version verwendet. „Kanonisch“ bedeutet nicht unveränderlich – es bedeutet kontrolliert.

Wenn RAG und kanonisches Wissen unterschiedlicher Ansicht sind

Früher oder später wird der Agent ein altes Dokument abrufen, das besagt, OTD sei das Verhältnis von termingerecht versandten zu insgesamt bestellten Sendungen, während das kanonische Konzept von termingerecht gelieferten zu insgesamt gelieferten Sendungen spricht. Das System benötigt eine explizite Prioritätsregel sowie für Widersprüche eine Antwort wie:

if contradiction(okf_context, rag_context):
  log_conflict(…)
  prefer(okf_context)

Es kann dem Benutzer sogar mitteilen: Ein älteres Dokument steht im Widerspruch zur aktuellen Metrikdefinition, und es wurde die aktuell überprüfte Definition verwendet. Der Agent tut somit mehr als nur antworten – er deckt Wissensdefizite auf, was zu den wertvollsten Nebeneffekten dieses Designs gehören kann.

Mehr als nur die endgültige Antwort messen

Bei dieser Architektur reicht es nicht aus, nur die Häufigkeit von Halluzinationen zu tracken. Ebenso sollte gemessen werden, wie das System zu einer Antwort gelangt ist, beispielsweise:

% queries routed to correct source
% canonical lookups with stale concepts
% live queries rejected by policy
% RAG/OKF conflicts detected
% concepts past stale_after
% concepts with no active owne

Eine falsche Endlösung kann aus ganz unterschiedlichen Fehlern entstehen. Das Modell könnte falsch argumentiert haben. Der Router könnte RAG gewählt haben, obwohl kanonisches Wissen erforderlich war. Das kanonische Konzept könnte veraltet sein. Die aktuelle Abfrage könnte richtig gewesen sein, während die Definition der Metrik falsch war. Es handelt sich dabei um verschiedene Ingenieurprobleme, und die Beobachtbarkeit sollte sie voneinander trennen.

Wann ist das Overengineering?

Ein fünfköpfiges Ingenieurteam mit nur wenigen internen Dokumenten hat vermutlich keinen Bedarf an einer Wissensverwaltungsplattform. Wenn der Anwendungsfall hauptsächlich darin besteht, relevante Informationen in Tausenden von Dokumenten zu finden, reicht RAG möglicherweise aus. Wenn sich das Wissen nur selten ändert, lohnt sich eine Mechanismus zur Aktualisierung möglicherweise nicht. Wenn heute niemand für die Dokumentation verantwortlich ist, wird das Hinzufügen von YAML-Frontmatter keine Kultur der Verantwortung schaffen.

Das Muster wird attraktiv, wenn mehrere dieser Bedingungen zutreffen:

• Mehrere Teams definieren jeweils die gleichen Konzepte
• Agenten führen operative Aktionen aus
• Schemata und Metriken werden häufig geändert
• Falsche Kenntnisse kosten das Unternehmen echte Verluste
• Definitionen benötigen Verantwortliche sowie eine Nachverfolgungsliste
• Live-Daten müssen mit kanonischen Semantiken verknüpft werden

Je mehr davon zutreffen, desto mehr lohnt sich die Aufteilung.

Wo MCP passt

Wenn Agenten auf mehrere Wissens- und Datensätze zugreifen, wird MCP zu einem natürlichen Integrationspunkt. Ein Agent kann beispielsweise folgende Funktionen nutzen:

get_canonical_metric_definition
get_schema
search_historical_documents
query_warehouse
get_runbook

Der Router wählt den geeigneten aus. OKF beschreibt Konzepte und Einschränkungen, MCP stellt Werkzeuge und Ressourcen bereit, Live-Systeme bleiben die Eigentümer der aktuellen Daten, und RAG bleibt die Entdeckungsschicht für unstrukturierte Historie. Diese Verantwortlichkeiten sollten am besten getrennt bleiben, es sei denn, es gibt einen triftigen Grund, sie zu verschmelzen.

Eine sinnvolle erste Implementierung

Es wäre ein Fehler, mit 300 Konzepten zu beginnen. Zehn wären besser – genauer gesagt zehn Konzepte, über die bereits diskutiert wird. Zum Beispiel:

3 metrics
2 schemas
2 SLAs
2 runbooks
1 business rule

Dann sollten einige Aspekte gemessen werden. Kann der Agent das kanonische Konzept finden? Weiß er, wann dieses Konzept veraltet ist? Wählt die Routenfindung den richtigen Weg? Können Live-Abfragen sicher ausgeführt werden? Wird die Konzepte tatsächlich gepflegt? Gute Ergebnisse rechtfertigen eine Erweiterung des Umfangs. Schlechte Ergebnisse rechtfertigen ein Aufhören. Ein Architekturexperiment sollte in der Lage sein, ohne große Kosten zu scheitern.

Die wichtigere Lektion

Die nützlichste Erkenntnis ist nicht ein neues Dateiformat. Vielmehr hat das Unternehmenswissen unterschiedliche Wahrheitsformen. Einige sind autoritativ, andere explorativ und wieder andere beschreiben den aktuellen Zustand – jede Form verdient ihr eigenes Zugriffsmodell. Eine praktische Zuordnung verbindet jede Frage mit einem Modell:

• Offizielle Definition: kanonisches Wissen.
• Relevante Informationen: Abruf.
• Aktuelle Wahrheit: Live-Abfrage.
• Was der Agent tun sollte: Alle oben genannten Aspekte unter Berücksichtigung von Richtlinien kombinieren.

RAG bleibt wertvoll, Vektordatenbanken bleiben wertvoll, und auch OKF kann wertvoll sein. Der architektonische Fehler besteht darin, anzunehmen, dass eine dieser Technologien alle Fragen beantworten sollte. Die Zukunft besteht nicht darin, RAG zu ersetzen. Es geht darum, zu wissen, wann RAG das richtige Werkzeug ist und wann nicht. Sobald Agenten innerhalb von Unternehmen tatsächliche Aktionen ausführen, wird die Auswahl der Quelle der Wahrheit nicht mehr eine Frage des Wissensmanagements, sondern zu einer architektonischen Entscheidung.