Unternehmenswissen
in Zusammenhang bringen.

Das Ziel ist eine unternehmensweite Wissensordnung, die unterschiedliche Fachbereiche zusammenführt. Dazu gehören Strategie und Entscheidungen, Organisation und Expertise, Kunden und Verträge, Produkte und Leistungen, Prozesse und Systeme sowie Projekte und ihre Ergebnisse. Diese Bestände haben verschiedene Verantwortliche und Schutzbedarfe. Gemeinsam erschließen bedeutet deshalb nicht, jedem Menschen Zugriff auf alles zu geben.

Ein Wissenskatalog beschreibt zunächst, welche Bestände existieren, wo sie liegen, wer sie verantwortet und unter welchen Bedingungen sie genutzt werden dürfen. Ein gemeinsames Begriffsmodell ordnet Fachbegriffe, Synonyme und fachliche Kategorien. Stabile Kennungen verbinden dasselbe Produkt, denselben Prozess oder dasselbe Projekt über mehrere Systeme hinweg. Versionen, Gültigkeit und Herkunft machen erkennbar, welche Aussage zu welchem Zeitpunkt galt.

Die führenden Fachsysteme können dabei bestehen bleiben. Je nach Bedarf wird Wissen über freigegebene Schnittstellen abgerufen oder als kontrollierte, aktualisierbare Ableitung indexiert. Ein zentraler Zugang erfordert keine vollständige Kopie aller Unternehmensdaten. Erfahrungswissen aus Gesprächen und praktischer Arbeit wird erst dann dauerhaft nutzbar, wenn es bewusst dokumentiert, fachlich eingeordnet und freigegeben wird.

Mit Deep Knowledge bezeichnen wir in diesem Beitrag dieses Architekturprinzip: Inhalte werden mit Bedeutung, Beziehungen, Verantwortung und Herkunft verbunden. Der Begriff steht weder für ein bestimmtes Produkt noch für eine normierte Qualitätsstufe. Eine Wissensbasis bleibt eine gepflegte Auswahl und Strukturierung des verfügbaren Wissens; sie wird durch ein Sprachmodell nicht automatisch vollständig oder richtig.

Retrieval-Augmented Generation, kurz RAG, stellt einem Sprachmodell passende, freigegebene Quellen zur Laufzeit als Kontext bereit. Dieser Abruf ist von einer Änderung der Modellgewichte durch Training oder Fine-Tuning zu unterscheiden; die Ansätze können sich ergänzen. Eine Antwort bleibt überprüfungsbedürftig. Ihr Wert hängt davon ab, ob die richtigen Bestände gefunden und ihre fachlichen Bedingungen erhalten wurden.

Der Kern einer hybriden Architektur ist die Trennung von führenden Quellen, Wissensordnung, Suche und Modellverarbeitung. In der hier beschriebenen Referenzarchitektur werden Katalog, aufbereitete Inhalte und Suchindizes in einer selbst kontrollierten Umgebung betrieben. Originale bleiben in den dafür vorgesehenen Fachsystemen oder Ablagen. Die Modellschicht kann je nach Aufgabe einen lokalen Dienst oder einen vertraglich und technisch freigegebenen Cloud-Dienst verwenden. Für jede Verbindung werden Aktualisierung, Datenort und Verantwortung festgelegt.

Hybrid ist kein automatischer Ausweichweg. Reicht die lokale Antwortqualität nicht aus, darf das System deshalb nicht ungeprüft vertrauliche Dokumente an einen externen Anbieter senden. Vor der Anfrage stehen Identitäts- und Rechteprüfung, Datenklassifikation, Kontextminimierung und eine verbindliche Entscheidung über den zulässigen Verarbeitungsweg. Fehlen Rechte oder eine Freigabe, wird der betreffende Pfad gesperrt. Fehlen belastbare Quellen, ist eine Rückfrage oder ein begründeter Verzicht auf die Antwort sinnvoller als ein Modellwechsel.

Auch der lokale Pfad muss vollständig betrachtet werden: OCR, Embeddings, Graph-Extraktion und Reranking können selbst Modelle oder externe Dienste aufrufen. Telemetrie, Fehlerprotokolle und Caches können Informationen nach außen tragen. Die Architektur muss deshalb für jeden Verarbeitungsschritt festlegen, wo er läuft, welche Daten er erhält und welche Netzwerkziele erlaubt sind.

Davon zu unterscheiden ist hybrides Retrieval: die kombinierte Suche über Volltext, Vektoren und gegebenenfalls einen Graph. Diese Suchstrategie kann vollständig lokal laufen. Umgekehrt kann ein lokal betriebenes Modell einen externen Datenbestand verwenden. Die zwei Entscheidungen sollten unabhängig voneinander geplant werden.

