RAG, Chatbot oder AI-Agent? Was Ihr Unternehmen wirklich braucht

Chatbot, RAG, LLM-Pipeline und KI-Agent sind nicht vier Versionen derselben Lösung. Sie können ähnliche Modelle verwenden, erfüllen aber völlig unterschiedliche Aufgaben.

Zunächst muss geklärt werden, ob das System antworten, suchen, verarbeiten oder handeln soll. Erst danach lohnt es sich, ein Modell, eine Vektordatenbank und die übrigen Technologiekomponenten auszuwählen.

Es fängt meistens mit einem Chatbot an

Immer mehr Gespräche über KI-Einführung beginnen ähnlich:

• Wir wollen einen Chatbot.

Manchmal braucht das Unternehmen tatsächlich einen Chatbot. Nach einigen Fragen stellt sich jedoch oft heraus, dass das System Dokumente lesen, aktuelle Daten aus dem ERP prüfen, Informationen aus mehreren Quellen analysieren, frühere Entscheidungen berücksichtigen oder mehrstufige Abläufe ausführen soll.

Dann sprechen wir nicht mehr über einen einfachen Chatbot.

Das Problem ist, dass Chatbot, RAG, LLM-Pipeline und KI-Agent heute in einen Topf geworfen werden. Alle können ein Sprachmodell nutzen. Alle können eine gesprächsähnliche Oberfläche haben. Aus Sicht des Anwenders können sie sogar ähnlich aussehen.

Der Unterschied beginnt tiefer.

Bei den Daten, die sie verwenden. Beim Prozess, den sie ausführen. Bei den Werkzeugen, auf die sie zugreifen können. Und vor allem bei der Verantwortung, die wir von ihnen erwarten.

Deshalb ist es besser, anstatt mit der Frage „Welches Modell sollen wir wählen?" zu beginnen, zuerst eine einfachere zu beantworten:

Soll das System antworten, suchen, verarbeiten oder handeln?

Ein einfacher Chatbot bedient ein konkretes Szenario

Der einfachste Bot muss nicht auf das gesamte Unternehmenswissen zugreifen können. Er muss auch nicht jede Frage verstehen, die ein Benutzer stellen könnte.

Er muss eine definierte Aufgabe erledigen.

Er kann die häufigsten Fragen beantworten, bei der Auswahl einer Dienstleistung helfen, Kontaktdaten erfassen, den Benutzer durch ein Formular führen oder das Gespräch an einen Menschen übergeben.

Das kann immer noch eine gute Lösung sein.

Nicht jeder Prozess braucht eine aufwendige KI-Architektur. Wenn der Fragenbereich begrenzt ist, sich Antworten selten ändern und ein Fehler keine schwerwiegenden Folgen hat, wird ein einfacher Bot oft schneller, günstiger und leichter zu warten sein.

Problematisch wird es, wenn wir erwarten, dass er auf Basis von Hunderten von Dokumenten, einem sich ändernden Produktkatalog oder aktuellen Daten aus internen Systemen antwortet.

In diesem Fall reicht ein gut geschriebener Prompt nicht mehr aus.

RAG gibt dem Modell Zugriff auf Unternehmenswissen

RAG, also Retrieval-Augmented Generation, wird oft als Kombination eines Sprachmodells mit einer Dokumentendatenbank beschrieben.

Das stimmt, aber nur teilweise.

Der entscheidende Punkt ist, dass das Modell nicht ausschliesslich auf Wissen aus seinem Training angewiesen ist. Bevor es eine Antwort generiert, durchsucht das System die unternehmenseigenen Quellen und übergibt die relevanten Informationen als Kontext.

Diese Quellen können Dokumente sein, aber auch eine SQL-Datenbank, ein Produktkatalog, ein CRM, ein ERP, interne APIs oder mehrere verschiedene Systeme gleichzeitig.

Die Retrieval-Schicht kann semantisch arbeiten - zum Beispiel über eine Vektordatenbank - oder deterministisch, wenn das System eine SQL-Abfrage ausführt oder einen konkreten Wert über eine API abruft.

Bei grösseren und vielfältigeren Wissensdatenbanken wird häufig auch hybride Suche eingesetzt. Sie kombiniert semantische Ähnlichkeit mit klassischer Stichwortsuche nach exakten Begriffen, Eigennamen, Produktcodes oder anderen Kennzeichnungen.

