Teams, die KI-Funktionen für B2B-SaaS entwickeln, stoßen früh in der Entwicklung auf denselben architektonischen Entscheidungspunkt. Das Modell funktioniert gut in einem Notebook. Es liefert plausible Antworten auf Testdaten. Dann verlangsamt sich das Projekt bei einer folgenschwereren Frage: Sollte die Funktion Kontext zur Abfragezeit abrufen, das Modell mit Domänendaten feinabstimmen oder sich auf deterministische Logik im Code verlassen?

Die falsche Wahl scheitert meist auf bekannte Weise. Eine RAG-Pipeline, die für eine Funktion verwendet wird, die eigentlich eine konsistente Formatierung erforderte, kann bei Randfällen halluzinieren und die Token-Kosten in die Höhe treiben. Ein feinabgestimmtes Modell, das auf wöchentlich wechselnde Daten angewendet wird, kann schnell an Genauigkeit verlieren. Workflow-Logik, die dort eingesetzt wird, wo tatsächlich ein Verständnis natürlicher Sprache erforderlich ist, kann zu einer anfälligen Regel-Engine werden, die ständige manuelle Aktualisierungen erfordert, wenn sich das Geschäft weiterentwickelt.

Diese Fehler treten oft zwischen Pilotphase und Produktion auf. In den meisten Fällen ist die Ursache dieselbe: Das Team hat sich für eine Architektur entschieden, bevor es die Anforderungen an Aktualität, Konsistenz, Latenz und Prüfbarkeit definiert hat. Der bessere Ansatz ist, diese Anforderungen zuerst zu bewerten und dann die Architektur an die Funktion anzupassen, anstatt umgekehrt.

Dieser Artikel erklärt, wo RAG, Fine-Tuning und Workflow-Orchestrierung jeweils passen, wo jeder Ansatz an seine Grenzen stößt und wie man den richtigen Ansatz für eine spezifische B2B-SaaS-Funktion auswählt. Ziel ist es, Produkt- und Engineering-Führungskräften einen praktischen Entscheidungsrahmen zu geben, bevor die Integrationsarbeit beginnt.

Wann RAG die richtige architektonische Wahl ist

RAG ist die richtige Wahl, wenn eine Funktion Fragen anhand von Daten beantworten muss, die nicht eingefroren werden können. Dazu gehören mandantenspezifische Konfigurationen, interne Dokumentenbibliotheken, täglich wechselnde Preisregeln und Compliance-Aufzeichnungen, die nach unvorhersehbaren Zeitplänen aktualisiert werden. Wenn das zugrunde liegende Wissen schneller wechselt, als ein Modell neu trainiert oder bereitgestellt werden kann, ist der Abruf der Ansatz, der Schritt hält.

Auf praktischer Ebene funktioniert RAG auf einfache Weise. Unternehmensinhalte werden in Vektor-Embeddings umgewandelt und in einem durchsuchbaren Index gespeichert. Wenn eine Benutzeranfrage eingeht, ruft das System die relevantesten Textabschnitte ab und übergibt sie dem LLM als Kontext zusammen mit der Anfrage. Die Gewichte des Modells bleiben fest. Das Wissen bleibt extern und austauschbar. Diese Trennung macht RAG operativ flexibel: Das Team aktualisiert den Index, nicht das Modell.

Wissen außerhalb des Modells zu halten, ist auch einer der größten Vorteile von RAG in regulierten Umgebungen. Da jede Antwort auf die vom Retriever ausgewählten Quelldokumente zurückgeführt werden kann, können Teams eine prüfbare Verbindung zwischen der Antwort des Systems und den verwendeten Informationen herstellen. Für B2B-Produkte, die unter DSGVO, HIPAA oder dem EU AI Act betrieben werden, ist das in praktischer Hinsicht wichtig. Wenn ein Mandant die Löschung von Daten beantragt, können die Datensätze aus dem Index entfernt werden. Das Modell selbst hat diese Daten nie absorbiert, sodass keine Unklarheit darüber besteht, ob sie die Ausgaben noch beeinflussen. Im Gegensatz dazu wird die verifizierte Entfernung zu einem Governance-Problem, wenn Kundendaten durch Fine-Tuning in die Modellgewichte eingearbeitet wurden.

RAG bringt jedoch Kompromisse mit sich, die im Voraus verstanden werden müssen.