Die folgende Tabelle beschreibt Rollen und Datenorte, keine Einkaufsliste. Verarbeitungsknoten können getrennt betrieben oder für einen ersten Piloten zusammengefasst werden. Dimensionierung und Trennung richten sich nach Datenvolumen, Parallelität, Verfügbarkeit und Schutzbedarf.

Für eine unternehmensweite Wissensbasis müssen vier Fragen getrennt beantwortet werden: Worum geht es fachlich? Wie ist der Inhalt strukturiert? In welchem Format liegt er vor? Welche Regeln gelten für seine Nutzung? Ein Vertrag ist ein fachlicher Gegenstand, PDF ein Dateiformat und „vertraulich“ eine Schutzklasse. Aus keinem dieser Merkmale allein ergibt sich die richtige Verarbeitung.

Strukturierte Daten haben definierte Felder, etwa Kunden-, Auftrags- oder Finanzdatensätze. Semi-strukturierte Daten tragen erkennbare Schlüssel oder Hüllen, etwa JSON, XML, Ereignisprotokolle oder E-Mail-Metadaten. Unstrukturierter Text vermittelt Bedeutung überwiegend in freier Sprache. Multimodale Inhalte ergänzen die mediale Perspektive: Bilder, Audio, Video oder technische Modelle. Das sind keine vier trennscharfen Schubladen. Eine E-Mail verbindet Felder, Freitext und Anhänge; ein PDF kann Fließtext, Tabellen und Scans enthalten; CAD-Geometrie kann hoch strukturiert sein.

Auch auf Feldebene müssen Typen erhalten bleiben: Zahl, Datum, Wahrheitswert, Kennung oder Aufzählungswert sind verschieden zu behandeln. Eine Artikelnummer ist meist eine Kennung, keine Zahl zum Rechnen. Währungen, Einheiten, Zeitzonen und Beziehungen zwischen Datensätzen gehören zur Bedeutung. Werden solche Inhalte pauschal in Fließtext umgewandelt, gehen wichtige Prüf- und Auswertungsmöglichkeiten verloren.

Data Input startet mit einem katalogisierten, freigegebenen Bestand und einer passenden Anbindung. Für strukturierte Daten werden Schlüssel und Feldtypen übernommen; für Dokumente Struktur und Fundstellen; für Medien gegebenenfalls OCR, Transkript oder Beschreibung als gekennzeichnete Ableitung. Docling kann unterschiedliche Dokumentformate in eine gemeinsame Zwischenrepräsentation überführen. Diese Arbeitsfassung ergänzt das Original, sie ersetzt es nicht.

Jeder Bestand braucht stabile Kennungen, Herkunft, fachliche Verantwortung, Version, Änderungszeit, Gültigkeit und Zugriffsregel. Dazu kommen bei Fundstellen Seite, Abschnitt, Datensatzschlüssel oder Zeitmarke. Importzeitpunkt und fachliche Gültigkeit sind verschieden. Die Berechtigungen der Quelle müssen bis zum späteren Suchtreffer und zur Ausgabe erhalten bleiben.

Data Cleansing ist mehr als das Entfernen leerer Zeilen. Es schafft konsistente, überprüfbare Arbeitsdaten. Dazu gehören Zeichencodierung, Sprache, Datumsformate, Einheiten, Dubletten und die Zuordnung verschiedener Schreibweisen. Aus „Art.-Nr. 0042“ und „Artikel 42“ darf aber erst nach einer fachlichen Regel dieselbe Entität werden. Führende Nullen, Versionszusätze, Negationen und Ausnahmebedingungen können entscheidend sein.

Bei der Aufbereitung bleiben Originale unverändert; Aufbewahrungs- und Löschregeln gelten weiterhin. Jede Transformation erzeugt eine nachvollziehbare Ableitung mit Versionsbezug. Ein exakt identisches Dokument kann über seine Prüfsumme erkannt werden; ähnliche Dokumente erfordern mehr Vorsicht. Zwei fast gleiche Serviceanweisungen können für unterschiedliche Produktstände gelten. Sie ungeprüft zusammenzuführen würde Wissen vernichten statt bereinigen.

KNIME Analytics Platform eignet sich als visuelle Schicht für solche Verarbeitungsschritte: Daten einlesen, Felder umformen, Regeln anwenden, Bestände verbinden und Ergebnisse prüfen. Eigene Python-Schritte oder spezialisierte Parser können einen Workflow ergänzen. Die sichtbare Abfolge erleichtert fachliche Reviews. Sie macht einen Prozess jedoch nicht von selbst korrekt oder rechtmäßig.

