Wenn Ähnlichkeit nicht relevant ist: Aufbau von Enterprise RAG jenseits der Vektorsuche.

Die Vektorsuche ist außergewöhnlich gut darin, Texte zutage zu fördern, die einer Frage ähneln. Ähnlichkeit und Nützlichkeit sind jedoch unterschiedliche Dinge, und genau in diesem Unterschied liegt oft das Problem bei unternehmensweiten RAG-Lösungen.

Ein abgerufenes Dokument kann zwar das Vokabular des Benutzers teilen, dennoch veraltet, unzugänglich, unvollständig oder für die jeweilige Geschäftssituation irrelevant sein. Gleichzeitig könnte das Dokument, das die Frage tatsächlich beantworten könnte, anders formuliert sein und daher eine niedrigere Bewertung erhalten. Der Fehler liegt in der Regel weder im Embedding-Modell noch in der Vektordatenbank. Er resultiert aus der Annahme, dass semantische Ähnlichkeit eine vollständige Definition der Relevanz darstellt – was jedoch nicht der Fall ist.

In einem Unternehmen hängt die Relevanz von weitaus mehr ab als nur von der Formulierung. Aktualität, Autorität, Geografie, Dokumenttyp, Benutzerrechte, Workflow-Zustand, vertragliche Verbindungen sowie Beziehungen zwischen Geschäftseinheiten spielen alle eine Rolle. Ein zuverlässiges System muss diese Anzeichen miteinander abwägen und die Nähe im Vektorraum nicht als endgültiges Urteil betrachten.

Wie die Vektorsuche zur Standardmethode wurde

Die Schlüsselwortsuche stützt sich stark auf genaue Begriffe. Jemand, der nach „employee departure policy“ sucht, könnte eine Datei mit dem Titel „Workforce Offboarding Procedure“ übersehen, weil die beiden Begriffe keine gemeinsamen Wörter enthalten.

Die Vektorsuche war die Lösung für diese Schwäche. Dokumente werden in Embeddings umgewandelt, numerische Repräsentationen ihrer Bedeutung, und die Frage des Benutzers wird in einen ähnlichen Vektor umgewandelt. Das System gibt anschließend die Abschnitte zurück, deren Vektoren am nächsten an denen der Abfrage liegen. Konzeptionell verwandtes Material kann gefunden werden, selbst wenn die Frage und die Quelle unterschiedliche Formulierungen verwenden.

Deshalb eignet sich die Vektorabrufung hervorragend für verschiedene Aufgaben: die Verarbeitung von Fragen in natürlicher Sprache, das Abgleichen von Synonymen und Paraphrasen, die Suche in unstrukturierten Dokumenten, die Unterstützung von konversationalen oder mehrsprachigen Abfragen sowie die Reduzierung einer großen Sammlung auf eine kurze Liste potenzieller Ergebnisse.

Diese Vorteile brachten Vektordatenbanken in den Mittelpunkt früher RAG-Designs, und der Standardprozess schien übersichtlich zu sein. Dokumente wurden in Blöcke aufgeteilt, jeder Block erhielt eine Embedding-Darstellung, und die Vektoren wurden gespeichert. Bei der Abfrage wurde die Frage ebenfalls in einen Vektor umgewandelt, die nächstgelegenen Blöcke abgerufen und an ein Sprachmodell übergeben, welches anschließend die Antwort erstellte.

Demos sowie kleine Wissensbasen funktionieren mit diesem Ansatz einwandfrei. In Unternehmensumgebungen zeigt sich jedoch bereits nach kurzer Zeit eine Belastung.

Ähnlichkeit ist nur ein von mehreren Signalen

Stellen Sie sich vor, ein Einkaufsmanager tippt: „Welche Zahlungsbedingungen gelten nach unserem aktuellen Vertrag mit Northstar Components?“

Ein rein vektorbasiertes System könnte mit einem aktuellen Liefervertrag, einem abgelaufenen Vertrag mit demselben Lieferanten, einem Vorlagedokument mit Standardzahlungsbedingungen, einer E-Mail zu einem vorgeschlagenen Änderungsvorschlag, einer Beschaffungspolitik, die Zahlungen an Lieferanten erwähnt, sowie einem Vertrag für eine andere Northstar-Tochtergesellschaft auftauchen.

