Warum sind Graphdatenbanken als Kundendatenquelle für RAG in regulierten Branchen nicht ideal?

Graphdatenbanken bieten standardmäßig keine unscharfe Suche (eine Suche nach "Phillip Mitchel" würde "Philipp Mitchell" ohne eine zusätzliche Suchmaschine wie Elasticsearch nicht finden), sie können langsam werden, wenn der Abruf mehrere transitive Sprünge über verknüpfte Datensätze erfordert, und in regulierten Branchen lässt sich nur schwer garantieren, dass die für einen Kunden abgerufenen, untereinander verknüpften Daten ausschließlich zu diesem Kunden gehören.

Verbessert die Kombination von Entity Resolution und Vektordatenbank die Antworten eines LLM tatsächlich?

In einer gemeinsam mit den Enterprise-LLM-Spezialisten von Kern.ai aufgebauten Reiseversicherungs-Demonstration wurden drei Aufbauten verglichen: Baseline-RAG (Vektordatenbank + LLM) lieferte vage Ergebnisse; Enhanced RAG mit dem eigenen Reranking-Modell von Kern.ai war differenzierter, blieb aber mehrdeutig; Enhanced RAG plus Tilores EntityRAG lieferte die spezifischste und nützlichste Antwort, weil der falsch geschriebene Kundenname zu zwei verknüpften Kundenprofilen aufgelöst wurde, die alle aktuellen und früheren Versicherungsverträge enthielten.

Reicht eine Vektordatenbank allein für kundenspezifische Prompts?

Nicht zuverlässig. Eine Vektordatenbank ist ausgezeichnet darin, ähnliches unstrukturiertes Wissen abzurufen, etwa die Standard-Versicherungsbedingungen eines Versicherers. Sobald sich der Prompt aber auf einen namentlich genannten Kunden bezieht, brechen zwei Dinge: Ungenauigkeiten in der Sucheingabe können dazu führen, dass der relevante Kunde nicht gefunden wird, und dieser Kunde kann mehr als einen Datensatz haben, die für eine vollständige 360°-Sicht verknüpft werden müssen. Entity Resolution schließt diese Lücke, indem sie die verstreuten Datensätze zu einem aufgelösten Profil verknüpft — deshalb schlägt Tilores sie als ergänzende RAG-Quelle neben der Vektordatenbank vor.

LLM-Genauigkeit mit Entity RAG verbessern

Kurzfassung (Stand 2026): Für allgemeines Dokumentenwissen ist eine Vektordatenbank die richtige RAG-Quelle. Sobald ein LLM-Prompt aber einen bestimmten Kunden betrifft, greift eine Vektordatenbank allein zu kurz: Ungenaue Sucheingaben können den passenden Kunden verfehlen, und ein Kunde kann mehrere Datensätze haben, die für eine vollständige 360°-Sicht miteinander verknüpft werden müssen. Ergänzt man Entity Resolution – die die verstreuten Datensätze eines Kunden bereits bei der Ingestion dedupliziert und zu einem aufgelösten Profil verknüpft –, erhält das LLM zur Abfragezeit den korrekten, vollständigen Kundenkontext. Sie ergänzt die Vektordatenbank, statt sie zu ersetzen. Tilores nennt diese Kombination EntityRAG.

Was ist der Unterschied zwischen einer Vektordatenbank und einer Entity-Resolution-API für KI-Anwendungen?

Die drei folgenden Datenquellen werden alle eingesetzt, um ein LLM in RAG zu erden. Sie unterscheiden sich darin, worin sie gut sind – und darin, wie gut sie mit einem Prompt zu einem bestimmten Kunden umgehen. Die vollständige Begründung finden Sie in den Abschnitten unter dieser Tabelle.