Ein sinnvoller Ablauf enthält eine Quarantäne für problematische Eingaben. Fehlende Rechte, beschädigte Dateien oder zweifelhafte OCR-Ergebnisse werden nicht einfach in den Wissensbestand übernommen. Stichproben und automatisierte Prüfregeln ergänzen sich. In Arbeitsverzeichnissen oder temporären Tabellen können sensible Inhalte liegen; KNIME-Verarbeitung ist deshalb nicht mit „nur im RAM“ gleichzusetzen.

Chunking zerlegt große Dokumente in Einheiten, die sich gezielt finden und als Kontext verarbeiten lassen. Zu kleine Abschnitte trennen Regeln von ihren Ausnahmen; zu große Abschnitte bringen irrelevante Informationen in die Antwort und beanspruchen mehr Kontext. Eine universell beste Größe gibt es nicht. Dokumentstruktur, Fragestellungen, Embedding-Modell, Tokenizer und nachgelagerte Verarbeitung bestimmen die sinnvolle Aufteilung.

Ein guter Chunk trägt seine Herkunft mit: Dokument-ID, Version, Überschriftenpfad, Fundstelle, Gültigkeit und Zugriffsregel. Tabellen sollten mit ihren Spaltenüberschriften und Einheiten lesbar bleiben. Eine Liste von Voraussetzungen sollte nicht von der Handlung getrennt werden, für die sie gilt. Bei längeren Kapiteln kann ein kleiner Suchtreffer auf einen größeren übergeordneten Abschnitt verweisen; erst die Kontextzusammenstellung entscheidet, wie viel davon gebraucht wird.

Überlappung kann den Übergang zwischen zwei Fenstern erhalten, erzeugt aber doppelte Inhalte. Das erhöht Index- und Kontextumfang und kann beim Zusammenstellen der Treffer zu Wiederholungen führen. Die Demo zählt bewusst Wörter, damit die Aufteilung sichtbar bleibt. In einer produktiven Pipeline müssen Größenlimits mit dem tatsächlich eingesetzten Tokenizer überprüft werden.

Nach der Aufteilung entstehen Embeddings und Suchindizes. Exakte Produktnummern profitieren von Volltext oder strukturierten Filtern; inhaltlich ähnliche Formulierungen von Vektorsuche. Anschließend können Treffer neu gewichtet werden. Rechtefilter gelten für alle Kandidaten und erneut vor der Kontextausgabe. Ein Relevanzwert ist keine Wahrheitswahrscheinlichkeit. Textabschnitte dienen dabei zugleich als Quellenbezug für abgeleitetes Wissen.

Eine relationale Datenbank organisiert Daten in Tabellen mit Zeilen und typisierten Spalten. Primärschlüssel identifizieren Datensätze; Fremdschlüssel und Zwischentabellen bilden Beziehungen ab. Abfragen verknüpfen Tabellen über JOINs. Das passt beispielsweise zu Buchungen, Stammdaten, Aufträgen und konsistenten Auswertungen. Beziehungen sind also ausdrücklich Teil des relationalen Modells.

Eine Graphdatenbank macht Entitäten und ihre Verbindungen unmittelbar zum Datenmodell. Im Property-Graph-Modell tragen Knoten und typisierte, gerichtete Kanten Eigenschaften. Abfragen folgen diesen Beziehungen, etwa von einem System zu abhängigen Prozessen, verantwortlichen Teams und zugehörigen Dokumenten. Das ist besonders anschaulich, wenn Wege und wechselnde Verknüpfungen selbst Gegenstand der Frage sind.

Das folgende Modellbeispiel zeigt dieselben Entitäten und Beziehungen in beiden Darstellungen. Die fachliche Antwort verändert sich durch den Wechsel der Speicherform nicht. Entscheidend sind die benötigten Abfragen, Regeln und Betriebsanforderungen – nicht die Annahme, Graphdatenbanken seien grundsätzlich moderner oder schneller.

Ein unternehmensweiter Knowledge Graph verbindet Fachdomänen, die in der Ablage oft getrennt bleiben: Menschen und Zuständigkeiten, Prozesse und Systeme, Projekte und Produkte, Kunden und Verträge sowie Richtlinien und Dokumente. Der Nutzen liegt in bereichsübergreifenden Fragen: Welche Prozesse hängen von einem System ab? Wer verantwortet sie? Welche Regeln und Entscheidungen sind für ein Vorhaben relevant? Die folgende Übersicht zeigt mögliche Beziehungstypen als vereinfachtes Ordnungsmodell, keinen vollständigen Unternehmensbestand.