Jedes dieser Elemente steht semantisch in engem Zusammenhang mit der Frage, doch vielleicht sind nur ein oder zwei für die praktische Anwendung relevant. Die richtige Auswahl bedeutet, weitere Fragen zu beantworten: Auf welche Rechtspersönlichkeit bezieht sich „unsere“ Angabe? Welche Northstar-Firma ist beteiligt? Ist der Vertrag noch in Kraft, und haben Änderungen die ursprünglichen Bedingungen geändert? Welches Rechtsgebiet gilt dafür? Hat dieser Benutzer Zugriff darauf? Gibt es eine unterschriebene Version, und welche Quelle hat die höchste Autorität?

Eine Embedding-Struktur verfügt nicht über ein eingebautes Verständnis für solche Einschränkungen. Sie misst die Nähe in einem gelernten semantischen Raum und kann nicht feststellen, welches Dokument rechtlich bindend oder operationell gültig ist.

So führt ein hoher Ähnlichkeitswert zu falschem Vertrauen. Das System liefert plausiblen Text, das Sprachmodell wandelt ihn in eine glatt formulierte Antwort um, und der fließende Stil verdeckt den Fehler bei der Informationsbeschaffung.

Sieben Arten, wie reine Ähnlichkeitsbetrachtung versagt

Mehrere wiederkehrende Fehlermuster machen eine reine Vektor-basierte Informationsbeschaffung riskant.

Veraltete Materialien. Alte Dokumente sehen oft genauso aus wie aktuelle. Eine abgelaufene Richtlinie kann bis auf einen einzigen Schwellenwert, ein Datum oder eine Genehmigungsregel der Ersatzrichtlinie entsprechen. Aufgrund der vielen gemeinsamen Formulierungen erzielen beide eine hohe Bewertung. Ohne Kontrollen bezüglich Version und Gültigkeitsdatum kann das System schließlich veraltete Leitlinien anbieten, was insbesondere in regulierten Bereichen gefährlich ist, wo eine kleine Änderung in der Richtlinie die Konformität, die Berichterstattung oder die Behandlung der Kunden beeinflussen kann.

Blindheit gegenüber der Autorität. Eine Brainstorming-Notiz, ein interner E-Mail-Verkehr und eine genehmigte Richtlinie können sich auf ein und dasselbe Thema beziehen, wobei die informelle Variante einfach deshalb Vorrang haben kann, weil ihre Formulierung der Frage ähnelt. Unternehmenswissen funktioniert nicht nach demokratischen Prinzipien. Ein unterschriebener Vertrag sollte grundsätzlich Vorrang vor einem Entwurf haben, eine genehmigte Verfahrensanweisung vor einer Sitzungsprotokollkopie und eine geprüfte regulatorische Einreichung vor den Notizen eines Analysten. Für die Relevanz ist eine Hierarchie der Beweise erforderlich.

Beziehungen durch Aufteilung in Teile getrennt. Um die Genauigkeit zu erhöhen und die Kontextfenster zu berücksichtigen, teilen RAG-Systeme Dokumente in kleine Abschnitte auf, wodurch Fakten von den Beziehungen getrennt werden können, die ihnen Bedeutung verleihen. Ein Abschnitt kann eine Zahlungspflicht definieren, ein anderer den Lieferanten nennen, und ein dritter enthält eine Änderung, die die ursprüngliche Klausel außer Kraft setzt. Jeder Abschnitt ist für sich genommen unvollständig, und das Herunterladen des am ähnlichstenen Abschnitts garantiert nicht, dass das vollständige Bild wiederhergestellt wird.

Probleme mit präzisen Identifikatoren. Embeddings sind auf Bedeutung optimiert und repräsentieren oft literale Zeichenketten ungenau. Typische Opfer sind Teilenummern, Kontonummern, Verweisnummern auf Klauseln, Arzneimittelcodes, Geräteidentifikatoren sowie Versionen. Eine Suche nach „Model AX-1047“ sollte nicht „AX-1041“ zurückgeben, nur weil die Beschreibungen dazu ähnlich sind. Bei geschäftlichen Suchvorgängen ist häufig sowohl präzise Genauigkeit als auch semantische Übereinstimmung erforderlich.

Negative Einschränkungen. Oft wird gefragt, was fehlt: Welche Kunden haben die Überprüfung noch nicht abgeschlossen, welche Geräte fallen außerhalb des aktuellen Wartungsvertrags, welche Rechnungen sind nach 60 Tagen noch nicht bezahlt, welche Teststandorte haben die erforderlichen Unterlagen nicht eingereicht. Solche Fragen beziehen sich auf Abwesenheit, Ausschluss oder Vergleich zwischen Datensätzen. Eine Ähnlichkeitssuche liefert zwar Texte zum jeweiligen Konzept, kann aber nicht zuverlässig ermitteln, was fehlt.

