Beim Definieren eines Playbooks können Sie optional Codeblöcke angeben. Dabei handelt es sich um Inline-Python-Code, mit dem sich das Verhalten von Kundenservicemitarbeitern besser steuern lässt. Dieser Code besteht aus Funktionen mit speziellen Decoratoren und allen erforderlichen Dienstprogrammfunktionen.
Beim Schreiben Ihres Codes können Sie die Codeblock-Systembibliothek verwenden, um das Verhalten des Kundenservicemitarbeiters zu steuern.
Beschränkungen
Es gelten folgende Einschränkungen:
- Codeblöcke dürfen keine Objekte enthalten, die Daten speichern. Sie können jedoch Tools verwenden, um Daten zu speichern und den Status beizubehalten.
- Codeblöcke können keine Remote-Aufrufe direkt ausführen. Sie können beispielsweise die Python-Bibliothek „requests“ nicht verwenden. Sie können jedoch Tools verwenden, um Remoteaufrufe indirekt auszuführen.
- Ressourcennamen, die in Python-Namen umgewandelt werden, müssen gültige Python-Namen sein.
- Codeblöcke können Sitzungsparameter nur lesen oder schreiben, wenn ein Ablaufübergang stattfindet.
- Wenn in einem Codeblock ein OpenAPI-Tool verwendet wird und ein anderer HTTP-Statuscode als 200 zurückgegeben wird, schlägt der Codeblock fehl und der Fehler kann nicht abgefangen werden.
Inline-Aktionen
Inline-Aktionen verhalten sich ähnlich wie Tool-Aktionen. Sie haben ein definiertes Eingabe- und Ausgabeschema, das durch die Python-Funktionssignatur bestimmt wird, einschließlich Typannotationen und Docstring. Ähnlich wie bei Toolaufrufen kennt der LLM den Code nicht, der die Aktion implementiert.
Beispiel:
@Action
def is_prime(n: int): bool
"""Returns true if n is prime."""
import math
return (all([False for i in range(2, math.sqrt(n)
if n % i == 0 ]) and not n < 2)
Für diese Funktion erhält das LLM Informationen zur Aktion, ihrer Eingabe und ihrer Ausgabe.
Wenn Sie in Ihren Playbook-Anweisungen auf eine Inline-Aktion verweisen möchten, geben Sie einfach den Aktionsnamen in Backticks ein und beschreiben Sie, wie sie verwendet werden soll.
Beispiel für eine place_order
-Inline-Aktion:
Take the customer's order, then call the `place_order` action when the order is ready.
Wenn Sie Beispiele mit Inline-Aktionen erstellen möchten, verwenden Sie im Bereich Eingabe und Ausgabe den Tooltyp inline-action.
Weitere Informationen finden Sie in der Referenzdokumentation zu @Action.
Triggerfunktionen
Mit Triggerfunktionen werden bedingte Aktionen im Code definiert.
Triggerfunktionen werden mithilfe von Decorators deklariert. Sie können die folgenden Triggerfunktionsdekorateure verwenden:
Dekorateur | Dekoratorparameter | Beschreibung |
---|---|---|
@EventTrigger | event: str, condition: str , wobei die Bedingung optional ist |
Durch ein Ereignis ausgelöst |
@BeforeModelTrigger | condition: str , wobei die Bedingung optional ist |
Wird jedes Mal ausgelöst, bevor der LLM die nächste Aktion vorhersagt. |
@BeforeActionTrigger | condition: str , wobei die Bedingung optional ist |
Wird jedes Mal ausgelöst, bevor der LLM eine Aktion ausführt. |
@BeforePlaybookTrigger | condition: str , wobei die Bedingung optional ist |
Wird ausgelöst, wenn ein Playbook zum ersten Mal gestartet wird. |
Diese Funktionen zeigen beispielsweise, wie Sie diese Dekoratoren und Dekoratorparameter verwenden, und auch wie Sie die Systembibliotheksfunktion für Codeblöcke respond verwenden.
# No decorator parameter
@PlaybookStartTrigger
def my_playbook_conditional_action():
respond("How can I help?")
# With a condition decorator parameter
@BeforeActionTrigger('$next-action.name = "search"')
def my_before_action_conditional_action():
respond("One moment please")
# Event
@EventTrigger(event="welcome")
def my_welcome_event():
respond("hi")
# Event with a condition:
@EventTrigger(event="welcome",
condition="$sys.func.NOW().hours < 10")
def my_good_morning_event():
respond("Good morning ☕")
Verweise auf Workflows, Playbooks und Tools
In Ihrem Codeblock können Sie mithilfe der globalen Variablen flows, playbooks und tools auf bestimmte Abläufe, Playbooks und Tools verweisen.
Jedes dieser Objekte hat Mitglieder, die mit den Namen der entsprechenden Ressourcen übereinstimmen. Diese Namen müssen gültige Python-Namen sein.
Beispiel:
add_override(playbooks.troubleshooting, {})
add_override(flows.billing)
add_override(tools.weather_api.get_weather, {"location": "San Francisco"})
Wenn Sie in einem Codeblock auf Abläufe und Playbooks verweisen, müssen Sie dies auch in der Playbook-Anleitung mit der folgenden Syntax tun:
${RESOURCE_TYPE: my_resource_name}
Wenn Ihr Codeblock beispielsweise flows.myflow
und playbooks.myplaybook
enthält, sollte Ihre Playbook-Anleitung Folgendes enthalten:
${FLOW: myflow}
${PLAYBOOK: myplaybook}
Aktionsüberschreibungen
Mit Codeblöcken können Sie eine Warteschlange mit Aktionen erstellen, die vor allen weiteren Aktionen ausgeführt werden, die vom LLM bestimmt werden, und diese möglicherweise überschreiben. Mit der globalen Funktion add_override können Sie Aktionsüberschreibungen erstellen.
Alle in der Warteschlange befindlichen Überschreibungsaktionen werden nacheinander ausgeführt und die Aktionsausgabe ist für den LLM verfügbar. Sobald die Warteschlange leer ist, kehrt der Vorgang zur Auswahl von Aktion und Eingabe zum LLM zurück, es sei denn, ein Überschreiben beendet die Runde mit respond oder einer anderen Funktion, die die Runde abschließt.
Funktionsargumente:
- action: Die auszuführende Aktion.
Verwenden Sie für eine Inline-Aktion
my_function_name
. Verwenden Sie für eine Toolaktiontools.my_tool_name.my_tool_action
. Verwenden Sie für eine Ablaufaktionflows.my_flow_name
. - inputs: Optionale Eingaben für die Aktion.
Beispiel:
{"location": "Omaha"}
.
Beispiele:
# Assuming remote tool named "dmv" with operationId "search_offices"
# remote tool with only requestBody
add_override(tools.dmv.search_offices,{"address": "95030"})
# remote tool with only parameters
add_override(tools.pets.get_pet, {"id": "123"})
# remote tool with requestBody + parameters:
add_override(tools.pets.create_pet, {"requestBody": {"arg1":"foo"}, "param1": "bar"})
# datastore. Assumes existing datastore tool named "Menu".
add_override(tools.menu.Menu, {"query": "what is the menu"})
# code block action. Assumes another code block @Action my_action.
add_override(my_action)
Antwortüberschreibungen
Ähnlich wie bei Aktionsüberschreibungen, aber speziell für die Antworten von Kundenservicemitarbeitern, können Sie die globale Funktion respond verwenden, um den Kundenservicemitarbeiter dazu zu zwingen, dem Nutzer mit bestimmten Inhalten zu antworten.
Beispiel:
respond("Hello")
Anruftools
In den Codeblockfunktionen können Sie die für Ihren Bot definierten Tools aufrufen. Im Gegensatz zum Überschreiben einer Tool-Aktion sind die Ergebnisse der Toolausführung beim direkten Aufruf eines Tools nicht für das LLM verfügbar.
Beispiele:
# Assumes existing tool named "DMV" with operationId "search_offices"
# remote tool with only request body.
offices = tools.dmv.search_offices({"address": "95030"})
# remote tool with parameters and request body
offices = tools.dmv.search_offices({"requestBody": {"address":"95030"}, "param1":"foo"})
# datastore actions. Assumes existing datastore tool named "Menu".
data = tools.menu.Menu({"query": "get the menu"})["snippets"]
Übereinstimmende Absicht
Codeblöcke können mithilfe der Funktion Flow.match_intent programmatisch mit einer Absicht für einen bestimmten Ablauf abgeglichen werden.
Beispiel:
matches = flows.flow1.match_intent(history.last_user_utterance).matches
if matches and matches[0].intent == "some_intent":
to_country = matches[0].parameters.get("to_country")
if to_country:
respond(f"To confirm, you're going to {to_country}, right?")
Debugging
Mit dem Simulator können Sie die Funktionen Ihres Codeblocks beheben. Diese Funktionen werden im Simulator als Aktionen angezeigt und enthalten bei Bedarf unsere Details.
Zusätzliche Einstellung
In diesem Leitfaden werden einige gängige Verwendungen der Codeblock-Systembibliothek beschrieben. Weitere Steuerelementtypen finden Sie in der Bibliotheksdokumentation.