Damit wird die Wissensbasis nicht nur durchsuchbar, sondern ihre Zuordnung ausdrücklich nutzbar. Änderungen lassen sich entlang bekannter Abhängigkeiten zur Prüfung vorlegen; neue Mitarbeitende können Zusammenhänge und Ansprechpersonen finden; mehrere Teams können sich auf dieselben Begriffe und Belege beziehen. Der Graph zeigt dabei nur dokumentierte Beziehungen. Eine fehlende Kante beweist nicht, dass es fachlich keinen Zusammenhang gibt.

Die Modellierung beginnt mit wenigen stabilen fachlichen Typen und eindeutigen Kennungen. Organisationseinheit, Person, Prozess, System, Projekt, Produkt und Dokument sind unterschiedliche Entitäten. „verantwortet“, „nutzt“, „gilt für“ und „belegt“ sind verschiedene Beziehungen. Ein gemeinsames Vokabular und fachlich verantwortete Zuordnungen verhindern, dass gleiche Namen ungeprüft als dieselbe Sache behandelt werden.

Modellgestützte Extraktion produziert zunächst Vorschläge. Quelle, Fundstelle, Gültigkeit, Extraktionsversion und Prüfstatus bleiben an jeder abgeleiteten Aussage erhalten. Widersprüche und ungeprüfte Verbindungen werden sichtbar gehalten. Fachverantwortliche entscheiden nach festgelegten Regeln, welche Aussagen in den freigegebenen Wissensbestand gelangen.

Graph-gestütztes RAG kann die Textsuche um zusammenhängenden Kontext ergänzen. Eine Frage untersucht beispielsweise das Umfeld eines Projekts oder folgt einer Kette aus Prozess, System und Richtlinie. Welche Beziehungen und Quellen in die Antwort eingehen dürfen, bestimmen Zugriff und fachliche Gültigkeit. Ein größerer Graph allein liefert keine besseren Antworten; entscheidend sind passende Modellierung, Pflege und Evaluation.

Graphsuche darf keine Berechtigungsgrenzen überspringen. Auch ein benachbarter Knoten, eine Beziehung oder eine erzeugte Zusammenfassung kann geschützte Informationen enthalten. Die Rechte der zugrunde liegenden Quellen müssen daher jede Erweiterung des Suchpfads begrenzen. Abgeleitete Beziehungen sollten bei Quellenänderung oder Löschung überprüft, berichtigt oder entfernt werden.

Eine Wissenssuche findet Informationen; RAG nutzt sie für eine Antwort. Ein Agent kann darüber hinaus Werkzeuge auswählen, Ergebnisse auswerten und weitere Schritte anstoßen. Der praktische Nutzen entsteht, wenn eine wiederkehrende Aufgabe mehrere Such- und Anwendungsschritte verbindet: weniger manuelles Übertragen, ein nachvollziehbarer Ablauf und eine vorbereitete Übergabe an die zuständige Person.

Agents können diese Wissensordnung in unterschiedlichen Bereichen nutzen: relevante Regeln und frühere Entscheidungen für ein Projekt zusammenstellen, Abhängigkeiten einer Systemänderung zur Prüfung vorlegen oder einen Recherche- und Dokumentationsentwurf vorbereiten. Dabei verbinden sie berechtigte Quellen, klären fehlende Angaben und halten Belege mit. Der gemeinsame Wissensbestand vermeidet, dass jede Anwendung eine eigene, widersprüchliche Sicht auf das Unternehmen aufbaut. Die vorliegenden Grafiken erläutern solche Möglichkeiten; sie greifen auf keine realen Systeme zu.

Für fest definierte Abläufe ist ein regelbasierter Workflow häufig ausreichend. Agentische Entscheidungen sind dort sinnvoll, wo der nächste Recherche- oder Werkzeugschritt von Zwischenergebnissen abhängt. Die erlaubten Aktionen bleiben trotzdem vorgegeben.

Lokale Speicherung ist eine Standortentscheidung, kein Datenschutzsiegel. Ein geschütztes Wissenssystem berücksichtigt Rechte beim Import, bei jeder Ableitung, bei der Suche und bei der Ausgabe. Datenschutz, Urheberrecht und Informationssicherheit beantworten dabei unterschiedliche Fragen. Sie sollten gemeinsam geplant, aber nicht miteinander verwechselt werden.

Die folgende Auswahl zeigt mögliche Bausteine. Sie ist keine fertig geprüfte Kombination und kein Anspruch auf Vollständigkeit. Adapter, Versionen, Betriebsanforderungen und Sicherheitsfunktionen müssen im gewählten Zusammenspiel verifiziert werden. Gerade für sensible Daten ist entscheidend, ob eine Eigenschaft tatsächlich in der verwendeten Edition verfügbar ist.

