Wie Writers Knowledge Graph Unternehmensdaten ohne Vektor-Chunking für KI-Anwendungen erschließt

Für IT-Architekten und Verantwortliche für Wissensmanagement in Unternehmen stellt der produktive Einsatz generativer KI häufig eine ernüchternde Herausforderung dar: Herkömmliche Pipelines zur Retrieval-Augmented Generation (Vektor-RAG) stützen sich fast durchgehend auf Vektor-Chunking (Vector Chunking). Dabei werden Dokumente schematisch in Textfragmente von 100 bis 200 Zeichen oder wenige hundert Token zerschnitten, in Vektor-Embeddings umgewandelt und über Algorithmen zur approximativen Nächste-Nachbarn-Suche (ANN/KNN) abgefragt.

In der betrieblichen Praxis versagt dieser Ansatz regelmäßig. Vektor-Chunking zerstört die hierarchische Gliederung von Dokumenten, trennt Tabellen und Finanzübersichten von ihren Spaltenüberschriften, isoliert Vertragsklauseln von grundlegenden Begriffsdefinitionen und scheitert an komplexen mehrstufigen Abfragen (Multi-Hop) über getrennte Systeme hinweg. Das unvermeidliche Resultat sind gravierende Kontextverluste und unkalkulierbare Modellhalluzinationen.

Die Enterprise-KI-Plattform Writer wählt ein grundlegend anderes Architekturparadigma: ihren proprietären Wissensgraphen (Writer Knowledge Graph bzw. graphbasiertes RAG). Statt Unternehmensdaten in zusammenhangslose Textschnipsel zu zerlegen, modelliert Writer strukturierte und unstrukturierte Datenbestände als dynamisches Beziehungsnetzwerk aus Entitäten und semantischen Kanten. Durch die Kombination dieses Graphen mit der patentierten Retrieval-Aware Compression (RAC) und den hauseigenen Palmyra-Sprachmodellen überwindet Writer die Grenzen des Vektor-Chunkings und schafft eine hochpräzise, nachvollziehbare und latenzarme Faktenbasis für unternehmenskritische Anwendungen.

Warum herkömmliches Vektor-Chunking bei Unternehmensdaten scheitert

Um die Notwendigkeit einer graphenbasierten Architektur zu verstehen, müssen die mechanischen Schwachstellen reiner Vektorsuchen bei realen Unternehmensdaten offengelegt werden.

1. Kontextverlust und strukturelle Fragmentierung

Unternehmensdokumente zeichnen sich durch strikte Hierarchien und hohe Kontextdichte aus (z. B. Prozessrichtlinien, Revisionshandbücher, Rahmenverträge und technische Spezifikationen):

• Zerstörung komplexer Tabellen und Finanzdaten: Wird eine mehrspaltige Preismatrix oder Bilanz horizontal in 200-Zeichen-Blöcke zerschnitten, verlieren die Datenzeilen den Bezug zu den Kopfzeilen. Das resultierende Vektor-Embedding kann nicht mehr erkennen, ob eine Zahl den Nettogewinn des dritten Quartals, einen Rabattsatz oder eine Artikelnummer darstellt.
• Trennung von Klauseln und rechtlichen Definitionen: In einem Rahmenvertrag hängt eine Haftungsbegrenzung auf Seite 18 rechtlich zwingend von den Begriffsbestimmungen auf Seite 2 ab. Vektor-Chunking kappt diese Verbindung; das isolierte Textfragment erreicht das Sprachmodell ohne die maßgeblichen Einschränkungen, was zu unvollständigen oder haftungsrechtlich gefährlichen Antworten führt.

2. Dichte und dünne Zuordnungen (Dense/Sparse Mapping) und der „Fluch der Dimensionalität“

Vektordatenbanken berechnen Relevanz anhand geometrischer Distanzen (wie Kosinus-Ähnlichkeit) in einem hochdimensionalen Raum. Bei Unternehmensdaten führt dieses Prinzip zu zwei typischen Fehlermustern:

• Dichte Zuordnung (Dense Mapping): Treten Schlüsselbegriffe (z. B. ein Kernproduktname, eine Modellnummer oder ein Konformitätsstandard) in hunderten Handbüchern zehntausende Male auf, ballen sich die Vektoren im selben Raumabschnitt. ANN-Algorithmen verlieren die Trennschärfe und liefern eine Flut semirelevanter Chunks zurück, die das Kontextfenster des Sprachmodells verstopfen.
• Dünne Zuordnung (Sparse Mapping): Tabellenzahlen, Codezeilen, Fehlermeldungen und alphanumerische Kennungen weisen im Vektorraum eine große geometrische Distanz zu natürlichsprachlichen Nutzerfragen auf. Da rein numerische Abstände ohne inhaltliches Kausalitätsverständnis gemessen werden, übersieht das System exakte Fakten oder ruft irrelevante Textpassagen ab.

3. Unfähigkeit zu mehrstufigen Schlussfolgerungen (Multi-Hop Reasoning)

Reale Geschäftsfragen lassen sich selten mit einem einzelnen isolierten Textabschnitt beantworten. Eine Frage wie: „Welche Enterprise-Kunden mit Vertragsverlängerung im dritten Quartal haben SLA-Pönalen von über 5 % vereinbart?“ erfordert die Verknüpfung von CRM-Daten, Vertragsarchiven und Servicetickets. Eine Vektordatenbank müsste mehrere spekulative Suchen aneinanderketten; dabei pflanzen sich Suchfehler fort und führen zu gravierenden Halluzinationen.

4. Index-Starrheit und hohe Betriebskosten

In reinen Vektordatenbanken hängt die relative Position eines Embeddings von der Verteilung des gesamten Datenbestands ab. Werden täglich Dokumente hinzugefügt, geändert oder gelöscht, müssen häufig umfangreiche Vektorindizes neu berechnet werden. Zusammen mit dem immensen Token-Verbrauch beim Einspeisen unstrukturierter Textblöcke in Prompts explodieren die Gesamtbetriebskosten (TCO) selbstgebauter Vektor-RAG-Systeme.

Die Writer-Architektur: Von der Datenintegration zum Wissensgraphen

Writer ersetzt das wahllose Zerschneiden von Texten durch eine durchgängige Datenpipeline, welche die strukturelle Integrität, systemübergreifende Relationen und eine lückenlose Nachvollziehbarkeit sicherstellt.

+-----------------------------------------------------------------------------------+
|                        UNTERNEHMENSWEITE DATENQUELLEN                             |
|   SharePoint  |  Google Drive  |  Notion  |  Confluence  |  Salesforce  |  Dateien    |
+------------------------------------------+----------------------------------------+
                                           |
                                           v
+-----------------------------------------------------------------------------------+
|               KONNEKTOREN & STRUKTURBEWUSSTE PARSING-SCHICHT                      |
|   Erhält Tabellen, Tabellenkalkulationen, Präsentationen, PDFs & Hierarchien      |
+------------------------------------------+----------------------------------------+
                                           |
                                           v
+-----------------------------------------------------------------------------------+
|                 GRAPHENAUFBAU & RAC-KOMPRESSION                                   |
|   - Spezialisiertes LLM extrahiert Entitäten (Knoten) & Beziehungen (Kanten)      |
|   - Retrieval-Aware Compression (RAC): verdichtet Fakten mit Metadaten-Index      |
+------------------------------------------+----------------------------------------+
                                           |
                                           v
+-----------------------------------------------------------------------------------+
|                 ABFRAGE-ENGINE: ZERLEGUNG & GRAPH-TRAVERSIERUNG                   |
|   - Zerlegt komplexe Anfragen in Unterfragen (über max_subquestions steuerbar)    |
|   - Traversiert Beziehungspfade; kombiniert semantische & lexikalische Schwellen  |
+------------------------------------------+----------------------------------------+
                                           |
                                           v
+-----------------------------------------------------------------------------------+
|                 PALMYRA-MODELLGENERIERUNG & INLINE-QUELLENANGABEN                 |
|   - Hauseigene Palmyra-LLMs (Palmyra X 004, Med, Fin) generieren auf Faktenbasis  |
|   - Klickbare Inline-Zitate mit direktem Verweis auf Quelldokument und Textstelle |
+------------------------------------------+----------------------------------------+

1. Native Konnektoren ohne aufwendige ETL-Vorverarbeitung

Entwicklungsteams müssen keine individuellen Skripte zur Textextraktion und Segmentierung pflegen. Writer bindet führende Unternehmenssysteme direkt an:

