tomczak.dev

KI-Architektur

RAG mit eigenen Daten: So bauen Unternehmen ihr System

20 Minuten suchen, um das richtige Angebot aus 2022 zu finden, oder drei Sekunden per RAG-Agent. Hier ist der Unterschied.

RAG-System Architektur für interne Wissensdatenbank

Zwanzig Minuten Suche gegen drei Sekunden

Ein Mitarbeiter sucht das Angebot, das er einem Kunden vor zwei Jahren geschickt hat. Zwanzig Minuten später hat er vier verschiedene Versionen gefunden, weiß aber nicht welche die finale war.

Ein RAG-Agent findet die richtige Version in drei Sekunden. Sucht nach Inhalt, nicht nach Dateinamen. Versteht "das Angebot für den Kunden in Hamburg mit den Sonderkonditionen für Lieferzeit", obwohl der Dateiname "Angebotv3finalWIRKLICHFINAL.pdf" lautet.

Das ist RAG. Und das ist der pragmatischste Einstieg in Private AI, den ich kenne.

Was RAG ist, und was es von Fine-Tuning unterscheidet

RAG steht für Retrieval-Augmented Generation. Das Prinzip ist einfach: Ein KI-Modell antwortet nicht nur aus seinem trainierten Wissen, sondern durchsucht vorher eine Dokumentenbibliothek und ergänzt die Antwort mit konkreten, aktuellen Informationen aus Ihren eigenen Unterlagen.

Der Unterschied zu Fine-Tuning: Beim Fine-Tuning werden Ihre Daten ins Modell "eingebrannt": ein komplexer, teurer Prozess, der das Modell grundlegend verändert. Bei RAG bleiben Modell und Daten getrennt. Das Modell bleibt generisch; Ihre Daten liegen in einer durchsuchbaren Vektordatenbank daneben.

Das hat praktische Vorteile: Daten können täglich aktualisiert werden, ohne das Modell neu zu trainieren. Und: Ihre Dokumente verlassen nie das System. Sie werden lokal gespeichert, lokal durchsucht, lokal genutzt.

Die Architektur: Wie RAG technisch funktioniert

Drei Komponenten bilden ein RAG-System:

1. Vektordatenbank: Ihre Dokumente werden in numerische Vektoren (Embeddings) umgewandelt und gespeichert. Suchen Sie nach "Reklamationsprozess", findet die Datenbank semantisch ähnliche Dokumente, auch wenn das Wort selbst nicht darin vorkommt.

2. Embedding-Modell: Wandelt Text in Vektoren um. Kann lokal laufen (z.B. sentence-transformers, Nomic Embed): kein Cloud-Transfer nötig.

3. LLM (das eigentliche Sprachmodell): Erhält die Frage des Nutzers plus die relevanten Dokument-Ausschnitte aus der Vektordatenbank und formuliert eine strukturierte Antwort.

Ablauf einer Anfrage:

Gesamtdauer: 1–3 Sekunden.

  • Mitarbeiter stellt Frage
  • Frage wird in Vektor umgewandelt
  • Vektordatenbank findet ähnliche Dokument-Chunks
  • LLM erhält Frage + Chunks und formuliert Antwort
  • Antwort inkl. Quellenangabe wird zurückgegeben

Welche Dokumente sich für RAG eignen

Theoretisch alles, was Text enthält. In der Praxis besonders wertvoll:

Weniger geeignet: stark strukturierte Daten, die besser in einer Datenbank mit SQL abgefragt werden (z.B. Preislisten, Lagerbestände). Für diese Fälle ist RAG Overkill, eine API-Anbindung ist effizienter.

  • Internes Wiki und Handbücher: "Wie läuft unser Onboarding-Prozess?" Der Agent weiß es.
  • Vertragsarchiv: Klauseln, Konditionen, Sondervereinbarungen durchsuchen
  • Support-Ticket-Historie: "Hat ein anderer Kunde dasselbe Problem gehabt?" Ja, mit Lösung.
  • CRM-Notizen und Gesprächsprotokolle: Kontext zu Kunden sofort abrufbar
  • Technische Dokumentation: Entwickler fragen intern statt Stack Overflow

Tools: Was Sie für einen Piloten brauchen

Für einen ersten funktionierenden Piloten brauchen Sie:

Zeitaufwand Pilot: Ein erfahrener KI-Entwickler baut einen funktionierenden Prototyp mit 10–50 Dokumenten in zwei bis vier Tagen. Die eigentliche Arbeit liegt dann in der Produktionsreife: Fehlerbehandlung, Zugriffsrechte, Skalierung, UI.

  • Vektordatenbank: Qdrant (Open Source, in Docker betreibbar) oder Chroma (besonders einfach für den Einstieg)
  • Embedding-Modell: nomic-embed-text oder bge-m3, beide lokal lauffähig, stark für Deutsch
  • LLM: Mistral 7B Instruct via Ollama, auf einem guten Server ohne GPU funktionsfähig, mit GPU deutlich schneller
  • RAG-Framework: LlamaIndex oder LangChain für die Orchestrierung

Was einen guten von einem schlechten RAG unterscheidet

Meine Erfahrung: Die meisten RAG-Probleme entstehen nicht im Modell, sondern in der Datenvorbereitung.

Chunking-Strategie: Wie Dokumente in Abschnitte aufgeteilt werden, bestimmt die Qualität der Suche. Zu kleine Chunks verlieren Kontext. Zu große enthalten zu viel Rauschen. Richtig zu chunken ist eine Kunst.

Metadaten: Jeder Chunk sollte wissen, aus welchem Dokument er stammt, wann es erstellt wurde, welche Abteilung zuständig ist. Das macht Antworten präziser und nachvollziehbar.

Re-Ranking: Einfache Vektorsuche findet ähnliche Chunks, aber nicht immer die relevantesten. Ein Re-Ranker-Modell sortiert die Kandidaten nochmal nach tatsächlicher Relevanz für die Frage.

---

Vollständige Private-AI-Strategie: Von der Architektur über DSGVO-Compliance bis zum ROI-Kalkül: Private AI: KI ohne Cloud-Risiko, der Leitfaden für deutsche Unternehmen

Nächster Schritt

Sollen wir Ihren KI-Use-Case einordnen?

Ich schaue mit Ihnen auf Ziel, Daten, Systeme und den sinnvollsten ersten Umsetzungsschritt.

Erstgespräch anfragen