Semantik ist Wunsch, Index ist Tatsache

Das ist eine äußerst fortschrittliche und genau den Kern des Problems treffende Frage. Das Aufkommen von PageIndex und No-Vector RAG (RAG ohne Vektoren) ist tatsächlich eine Reflexion über und Korrektur der Einschränkungen des derzeit vorherrschenden Vector RAG (Retrieval-Augmented Generation auf Basis von Vektordatenbanken).

Einfach gesagt ist PageIndex eine auf dem invertierten Index (Inverted Index) basierende Technologie. Sie soll durch den Abgleich von Schlüsselwörtern präzise relevante „Seiten (Pages)“ oder vollständige Kontexte finden, statt sich auf eine unscharfe semantische Vektorsuche über Textfragmente zu verlassen.

Im Folgenden erläutere ich dir ausführlich das Konzept von PageIndex und warum wir beginnen, uns dem „No-Vector RAG“ zuzuwenden oder es damit zu kombinieren.

---

1. Was ist PageIndex?

Beim herkömmlichen Vector RAG teilen wir Dokumente in kleine Einheiten (Chunks) auf, wandeln sie in Vektoren um und suchen anschließend nach ähnlichen Vektoren.
Im PageIndex-Modus kehrt die Logik zum Ursprung der Suchmaschinen zurück:

1. Indexierungsphase: Das System teilt Dokumente nicht mehr in Fragmente auf und vektorisiert sie nicht, sondern erstellt einen globalen invertierten Index (ähnlich der Indexseite am Ende eines Buches). Er verzeichnet, auf welchen Seiten (Pages) oder in welchen Dokumenten jedes Schlüsselwort (Keyword) vorkommt.
2. Retrieval-Phase: Wenn der Benutzer eine Frage stellt, extrahiert das System die Schlüsselwörter aus der Frage und lokalisiert über den invertierten Index direkt die vollständigen Seiten, die diese Schlüsselwörter enthalten.
3. Generierungsphase: Das System übergibt diese vollständigen Seiteninhalte (statt fragmentierter Chunks) als Kontext an das LLM (großes Sprachmodell), damit das LLM selbst lesen, verstehen und die Antwort extrahieren kann.

Kernunterschied: Vector RAG gibt dem LLM „zerstückelte Absätze“; PageIndex gibt dem LLM „vollständige Seiten mit Hinweisen“.

---

2. Warum sollte man „No-Vector RAG“ (RAG ohne Vektoren) einsetzen?

Vector RAG ist zwar weit verbreitet, legt bei der praktischen Umsetzung jedoch drei zentrale Probleme offen. No-Vector RAG wurde genau entwickelt, um diese Probleme zu lösen:

A. Semantische Fragmentierung durch das „Chunking“ (The Chunking Problem)

• Problem von Vector RAG: Um lange Dokumente in einer Vektordatenbank zu speichern, müssen sie in Blöcke von 500–1000 Zeichen geteilt werden. Dadurch geht Kontext verloren. Beispielsweise kann sich die „Vertragsverletzungsklausel“ eines Vertrags auf Seite 5 befinden, während der „Entschädigungsbetrag“ auf Seite 10 steht. Die Vektorsuche findet möglicherweise nur den Block von Seite 5, sodass das LLM die vollständige logische Frage nicht beantworten kann.
• Vorteil von No-Vector: PageIndex sucht nach Pages (Seiten) oder Documents (Dokumenten). Das LLM verfügt dadurch über ein längeres Kontextfenster (mit der Unterstützung von 128k/200k/1M Token durch die Modelle wird dies praktikabel) und kann logische Beziehungen über mehrere Absätze hinweg verstehen.

B. Unscharfer Abgleich vs. präziser Abgleich (Fuzziness vs. Precision)

• Problem von Vector RAG: Die Vektorsuche ist eine unscharfe Suche auf Grundlage „semantischer Ähnlichkeit“.
  • Beispiel: Du suchst nach „Fehlercode 1024“, aber der Vektor findet möglicherweise relevante Inhalte zu „Fehlercode 1025“, weil beide im mathematischen Raum nahe beieinanderliegen. Für Programmierer ist das jedoch völlig falsch.
  • Versagen bei Eigennamen: Bei der Suche nach bestimmten SKU-Nummern, Namen oder extrem seltenen Wörtern versagen Vektoren häufig.
