Stell dir vor, du rufst beim Kundensupport deiner Bank an.
Das Erste, was du hörst, ist ein Menü:
„Drücke 1 bei Kontoproblemen. Drücke 2 bei Problemen mit deiner Karte. Drücke 3 bei Betrugsverdacht.“ Du drückst die 2.
Einen Moment später stellt das System eine Anschlussfrage: „Wurde deine Karte verloren, gestohlen oder wird sie abgelehnt?“ Du wählst „abgelehnt“ und plötzlich sprichst du mit dem richtigen System – eines, das relevante Fragen stellt, die richtigen Daten prüft und dir eine Antwort gibt, die für deine Situation tatsächlich Sinn ergibt.
Jetzt stell dir das gegenteilige Erlebnis vor.
Du erklärst, dass deine Karte abgelehnt wird, aber das System ignoriert diesen Kontext. Es presst dich durch ein starres Skript, wiederholt allgemeine Fragen, startet den Ablauf neu und behandelt jedes Problem so, als wäre es dasselbe. Keine Verzweigung. Keine Anpassung. Nur eine feste Abfolge, die nie innehält, um zu fragen, ob sie noch auf dem richtigen Weg ist.
Dieses zweite Erlebnis fühlt sich kaputt an – nicht, weil es dem System an Informationen mangelt, sondern weil es ihm an Entscheidungsfähigkeit fehlt. Genau dieses Problem tritt in KI-Systemen ständig auf.
Das Problem mit sequenziellen Ketten (Chains)
Viele KI-Agenten sind als sequenzielle Ketten aufgebaut: Schritt 1 füttert Schritt 2, welcher Schritt 3 füttert. Die gesamte Konversation oder Aufgabe ist in einem einzigen langen Prompt oder einer festen Serie von Prompts kodiert. Solange sich der Nutzer genau wie erwartet verhält, funktioniert das System.
Aber in dem Moment, in dem die Realität abweicht: „Das habe ich schon versucht.“ „Das ist nicht mein Problem.“ „Das trifft auf mich nicht zu.“ … läuft die Kette trotzdem weiter. Sie hält nicht an, um zu fragen, ob dies noch der richtige Pfad ist. Sie führt einfach den nächsten Schritt aus, weil sie nichts anderes gelernt hat.
Das passiert, weil jede sequenzielle Kette auf fragilen Annahmen basiert: dass der Nutzer genau wie erwartet antwortet und dass die ursprüngliche Strategie bis zum Ende relevant bleibt. Wenn diese Annahmen scheitern, tappt das System in die „Komplexitätsfalle“. Anstatt umzuschwenken, versuchen Entwickler oft, die Kette zu „flicken“, indem sie dem Prompt mehr Anweisungen und Sonderfälle hinzufügen. Dies führt zu „Prompt-Aufblähung“ (Prompt Bloat), was das System instabil und teuer macht und es dem Modell erschwert, logisch zu schlussfolgern. Die Kette scheitert nicht, weil es der KI an Intelligenz mangelt; sie scheitert, weil ihr die Logikgatter fehlen, um den Kurs zu ändern.
Einführung in das Routing
Kehren wir zu unserem Kundensupport-Beispiel zurück. In einer linearen Kette ist der Agent ein starres Skript. In einem Routing-System ist der Agent der Empfangsmitarbeiter. Routing ist der explizite Moment, in dem das System die Eingabe des Nutzers bewertet und entscheidet, welche „Abteilung“ den Anruf bearbeiten soll. Anstatt jeden Nutzer durch dasselbe Standard-Skript zu zwingen, hört das System auf Signale:
- „Mir wurde zu viel berechnet“ → Route zu Abrechnung.
- „Meine Karte funktioniert nicht“ → Route zu Technischer Support.
- „Ich habe diesen Kauf nicht getätigt“ → Route zu Betrugsprävention. Der Unterschied ist transformativ: Das System legt sich erst auf einen Pfad fest, wenn es weiß, welcher Pfad tatsächlich zutrifft.
Wie Routing in KI-Systemen funktioniert
In einem agentenbasierten System spielt das Routing die Rolle des „Gehirns“ vor der „Muskelkraft“. Anstatt das Modell in einen einzigen, massiven Prompt einzusperren, bewertet das System zuerst den Kontext und wählt den relevantesten Workflow aus. Dieser Workflow könnte sein:
- Eine spezialisierte Kette zur Fehlersuche.
- Eine kurze Klärungsschleife.
- Eine sofortige Weiterleitung an einen Menschen.
Ketten sind nicht verschwunden. Sie wurden lediglich organisiert. Genau wie ein Callcenter verschiedene Skripte für unterschiedliche Abteilungen hat, nutzt ein Routing-KI-System fokussierte Ketten, die für spezifische Aufgaben optimiert sind. Die „Endlosschleife des Grauens“ passiert nur dann, wenn du ein Abrechnungsproblem durch eine technische Support-Kette erzwingst.
Warum dies das Prompt-Design verändert
Ohne Routing tappen Entwickler in die „Mega-Prompt-Falle“. Sie versuchen, jedes „Wenn/Dann“-Szenario in ein einziges, massives Anweisungsset zu backen: Wenn der Nutzer frustriert ist, entschuldige dich; wenn er die Lösung schon probiert hat, schlage einen Neustart vor; wenn er eine Rückerstattung erwähnt, erkläre die 30-Tage-Frist...
Dies führt zu „Prompt Bloat“ – das Modell wird durch zu viele Anweisungen verwirrt. Routing lagert diese Logik aus. Am Ende hast du:
- Den Router: Ein kleiner, schneller Prompt, dessen einzige Aufgabe es ist, die Absicht zu kategorisieren.
- Die Spezialisten: Schlanke, fokussierte Ketten, die nur ihren spezifischen Bereich bearbeiten.
Vom Skript zum System
Ein rein sequenzieller Agent ist ein Skript, das einfach weiterredet, ungeachtet des Publikums. Ein Routing-Agent ist ein System – eines, das umleiten, eskalieren oder die Strategie ändern kann, sobald neue Informationen auftauchen. Sobald du aufhörst zu fragen „Was ist der nächste Schritt?“ und anfängst zu fragen „Wohin soll das als Nächstes gehen?“, hörst du auf, Bots zu bauen, und fängst an, Agenten zu bauen.
Routing-Strategien
Das Ziel des Routings ist es, eine Frage zu beantworten: Wohin soll diese Anfrage als Nächstes gehen? In einem agentenbasierten System gibt es vier Hauptwege, um diese Entscheidung zu treffen. Um den Unterschied zu verstehen, schauen wir uns an, wie jeder Weg mit derselben Nutzereingabe umgeht: Ich bin in einem Restaurant in Paris, meine Karte wurde gerade abgelehnt und ich habe Angst, dass ich wegen Betrugsverdachts gesperrt wurde.
LLM-basiertes Routing (Der „denkende“ Weg)
Dies ist die flexibelste und oft einfachste Methode für den Anfang. Hier erhält ein Sprachmodell den aktuellen Kontext und wird gebeten zu entscheiden, welche Route zutrifft. Konzeptionell ähnelt das einem Support-Mitarbeiter, der dein Problem liest und sagt: „Das klingt nach einem Abrechnungsproblem, nicht nach einem technischen.“
Der Router-Prompt könnte folgendes prüfen:
- Die Nachricht des Nutzers
- Den Konversationsverlauf
- Den Systemstatus oder Metadaten
… und ein Label zurückgeben wie:
- technischer_support
- abrechnung
- eskalation
- klaerung_erforderlich Dieses Label bestimmt, welche Kette oder welcher Agent als Nächstes läuft.
Wie es unser Beispiel handhabt:
Es bemerkt, dass der Nutzer im Ausland ist („Paris“) und „Betrug“ erwähnt. Es erkennt, dass dies nicht nur ein technischer Fehler ist – es ist eine stressige Reise-Situation. Es routet zu „Reise & Sicherheit“ mit einer hohen Prioritätsstufe.
Wann es gut funktioniert
- Mehrdeutige oder natürliche Spracheingaben
- Schnell wechselnde Anforderungen
- Systeme im frühen Stadium, in denen Flexibilität wichtig ist
Nachteile
- Höhere Latenz und Kosten pro Routing-Entscheidung
- Weniger deterministisches Verhalten, wenn nicht stark eingeschränkt LLM-basiertes Routing glänzt, wenn die Absicht unklar ist und menschenähnliches Urteilsvermögen gefragt ist.
Embedding-basiertes Routing (Der „Ähnlichkeits“-Weg)
Embedding-basiertes Routing beantwortet eine einfachere Frage: Welcher bekannten Kategorie ist dies am ähnlichsten?
Anstatt über die Eingabe nachzugrübeln, vergleicht das System sie mittels Vektorähnlichkeit mit vordefinierten Beispielen oder Beschreibungen. Das ist vergleichbar mit einem Support-System, das Anrufe routet, indem es Schlüsselwörter oder Sätze mit bekannten Problemtypen abgleicht. Zum Beispiel eingebettet das System die Nachricht des Nutzers und vergleicht sie mit Embeddings für:
- Probleme mit abgelehnter Karte
- Internet-Verbindungsprobleme
- Abrechnungsstreitigkeiten Die Kategorie, die am nächsten liegt, gewinnt.
Wie es unser Beispiel handhabt:
Das System stellt fest, dass der Satz „Karte wurde gerade abgelehnt“ mathematisch am nächsten an 5.000 früheren Tickets mit dem Label „Transaktionsfehler“ liegt. Es leitet den Nutzer zum standardmäßigen automatisierten Fehlersuch-Prozess weiter.
Wann es gut funktioniert
- Stabile Anzahl an Routen
- Hohes Volumen ähnlicher Anfragen
- Schnelles, kostengünstiges Routing
Nachteile
- Hat Schwierigkeiten bei völlig neuen Fällen: Es könnte die Nuance übersehen, dass der Nutzer gerade in einem anderen Land feststeckt.
- Erfordert eine gute Abdeckung durch Beispiele.
Embedding-basiertes Routing wird oft als schneller, zuverlässiger erster Schritt eingesetzt. Manchmal wird es für Sonderfälle mit LLM-Routing kombiniert.
Regelbasiertes Routing (Der „festverdrahtete“ Weg)
Dies ist die berechenbarste Strategie unter Verwendung von Wenn/Dann-Logik. Es funktioniert wie ein Telefonmenü.
Hier werden Routing-Entscheidungen anhand fester Bedingungen getroffen:
- Wenn der Nutzer „Rückerstattung“ erwähnt, gehe zur Abrechnung.
- Wenn Fehlercode X erscheint, gehe zum technischen Support.
- Wenn der Konfidenzwert niedrig ist, eskalliere.
Es gibt keine Mehrdeutigkeit und keine Interpretation.
Wie es unser Beispiel handhabt:
Das System scannt nach dem Schlüsselwort „Betrug“. Da dieses Wort ein fest einprogrammierter Trigger ist, wird der Nutzer sofort an die Betrugsabteilung weitergeleitet, selbst wenn das eigentliche Problem nur eine abgelaufene Karte war.
Wann es gut funktioniert
- Klare, eindeutige Signale
- Regulatorische oder sicherheitskritische Abläufe
- Situationen, die vollen Determinismus erfordern
Nachteile
- Unflexibel bei unerwarteten Eingaben: Wenn der Nutzer sagt „jemand hat mein Geld gestohlen“ statt „Betrug“, löst die Regel eventuell nicht aus.
- Wird komplex, wenn sich Regeln ansammeln.
Regelbasiertes Routing reicht in dialogorientierten Systemen selten allein aus, wird aber oft als „Leitplanke“ oder Override eingesetzt.
ML-Modell-basiertes Routing (Der „Muster“-Weg)
Bei diesem Ansatz wird das Routing von einem dedizierten Klassifikator übernommen, der auf historischen Daten trainiert wurde. Anstatt logisch zu schlussfolgern oder Ähnlichkeiten abzugleichen, lernt das Modell Muster aus vergangenen Beispielen: Anfragen wie diese gehen normalerweise zu Pfad X.
Das spiegelt wider, wie große Support-Organisationen Tickets basierend auf früheren Ergebnissen und Kennzahlen routen.
Wie es unser Beispiel handhabt:
Basierend auf historischen Mustern weiß das Modell, dass bei der Kombination von „abgelehnt“ und „Paris“ eine 85-prozentige Wahrscheinlichkeit besteht, dass der Nutzer vergessen hat, eine Reiseankündigung zu hinterlegen. Es leitet ihn zum Agenten für „Self-Service Reise-Einstellungen“ weiter.
Wann es gut funktioniert
- Große Datensätze mit gelabelten Ergebnissen
- Stabile Problembereiche
- Performance-getriebene Optimierung
Nachteile
- Erfordert Trainingsdaten und Wartung
- Schwerer schnell an neue Kategorien anzupassen
ML-basiertes Routing ist skalierbar und mächtig, aber für frühe oder sich schnell ändernde Systeme oft überdimensioniert.
Strategie-Vergleich
Die richtige Strategie wählen: Der hybride Ansatz
In der Praxis wählst du selten nur eine Strategie. Die robustesten Systeme nutzen Layered Routing (geschichtetes Routing), bei dem verschiedene Methoden als Filter fungieren.
Denk an die Sicherheitsebenen einer Bank: Ein Karteneinsatz besteht vielleicht eine Basis-Regel (ist die Karte aktiv?), löst aber ein ML-Modell für verdächtige Aktivitäten aus und erfordert schließlich ein LLM (oder einen Menschen), um einen komplexen Streitfall zu lösen.
Wie Layering funktioniert
Anstatt eine Methode zu wählen, stapelst du sie von der schnellsten/günstigsten zur „intelligentesten“:
- Ebene 1: Regeln (Die Leitplanke): Handhabt explizite Befehle und Sicherheit. Beispiel: Wenn ein Nutzer „STOPP“ tippt, killt das System den Prozess sofort über eine Regel und ignoriert jede andere Logik.
- Ebene 2: Embeddings (Der Schnellpfad): Handhabt 80 % der häufigen Anfragen sofort. Beispiel: „Wie hoch ist mein Kontostand?“ passt zum Vektor „Kontofunktionen“ und wird geroutet, ohne ein „Gehirn“ zu bemühen.
- Ebene 3: LLMs (Der Spezialist): Handhabt die „schwierige Mitte“. Beispiel: „Ich muss eine Abbuchung von letzter Woche anfechten, weil der Händler eine Rückerstattung versprochen hat, die nie ankam.“ Dies erfordert, dass das LLM die Absicht und die Nuancen versteht.
Das „Override“-Prinzip: Ein hybrides System erlaubt es einer Ebene, eine andere zu überschreiben. Zum Beispiel sollte eine Rückerstattungsanfrage, die das Wort „Betrug“ enthält, einen regelbasierten Override zur Sicherheit auslösen, selbst wenn die Embeddings vermuten lassen, dass es ein Standard-Abrechnungsthema ist.
Routing als kontinuierliches Logikgatter
Routing ist nicht nur eine Aktivität an der „Haustür“; es sollte als Logikgatter behandelt werden, das an jedem Punkt eines Multi-Prompt-Flows ausgelöst werden kann. Wenn du nur am Anfang routest, baust du nur eine etwas smartere Kette. Wenn du zwischen den Schritten routest, baust du ein adaptives System.
Ein Beispiel für den Schwenk mittendrin: Stell dir vor, ein Nutzer ist drei Schritte tief in einer „Kontoinformationen“-Kette. Er hat sich identifiziert und seinen Kontostand gesehen. Plötzlich fragt er: „Kann ich das Geld eigentlich direkt auf mein Sparkonto schieben?“ Eine statische Kette würde scheitern oder eine irrelevante Antwort geben, weil sie im „Kontoinfo-Skript“ gefangen ist. Ein System mit Routing zwischen den Schritten erkennt die Änderung der Absicht und wechselt den Flow zum Prompt für „Interne Überweisung“ – es „überlegt es sich anders“ basierend auf der neuen Eingabe.
Wo Routing im System lebt
Routing ist keine einzelne „Schranke“ am Anfang; es ist eine strukturelle Ebene, die in verschiedenen Tiefen auftreten kann.
- Der Einstiegspunkt (Makro-Routing): Bevor die Verarbeitung beginnt, klassifiziert ein Router-Prompt die Absicht.
- Der Schwenk in der Mitte (Inter-Prompt-Routing): Routing zwischen Prompts in einer Sequenz. Dies erlaubt es dem System, die Ausgabe von „Prompt A“ zu bewerten, bevor es entscheidet, welcher „Prompt B“ ausgelöst wird.
- Die Subroutine-Ebene (Mikro-Routing): Routing innerhalb einer spezifischen Aufgabe, um zu entscheiden, welches Werkzeug (Tool) oder welche Datenquelle genutzt werden soll.
Warum diese Architektur wichtig ist
Ohne Routing auf diesen Ebenen bricht die Spezialisierung zusammen. Du endest wieder beim „Gott-Prompt“ – einem einzigen, 2.000 Wörter langen Anweisungsset, das alles gleichzeitig versucht. Überladene Prompts sind der Ort, an dem Zuverlässigkeit stirbt. Durch verteiltes Routing stellst du sicher, dass:
- Prompts klein bleiben: Jeder Prompt bearbeitet nur seinen Bereich.
- Latenz niedrig bleibt: Du führst nur die Logik aus, die für den aktuellen Pfad nötig ist.
- Fehlersuche einfacher ist: Du kannst genau sehen, welches Routing-Gatter falsch abgebogen ist.
Fazit: Den Kreis schließen
Erinnerst du dich an unser Kundensupport-Beispiel vom Anfang? Wir alle waren schon mal in der „Telefonmenü-Hölle“ gefangen, in der jede Option in eine Sackgasse führt.
Genau wie ein Callcenter, das dich endlos weiterverbindet, schlimmer ist als eines, das Unsicherheit zugibt, muss Routing in KI-Systemen transparent und korrigierbar sein.
Wenn dein System eine Routing-Entscheidung trifft, die sich als falsch herausstellt, sollte es nicht „einfach durchziehen“ und auf das Beste hoffen. Es sollte die Fähigkeit haben, den Fehler zu erkennen und den Nutzer auf den richtigen Pfad umzuleiten.
Wenn du aufhörst darüber nachzudenken, „was als Nächstes in der Kette kommt“, und anfängst zu überlegen, „wohin das als Nächstes gehen sollte“, baust du keine komplizierten Skripte mehr, sondern resiliente Systeme.
