Der Weg durchs LLM-Labyrinth:

Was ist RAG?

Mit dem RAG-Ansatz kann die Lücke zwischen den Large Language Modellen (LLM) und deren fehlenden Informationen zu eigenen und neuen Daten geschlossen werden. Die Idee dabei ist, zu einer gegebenen Anfrage die relevanten Informationen zu extrahieren (Data Retrieval) und diese als Teil des Prompts dem LLM mitzuschicken (Augmented Generation).

Für einen QA-Bot würde dies folgendermassen aussehen: Der Benutzer interagiert mit einer Applikation, welche basierend auf der Frage des Benutzers und dessen Chatverlauf eine semantische Suche in der eigenen Datenbank unternimmt. Mit den besten Treffern der Suche (Top-K Dokumente) als Kontext wird die Frage via LLM beantwortet. Für die semantische Suche wird meist eine Vektor-Suche und/oder eine Keywordsuche benutzt.

Inkubationsphase

In einem ersten Schritt gilt es die Anforderungen zu analysieren und mittels PoC den spezifischen RAG-Anwendungsfall auf seine Machbarkeit zu prüfen. Es ist wichtig zu verstehen, dass bei dem RAG-Pattern mehrere Komponenten für die Performance (Genauigkeit & Latenzzeit) verantwortlich sind. Um eine Benutzerfrage richtig zu beantworten, braucht es den relevanten Kontext mit den Informationen zur Beantwortung der Frage und die Fähigkeit, diese Kontextinformationen für die Antwort zu nutzen. Die RAG-Performance ist folglich durch die folgenden 3 Komponenten massgeblich beeinflusst:

1. Large Language Modell
2. Embedding Modell & semantische Suchmethode
3. Data Preprocessing & Chunking

In der Incubate Phase gilt es die drei Komponenten des RAG zu verstehen und auf seinen Anwendungsfall zu optimieren. Folgende Leitfragen sollten dementsprechend adressiert werden:

• Welche Sprachmodelle werden benutzt & mit welchem Tech Stack interagiere ich mit den Modellen?
• Wie implementiere ich die semantische Suche? Vektorsuche vs. Keyword-Suche? Und falls Vektorsuche, welche Embedding Modelle benutze ich?
• Welche Datenquellen sollen für das RAG genutzt werden und wie gestalte ich das Data Preprocessing und Chunking?

Im RAG benutzen wir ein Sprachmodell (LLM) für die Beantwortung der Frage. Neben dem Prompt-Engineering entscheidet hauptsächlich die Modellauswahl über die Performance und Kosten. Hier gibt es diverse Open Source- wie auch proprietäre Modelle unterschiedlicher Grössen, welche je nach Anwendungsfall besser geeignet sind.

Die Knacknuss im RAG-Pattern liegt jedoch im Data Retrieval. Wie können wir den relevanten Kontext zur Beantwortung der Frage aus Unmengen von eigenen Daten suchen und abrufen? Da wir den heutigen Sprachmodellen nur einen limitierten Input übergeben können, ist das Chunking von grossen Daten und die anschließende semantische Suche nach den relevanten Chunks essenziell. Das LLM funktioniert analog zu einem Menschen, der bei wenigen Sätzen sehr detaillierte Antworten liefern könnte, jedoch bei einem Artikel oder Buch die einzelnen Sätze nicht mehr wüsste. Zu verstehen, was die Aufteilung der Daten in Chunks für die Suche wie auch den gesamten Anwendungsfall zu bedeuten hat, ist zentral.

Data Chunking

Das Zerlegen eines Textdokumentes in kleinere Teile (Chunks) hat den Nachteil, dass Zusammenhänge und Beziehungen im Text verloren gehen. Beim RAG-Pattern werden nur die Top-K Chunks dem LLM im Prompt übergeben, weshalb das Sprachmodell Schwierigkeiten haben wird, Fragen, welche genau diese Zusammenhänge voraussetzen, zu beantworten. Folglich ist das RAG gut in eng gefassten, beschreibenden Fragen ohne grossen Zusammenhang. Beispiel: “Gibt es einen Mitarbeiter mit Java-Kenntnissen?". Bei Fragen über Zusammenhänge, langfristige Zusammenfassungen oder Fragen mit Vollständigkeitsanspruch wie “Kannst du mir eine Liste mit allen Mitarbeitern, welche mind. 3 Jahre C#-Kenntnisse haben, erstellen?” hat das RAG-Pattern Mühe.

