Sechs Lektionen zum Aufbau von RAG-Systemen in der Produktion

Innerhalb weniger Jahre hat sich RAG zu einer Artwork Glaubwürdigkeitssignal im KI-Bereich entwickelt. Wenn ein Unternehmen gegenüber Investoren, Kunden oder sogar der eigenen Führung einen seriösen Eindruck machen möchte, wird nun erwartet, dass es eine Retrieval-Augmented Era-Story parat hat. LLMs veränderten die Landschaft quick über Nacht und drängten generative KI in quick jedes Geschäftsgespräch.

Aber in der Praxis gilt: Der Aufbau eines schlechten RAG-Techniques ist schlimmer als gar kein RAG.

Ich habe gesehen, dass sich dieses Muster immer wieder wiederholt. Etwas wird schnell versendet, die Demo sieht intestine aus, die Führung ist zufrieden. Dann beginnen echte Benutzer, echte Fragen zu stellen. Die Antworten sind vage. Manchmal falsch. Gelegentlich selbstbewusst und völlig unsinnig. Das ist normalerweise das Ende. Das Vertrauen verschwindet schnell, und wenn Benutzer entscheiden, dass einem System nicht vertraut werden kann, prüfen sie nicht ständig, ob es sich verbessert hat, und geben ihm keine zweite Probability. Sie hören einfach auf, es zu benutzen.

In diesem Fall ist das eigentliche Versagen nicht technischer Natur, sondern menschlicher Natur. Die Leute tolerieren langsame Instruments und unhandliche Schnittstellen. Was sie nicht tolerieren, ist, in die Irre geführt zu werden. Wenn ein System Ihnen voller Zuversicht die falsche Antwort gibt, fühlt es sich täuschend an. Es ist extrem schwer, sich davon zu erholen, selbst nach monatelanger Arbeit.

Schon wenige falsche Antworten reichen aus, um Benutzer wieder zur manuellen Suche zu verleiten. Bis das System endlich wirklich zuverlässig wird, ist der Schaden bereits angerichtet und niemand möchte es mehr verwenden.

In diesem Artikel teile ich sechs Lektionen, die ich gerne gewusst hätte, bevor ich RAG-Projekte für Kunden bereitgestellt habe.

1. Beginnen Sie mit einem echten Geschäftsproblem

Wichtige RAG-Entscheidungen werden lange vor dem Schreiben von Code getroffen.

• Warum starten Sie dieses Projekt? Das zu lösende Drawback muss wirklich identifiziert werden. Es zu tun, „weil alle anderen es tun“, ist keine Strategie.

• Dann ist da noch die Frage der Kapitalrendite, die jeder vermeidet. Wie viel Zeit wird dadurch tatsächlich in konkreten Arbeitsabläufen gespart, und zwar nicht nur auf der Grundlage abstrakter, in Folien präsentierter Metriken?

• Und schließlich der Anwendungsfall. Hier scheitern die meisten RAG-Projekte stillschweigend. „Interne Fragen beantworten“ ist kein Anwendungsfall. Hilft es der Personalabteilung, auf Richtlinienfragen ohne endloses Hin und Her zu reagieren? Bietet es Entwicklern beim Codieren sofortigen und genauen Zugriff auf die interne Dokumentation? Handelt es sich um einen eng begrenzten Onboarding-Assistenten für die ersten 30 Tage einer neuen Einstellung? Ein starkes RAG-System leistet eine Sache intestine.

RAG kann mächtig sein. Es kann Zeit sparen, Reibungsverluste reduzieren und die Arbeitsweise von Groups wirklich verbessern. Aber nur, wenn es als echte Infrastruktur und nicht als Trendexperiment behandelt wird.

Die Regel ist einfach: Verfolgen Sie keine Tendencies. Wert umsetzen.

Wenn dieser Wert nicht eindeutig in Zeitersparnis, Effizienzsteigerung oder Kostensenkung gemessen werden kann, sollte das Projekt wahrscheinlich überhaupt nicht existieren.

2. Die Datenvorbereitung wird mehr Zeit in Anspruch nehmen, als Sie erwarten

