Menu

DE

Menu

DE

denkwerk TechTalk: Lasst uns RAG erstellen

denkwerk TechTalk: Lasst uns RAG erstellen

Robert Krämer, Technical Director, denkwerk
Robert Krämer, Technical Director, denkwerk

Robert Krämer

Robert Krämer

Technical Director

Technical Director

denkwerk

denkwerk

Künstliche Intelligenz (KI) steht im Arbeitsalltag im WebDev weit oben auf der To-do-Liste. Das Thema KI weist jedoch einige Einschränkungen auf. Diese Large Language Models (LLMs) sorgen zum Beispiel in puncto Datenschutz oder Zuverlässigkeit (Stichwort Halluzinationen) immer wieder für Gesprächsstoff. Auch deswegen haben wir in der Technik ein eigenes Retrieval Augmented Generation (RAG) konzipiert und gebaut.

Beim denkwerk TechTalk  erläuterten Tobias Kaulfuß (Software Developer) und Karam Aram (Senior Software Developer) ihr Vorgehen beim denkwerk eigenen Retrieval Augmented Generation (RAG).

Was ist eigentlich RAG?

Retrieval Augmented Generation steht für Methode: Sie ermöglicht die Fütterung einer künstlichen Intelligenz (KI), also eines Large Language Models (LLM), mit Daten aus externen Quellen. Der generierende Part der KI wird also ergänzt durch eine Suche in Datenquellen. Unsere beiden Entwickler Tobias und Karam haben mit viel Elan ein eigenes RAG für denkwerk gebaut.

Die Zutaten für das dw-RAG

Karam machte Lust auf mehr: Mit Detailwissen stillte er Wissenshunger. Der Software-Entwickler stellt die Zutaten für das RAG vor: Da wären zum einen proprietäre Daten. Das sind Daten, die der KI zu Trainingszeiten nicht zur Verfügung standen und auf die die KI keinen Zugriff hat. Zum anderen bräuchte man natürlich eben diese eine KI. Und zu guter Letzt noch die verbindende Zutat: nämlich eine Anwendung, die das Ganze orchestriert. Ganz konkret habe wir diese Komponenten ausgewählt:


  • VectorStore/ChromaDB (Retrieval)

  • Ollama (Generation)

  • SpringBoot/Spring AI  Applikation (Augmentation)

Die Vorteile der bestehenden Komponenten

Zunächst beschäftigten sich unsere beiden Experten mit der zugrunde liegenden KI-Technologien. Im Fokus stand Ollama, einer Laufzeitumgebung für verschiedene Open-Source LLMs. Es ermöglicht die Nutzung unterschiedlicher Modelle und stellt eine API bereit, mit der sich Sprachmodelle flexibel in Anwendungen integrieren lassen. Ollama kommt vor allem bei großen Sprachmodellen zum Einsatz. In der Entwicklung kann die Leistung von LLMs direkt auf den lokalen Rechnern genutzt werden. Neben Ollama können auch andere LLM-Anbieter wie OpenAI oder Spring AI  angebunden werden. Spring AI  stellt beispielsweise eine abstrahierte Schnittstelle für verschiedene LLM-APIs bereitstellt.

Für die semantische Suche in großen Textmengen kommt ein Vektorspeicher zum Einsatz. Mithilfe von Embedding-Modellen aus Ollama werden Texte in hochdimensionale Vektoren umgewandelt und in ChromaDB gespeichert. Diese Vektorisierung ermöglicht es, kontextuell ähnliche Inhalte zu einem Nutzer-Prompt effizient im Vektorspeicher zu finden und bereitzustellen. So können relevante Informationen auch aus großen Datenmengen präzise extrahiert werden.

Schon aus diesen beiden Komponenten lassen sich die großen Vorteile von RAG für Unternehmen ableiten, insbesondere im Vergleich zu KI als Stand Alone Entity:


  • Ressourcen- und Datenhoheit

  • Datenschutz

  • Geringere Latenz

  • Lokales Hosting

  • Polyvalenz/Anpassbarkeit


Besonders Datenhoheit und Datenschutz sind Werte, die in Zeiten von KI gefährdet sind. Aber woher rührt die größere Zuverlässigkeit, die erwähnt wurde? Hier lautet die Antwort: in den proprietären Daten und in der Art und Weise wie diese aufbereitet werden. Denn nun musste ja noch die orchestrierende Anwendung gebaut werden. Und was in der Theorie einfach und schön klingt, stellte die Entwicklung dann doch vor gewisse Herausforderungen.

