Ein Vektor reicht nicht: Wo die Embedding-Suche an ihre Grenze stößt

Der Vektor hat eine Obergrenze. Jemand hat sie gemessen.

Letztes Mal haben wir geschrieben, dass eine Überzeugung ein Vektor ist: Ein Konzept im Modell hat Koordinaten, auf die man zeigen kann. Das stimmt, und es ist mächtig. Aber ein Vektor ist auch etwas weniger Schmeichelhaftes: eine Kompression. Eine einzige Liste von Zahlen, die für etwas viel Reicheres einsteht. Und Kompression hat Grenzen.

Ein Team von Google DeepMind und der Johns Hopkins University hat gerade eine dieser Grenzen vermessen, und das Ergebnis sollte ändern, wie Sie Suche bauen. Die Publikation trägt den Titel On the Theoretical Limitations of Embedding-Based Retrieval (ICLR 2026, arXiv:2508.21038). Ihr Befund lautet nicht „Embeddings könnten besser sein”, sondern: „Embeddings können das beweisbar nicht, und ein größeres Modell zu kaufen hilft nicht.”

Was sie bewiesen haben

Fast jedes RAG-System in Produktion arbeitet gleich. Jedes Dokument wird zu einem Vektor, die Anfrage wird zu einem Vektor, zurück kommen die Dokumente, deren Vektoren am nächsten liegen. Ein Vektor, ein Skalarprodukt, fertig. Das ist schnell, verallgemeinert gut und trägt die gesamte Branche.

Die Publikation stellt eine schlichte Frage: Kann dieser Aufbau jede Kombination von Relevanz abbilden? Lässt sich ein Ein-Vektor-Modell dazu bringen, aus einer Menge von Dokumenten jede beliebige Teilmenge als Top-Treffer zurückzugeben?

Die Antwort ist nein, und die Obergrenze ist die Dimension des Embeddings. Trägt man in ein großes Raster ein, welche Dokumente für welche Anfragen relevant sind, dann ist die Zahl der verschiedenen „Top-k”-Muster, die eine Menge von Vektoren erzeugen kann, durch die Anzahl der Zahlen pro Vektor begrenzt. Jenseits dieses Punktes sind bestimmte Relevanzmuster nicht bloß unwahrscheinlich; sie sind unerreichbar. Kein Trainingslauf, keine Datenmenge, kein Kniff innerhalb des Ein-Vektor-Paradigmas führt Sie dorthin.

Dann haben sie es beziffert. Selbst im günstigsten denkbaren Fall (die Vektoren direkt gegen die Testantworten optimiert, ohne jede Einschränkung durch echte Sprache) ist ein 512-dimensionales Embedding bei rund 500.000 Dokumenten am Ende. Ein 1024-dimensionales bei etwa 4 Millionen. Selbst ein 4096-dimensionales Embedding, größer als die meisten Produktivsysteme fahren, reicht nur bis knapp 250 Millionen. Und das ist die großzügige Grenze; echte Modelle, die zusätzlich noch tatsächliche Sprache abbilden müssen, bleiben weit darunter.

Embeddings scheitern hier nicht, weil sie schlecht trainiert wurden. Sie scheitern, weil Sie von einer festen Zahl an Dimensionen verlangen, mehr Unterscheidungen zu kodieren, als darin Platz haben.

Der Teil, der Ihnen Sorgen machen sollte

Theorie lässt sich leicht abtun. Also bauten die Autoren LIMIT: einen Datensatz, so einfach, dass er wie ein Scherz wirkt. Kurze Aussagen in natürlicher Sprache: „Jon mag Quokkas und Äpfel.” Eine triviale Frage: „Wer mag Quokkas?” Der einzige Kniff: Der Datensatz deckt systematisch viele Kombinationen ab, wer was mag.

Die modernsten Embedding-Modelle scheitern daran. Deutlich. Eine Aufgabe, die ein Kind löst, und die besten dichten Retriever der Welt bekommen sie nicht hin.

BM25 dagegen, der langweilige Stichwort-Algorithmus aus den Neunzigern, kommt der perfekten Lösung nahe. Und ein Mehrvektor-Modell schlägt die Ein-Vektor-Modelle mit großem Abstand. Es liegt nicht an der Domäne. Es lässt sich auch nicht mit mehr Trainingsbeispielen beheben; die Autoren haben es geprüft. Die einfache Aufgabe liegt grundsätzlich jenseits dessen, was ein einzelner Vektor pro Dokument abbilden kann.

Warum das über einen Benchmark hinausreicht: Die ganze Branche treibt die Suche Richtung Allgemeingültigkeit: „bilde jede Anfrage ab, jede Definition von Relevanz”, anweisungsbasierte Suche, Suche, die schlussfolgert. Genau in dieser Richtung liegt die Obergrenze. Enge, natürliche Anfragen bleiben unproblematisch, deshalb lief Ihr RAG-Prototyp. Verlangen Sie vom selben System beliebige logische Kombinationen von Relevanz, laufen Sie geradewegs gegen eine Wand, die sich durch bloßes Skalieren nicht verschieben lässt.