Viele Groups beschleunigen ihre RAG-Entwicklung, und um ehrlich zu sein, kann ein einfacher MVP sehr schnell erreicht werden, wenn wir uns nicht auf die Leistung konzentrieren. Aber RAG ist kein schneller Prototyp; Es ist ein riesiges Infrastrukturprojekt. Sobald Sie beginnen, Ihr System mit realen, sich entwickelnden Daten in der Produktion zu belasten, werden die Schwachstellen in Ihrer Pipeline sichtbar.

Angesichts der jüngsten Beliebtheit von LLMs mit großen Kontextfenstern, die manchmal Millionen betragen, erklären einige Modelle mit langem Kontext, dass der Abruf non-obligatory ist, und Groups versuchen, den Abrufschritt einfach zu umgehen. Aber soweit ich diese Architektur viele Male implementiert habe, sind große Kontextfenster in LLMs tremendous nützlich, aber sie sind kein Ersatz für eine gute RAG-Lösung. Wenn man die Komplexität, Latenz und Kosten der Weitergabe eines riesigen Kontextfensters mit dem Abrufen nur der relevantesten Snippets vergleicht, bleibt ein ausgereiftes RAG-System erforderlich.

Doch was macht ein „gutes“ Retrieval-System aus? Natürlich Ihre Daten und deren Qualität. Das klassische Prinzip „Rubbish In, Rubbish Out“ gilt hier genauso wie beim traditionellen maschinellen Lernen. Wenn Ihre Quelldaten nicht sorgfältig vorbereitet sind, wird Ihr gesamtes System Probleme haben. Es spielt keine Rolle, welches LLM Sie verwenden; Ihre Abrufqualität ist die wichtigste Komponente.

Zu oft übertragen Groups Rohdaten direkt in ihre Vektordatenbank (VectorDB). Es wird schnell zu einer Sandbox, in der der einzige Abrufmechanismus eine auf Kosinusähnlichkeit basierende Anwendung ist. Auch wenn es Ihre schnellen internen Assessments besteht, wird es unter realem Druck mit ziemlicher Sicherheit scheitern.

In ausgereiften RAG-Systemen verfügt die Datenaufbereitung über eine eigene Pipeline mit Assessments und Versionierungsschritten. Das bedeutet, dass Sie Ihren Eingabekorpus bereinigen und vorverarbeiten müssen. Kein noch so cleveres Chunking oder eine ausgefallene Architektur kann grundsätzlich fehlerhafte Daten reparieren.

3. Beim effektiven Chunking geht es darum, Ideen intakt zu halten

Wenn wir über Datenaufbereitung sprechen, sprechen wir nicht nur über saubere Daten; Wir sprechen über einen sinnvollen Kontext. Das bringt uns zum Chunking.

Unter Chunking versteht man das Zerlegen eines Quelldokuments, etwa einer PDF-Datei oder eines internen Dokuments, in kleinere Stücke, bevor es in Vektorform kodiert und in einer Datenbank gespeichert wird.

Warum ist Chunking nötig? LLMs verfügen über eine begrenzte Anzahl von Tokens, und selbst „LLMs mit langem Kontext“ werden teuer und werden durch zu viel Lärm abgelenkt. Der Kern des Chunking besteht darin, das relevanteste Informationsbit auszuwählen, das die Frage des Benutzers beantwortet, und nur dieses Bit an das LLM zu übertragen.

Die meisten Entwicklungsteams teilen Dokumente mithilfe einfacher Techniken auf: Token-Limits, Zeichenanzahl oder grobe Absätze. Diese Methoden sind sehr schnell, aber normalerweise beginnt der Abruf an diesem Punkt nachzulassen.

Wenn wir einen Textual content ohne intelligente Regeln aufteilen, werden daraus Fragmente und nicht ganze Konzepte. Das Ergebnis sind Teile, die langsam auseinanderdriften und unzuverlässig werden. Es ist gefährlich, eine naive Chunking-Strategie aus der veröffentlichten Architektur eines anderen Unternehmens zu kopieren, ohne die eigene Datenstruktur zu verstehen.

Die besten RAG-Systeme, die ich je gesehen habe, enthalten Semantic Chunking.

In der Praxis bedeutet Semantic Chunking, Textual content in sinnvolle Teile aufzuteilen, nicht nur in zufällige Größen. Die Idee besteht darin, jedes Stück auf einen vollständigen Gedanken zu konzentrieren. Das Ziel besteht darin, sicherzustellen, dass jeder Teil eine einzige vollständige Idee darstellt.