Auf der anderen Seite kann man Chunks nicht beliebig gross erstellen. Das Embedding Modell reduziert den Inputtext auf einen Vektor, welcher die semantischen Eigenschaften bestmöglich erhalten soll, jedoch durch die reduzierte Dimension Informationen verliert. Embedding Modelle sind weniger effektiv bei Texten mit vielen Themen oder mehreren Wendungen, weshalb kürzere Chunks im RAG besser abschneiden.

Ein wichtiger Parameter beim “Fine tuning” des RAG-Pattern ist folglich die Chunkgrösse. Bei einer Analyse von MSFT schnitt eine Grösse von 521 Input Tokens pro Vektor am besten ab.

Neben der Grösse gibt es diverse Strategien, welche die Performance verbessern können. Zum Beispiel kann man den Text in überlappende Chunks einteilen, um das Risiko, Zusammenhänge aufzubrechen, zu reduzieren. Oder man implementiert eine Strategie für Metadaten, welche in der semantischen Suche neben der Vektor-Ähnlichkeit benutzt wird.

Für gewisse Anwendungsfälle lohnt es sich, ein Preprocessing einzelner Daten zu machen. So kann zum Beispiel bei einem Competence Profile jedes Projekt einen Chunk darstellen, welchen man mit den Informationen des Mitarbeiters ergänzt. So kann man den Zusammenhang des Projektes und des Mitarbeiters, der sonst verloren ging, wiederherstellen. Ein weiterer Ansatz wäre das Generieren einer Zusammenfassung des Textes vor und nach dem aktuellen Chunk, um den Kontext im Dokument nicht zu verlieren.

Wir empfehlen in der Incubate-Phase die Anwendungsfälle auf diverse Preprocessing und Chunking-Strategien zu prüfen, um schnell einen Einblick in die Mögliche Performance zu bekommen.

Production-Ready

In der Incubate-Phase konnten wir den Einsatz des Chatbots anhand eines funktionierenden Prototyps validieren. In der Production-Ready-Phase geht es darum, diesen Anwendungsfall so weiterzuentwickeln, dass alle PII oder sensiblen Daten (z.B. Patientendaten) unternehmenskonform verarbeitet und in der Produktion mit einem garantierten SLA betrieben werden können. Viele unserer Kunden suchen Antwort für folgende Fragen:

• Access Control: Wie stellen ich sicher, dass nur autorisierte Benutzer die relevanten Informationen erhalten?
• Verschlüsselung: Wie speichere ich Daten sicher und regelkonform in der Cloud?
• Operationalisierung: Wie halte ich die Daten fürs Retrieval up to date?

RBAC

Wir fokussieren uns hier auf das Thema Access Control und erklären mit einem Szenario, warum das eine Herausforderung ist. Viele Unternehmen realisieren mit LLM das Szenario “Company Brain”. Die erfolgreiche Umsetzung von diesem Case bedingt die Bereitstellung von unternehmensweiten Daten oder Dokumente mit unterschiedlichen Einstufungen. Schauen wir uns das am Beispiel eines Finanzinstituts an. Dieses verfügt zum Beispiel über Betriebshandbücher, die für alle Mitarbeiter verfügbar sind. Das sind interne Dokumente. Es gibt auch die PII-Daten wie z.B. Ausweise, Zertifikate und Verträge, die nur von autorisierten Kundenberatern und Legal Experten angesehen werden dürfen. Es gibt vielleicht streng vertrauliche Daten wie politische Orientierung, die nur von sehr eingeschränkten Kreisen mit Approval für einen definierten Zeitraum angesehen werden.

Die unterschiedlichen Daten mit entsprechenden Datenklassifizierungen bedeuten, dass eine Access Control-Schicht über die Datenpersistenzschicht (mit Embeddings) implementiert werden muss. Man sollte sich fragen, ob es sich lohnt, für die streng vertraulichen Daten eine eigene Datenverwaltung zu implementieren. Ausserdem muss man sich überlegen, wie man sehr flexible und feingranulare Zugriffsberechtigungen auf Dokumenten- oder Datensatzebene implementieren kann. Die meisten Dokumente sind in der Regel bereits mit entsprechenden Zugriffsebenen in bestehenden Systemen getaggt. Wie lassen sich diese Tags auf die Datenhaltung von LLM übertragen und synchronisieren?

Wir empfehlen, ein nachhaltiges Access Control Konzept zu entwerfen, bevor mit der Realisierungsphase begonnen wird.

Enterprise Scale