Keine Vorstellung vom Geschäftsstatus. Ein Unternehmensobjekt durchläuft Zustände wie Entwurf, eingereicht, genehmigt, ausgesetzt, abgelaufen und archiviert. Zwei Dokumente über dasselbe Objekt können trotz unterschiedlicher Zustände fast identisch aussehen, und der aktuelle Zustand bestimmt, ob ein Dokument überhaupt relevant ist.

Autorisierung allein reicht nicht aus. Das semantisch am relevantesten Dokument könnte eines sein, das der Benutzer nicht sehen darf. Der Zugriffskontrollmechanismus darf nicht lediglich in einer Anweisung enthalten sein. Eingeschränkter Inhalt muss entfernt werden, bevor er in den Kontext des Modells gelangt, da sonst das Risiko besteht, dass sensible Details direkt durchsickern oder das Modell sie indirekt ableiten kann.

Relevanz hat viele Dimensionen

In Unternehmensumgebungen mit RAG sollte die Relevanz am besten als Mischung aus verschiedenen Signalen betrachtet werden: semantische Ähnlichkeit, Relevanz durch Schlüsselwörter oder exakte Übereinstimmungen, Autorität der Quelle, zeitliche Gültigkeit, Übereinstimmung mit Geschäftsregeln, Berechtigung zum Zugriff sowie Beziehungs- oder Graphrelevanz. Eine Ranking-Formel könnte diese Faktoren mit jeweils unterschiedlichem Gewicht zusammenfassen.

Die Gewichtung hängt vom Anwendungsfall ab. Ein interner Forschungsassistent kann der semantischen Ähnlichkeit ein hohes Gewicht beimessen. Ein Vertrags-Frage-Antwort-Tool legt möglicherweise mehr Wert auf Gültigkeitsdaten und Quellenautorität. Eine Ermittlungsplattform wird möglicherweise von den Beziehungen zwischen Personen, Ereignissen, Orten und Ressourcen dominiert.

Das bedeutet nicht, dass jede Organisation ein aufwendiges mathematisches Ranking-Modell benötigt. Es bedeutet vielmehr, dass die Relevanz bewusst definiert werden sollte und nicht aus der Standardbewertung einer Vektordatenbank übernommen werden darf.

Wie eine robustere Sucharchitektur aussieht

Ein zuverlässiges RAG durchläuft in der Regel mehrere Such- und Validierungsphasen.

1. Verständnis der Anfrage

Vor der Suche ermittelt das System, um was es geht. Das kann bedeuten, dass es die Absicht sowie alle benannten Entitäten, Zeitintervalle, Dokumenttypen, Rechtsgebiete, Kunden- oder Produktidentifikatoren, Geschäftseinheiten und das gewünschte Autorisierungslevel herausfiltert, um anschließend zu entscheiden, ob die Anfrage eine Suche, Berechnung, Vergleich oder Graphenabfrage erfordert.

Nehmen wir die Frage „Was hat sich in unserer europäischen Datenerhaltungspolitik in diesem Jahr geändert?“ Sie sollte nicht als generische semantische Suche behandelt werden. Sie beinhaltet eine Region, eine Dokumentkategorie, ein Zeitfenster sowie einen Vergleich von Versionen. Die Abfragedeutungskomponente wandelt einen unstrukturierten Satz in einen strukturierten Suchplan um.

2. Metadatenfilterung

Metadaten reduzieren den Suchraum vor oder während der Abfrage. Zu den nützlichen Feldern gehören Region, Eigentümer, Geschäftseinheit, die Datumsangaben für Inkrafttreten und Ablauf eines Dokuments, dessen Freigabestatus und Version, Dokumenttyp, Datenklassifizierung, Produktfamilie, Kunden- oder Lieferant-ID sowie die für die Zugriffskontrolle verwendeten Attribute.

Durch das Anwenden von Filtern werden eindeutig ungeeignete Kandidaten davon abgehalten, mit geeigneten zu konkurrieren. Zudem macht es die Qualität der Metadaten zu einem Bestandteil der RAG-Qualität: Wenn Dokumente ohne zuverlässige Datumsangaben, Eigentümerangaben, Versionsstatus oder Zugriffslabel eingeführt werden, bleibt die Abfrage unzuverlässig, unabhängig vom verwendeten Embedding-Modell.