• Cloud-Speicher und Kollaboration: Native Schnittstellen zu Microsoft SharePoint, OneDrive, Google Drive, Box, Notion und Confluence.
• Geschäftsanwendungen: Anbindung von Salesforce, internen Wikis und Kundendienstsystemen.
• Parsing komplexer Dateiformate: Verarbeitung von Excel-Dateien, gescannten PDFs, PowerPoint-Folien, Diagrammen sowie Audio- und Videotranskripten.

Dokumentstrukturen, Tabellenkoordinaten und Zugriffsberechtigungen bleiben ab dem Moment des Einlesens vollständig gewahrt.

2. Entitäten- und Beziehungsextraktion über spezialisierte Sprachmodelle

Der entscheidende Schritt weg vom Vektor-Chunking erfolgt beim Aufbau des Wissensgraphen:

• Knoten als Entitäten und Konzepte: Writer nutzt ein spezialisiertes Sprachmodell, das darauf trainiert ist, Informationen im großen Maßstab zu strukturieren. Es identifiziert Kunden, Verträge, Produktvarianten, SLA-Schwellenwerte, Fristen und Verantwortliche als eigenständige Knoten.
• Kanten als typisierte Beziehungen: Das System etabliert gerichtete semantische Relationen (Kunde_A $\rightarrow$ hält_Vertrag $\rightarrow$ Vertrag_B $\rightarrow$ beinhaltet_Pönale $\rightarrow$ Klausel_C).
• Dauerhafter Erhalt des logischen Kontexts: Weil Fakten als verknüpfte Entitäten und nicht als isolierte Textpassagen abgelegt werden, bleibt jede Vertragsklausel untrennbar mit ihrem Hauptvertrag und den Unterzeichnern verbunden.

3. Retrieval-Aware Compression (RAC)

Um zu verhindern, dass der Graph ausufert oder das Sprachmodell mit irrelevantem Text überfrachtet wird, setzt Writer auf Retrieval-Aware Compression (RAC):

• Präzise Informationsverdichtung: RAC komprimiert weitschweifige Firmentexte zu kompakten semantischen Knoten, behält Zahlen, Grenzwerte und Bedingungen jedoch exakt bei.
• Umfassender Metadaten-Index: Jeder Knoten und jede Kante enthält vollständige Herkunftsnachweise: Dokumenten-ID, Seitenzahl, Tabellenkoordinaten, Zeitstempel und Berechtigungsstufen.
• Fokus auf signalstarke Fakten: Das Sprachmodell erhält kein unstrukturiertes Textkonvolut, sondern ein komprimiertes, verifiziertes Faktennetzwerk, was Inferenzkosten senkt und die Antwortqualität steigert.

4. Abfragezerlegung und mehrstufige Graphtraversierung

Geht eine komplexe Anfrage eines Nutzers oder KI-Agenten ein, führt die Engine keine plumpe Vektordistanzsuche durch:

1. Automatisierte Zerlegung: Komplexe Abfragen werden in gezielte Teilfragen aufgespalten (über den Parameter max_subquestions konfigurierbar, standardmäßig bis zu 6).
2. Beziehungsbasierte Graphtraversierung: Die Engine folgt den Kanten des Wissensgraphen über Systemgrenzen hinweg (z. B. vom CRM-Datensatz in Salesforce zur Vertragsklausel in SharePoint).
3. Ausbalancierte Hybridsuche: Die semantische Graphtraversierung wird mit exakter lexikalischer Stichwortsuche kombiniert. Dies stellt sicher, dass übergeordnete Konzepte ebenso treffsicher erfasst werden wie exakte Teilenummern oder Bilanzkennzahlen.

5. Grounding auf Palmyra-Modellen mit verifizierbaren Inline-Zitaten

Die ermittelten Teilgraphen und komprimierten Fakten werden an Writers eigene Palmyra-Modellfamilie übergeben (darunter Palmyra X 004, Palmyra-Med für das Gesundheitswesen und Palmyra-Fin für Finanzdienstleister):