Der erste Punkt ist die Abrufqualität. Ein RAG-System ist nur so gut wie die Textabschnitte, die es abruft. Wenn das Chunking wichtige Kontexte falsch aufteilt oder das Embedding-Modell domänenspezifische Terminologie nicht gut darstellt, kann der Retriever falsche Informationen liefern. Das LLM kann dann eine Antwort produzieren, die fundiert und überzeugend aussieht, aber dennoch falsch ist. In der Produktion ist diese Art von Fehler schwer zu erkennen, da die Antwort immer noch glaubwürdig aussieht. Die Diagnose erfordert die Verfolgung der Abrufschicht und nicht der Modellschicht, was bedeutet, dass Teams Beobachtbarkeit und Tools benötigen, die viele erst nach dem ersten Vorfall entwickeln.

Der zweite Kompromiss ist die Latenz. Der Abruf fügt ungefähr 50 bis 300 Millisekunden Overhead pro Abfrage. Für interne Wissensassistenten oder Dokumenten-Q&A-Funktionen mag das vernachlässigbar sein. Für Erlebnisse, die näher an Echtzeit liegen und in großem Maßstab betrieben werden, muss dieser Overhead gegen die Produktanforderung bewertet werden.

Der dritte Punkt ist die Kostenprognostizierbarkeit. RAG erhöht die Token-Kosten pro Abfrage, da der abgerufene Kontext in jeden Prompt injiziert wird. Je mehr Inhalt der Retriever abruft, desto größer wird der Prompt und desto teurer ist die Anfrage. Im Gegensatz zu einem feinabgestimmten Modell, bei dem die Prompt-Größe klein und konsistent bleiben kann, steigen die RAG-Kosten mit dem Abrufvolumen. Bei Multi-Tenant-Produkten, bei denen die Abfragekomplexität je nach Kunde erheblich variieren kann, macht dies die Budgetierung weniger vorhersehbar.

Diese Kompromisse sind handhabbar, stellen aber dennoch echte operative Verpflichtungen dar. Teams sollten sie berücksichtigen, bevor sie die Architektur festlegen. 

Wann Fine-Tuning besser geeignet ist

Fine-Tuning ist am nützlichsten, wenn es nicht darum geht, was das Modell weiß, sondern wie es sich verhält. Viele Teams greifen zunächst zum Fine-Tuning, weil sie davon ausgehen, dass sie dem Modell ihr Domänenwissen beibringen müssen. In diesem Kontext ist das der falsche Grund. Im B2B-SaaS ist Fine-Tuning die bessere Wahl, wenn die Anforderung eine strukturell konsistente Ausgabe über eine große Anzahl von Randfällen hinweg ist, die Prompt Engineering allein nicht zuverlässig bewältigen kann. Das kann strukturiertes JSON für nachgelagerte Dienste, vorhersehbare Antwortlängen für die UI-Konsistenz, erforderliche Domänen-Terminologie oder stabile Schlussfolgerungsmuster umfassen, die das Vertrauen der Benutzer im Laufe der Zeit unterstützen.

Der Reiz liegt im Praktischen: geringere Latenz, kleinere Prompts und besser vorhersehbare Kosten pro Abfrage. Ohne einen Abrufschritt ist die Inferenzlatenz geringer. Ohne injizierten Kontext bleiben Prompts klein und konsistent. Das macht die Kosten pro Abfrage leichter modellierbar, was besonders wichtig ist, wenn KI-Funktionen in einem Multi-Tenant-Produkt bepreist werden. Bei RAG variieren die Kosten mit dem Abrufvolumen. Beim Fine-Tuning können die Kosten direkter am Abfragevolumen modelliert werden.

Die größere Belastung zeigt sich vor und nach der Bereitstellung.

Fine-Tuning erfordert Datenkuratierung, was bedeutet, einen hochwertigen, gelabelten Datensatz entweder durch monatelange manuelle Arbeit oder eine strukturierte Pipeline zusammenzustellen, die das Team über die Zeit pflegt. Es erfordert auch eine Evaluierungsinfrastruktur. Teams müssen beweisen, dass das abgestimmte Modell das Basismodell mit einem starken Prompt-Design tatsächlich übertrifft. Ohne diesen Vergleich ist es leicht, in ML-Overhead zu investieren, nur um festzustellen, dass ein besseres Prompting den größten Nutzen gebracht hätte.

