Wann Engineering-Teams Dust anstelle eigener In-House-RAG-Pipelines einführen sollten

Der Bau eines Prototyps für Retrieval-Augmented Generation (RAG) ist denkbar einfach: Mit LangChain oder LlamaIndex, einem Standard-Embedding-Modell und einer Vektordatenbank wie pgvector oder Pinecone lässt sich an einem einzigen Wochenende ein System aufsetzen, das relevante Textstellen aus einem Ordner voller Markdown-Dateien findet. Der langfristige Betrieb eines produktionsreifen internen Wissensabfragesystems für ein gesamtes Technologie- und Geschäftsunternehmen stellt jedoch vollkommen andere Anforderungen.

Engineering-Teams sollten Dust einführen, wenn das primäre Ziel in der internen Befähigung und dem operativen Wissensabruf über heterogene Unternehmens-SaaS-Tools (Notion, Slack, Google Drive, Confluence und GitHub) liegt – ohne dafür festangestellte Plattform-Entwickler für Connector-Wartung, Rechtesynchronisation und Pipeline-Stabilität abstellen zu müssen.

Umgekehrt sollten Teams eigene In-House-RAG-Pipelines beibehalten, wenn die Abfragefunktionalität das zentrale Alleinstellungsmerkmal ihres kommerziellen Produkts darstellt, Latenzen von unter 100 Millisekunden (p99) zwingend erforderlich sind, proprietäre hybride Suchalgorithmen oder multimodale Embeddings entwickelt werden müssen oder ein Betrieb in vollständig isolierten Air-Gapped-Umgebungen ohne Zugriff auf Cloud-LLMs gesetzlich vorgeschrieben ist.

Der unsichtbare Eisberg: Die "Day 2"-Herausforderungen eigener RAG-Pipelines

Viele technische Führungskräfte unterschätzen die Gesamtbetriebskosten (Total Cost of Ownership, TCO) einer Eigenentwicklung, da der anfängliche Prototyp weniger als 20 Prozent des Gesamtaufwands über den Lebenszyklus ausmacht. Die restlichen 80 Prozent entfallen auf kontinuierliche operative Reibungsverluste.

1. SaaS-Connector-Drift und Fehleranfälligkeit bei der Datenaufnahme

Die Anbindung von Enterprise-SaaS-Plattformen ist kein einmaliger API-Aufruf. Jeder Dienst bringt spezifische Fehlerquellen mit sich:

• Rate Limits und exponentielles Backoff: Slack und Notion verhängen strikte Ratenbegrenzungen bei Massenabfragen großer Workspaces, was widerstandsfähige verteilte Warteschlangen und Wiederholungslogiken erfordert.
• Webhook-Zuverlässigkeit: Webhooks von Drittanbietern verlieren bei Netzwerkstörungen Ereignisse, erfassen Rechteänderungen in tief verschachtelten Ordnern unzuverlässig und leiden unter ablaufenden OAuth-Tokens.
• Verarbeitung komplexer Dokumentformate: Das Extrahieren und Chunking von Inhalten aus Google Slides, relationalen Notion-Datenbanken, Excel-Tabellen mit mehreren Arbeitsblättern und eingescannten PDFs erfordert eine ständige Pflege von Parser-Bibliotheken.

2. Rechtevererbung und das Risiko von ACL-Datenlecks

Sicherheit beim Zugriff auf internes Unternehmenswissen duldet keine Fehler: Ein Entwickler darf keine Gehaltslisten der Geschäftsführung abfragen können, und ein Supportmitarbeiter darf keine geschützten Kundendaten (PII) einsehen. In einer eigenen Pipeline erfordert das Abgleichen von Identity-Provider-Gruppen (IdP wie Okta oder Microsoft Entra ID) mit granularen Zugriffsrechten (ACLs) über mehrere Tools hinweg eine eigens entwickelte Synchronisations-Engine. Ändern sich die Freigaben in Google Drive oder Notion, müssen die Metadaten in der Vektordatenbank unmittelbar aktualisiert werden. Schlägt die Metadatenfilterung bei Abfragen fehl, droht ein sofortiges Sicherheitsleck.

