24 June 2026 · 9 min
Vektorsuche findet Ähnliches. Für Multi-Hop-Fragen zu Beziehungen reicht das nicht.
Retrieval-augmented Generation ist der Standardweg geworden, ein Sprachmodell in eigenen Daten zu verankern, und für die meisten Teams heißt das eines: alles in Vektoren einbetten, in einer Vektordatenbank speichern und die nächsten Treffer je Frage abrufen. Für eine große Klasse von Problemen funktioniert das bemerkenswert gut. Doch es gibt eine zweite Klasse, in der es still versagt — und das Versagen ist leicht zu übersehen, weil das System weiter selbstbewusste, plausible Antworten liefert, nur unvollständige oder falsche.
Die entscheidende Unterscheidung ist nicht, welche Technologie neuer oder raffinierter ist. Es ist die Form Ihrer Daten und die Form der Fragen. Stimmt diese Diagnose, wird die Wahl zwischen reiner Vektorsuche und einem graphbasierten Ansatz offensichtlich.
Vektorsuche beantwortet Ähnlichkeitsfragen. Sie haben viel Text, jemand fragt etwas, und die Antwort liegt in einer Passage — oder einigen wenigen — die semantisch nah an der Frage sind. Produktdokumentation, Wissensdatenbanken, Support-Archive, Forschungsbibliotheken: ein nahezu perfekter Fall. Der Fakt sitzt in einem Chunk, der Chunk ähnelt der Frage, und der Abruf findet ihn.
Für diese Klasse ist Vektorsuche schnell, günstig und schwer zu schlagen. Graph-Maschinerie darüberzulegen wäre Over-Engineering — Komplexität ohne Gegenwert. Wenn Ihre Fragen durch die relevanteste Passage beantwortet werden, brauchen Sie nichts Aufwendigeres, und wir sagen es Ihnen, statt ein größeres System zu verkaufen.
Das Problem beginnt, wenn die Antwort in keiner einzelnen Passage liegt, sondern in den Beziehungen zwischen Passagen. Etwa: welche Lieferanten sind von einer Vorschrift betroffen, die eine andere ändert, die ein Bauteil regelt, das in einer Produktlinie einer bestimmten Tochter genutzt wird? Kein einzelner Chunk enthält das. Es muss durch Verfolgen von Verknüpfungen zusammengesetzt werden.
Vektorsuche kann keinen Verknüpfungen folgen. Sie ruft Passagen ab, die der Frage ähneln, aber Ähnlichkeit ist keine Verbindung. Die einzelnen Hops sind oft textlich unähnlich zur Frage, sodass die richtigen Passagen nie auftauchen. Das Modell antwortet dann aus dem, was es abrief — flüssig, selbstbewusst, falsch. Genau dieser Modus überrascht Teams, weil nichts einen Fehler wirft.
Ein Wissensgraph speichert Fakten als explizite Entitäten und Beziehungen: diese Vorschrift ändert jene, dieses Bauteil gehört zu jenem Produkt, dieses Produkt zu jener Tochter. GraphRAG verbindet diese Struktur mit Retrieval. Statt nur ähnlichen Text zu finden, kann es den Graphen traversieren — Änderungslink, dann Bauteillink, dann Eigentumslink — und eine Antwort aus einer Kette verbundener Fakten bauen.
Das erschließt Multi-Hop-Fragen, die flaches Retrieval nicht berührt. Es bringt einen zweiten, in regulierten Kontexten enorm wichtigen Vorteil: Nachvollziehbarkeit. Weil die Antwort einen expliziten Pfad durch den Graphen ging, können Sie diesen Pfad zeigen. Die Antwort kommt mit ihrer Argumentation, die Prüfer verifizieren können.
Graphen sind nicht kostenlos. Einen zu bauen heißt, Entitäten und Beziehungen aus den Daten zu extrahieren — ein Modellierungsaufwand, den Vektorsuche ganz überspringt. Sie müssen entscheiden, was die Entitäten sind, welche Beziehungen sie verbinden, und die Struktur aktuell halten. Für Text, dessen Antworten wirklich in einzelnen Passagen liegen, ist das reiner Overhead ohne Rendite.
Genau deshalb kommt die Diagnose zuerst. Zum Graphen zu greifen, weil er mächtiger klingt, ist ein häufiger und teurer Fehler. Der Graph verdient seine Kosten nur, wenn Ihre Fragen wirklich Verbindungen erfordern; sonst ist er Komplexität, die Sie ewig pflegen — ohne Nutzen.
In der Praxis sind die stärksten Systeme selten rein. Die meisten echten Korpora enthalten beide Fragearten: viele, die eine relevante Passage beantwortet, und einige, die Fakten verbinden müssen. Die richtige Architektur nutzt Vektorsuche für semantischen Recall und eine Graphschicht für die relationalen Multi-Hop-Fälle und leitet jede Frage an den passenden Mechanismus.
Diese Aufteilung gut zu entwerfen — was als Graph modellieren, was als flachen Text lassen, wie beides zur Laufzeit kombinieren — ist, wo das meiste Engineering-Urteil liegt. Richtig gemacht zahlen Sie Graph-Komplexität nur dort, wo sie sich auszahlt.
Meist diagnostizieren Sie den Fall allein aus den Fragen. Schreiben Sie die zehn schwersten Fragen auf, die Ihre Nutzer wirklich stellen. Wird jede durch die einzelne relevanteste Passage beantwortet, brauchen Sie Vektorsuche und nichts weiter. Können einige nur durch Kombinieren mehrerer, textlich unähnlicher Fakten beantwortet werden, haben Sie Multi-Hop-Fragen — und eine Graphschicht verdient ihren Platz.
Wir beginnen jedes Retrieval-Projekt mit genau dieser Übung, an Ihren echten Fragen und Daten, bevor Code entsteht. Die Technologie folgt der Diagnose, nie umgekehrt — und die Diagnose ist fast immer klarer als das Marketing um beide Ansätze.
Buchen Sie ein 30-minütiges Gespräch. Wir sagen Ihnen ehrlich, ob wir helfen können.
Termin buchen