• Strikte Faktenbindung: Palmyra-Modelle sind durch Instruktions-Feinabstimmung darauf ausgerichtet, sich strikt an die gelieferten Graphfakten zu halten, wodurch Halluzinationen unterbunden werden.
• Antwortzeiten unter 0,6 Sekunden: Da die Abfrage gezielten Pfaden folgt, statt Millionen Vektoren abzugleichen, liegt die durchschnittliche Antwortzeit bei unter 0,6 Sekunden.
• Klickbare Inline-Zitate (Inline Citations): Dank der RAC-Metadaten wird jede zentrale Aussage mit einer Quellenangabe versehen. Nutzer können direkt auf die Zitate klicken, um das Ursprungsdokument und die exakte Textstelle zu prüfen.

Technischer Vergleich: Traditionelles Vektor-RAG vs. Writer Knowledge Graph

Benchmark-Ergebnisse: Leistungsnachweis in RobustQA

Um die Leistungsfähigkeit graphbasierter Verfahren im Vergleich zu Vektorsystemen objektiv zu messen, wurde der Writer Knowledge Graph auf dem Benchmark RobustQA getestet. RobustQA wurde von Amazon-Forschern entwickelt und prüft die Qualität von Open-Domain-Frage-Antwort-Systemen in 8 Fachdomänen (u. a. Biomedizin und Technologie) anhand von 50.000 Fragen über mehr als 32 Millionen Dokumente hinweg.

Die Ergebnisse belegen deutliche Vorteile bei Präzision und Verarbeitungsgeschwindigkeit:

• Höchste Genauigkeit im Testfeld (86,31 %): Der Writer Knowledge Graph erzielte auf RobustQA einen Bestwert von 86,31 % und übertraf damit alle sieben getesteten Vektor-RAG-Ansätze. Zum Vergleich: LlamaIndex mit Weaviate-Hybridsuche erreichte 75,89 %, Azure Cognitive Search mit GPT-4 lag bei 72,36 % und Kombinationen aus Pinecone Canopy und LangChain erzielten zwischen 59,61 % und 69,02 %.
• Antwortzeit unter 0,6 Sekunden: Writer erreichte eine durchschnittliche Latenz von weniger als 0,6 Sekunden, was beweist, dass relationale Graphpfade auch bei Millionen Dokumenten ohne Performance-Einbußen skalieren.
• 67 % niedrigere Betriebskosten: Durch RAC-Verdichtung und optimiertes Serving der hauseigenen Palmyra-Modelle sinken die Betriebskosten um bis zu 67 % gegenüber selbst zusammengebauten Vektor-RAG-Pipelines.

Entwickler-Leitfaden: API-Konfiguration und Agenten-Werkzeuge

Im Writer AI Studio können Wissensgraphen über REST-APIs und offizielle SDKs programmgesteuert verwaltet und in ihren Retrieval-Parametern feinjustiert werden.

Direkte Graphabfrage per API

Entwickler können gezielte Abfragen an bestimmte Wissensgraphen senden und das Retrieval über query_config präzise steuern:

curl -X POST https://api.writer.com/v1/graphs/question \
  -H "Authorization: Bearer $WRITER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "graph_id": "graph_f83a9102c",
    "question": "Welche Haftungshöchstgrenzen gelten für Softwareverträge im Gesundheitswesen?",
    "query_config": {
      "inline_citations": true,
      "search_weight": 60,
      "grounding_level": 0.85,
      "max_snippets": 5,
      "max_subquestions": 4
    }
  }'

Zentrale Parameter in query_config

• inline_citations (boolean): Bei true werden strukturierte Inline-Zitate in den Antworttext eingebettet, die direkt auf Datei-IDs, Seitenzahlen und Textausschnitte verweisen.
• search_weight (integer, 0–100, Standard 50): Steuert die Gewichtung zwischen exakter Stichwortsuche und semantischer Graphtraversierung. Niedrigere Werte priorisieren exakte Wortlaute (ideal für Teilenummern oder Rechtsklauseln); höhere Werte fördern übergreifende konzeptionelle Verknüpfungen.
• grounding_level (float, 0.0–1.0, Standard 0.0): Bestimmt, wie strikt das Modell an die Graphfakten gebunden ist. Höhere Werte eliminieren freie Interpretationen und verlangen explizite Belege.
• max_subquestions (integer, Standard 6): Maximale Anzahl von Unterfragen, in die komplexe Multi-Hop-Anfragen aufgeteilt werden dürfen.
• max_snippets (integer): Obergrenze der Belegfragmente, die dem Modell zur Synthese übergeben werden.