Es besteht auch ein Risiko der Neuschulung. Jeder Neuschulungszyklus kann das Modell zu stark einschränken, wodurch die Leistung bei der Zielaufgabe verbessert, aber die Leistung bei angrenzenden Anfragen, die Benutzer weiterhin erwarten, dass das Modell sie bearbeitet, geschwächt wird. Diese Verschlechterung verstärkt sich mit der Zeit und erfordert spezielle Benchmarks zu ihrer Erkennung.

Governance ist ein weiterer wichtiger Aspekt. Wenn Daten eines Kunden in den Trainingsdatensatz aufgenommen wurden, sind die Muster dieses Kunden in den Gewichten des Modells verankert. Macht dieser Kunde später seine DSGVO-Löschrechte geltend, ist es schwierig zu beweisen, dass seine Daten die Ausgaben nicht mehr beeinflussen. In der Praxis besteht die Abhilfe darin, das Modell von Grund auf mit einem bereinigten Datensatz neu zu trainieren. In einem Multi-Tenant-Produkt ist das keine nachträgliche Bereinigungsaufgabe. Es ist ein Compliance-Prozess, der vor Beginn des Trainings konzipiert werden muss.

Feinabstimmung ist daher die richtige Wahl, wenn Verhaltenskonsistenz nicht verhandelbar ist und das zugrunde liegende Wissen stabil bleibt. Die eigentliche Frage ist, ob dieser Grad an Infrastruktur- und Governance-Engagement gerechtfertigt ist, oder ob ein gut konzipiertes RAG-System mit starkem Prompt Engineering nahe genug herankommt.

Wo Workflow-Logik und Orchestrierung am wichtigsten sind

Viele KI-Funktionen in B2B-SaaS werden fragil, weil Teams Modellaufrufe an Stellen platzieren, wo deterministischer Code besser funktionieren würde. Workflow-Logik und Orchestrierung existieren, um diese Grenze zu definieren. Sie bestimmen, wann das LLM aufgerufen wird, auf welche Daten es zugreifen kann, was mit der Ausgabe geschehen darf und was das System tut, wenn das Ergebnis nicht sicher verwendet werden kann.

Viele Teams leiten zu viel über das Modell, einfach weil die Funktion als KI bezeichnet wird, selbst wenn deterministische Logik günstiger und zuverlässiger wäre. Aufgaben wie die Klassifizierung anhand einer bekannten Taxonomie, das Routing basierend auf strukturierten Metadaten oder die Anwendung etablierter Geschäftsregeln werden oft besser mit deterministischer Logik gehandhabt. In diesen Fällen ist Code schneller, günstiger und einfacher zu debuggen als ein LLM-Aufruf.

Der Schlüssel ist, Aufgaben, die wirklich Sprachverständnis benötigen, von Aufgaben zu trennen, die lediglich vorhersagbaren Code erfordern.

Orchestrierung wird unerlässlich, wenn Teams das LLM in Kontrollen einbetten müssen, die sie durchsetzen, testen und prüfen können. Dazu gehören die Validierung und Bereinigung von Eingaben vor der Inferenz, die Überprüfung von Ausgaben anhand von Geschäftsregeln, bevor sie den Benutzer erreichen, die Definition von Fallback-Verhalten für Modellantworten mit geringer Konfidenz oder unbrauchbaren Antworten, die Begrenzung der Anzahl von Modellaufrufen, die eine einzelne Benutzeraktion auslösen kann, und die Sicherstellung, dass das Modell nur Daten erhält, auf die der anfragende Benutzer zugreifen darf. Dies sind keine Kontrollen, die allein durch Prompt-Anweisungen zuverlässig durchgesetzt werden können.

Deterministische Orchestrierung hat jedoch Kosten. Sie erfordert eine vorherige Spezifikation, was die frühe Entwicklung verlangsamen kann. Komplexe Regelsysteme können mit der Produktentwicklung zu einer eigenen Wartungslast werden. Und die Workflow-Logik kann mehrdeutige Eingaben oder offenes Denken nicht eigenständig verarbeiten, genau hier gehört das LLM noch hin. Das Ziel ist nicht, Modellaufrufe vollständig zu eliminieren. Es geht darum sicherzustellen, dass jeder Modellaufruf bewusst, begrenzt und von Logik umgeben ist, die das Team kontrolliert.

