Der Support-Chatbot von ShopEasy kann die Frage „Wo ist meine Bestellung?“ beantworten, indem er eine Backend-Funktion wie lookup_order aufruft und das Ergebnis anschließend in einen hilfreichen, für den Nutzer verständlichen Satz umwandelt.
Eine einfache Erklärung für ein Large Language Model (LLM) in diesem Kurs lautet: Ein LLM nimmt den von uns gesendeten Text entgegen und sagt den nächsten Text voraus, der zurückgegeben werden soll – ähnlich wie eine extrem leistungsstarke Autovervollständigung, die ganze Absätze generieren kann.
Selbst bei dieser einen Frage zur Bestellung gibt es bei ShopEasy bereits verschiedene Eingaben. Der System-Prompt ist die interne Anweisung, die ShopEasy bei jeder Anfrage mitsendet, zum Beispiel: „Du bist der ShopEasy-Support. Fasse dich kurz. Frage nach der Bestellnummer, falls diese fehlt.“ Der Konversationsverlauf ist das fortlaufende Protokoll früherer Interaktionen, das ShopEasy mitsendet, damit das Modell konsistent bleiben kann. Die Nutzereingabe ist die neue Nachricht, etwa „Wo ist meine Bestellung?“. Tools sind serverseitige Funktionen, die ShopEasy ausführen kann – wie lookup_order oder request_refund –, wenn der Chatbot Daten benötigt oder eine Aktion durchführen muss.
Sobald ShopEasy über diese Komponenten verfügt, durchläuft eine Anfrage einen wiederholbaren Zyklus. Eine Nachricht des Nutzers trifft bei der ShopEasy-API ein, und die Anwendung stellt einen Prompt für das Modell zusammen, indem sie den System-Prompt, den Konversationsverlauf und die neue Nutzereingabe miteinander kombiniert. Die Anwendung sendet diesen Prompt an einen LLM-Anbieter; dieser liefert eine Modellausgabe zurück, bei der es sich entweder um eine direkte Textantwort oder um einen vorgeschlagenen Tool-Aufruf samt Argumenten handelt.
Wenn das Modell einen Tool-Aufruf vorschlägt, entscheidet der Anwendungscode von ShopEasy, ob dieser ausgeführt werden soll. Anschließend wird eine konkrete Funktion aufgerufen – etwa lookup_order, um den Versandstatus abzurufen, oder request_refund, um eine Rückerstattung einzuleiten. ShopEasy sendet das Ergebnis des Tools als weitere Nachricht an das Modell zurück, damit dieses die endgültige Antwort für den Nutzer formulieren kann; nur diese finale Antwort gelangt schließlich zum Nutzer. Ein Detail ist für Sicherheit und späteres Debugging wichtig: Das Modell verfügt über keinen eingebauten Speicher zwischen den einzelnen Aufrufen. Daher muss ShopEasy den Konversationsverlauf jedes Mal erneut mitsenden, da das Modell sonst so reagieren würde, als hätte es den Nutzer noch nie zuvor gesehen. Halten wir diesen Ablauf in einem Diagramm des Anfragepfads fest.
Dieses Diagramm macht die Vertrauensgrenze sichtbar. Benutzereingaben gelten als nicht vertrauenswürdig, da jeder Aufrufer beliebigen Text eingeben kann; ebenso sind Tool-Ergebnisse nicht vertrauenswürdig, da ein Tool unerwartete Inhalte liefern kann, die anschließend wieder in das Modell eingespeist werden.
Eine wichtige sicherheitsrelevante Konsequenz dieses Kreislaufs ist, dass das Modell weder die Datenbank liest noch Rückerstattungen veranlasst oder Richtlinien durchsetzt. Das Modell generiert lediglich Text, der Vorschläge für die nächsten Schritte macht; der Anwendungscode von ShopEasy ist hingegen die Komponente, die tatsächlich Aktionen ausführt und Daten über Tools zurückgibt.
Diese Trennung bleibt nur dann gewahrt, wenn wir drei Identitäten klar voneinander unterscheiden. Der Endnutzer ist der Kunde, der sich nach einer Bestellung erkundigt; dessen Berechtigungen sollten einschränken, welche Bestellungen er einsehen und welche Aktionen er anfordern kann. Der ShopEasy-Dienst ist unser Backend selbst; es verfügt über weitreichendere Befugnisse, wie etwa den Datenbankzugriff und die Möglichkeit, die Funktion request_refund auszuführen. Die Zugangsdaten des LLM-Anbieters (z. B. API-Schlüssel oder Service-Token) werden von ShopEasy für den Aufruf des Modell-Endpunkts verwendet; sie autorisieren lediglich die Nutzung des Modells, nicht jedoch Kundenaktionen. Eine Vermischung dieser Identitäten kann zu Fehlern führen, bei denen das Backend Geld ausgibt, Daten preisgibt oder Aktionen im Auftrag eines Benutzers ausführt, der diese eigentlich nicht hätte auslösen dürfen. Wenn etwas schiefgeht: Welcher Teil kann dann tatsächlich Regeln durchsetzen – der Prompt-Text, das LLM oder der Anwendungscode von ShopEasy?