„VectorStore/ChromaDB gibt es von der Stange, Ollama gibt es von der Stange, aber die Daten aus unserer gewählten Datenbank kamen nicht normalisiert raus, die API funktionierte nicht.“

Karam Amara, Senior Software Developer bei denkwerk

Helden für die Infrastruktur: Hand in Hand mit den Admins

Helfer in der Not waren, wie so oft, unsere Systemadministratoren. Sie stellten die Infrastruktur zur Verfügung. So konnte Ollama auf einem Server installiert werden, und zwar mit zwei Modellen: Das erste Modell übersetzt Text in Vektoren für die Datenbank (Ollama-Model for Embeddings), das zweite steht für den Chatbot zur Verfügung (Ollama-Model for Generation). Richtig gehört: Zur Abfrage des Wissens gehört natürlich eine Suche mittels Prompts, wie es die herkömmlichen Chatbots bieten. Zur RAG-Infrastruktur wurde weiterhin der Application Server implementiert, der die verschiedenen Services für Frontend, den VectorStore und natürlich das Backend beinhaltet.

Ein Held fürs Backend: SpringBoot/Spring AI  Applikation

Zum Kern des Projekts wurde SpringBoot und die noch junge Anwendung Spring AI  des Frameworks. Spring AI  befasst sich mit der grundlegenden Herausforderung der KI-Integration: der Verbindung der Unternehmensdaten und APIs mit den KI-Modellen. Warum es zum Favoriten unserer denkwerker wurde, fasst Tobias so zusammen:

„Das Spring AI Framework ist eine recht junge Komponente im Spring Ökosystem, die momentan rasant weiterentwickelt wird. Dieses Projekt hat uns die Gelegenheit gegeben, uns mit den Möglichkeiten von Spring AI intensiv vertraut zu machen. Da wir in unseren Kundenprojekten stark auf Spring setzen, können wir damit AI-Funktionalität nahtlos in unsere Businessanwendungen integrieren.“

Tobias Kaulfuß, Lead Software Developer bei denkwerk

 

Mittels Spring AI wurde das Ollama und die ChromaDB verbunden. Das Ollama ist dabei austauschbar. Weitere Alternativen sind Claude oder auch OpenAI. Ebenso ist die Datenbank austauschbar, das noch mal zur Verdeutlichung der Polyvalenz/Anpassbarkeit von RAG.

Und: ohne Daten keine Antworten

Wir erinnern uns: Die Daten aus der gewählten (internen) Datenbank wurden nicht normalisiert ausgespielt, die API von Ollama funktionierte nicht ... Hier war dann wieder Verlass auf unsere Admins, die die Daten exportieren konnten. Blieb „nur noch“ die Fleißarbeit: Die Daten mussten aufbereitet und in der Datenbank gespeichert werden. Dazu wurden die Daten zunächst in sogenannte „Token/Chunks“ gestückelt. Relevante Daten in einer Datenbank werden am besten gefunden, wenn sie in der Größe den Prompts entsprechen. Die Macher standen vor einem riesigen Berg an Textdaten, die zerstückelt und als Strings aufbereitet werden mussten.

„RAG steht und fällt mit den Daten ... Daten normalisieren und in die Pipeline zum Embedden bringen, ist die eigentlich Aufgabe beim RAG.“

Karam Amara, Senior Software Developer bei denkwerk


Im nächsten Schritt folgten dann noch eine Reihe von Anweisungen, schließlich müssen die Strings vom Chatbot gefunden werden. Dies ist der Retrieval-Teil von RAG. Normalerweise macht das Framework die Abfrage selbstständig, kann aber per Prompt-Engineering Fine-Tuning erhalten. Tobias und Kollegen gaben dem Ollama daher Kontext und Hintergrundinformation aus der dw-Datenquelle, damit es auch zuverlässige und relevante Informationen finden kann. Dem User wird gesagt, wenn es eine Frage nicht beantworten kann. So werden insgesamt Halluzinationen verhindert, die bei den Chatbots auf dem Markt leider noch sehr häufig vorkommen.

„Hauptsächlich Text, hauptsächlich Strings, super wenig Code, Logik […] ein paar Parameter zur Anbindung, die uns das Framework liefert.“

Tobias Kaulfuß, Lead Software Developer bei denkwerk


Ein herrliches Understatement von Tobias Kaulfuß im TechTalk. Ohne die Expertise, die innovativen Lösungsansätze und vor allem auch die Bewertung der Systeme auf dem Markt wäre das dw-RAG nicht entstanden. Und klar, um die zukünftigen Business-Anwendungen des Tools ging es im regen Austausch im Anschluss an den TechTalk …


Diesen Artikel teilen

Letzte Sparks