• Vorteil von No-Vector: Ein invertierter Index arbeitet mit präzisem Abgleich. Suchst du nach „1024“, erhältst du nur Seiten, die „1024“ enthalten. Für Bereiche wie Recht, Finanzen und Code, in denen Genauigkeit entscheidend ist, ist das von großer Bedeutung.

C. Mangelnde Erklärbarkeit und Wartungskosten (Black Box & Complexity)

• Problem von Vector RAG: Ein Vektor ist eine Blackbox. Du weißt nicht, warum das System A und B für ähnlich hält. Außerdem ist die Wartung einer leistungsfähigen Vektordatenbank (Vector DB) teuer, und die Aktualisierung des Index (Hinzufügen, Löschen, Ändern und Abfragen) ist komplexer als bei herkömmlichen Datenbanken.
• Vorteil von No-Vector: Die schlüsselwortbasierte Suche ist vollständig erklärbar („weil diese Seite diese drei Suchbegriffe enthält“). Außerdem sind Technologien für invertierte Indizes (wie Lucene und ElasticSearch) bereits sehr ausgereift, kostengünstig und effizient.

---

3. PageIndex vs. Vector RAG: zentraler Vergleich

Um die beiden Architekturen anschaulicher zu verstehen, können wir sie miteinander vergleichen:

---

4. Warum wird es erst jetzt populär? (Technischer Hintergrund)

Du fragst dich vielleicht: „Sind invertierte Indizes nicht eine jahrzehntealte Technologie? Warum spricht man erst jetzt darüber?“

Der Grund ist, dass das Kontextfenster (Context Window) von LLMs größer geworden ist.

• Früher (Anfang 2023): LLMs konnten nur 4k Token verarbeiten. Wenn du eine ganze Seite (möglicherweise 2k Token) einfügtest, war das Fenster nach zwei Seiten voll. Deshalb musste man Chunks erstellen (Vector RAG).
• Heute: Claude 3 unterstützt 200k, Gemini 1.5 Pro unterstützt mehr als 1M Token.
• Ergebnis: Wir müssen Wissen nicht mehr mühsam „zerstückeln“. Wir müssen nur mit PageIndex schnell etwa 10 relevante Seiten lokalisieren und diese 10 Seiten dem LLM vollständig übergeben: „Lies innerhalb dieses Bereichs und finde die Antwort für mich.“

Dieses Muster „Retrieve Pages -> LLM Reads All“ liefert häufig bessere Ergebnisse als „Embed Chunks -> Retrieve Chunks -> LLM Guesses“.

---

Zusammenfassung

No-Vector RAG (PageIndex) bedeutet nicht, Vektoren vollständig aufzugeben, sondern die Probleme zu lösen, dass die Vektorsuche „nicht präzise genug“ ist und „Kontext verliert“.

• Vector RAG ist wie ein Bibliothekar mit sehr guter Intuition: Er weiß ungefähr, welche Bücher mit deiner Frage zu tun haben, reißt dir aber nur einige Seiten heraus.
• PageIndex ist wie ein präzises Indexsystem: Es schlägt alle Seiten auf, auf denen die Schlüsselwörter vorkommen, und lässt dich selbst (das LLM) den vollständigen Kapitelinhalt lesen.

Der Trend der Zukunft ist Hybrid RAG: Zuerst mit PageIndex sicherstellen, dass die Schlüsselwörter abgedeckt sind (Präzision), und anschließend mit Vector semantische Lücken ergänzen (Generalisierung).

Möchtest du als Nächstes, dass ich dir ein einfaches Python-Codebeispiel zeige, das die Unterschiede zwischen „vektorbasierter Suche“ und „schlüsselwortindexbasierter Suche“ in der praktischen Codeimplementierung vergleicht?

Das ist eine sehr scharfsinnige Frage. Dass Vector RAG für dich „so schlecht klingt“, liegt daran, dass wir es gerade mit der Präzision (der Stärke von PageIndex) gegen seine Vagheit (der Schwäche von Vector RAG) in Stellung gebracht haben.

Tatsächlich ist Vector RAG die derzeit vorherrschende Technologie. Es ist nicht „schlecht“, sondern es opfert „Präzision“ für „Allgemeinheit“.

Um deine Frage zu beantworten, müssen wir in die zugrundeliegende Logik von Vector RAG eintauchen und sehen, wie es lange Texte tatsächlich „komprimiert“ und „zerstückelt“.

---