3. Re-Indizierungslatenz und verwaiste Datenfragmente

Unternehmensdokumente ändern sich täglich. In einer einfachen Vektorarchitektur müssen bei der Aktualisierung einer 50-seitigen Architekturspezifikation alte Chunks gelöscht, neue Chunks eingefügt und verwaiste Fragmente bereinigt werden. Verliert die Datenbank die Synchronität zum Originaldokument, liefert das LLM Halluzinationen auf Basis veralteter Richtlinien. Zudem erfordert jedes Upgrade des Embedding-Modells (etwa von text-embedding-ada-002 auf text-embedding-3-large) eine vollständige Neuindizierung des gesamten Dokumentenbestands im laufenden Betrieb.

4. Rasante Modellentwicklung und Orchestrierungsaufwand

Die führenden LLMs entwickeln sich monatlich weiter. Eine eigene Pipeline verlangt regelmäßige Refaktorisierungen des Orchestrierungscodes, um neue Kontextfenster, JSON-Ausgabeformate und Reasoning-Parameter von Anbietern wie OpenAI, Anthropic Claude, Google Gemini, Mistral und DeepSeek zu unterstützen.

5. Bereitstellung und Wartung von Nutzeroberflächen

Entwickler arbeiten in Slack, Terminal und GitHub; Fachbereiche nutzen Webbrowser und Ticketsysteme. Ein eigenes RAG-System zwingt das Team dazu, Slack-Bots, Web-Chat-Oberflächen mit Server-Sent Events (SSE), Quellenverweise und Authentifizierungsmechanismen selbst zu programmieren und instand zu halten.

Architekturüberblick: Was Dust als Managed Platform leistet

Dust ist als Betriebssystem für Unternehmensagenten konzipiert, das Teams vollständig von der Infrastruktur- und Integrationslast befreit.

Vollständig verwaltete Datenquellen und native Connectors

Dust bietet schlüsselfertige, native Anbindungen an Slack, Notion, Google Drive, Confluence, GitHub, Zendesk, Intercom, Snowflake und BigQuery.

• Automatisierter Dokumenten-Lebenszyklus: Eingehende Dokumente erhalten eine eindeutige document_id. Schreibvorgänge erfolgen als Upsert: Bei Updates werden veraltete Chunks im Vektorindex automatisch ersetzt, wodurch verwaiste Daten vermieden werden.
• Bereinigung und Chunking: Text wird von überflüssigen Leerzeichen bereinigt und semantisch anhand konfigurierter Token-Grenzwerte (max_chunk_size) zerlegt.
• Embedding-Infrastruktur: Standardmäßig wird OpenAIs text-embedding-3-large verwendet (Enterprise-Kunden können alternative Modelle anfordern). Bei Abfragen bettet Dust den Prompt ein, sucht relevante Vektoren, fasst Chunks nach Dokument zusammen und sortiert die Ergebnisse absteigend nach Relevanz.

Governance über Spaces und zweistufige Berechtigungsisolierung

Statt fragile dateibasierte Rechtestrukturen aus verschiedenen Tools mühsam nachzubauen, setzt Dust auf strukturierte Governance mittels Spaces (Räume):

• Open Spaces (Offene Räume): Für alle Mitglieder des Workspaces zugänglich; ideal für Unternehmensrichtlinien, Engineering-Handbücher und allgemeine Dokumentation. Enthält den standardmäßigen, unveränderlichen Bereich Company Data.
• Restricted Spaces (Eingeschränkte Räume): Zugriff ist auf bestimmte Personen oder über SCIM aus dem Unternehmens-IdP (Okta, Microsoft Entra ID) synchronisierte Gruppen beschränkt.
• Zweistufige Zugriffskontrolle:
  1. Agent zu Daten: Agenten können nur Datenquellen abfragen, die dem konfigurierten Space zugewiesen sind.
  2. Benutzer zu Agent: Benutzer können nur Agenten sehen und ausführen, wenn sie Mitglied des jeweiligen Space sind. Vertrauliche Daten gelangen somit niemals über Agenten-Antworten an unbefugte Kollegen.
