Heute sind wir weiter. Dank Large Language Models (LLMs) und Agenten-Architekturen bauen wir keine starren Entscheidungsbäume mehr. Wir nutzen das LLM als intelligenten „Dispatcher“, der versteht, was der Nutzer wirklich will – und dann gezielt spezialisierte Akteure steuert.
Der neue Standard: Der LLM-Dispatcher als Gatekeeper
Früher war Intent-Erkennung simples Keyword-Matching. Heute ist es semantisches Verständnis. In unserer Architektur schicken wir jede Anfrage zuerst an ein LLM. Dieses ist mit präzisen Prompts zur Absichtserkennung (Intents) ausgestattet. Schreibt ein Nutzer: „Können wir mal quatschen?“ oder „Ich brauche einen Termin“, erkennt das LLM sofort den Intent contact_request oder appointment_booking. Das Besondere: Es braucht kein exaktes Schlagwort; das LLM versteht den Kontext.
Die Architektur: Wenn der Agent das Steuer übernimmt
Sobald das System eine spezifische Absicht erkennt, wechselt der Modus. Der Chat wird an einen spezialisierten Agenten übergeben.
- Datensammlung & Dialog: Der Agent weiß nun, dass er ein Ziel verfolgt (z. B. einen Termin vereinbaren). Er fragt gezielt nach fehlenden Informationen: „Gerne, an welchem Tag passt es Ihnen?“
- Aktion (Function Calling): Der Agent ist nicht nur ein Text-Generator, er ist handlungsfähig. Er greift auf „Tools“ zu, um externe Akteure aufzurufen:
- E-Mails verschicken via API.
- Termine eintragen im Kalender-Backend.
- Datenbank-Updates im CRM.
- Die Rückgabe: Sobald die Mission erfüllt ist (der Termin steht, die Mail ist raus), gibt der Agent das Wort zurück an das RAG-System.
Zurück zur Basis: RAG als Wissensquelle
Wenn kein spezifischer Transaktions-Intent (wie „Termin buchen“) vorliegt oder der Agent seine Arbeit erledigt hat, übernimmt wieder das RAG-System (Retrieval-Augmented Generation). Hier kommt die Vektordatenbank (wie Chroma DB) ins Spiel. Sie dient als das „Langzeitgedächtnis“. Anstatt den Nutzer mit „Ich weiß nicht“ abzuspeisen, durchsucht das System nun Dokumente, Handbücher oder FAQs, um fundierte Antworten auf Basis der internen Daten zu geben.
Backend-Prozesse: Von der Absicht zur Aktion
Der Prozessflow im Überblick:
| Schritt | Aktion | Aktion |
|---|---|---|
| Input | Nutzer stellt eine Frage. | Stellt eine Anfrage (egal wie formuliert). |
| Dispatching | LLM | Intent-Erkennung via Prompting (Booking, Support, Info?). |
| Handover | Agent | Übernimmt den Chat, falls ein Intent erkannt wurde. |
| Execution | Backend | Agent sammelt Daten und nutzt Tools (Mail, Kalender, etc.). |
| Return | RAG (Chroma DB) | Nach Abschluss übernimmt wieder die wissensbasierte Suche. |
Warum diese Trennung der Schlüssel zum Erfolg ist
Warum schicken wir den Nutzer erst zum Agenten und dann zurück zum RAG?
- Präzision: Ein Agent, der auf „Termine“ spezialisiert ist, halluziniert nicht. Er folgt einem Protokoll, bis alle Daten vorliegen.
- Handlungsfähigkeit: Reine RAG-Systeme können nur antworten. Erst durch die Agenten-Übergabe wird aus einem Chatbot ein echter digitaler Mitarbeiter, der Aufgaben erledigt.
- Natürlicher Fluss: Für den Nutzer fühlt es sich wie ein einziges, flüssiges Gespräch an. Er merkt nicht, dass im Hintergrund zwischen Intent-Erkennung, spezialisierter Logik und Vektorsuche gewechselt wird.
Fazit: Die Zukunft ist "Agentic"
Wir bauen keine Systeme mehr, die nur Text generieren. Durch die Kombination von LLM-basiertem Routing, aktionsorientierten Agenten und effizienten Vektordatenbanken wie Chroma DB schaffen wir Lösungen, die mitdenken. Wir bauen digitale Mitarbeiter, die nicht nur wissen, wo die Information steht, sondern auch, wie man das passende Werkzeug aus dem Backend-Koffer benutzt.