• So implementieren Sie es: Sie können dies mithilfe von Techniken wie den folgenden implementieren: Rekursive Aufteilung: Aufteilen von Textual content basierend auf strukturellen Trennzeichen (z. B. Abschnitte, Überschriften, dann Absätze, dann Sätze).
• Satztransformatoren: Hierbei wird ein leichtes und kompaktes Modell verwendet, um alle wichtigen Übergänge anhand semantischer Regeln zu identifizieren und den Textual content an diesen Stellen zu segmentieren.

Um robustere Techniken zu implementieren, können Sie Open-Supply-Bibliotheken wie die verschiedenen Textsegmentierungsmodule von LangChain (insbesondere ihre erweiterten rekursiven Module) und Forschungsartikel zur Themensegmentierung konsultieren.

4. Ihre Daten werden veraltet sein

Die Liste der Probleme endet hier nicht, sobald Sie gestartet sind. Was passiert, wenn sich Ihre Quelldaten weiterentwickeln? Veraltete Einbettungen zerstören RAG-Systeme mit der Zeit langsam.

Dies geschieht, wenn sich das zugrunde liegende Wissen in Ihrem Dokumentenkorpus ändert (neue Richtlinien, aktualisierte Fakten, umstrukturierte Dokumentation), die Vektoren in Ihrer Datenbank jedoch nie aktualisiert werden.

Wenn Ihre Einbettungen schwach sind, halluziniert Ihr Modell im Wesentlichen eher von historischen Aufzeichnungen als von aktuellen Fakten.

Warum ist die Aktualisierung einer VectorDB technisch anspruchsvoll? Vektordatenbanken unterscheiden sich stark von herkömmlichen SQL-Datenbanken. Jedes Mal, wenn Sie ein einzelnes Dokument aktualisieren, ändern Sie nicht einfach ein paar Felder, sondern müssen möglicherweise das gesamte Dokument neu aufteilen, neue große Vektoren erstellen und dann die alten vollständig ersetzen oder löschen. Dies ist ein rechenintensiver Vorgang, der sehr zeitaufwändig ist und bei unsachgemäßer Behandlung leicht zu Ausfallzeiten oder Inkonsistenzen führen kann. Groups überspringen dies oft, weil der technische Aufwand nicht trivial ist.

Wann muss der Korpus neu eingebettet werden? Es gibt keine Faustregel; Das Testen ist Ihr einziger Leitfaden während dieser POC-Part. Warten Sie nicht auf eine bestimmte Anzahl von Änderungen in Ihren Daten; Der beste Ansatz besteht darin, Ihr System automatisch erneut einzubetten, beispielsweise nach der Veröffentlichung einer Hauptversion Ihrer internen Regeln (wenn Sie ein HR-System aufbauen). Sie müssen auch eine erneute Einbettung durchführen, wenn sich die Area selbst erheblich ändert (z. B. im Falle einer größeren regulatorischen Änderung).

Das Einbetten der Versionierung oder das Nachverfolgen, welche Dokumente mit welcher Ausführung zum Generieren eines Vektors verknüpft sind, ist eine bewährte Vorgehensweise. Dieser Raum braucht progressive Ideen; Die Migration in VectorDB wird von vielen Groups oft verpasst.

5. Ohne Bewertung treten Fehler nur auf, wenn sich Benutzer beschweren

Bei der RAG-Bewertung wird gemessen, wie intestine Ihre RAG-Anwendung tatsächlich funktioniert. Die Idee besteht darin, zu überprüfen, ob Ihr von RAG unterstützter Wissensassistent genaue, hilfreiche und fundierte Antworten gibt. Oder einfacher: Funktioniert es tatsächlich für Ihren tatsächlichen Anwendungsfall?
Die Bewertung eines RAG-Techniques unterscheidet sich von der Bewertung eines klassischen LLM. Ihr System muss reale Abfragen verarbeiten, die Sie nicht vollständig vorhersehen können. Sie möchten verstehen, ob das System die richtigen Informationen abruft und richtig antwortet.
Ein RAG-System besteht aus mehreren Komponenten, angefangen bei der Artwork und Weise, wie Sie Ihre Dokumente aufteilen und speichern, bis hin zu Einbettungen, Abruf, Eingabeaufforderungsformat und der LLM-Model.
Aus diesem Grund sollte auch die RAG-Bewertung mehrstufig erfolgen. Die besten Bewertungen umfassen Metriken für jeden Teil des Techniques separat sowie Geschäftsmetriken, um zu bewerten, wie das gesamte System durchgängig funktioniert.