Wissensgraphen als Werkzeuge für autonome KI-Agenten

In Chat-Completions oder Workflows autonomer Agenten fungieren Wissensgraphen als standardmäßige Tools. Erkennt der Agent, dass zur Beantwortung interne Unternehmensdaten nötig sind, ruft er den Graphen selbstständig auf:

{
  "tools": [
    {
      "type": "function",
      "function": {
        "name": "knowledge_graph_search",
        "description": "Durchsucht den internen Wissensgraphen nach verifizierten Unternehmensfakten.",
        "parameters": {
          "type": "object",
          "properties": {
            "query": { "type": "string" },
            "query_config": {
              "type": "object",
              "properties": {
                "inline_citations": { "type": "boolean" },
                "search_weight": { "type": "integer" }
              }
            }
          },
          "required": ["query"]
        }
      }
    }
  ]
}

Unternehmens-Governance, Zugriffskontrolle und Datenschutz

Der Einsatz generativer KI auf vertraulichen Geschäftsdaten erfordert kompromisslose Governance-Standards:

1. Kein Modelltraining auf Kundendaten: Writer stellt vertraglich sicher, dass Unternehmensdaten aus Wissensgraphen oder API-Abfragen niemals zum Trainieren oder Verbessern öffentlicher Basismodelle herangezogen werden.
2. Mandantentrennung auf Teamebene (Team-Scoped Graphs): Graphen können unternehmensweit (Org-wide) oder auf bestimmte Abteilungen beschränkt (Team-scoped) eingerichtet werden. Ein teamspezifischer API-Schlüssel verhindert Zugriffe auf nicht autorisierte Bereiche.
3. Umfassende Sicherheitszertifizierungen: Die Plattform erfüllt durchgehend die Kriterien von SOC 2 Type II, HIPAA und DSGVO.
4. Vollständige Auditierbarkeit: Jede generierte Aussage lässt sich lückenlos bis zum Originaldokument zurückverfolgen, was Revisions- und Compliance-Prüfungen vereinfacht.

Empfehlungen für die Praxis

Für IT-Architekten, die generative KI von Pilotprojekten in den regulären Betrieb überführen wollen, empfiehlt sich folgendes Vorgehen:

1. Dokumentstrukturen im Vorfeld prüfen: Besteht der Datenbestand überwiegend aus komplexen Tabellen, verschachtelten Verträgen oder hierarchischen Richtlinien, sollte auf Vektor-Chunking verzichtet werden. Die unvermeidlichen Kontextverluste untergraben rasch das Vertrauen der Fachbereiche.
2. Zentrale Datenquellen priorisieren: Binden Sie zunächst maßgebliche Referenzsysteme (wie freigegebene SharePoint-Archive oder zentrale Confluence-Bereiche) an, um ein stabiles Entitätengerüst aufzubauen, bevor dezentrale Dokumente integriert werden.
3. Parameter auf den Einsatzzweck abstimmen:
   • Rechtsabteilung, Revision und Compliance: Setzen Sie grounding_level auf $\ge 0.85$ und search_weight auf $30\text{--}40$, um maximale Texttreue und Prüfbarkeit sicherzustellen.
   • Vertriebsunterstützung und allgemeines Wissensmanagement: Wählen Sie für search_weight Werte zwischen $50\text{--}60$, um abteilungsübergreifende Querverbindungen zu ermöglichen.
4. Mehrstufige Testabfragen etablieren: Überprüfen Sie das System gezielt mit Fragen, die Daten aus mindestens zwei getrennten Systemen kombinieren müssen, um die Funktionsweise der automatischen Abfragezerlegung zu validieren.

Indem Writer unstrukturierte Texte in ein strukturiertes Beziehungsnetzwerk überführt, erhalten Unternehmen eine robuste, skalierbare und wirtschaftliche Grundlage für anspruchsvolle KI-Anwendungen.

Quellen

• Graph-based RAG | WRITER Knowledge Graph
• The limitations of vector retrieval for enterprise RAG — and what to use instead
• RAG benchmarking: Writer Knowledge Graph ranks #1
• Writer AI Studio Developer Documentation