RAG auf Databricks: Vom ersten Test zum verlässlichen Knowledge Assistant
Wie RAG auf Databricks vom halluzinierenden Pilot zum produktiven Knowledge Assistant wird: Pipeline-Stufen, Plattform-Komponenten und Eval-Pfad im Überblick.
Die Kernaussagen auf einen Blick.
- Ein RAG-System besteht aus acht aufeinander aufbauenden Verarbeitungsschritten: Dokumente laden, Inhalte auslesen, Text aufteilen, für die Suche vorbereiten, indexieren, passende Stellen finden, Treffer sortieren und eine Antwort erzeugen.
- Databricks stellt für viele dieser Schritte bereits integrierte Dienste bereit: Auto Loader und Lakeflow Connect für die Anbindung der Datenquellen, Vector Search und AI Search für die Suche in den Dokumenten, Foundation Model APIs für die Verarbeitung der Texte und die Erzeugung der Antworten sowie Mosaic AI Agent Framework für mehrstufige KI-Anwendungen.
- Die Qualität der Antworten hängt besonders von drei häufig unterschätzten Punkten ab: einer sinnvollen Aufteilung der Dokumente, einer Kombination aus Stichwort- und Ähnlichkeitssuche mit anschließender Sortierung der Treffer sowie einem automatisierten und regelmäßig wiederholbaren Qualitätstest.
- Empfehlenswert ist, RAG als bevorzugten Ansatz für Knowledge Assistants auf internen Dokumenten zu prüfen, zunächst die vorhandenen Databricks-Dienste zu nutzen, die zusätzliche Sortierung der Suchtreffer bereits in den ersten Qualitätstests zu berücksichtigen und ein eigenes Modelltraining erst zu prüfen, wenn Dokumentaufteilung, Suche und Trefferqualität optimiert wurden.
Inhaltsverzeichnis
Was ist RAG? Retrieval-Augmented Generation einfach erklärt
Viele RAG-Projekte folgen demselben Verlauf. Der erste Test beantwortet einige sorgfältig ausgewählte Fragen korrekt, auch die vorbereitete Präsentation überzeugt die Beteiligten. Sobald Fachanwender eigene Fragen stellen, werden die Antworten jedoch deutlich unzuverlässiger. Der Assistent erzeugt Aussagen, die sich in den gefundenen Dokumenten nicht belegen lassen. Teilweise findet er zwar das richtige Dokument, verwendet aber die falsche Textstelle. Ohne systematische Tests bleibt unklar, ob die Ursache in der Dokumentaufteilung, der Suche, der Sortierung der Treffer oder im Sprachmodell liegt.
Die Qualitätsprüfung besteht häufig nur aus wenigen manuell gepflegten Testfragen. Änderungen verbessern einzelne Antworten, verschlechtern aber möglicherweise andere, ohne dass dies sofort sichtbar wird. Auch ein technisch funktionierender Suchindex garantiert noch keine guten Antworten. Oft entsteht dann vorschnell die Hoffnung, ein eigenes Modelltraining werde das Problem beheben.
Genau hier setzen wir an. Bei RAG verteilt sich die Verantwortung für die Qualität auf mehrere Verarbeitungsschritte: jeder Schritt kann die Antwort verbessern oder verschlechtern und muss deshalb separat geprüft werden. Auf Databricks ist die gute Nachricht, dass die meisten dieser Schritte verwaltete Plattform-Komponenten sind. Die weniger gute Nachricht: Entscheidend sind das Zusammenspiel der Schritte und eine Messung, mit der Veränderungen zuverlässig bewertet werden können. Ein einzelner Dienst oder ein größeres Sprachmodell löst das Qualitätsproblem meist nicht allein.
RAG verbindet eine Suche in eigenen Dokumenten mit einem Sprachmodell. Für jede Frage werden zunächst passende Textstellen gesucht und anschließend an das Sprachmodell übergeben. Das Modell soll seine Antwort auf diese gefundenen Inhalte stützen. Der Ansatz wurde 2020 wissenschaftlich beschrieben und hat sich seitdem breit etabliert, zu einem häufig genutzten Ansatz für KI-Anwendungen auf Unternehmenswissen entwickelt.
Für die praktische Umsetzung ist vor allem wichtig, dass RAG aus mehreren Schritten besteht. Dokumente werden eingelesen, in verständliche Textabschnitte zerlegt, für die Suche vorbereitet und bei jeder Frage nach passenden Inhalten durchsucht. Jede dieser Stufen hat eigene Stellschrauben und eigene Fehlerquellen. Die Qualität der Antwort hängt vom schwächsten Schritt in dieser Kette ab.
Zwei Abgrenzungen helfen bei der Einordnung. Beim Fine-Tuning wird das Verhalten des Modells dauerhaft verändert. Eigene Trainingsdaten und ein neuer Trainings-Lauf sind nötig, und jede neue Dokumentversion löst diese Arbeit erneut aus. Bei RAG bleibt das Modell unverändert; die Dokumente bleiben eigenständige Wissensquelle und werden bei jeder Frage durchsucht. Die klassische Volltext-Suche zeigt dagegen nur Trefferlisten. Ein RAG-Assistent formuliert daraus eine zusammenhängende Antwort und verweist auf die verwendeten Quellen. Was RAG als Plattform-Pattern auf Databricks bedeutet und wie es ins KI-Portfolio einsortiert ist, klären wir im Überblick zu künstlicher Intelligenz auf Databricks.
Acht Schritte von der Quelle bis zur Antwort
Für die Planung lässt sich ein RAG-System in acht Schritte aufteilen. Jeder Schritt verarbeitet das Ergebnis des vorherigen und gibt es an den nächsten weiter. Für jeden Schritt sollte eine eigene Qualitätsfrage beantwortet werden.
| Stufe | Aufgabe | Databricks-Komponente | Häufige Fehlerquelle | Eval-Frage |
|---|---|---|---|---|
| 1. Dokumente einlesen | Dokumente aus SharePoint, Confluence, Cloud-Speichern oder Dateifreigaben übernehmen | Auto Loader, Lakeflow Connect, Volumes | Neue, geänderte oder gelöschte Dokumente werden nicht vollständig berücksichtigt | Sind alle gültigen Dokumente vorhanden und veraltete Versionen entfernt? |
| 2. Inhalte auslesen | Text, Tabellen und Überschriften aus unterschiedlichen Dateiformaten extrahieren | Databricks Document Parsing, PyMuPDF, Unstructured | Wichtige Inhalte werden beim Auslesen übersehen oder falsch angeordnet | Wurden Text und Struktur des Dokuments korrekt übernommen? |
| 3. Dokumente aufteilen | Dokumente in sinnvolle Textabschnitte zerlegen | Eigene Logik in Spark/Python | Textabschnitte sind zu groß, zu klein oder trennen zusammengehörige Inhalte | Enthält mindestens ein Abschnitt alle Informationen, die für eine Antwort benötigt werden? |
| 4. Texte für die Ähnlichkeitssuche vorbereiten | Textabschnitte in eine mathematische Darstellung für die Suche umwandeln | Foundation Model APIs (GTE-Large, BGE-Large, OpenAI text-embedding-3) | Das verwendete Modell erkennt spezielle Begriffe und fachliche Zusammenhänge nicht zuverlässig | Findet die Suche auch dann passende Inhalte, wenn Frage und Dokument unterschiedliche Formulierungen verwenden? |
| 5. Suchindex aufbauen | Die vorbereiteten Textabschnitte in einem durchsuchbaren Index speichern | Mosaic AI Vector Search, AI Search | Aktualisierungen kommen verspätet an oder Berechtigungen und Filter fehlen | Sind neue Inhalte zeitnah auffindbar und nur für berechtigte Nutzer sichtbar? |
| 6. Passende Textstellen suchen | Zu einer Frage passende Dokumentabschnitte finden | Vector Search Query, Hybrid Search | Konkrete Nummern, Produktnamen und exakte Begriffe werden nicht zuverlässig gefunden | Befinden sich die wichtigsten Textstellen unter den ersten Suchergebnissen? |
| 7. Treffer neu sortieren | Die gefundenen Abschnitte mit einem genaueren Modell erneut bewerten | BGE-Reranker, Cross-Encoder, LLM-Reranker | Die wichtigste Textstelle steht zu weit hinten und wird vom Sprachmodell kaum berücksichtigt | Stehen die hilfreichsten Textstellen ganz oben in der Trefferliste? |
| 8. Antwort erzeugen | Aus den gefundenen Textstellen eine verständliche Antwort erstellen | Foundation Model APIs (Llama 4, Mistral, Claude) oder externe Modelle über Unity AI Gateway (GPT-5, Gemini 3) | Das Modell verwendet die Quellen nicht korrekt oder ergänzt unbelegte Aussagen | Lässt sich jede wesentliche Aussage mit den bereitgestellten Quellen belegen? |
Diese Aufteilung hilft dabei, Fehler gezielt dem richtigen Verarbeitungsschritt zuzuordnen. Wer ausschließlich das Sprachmodell austauscht, übersieht möglicherweise, dass die benötigte Information bereits bei der Dokumentaufteilung verloren ging, oder dass eine gute Textstelle in der Trefferliste zu weit hinten steht.
Data & AI Beratung mit ruhrdot
Als offizieller Databricks-Partner begleiten wir dich von der Datenstrategie bis zur produktiven KI-Lösung.
Vector Search, AI Search und Foundation Model APIs
Die Databricks-Doku beschreibt RAG als integrierten Anwendungsfall innerhalb der Plattform, das die meisten Stufen über verwaltete Dienste abdeckt. Die wichtigsten Dienste lassen sich den einzelnen Verarbeitungsschritten klar zuordnen.
Von der Dokumentenquelle zum RAG-Endpoint..
Vector Search verbindet Delta Tables mit Foundation-Model-Embeddings zu einem serverlosen Index. RAG Agents und Chatbots fragen ihn direkt über eine Query-API ab. Governance läuft durchgängig über Unity Catalog.
Delta Lake
ParquetDokumente anbinden und Inhalte extrahieren. Auto Loader erkennt neue Dateien im Cloud-Speicher und verarbeitet sie automatisch. Lakeflow Connect bindet Wissens- und Geschäftssysteme wie SharePoint, Google Drive oder Salesforce als verwaltete Connectoren in Databricks an; klassische Dokumentbestände aus Dateifreigaben oder Cloud-Speichern landen über Auto Loader auf Volumes. Für PDFs, Word- und HTML-Dokumente können integrierte oder externe Werkzeuge den Text und seine Struktur auslesen. Je nach Dokumenttyp können auch Python-Bibliotheken eingesetzt werden, etwa PyMuPDF oder die Unstructured-Bibliothek im Notebook. Wo Auto Loader, Connect und Jobs in einem gemeinsamen Betriebsmodell zusammenspielen, klären wir im Überblick zu Lakeflow auf Databricks.
Chunking: Dokumente in suchbare Stücke zerlegen. Die Aufteilung in Chunks bleibt Eigenleistung und muss anhand der eigenen Dokumente entwickelt und getestet werden. Das Team legt fest, wie Überschriften, Absätze, Tabellen und andere Inhalte in einzelne Chunks geschnitten werden. Chunk-Größe und Overlap (Überschneidung zwischen aufeinanderfolgenden Chunks) richten sich nach der gemessenen Antwortqualität. Eine allgemeingültige Einstellung gibt es dafür nicht.
Suchbare Darstellung und Index. Mosaic AI Vector Search erstellt einen Suchindex und kann Änderungen aus Delta-Tabellen automatisch übernehmen. Unterstützt sowohl Ähnlichkeitssuche als auch die Kombination mit klassischer Stichwortsuche. Die Umwandlung der Texte in eine suchbare mathematische Darstellung kann automatisch erfolgen, über die Foundation Model APIs. AI Search bündelt mehrere Schritte der Suche in einem verwalteten Dienst: Indexaufbau, Aktualisierung, kombinierte Suche und Zugriffsprüfung werden gemeinsam verwaltet. Wie sich der Index aufbaut, welche Datentypen er kennt und wie Storage- und Compute-Trennung im Index laufen, klären wir im Überblick zu Vector Search auf Databricks. Welcher Endpoint Hybrid Search und Sync abnimmt und wann er die eigene RAG-Pipeline ersetzt, klären wir im Überblick zu AI Search auf Databricks. Wo der Vektor- und Volltext-Index direkt aus der OLTP-Schicht heraus für Agenten greift, zeigen wir im Überblick zu Lakebase Search.
Treffer finden und nach Relevanz sortieren. Anwendungen können den Suchindex über Programmierschnittstellen abfragen. Die genauere Sortierung der Treffer muss weiterhin selbst ergänzt werden. Dafür kann ein spezialisiertes Modell als eigener Endpunkt betrieben werden, etwa ein BGE-Reranker oder ein dediziertes LLM. Eine bessere Sortierung der Suchergebnisse verbessert die Antworten häufig deutlich, ohne den gesamten Stack umzubauen.
Antworterstellung. Über die Foundation Model APIs können verschiedene Sprachmodelle verwendet werden, ohne sie vollständig selbst zu betreiben. Welche Modell-Familien dort gelistet sind und ab welchem Nutzungsvolumen ein eigener Modellendpunkt wirtschaftlicher wird, klären wir im Überblick zu Foundation Model APIs auf Databricks.
Mehrstufige Abläufe und externe Werkzeuge. Wenn der Assistent zusätzlich Berechnungen ausführt, APIs aufruft oder mehrere Arbeitsschritte steuert, kann das Mosaic AI Agent Framework diese Schritte steuern und protokollieren. Ein einfacher Knowledge Assistant, der nur Dokumente durchsucht und Antworten erzeugt, benötigt diese zusätzliche Schicht nicht zwingend.
Qualitätsprüfung und Überwachung. Mosaic AI Agent Evaluation und MLflow LLM Evaluation unterstützen automatisierte Tests und die laufende Bewertung der Antworten, wir kommen darauf gleich zurück.
RAG Chunking, Hybrid Search und Reranking: Die wichtigsten Qualitätshebel
Eine reine Ähnlichkeitssuche (Vektor- oder Semantic Search) erkennt verwandte Bedeutungen, findet aber exakte Nummern und Namen nicht immer zuverlässig. Typische Beispiele sind Produktnummern, Vertragskennzeichen, Personennamen und seltene Fachbegriffe. Eine Suche nach „Vertrag A-2024-118" will diesen Vertrag. Bei solchen Anfragen wird der exakte Treffer benötigt und nicht nur ein thematisch ähnliches Dokument.
Hybrid Search kombiniert Bedeutung und konkrete Begriffe in einer Suchschicht. Vector Search verbindet die Ähnlichkeitssuche mit klassischer Volltextsuche (BM25) im selben Index. Die Ergebnisse beider Sucharten fließen zu einer gemeinsamen Trefferliste zusammen. Du brauchst keine zweite Suchschicht parallel; der Index liefert die Hybrid-Treffer direkt. Für viele Knowledge Assistants ist Hybrid Search der erste sinnvolle Qualitätsschritt, bevor ein größeres oder teureres Sprachmodell getestet wird.
Anschließend kann ein Reranker die Treffer genauer sortieren. Die erste Suche liefert zunächst eine größere Kandidatenmenge (Top-N, typisch 20 bis 50 Treffer). Ein präziseres Modell wie ein Cross-Encoder oder ein dafür eingesetztes LLM bewertet anschließend nur diese Auswahl und setzt die besten Treffer an den Anfang (Top-K, typisch 3 bis 8). Der Grund ist nicht akademisch. Das Paper „Lost in the Middle" von Liu et al. 2024 zeigt: Sprachmodelle berücksichtigen Informationen am Anfang und Ende eines langen Kontexts oft stärker als Inhalte in der Mitte (Lost-in-the-Middle-Effekt). Steht die wichtigste Textstelle zu weit hinten, kann sie trotz grundsätzlich korrekter Suche in der Antwort untergehen. Das Reranking bringt die wichtigste Quelle weiter nach vorn.
Spätestens in drei Situationen sollte Reranking geprüft werden:
Dokumentenmenge wächst
Ab etwa 5.000 Dokumenten wird eine genauere Sortierung der Treffer relevant.
Richtiges Dokument, falscher Chunk
Die Suche trifft das passende Dokument, aber nicht die passende Textstelle darin.
Antwort über mehrere Chunks verteilt
Eine vollständige Antwort benötigt Informationen aus mehreren gefundenen Abschnitten.
Bis dahin reicht Hybrid Search alleine. Die Optimierung sollte insgesamt in einer festen Reihenfolge erfolgen. Ein Modellwechsel kann Fehler in Chunking und Retrieval nicht zuverlässig ausgleichen.
Hybrid Search verbessern
Kombination aus Ähnlichkeits- und Stichwortsuche zuerst optimieren, die größte Hebelwirkung bei geringstem Aufwand.
Reranking ergänzen
Treffer mit einem präziseren Modell neu sortieren, sobald Dokumentenmenge oder Antwortkomplexität es rechtfertigen.
Sprachmodell vergleichen
Erst wenn Suche und Sortierung zuverlässig funktionieren, verschiedene Modelle unter denselben Testbedingungen vergleichen.
Welches LLM passt für RAG?
Das verwendete Sprachmodell lässt sich meist einfacher wechseln als Dokumentaufteilung und Suche. In Databricks stehen dafür drei grundlegende Betriebsmodelle zur Verfügung.
Verwaltete Modelle über Databricks Foundation Model APIs. Verwaltet abrufbar sind die Llama-4-Modelle (Maverick und Scout), Llama 3.3 70B sowie Modelle der Mistral-Familie. Über die Anthropic-Partnerschaft stehen Claude-Modelle (Opus, Sonnet, Haiku) ebenfalls direkt im Workspace bereit, ohne separates Gateway. Die Kosten entstehen je nach Modell nutzungsabhängig (Pay-per-Token) oder über reservierte Kapazität (Provisioned Throughput). Für deutschsprachige Anwendungen lohnt der Vergleich mehrerer Modelle anhand derselben Testfragen; die Eignung schwankt zwischen den Familien deutlich. Wie sich das Modell-Portfolio aufteilt und wann ein großes Frontier-Modell gegen ein kompaktes Open-Weight-Modell kippt, klären wir im Überblick zu Large Language Models auf Databricks.
Externe Sprachmodelle über das Unity AI Gateway. OpenAI (GPT-5, GPT-5.1, o-Reihe), Google (Gemini 2.5 Pro und Gemini 3 Pro) und weitere Anbieter sind über das Gateway anbindbar. Anthropic Claude läuft inzwischen direkt über Databricks und braucht das Gateway nicht mehr zwingend. Das Gateway protokolliert die Nutzung zentral, steuert sie über Quoten und ordnet Kosten Anwendungen oder Teams zu. Das ist hilfreich, wenn ein Anbieter bereits freigegeben ist oder in den Tests bessere Ergebnisse liefert als die verwalteten Optionen.
Selbst betriebene oder angepasste Modelle. Für speziell trainierte Modelle mit besonderem Fachvokabular oder eigenen Anforderungen gibt es Model Serving als Endpoint-Pfad. Diese Variante verursacht den höchsten Entwicklungs- und Betriebsaufwand. Sie sollte erst gewählt werden, wenn allgemein verfügbare Modelle die fachlichen Anforderungen nachweislich nicht erfüllen.
Das Sprachmodell sollte erst verglichen werden, nachdem Dokumentaufteilung und Suche zuverlässig funktionieren. Andernfalls wird die gesamte Lösung vorschnell auf ein Modell zugeschnitten, statt mehrere Modelle objektiv mit denselben Qualitätskriterien zu vergleichen.
Berechtigungen, Quellen und Suchergebnisse
Ein zentraler Vorteil der integrierten Databricks-Dienste ist die Wiederverwendung vorhandener Datenberechtigungen. Suchindizes werden als zentral verwaltete Objekte in Unity Catalog geführt. Zugriffsrechte, Datenherkunft und Änderungen können nachvollzogen werden. Zeilenfilter und Maskierungen sensibler Inhalte können auch bei der Suche berücksichtigt werden. Der Assistent darf einem Nutzer nur Inhalte anzeigen, die dieser auch in der Quelle lesen darf.
Diese durchgängige Berechtigung ist für Datenschutz und Informationssicherheit häufig entscheidend. Bei einem externen Suchsystem müssen Zugriffsrechte häufig zusätzlich aufgebaut und synchron gehalten werden. Jede neue Anwendung verursacht dadurch zusätzliche Pflege und Prüfung. In Prüfungen müssen dann zwei getrennte Zugriffsmodelle nachvollzogen werden. Auch Änderungen an Nutzern und Gruppen müssen in mehreren Systemen umgesetzt werden.
Für RAG kommen zwei Themen hinzu, die der Katalog mitlöst. Erstens die zentrale Protokollierung von Fragen, Antworten und Modellaufrufen in Inference-Tabellen. Diese Daten können für Qualitätskontrollen und die Erkennung von Verschlechterungen genutzt werden. Zweitens die nachvollziehbare Verbindung zwischen Quelldokumenten, Suchindex und Anwendung, die bei einer Modell- oder Embedding-Änderung sichtbar macht, welche Anwendungen bei einer Änderung überprüft werden müssen. Wie die Berechtigungs- und Lineage-Mechanik im Katalog selbst aufgebaut ist, schauen wir uns im Überblick zu Unity Catalog auf Databricks genauer an.
Eine wichtige Grenze bleibt jedoch bestehen. Berechtigungen gelten zunächst für das gesamte Dokument und die daraus erzeugten Abschnitte. Enthält ein Dokument intern unterschiedlich geschützte Inhalte, kann eine reine Dokumentberechtigung zu grob sein. Solche Dokumente müssen vor der Aufteilung getrennt, bereinigt oder genauer klassifiziert werden.
RAG Evaluation mit LLM-as-a-Judge, MLflow und Mosaic AI Agent Evaluation
Eine systematische Qualitätsprüfung entscheidet häufig darüber, ob ein Pilot produktiv werden kann. Wenige manuell geprüfte Fragen reichen für eine verlässliche Bewertung nicht aus. Sie zeigt nur einen kleinen Ausschnitt und macht Veränderungen kaum vergleichbar.
Mosaic AI Agent Evaluation übersetzt subjektive Eindrücke in vergleichbare Qualitätswerte. Ein zweites Sprachmodell bewertet die erzeugte Antwort anhand festgelegter Kriterien. Drei Qualitätskriterien sind dabei besonders wichtig.
Übereinstimmung mit den Quellen
Lassen sich die Aussagen der Antwort aus den gefundenen Textstellen ableiten, oder enthält sie unbelegte Ergänzungen? Wichtigste Kennzahl gegen frei erfundene Antworten.
Inhaltliche Richtigkeit
Ist die Antwort fachlich richtig und vollständig? Dafür werden fachlich geprüfte, dauerhaft gepflegte und versionierte Erwartungsantworten benötigt.
Genauigkeit der Trefferliste
Wie viele gefundenen Abschnitte passen zur Frage, und sind wichtige Textstellen vollständig enthalten? Zeigt, ob die Ursache in Suche oder Antworterzeugung liegt.
Die Tests sollten regelmäßig mit einem festen und versionierten Fragenkatalog ausgeführt werden. Unterschiedliche Dokumentaufteilungen, Suchmethoden und Modelle können direkt miteinander verglichen werden. Jede technische Änderung wird als eigener Testlauf dokumentiert. Damit ist sichtbar, ob eine Chunk-Größen-Änderung die Antwortqualität verbessert oder verschlechtert, und ob eine teurere Variante tatsächlich eine messbare Qualitätsverbesserung bringt. Wie sich Eval, Drift-Monitoring und KI-spezifische Governance über die Schichten verzahnen, klären wir im Überblick zu AI Governance auf Databricks.
Die operative Konsequenz ist klar: Die automatisierte Qualitätsprüfung sollte vor dem produktiven Rollout stehen. Ohne Messung beruhen technische Entscheidungen hauptsächlich auf Einzelmeinungen und wenigen Beispielen.
AI Search oder eigene RAG-Pipeline?
Für viele Standardanwendungen muss nicht jeder Verarbeitungsschritt selbst entwickelt werden. AI Search bündelt mehrere Schritte in einem verwalteten Dienst: Datenanbindung, Indexaufbau, kombinierte Suche und Berechtigungen werden gemeinsam betrieben. Das Team legt im Wesentlichen die Datenquelle und das verwendete Suchmodell fest. Viele technische Betriebsaufgaben übernimmt Databricks.
AI Search wählen, wenn
- Ein klassischer interner Knowledge Assistant auf gut vorbereiteten Dokumenten entsteht (unter 100.000 Dokumenten, ohne strenge Anforderungen an die Antwortzeit)
- Ein erster produktiver Anwendungsfall mit begrenzter Komplexität ansteht, bei dem Datenquellen, Berechtigungen und Betrieb zunächst stabil aufgebaut werden
- Einfache semantische Suchen und Klassifizierungen aus Databricks SQL über ai_query ohne separate App genügen
Eigene Pipeline wählen, wenn
- Eine besonders genaue oder individuell trainierte Sortierung der Treffer gefragt ist, die über Hybrid Search hinausgeht
- Assistenten zusätzlich externe Systeme aufrufen oder mehrere Arbeitsschritte über das Agent Framework ausführen
- Sehr große oder ungewöhnlich strukturierte Dokumentbestände individuelle Aufteilung für Tabellen, Quellcode oder Sonderformate brauchen
Der verwaltete und der individuelle Ansatz können schrittweise kombiniert werden. Ein sinnvoller Einstieg ist häufig der verwaltete Dienst. Eine eigene Pipeline wird erst ergänzt, wenn konkrete Anforderungen dies rechtfertigen. Beide Pfade lassen sich nebeneinander betreiben, weil sie auf demselben Vector-Search-Index aufsetzen können.
RAG oder Fine-Tuning?
In vielen Projekten wird früh gefragt, ob ein speziell trainiertes Modell die bessere Lösung wäre. Häufig besteht die Erwartung, dadurch Probleme bei Suche und Dokumentenqualität zu umgehen. Fine-Tuning ersetzt die Dokumentensuche jedoch meist nicht, sondern kann sie lediglich ergänzen. Drei Grundregeln helfen bei der Entscheidung.
Für regelmäßig aktualisierte Dokumente ist RAG in der Regel der sinnvollere Ausgangspunkt. Wenn die Wissensbasis aus Dokumenten besteht, die regelmäßig wachsen oder sich ändern, ist RAG gleichzeitig einfacher und überlegen. Ändert sich das Wissen, muss ein speziell trainiertes Modell erneut angepasst werden. Neue oder geänderte Dokumente verursachen zusätzlichen Trainingsaufwand. Bei RAG genügt meist die Aktualisierung des Suchindex.
Fine-Tuning kann sinnvoll sein, wenn Antworten einer festen Sprache, Struktur oder Tonalität folgen müssen. Oder wenn das allgemeine Modell bestimmte fachliche Anweisungen trotz guter Quellen nicht zuverlässig befolgt. Es ergänzt RAG, ersetzt es nicht: Die Dokumente bleiben weiterhin über RAG angebunden, während das Modell den gewünschten Antwortstil lernt. Wie Mosaic AI Training und der Fine-Tuning-Pfad operativ aussieht, klären wir im Überblick zu Mosaic AI Training auf Databricks.
Die operative Konsequenz: Fine-Tuning bleibt eine mögliche spätere Option und sollte anhand messbarer Qualitätslücken entschieden werden.
Was RAG nicht lösen kann
Ein Knowledge Assistant kann nur mit den Informationen arbeiten, die in den freigegebenen Dokumenten enthalten sind. Veraltete, widersprüchliche oder unvollständige Inhalte bleiben auch mit RAG problematisch.
Wenn die Wissensbasis unterschiedliche Versionen, fehlende Informationen oder gegensätzliche Vorgaben enthält, kann eine technisch gute Lösung solche fachlichen Lücken nicht zuverlässig ausgleichen. Drei Linien, die regelmäßig sichtbar werden:
Aktualität und Ordnung
Mehrere Versionen, doppelte Dateien und nicht freigegebene Entwürfe. Ohne klare Kennzeichnung bevorzugt die Suche mitunter eine veraltete oder nicht freigegebene Version.
Wissenslücken
Zu Fragen ohne verlässliche Information in der Wissensbasis kann das Modell trotzdem eine scheinbar plausible Antwort erzeugen. Strenge Regeln lassen dann nur den Hinweis auf eine fehlende Quelle zu.
Einheitliche Fachbegriffe
Unterschiedliche Bezeichnungen für denselben Prozess oder dasselbe Produkt lassen die Suche relevante Inhalte schlechter zusammenführen. Ein gepflegtes Glossar verbessert die Auffindbarkeit.
Diese Aufgaben gehören zur organisatorischen Pflege der Wissensbasis. Die Lakehouse-Komponenten lösen die technische Schicht; Verantwortliche für Aktualisierung, Archivierung und die Klärung widersprüchlicher Inhalte müssen unabhängig von der technischen Plattform festgelegt werden. Wir benennen das vor jedem Roll-out, weil sich ohne diese Verantwortung die Antwortqualität nach dem Pilot häufig schnell verschlechtert.
Grenzen eines produktiven RAG-Systems auf Databricks
Vier Einschränkungen sollten vor dem produktiven Einsatz berücksichtigt werden.
Funktionsumfang je Region
Nicht alle Dienste stehen in jeder Cloud und Region im gleichen Reifegrad bereit. Vor der Architekturentscheidung den produktiven Funktionsumfang der Zielregion prüfen.
Antwortzeit durch mehrere Schritte
Suche, Sortierung und Generierung verlängern gemeinsam die Antwortzeit. Für viele Knowledge Assistants realistisch, für Sprachassistenten oder Eingabe-Vorschläge oft zu langsam.
Modellkosten steigen mit Nutzung
Bei intensiver Nutzung entstehen spürbare monatliche Modell- und Compute-Kosten. Kosten sollten nach Anwendung, Fachbereich und Modell zugeordnet werden.
Dokumentenpflege bleibt Aufgabe
Ohne Dokumenten-Owner und Pflege-Prozess erhält der produktive Betrieb nur vorübergehend gute Ergebnisse. Die Inhalte müssen Fachbereiche aktualisieren.
Diese Grenzen schließen einen produktiven Einsatz nicht aus. Sie zeigen jedoch, ob Aufwand, Kosten und erwartete Nutzererfahrung realistisch zusammenpassen.
Fazit
Ein produktiver Knowledge Assistant auf Databricks entsteht aus mehreren aufeinander abgestimmten Verarbeitungsschritten.
Für viele technische Aufgaben stellt Databricks bereits integrierte Dienste bereit. Drei Aufgaben bleiben besonders entscheidend und müssen individuell gelöst werden: sinnvolle Dokumentaufteilung, genaue Sortierung der Suchtreffer und automatisierte Qualitätsprüfung. Mit ernsthafter Arbeit an diesen drei Stellen wird aus einem überzeugenden Pilot ein dauerhaft verlässliches System.
Ein wesentlicher Vorteil gegenüber einer vollständig selbst aufgebauten Lösung ist die Verbindung von Datenberechtigungen, Nachvollziehbarkeit und Qualitätstests innerhalb derselben Plattform. Unity Catalog kann Nutzerrechte und die Herkunft der verwendeten Daten zentral verwalten. Ein separates Berechtigungsmodell für eine externe Suchdatenbank kann dadurch entfallen. Die Qualität der Antworten kann automatisiert und über verschiedene Versionen hinweg verglichen werden. Manuelle Stichproben bleiben eine Ergänzung, sind aber nicht mehr die einzige Bewertungsgrundlage.
Empfehlenswert ist folgender Ansatz: Als ersten produktiven Anwendungsfall einen internen Knowledge Assistant auf klar gepflegten Dokumenten auswählen. Eine kombinierte Suche, eine zusätzliche Sortierung der Treffer und ein anhand von Tests ausgewähltes Sprachmodell einsetzen. Von Beginn an einen versionierten Fragenkatalog und automatisierte Qualitätstests aufbauen. Für einfachere weitere Anwendungen den stärker verwalteten AI-Search-Ansatz prüfen. Ein eigenes Modelltraining erst dann bewerten, wenn Suche und Dokumentverarbeitung nachweislich keine weiteren Verbesserungen mehr bringen und die verbleibenden Probleme hauptsächlich Tonalität, Format oder Antwortverhalten betreffen.
FAQ
Retrieval-Augmented Generation kombiniert einen Such-Index auf der eigenen Wissensbasis mit einem Sprachmodell, das die abgerufenen Treffer als Kontext für die Antwort nutzt. Auf Databricks setzt sich der Stack aus Auto Loader oder Lakeflow Connect für die Ingestion, Vector Search oder AI Search für den Index, den Foundation Model APIs für Embedding und Generierung und Mosaic AI Agent Evaluation für die Qualitäts-Messung zusammen. Berechtigungen erbt der Index über Unity Catalog aus den Quell-Tabellen.
