Daten und Informationen liefern die Grundlage für fundierte Entscheidungen, effiziente Prozesse, Innovationen und ein personalisiertes Kundenerlebnis. Allerdings stehen wir bei Thalia – wie nahezu alle Unternehmen – vor der Herausforderung, dass Daten und Informationen über verschiedene Plattformen und Systeme verteilt sind und häufig in unstrukturierte Form vorliegen. Ob es sich um Dokumentationen in Confluence, Dateien in SharePoint oder andere interne Informationsquellen handelt – die wertvollen Informationen sind oft schwer zugänglich und nur umständlich zu integrieren. Heinrich von Pierer, ehemalige CEO von Siemens brachte dieses Phänomen mit dem Satz: „Wenn Siemens wüsste, was Siemens weiß …“ auf dem Punkt. Gleiches gilt auch bei Thalia. Die Frage ist also, wie können wir KI einsetzen, um unsere Daten- und Wissensschätze zu heben?
Eine mögliche Antwort auf diese Frage ist sog. Retrieval Augmented Generation (RAG)¹.

Was ist Retrieval-Augmented Generation (RAG)?

RAG ist eine Mischung aus zwei verschiedenen KI-Typen: Retrieval und Generierung. Retrieval-Modelle sind gut darin, relevante Informationen aus großen Datenbanken und Dokumentenmengen zu ziehen, während Generationsmodelle dafür sorgen, dass diese Infos in verständliche und sinnvolle Texte umgewandelt und so den Nutzer*innen präsentiert werden. Auf diese Weise können große Sprachmodelle – wie z.B. ChatGPT von OpenAI² oder Gemini von Google³ – Fragen zu internen Wissensquellen beantworten, ohne das die Modelle aufwändig auf dieses Wissen trainiert werden müssen.

Wie funktioniert RAG?

Speicherung von Wissen: Bevor die Anfrage einer Nutzer*in verarbeitet werden kann, muss das Wissen aus den Rohdaten der Wissensquellen extrahiert und in eine durch das RAG-System verarbeitbare Form gebracht und gespeichert werden.

Vorverarbeitung und Vektorisierung der Wissensquelle: In einem ersten Schritt werden die zu durchsuchenden Dokumente und Datenquellen in kleinere, verdauliche Stücke (Chunks) zerlegt⁴. Ein Chunk sollte sollte dabei einen logischen zusammenhängenden Textabschnitt repräsentieren. Der Chunk stellt sozusagen ein Buch zu einem bestimmten Thema dar, auf das das System später Antworten geben kann. Die Chunks werden anschließend durch ein sog. Embedding-Modell⁵ in Vektoren umgewandelt, die die semantische Bedeutung jedes Informationsstücks in einem mehrdimensionalen Raum darstellen. Dieser Schritt ist notwendig, damit das RAG-System in der Lage ist die zu einer Anfrage passenden Wissensschnippsel herauszusuchen. Die Vektorisierung erfolgt mithilfe von vortrainierten Sprachmodellen wie BERT⁶ oder anderen Embedding-basierten Methoden.

Speichern der Inhaltsvektoren: Die Vektoren der Chunks werden zusammen mit dem Chunk selbst und ggf. mit weiteren Meta-Daten in einer speziell optimierten Vektordatenbank⁷ gespeichert, um schnelle und präzise Abfragen zu unterstützen. Die Vektordatenbank stellt die Wissensbasis dar und man kann sie sich als großes Bücherregal vorstellen in dem die einzelnen Bücher (Text-Chunks) stehen und über einen Suchindex (Vektor) gefunden werden können.

Verarbeitung einer Anfrage: Ist das Wissen in Form von Chunks, Vektoren und Meta-Daten in der Vektordatenbank gespeichert, kann es genutzt werden, um Anfragen von Nutzer*innen zu beantworten. Der Prozess beginnt mit der Erfassung einer Anfrage. Diese kann von einer Nutzer*in kommen, die eine Frage stellt oder nach bestimmten Informationen sucht, indem sie mit einem Chatbot oder einer Sucheingabe interagiert. Die Anfrage wird in natürlicher Sprache gestellt und dient als Eingabe für das System.

Vorverarbeitung und Vektorisierung der Anfrage: Die eingehende Anfrage wird vorverarbeitet, um sicherzustellen, dass sie für die nachfolgenden Schritte geeignet ist. Dies kann die Bereinigung von Text, Tokenisierung⁸ und andere Natural Language Processing (NLP) Vorverabeitungen⁹ umfassen, um die Anfrage in eine für das KI-Modell verständliche Form zu bringen. Wie ein Bibliothekar filtert der das RAG-System die für die Bearbeitung relevanten Informationen heraus.
Die vorverarbeitete Anfrage wird – wie auch die Chunks unserer Wissensbasis – in einen Vektor umgewandelt. Dabei wird das gleiche Modell wie bei der Erzeugung der Wissensbasis verwendet, sodass sich Anfrage und Wissensbasis im gleichen Vektorraum befinden. Das ermöglicht dem RAG-System die Suche in der Vektordatenbank.