In der Praxis sieht der Prozess ungefähr so aus:

1. Der Benutzer stellt eine Frage,
2. das System bestimmt, wo nach der Antwort gesucht werden soll,
3. es ruft die relevanten Informationen ab,
4. übergibt sie an das Modell,
5. das Modell generiert eine Antwort auf Basis der abgerufenen Daten,
6. das System kann Quellen oder bestätigende Auszüge anfügen.

Ein solcher Assistent kann Fragen zur technischen Dokumentation, zu Verfahren, zum Angebot, zu Produkten, zu Vorschriften oder zum internen Unternehmenswissen beantworten.

In einem gut gestalteten System geht es jedoch nicht nur darum, Text zu finden, der semantisch ähnlich zur Frage ist.

Den aktuellen Lagerbestand holt man besser direkt aus dem ERP. Den Preis aus dem System, das die Quelle der Wahrheit ist. Dokumentation kann semantisch durchsucht werden, während Beziehungen zwischen Objekten manchmal einen Graphen oder eine strukturierte Abfrage erfordern.

RAG bedeutet also nicht automatisch „PDFs plus Vektordatenbank".

Es ist eine Methode, dem Modell den richtigen Kontext zu liefern. Die Retrieval-Methode selbst hängt von den Daten und der Frage ab.

Ein gutes Beispiel ist das System BLUP-FLOCK, bei dem die klassische Dokumentensuche nicht ausreichte. Das System musste mit genealogischen Daten und Beziehungen über Tiergenerationen hinweg arbeiten, weshalb ein eigener Kontextabrufmechanismus und eine deterministische Berechnungsschicht erforderlich waren.

Mehr über diese Architektur haben wir in unserem Artikel über produktive KI-Integrationen, RAG und LLM-Pipelines beschrieben.

Eine LLM-Pipeline muss mit niemandem sprechen

Nicht alle auf Sprachmodellen basierenden Systeme haben eine Chat-Oberfläche.

Manchmal will der Benutzer nicht mit einer KI sprechen. Er will, dass das System die Arbeit erledigt und ein fertiges Ergebnis liefert.

Eine LLM-Pipeline kann ein Dokument abrufen, seinen Typ erkennen, die benötigten Informationen extrahieren, sie gegen Regeln prüfen, das Ergebnis im CRM speichern und den Vorgang an die nächste Prozessstufe übergeben.

Sie kann Angebotsanfragen analysieren, Nachrichten klassifizieren, Produktdaten ordnen, Zusammenfassungen erstellen oder Inhalte vor der Veröffentlichung verarbeiten.

Die einzelnen Schritte sind in der Regel vordefiniert.

Das Modell übernimmt den Teil der Arbeit, der Sprachverständnis erfordert, aber der Gesamtprozess muss nicht selbst entscheiden, was als Nächstes zu tun ist. Wenn ein Dokument korrekt klassifiziert wurde, geht es zu Schritt zwei. Wenn nicht, löst das System eine Validierung aus oder übergibt den Fall an einen Menschen.

Das ist ein wichtiger Unterschied.

Eine Pipeline kann ein LLM nutzen, muss aber kein Agent sein.

Ein KI-Agent bekommt eine Rolle, ein Gedächtnis und Werkzeuge

Ein Agent beginnt dort, wo das System Daten nicht nur entlang eines einzigen Pfads verarbeitet, sondern die Situation bewerten und den nächsten Schritt wählen muss.

Bei unseren Marketing-Agenten ist der eigentliche Modellaufruf der am wenigsten interessante Teil.

Der Agent muss wissen, für welches Unternehmen er arbeitet. Dessen Ziele kennen, die Geschichte früherer Entscheidungen und die Einschränkungen. Zugriff auf die richtigen Daten haben. Verstehen, was er anfassen darf und was er nicht verändern darf.

Ein Agent kann beispielsweise Daten aus Google Ads abrufen und einen deutlichen Kostenanstieg erkennen. Eine Veränderung eines Kennwerts bedeutet jedoch noch nicht, dass etwas schiefgelaufen ist.