• Dedizierte Service-Accounts: Für Google Drive und Notion empfiehlt Dust dedizierte Administrationskonten (wie dust-admin@firma.de). Dadurch können IT- und Sicherheitsabteilungen zentral prüfen und steuern, welche geteilten Laufwerke und Teamspaces synchronisiert werden.

Multi-Modell-Flexibilität und dynamisches Routing

Dust abstrahiert LLM-Anbieter hinter einer einheitlichen Oberfläche. Teams können Agenten ohne Programmieraufwand über 20+ Spitzenmodelle zuweisen (OpenAI GPT-4o, Anthropic Claude 3.5 und 3.7 Sonnet, Google Gemini 1.5 und 2.0, Mistral Large, DeepSeek). Administratoren können Modellzugriffsstufen und Beschränkungen des Denkaufwands (Reasoning effort) pro Gruppe festlegen, um Budgetüberschreitungen zu vermeiden.

Entwickler-Schnittstellen: REST APIs und MCP (Model Context Protocol)

Dust ist keine geschlossene No-Code-Plattform:

• Entwickler-API und OpenAPI 3.0: Bietet Endpunkte zur programmatischen Verwaltung von Datenquellen, zum Upsert von Text- und PDF-Dateien, zum Aufrufen von Agenten und zum Streamen von SSE-Events.
• Model Context Protocol (MCP) Unterstützung: Dust unterstützt standardmäßig MCP-Server (remote und clientseitig als Vorschau), wodurch Agenten sicher auf interne Microservices, Firmendatenbanken oder CI/CD-Pipelines zugreifen können.
• Trigger und automatisierte Workflows: Agenten können nach festen Zeitplänen (Cron) oder über externe Webhooks automatisiert ausgelöst werden.
• Transparenter Open-Core: Das Kernsystem von Dust ist auf GitHub öffentlich einsehbar (dust-tt/dust). Technische Architekten können die interne Implementierung auditieren und vermeiden proprietäre Vendor-Lock-ins.

Direkter Vergleich: Eigene In-House-Pipeline vs. Dust Managed Platform

Total Cost of Ownership (TCO): Die wirtschaftliche Rechnung

Bei der Entscheidung zwischen Eigenbau und Einkauf müssen technische Leiter die Software-Lizenzkosten den voll belasteten Entwicklergehältern und den Opportunitätskosten gegenüberstellen.

Szenario: Technologieunternehmen mit 150 Mitarbeitern (50 Entwickler)

Kosten der Eigenentwicklung und Instandhaltung

• Initiale Entwicklungsphase (4 Monate): Zwei Senior-Entwickler für Datenpipelines, Vektorindizes, Benchmarking und Slack-Integration. Bei Vollkosten von ca. 140.000 €/Jahr pro Entwickler entspricht dies rund 93.000 €.
• Laufende Wartung (jährlich): 0,75 Vollzeit-Entwickler für API-Anpassungen, Modellmigrationen und Datenbankbereinigung: 105.000 €/Jahr.
• Infrastruktur- und Modellkosten: Vektordatenbank (Pinecone/Qdrant Cloud), Rechenressourcen, Parsing-Tools und LLM-APIs: 15.000 € bis 25.000 €/Jahr.
• Gesamtkosten im ersten Jahr: ~213.000 € bis 223.000 €, mit jährlichen Folgekosten von über 120.000 €.

Kosten bei Einführung von Dust

