Ein nützlicher Chatbot muss wissen, wie man eine Person verweist, wenn die Antwort fehlt, eine Entscheidung erforderlich ist oder der Benutzer sie anfordert. Entwerfen Sie diese Passage mit dem Rest der Route: verfügbarer Kanal, übermittelte Informationen und Bestätigung der Gegenleistung.
Begrenzen Sie, was der Chatbot verarbeiten kann
Separate allgemeine Informationen, Konsultation einer Akte und geschäftliche Maßnahmen. Ein Dokumentarassistent kann ein Verfahren erklären, ohne berechtigt zu sein, eine Bestellung zu ändern. seine Grenzen in einer verständlichen Sprache anzeigen. Das Vorhandensein einer Chat-Schnittstelle sollte die üblichen Kontaktmittel nicht eliminieren. Überprüfen Sie auf Mobilgeräten, dass die Navigation oder die wesentlichen Informationen nicht ausgeblendet werden.
Relais-Trigger einstellen
Planen Sie mindestens die ausdrückliche Bitte des Benutzers, das Fehlen ausreichender Quellen und Situationen außerhalb des Geltungsbereichs. Vermeiden Sie Schleifen, bei denen das Modell die gleiche Antwort auf unbestimmte Zeit umformuliert. Auslöser sollten anhand von Beispielen getestet werden können. Für eine sensible Frage beweist die Fließfähigkeit einer Antwort nicht, dass es sich um eine autorisierte Entscheidung handelt.
Beschreiben Sie das Relais als kompletten Kurs
Eine Kontaktschaltfläche reicht nicht aus, wenn niemand weiß, was sie sendet oder wer die Anfrage verarbeitet. Beschreiben Sie den Anfangszustand, die Benutzeraktion, die vorgeschlagenen Informationen und die erwartete Bestätigung. Die Route kann einfach sein: eine Wiederholungszusammenfassung, ein Formular und ein verifizierter Empfangskanal. Es ist wichtig, nicht vorzuschlagen, dass die Anfrage berücksichtigt wurde, bevor der Antrag dies wirklich bestätigt.
| Situation | Schnittstellenantwort | Abnahmetestüberprüfung |
|---|---|---|
| Der Benutzer fragt nach einer Person | Ein zugänglicher Kontaktweg wird vorgeschlagen | Keine Schleife, die neue Neuformulierungen auferlegt |
| Die Dokumentation reagiert nicht | Das Limit wird angekündigt und eine nützliche Fortsetzung wird vorgeschlagen | Kein erfundener Zustand oder Wert |
| Der Service ist geschlossen | Die tatsächliche Verfügbarkeit wird erklärt | Keine automatische Verzögerung nicht validiert |
| Der Kanal schlägt aus | Eine Fehlermeldung und eine Alternative sind verfügbar | Keine falsche Versandbestätigung |
| Eine Geschäftsentscheidung ist notwendig | Nachfrage orientiert sich an der kompetenten Rolle | Das Modell zeigt keine Modifikation wie vorgenommen |
Dieses Raster ist ein Entwurfsvorschlag. Die Berechtigungen bleiben ausschlaggebend: Ein informativer Assistent sollte einen Vertrag nicht ändern oder nur den Zugriff ändern, weil seine Antwort darauf hindeutet. Die Empfehlungen derOWASP für LLM-Anwendungen Helfen Sie dabei, zwischen produziertem Text von tatsächlich autorisierten Aktionen zu unterscheiden.
Übertragen Sie nur, was hilft
Das Relais kann eine Zusammenfassung bieten, die die Person vor dem Senden erneut liest. Identifizieren Sie die erforderlichen Informationen, den Empfänger und den genehmigten Kanal. Kopieren Sie nicht automatisch die gesamte Konversation, wenn es unnötige Daten enthält. Wenn der Dienst geschlossen ist, geben Sie den Weg an, eine Anfrage zu hinterlassen und was als nächstes passieren wird, ohne eine Verzögerung zu versprechen, die vom Team nicht validiert wurde.
Fiktives Beispiel: Eine Änderungsanforderung
Ein Besucher möchte einen bereits bestellten Service ändern. Der Chatbot kann erklären, wo Sie nützliche Informationen finden und einen Kontakt vorschlagen können, aber er bestätigt die Änderung nicht. Der Benutzer prüft eine Zusammenfassung seiner Anfrage vor der Übertragung. Die Seite zeigt eine echte Empfangsbestätigung oder eine Fehlermeldung an, um es erneut zu versuchen. Eine generierte Formel ersetzt diese Überprüfung nicht.
Entwerfen Sie eine Zusammenfassung, die die Person kontrollieren kann
- Beschränken Sie die Zusammenfassung auf die Frage, den nützlichen Kontext und die Elemente, denen der Benutzer zusendet. Zeigen Sie es vor dem Senden, wenn die Route es zulässt.
- Geben Sie den Kanal und den funktionalen Empfänger der Anfrage an. Eine vage Formel wie "Wir kümmern uns darum" beschreibt keinen nachweisbaren Empfang.
- erlauben, die Zusammenfassung zu korrigieren. Eine schlechte Umformulierung durch das Modell sollte nicht die einzige Version der vom Team gehaltenen Anfrage werden.
- Testen Sie den Empfang mit Demo-Daten und dann dem Fehlerszenario. Überprüfen Sie die Route auf der Tastatur und auf einem schmalen Bildschirm, auch wenn das Chat-Fenster geöffnet ist.
In einer fiktiven Simulation möchte eine Person einen bereits bestellten Service entwickeln. Der Chatbot kann erklären, welche Informationen vorzubereiten sind, und eine Zusammenfassung vorschlagen. Es bestätigt keine Annahme oder Änderung der Datei. Das Team erhält eine umsetzbare Anfrage und bleibt für die Entscheidung verantwortlich. Diese Trennung ermöglicht es, schnell zu helfen, ohne eine kommerzielle Verpflichtung einzugehen.
Bei einem Agenturstandort kann das Relais auf einen Framing-Austausch gerichtet sein, anstatt jede Situation sofort zu lösen. Planen Sie die Überprüfung der unbeantworteten Fragen, um die Dokumentation zu verbessern. Die Vorbereitung einer Wissensbasis und die Tests der RAG-Qualität Ergänzen Sie dann die Arbeit am Formular und zum tatsächlichen Empfang der Nachrichten.
Testen Sie das Ende des Kurses
Simulieren Sie eine unauffindbare Reaktion, eine unmittelbare menschliche Nachfrage und einen Kontaktkanalausfall. Steuern Sie Tastatur, mobile Lese- und Bestätigungsnachrichten. Der OWASP identifiziert die mit den Ausgängen und Zugriffen von LLM-Anwendungen verbundenen Risiken: Begrenzen Sie daher die Leistungen des Chatbots auf das Notwendige. Verknüpfen Sie diese Arbeit mitVerbesserung des Kontaktformulars ein zuverlässiges Problem aufrechtzuerhalten.