Das System kann prüfen, ob sich die Nachfrage verändert hat, ob die Konversionszahlen gesunken sind, ob die Traffic-Qualität nachgelassen hat oder ob die Landingpage schlechter performt. Es kann frühere Empfehlungen lesen und feststellen, dass eine ähnliche Situation einen Monat zuvor aufgetreten war. Erst dann erstellt es seine Schlussfolgerung.

Nicht nur:

CPC ist um 18% gestiegen.

Sondern eher:

CPC ist gestiegen, aber das Konversionsvolumen blieb stabil. Im gleichen Zeitraum stieg der Anteil des Traffics aus einer teureren Produktkampagne. Wir empfehlen keine Budgetkürzung, bis die Rentabilität dieser Produktgruppe überprüft wurde.

Das bedeutet immer noch nicht, dass der Agent die Kampagne eigenständig ändern sollte.

Er kann eine Empfehlung vorbereiten, die Daten anhängen, ein Confidence-Level auf Basis von Datenqualität, Vollständigkeit und Konsistenz bestimmen und dann die Entscheidung an einen Menschen übergeben.

Berechtigungen zur Durchführung von Änderungen können später hinzugefügt werden - nur dort, wo das Risiko kontrolliert ist und ein Audit-Trail existiert.

Das Modell ist wichtig. Aber ein Agent entsteht erst, wenn um das Modell herum folgende Elemente vorhanden sind:

• eine Rolle,
• Kontext,
• Gedächtnis,
• Werkzeuge,
• Regeln,
• Berechtigungen,
• Monitoring,
• eine Entscheidungshistorie.

Diese Art von Architektur setzen wir in unserem System von Agenten ein, die Google Ads-, GA4- und Search Console-Daten analysieren. Der Agent generiert nicht nur einen Bericht - er vergleicht Quellen, bewertet die Datenqualität, speichert frühere Entscheidungen und erstellt Empfehlungen, die eine menschliche Freigabe erfordern.

Zum Case Study: AI Agents for Google Ads & SEO Intelligence.

Wann macht ein KI-Agent geschäftlich Sinn?

Allein die Tatsache, dass ein Prozess mehrere Systeme oder ein Sprachmodell nutzt, bedeutet noch nicht, dass man einen Agenten bauen muss.

Ein Agent kann sinnvoll sein, wenn mindestens mehrere der folgenden Bedingungen gleichzeitig vorliegen:

• Die Entscheidung erfordert die Kombination von Informationen aus mehreren Quellen,
• die Situation ist nicht eindeutig und lässt sich nicht in einer einzigen Regel abbilden,
• Experten führen regelmässig ähnliche Analysen durch, müssen aber jedes Mal einen anderen Kontext berücksichtigen,
• die Reaktionszeit beeinflusst Umsatz, Kosten oder Servicequalität,
• der Prozess endet mit einer Empfehlung oder Aktion, nicht nur mit generiertem Text,
• das Unternehmen kann definieren, welche Entscheidungen der Agent selbst treffen darf und welche eine Freigabe erfordern,
• es gibt eine Möglichkeit zu überprüfen, ob die Empfehlungen des Agenten tatsächlich Ergebnisse liefern.

Das blosse Zusammenführen mehrerer Datenquellen rechtfertigt noch keinen Agenten. Manchmal reichen eine Pipeline, ein Dashboard oder eine gut geschriebene Automatisierung.

Ein Agent wird dann gerechtfertigt, wenn der grösste Wert nicht im Sammeln der Daten liegt, sondern in deren Interpretation und der Wahl des nächsten Schritts.

Vier verschiedene Systemrollen

Den Unterschied sieht man am besten, wenn man nicht die Technologien selbst vergleicht, sondern die Rollen, die sie in einem Prozess übernehmen sollen.

Kriterium	FAQ-Bot / einfacher Chatbot	RAG-Assistent	LLM-Pipeline	KI-Agent
Hauptaufgabe	Begrenztes Szenario bedienen	Antworten auf Basis von Unternehmensdaten	Automatische Datenverarbeitung	Analyse und mehrstufiges Handeln
Daten	Prompt-Anweisungen, statische Antworten oder einfache Regeln	Dokumente, APIs, SQL und Retrieval	Quellsysteme und Dateien	APIs, Gedächtnis, Werkzeuge und Kontext
Oberfläche	Meist Chat	Chat, Suche oder API	Meist Hintergrundprozess	Chat, Dashboard, E-Mail oder Hintergrundprozess
Ergebnis	Antwort oder Weiterleitung	Quellenbasierte Antwort	Strukturiertes Ergebnis	Insight, Empfehlung oder Aktion
Prozessvariabilität	Niedrig	Mittel	Niedrig bis mittel	Hoch
Menschliche Kontrolle	Meist bei Ausnahmen	Bei Antworten mit hohem Risiko	Bei Fehlern und Ausnahmen	Bei Aktionen mit erheblicher Auswirkung