I. Wie wurde das ursprüngliche Vector RAG gemacht? (Standardprozess)

Der Kern von Vector RAG ist die Umwandlung von Text in mathematische Koordinaten. Der Arbeitsablauf besteht normalerweise aus vier Schritten:

1. Chunking (Zerschneiden):

• Zuerst wird ein langes Dokument (z. B. eine 100-seitige PDF) in unzählige kleine Absätze zerschnitten.

• Zum Beispiel alle 500 Wörter ein Stück.

• Folge: Der ursprünglich zusammenhängende logische Fluss des Artikels wird gewaltsam unterbrochen.

2. Embedding (Vektorisierung):

• Ein Modell (wie OpenAI's text-embedding-3) wird verwendet, um diese 500 Wörter in eine Reihe von Zahlen (normalerweise 1536 Gleitkommazahlen) umzuwandeln.

• Diese Zahlenreihe repräsentiert die „semantische Position“ dieses Textabschnitts.

3. Indexing (Speicherung):

• Diese Zahlenreihe wird in einer Vektordatenbank (Vector DB) gespeichert.

4. Retrieval (Abruf):

• Wenn du eine Frage stellst, wird auch deine Frage in eine Zahlenreihe umgewandelt.

• Die Datenbank berechnet, welcher Textabschnitt in seinen Zahlen deiner Frage am nächsten kommt (Kosinus-Ähnlichkeit) und holt diese Abschnitte heraus.

---

II. Wie wurde langer Text „komprimiert“? (Kernprinzip)

Das ist der anspruchsvollste Teil deiner Frage. Dabei wird der Text zweimal komprimiert, was auch die Ursache für den Informationsverlust ist.

1. Physische Kompression: Das Chunking

Stell dir vor, du siehst dir einen Film (langer Text) an. Der Cutter schneidet den Film in unzählige 30-Sekunden-Clips (Chunks).

• Problem: Wenn ein Dialog einen Schnittpunkt überspannt, z. B. der erste Satz in Clip 1 und der zweite Satz in Clip 2, und du nur Clip 1 abrufst, weißt du nicht, worum es geht. Das ist Kontextverlust.

2. Semantische Kompression: Das Embedding

Das ist der abstrakteste Schritt. Die sogenannte „Vektorisierung“ ist eigentlich eine extrem verlustbehaftete semantische Kompression.

• Prinzip: Das Embedding-Modell liest die 500 Wörter und versucht dann, mit 1536 Dimensionen (Zahlen) zusammenzufassen, worum es in diesen 500 Wörtern geht.

• Vergleich: Angenommen, du musst jemandem einen Freund vorstellen (langer Text).

• Vollständige Vorstellung (Originaltext): „Er heißt Ming, isst gerne scharf, wurde als Kind von einem Hund gebissen und hat deshalb Angst vor Hunden, ist kürzlich von seiner Freundin verlassen worden …“

• Vektorisierung (komprimiert): [Größe: 180, Gewicht: 70kg, Geschlecht: männlich, Emotionsindex: 0.2]

• Warum ist das „schlecht“?

• Diese Kompression verliert Details. Wenn deine Frage ist: „Was ist Ming als Kind passiert?“, kannst du aus der reinen Zahlenreihe (Größe, Gewicht) nicht ableiten, dass er „von einem Hund gebissen wurde“.

• Das Embedding komprimiert einen reichhaltigen Text tatsächlich zu einem „vagen Hauptthema“. Es merkt sich „dieser Abschnitt handelt von persönlichen Daten“, vergisst aber möglicherweise die spezifische „Telefonnummer“.

---

III. Warum klingt Vector RAG so „schlecht“?

Es liegt nicht an der Technologie an sich, sondern an ihren inhärenten Schwächen bei der Verarbeitung wissensintensiver Aufgaben. Diese zeigen sich hauptsächlich in drei Punkten:

1. „Vagheit“ führt zu „Halluzinationen“

Die Vektorsuche basiert auf „Ähnlichkeit“.

• Beispiel: Du suchst nach „Getränk ohne Zucker“.

• Vektorergebnis: Es könnte dir „zuckerhaltige Getränke“ empfehlen.

• Grund: Im mathematischen Raum liegen die Wörter „mit Zucker“ und „ohne Zucker“ sehr nahe beieinander (weil sie beide über Zucker und Getränke sprechen). Der Vektor hat Schwierigkeiten, das entscheidende Wort „ohne“ zu unterscheiden. Ein invertierter Index (Keyword-Abgleich) macht diesen Fehler nicht, weil er das Wort „ohne“ exakt matchen muss.

2. „Chunking“ zerstört die Logik

Viele komplexe Dokumente (wie juristische Verträge, technische Handbücher) erfordern ein Verständnis über Absätze hinweg.

• Szenario: Die Definition steht auf Seite 1, die konkrete Ausführung auf Seite 10.

• Vector RAG: Es könnte die Ausführungsschritte von Seite 10 abrufen, aber weil Seite 1 weggeschnitten wurde, weiß das LLM nicht, was die darin erwähnten Fachbegriffe bedeuten, und beginnt zu fabulieren.

3. „Blackbox“ verhindert Optimierung

• Wenn ein Benutzer eine Frage stellt und die Vektordatenbank die falschen Fragmente zurückgibt, ist es für Entwickler schwierig, dies zu debuggen.

• Du weißt nicht, warum diese eine Reihe von 1536 Zahlen als „ähnlich“ zu jener anderen Reihe von Zahlen eingestuft wird. Das macht die Optimierung des Systems sehr schwierig.

---

Zusammenfassung: Warum verwenden wir immer noch Vector RAG?

Obwohl es viele Nachteile zu haben scheint, hat Vector RAG einen unschlagbaren Vorteil gegenüber PageIndex: Es versteht die „Zwischentöne“ der menschlichen Sprache.

• Benutzer: „Mein Auto springt nicht an.“

• Dokument: „Eine entladene Batterie kann dazu führen, dass der Motor nicht startet.“

In diesem Fall:

• PageIndex (Keywords) könnte versagen, weil der Benutzer weder „Batterie“ noch „Startfehler“ sagt.

• Vector RAG (Vektoren) würde erfolgreich sein, weil es erkennt, dass „springt nicht an“ und „Startfehler“ semantisch dasselbe sind.

Fazit: Dass das ursprüngliche Vector RAG für dich „schlecht“ klingt, liegt daran, dass es eine „vage Zusammenfassung“ ist. PageIndex hingegen ist eine „präzise Lokalisierung“. Der Trend geht heute dahin, Text nicht mehr zu komprimieren. Da LLMs in der Lage sind, auf einmal 1 Million Wörter zu lesen, neigen wir zunehmend dazu, den „unkomprimierten Originaltext“ direkt dem LLM zu geben und das intelligenteste Modell selbst lesen zu lassen, anstatt uns auf den „Vermittler, der nur die Körpergröße berechnet (das Vektormodell)“ zu verlassen.

Deine Intuition ist sehr scharf. Tatsächlich sind „Semantische Segmentierung (Semantic Chunking)“ und „feinere Granularität (Small-to-Big)“ die beiden Hauptrichtungen, in die sich die RAG-Optimierung derzeit bewegt.

Es ist nicht so, dass diese Ansätze „nicht verwendet“ werden, sondern sie bringen jeweils neue Nebenwirkungen mit sich.

Das ist wie beim Kuchenanschneiden:

• Feste Größe (traditionell): Egal wie, alle 5 cm ein Schnitt. Einfach und grob, aber leicht, das Muster zu beschädigen.

• Semantische Segmentierung: Entlang des Musters schneiden. Gutes Ergebnis, aber das Schneiden dauert lange und es ist schwer zu definieren, wo das „Muster“ endet.

• Feiner zerschneiden: In Krümel zerkleinern. Jeder Krümel ist essbar, aber du weißt nicht, ob dieser Krümel ursprünglich von der Erdbeere oben oder vom Boden unten stammt.

Im Folgenden erkläre ich im Detail, warum diese beiden Ansätze das Problem nicht vollständig lösen:

---

I. Warum wird „Semantische Segmentierung“ nicht flächendeckend eingesetzt?

Semantische Segmentierung bedeutet, mit einem NLP-Modell zu beurteilen, „ob dieser Absatz zu Ende ist“, und dann zu schneiden, anstatt starr nach Wortzahl zu schneiden.

Obwohl es perfekt klingt, gibt es in der Praxis drei große Hürden:

1. Langsam und teuer (Latenz & Kosten)

• Beim traditionellen Zerschneiden nach Wortzahl reicht eine Zeile Python-Code text[0:500], das dauert 0,0001 Sekunden.

• Die semantische Segmentierung erfordert, dass das Modell den Artikel „liest“, die Ähnlichkeit benachbarter Sätze berechnet oder das LLM beurteilen lässt, „ob hier das Thema wechselt“. Die Verarbeitung einer großen Datei kann Minuten oder länger dauern. Für Systeme mit hohen Echtzeitanforderungen ist das inakzeptabel.

2. Die Grenzen der „Semantik“ sind extrem vage

• Beispiel: Ein Absatz spricht zuerst über den „Produktpreis“ und dann direkt über die „Rückerstattungsrichtlinie“.

• Schneidest du ab, wenn der „Preis“ zu Ende ist? Aber wenn du schneidest, und der Benutzer fragt: „Zu welchem Preis wird das Produkt bei Rückerstattung berechnet?“, ist RAG ratlos, weil der „Preis“ im vorherigen Block und die „Rückerstattung“ in diesem Block liegt. Der Zusammenhang ist unterbrochen.

3. Löst das Problem der „globalen Abhängigkeit“ immer noch nicht

• Selbst wenn du perfekt nach Absätzen trennst, kann dieser Absatz dennoch von einer Definition abhängen, die Seiten zuvor steht.

• Zum Beispiel sagt ein Absatz auf Seite 10: „Gemäß der oben genannten Vereinbarung ausführen …“

• Die semantische Segmentierung stellt zwar sicher, dass dieser Absatz vollständig ist, enthält aber immer noch nicht die „oben genannte Vereinbarung“ von Seite 1.

---

II. Warum die Absätze nicht feiner zerschneiden?

Du könntest denken: „Wenn große Stücke Rauschen enthalten, schneide ich sie auf Satzebene (Sentence Level). Wenn ich einen Satz finde, verwende ich diesen Satz. Wäre das nicht am präzisesten?“

Hier kommen wir zum klassischen Paradoxon im RAG-Bereich: Retrieval-Granularität vs. Verständnis-Granularität.

Zu feines Zerschneiden (z. B. nach Sätzen) führt zu folgenden fatalen Problemen:

1. Die Pronomen-Katastrophe (Das Pronomen-Problem)

• Originaltext: „Elon Musk gründete SpaceX. Es senkte die Raketenstartkosten drastisch.“

• Nach dem Zerschneiden (feine Granularität):

• Block A: „Elon Musk gründete SpaceX.“

• Block B: „Es senkte die Raketenstartkosten drastisch.“

• Suche: Benutzer fragt: „Was senkte die Startkosten?“

• Ergebnis: Der Vektor findet Block B.

• Dem LLM präsentiert: Das LLM sieht „Es senkte die Kosten“. Das LLM fragt: „Wer ist ‚Es‘?“

• Ende: Weil zu fein geschnitten wurde, ging die Referenzbeziehung verloren. Dieses Fragment wird zu nutzlosen Daten.

2. Zu geringe semantische Dichte (Low Semantic Density)

• Die Vektorsuche benötigt einen Absatz mit ausreichend „Informationsgehalt“, um genau zu lokalisieren.

• Wenn du in kurze Sätze schneidest: „Ja, ich stimme zu.“ Oder „Gemäß den folgenden Bestimmungen:“.

• Diese kurzen Sätze erzeugen extrem allgemeine Vektoren ohne besondere Merkmale. Wenn der Benutzer sucht, tauchen diese kurzen Sätze als Rauschen in großer Zahl auf und verdrängen die wirklich nützlichen Informationen in der Rangfolge.

3. Fragmente ergeben kein Gesamtbild

• Angenommen, das Fenster des LLMs kann 5 Blöcke aufnehmen.

• Grobes Zerschneiden: Du siehst 5 vollständige Absätze und verstehst ungefähr den Zusammenhang.

• Extrem feines Zerschneiden: Du siehst 5 isolierte Sätze. Es ist, als ob du 5 Puzzleteile bekommst und das gesamte Bild erraten müsstest – extrem schwierig.

---

III. Aktuelle fortgeschrittene Lösung: Parent-Child Indexing (Eltern-Kind-Indexierung)

Um die beiden von dir aufgeworfenen Probleme zu lösen, heißt die derzeit ausgereifteste Lösung "Small-to-Big" (kleine Blöcke zum Abruf, große Blöcke für das LLM).

Dies ist ein Kompromiss, der die Vorteile von „fein schneiden“ und „nicht zerstückeln“ kombiniert:

1. Segmentierungsphase:

• Child Chunk (kleiner Block): Das Dokument wird in extrem feine Sätze oder kleine Absätze (z. B. 100 Wörter) zerschnitten. Diese werden für die Vektorisierung und den Abruf verwendet. Da kleine Blöcke semantisch rein sind, ist die Abrufgenauigkeit hoch.

• Parent Chunk (großer Block): Es wird aufgezeichnet, zu welchem größeren übergeordneten Absatz (z. B. 1000 Wörter) oder sogar zum gesamten Dokument dieser kleine Block gehört.

2. Retrieval-Phase:

• Das System findet über den Vektor den „kleinen Block“ (z. B. den Satz „Es senkte die Kosten“).

3. Generierungsphase (entscheidender Schritt):

• Das System gibt nicht diesen kleinen Block an das LLM.

• Stattdessen findet das System über die ID seinen „Elternteil“ (Parent Chunk) und übergibt den vollständigen 1000-Wörter-Absatz mit Kontext an das LLM.

Zusammenfassung:

• Keine semantische Segmentierung -> weil zu langsam, stattdessen überlappende Segmentierung (Sliding Window) zur Milderung von Grenzproblemen.

• Keine feine Granularität für die Generierung -> weil ohne Kontext unverständlich.

Der Trend geht also dahin: Mit extrem feiner Granularität „zielen“ (Index), mit extrem grober Granularität „lesen“ (Generierung). Und PageIndex ist im Grunde die ultimative Form dieser Logik: Mit Keywords zielen, mit dem gesamten Text lesen.

Das ist eine hervorragende Nachfrage. Die einfache Antwort lautet: Es hat das Problem der „Aufteilung“ und des „Kontexts“ nahezu perfekt gelöst, aber zugleich einen neuen, fatalen Mangel geschaffen.

No-Vector RAG (PageIndex) ist kein Allheilmittel, sondern eher eine Art „gegen den Strich gehende“ Ästhetik der rohen Gewalt.

Man kann es als einen Tausch verstehen: „Rechenleistung gegen Intelligenz.“

---

I. Welche Probleme löst es vollständig? (Gewinn)

No-Vector RAG gibt die „Vorverarbeitungsaufteilung“ auf und nutzt direkt die Fähigkeit von LLMs zu extrem langen Kontexten. Dadurch beseitigt es die zuvor genannten hartnäckigen Probleme an der Wurzel:

1. Die „Fragmentierung durch Chunks“ vollständig beseitigt (Solved: Fragmentation)

• Problem von Vector RAG: Der Text wird mitten im Zusammenhang geteilt, wodurch die Logik über mehrere Absätze hinweg verloren geht.
• Lösung von No-Vector RAG: Wenn man nicht weiß, wo man schneiden soll, schneidet man einfach überhaupt nicht.
  • Es übergibt dem LLM direkt die vollständige Seite oder sogar das vollständige Kapitel, die die Schlüsselwörter enthält.
  • Ergebnis: Probleme wie „unklare Pronomenbezüge“ und „Definitionen über mehrere Absätze hinweg“ verschwinden sofort. Da das LLM den zusammenhängenden Originaltext sieht, kann es selbst verstehen, worauf sich „es“ bezieht und welches Protokoll mit „dem oben erwähnten Protokoll“ gemeint ist.

2. Das Problem der „Präzision“ gelöst (Solved: Precision)

• Problem von Vector RAG: Bei der Suche nach „1024“ erscheint „1025“, und seltene Namen werden nicht gefunden.
• Lösung von No-Vector RAG: Rückkehr zum invertierten Index (Ctrl+F-Logik).
  • Ergebnis: Es werden nur Seiten gefunden, die zwingend das Wort „1024“ enthalten. Bei harten Kriterien wie Vertragsnummern, SKUs, Code-Fehlermeldungen und Namen steigt die Genauigkeit von 70 % auf 100 %.

3. Das Problem von „Blackbox und Wartung“ gelöst (Solved: Black Box)

• Problem von Vector RAG: Die Vektordatenbank ist eine Blackbox, und es ist schwer zu erkennen, warum ein bedeutungsloser Textabschnitt gefunden wurde.
• Lösung von No-Vector RAG: Die Logik ist transparent.
  • Ergebnis: Warum wurde diese Seite abgerufen? Weil sie diese drei Schlüsselwörter enthält. Wenn der Abruf falsch ist, liegt das Problem an der Strategie zur Schlüsselwortextraktion, die sich sehr leicht ändern lässt.

---

II. Welche neuen Probleme entstehen? (Verlust)

Alles hat seinen Preis. No-Vector RAG opfert tatsächlich „semantisches Verständnis“ zugunsten von „präzisem Kontext“. Dadurch entstehen zwei neue Problembereiche:

1. Der Verlust der „impliziten Bedeutung“ (Lost: Semantic Fuzziness)

Das ist die größte Schwäche von No-Vector RAG.

• Szenario: Der Benutzer sucht „Wie kann man Geld sparen?“, im Dokument steht jedoch „Durch die Optimierung von Prozessen Kosten senken“.
• Vector RAG: Findet es. Denn es weiß, dass „Geld sparen“ ≈ „Kosten senken“ bedeutet.
• No-Vector RAG: Findet es nicht. Denn die beiden Wörter „Geld sparen“ kommen im Dokument nicht vor.
  • Abhilfe: Vor der Suche muss ein LLM eine „Query Expansion (Suchanfrageerweiterung)“ durchführen und die Frage in mehrere Schlüsselwörter umformulieren („Geld sparen“ -> Kosten senken, Ausgaben reduzieren, Einsparungen erzielen). Das erhöht jedoch die Komplexität und die Latenz.

2. Rechen- und Geldverbrauch beim „Suchen einer Nadel im Heuhaufen“ (Cost & Latency)

• Vector RAG: Das LLM sieht nur 5 Fragmente (etwa 1000 Token). Günstig und schnell.
• No-Vector RAG: Das LLM bekommt möglicherweise 10 vollständige Seiten zu sehen (etwa 10.000 bis 20.000 Token).
  • Geld: Deine API-Rechnung kann sich um das 10- bis 20-Fache erhöhen.
  • Langsamkeit: Ob ein LLM 20.000 oder 1.000 Wörter liest, macht bei der Verzögerung bis zur Generierung des ersten Tokens (TTFT) einen erheblichen Unterschied.
  • Risiko des Verlorengehens (Lost in the Middle): Obwohl LLMs angeblich 200k Kontext unterstützen, zeigen Experimente, dass LLMs bei zu langem Kontext Informationen in der Mitte leicht übersehen und sich nur an Anfang und Ende erinnern.

---

III. Das endgültige Urteil: Worin liegt der eigentliche Vorteil?

Um das Wesentliche klarzumachen, verwenden wir den Vergleich einer „Open-Book-Prüfung“:

IV. Was ist derzeit die beste Vorgehensweise?

Niemand „ersetzt“ den anderen. Die derzeit leistungsfähigste Architektur ist Hybrid RAG (hybrides RAG), bei dem die jeweiligen Stärken kombiniert werden:

1. Abruf über zwei Wege:
   • Ein Weg verwendet Vector, um semantisch relevante Inhalte zu finden (und das Problem „Geld sparen“ vs. „Kosten“ zu lösen).
   • Der andere Weg verwendet Keyword, um präzise Übereinstimmungen zu finden (und das Problem mit Vertragsnummern zu lösen).
2. Neurangordnung (Rerank):
   • Die über beide Wege gefundenen Inhalte werden zusammengeführt und mit einem präzisen Modell bewertet, um die besten N Ergebnisse auszuwählen.
3. Generierung mit großem Fenster:
   • Unabhängig davon, auf welche Weise der Abruf erfolgt, sollte das „Kontextfenster“ möglichst groß gewählt werden (wurde beispielsweise ein bestimmter Abschnitt abgerufen, gibt man dem LLM zusätzlich die 2.000 Zeichen davor und danach), wobei aktuelle, günstige Langtextmodelle wie Gemini 1.5 Flash oder Claude Haiku zum Lesen eingesetzt werden.

Fazit:
No-Vector RAG löst die beiden schmerzhaftesten technischen Probleme von „fragmentiertem Kontext“ und „mangelnder Präzision“, ist aber in hohem Maße von den Langtextfähigkeiten des LLMs und der Größe deines Geldbeutels abhängig.

Möchtest du als Nächstes erfahren, wie die konkrete Architektur von „Hybrid RAG (hybridem RAG)“ aufgebaut wird? Oder möchtest du sehen, wie sich die Kosten von RAG mit langen Texten optimieren lassen?