RAG-Datenquelle	Stärke	Grenze bei kundenspezifischem RAG
Vektordatenbank	Abruf ähnlicher unstrukturierter Inhalte (z. B. Policendokumente)	Kann bei ungenauer Eingabe den richtigen Kunden verfehlen; kann mehrere Datensätze eines Kunden nicht zu einem Profil verknüpfen
Graphdatenbank	Abbildung verbundener, untereinander verknüpfter Daten	Standardmäßig keine unscharfe Suche; langsam bei transitiven Sprüngen; schwer zu garantieren, dass die abgerufenen Daten zu genau einem Kunden gehören
Entity-Resolution-API (EntityRAG)	Deduplizierung und Verknüpfung der Datensätze eines Kunden zu einem aufgelösten Profil bereits bei der Ingestion	Ergänzt die Vektordatenbank, statt sie zu ersetzen – beide zusammen ergeben kundenbewusstes RAG

Seit Large Language Models (LLMs) explosionsartig an Popularität gewonnen haben – maßgeblich angetrieben von OpenAIs ChatGPT –, prüfen Unternehmen, wie sie LLMs auf privaten, internen Datenbeständen betreiben können, die diese Modelle nie gesehen haben und die vertraulich bleiben müssen.

Retrieval Augmented Generation (RAG) ist die Technik, LLMs mit zusätzlichen Daten aus Quellen anzureichern, die Sie selbst kontrollieren. In diesem Beitrag stellen wir EntityRAG vor, entwickelt von Tilores, als deutliche Verbesserung für Genauigkeit und Zuverlässigkeit von LLMs, insbesondere in regulierten Umgebungen.

Typischerweise beruht eine RAG-Datenquelle auf einer Vektordatenbank. Die Vektorsuche ist hervorragend darin, Daten aus unstrukturierten Quellen abzurufen. Wenn Sie beispielsweise RAG für einen Versicherer aufbauen, könnten Sie sämtliche Standard-Versicherungsbedingungen Ihres Unternehmens in einer Vektordatenbank ablegen. Das LLM könnte dann bei einem passenden Prompt ähnliches Wissen abrufen und die Versicherungsbedingungen über die Vektordatenbank als Kontext nutzen.

Welche Datenquelle sollte ein LLM aber verwenden, wenn sich der Prompt auf einen bestimmten Kunden bezieht? In diesem Fall wäre eine Vektordatenbank aus folgenden Gründen ungeeignet:

Ungenauigkeiten in der Sucheingabe können dazu führen, dass der relevante Kunde nicht gefunden wird.
Der relevante Kunde hat womöglich mehr als einen Kundendatensatz, und diese müssen für eine vollständige 360°-Kundensicht korrekt miteinander verknüpft werden.

Um das zu lösen, schlagen wir vor, Entity-Resolution-Technologie als ergänzende Datenquelle neben Vektordatenbanken in RAG einzusetzen. Wir nennen das EntityRAG.

Was ist Entity Resolution?

Entity Resolution ist der Prozess, Datensätze zu deduplizieren, zu verknüpfen und durchsuchbar zu machen, die sich auf eine reale Entität beziehen (also eine Person, ein Unternehmen, ein Produkt) und aus einer oder mehreren Datenquellen stammen. Wird sie speziell auf Personendaten angewendet, spricht man häufig von „Identity Resolution".

Sie stützt sich auf Fuzzy-Matching-Algorithmen wie die Kosinus-Ähnlichkeit (die auch in Vektordatenbanken häufig zum Einsatz kommt), um zu erkennen, wann Datensätze sich in einzelnen Attributen leicht unterscheiden, aber dennoch als identisch gelten sollten.

Typischerweise wird Entity Resolution zur Erkennung von Finanzkriminalität, zur Betrugsprävention und als Bestandteil einer Customer Data Platform (CDP) eingesetzt, um Kundenprofile aus verschiedenen Quellen abzugleichen.

Wichtig für regulierte Branchen, in denen die Genauigkeit der Daten entscheidend ist: Entity-Resolution-Systeme lassen sich so justieren, dass sie hochgenaue, zuverlässige und erklärbare Ergebnisse liefern.