Innerhalb eines einzelnen Systems können sich diese Rollen natürlich überschneiden.

Ein Agent kann RAG nutzen. Eine Pipeline kann einen Retrieval-Schritt enthalten. Ein RAG-Assistent kann wie ein Chatbot aussehen. Ein einfacher Bot kann schwierigere Fragen an ein fortgeschritteneres System eskalieren.

Es geht nicht darum, ein einzelnes Etikett zu wählen.

Es geht darum, die Verantwortlichkeiten richtig aufzuteilen.

Manchmal ist die beste Lösung immer noch eine einfache Automatisierung

Je mehr über Agenten gesprochen wird, desto leichter fällt es, sie überall einzusetzen.

Das ergibt keinen Sinn.

Wenn ein Prozess eindeutig beschrieben werden kann:

wenn A eintritt, führe B aus,

ist es meistens am besten, eine einfache Regel zu schreiben.

Code ist günstiger, schneller, leichter zu testen und vorhersehbarer als ein Sprachmodell.

Ein Agent ist dann nützlich, wenn die Situation nicht eindeutig ist. Wenn man Informationen aus mehreren Stellen zusammenführen, ihre Bedeutung interpretieren, eine Hypothese aufstellen oder den nächsten Schritt wählen muss.

Die besten Systeme, die wir heute bauen, kombinieren beide Ansätze.

Daten werden deterministisch abgerufen und validiert. Schwellenwerte, Formate und grundlegende Berechnungen bleiben im Code. Das Modell kommt nur dort zum Einsatz, wo Interpretation wirklich benötigt wird.

Der Rest bleibt in deterministischem Code, weil Code günstiger, schneller und leichter zu testen ist.

Nicht weil wir KI weniger nutzen wollen.

Sondern weil wir sie dort einsetzen wollen, wo sie Mehrwert bringt.

Was beeinflusst die Kosten?

Man kann nicht ehrlich behaupten, dass ein Chatbot immer am günstigsten und ein Agent immer am teuersten sein wird.

Ein einfacher Bot, der einige Fragen bearbeitet, kann wenig kosten. Ein Chatbot, der auf einem teuren Modell läuft und Tausende langer Gespräche pro Tag bedient, kann teurer sein als ein Agent, der einmal pro Woche läuft.

Die Kosten hängen unter anderem ab von:

• Anzahl der Modellaufrufe,
• Kontextlänge,
• gewähltem Modell,
• Anzahl der Prozessschritte,
• Anzahl externer Tool-Aufrufe,
• Häufigkeit der Datensynchronisation,
• Retrieval- und Reranking-Ansatz,
• geforderter Antwortgeschwindigkeit,
• Monitoring und Evaluation,
• menschlicher Beteiligung,
• Sicherheits- und Infrastrukturanforderungen.

Bei RAG kommen die Kosten für Datenaufbereitung, Indexierung und Aktualisierung hinzu. Bei Pipelines spielt das Volumen der verarbeiteten Dokumente eine Rolle. Bei Agenten - die Anzahl der Schritte, genutzten Quellen und die Ausführungshäufigkeit.

Eine eigene Kategorie bilden die Einstiegskosten.

Sie umfassen Datenaufbereitung, Integration mit bestehenden Systemen, Berechtigungskonfiguration, Aufbau einer Testsuite, Entwurf von Einschränkungen, Behandlung von Sonderfällen und Einführung des Monitorings.

In der ersten Projektphase können die Einstiegskosten deutlich höher sein als die späteren laufenden Kosten der Modellaufrufe.

Die reinen Token-Kosten sind oft nicht der grösste Posten.

Mehr kostet die Datenaufbereitung, die Integration mit bestehenden Systemen, die Fehlerbehandlung und das Hinführen der Lösung zu dem Punkt, an dem man ihr in der Produktion vertrauen kann.

Das grösste Risiko entsteht vor der Technologiewahl