In diesem Abschnitt wollen wir uns mit den Challenges befassen, welche über einen eigenständigen Anwendungsfall hinausgehen und wie man die Kosten bei RAG-Anwendungsfällen im Griff hält.  Aus unserer Projekterfahrung mit Kunden haben sich folgende Fragen ergeben:

• Wie decke ich mehrere Anwendungsfälle mit einem virtuellen Agenten ab?
• Wie gestalte ich die Datenverwaltung in grossem Massstab? Und wie integriere ich die Lösung in meine existierende Enterprise-Landschaft?
• Wie behalte ich die Kosten im Griff? Welche Methoden gibt es, die Kosten zu reduzieren?

FinOps

Gerade der letzte Punkt beschäftigt viele Kunden. Die neuen Möglichkeiten mit Generative AI kommen nicht ohne Kosten. Es ist wichtig, diese mit FinOps Methoden im Griff zu behalten und in Relation zum Business Value zu setzen. Deshalb muss man die verschiedenen Komponenten im RAG Pattern genau verstehen und die optimale Lösung für den jeweiligen Anwendungsfall nutzen. Die Modellauswahl ist sicherlich die offensichtlichste Entscheidung. Hier kann man zum Beispiel zwischen Open Source und proprietären Modellen entscheiden. Ein Blog dazu folgt. Ein weiterer Punkt ist das Modell selbst. So performt z.B. GPT-4 besser als GPT-3.5 Turbo, jedoch rechtfertigen sich für einen simplen RAG Anwendungsfall die 10x höheren Kosten meist nicht.

Ein weiterer Punkt ist der Embedding Prozess. Dieser kostet bei proprietären Modellen verglichen zu LLM Modellen deutlich weniger. Jedoch könnte sich hier bei vielen Daten ein lokales Open Source Modell lohnen. Weiter sollte man sich eine Update Strategie erarbeiten und nur neue und veränderte Daten möglichst in Batch-Jobs embedden. Auf der anderen Seite kann das Data Retrieval durch die Applikation und Caching optimiert werden. So sollte der Agent auf die Eingabe “Hallo, wie gehts?” vermutlich direkt antworten und den Retrieval Prozess auslassen. Caching gestaltet sich schwieriger, jedoch gibt es bereits Ansätze wie GPTCache, welche durch semantische Suche die Frage gegen bereits gestellte Fragen vergleicht und bei einem Match den gespeicherten Kontext zurückliefert.

Neben der Modellauswahl und diversen Caching Strategien gilt es meist zwischen der benötigten Genauigkeit (Accuracy) und Antwortzeit (Latency) zu optimieren. So kann eine LLM-Chain oder LLM-Agent diverse Zwischenschritte durchführen, was die Genauigkeit der Antwort erhöht. Jedoch werden durch die zusätzlichen Modell Interaktionen die Kosten hochgehen und die Antwortzeit verlängert. Hier gilt es, den eigenen Anwendungsfall zu analysieren und die gewonnene Genauigkeit durch Mehrfach-Interaktion mit dem LLM  in Relation zu den Kosten und Antwortzeit zu setzen.

Multi Agent

Wie kann ich eine einfache RAG-Lösung mit neuen oder spezifischen Anwendungsfällen erweitern? Das Stichwort heisst “Multi Agent”, bei welchem wir verschiedene Lösungen in einem einzelnen Interface dem Benutzer anbieten können. Die Idee dabei ist, dass wir einen Agenten als Router oder Dispatcher verwenden. Dieser interagiert mit dem Benutzer, hat dessen Chatverlauf und entscheidet jeweils, welches Tool er für die Beantwortung der Anfrage einsetzen muss. Ein Tool kann dabei etwas Simples wie ein “Google Search” sein, eine eigene RAG Chain oder einen weiteren Agenten, welcher spezifische Anwendungsfälle handhaben kann. 

Fazit

In diesem Blog beleuchten wir eingehend die vielfältigen Herausforderungen, die typischerweise bei der Implementierung von Large Language Model (LLM) Projekten mittels Retriever-And-Generator (RAG) Musters auftreten. Wir sind der Meinung, dass eine erfolgreiche Umsetzung eines LLM-Projekts ein breitgefächertes, interdisziplinäres Verständnis in Schlüsselbereichen wie Data Engineering (z.B. Chunking), IT-Sicherheit (z.B. Access Control) und Cloud-Technologien (z.B. FinOps) erfordert. Im nächsten Blog planen wir, eine tiefere Einsicht zu geben, wie diese spezifischen Herausforderungen angegangen werden können. Stay tuned.