Und was ist mit Graphdatenbanken?

Auch Graphdatenbanken wie Neo4j sind zuletzt als RAG-Quelle beliebter geworden. Tatsächlich eignen sich Graphen außerordentlich gut, um vielfältige und untereinander verknüpfte Daten strukturiert zu organisieren und abzubilden, und sie können Vektordatenbanken in RAG ergänzen.

Sie haben jedoch bestimmte Grenzen, die sie für manche LLM-Anwendungen weniger als ideal machen.

Keine unscharfe Suche
Schwierigkeiten bei transitiven Sprüngen, wenn verknüpfte Datensätze schnell abgerufen werden müssen.
Mangelnde Genauigkeit bei der Unterscheidung und Abgrenzung eigenständiger Entitäten.

Standardmäßig bieten Graphdatenbanken keine unscharfe Suche. Wenn Sie also nach „Phillip Mitchel" suchen, erhalten Sie die Daten zu „Philipp Mitchell" wegen des Schreibfehlers nicht. Sie können das mit einer Suchmaschine wie Elasticsearch umgehen, führen damit aber ein weiteres komplexes System ein, das betrieben werden muss.

Transitive Sprünge sind ein besonderes Problem von Graphdatenbanken. Weil theoretisch alle Daten mit allen anderen Daten verbunden sind, kann der Abruf sehr langsam werden, sobald der Graph mehrere Knoten (Datensätze) durchlaufen muss.

Die Genauigkeit bei eigenständigen Entitäten ist in regulierten Branchen ein besonderes Problem. Wenn Sie die Daten zu einem Kunden abrufen und diese Daten aus Datensätzen stammen, die – möglicherweise aus ganz unterschiedlichen Quellen – miteinander verknüpft wurden, müssen Sie sicher sein können, dass sie tatsächlich zusammengehören.

Graphdatenbanken sind zwar hervorragend darin, komplexe Beziehungen abzubilden, stoßen in bestimmten Szenarien aber an Grenzen, insbesondere bei Kundendaten in regulierten Branchen. Die stark verwobene Natur von Graphstrukturen kann es mitunter schwer machen zu garantieren, dass die abgerufenen Daten ausschließlich zu einem einzigen Kunden gehören – vor allem bei großen, komplexen Datenbeständen.

EntityRAG für Genauigkeit und Zuverlässigkeit

Um zu prüfen, ob Entity Resolution in Kombination mit einer Vektordatenbank bessere Ergebnisse liefert als eine Vektordatenbank allein, haben wir uns mit den Enterprise-LLM-Spezialisten von Kern.ai zusammengetan und ein Demonstrationsszenario am Beispiel eines Reiseversicherers aufgebaut. Das Webinar-Video finden Sie am Ende der Seite.

In dieser Demo haben wir drei Aufbauten getestet:

Baseline-RAG – eine Vektordatenbank und ein LLM
Enhanced RAG – mit dem eigenen Reranking-Modell von Kern.ai
Enhanced RAG + EntityRAG – Anreicherung des Enhanced RAG mit Ergebnissen aus Tilores

Baseline-RAG

Baseline-RAG wie in der Cognition-Plattform von Kern.ai konfiguriert. Baseline-RAG allein mit einer Vektordatenbank lieferte sehr vage Ergebnisse.

Enhanced RAG

Enhanced RAG mit dem eigenen Reranking-LLM von Kern.ai. Enhanced RAG lieferte eine differenziertere Antwort, es blieb aber eine gewisse Mehrdeutigkeit.

Enhanced RAG + Tilores EntityRAG

Hier wurden Vor- und Nachname aus der Kundennachricht extrahiert und zur Suche nach dem Kunden in Tilores verwendet. Der aus der Eingabe extrahierte Name enthält Schreibfehler. Aus Tilores zurück kommen zwei Kundenprofile, die miteinander verknüpft wurden und Informationen zu allen aktuellen und früheren Versicherungsverträgen enthalten.

