In meinem Letzter Beitragwie man mithilfe des JSON-Modus, Funktionsaufrufen und strukturierten Ausgaben strukturierte, maschinenlesbare Ausgaben als Antwort von einem LLM erhält. In diesem Beitrag haben wir die Idee des Funktionsaufrufs kurz angesprochen und ihn als Methode zum Erhalten strukturierter Antworten betrachtet. Dennoch geht der Funktionsaufruf weit über das bloße Zurückholen strukturierter Daten aus einem Modell hinaus, da er im Wesentlichen das Rückgrat von darstellt Agentische KI-Workflows. Deshalb werden wir uns im heutigen Beitrag genau mit diesem Thema beschäftigen.
In allen Beispielen, die wir bisher behandelt haben, wird der LLM nur als passiver Responder verwendet, das heißt, er empfängt eine Frage und generiert dann eine Antwort, und das conflict’s. Was aber, wenn wir wollen, dass das LLM nicht nur mit etwas antwortet, sondern mit etwas? etwas tun? Oder genauer gesagt: Was wäre, wenn wir möchten, dass eine Aktion basierend auf der Reaktion des Modells ausgelöst wird? Diese Aktion kann alles sein: Reside-Daten nachschlagen, eine Nachricht senden, eine Datenbank abfragen, eine externe API aufrufen und so weiter.
Möglich wird dies mit Werkzeugaufruf. Der Werkzeugaufruf verwandelt einen LLM von einem sehr intelligenten Textgenerator in etwas, das tatsächlich Aktionen auslösen und mit der Welt um ihn herum interagieren kann.
Additionally schauen wir mal rein!
Was ist Software Calling?
Werkzeugaufruf (auch genannt Funktionsaufruf) ist der Mechanismus, mit dem ein LLM im Rahmen der Generierung seiner Antwort die Ausführung externer Funktionen oder APIs anfordern kann. Mit anderen Worten: Anstatt nur Textual content zurückzugeben, kann das Modell eine bestimmte Funktion mit bestimmten Argumenten als Antwort auf die Anfrage des Benutzers ausführen.
Das Wichtigste, was es hier zu verstehen gilt, ist Folgendes Das Modell selbst führt das Werkzeug nicht aus. Es nur entscheidet welches Software aufgerufen werden soll und mit welchen Argumenten. Die eigentliche Ausführung des ausgewählten Instruments erfolgt in unserem eigenen Code, in dem die Anfrage an das KI-Modell enthalten ist. Anschließend geben wir das Ergebnis des Instruments an das KI-Modell zurück, das daraus eine endgültige Antwort an den Benutzer generiert.
Dies ist die Werkzeugaufrufschleife, die die folgenden Schritte umfasst:
- Der Benutzer sendet eine Nachricht
- Das KI-Modell nimmt die Nachricht als Eingabe und erzeugt eine Ausgabe, bei der es sich im Wesentlichen um die Entscheidung darüber handelt, welches Software mit welchen Argumenten verwendet werden soll
- Die Antwort des Modells, die die Werkzeugauswahl und die jeweiligen zu verwendenden Argumente enthält, wird an den Code zurückgegeben. Der Code führt – ohne Beteiligung des KI-Modells – das ausgewählte Software mit den ausgewählten Argumenten aus. Diese Ausführung erzeugt ein Ergebnis (z. B. eine Berechnung, von einer API erhaltene Informationen usw.), und dieses Ergebnis wird dann an das KI-Modell zurückgegeben.
- Das KI-Modell verwendet als Eingabe das Ergebnis des Instruments und erstellt darauf basierend eine endgültige Antwort an den Benutzer.
Auch hier generiert das Modell einen Werkzeugaufruf, keine Werkzeugausführung. Die beiden Dinge sind sehr unterschiedlich und ihre Vermischung ist eine der häufigsten Ursachen für Verwirrung.
Aber was genau ist ein Software-Aufruf? In der Praxis bedeutet dies, dass das Modell mithilfe von Funktionsaufrufen eine strukturierte, maschinenlesbare Antwort zurückgibt, wie wir im vorherigen Beitrag gesehen haben. In dieser Antwort ist Inhalt None; Es gibt keine Antwort in natürlicher Sprache, sondern lediglich eine strukturierte Anweisung, die angibt, welches Software mit welchen Argumenten aufgerufen werden soll. Erst nachdem wir das Software ausgeführt und das Ergebnis zurückgegeben haben, generiert das Modell eine tatsächliche Textantwort für den Benutzer.
Aber schauen wir uns das mal in der Praxis an!
Wir beginnen mit einem einfachen Beispiel mit nur einem Software und einem Aufruf und bauen dann schrittweise auf einige interessantere Szenarien auf.
1. Ein einziges Software: Wetter-API
Ich denke, das häufigste Beispiel für die Verwendung von Instruments mit KI, das mir in den Sinn kommt, ist eine Wetter-API (der Grundstein für benutzerdefinierte Reside-Daten). Stellen wir uns additionally vor, wir entwickeln einen Wetterassistenten. Insbesondere möchten wir einen Mechanismus schaffen, bei dem der Benutzer nach dem Wetter fragt, und anstatt das KI-Modell einfach etwas erfinden zu lassen (was das Modell sehr gerne tun würde 🙃), möchten wir, dass es eine echte Wetterfunktion aufruft und tatsächliche Daten über das Wetter von irgendwo anders außerhalb des LLM erhält. Um die Wetterdaten zu erhalten, werde ich verwenden Open-Meteoeine kostenlose Open-Supply-Wetter-API, die erfreulicherweise keinen API-Schlüssel erfordert.
Um ein Software verwenden zu können, müssen wir es zunächst in deklarieren instruments.
from openai import OpenAI
import json
shopper = OpenAI(api_key="your_api_key")
# Step 1: outline the software
instruments = (
{
"kind": "operate",
"operate": {
"identify": "get_current_weather",
"description": "Get the present climate for a given metropolis",
"parameters": {
"kind": "object",
"properties": {
"metropolis": {
"kind": "string",
"description": "The identify of town, e.g. Athens"
},
"unit": {
"kind": "string",
"enum": ("celsius", "fahrenheit"),
"description": "The temperature unit to make use of"
}
},
"required": ("metropolis")
}
}
}
)Beachten Sie, dass das tatsächlich zu verwendende Software (die Wetter-API) bisher nirgendwo erwähnt wird. Stattdessen entscheidet das Modell anhand von drei Dingen, welches Software aufgerufen werden soll: der Funktionsbeschreibung („Erhalten Sie das aktuelle Wetter für eine bestimmte Stadt“), die Parameterbeschreibungen („Der Title der Stadt, z. B. Athen“) und das erzwungene Schema. Allein anhand dieser Informationen findet das Modell heraus, ob und mit welchen Argumenten dies das richtige Software ist, um eine bestimmte Benutzernachricht aufzurufen. Daher ist das Verfassen klarer und genauer Beschreibungen bei der Definition unserer Instruments von entscheidender Bedeutung, damit das Modell das richtige Software basierend auf den Eingaben des Benutzers erfolgreich identifizieren und aufrufen kann.
Nachdem wir additionally die Instruments-Variable definiert haben, können wir eine Anfrage an das KI-Modell stellen:
# Step 2: ship the person message together with the software definition
messages = (
{"function": "person", "content material": "What is the climate like in Athens proper now?"}
)
response = shopper.chat.completions.create(
mannequin="gpt-4o-mini",
instruments=instruments,
messages=messages
)
print(response.selections(0).message)Folgendes passiert, wenn wir diese Anfrage stellen. Das Modell liest die Nachricht des Benutzers, „Wie ist das Wetter gerade in Athen?“und versteht, dass das verfügbare Software get_current_weather kann helfen, diese Frage mit echten Reside-Daten zu beantworten. Anstatt additionally direkt eine Textantwort zu generieren, wird beschlossen, zuerst das Software aufzurufen. Genauer gesagt sieht die Reaktion des Modells zu diesem Zeitpunkt wie folgt aus:
ChatCompletionMessage(
content material=None,
function='assistant',
tool_calls=(
ChatCompletionMessageToolCall(
id='call_abc123',
kind='operate',
operate=Operate(
identify='get_current_weather',
arguments='{"metropolis": "Athens", "unit": "celsius"}'
)
)
)
)Beachten Sie, wie der Inhalt ist Noneda das Modell keine Textantwort zurückgibt, sondern ein Software-Aufruf. Jetzt ist es unsere Aufgabe, das Werkzeug tatsächlich auszuführen, das Modell auszuwählen und das Ergebnis an dieses zurückzugeben. In unserem Fall wird dazu die API-Anfrage an die Wetter-API gestellt und dabei die Argumente (d. h. die Stadt und die Maßeinheit) verwendet, die in der Antwort des KI-Modells bereitgestellt werden:
# Step 3: execute the software utilizing the Open-Meteo API
import requests
def get_current_weather(metropolis: str, unit: str = "celsius"):
# geocode town identify to coordinates
geo = requests.get(
"https://geocoding-api.open-meteo.com/v1/search",
params={"identify": metropolis, "rely": 1}
).json()
lat = geo("outcomes")(0)("latitude")
lon = geo("outcomes")(0)("longitude")
# fetch present climate
climate = requests.get(
"https://api.open-meteo.com/v1/forecast",
params={
"latitude": lat,
"longitude": lon,
"present": "temperature_2m,weather_code",
"temperature_unit": unit
}
).json()
temp = climate("present")("temperature_2m")
return {"metropolis": metropolis, "temperature": temp, "unit": unit}
# extract the software name from the response
tool_call = response.selections(0).message.tool_calls(0)
arguments = json.masses(tool_call.operate.arguments)
# name the precise operate
weather_result = get_current_weather(**arguments)Anschließend können wir das Ergebnis des Instruments an den Nachrichtenverlauf anhängen und dann alles an das Modell zurücksenden:
# Step 4: add the assistant's software name AND the software outcome to the message historical past
messages.append(response.selections(0).message) # necessary: append the software name first
messages.append({
"function": "software",
"tool_call_id": tool_call.id, # hyperlinks the outcome again to the precise software name
"content material": json.dumps(weather_result)
})
# Step 5: ship every part again to the mannequin for a closing response
final_response = shopper.chat.completions.create(
mannequin="gpt-4o-mini",
instruments=instruments,
messages=messages
)
print(final_response.selections(0).message.content material)Und jetzt bekommen wir endlich eine richtige Textantwort:
It is presently 29°C in Athens. Feels like an important day to be outdoors!🍨 DataCream ist ein Publication mit Geschichten und Tutorials zu KI, Daten und Technologie. Wenn Sie sich für diese Themen interessieren, Abonnieren Sie hier!
2. Das Modell aus mehreren Werkzeugen auswählen lassen
Schauen wir uns nun ein realistischeres Beispiel an. In einer realen Agentenanwendung hat das Modell normalerweise Zugriff auf nicht nur einen, sondern mehrere Daher muss anhand der Anforderungen des Benutzers ermittelt werden, welche Instruments verwendet werden müssen.
Erweitern wir unser erstes Wetter-API-Beispiel, indem wir ein zusätzliches Software für Währungen hinzufügen. Dafür verwenden wir Frankfurtereine Währungs-API, die Tageskurse der Europäischen Zentralbank bereitstellt, wiederum ohne API-Schlüssel-Anforderung. Additionally, lasst uns unsere aktualisieren instruments variabel durch Hinzufügen eines zweiten Instruments zur Währungsumrechnung:
instruments = (
{
"kind": "operate",
"operate": {
"identify": "get_current_weather",
"description": "Get the present climate for a given metropolis",
"parameters": {
"kind": "object",
"properties": {
"metropolis": {"kind": "string", "description": "The identify of town"},
"unit": {"kind": "string", "enum": ("celsius", "fahrenheit")}
},
"required": ("metropolis")
}
}
},
{
"kind": "operate",
"operate": {
"identify": "convert_currency",
"description": "Convert an quantity from one foreign money to a different",
"parameters": {
"kind": "object",
"properties": {
"quantity": {"kind": "quantity", "description": "The quantity to transform"},
"from_currency": {"kind": "string", "description": "The supply foreign money code, e.g. USD"},
"to_currency": {"kind": "string", "description": "The goal foreign money code, e.g. EUR"}
},
"required": ("quantity", "from_currency", "to_currency")
}
}
}
)Und auch das eigentliche einrichten convert_currency Funktion mit der Frankfurter API:
def convert_currency(quantity: float, from_currency: str, to_currency: str):
response = requests.get(
f"https://api.frankfurter.dev/v2/charge/{from_currency}/{to_currency}"
).json()
charge = response("charge")
transformed = spherical(quantity * charge, 2)
return {
"quantity": quantity,
"from_currency": from_currency,
"to_currency": to_currency,
"converted_amount": transformed,
"charge": charge
}Auf diese Weise kann das Modell ein viel größeres Spektrum an Benutzeranfragen verarbeiten; Es kann jetzt zusätzlich zum Wetter auch Fragen zu Währungen beantworten 😋. Nun, wenn der Benutzer fragt „Wie ist das Wetter in Athen?“sollte das Modell aufrufen get_current_weather. Wenn sie fragen „Wie viel sind 100 USD in EUR?“es sollte anrufen convert_currency. Und wenn wir etwas fragen, das weder für das Wetter noch für Währungen related ist und bei dem keines der verfügbaren Instruments weiterhelfen kann, antwortet das Modell einfach in Textform, ohne überhaupt ein Software aufzurufen.
Aber sehen wir uns das in Aktion an:
messages = (
{"function": "person", "content material": "How a lot is 200 USD in EUR?"}
)
response = shopper.chat.completions.create(
mannequin="gpt-4o-mini",
instruments=instruments,
messages=messages
)
tool_call = response.selections(0).message.tool_calls(0)Werfen wir einen Blick auf die Antwort:
print(tool_call.operate.identify) von dem wir bekommen convert_currency. Das Modell verstand additionally, dass die Frage „Wie viel sind 200 USD in EUR?“ ist related für die convert_currency Werkzeug. Werfen wir auch einen Blick auf die Argumente:
print(tool_call.operate.arguments) von dem wir bekommen
'{"quantity": 200, "from_currency": "USD", "to_currency": "EUR"}'
Das Modell identifiziert additionally korrekt convert_currency als das richtige Werkzeug und trägt die entsprechenden Argumente ein, ohne dass wir etwas anderes tun müssen, als entsprechende Werkzeugbeschreibungen bereitzustellen und dem Benutzer eine entsprechende Nachricht zu übermitteln. Dieser genaue Entscheidungsmechanismus macht Software-Calling zur Grundlage von Agentensystemen.
3. Mehrere Instruments gleichzeitig aufrufen
Ein weiteres interessantes Software-Aufrufszenario besteht darin, dass viele Modelle wie gpt-4okann mehrere Instruments in einer einzigen Antwort aufrufen, wenn die Anfrage des Benutzers dies erfordert. Dies ist bekannt als paralleler Werkzeugaufruf.
Stellen wir uns zum Beispiel ein Szenario vor, in dem der Benutzer in einer einzigen Anfrage etwas fragt, das die Verwendung beider erfordert get_current_weather Und convert_currency Instruments, um die erforderlichen Informationen zu erhalten:
messages = (
{"function": "person", "content material": "What is the climate in Athens and the way a lot is 100 USD in EUR?"}
)
response = shopper.chat.completions.create(
mannequin="gpt-4o-mini",
instruments=instruments,
messages=messages
)
for tool_call in response.selections(0).message.tool_calls:
print(tool_call.operate.identify)
print(tool_call.operate.arguments)In diesem Fall erhalten wir folgende Antwort:
get_current_weather
{"metropolis": "Athens"}
convert_currency
{"quantity": 100, "from_currency": "USD", "to_currency": "EUR"}Beachten Sie, wie beide Instruments in einer einzigen Modellantwort aufgerufen werden. Anschließend können wir die jeweiligen Instruments mit den bereitgestellten Argumenten ausführen und die Software-Ergebnisse gemeinsam an das Modell zurückgeben. Dies ist viel effizienter als sequentielle Aufrufe und ist die Artwork und Weise, wie fortgeschrittenere Agenten mehrteilige Anfragen verarbeiten.
In meinen Gedanken: Was macht diesen Agenten aus?
Eine Sache, die mir immer auf die Nerven gegangen ist, ist der Begriff „Agent“, der auf alles geschoben wird. Agenten, Agenten-Workflows, alles, was aus dem Wort hervorgeht Agent ist heutzutage sehr attractive, aber wie Sie vielleicht schon selbst herausgefunden haben, ist nicht alles, was als Agent verkauft wird, wirklich attractive.
Machen wir additionally einen Schritt zurück und denken wir darüber nach, was ein Agent überhaupt ist. Im Kern ist ein Agent etwas, das seine Umgebung wahrnimmt, diese Informationen auf irgendeine Weise verarbeitet, ein Ziel hat und dann entscheidet, welche Maßnahmen es ergreifen muss, um dieses Ziel zu erreichen. Denken Sie darüber nach, was unser Software-Aufrufmechanismus tut: Er erkennt die verfügbaren Instruments, entscheidet, welches für die Anfrage des Benutzers (falls vorhanden) geeignet ist, und gibt diese Entscheidung zur Ausführung an den Relaxation des Codes weiter. Das ist in seiner einfachsten Kind Handlungsfreiheit.
In realen Agentenanwendungen wird die Software-Aufrufschleife nicht nur einmal, sondern mehrere Male ausgeführt, wobei das Modell anhand der Ergebnisse eines Software-Aufrufs entscheidet, ob und welches Software als nächstes aufgerufen werden soll. Dies wird manchmal als a bezeichnet ReAct-Schleife (Grund + Handeln) und ermöglicht es Agenten, komplexe, mehrstufige Aufgaben zu bewältigen, die nicht in einem einzigen Anruf gelöst werden können.
Letztendlich finde ich am Software-Calling am faszinierendsten, wie es die Natur dessen, was ein LLM ist, verändert. Bis zu diesem Zeitpunkt conflict ein Sprachmodell im Wesentlichen ein sehr ausgefeilte Eingabe-Ausgabe-Funktion, die Textual content als Eingabe verwendet und Textual content als Ausgabe generiert. Aber mit dem Software-Aufruf erhalten wir Zugriff auf eine endlose Sammlung zusätzlicher Funktionalitäten, die wir mit der Argumentationsleistung des LLM kombinieren können, um Systeme zu schaffen, die weitaus leistungsfähiger sind als beide allein.
✨ Danke fürs Lesen! ✨
Wenn du es bis hierher geschafft hast, Vielleicht finden Sie Pialgorithmen nützlich – eine von uns entwickelte Plattform, die Groups dabei hilft, organisatorisches Wissen sicher an einem Ort zu verwalten.
Hat Ihnen dieser Beitrag gefallen? Begleiten Sie mich 💌Unterstapel und 💼LinkedIn
Alle Bilder vom Autor, sofern nicht anders angegeben.