In vielen Produktionsarchitekturen trägt die Orchestrierungsschicht letztendlich mehr operatives Gewicht als das Retrieval-System oder das feinabgestimmte Modell. Es ist die Schicht, in der Teams die Regeln durchsetzen, die eine KI-Funktion sicher für den Einsatz machen.

Ein praktischer Entscheidungsrahmen

Diese Ansätze lösen unterschiedliche Probleme. In der Praxis verlassen sich die meisten Produktionsfunktionen nicht nur auf einen Ansatz. Die architektonische Frage ist meist spezifischer: welche Teile der Funktion Retrieval benötigen, welche Teile Verhaltenskonsistenz erfordern und welche Teile in deterministischem Code bleiben sollten?

Ein praktischer Rahmen beginnt mit fünf Fragen. Nicht jede Frage wird auf jede Funktion gleichermaßen zutreffen, aber zusammen schaffen sie die Disziplin, die Teams davor bewahrt, sich zu früh auf eine Architektur festzulegen.

1. Benötigt diese Aufgabe überhaupt ein LLM?

Dies ist oft die erste Frage, die Teams stellen sollten, und diejenige, die sie am häufigsten überspringen. Routing basierend auf strukturierten Metadaten, Klassifizierung anhand einer bekannten Taxonomie und die Anwendung kodifizierter Geschäftsregeln gehören in die Orchestrierungsschicht. Jeder unnötige LLM-Aufruf verursacht Kosten, Latenz und einen weiteren Fehler, der behoben werden muss. Der Ausgangspunkt ist, die Grenze zu definieren zwischen dem, was natürliches Sprachverständnis erfordert, und dem, was im Code bleiben sollte.

2. Wie oft ändert sich das Wissen hinter dieser Funktion?

Wenn sich das Wissen täglich ändert oder je nach Tenant variiert, ist Retrieval die bessere Wahl. Wenn das Wissen über längere Zeiträume stabil ist und die Anforderung an Konventionen, Formatierungsregeln oder Denkweisen gebunden ist, wird Feinabstimmung praktikabler. Viele Funktionen liegen zwischen diesen Extremen: stabile Verhaltensanforderungen kombiniert mit dynamischem, mandantenspezifischem Wissen. In diesen Fällen kann eine hybride Architektur sinnvoll sein, wobei Feinabstimmung oder strukturiertes Prompting das Verhalten und RAG das Wissen verwalten.

3. Was muss das Team aufbauen und pflegen?

Jede Option erzeugt eine andere langfristige Betriebsbelastung. RAG erfordert eine Embedding-Pipeline, Chunking-Strategie, Retrieval-Evaluierung und Indexpflege. Feinabstimmung erfordert gelabelte Datensätze, Benchmarks, Neuschulungszyklen und ML-Expertise. Workflow-Orchestrierung erfordert eine vorherige Spezifikation und laufende Regelwartung. Die richtige Entscheidung hängt nicht nur von der technischen Eignung ab. Es geht auch darum, was das Team in seinem aktuellen Stadium zuverlässig betreiben kann.

4. Welche regulatorischen und Governance-Risiken bestehen?

Wird das Produkt unter DSGVO, HIPAA oder kundenspezifischen Datenverarbeitungsanforderungen betrieben, muss die Architektur Löschbarkeit und Prüfbarkeit von Grund auf unterstützen. RAG bietet den saubersten Ansatz, da Mandantendaten im Index verbleiben und direkt entfernt werden können. Eine Feinabstimmung mit Mandantendaten schafft Governance-Schulden, die mit der Zeit wachsen. Die Workflow-Logik liefert deterministische Prüfprotokolle, die Compliance-Teams vor Aufsichtsbehörden verwenden können. Diese Einschränkungen müssen vor Beginn jeglicher Integrationsarbeiten erfasst werden.

5. Kann das Team einfacher beginnen und später aufstocken?

Einige Funktionen, die RAG oder Feinabstimmung zu erfordern scheinen, können zunächst mit starkem Prompting, eingebettet in deterministische Orchestrierung, eingeführt werden. Der Start mit einer einfacheren Implementierung ermöglicht es dem Team, aus der realen Nutzung zu lernen, bevor es sich zu einer aufwendigeren Infrastruktur verpflichtet. In vielen Fällen ist die verantwortungsvolle Vorgehensweise zuerst Prompt Engineering, dann RAG und Feinabstimmung nur dort, wo Daten und Anforderungen dies rechtfertigen.