Was Sie stattdessen einsetzen

„Ein Vektor reicht nicht” nützt nur, wenn ein nächster Zug dazugehört. Es gibt mehrere, und die ehrliche Antwort lautet: Keiner ist ein direkter Ersatz; jeder erkauft Ausdruckskraft mit anderen Kosten.

Dünnbesetzte, lexikalische Suche (BM25, SPLADE). Der älteste Trick schlug bei LIMIT den neuesten. Der exakte Begriffsabgleich hat keine Dimensionsgrenze und ist billig. Die Lehre der letzten beiden Jahre: Die lexikalische Suche wurde zu früh aussortiert. In fast jedes ernsthafte System gehört sie hinein.

Mehrvektor, Late Interaction (ColBERT, ColPali). Statt eines Vektors pro Dokument behält man einen pro Token und vergleicht sie erst zur Anfragezeit (MaxSim). Deutlich ausdrucksstärker als ein einzelner Vektor, mit einem Nebeneffekt: Man sieht, welche Tokens übereinstimmten, die Suche ist keine Blackbox mehr. Der Preis sind Speicher und Rechenzeit (Tausende Vektoren pro Dokument), weshalb man damit in der Praxis eine Vorauswahl neu sortiert, statt den ganzen Bestand zu durchsuchen.

Cross-Encoder. Die ausdrucksstärkste Ähnlichkeit überhaupt: Anfrage und Dokument laufen gemeinsam durch das Modell. Auch die teuerste: Sie bewertet ein Paar nach dem anderen und taugt darum als letzte Stufe über einer kurzen Liste, nie als erste Suche über den ganzen Bestand.

Wo Wissensgraphen ins Spiel kommen

Alle bisherigen Alternativen fragen weiterhin: „Welcher Text ähnelt dieser Anfrage?” Ein Wissensgraph stellt eine ganz andere Frage: „Wie hängen diese Dinge zusammen?”

Statt ein Dokument in einen Vektor aufzulösen, zieht man seine Entitäten und die Beziehungen zwischen ihnen heraus und legt beides als ausdrückliche Knoten und Kanten ab. Jon mag Quokkas. Quokkas leben in Australien. Australien ist ein Land. Jetzt kann eine Anfrage dem Graphen folgen: von Kante zu Kante springen, von Fakt zu Fakt, und Fragen beantworten, die kein Ähnlichkeitswert beantwortet, weil die Antwort in genau der Struktur steckt, die ein einzelner Vektor wegwirft. Darauf bauen GraphRAG und seine leichteren Verwandten (LightRAG, LazyGraphRAG).

Wo Graphen wirklich gewinnen: bei mehrstufigen Fragen („Welche unserer Lieferanten hängen von einem Anbieter in einer sanktionierten Region ab?”), bei der Zusammenschau über viele verknüpfte Dokumente und bei der Eindeutigkeit: Ein Knoten trägt seine Beziehungen bei sich, also sind „Jaguar, das Tier” und „Jaguar, das Auto” schlicht verschiedene Knoten und nicht zwei Kollisionen im selben Embedding.

Jetzt der ehrliche Teil, denn auch Wissensgraphen werden überverkauft. Den Graphen zu bauen ist echte Arbeit: Die Entitäten zieht ein LLM heraus, und dieser Schritt halluziniert und muss nachkorrigiert werden. Früher waren die berichteten Vorteile aufgebläht: Eine 2026 um Verzerrungen bereinigte Analyse fand, dass schlichtes RAG eine beliebte GraphRAG-Variante leicht schlug, sobald man undichte Stellen in der Auswertung ausschloss. Und die unangenehme Zahl der Branche: Die meisten RAG-Projekte im Unternehmen gehen nie in Produktion, und der Aufwand für den Graphenbau ist dabei ein Wiederholungstäter. Neu ist 2026, dass die Kosten fürs Indizieren stark gefallen sind; LightRAG und LazyGraphRAG indizieren inzwischen etwa zum Preis von reinem Vektor-RAG. Die verbleibende Frage ist also Passung, nicht Budget.

Nachtrag, September 2026. Zur Frage der Passung liegen inzwischen Zahlen vor. Eine Publikation der Toronto Metropolitan University (arXiv:2608.28978) baut ein graphbasiertes Gedächtnis für Agenten mit langer Laufzeit und misst es bei gleichem Suchbudget gegen eine flache Vektorsuche: 0,417 gegen 0,468 F1, der Graph liegt hinten. Fast der gesamte Abstand geht auf eine einzige Frageart zurück. Soll eine frühere Antwort wörtlich wiedergegeben werden, fällt die bewertete Korrektheit von 0,911 auf 0,607. Der Grund liegt in der Bauart, denn wer einen Beitrag in Entitäten und Beziehungen zerlegt, wirft die Oberflächenform weg, an der solche Fragen hängen. Die Autoren schränken selbst ein, dass sie ein einzelnes kleines Extraktionsmodell auf einem Benchmark geprüft haben. Für die Faustregel unten kommt damit ein dritter Fall dazu: Neben exakter und kombinatorischer Relevanz verliert ein Graph auch dort, wo es auf den Wortlaut ankommt.