Während diese Bewertung normalerweise während der Entwicklung beginnt, benötigen Sie sie in jeder Part des KI-Produktlebenszyklus.

Eine strenge Bewertung verwandelt RAG von einem Proof of Idea in ein messbares technisches Projekt.

6. Trendige Architekturen passen selten zu Ihrem Drawback

Architekturentscheidungen werden häufig aus Blogbeiträgen oder Konferenzen importiert, ohne jemals zu fragen, ob sie den internen spezifischen Anforderungen entsprechen.

Für diejenigen, die mit RAG nicht vertraut sind: Es gibt viele RAG-Architekturen, angefangen bei einem einfachen monolithischen RAG-System bis hin zur Skalierung bis hin zu komplexen, Agenten-Workflows.

Sie benötigen kein kompliziertes Agentic RAG, damit Ihr System intestine funktioniert. Tatsächlich lassen sich die meisten Geschäftsprobleme am besten mit einer Primary-RAG- oder einer Two-Step-RAG-Architektur lösen. Ich weiß, dass die Wörter „Agent“ und „Agent“ derzeit beliebt sind, aber bitte geben Sie dem umgesetzten Wert Vorrang vor den umgesetzten Tendencies.

• Monolithisches (einfaches) RAG: Beginnen Sie hier. Wenn die Anfragen Ihrer Benutzer unkompliziert und sich wiederholend sind („Wie lauten die Urlaubsbestimmungen?“), ist eine einfache RAG-Pipeline zum Abrufen und Generieren alles, was Sie benötigen.
• Zweistufiges Umschreiben von Abfragen: Verwenden Sie dies, wenn die Eingabe des Benutzers indirekt oder mehrdeutig sein könnte. Der erste LLM-Schritt schreibt die mehrdeutige Eingabe des Benutzers in eine sauberere, bessere Suchabfrage für die VectorDB um.
• Agentischer RAG: Berücksichtigen Sie dies nur, wenn der Anwendungsfall komplexe Überlegungen, die Ausführung von Arbeitsabläufen oder die Verwendung von Instruments erfordert (z. B. „Suchen Sie die Richtlinie, fassen Sie sie zusammen und verfassen Sie dann eine E-Mail an die Personalabteilung mit der Bitte um Klarstellung“).

RAG-Systeme sind eine faszinierende Architektur, die in letzter Zeit massiv an Bedeutung gewonnen hat. Während einige behaupten „RAG ist tot“, glaube ich, dass diese Skepsis einfach ein natürlicher Teil einer Ära ist, in der sich die Technologie unglaublich schnell weiterentwickelt.

Wenn Ihr Anwendungsfall klar ist und Sie einen bestimmten Problempunkt im Zusammenhang mit großen Dokumentendatenmengen lösen möchten, bleibt RAG eine äußerst effektive Architektur. Der Schlüssel liegt darin, es einfach zu halten und den Benutzer von Anfang an einzubeziehen.

Vergessen Sie nicht, dass der Aufbau eines RAG-Techniques ein komplexes Unterfangen ist, das eine Mischung aus maschinellem Lernen, MLOps, Bereitstellung und Infrastrukturkenntnissen erfordert. Sie müssen die Reise unbedingt mit allen Beteiligten beginnen – vom Entwickler bis zum Endbenutzer – vom ersten Tag an.

🤝 Bleiben Sie in Verbindung

Wenn Ihnen dieser Artikel gefallen hat, folgen Sie mir gerne auf LinkedIn, um weitere ehrliche Einblicke in KI, Information Science und Karrieren zu erhalten.

👉 LinkedIn: Sabrine Bendimerad

👉 Medium: https://medium.com/@sabrine.bendimerad1

👉 Instagram: https://tinyurl.com/datailearn