Man nimmt leicht an, dass der grösste Fehler die Wahl von RAG statt eines Agenten oder einer Pipeline statt eines Chatbots wäre.

Häufiger beginnt das Problem früher.

Das Unternehmen weiss nicht genau, welchen Prozess es verbessern will. Es gibt keine eindeutige Datenquelle. Dokumente sind veraltet. Zwei Systeme zeigen unterschiedliche Werte. Niemand hat festgelegt, wer für das Ergebnis verantwortlich ist oder was das System tun soll, wenn es nicht genügend Informationen hat.

Probleme mit Datenqualität, -verfügbarkeit und -governance gehören zu den häufigsten Gründen, warum KI-Projekte ins Stocken geraten.

Sie sind jedoch nicht die einzigen.

Ebenso wichtig können sein:

• kein klar definierter Geschäftswert,
• die Kosten für die Wartung der Lösung,
• Unterschätzung des Integrationsaufwands,
• fehlendes Monitoring,
• kein Verfahren für fehlerhafte Antworten,
• ein zu breiter Umfang der ersten Version,
• keine Person, die für den Betrieb des Systems verantwortlich ist.

Man kann einen technisch einwandfreien Chatbot, ein RAG-System oder einen Agenten bauen, den niemand braucht.

Deshalb sollte ein Projekt nicht mit einer Modell-Demo beginnen, sondern mit einem Gespräch über den Prozess.

Wie also wählen?

Wenn der Benutzer ein einfaches, begrenztes Szenario durchlaufen soll - reicht wahrscheinlich ein FAQ-Bot oder eine klassische Automatisierung.

Wenn er Fragen zu Unternehmensdokumenten und -daten stellen soll - kann ein RAG-Assistent das Richtige sein.

Wenn das System regelmässig Dokumente oder Datensätze nach einem definierten Ablauf verarbeiten soll - lohnt es sich, eine LLM-Pipeline in Betracht zu ziehen.

Wenn es eine Situation beobachten, mehrere Werkzeuge nutzen, frühere Entscheidungen berücksichtigen und nächste Schritte wählen soll - dann sprechen wir über einen KI-Agenten.

Bei komplexeren Projekten lautet die Antwort oft:

wir brauchen mehrere dieser Elemente gleichzeitig.

Ein Assistent kann RAG nutzen. Eine Pipeline kann Daten für einen Agenten aufbereiten. Ein Agent kann deterministische Automatisierung auslösen. Ein Mensch kann Aktionen mit grösserer Tragweite freigeben.

Technologie sollte aus dem Prozess folgen, nicht umgekehrt.

Das Modell ist erst der Anfang

Noch vor Kurzem begannen die meisten Gespräche über KI-Systeme mit der Modellwahl.

GPT, Claude, Gemini, DeepSeek. Welches ist besser? Welches günstiger? Welches hat ein grösseres Kontextfenster?

Das sind immer noch wichtige Fragen, aber immer weniger die wichtigsten.

Ein Modell kann ausgetauscht werden. Viel schwieriger ist es, schlecht gestaltete Daten, fehlende Integrationen, unklare Berechtigungen oder einen Prozess zu ersetzen, den vorher niemand verstanden hat.

Deshalb beginnen wir bei KI-Projekten mit dem Anwendungsfall, den Datenquellen, den Risiken und den Stellen, an denen das System einen Menschen wirklich entlasten soll.

Erst danach wählen wir, ob ein Chatbot, RAG, eine LLM-Pipeline, ein Agent - oder eine Kombination mehrerer Schichten nötig ist.

Denn ein Unternehmen braucht in der Regel keine „KI-Einführung".

Es braucht die Lösung eines konkreten Problems. KI ist ein möglicher Teil dieser Lösung.

Planen Sie eine KI-Einführung?

Wir entwickeln produktive KI-Systeme, die mit realen Unternehmensdaten und -prozessen verbunden sind - von RAG-Assistenten und LLM-Pipelines bis hin zu spezialisierten Agenten, die APIs, Gedächtnis und Werkzeuge nutzen.

Jedes Projekt beginnt mit einer Analyse des Anwendungsfalls, der Daten und der Architektur. Nicht mit der Modellwahl.

Erfahren Sie, wie wir KI-Systeme und LLM-Integrationen bauen.