Der pragmatische Konsens ist unspektakulär und richtig: Schöpfen Sie zuerst die hybride Suche aus. BM25 plus dichte Vektoren, zusammengeführt, mit einem Reranker obendrauf, schlägt in Praxistests jede einzelne Methode um 15 bis 30 Prozent bei der Trefferquote. Zum Wissensgraphen greifen Sie erst, wenn Ihre Fragen wirklich die Zusammenschau über verknüpfte Fakten verlangen, und keinen Moment früher.

Wann ein Vektor genau richtig ist

Nichts davon heißt, dass Embeddings ein Fehler waren. Für eine große Klasse von Problemen sind sie das richtige Werkzeug, und zu wissen, welche Klasse das ist, ist die eigentliche Kunst.

Ein einzelner Vektor glänzt, wenn Relevanz heißt: “semantisch ähnlich zu dieser einen Anfrage”, Dokument für Dokument bewertet. Das deckt eine Menge echter, produktiver Arbeit ab:

• Unscharfe Suche, die Wortlücken überbrückt. „Wie kündige ich meinen Tarif?” findet eine Seite mit dem Titel „Abo beenden”: kein gemeinsames Stichwort, gleiche Bedeutung. Genau das verfehlt BM25, und genau das treffen Embeddings. Dropbox senkte damit die ergebnislosen Suchen um rund 17 %; Support-Werkzeuge wie Zendesk verbesserten damit handfeste Kennzahlen.
• Empfehlungen und „mehr davon”. Ähnliche Produkte, verwandte Artikel, Lebenslauf zu Stellenanzeige, Dublettenerkennung. Hier ist Relevanz tatsächlich Ähnlichkeit, also ist ein Ähnlichkeitswert das richtige Mittel.
• Breite erste Trefferauswahl. Ein paar Hundert plausible Kandidaten billig aus Millionen herausziehen, bevor eine langsamere, schärfere Stufe die genaue Arbeit macht.

Der Unterschied ist einfach. Die Vektorsuche gewinnt, wenn Relevanz semantisch ist, einem einzigen Begriff folgt und pro Dokument entschieden wird: Jedes Ergebnis verdient seinen Platz aus eigener Kraft, über die Bedeutung. Sie bricht, wenn Relevanz exakt ist (eine Teilenummer, ein Fehlercode, ein Name; semantische Drift macht aus „Python 3.11 Performance” allgemeine Python-Tipps), kombinatorisch (Sie brauchen eine bestimmte Menge, das Versagen bei LIMIT) oder relational (die Antwort ergibt sich aus Verbindungen: der Fall für den Wissensgraphen).

Entscheidend ist die Frage: „Was bedeutet Relevanz für diese Anfrage?” Passt das Werkzeug zur Antwort, ist ein Vektor oft alles, was Sie brauchen.

Die eigentliche Verschiebung

Die Ära „alles in eine Vektordatenbank kippen und ausliefern” endet für ernsthaftes Retrieval. Für die breite erste Trefferauswahl bleiben Vektoren großartig; das Problem ist, dass eine einzige Repräsentation nie jede Art von Frage tragen konnte. Diese Arbeit ist der Beweis, dass die Obergrenze real ist, Koordinaten hat und sich nicht darum schert, wie viel Sie für ein größeres Embedding-Modell ausgeben.

Retrieval wird wieder zur Architekturentscheidung. Lexikalisch für exakte Begriffe. Dichte Vektoren für die breite Trefferauswahl. Late Interaction für Präzision. Ein Graph für Struktur. Mit Absicht zusammengesetzt, passend zu der Relevanz, die Ihr Produkt wirklich braucht, und nicht automatisch das, was Ihnen der Schnellstart der Vektordatenbank vorgesetzt hat.

Warum wir das verfolgen

Wenn wir für einen Kunden eine Suche bauen, greifen wir nicht reflexhaft zur Vektordatenbank und hoffen auf das Beste. Wir sehen uns die Fragen an, die das System tatsächlich beantworten muss, schätzen ab, wo die Ein-Vektor-Grenze zuschlagen würde, und setzen den Stack zusammen, der passt: lexikalisch, dicht, Late Interaction, Graph, in welcher Kombination das Problem es rechtfertigt.

Das ist der Unterschied zwischen dem Abarbeiten eines Schnellstarts und dem Konstruieren eines Systems. Ein Vektor ist eine mächtige Sache. Genau zu wissen, wo er aufhört zu genügen, ist die eigentliche Arbeit.