3. Hybride Abfrage

Die hybride Suchmethode kombiniert semantische Suche mit lexikalischer Suche. Vektoren befassen sich mit Bedeutung und Paraphrasen, während lexikalische Methoden wie BM25 sich auf genaue Terminologie, Identifikatoren und seltene Begriffe konzentrieren. Ein hybrides System kann erkennen, dass „Beendigungsverfahren“ mit „Offboarding-Politik“ zusammenhängt, und dennoch auf eine exakte Übereinstimmung für „HR-OPS-204“ bestehen.

Die Ergebnisse können durch rekursive Rangfusion oder eine domain-spezifische Bewertungsfunktion zusammengeführt werden. Für viele Unternehmen gehört dies zu den praktischsten Verbesserungen gegenüber einem rein vektorbasierten Prozess.

4. Suche nach strukturierten Daten

Dokumentabschnitte sind für bestimmte Fragen die falsche Quelle. Alles, was mit Zählungen, Gesamtwerten, Schwellenwerten, Statusen oder Vergleichen zu tun hat, eignet sich in der Regel besser für SQL-Abfragen, Suchindizes, APIs, Datenlager, Wissensbasen, Master-Daten-Systeme oder Regelwerke.

Falls jemand fragt: „Wie viele offene Forderungen haben in diesem Quartal 500.000 ₹ überschritten?“, ist der richtige Ansatz, die strukturierte Quelle abzufragen, in der die Forderungsdaten gespeichert sind. Reine Beschreibungen der Forderungen können keine Zahlen liefern. Ein ausgereiftes Design leitet jede Frage an das geeignete Verfahren weiter.

5. Wissensgraphen und relationserkennende Suche

Manche Fragen beziehen sich im Grunde auf Beziehungen. Ein Wissensgraph kann Kunden, Lieferanten, Produkte, Verträge, Standorte, Vorfälle und Vorschriften sowie die Verbindungen zwischen ihnen modellieren.

Nehmen wir an, ein Risikoanalytiker möchte wissen, welche aktiven Lieferanten über die tatsächlichen Eigentümerbeziehungen mit sanktionierten Einheiten in Verbindung stehen. Wahrscheinlich enthält kein einzelner Absatz alle notwendigen Beweise. Um eine Antwort zu finden, muss man durch Lieferantendaten, Unternehmenseigentumsinformationen, Prüfergebnisse und Vertragsstatus weitergehen. Die Graphenextraktion kann das betroffene Netzwerk der Einheiten ermitteln, wobei die Vektorsuche anschließend unterstützende Passagen zu diesen Einheiten sowie die dabei entdeckten Verbindungen liefern kann.

Die Kombination dieser Methoden wird üblicherweise als GraphRAG bezeichnet, obwohl die Implementierungen variieren. Der Vorteil liegt nicht darin, dass Graphen fortschrittlicher sind als Vektoren, sondern darin, dass Graphen explizite Beziehungen bewahren, während Embeddings diese in statistische Nähe pressen.

6. Neubewertung

Die Erstansuchung sollte auf die Vollständigkeit der Ergebnisse ausgerichtet sein: Es sollten eine breite Auswahl möglicher relevanter Kandidaten gesammelt werden. Anschließend bewertet ein Neubewertungsmodell diese Kandidaten genauer im Vergleich zur vollständigen Abfrage. Kreuzkodierer, spezialisierte Ranking-Modelle oder auf großen Sprachmodellen basierende Bewertungstools können feststellen, ob ein Abschnitt tatsächlich die Frage beantwortet.

Zu berücksichtigende Signale umfassen den direkten Bezug des Abschnitts zur Frage, die Übereinstimmung mit Entitäten, Autorität, Aktualität, Vollständigkeit, Spezifität, Widersprüche sowie Geschäftsregeln. Ziel ist es, Abschnitte zu unterscheiden, die „zum Thema gehören“, von solchen, die „für diese Frage nützlich sind“.

7. Zusammenstellung des Kontexts

Das Übergeben der fünf wichtigsten Abschnitte an ein LLM ist keine Strategie zur Handhabung des Kontexts. Die Beweismittel müssen möglicherweise nach Dokumenten gruppiert, chronologisch geordnet, durch angrenzende Abschnitte erweitert, mit Definitionen oder Tabellen verknüpft, dupliziert entfernt, mit Änderungen zusammengeführt, zwischen Versionen verglichen, mit Kennzeichnungen für Quelle und Autorität versehen sowie komprimiert werden, wobei Ausnahmen beibehalten werden müssen.