Abruf relevanten Wissens (Retrieval): Die Vektorreprksentation der Anfrage wird nun verwendet, um in der Vektordatenbank nach den relevantesten Informationsstücken zu suchen – wie ein Bibliothekar, der die Passenden Bücher heraussucht. Dazu wird auf ein Distanzmaß (z.B. die Cosine-Similarity¹⁰) zurückgegriffen. So wird es ermöglicht, die Chunks nach ihrer semantischen Ähnlichkeit mit der Anfrage zu sortieren und die relevantesten (ähnlichsten) Chunks schnell abzurufen. Die am höchsten bewerteten Chunks werden für den nächsten Schritt ausgewählt.

Anreicherung der Anfrage um Wissen der ähnlichsten Inhaltsvektoren: Die ursprüngliche Anfrage einer Nutzer*in wird nun um die gefunden Wissensschnippsel (Chunks) angereichert. Das LLM bekommt als das notwendige Wissen für die Beantwortung der Anfrage gleich mitgeliefert.

Formulierung einer passenden Antwort (Generation): Ein Generationsmodell (im Regelfall ein Large Language Model (LLM)¹¹), in unserem Fall ein in unserer Azure-Instanz gehostetes GPT-Modell, nutzt die ausgewählten Chunks, um eine kohärente und kontextuell passende Antwort zu erzeugen. Das Generationsmodell Modell ist in der Lage, komplexe Zusammenhänge zu verstehen und aus den bereitgestellten Informationen eine sinnvolle, natürlichsprachliche Antwort zu formulieren. Die Antwort wird der Nutzer*in über den Kanal ausgespielt, über den sie auch die Anfrage gesendet hat.

Wofür setzen wir RAG bei Thalia ein?

Wir setzen bei Thalia RAG in verschiedenen Szenarien ein und verproben laufend weitere Anwendungsfälle, darunter z.B.:

• Chatbot für die Mitarbeiter*innen in den Filialen: Ein RAG-basierter Chatbot soll zukünftig Mitarbeiter*innen in den Filialen schnell auf unternehmensinterne Wissensdatenbanken zugreifen lassen, um Fragen zu Produkten, Prozessen oder Unternehmensrichtlinien effizient zu beantworten.
• Chatbot für interaktive Gebrauchsanweisungen für unseren eReader Tolino: Der Chatbot kann Fragen von Nutzer*innen zu Funktionen und Problemen des Tolino eReaders dynamisch beantworten, indem er Informationen aus technischen Dokumentationen und Handbüchern zieht.
• Chatbot für Mitarbeiter*innen-Services: Dieser RAG-basierte Chatbot ist in der Lage allgemeine Fragen zu HR-Themen wie Urlaubsregelungen, Dienstreisen oder Betriebsunfällen beantworten. Mithilfe von RAG kann der Chatbot gezielt auf die entsprechenden Richtlinien und Informationen zugreifen und somit schnell und präzise Antworten auf häufige Anfragen liefern.
• KI-basierte Coding-Assistenten: Ein RAG-basiertes System könnte Entwickler*innen bei der Lösung spezifischer Programmierprobleme helfen, indem es relevante Codebeispiele, Dokumentationen und Best Practices aus internen und externen Quellen bereitstellt. Es ermöglicht kontextbezogene Unterstützung und sorgt für eine kontinuierliche Verbesserung der Entwicklungsprozesse.

Implementierung und Komponenten unseres ThaliaAI-RAG-Systems:

Unser RAG-System und der darauf basierende ThaliaAI-Chatbot wurde zum Großteil innerhalb des Microsoft Azure Tool Stack umgesetzt. Die Entwicklung erfolgte nach dem Grundprinzip einer modularen Architektur. So lassen sich einzelne Komponenten nach Belieben durch andere Services austauschen, um z.B. das LLM oder die Vektor-DB zu ersetzen. Diese modulare Struktur macht unser RAG-System und den angeschlossenen Chatbot flexibel und leicht wartbar. Unser RAG-Architektur besteht aus fünf Hauptkomponenten: Scraper¹², Vektordatenbank¹³, Embedding Modell, Large Language Modell (LLM) und Chatbot Applikation. Des Weiteren wird Blob Storage als Datenspeicher in der Cloud verwendet. Optional sind eine CosmosDB und ein Data-Pipeline Schedule Job angebunden. 

Scraper: Die Implementierung des RAG-Systems und des Chatbots erfordert eine Daten-Pipeline, die Daten von der Wissensquelle (im Beispiel ein SharePoint) zu einem Zwischenspeicher (bei uns Azure Blob Storage) transferiert. Ein technischer User extrahiert Metadaten und Inhalte der SharePoint-Seiten und Dokumente. Diese Informationen werden anschließend in einem Blob Storage hochgeladen. Der Scraper vergleicht Hash-Werte der SharePoint- und Blob Storage-Daten, um geänderte oder gelöschte Inhalte zu aktualisieren oder zu entfernen. Die SharePoint Seiten werden mithilfe eines Webdrivers geöffnet und die Texte extrahiert, bevor sie in Textdateien gespeichert und hochgeladen werden. Der Scraper funktioniert technologieagnostisch und kann auch in anderen Cloud-Diensten verwendet werden. Der Scraper wird täglich ausgeführt, um die Wissensbasis des RAG-Systems aktuell zu halten. 

