Was ist ein Knowledge Graph — und warum interessiert das dein Unternehmen?
Ein Knowledge Graph macht die Zusammenhaenge in deinen Daten sichtbar. Er verwandelt implizites Expertenwissen in ein navigierbares, deterministisches System.
TL;DR
Ein Knowledge Graph speichert nicht nur Fakten, sondern die Beziehungen zwischen Fakten. Er macht implizites Expertenwissen explizit, antwortet deterministisch, und verliert seinen Wert nicht, wenn Mitarbeiter gehen.
Wichtigste Erkenntnisse
Daten sind nicht Wissen
Dein CRM speichert Fakten. Ein Knowledge Graph speichert die Beziehungen zwischen Fakten — und genau dort liegt der Wert.
Query Determinism
Gleiche Frage, gleiches Ergebnis. Jedes Mal. Das ist der fundamentale Unterschied zu LLM-basierten Systemen.
Der Experte im System
Was passiert, wenn dein erfahrenster Mitarbeiter kuendigt? Ein Knowledge Graph speichert sein Wissen — nicht in Dokumenten, sondern in Struktur.
Das Problem: Wissen lebt in Koepfen
Dein CRM hat 50.000 Datensaetze. Dein erfahrenster Mitarbeiter hat das Wissen ueber die Zusammenhaenge. Er kuendigt morgen. Das Wissen geht mit ihm.
Das ist kein hypothetisches Szenario. Es passiert in jedem Unternehmen, das sein Wissen in Koepfen statt in Systemen speichert. Die Datensaetze bleiben. Die Intelligenz verschwindet.
Was speichert eine Datenbank — und was nicht?
Eine relationale Datenbank speichert Fakten in Tabellen. Kunde X, Adresse Y, Umsatz Z. Das ist nützlich. Aber es ist nicht Wissen.
Wissen ist: Kunde X hat vor drei Monaten nach Objekttyp A gefragt, kennt Entscheider Y bei Firma Z, und reagiert erfahrungsgemaess innerhalb von zwei Tagen auf persoenliche Anrufe, aber nie auf Massen-Emails.
Diese Information existiert — verteilt ueber CRM-Notizen, E-Mail-Verlaeufe, und den Kopf eines Mitarbeiters. Kein SQL-Query der Welt kann sie zusammenfuehren. Nicht weil die Daten fehlen. Sondern weil die Beziehungen zwischen den Daten nirgends strukturiert gespeichert sind.
Ein Knowledge Graph aendert das.
Wie funktioniert ein Knowledge Graph?
Ein Knowledge Graph besteht aus drei Elementen:
Knoten (Entities): Personen, Objekte, Konzepte, Ereignisse. Alles was einen Namen hat.
Kanten (Relationships): Die Verbindungen zwischen Knoten. "Kennt", "hat gekauft", "liegt in", "gehoert zu". Jede Kante hat einen Typ, eine Richtung, und optional Eigenschaften.
Eigenschaften (Properties): Attribute auf Knoten und Kanten. Nicht nur "Kunde", sondern "Kunde mit Entscheidungsbefugnis, aktiv seit 2019, Praeferenz fuer Altbau".
Die Kraft liegt in der Kombination: Du kannst Pfade durch den Graphen traversieren. Nicht "zeig mir alle Kunden" — sondern "zeig mir alle Kunden, die einen Entscheider kennen, der in den letzten 90 Tagen aktiv war, und deren Firma in einer Branche arbeitet, die zu unserem neuen Produkt passt."
Was ist der Unterschied zu einer normalen Datenbank?
| Relationale Datenbank | Knowledge Graph | |
|---|---|---|
| Speichert | Fakten in Tabellen | Fakten + Beziehungen in Netzwerk |
| Fragt | "Welche Kunden haben Umsatz > X?" | "Welche Kunden kennen jemanden, der gerade kaufbereit ist?" |
| Joins | Teuer, vordefiniert | Natuerlich, unbegrenzt tief |
| Wissen | Implizit (in Koepfen) | Explizit (im Graphen) |
| Determinismus | Ja | Ja — gleiche Query, gleiches Ergebnis. Immer. |
LLMs halluzinieren. Datenbanken nicht. Knowledge Graphs auch nicht. Query Determinism Rate: 100%.
Was ist der Unterschied zu einem Data Lake?
Data Lakes sammeln alles. Knowledge Graphs kuratieren Zusammenhaenge.
Ein Data Lake ist ein Parkplatz, auf dem jeder sein Auto abstellt. Ein Knowledge Graph ist ein Stadtplan, der zeigt, welche Strassen wohin fuehren.
Warum jetzt?
Drei Entwicklungen machen Knowledge Graphs fuer Unternehmen relevant:
1. LLMs brauchen Kontext. Ein Sprachmodell ohne strukturierten Kontext halluziniert. Ein Sprachmodell mit Knowledge Graph als Kontext-Quelle gibt praezise, nachvollziehbare Antworten. Der Graph liefert die Fakten. Das LLM formuliert die Antwort.
2. Die Werkzeuge sind reif. Neo4j, Property Graphs, Cypher als Abfragesprache — das Oekosystem ist production-ready.
3. Die Alternative wird teurer. Jeder Mitarbeiter, der geht, nimmt Beziehungswissen mit. Jeder neue Mitarbeiter braucht Monate um es aufzubauen. Das skaliert nicht. Ein Knowledge Graph schon.
Fuer wen ist das relevant?
Nicht fuer jedes Unternehmen. Fuer Unternehmen, bei denen:
- Beziehungswissen wertschoepfend ist (Immobilien, Recruiting, Beratung, Vertrieb)
- Mehrere Informationsquellen existieren (CRM + Email + Kalender + Notizen)
- Entscheidungen auf Zusammenhaengen basieren, nicht auf Einzelfakten
- Implizites Wissen in wenigen Koepfen konzentriert ist (Bus-Factor-Problem)
Takeaways
- Daten sind nicht Wissen. Der Wert liegt in den Beziehungen zwischen Daten, nicht in den Daten selbst.
- Determinismus schlaegt Halluzination. Ein Knowledge Graph antwortet konsistent — gleiche Frage, gleiches Ergebnis.
- Wissen gehoert ins System, nicht in Koepfe. Ein Knowledge Graph ist die Antwort auf das Bus-Factor-Problem.
Häufig gestellte Fragen
Was ist der Unterschied zwischen einem Knowledge Graph und einer Datenbank?
Eine Datenbank speichert Fakten in Tabellen. Ein Knowledge Graph speichert zusaetzlich die Beziehungen zwischen Fakten und erlaubt es, Pfade durch diese Beziehungen zu traversieren — eine Faehigkeit, die SQL grundsaetzlich nicht hat.
Brauche ich einen Knowledge Graph oder reicht RAG?
RAG findet aehnliche Textpassagen. Ein Knowledge Graph versteht Beziehungen zwischen Entitaeten. Fuer Fragen wie 'Welche Kunden kennen jemanden, der gerade kaufbereit ist?' braucht es den Graphen — das laesst sich nicht per Textaehnlichkeit beantworten.
Fuer welche Unternehmensgroesse ist ein Knowledge Graph sinnvoll?
Ab dem Moment, wo implizites Beziehungswissen geschaeftskritisch ist und in wenigen Koepfen konzentriert sitzt. Das kann ein Maklerbuero mit 5 Mitarbeitern sein oder eine Beratung mit 50.