Some Assembly Required

Der Newsletter für technische Entscheider, Business-Strategen und KI-Interessierte.

Heute auf der Setlist: Warum „gekauft“ bei RAG nicht automatisch „gelöst“ heißt.

🎚️ Soundcheck

An Verantwortliche in RAG-basierten Projekten wird regelmäßig das Versprechen herangetragen, mit Plattform X sei das RAG-Problem gelöst. In Wirklichkeit zeichnet sich ein anderes Bild ab, denn gekauft ist nicht gelöst, und gerade bei RAG-Projekten treten die Grenzen dieses Versprechens regelmäßig zutage. Diese Ausgabe erklärt die Ursachen, aber auch die Frage, die stattdessen im Mittelpunkt stehen sollte.

🎤 Main Set: Was man wirklich kauft

Der Konflikt zwischen Standardisierung und Flexibilität

Fertigsysteme bewegen sich zwischen zwei Extremen. Geschlossene Turnkey-Produkte ermöglichen einen schnellen Start mit vordefinierten Workflows, sind aber merklich unflexibel, sobald die Anforderungen an Chunking, Retrieval-Strategie, Reranking oder Evaluation von der Standardkonfiguration abweichen, und sie bringen natürlich oft einen Vendor Lock-in mit sich. Flexible Plattformen erlauben nahezu beliebige Anpassungen, verlagern damit aber die Konfiguration von Chunking-Strategien, Embedding-Modellen, hybrider Suche, Reranking, Evaluation-Metriken und Zugriffskontrolle vollständig auf den Anwender. Die Flexibilität ist in diesem Fall nicht die Lösung, sondern die tatsächlich notwendige Arbeit.

Das eigentliche Problem liegt nicht in der Infrastruktur

Die ressourcenintensiven Teile von RAG waren nie die technisch zugrunde liegenden Komponenten, denn Vektor-Stores und die Anbindung von Sprachmodellen sind durchaus keine Probleme. Die kritischen Herausforderungen liegen viel mehr hier:

• Retrieval-Qualität und Genauigkeit
• Dokumenten-Fragmentierung und Chunking-Strategien
• Context Engineering und Prompt-Design
• Aufbau und Pflege der Wissensbasis
• Evaluation und Metriken für den konkreten Anwendungsfall
• Domänenmodellierung
• Zugriffskontrolle und berechtigungsbewusstes Retrieval, häufig erschwert durch asynchron und stark zeitverzögert synchronisierte Berechtigungen sowie das ACL-Mapping zwischen Quellsystemen und Index

Oft liefert eine Plattform nur die Basis-Infrastruktur (Vektordatenbank, Anbindung an Sprach-/Embedding-Modelle etc.). Bei der flexiblen Konfiguration der oben genannten Punkte wird es dann schon schwierig. Selbst große Plattformen wie Microsofts Azure AI Search haben bis vor kurzem keinerlei Konfigurationen zugelassen und alles mit BM25 Hybrid Search gelöst. Das ist oft sicherlich ausreichend genug für simple semantische Suchaufgaben, bei vielen speziellen Domänen aber ganz und gar nicht. Hier zeigt sich aktuell, mit welchem Aufwand die wichtigsten Stellen flexibilisiert werden.

🥁 Track 2: Die Kostenrechnung

Die Kosten fallen zweifach an, erstens für die Plattform selbst in Form von Lizenz- oder Nutzungsgebühren, zweitens für die Implementierung, also Konfiguration, Datenvorbereitung, Evaluation und laufende Wartung. Eine Plattform reduziert den Aufwand für standardisierte Komponenten, die domänenspezifische Arbeit bleibt jedoch bestehen und entfällt nicht durch den Kauf.

Zusätzliche Kostenrisiken:

• Vendor Lock-in und fehlende Portabilität
• Nutzungsbasierte Preismodelle, die mit dem Volumen skalieren
• Systeme, die für alle Fälle flexibel sind, sind für den konkreten Fall selten optimiert

Blueprint-Architekturen

Standard-RAG-Referenzmodelle bieten Orientierung, führen als universelle Lösung jedoch in die Irre. Ein One-size-fits-all existiert nicht, und die geeignete Architektur richtet sich nach den konkreten Anwendungsfällen.

🎯 Encore: Der eine Gedanke für Entscheider

Die zentrale Entscheidungsfrage lautet nicht, welche Plattform gekauft wird, sondern welche Komponenten undifferenzierte Standardtechnologie sind, die lizenziert werden sollten, und welche den domänenspezifischen Kern bilden, der selbst kontrolliert werden muss.

Kauf die Standardtechnologie und behalte den Differenzierer in eigener Hand. Eine Plattform ist ein Ausgangspunkt, kein Endzustand, und der Verweis auf einen erfolgten Kauf ersetzt keine Architektur-Strategie.

💿 B-Side

Anti-Pattern: Eine RAG-Plattform einkaufen und erwarten, dass Retrieval-Qualität und Wissenspflege automatisch enthalten sind. Die teuersten Projekte sind jene, in denen sich nach dem Kauf zeigt, dass die eigentliche Arbeit erst beginnt, nun aber mit zusätzlichen Plattformkosten.

Vorgehen vor dem Kauf:

• Einen Evaluation-Datensatz mit den echten, kritischen Anwendungsfällen erstellen
• Kandidatensysteme anhand dieser Metriken testen, nicht anhand von Demos des Anbieters
• Den Implementierungsaufwand getrennt von den Lizenzkosten kalkulieren
• Exit-Szenarien und Datenportabilität prüfen

---

Das war Rag'n'Roll #007. Die nächste Ausgabe widmet sich der Observability agentischer Systeme, also der Frage, warum bei Agenten nicht nur das Ergebnis zählt, sondern die nachvollziehbare Kette aus Reasoning, Tool-Aufrufen und Kosten pro Schritt.

Weiterleiten erwünscht🤘