Wie das Framework in der Praxis funktioniert

Aktuelle Fallstudie von Codebridge zeigt, wie diese architektonischen Entscheidungen in einem System zusammenwirken können. In einer KI-gestützten Rekrutierungsplattform für ein US-amerikanisches Unternehmen, das monatlich 1.500 bis 3.000 Ingenieurbewerbungen bearbeitet, kombinierte die Lösung alle drei Ansätze, anstatt eine einzige Methode für alles zu verwenden.

Die Orchestrierungsschicht trug das größte operative Gewicht. Ein zentraler Orchestrator, der auf LangGraph basierte, koordinierte fünf spezialisierte Agenten für Sourcing, Screening, Bewertung, Interviewanalyse und Onboarding. Vertrauensbasierte Weiterleitung ermöglichte autonome Entscheidungen nur, wenn das Vertrauen 90 % überstieg. Grenzfälle wurden automatisch an menschliche Recruiter eskaliert, und Kandidaten in der Endphase wurden niemals vom System abgelehnt. Diese Steuerungslogik befand sich in deterministischem Code, nicht in Prompts.

RAG verankerte die Agenten in den tatsächlichen Einstellungsstandards des Unternehmens. Technische Anforderungen pro Rolle, annotierte Beispiele für starke und schwache Kandidatenantworten sowie interne Bewertungskriterien wurden in einem Retrieval-Index gespeichert. Jeder Agent fragte diesen Index zur Inferenzzeit ab, was verhinderte, dass das System Bewertungskriterien erfand, die im Unternehmensprozess nicht existierten. Wenn sich die Einstellungsstandards änderten, aktualisierte das Team den Index, anstatt das Modell neu zu trainieren.

Verhaltenskonsistenz wurde durch strukturierte Ausgabeanforderungen gewährleistet. Bewertungsagenten erstellten personalisierte Testaufgaben in einem vorhersehbaren Format, während Interview-Agenten strukturierte Debriefing-Berichte mit konsistenten Abschnitten wie technischer Tiefe, Sprachmusteranalyse und Warnsignalen (Red Flags) erstellten, die alle in einem Recruiter-Dashboard dargestellt wurden. Die Formatierungs- und Argumentationsmuster blieben über Tausende von Kandidaten hinweg stabil. Das ist die Art von Problem, die Feinabstimmung lösen soll, obwohl das Team es in diesem Fall durch strukturiertes Prompting und Orchestrierung erreichte.

Das System reduzierte die gesamte Einstellungszeit von 24 auf 10–12 Tage. Der manuelle Überprüfungsaufwand für Ingenieure sank um 60 %. Die Antwortzeit der Kandidaten verkürzte sich von über 24 Stunden auf unter 2 Minuten. Das System erreichte innerhalb des ersten Jahres die Gewinnschwelle.

Fazit

Es geht nicht darum, einen besseren Ansatz zu wählen. Vielmehr sollte jeder Ansatz den Teil des Systems übernehmen, für den er tatsächlich geeignet ist. Retrieval verarbeitet dynamisches Wissen. Orchestrierung übernimmt Steuerung, Routing und Governance. Das Team gewährleistete Verhaltenskonsistenz durch die Durchsetzung strukturierter Ausgabeanforderungen.

Das Fünf-Fragen-Framework ist am nützlichsten, bevor das Team Integrationscode schreibt. Es bietet Produkt- und Engineering-Leitern eine Möglichkeit, jede Komponente einer Funktion dem Ansatz zuzuordnen, der ihren tatsächlichen Anforderungen entspricht, und nicht dem, der sich einfach am meisten nach dem Bau von KI anfühlt.

Teams geraten in der Regel in Schwierigkeiten, wenn sie sich für eine Architektur entscheiden, bevor sie verstehen, was jede Schicht der Funktion erfordert. Teams, die zuverlässige KI-Funktionen in der Produktion bereitstellen, behandeln Retrieval, Verhaltenssteuerung und deterministische Logik als separate Designentscheidungen und nutzen dann die Orchestrierung, um sie zusammenzuhalten.