Das Ziel ist es, die für das logische Denken erforderliche Struktur beizubehalten. Bei einer Vertragsklausel bedeutet das, ihre Definitionen, Ausnahmen sowie die Geschichte der Änderungen mitzunehmen. Ein klinischer Eingriff benötigt möglicherweise die dazugehörigen Warnhinweise. Ein finanzielles Ergebnis erfordert möglicherweise seinen Berichtszeitraum und die Buchführungsgrundlagen.

8. Überprüfung der Beweismittel

Vor der Erstellung einer endgültigen Antwort sollte das System überprüfen, ob die Beweise ausreichen. Unterstützen die Quellen die Antwort direkt und sind sie aktuell? Stimmen autoritative Quellen nicht überein? Fehlt ein notwendiges Dokument? Beruht die Antwort auf einer ungesicherten Schlussfolgerung? Kann der Benutzer tatsächlich jeden zitierten Abschnitt öffnen?

Wenn die Beweise unzureichend sind, könnte die sicherste Reaktion darin bestehen, dies zu erwähnen, um Klarstellung zu bitten oder das Problem weiterzuleiten. Enterprise RAG sollte so konzipiert sein, dass es abweist, anstatt nur Antworten zu geben.

Unternehmensregeln haben tatsächlichen Einfluss

Ein erheblicher Anteil der Abruffehler lässt sich durch bessere Embeddings niemals beheben, da die Relevanz durch die Organisation definiert wird. Typische Regeln: Wählen Sie die neueste genehmigte Richtlinie, es sei denn, eine regionale gilt; wenden Sie Vertragsänderungen in der Reihenfolge an, in der sie durchgeführt wurden; bevorzugen Sie geprüfte Finanzdaten gegenüber Managementschätzungen; lassen Sie Entwürfe von Regulierungsdokumenten aus; identifizieren Sie den Kunden anhand der Rechtsform und nicht des Handelsnamens; und geben Sie nur die Datensätze zurück, die zum vom Benutzer zugänglichen Gebiet gehören.

Diese Regeln gehören in den Code für das Abrufen, Ranking oder die Orchestrierung. Zu erwarten, dass ein LLM sie aus dem Kontext ableitet, ist unzuverlässig und lässt nichts zur Überprüfung übrig. Hier verwandelt sich enterprise RAG in eine Aufgabe des Systemsengineering statt in eine Frage der Auswahl eines Modells.

Bewertung jenseits der Antwortgenauigkeit

Ein System kann aus dem falschen Grund die richtige Antwort liefern, indem es schwache Beweise heranzieht und auf das vorherige Wissen des Modells setzt. Es kann auch bei Tests korrekt erscheinen, aber versagen, sobald sich die Dokumente ändern. Daher muss die Bewertung jede Ebene des Prozesses untersuchen.

Auswahl der Beweise. Überprüfen Sie, ob die notwendigen Beweise gefunden wurden: Recall@k, Precision@k, mittlerer umgekehrter Rang sowie normalisierter diskontierter kumulativer Gewinn – außerdem, wie oft exakte Identifikatoren gefunden werden und wie oft die Ergebnisse aktuell und zuverlässig sind.

Kontext. Überprüfen Sie, ob das zusammengestellte Material nutzbar ist: Vollständigkeit der Beweise, Redundanz, Anteil an Widersprüchen, Relevanz im Kontext, Beibehaltung von Tabellen- und Abschnittsbeziehungen sowie Konsistenz der Versionen.

Generierung. Überprüfen Sie die endgültige Antwort: Treue zu den Beweismitteln, Korrektheit der Zitierungen, Vollständigkeit, Häufigkeit ununtermaufter Behauptungen, angemessenes Ausbleiben von Aussagen sowie Einhaltung von Genehmigungen und Richtlinien.

Unternehmensergebnisse. Verfolgen Sie den operativen Wert: Eingesparte Stunden, Häufigkeit der Eskalation von Fällen, verbleibende Überprüfungsarbeiten, Schweregrad der Fehler, Geschwindigkeit der Problemlösung, ob die Nutzer das Tool vertrauen, Vorkommen von Compliance-Verstößen sowie das Ausmaß, in dem Workflows es nutzen. Bessere semantische Suchergebnisse nützen wenig, wenn abgelaufene Verträge oder unzugängliche Aufzeichnungen weiterhin auftauchen.