Die daraus resultierende Antwort ist weit spezifischer und nützlicher als die beiden vorherigen Ergebnisse, denn dank EntityRAG weiß das LLM, welcher Kunde gemeint ist und welche Versicherungen dieser aktuell hat.

Fazit

Unsere Zusammenarbeit mit Kern.ai hat gezeigt, dass ein fortgeschrittenes Entity-Resolution-System wie Tilores die Genauigkeit und Relevanz der Antworten von Large Language Models (LLMs) deutlich verbessern kann. Diese Neuerung, verkörpert in EntityRAG, wird regulierten Unternehmen helfen, LLM-Anwendungen mit besserer Genauigkeit und Relevanz zu entwickeln.

Sobald Ihre Kundendaten in Tilores vereinheitlicht sind, dient dieser einheitliche, deduplizierte Datenbestand als verlässliche Quelle der Kundenwahrheit und trägt Funktionen wie Betrugsprävention, KYC (Know Your Customer) und Marketing-Operations – ohne dass Sie eine eigene Dateninfrastruktur aufbauen oder die Kosten einer Migration in ein zentrales Data Warehouse tragen müssen.

Der aktuelle Stand (2026): GraphRAG und wo Entity Resolution weiterhin gewinnt

Seit der Erstveröffentlichung dieses Artikels hat der graphdatenbankbasierte RAG-Ansatz unter dem Namen GraphRAG feste Konturen bekommen. Microsoft Research stellte GraphRAG am 13. Februar 2024 vor und nutzt dabei einen LLM-generierten Knowledge Graph als Retrieval-Schicht. Als Stärken nennt Microsoft das „Verbinden der Punkte" über verstreute Informationen hinweg, die ganzheitliche Zusammenfassung eines gesamten Datenbestands sowie die Nachvollziehbarkeit der Herkunft, sodass sich eine Antwort auf den Datenbestand zurückführen lässt.

Neo4j Labs positioniert GraphRAG inzwischen ausdrücklich als Hybrid: Es „kombiniert bewertete Vektorsuche mit struktureller Graphsuche", nutzt also die Vektorsuche, um relevante Textabschnitte zu finden, und folgt anschließend den Graphbeziehungen nach außen (Multi-Hop). Neo4j beschreibt das als Ersatz für die „Black-Box-Suche rein über Vektoren" durch einen nachvollziehbaren Pfad.

Das bestätigt die ursprüngliche Aussage dieses Artikels, statt sie zu widerlegen: Graph und Vektor ergänzen einander, und ein Knowledge Graph fügt Struktur und Herkunftsnachweis hinzu. GraphRAG ist jedoch darauf optimiert, einen Dokumentenbestand zu erschließen – nicht darauf, zu garantieren, dass die zu einem bestimmten Kunden abgerufenen Datensätze auch tatsächlich zu diesem Kunden gehören.

Genau bei dieser Ein-Kunden-Garantie gewinnt Entity Resolution weiterhin. Sie bringt Fuzzy Matching von Haus aus mit (sodass „Phillip Mitchel" weiterhin zu „Philipp Mitchell" aufgelöst wird), sie dedupliziert und verknüpft die verstreuten Datensätze eines Kunden bereits bei der Ingestion zu einem aufgelösten Profil, und in regulierten Branchen lässt sie sich auf erklärbare, prüfbare Übereinstimmungen justieren. Das praktische Muster für 2026 lautet deshalb nicht „Vektor vs. Graph vs. Entity Resolution", sondern: Nutzen Sie eine Vektordatenbank (oder GraphRAG) für Dokumentenwissen und ergänzen Sie eine Entity-Resolution-Schicht, wenn die Antwort davon abhängt, die Identität eines einzelnen Kunden exakt richtig zu treffen.