• Business-Plan: Pro-Plätze für reguläre Nutzer ab 24 €/Monat (bei jährlicher Abrechnung), Max-Plätze für Power-User ab 120 €/Monat, inklusive monatlicher Nutzungskredite.
• Enterprise-Plan: Maßgeschneiderte Volumenpreise mit gepoolten Credits für den gesamten Workspace, unbegrenzte Connectors und MCP-Server, SCIM, dedizierte SLAs sowie EU-Datenresidenz.
• Jährliche Gesamtkosten: Machen nur einen Bruchteil des Jahresgehalts eines einzelnen Senior-Entwicklers aus.
• Strategischer Hebel: Zwei erfahrene Entwickler arbeiten vollständig am Kernprodukt, das direkten Unternehmensumsatz erwirtschaftet, anstatt interne Dokumentenscraper zu warten.

Entscheidungsmatrix: Wann welcher Weg der richtige ist

Dust wählen, wenn:

1. Unternehmenswissen über diverse SaaS-Tools verteilt ist: Spezifikationen, Besprechungsprotokolle und Richtlinien liegen in Slack, Notion, Google Drive, Confluence und GitHub.
2. Fachbereiche selbstständig Agenten erstellen sollen: Produktmanager, Support-Leiter und Operations-Teams sollen eigene RAG-Agenten per natürlicher Sprache und MCP konfigurieren können, ohne Entwicklertickets zu eröffnen.
3. Engineering-Ressourcen knapp sind: Die Plattform-Entwickler müssen sich auf geschäftskritische Produktmeilensteine konzentrieren.
4. Unternehmens-Compliance sofort gefordert ist: SOC 2, DSGVO-Konformität, SAML-SSO und Audit-Logs werden ab Tag eins verlangt.

Eigene In-House-RAG-Pipeline beibehalten, wenn:

1. Die RAG-Pipeline das kommerzielle Kernprodukt ist: Sie verkaufen eine spezialisierte juristische Suchmaschine, eine medizinische Diagnostik-Plattform oder ein Code-Analyse-Tool, bei dem die Abruflogik das geistige Eigentum Ihrer Firma darstellt.
2. Extreme Latenzanforderungen (<100 ms) bestehen: Dedizierte In-Memory-Vektorindizes oder Hardware-Beschleuniger müssen direkt in Transaktionssysteme eingebettet werden.
3. Vollständige Air-Gapped-Umgebungen vorliegen: Strenge Sicherheitsauflagen verbieten jede Kommunikation mit externen Cloud-SaaS- und LLM-Anbietern, sodass rein lokale Modelle (vLLM/Ollama mit On-Premise Milvus) zwingend sind.
4. Massenhafte öffentliche Daten mit einheitlichen Rechten vorliegen: Indizierung von 50 Millionen öffentlichen Produktkatalogen, bei denen nutzerbasierte SaaS-Preise unrentabel sind und keine granularen Zugriffsrechte benötigt werden.

Das hybride Architekturmuster: Der pragmatische Mittelweg

Führende Engineering-Organisationen setzen zunehmend auf eine pragmatische Kombination:

• Internes Unternehmenswissen über Dust: Dust übernimmt das Onboarding, die Dokumentensuche und die operative Zusammenarbeit über alle Standard-SaaS-Tools hinweg.
• Proprietäre Systeme angebunden über MCP: Statt eine RAG-Infrastruktur neu zu erfinden, entwickeln die Ingenieure schlanke MCP-Server oder REST-APIs für interne Datenbanken und binden diese an Dust-Agenten an. Dust übernimmt Authentifizierung, Multi-Modell-Routing und UI, während sich das interne Team ausschließlich auf hochwertige Fachdaten konzentriert.

Indem Engineering-Teams die unproduktive Routinearbeit der Connector- und Rechtesteuerebene an eine Plattform abgeben, sichern sie ihren strategischen Fokus für wertschöpfende Produktentwicklung.

Referenzen

• Dust Pricing: Business and Enterprise Plans for AI Agents
• Understanding Retrieval Augmented Generation (RAG) and the search method in Dust
• Chunks and Documents
• Datasources
• Access Controls and Permissions
• Spaces management
• Google Drive Connection
• Notion Connection
• The economics of multiplayer AI