Fehler, die Teams machen, wenn sie auf die Vektor-Suche verzichten

Organisationen erkennen oft die Grenzen einer rein vektorbasierten RAG-Lösung und fügen dann Komplexität hinzu, ohne ein klares Modell für die Relevanz zu haben.

Ein Fehler besteht darin, alle Techniken auf einmal zu übernehmen. Ein Wissensgraph, ein Neurangier und ein agiler Arbeitsablauf werden fehlende Metadaten oder eine schlechte Dokumentverwaltung nicht beheben.

Ein weiterer Fehler ist es, das LLM zum universellen Schiedsrichter zu machen. Modelle eignen sich gut zur Interpretation von Anfragen und zur Rangfolgebestimmung von Beweismitteln, doch Regeln, die präzise sein müssen – wie Zugriffskontrollen, Datumsangaben und Entity-IDs – sollten in der Regel weiterhin aus deterministischem Code bestehen.

Ein dritter Fehler ist die Anpassung ausschließlich an Benchmark-Fragen. Reale Nutzer stellen oft vage, unvollständige Anfragen, die stark vom Kontext abhängen; daher benötigen Testdaten echte Randfälle, veraltete Dokumente, widersprüchliche Quellen sowie Zugriffsbeschränkungen.

Schließlich betrachten einige Teams die Informationsabrufung als Kauf einer Infrastruktur. Die Wahl einer Vektordatenbank ist nur eine von vielen Entscheidungen, denn die Relevanz hängt auch davon ab, wie Dokumente eingeholt und strukturiert werden, welche Metadaten hinzugefügt werden, wie Identitäten gelöst werden sowie wie Ranking, Orchestrierung und Verwaltung gehandhabt werden.

Ein praktischer Weg voran

Es ist nicht notwendig, die bestehende RAG-Plattform zu ersetzen, um die Relevanz zu verbessern. Sie kann schrittweise weiterentwickelt werden.

Beginnen Sie mit den fehlschlagenden Anfragen und klassifizieren Sie jeden Fehler beim Informationsabruf. Fehlte das richtige Beweismittel, wurde es zu niedrig rangiert, falsch gefiltert, in mehrere Teile aufgeteilt oder von einer veralteten Quelle überschattet?

Anschließend klären Sie, was Relevanz für den jeweiligen Arbeitsablauf bedeutet, indem Sie entscheiden, welche Quellen Autorität haben, welche Metadatenfelder relevant sind und welche Geschäftsregeln die Gültigkeit bestimmen.

Fügen Sie anschließend den einfachsten Mechanismus hinzu, der zu jedem Fehler passt. Genaue Identifikatoren erfordern eine lexikalische Suche. Daten, Regionen und Dokumenttypen erfordern Metadatenfilter. Ungenaue Beurteilungen von Abfragen und Dokumenten erfordern einen Neurankierer. Abschnitte ohne Kontext erfordern das Abrufen benachbarter Abschnitte. Analytische Fragen gehören zu strukturierten Datenbanken. Antworten, die von Beziehungen zwischen Entitäten abhängen, erfordern einen Graphenablauf. Berechtigungen sollten vor dem Abrufen deterministisch überprüft werden, und unvollständige Beweise sollten Regeln zur Zurückhaltung auslösen.

Zuletzt erstellen Sie eine Bewertungsmenge aus echten Benutzerfragen und echten Fehlern und testen Sie das Abrufen sowie die Erstellung getrennt voneinander, damit Verbesserungen in einem Bereich Probleme in einem anderen nicht verdecken.

Richtige Beweise statt ähnlicher Texte

Die Vektorsuche bleibt wertvoll und ist hervorragend darin, Passagen zu ähnlichen Themen zu finden. Was sie allein nicht leisten kann, ist die Entscheidung, welche Passage aktuell, autoritativ, zulässig, vollständig oder auf eine bestimmte Geschäftssituation anwendbar ist.

Es wird eine umfassendere Relevanzarchitektur benötigt, die semantische Suche mit exakter Übereinstimmungssuche, Metadaten, Geschäftsregeln, strukturierten Quellen, Graphenbeziehungen, Neubewertung sowie einer Überprüfung der Belege kombiniert.

Die nächste Welle an RAG-Systemen wird nicht dadurch gewonnen, dass mehr ähnlicher Text herangezogen wird. Die Gewinner werden den richtigen Beleg für den richtigen Benutzer, im richtigen Kontext und zum richtigen Zeitpunkt liefern.