Möchten Sie das selbst ausprobieren?

Bauen Sie Ihr eigenes EntityRAG: Buchen Sie eine Demo, um Echtzeit-Matching auf Ihren eigenen Daten zu sehen, oder holen Sie sich den Evaluation Build, um es lokal zu testen. Anschließend zeigt Ihnen die Entity-Resolution-Software von Tilores, wie Echtzeit-Matching die Datensätze eines Kunden zu einem aufgelösten Profil verknüpft.

Häufig gestellte Fragen

Was ist der Unterschied zwischen einer Vektordatenbank und einer Entity-Resolution-API für KI-Anwendungen?: Eine Vektordatenbank ist hervorragend darin, ähnliches Wissen aus unstrukturierten Quellen abzurufen, etwa die Standard-Versicherungsbedingungen eines Versicherers. Bezieht sich der Prompt jedoch auf einen bestimmten Kunden, kann eine Vektordatenbank scheitern: Ungenauigkeiten in der Sucheingabe können den relevanten Kunden verfehlen, und ein einzelner Kunde kann mehr als einen Datensatz haben, die für eine vollständige 360°-Sicht korrekt verknüpft werden müssen. Entity Resolution löst das, indem sie Kundendatensätze dedupliziert, verknüpft und durchsuchbar macht – sie funktioniert damit als ergänzende RAG-Datenquelle neben der Vektordatenbank. Tilores nennt diese Kombination EntityRAG.
Warum sind Graphdatenbanken als Kundendatenquelle für RAG in regulierten Branchen nicht ideal?: Graphdatenbanken bieten standardmäßig keine unscharfe Suche (eine Suche nach „Phillip Mitchel" würde „Philipp Mitchell" ohne eine zusätzliche Suchmaschine wie Elasticsearch nicht finden), sie können langsam werden, wenn der Abruf mehrere transitive Sprünge über verknüpfte Datensätze erfordert, und in regulierten Branchen lässt sich nur schwer garantieren, dass die für einen Kunden abgerufenen, untereinander verknüpften Daten ausschließlich zu diesem Kunden gehören.
Verbessert die Kombination von Entity Resolution und Vektordatenbank die Antworten eines LLM tatsächlich?: In einer gemeinsam mit den Enterprise-LLM-Spezialisten von Kern.ai aufgebauten Reiseversicherungs-Demonstration wurden drei Aufbauten verglichen: Baseline-RAG (Vektordatenbank + LLM) lieferte vage Ergebnisse; Enhanced RAG mit dem eigenen Reranking-Modell von Kern.ai war differenzierter, blieb aber mehrdeutig; Enhanced RAG plus Tilores EntityRAG lieferte die spezifischste und nützlichste Antwort, weil der falsch geschriebene Kundenname zu zwei verknüpften Kundenprofilen aufgelöst wurde, die alle aktuellen und früheren Versicherungsverträge enthielten.
Reicht eine Vektordatenbank allein für kundenspezifische Prompts?: Nicht zuverlässig. Eine Vektordatenbank ist ausgezeichnet darin, ähnliches unstrukturiertes Wissen abzurufen, etwa die Standard-Versicherungsbedingungen eines Versicherers. Sobald sich der Prompt aber auf einen namentlich genannten Kunden bezieht, brechen zwei Dinge: Ungenauigkeiten in der Sucheingabe können dazu führen, dass der relevante Kunde nicht gefunden wird, und dieser Kunde kann mehr als einen Datensatz haben, die für eine vollständige 360°-Sicht verknüpft werden müssen. Entity Resolution schließt diese Lücke, indem sie die verstreuten Datensätze zu einem aufgelösten Profil verknüpft – deshalb schlägt Tilores sie als ergänzende RAG-Quelle neben der Vektordatenbank vor.

Webinar-Video

Das EntityRAG-Webinar ansehen