Die Spalte „Open Source“ wäre für einen solchen Stack zu pauschal. Anwendungscode, Erweiterungen, Modellgewichte und gehostete Angebote können unterschiedliche Bedingungen haben. Frei verfügbare Modellgewichte sind nicht automatisch uneingeschränkt quelloffene Software; sie können eigenen Nutzungsbedingungen unterliegen. Die Auswahl sollte deshalb fachliche Eignung, Lizenz und Betriebsmodell getrennt betrachten.

Auch ein als lokal bekanntes Werkzeug kann Cloud-Funktionen enthalten. Für einen streng lokalen Pfad gehören überprüfte Konfiguration, Netzwerkregeln und die Kontrolle aller beteiligten Dienste dazu. Eine Produktbezeichnung ersetzt keinen Nachweis des tatsächlichen Datenflusses.

Wartbarkeit gehört zur Auswahl: Vor dem produktiven Einsatz werden Pflegezustand, Sicherheitsupdates, verfügbare Adapter und ein möglicher Wechselpfad geprüft. Das gilt für Graphdatenbanken ebenso wie für Modellserver und Benutzeroberflächen. Eine Kombination mehrerer Werkzeuge sollte erst dann als belastbare Architektur gelten, wenn ihre konkrete Integration und ihr Betrieb geprüft sind.

Ein belastbarer Pilot beginnt mit echten fachlichen Fragen und erwarteten Fundstellen. Dazu gehören einfache Suchaufgaben, Fragen über mehrere Dokumente, veraltete Versionen, widersprüchliche Angaben und bewusst unbeantwortbare Fragen. Die Bewertung trennt, ob die richtige Quelle gefunden wurde, ob die Antwort durch sie gedeckt ist und ob das System fehlendes Wissen erkennt.

Neben der Antwortqualität wird der Arbeitsablauf mit dem bisherigen Vorgehen verglichen: Zeit bis zur belegten Antwort, notwendige Rückfragen, manuelle Übertragungen und fachliche Nacharbeit. Bei Agents kommen korrekt abgeschlossene Vorgänge, eingehaltene Freigaben, doppelte Aktionen und Kosten pro erledigter Aufgabe hinzu. Ein schneller Entwurf ist nur dann ein Fortschritt, wenn die anschließende Prüfung nicht mehr Aufwand verursacht. Ziele und Messverfahren werden vor dem Piloten mit dem Fachbereich festgelegt.

Sicherheit wird ebenfalls getestet: Darf eine Person ohne Berechtigung über die Suche, den Graph oder eine Zusammenfassung trotzdem etwas erfahren? Bleibt ein gelöschtes Dokument verschwunden? Kann ein manipuliertes Quelldokument eine externe Aktion auslösen? Solche Prüfungen gehören zu einer Freigabe ebenso wie Antwortqualität, Latenz und Kosten je nützlicher Anfrage.

Ändern sich Parser, Chunking, Embedding-Modell oder Extraktionsschema, müssen betroffene Ableitungen gegebenenfalls neu erzeugt werden. Die Pipeline sollte dokumentieren, welche Version welchen Index aufgebaut hat. Ein Rollback braucht konsistente Daten und Konfigurationen, nicht nur die vorherige Anwendungsversion. Monitoring darf seinerseits keine unkontrollierte zweite Wissensablage aus vollständigen Prompts und Antworten schaffen.

Für den Einstieg bietet sich ein klar begrenzter Bestand mit bekannten Verantwortlichen an. Zuerst werden Datenqualität, Rechte und einfache Suche tragfähig gemacht. Graphbeziehungen kommen dort hinzu, wo die fachlichen Fragen sie benötigen. Ein Cloud-Pfad wird anschließend anhand freigegebener Kontexte und konkreter Qualitäts- oder Betriebsanforderungen bewertet. So wächst das System aus einem überprüfbaren Kern statt aus einer möglichst langen Werkzeugliste.

Neben der Qualität einzelner Antworten wird die Wissensbasis als Ganzes geprüft: Welche priorisierten Fachbereiche sind erschlossen? Für welche Bestände fehlen Verantwortliche, aktuelle Versionen oder Rechteinformationen? Wie schnell werden Änderungen übernommen? Wie häufig bleiben Begriffe oder Beziehungen ungeklärt? Solche Kennzahlen machen Pflegebedarf sichtbar; sie sind kein pauschaler Beweis, dass das gesamte Unternehmenswissen vollständig erfasst ist.