Embedding-Modell: Das Embedding-Modell dient dazu, den natürlichsprachlichen Text aus den Quelldateien in Vektoren/Embeddings und damit in ein maschinell verarbeitbares Datenformat umzuwandeln. Die so generierten Vektoren können anschließend durch unser System interpretiert und weiterverarbeitet werden. Eine solche Weiterverarbeitung kann beispielsweise der semantische Vergleich zweier Vektoren über Ähnlichkeitsmaße sein. Wichtig ist, dass dabei das gleiche Embedding-Modell sowohl für die Such-Query der Nutzer*innen, als auch für das Erstellen der Vektoren im Index verwendet wird. 

Vektordatenbank: Für die Vektordatenbank des RAG-Systems wird derzeit die Azure AI Search verwendet. Innerhalb der AI Search werden eine Data Source, ein Index, ein Indexer¹⁴ und ein Skillset erstellt. Die Data Source greift auf einen Datenspeicher – hier auf unseren Blob Storage, der mit unseren SharePoint-Daten befüllt wird – zu. Der Index wird vom Indexer einmalig oder durch einen Scheduler über die Datenquelle befüllt und dient als Speicherung der Daten und deren Vektoren. Ein Skillset kann neben dem Indexer verwendet werden, um Daten, die in den Index laufen um weitere Transformationen und Metadaten anzureichern. Eine solche Anreicherung kann beispielsweise das „Chunking“ der Daten und das anschließende Vektorisieren dieser Text-Chunks sein. Später werden die Vektoren dieser Chunks mit dem Vektor des Such-Query, also der Nutzer*innen-Fragen verglichen und die ähnlichsten Chunks zum Such-Query wiedergegeben.

LLM: Das Large Language Modell (LLM) ist die wohl bekannteste Komponente eines RAG-Systems. Durch bekannte Vertreter, wie Googles Gemini und OpenAI’s ChatGPT erfreuen sich LLMs großer Beliebtheit. ThaliaAI basiert aktuell auf in Azure bereitgestellten GPT-Versionen. Konkret sind die neueren Versionen GPT-4o oder GPT-4o-mini im Einsatz. Das LLM ist die Komponente, mit der der eigentliche Chat erfolgt. Die Such-Query und die gefundenen, ähnlichsten Kontext-Chunks aus dem Index der Vektordatenbank werden dem LLM präsentiert. Das LLM formuliert dann daraus eine Antwort in natürlicher Sprache. Dabei wird das RAG-System so konfiguriert, dass das LLM für die Formulierung einer passenden Antwort auf eine Frage einer Nutzer*in nur die Informationen nutzen kann, die es aus der Vektor-DB erhält. Auf diese Weise werden Falschinformationen und dem sog. Halluzinieren des LLM vorgebeugt. 

Chatbot Applikation: Unser ThaliaAI Chatbot besteht aus einem React Frontend gepaart mit einem Python Backend. Dabei regelt das Backend die Kommunikation zwischen der Vektordatenbank, LLM und Embedding-Modell. Das Frontend besteht aus einem Chat mit klassischen Chatbot-Features wie Buttons, die häufige Fragen vorformulieren und einer Chat-Historie. Wichtigste Komponente des Bots ist die Ausgabe von Quellen. Die Nutzer*innen erhalten immer einen Link auf die jeweiligen Quelldateien, die zur Antwortgenerierung genutzt wurden. Die so geschaffene Transparenz stärkt die Nachvollziehbarkeit und das Vertrauen in das RAG-System.

Autoren

Dr. Henrik Kortum-Landwehr, Team Lead: KI und Data Science, Thalia Bücher GmbH

Sascha Meyer, Data Scientist / ML Engineer, Thalia Bücher GmbH

---

1. https://nlp.stanford.edu/IR-book/information-retrieval-book.html ↩︎
2. https://openai.com/index/chatgpt/ ↩︎
3. https://gemini.google.com/ ↩︎
4. https://stackoverflow.blog/2024/06/06/breaking-up-is-hard-to-do-chunking-in-rag-applications/ ↩︎
5. https://web.stanford.edu/~jurafsky/slp3/6.pdf ↩︎
6. https://arxiv.org/abs/1810.04805v2 ↩︎
7. https://www.elastic.co/de/what-is/vector-database ↩︎
8. https://www.kaggle.com/code/satishgunjal/tokenization-in-nlp ↩︎
9. https://medium.com/@maleeshadesilva21/preprocessing-steps-for-natural-language-processing-nlp-a-beginners-guide-d6d9bf7689c9 ↩︎
10. https://studymachinelearning.com/cosine-similarity-text-similarity-metric/ ↩︎
11. https://de.wikipedia.org/wiki/Large_Language_Model ↩︎
12. https://en.wikipedia.org/wiki/Web_scraping ↩︎
13. https://www.elastic.co/de/what-is/vector-database ↩︎
14. https://medium.com/@j13mehul/rag-part-4-indexing-1985f4000f72 ↩︎