Was ist Function Calling? So nutzt KI Werkzeuge Schritt für Schritt

Was ist Function Calling?

Function Calling bedeutet, dass ein KI Modell entscheidet, welche Ihrer vorab definierten Funktionen es mit welchen Argumenten aufrufen möchte. Das Modell führt die Funktion nicht selbst aus. Es liefert einen strukturierten Aufrufvorschlag, Ihre Anwendung führt ihn aus, und das Ergebnis geht zurück an das Modell.

Stellen Sie sich ein Restaurant vor. Der Gast nennt dem Kellner seinen Wunsch, und der Kellner schreibt einen Bon, den die Küche versteht. Der Kellner kocht nämlich nicht, denn das macht die Küche. Beim Function Calling ist das Modell der Kellner, und Ihr Code ist die Küche.

Dieses Bild zeigt zudem ein Risiko. Was auf dem Bon steht, wird gekocht, deshalb sollte jemand den Bon vorher prüfen. Ebenso sollten Sie jeden Vorschlag des Modells validieren, bevor Sie ihn ausführen.

Dieser Artikel behandelt nur diesen einen Begriff. Verwandte Konzepte streifen wir daher kurz und verlinken unsere Ratgeber für die Details. Bei genauen Parameternamen gilt allerdings immer die offizielle Dokumentation des Anbieters.

Was ist Function Calling im Detail: Wie läuft der Ablauf Schritt für Schritt ab?

Der Ablauf hat vier Schritte, und die offiziellen Dokumentationen der großen Anbieter folgen demselben Grundgerüst. Die Details unterscheiden sich von API zu API, die Idee bleibt dennoch gleich.

1. Zunächst senden Sie dem Modell eine Liste der verfügbaren Funktionen mit Namen, Beschreibungen und Parametern.
2. Danach liest das Modell die Anfrage des Nutzers und entscheidet, ob eine Funktion nötig ist.
3. Ist das der Fall, liefert das Modell einen Aufrufvorschlag mit Funktionsname und Argumenten. Ihre Anwendung führt die Funktion in ihrer eigenen Umgebung aus.
4. Schließlich schicken Sie das Ergebnis zurück, und das Modell formuliert daraus eine natürliche Antwort.

Das heißt, zwischen Modell und Anwendung gibt es ein Hin und Her. Das Modell erzeugt nur Text und strukturierte Vorschläge. Somit bleibt alles, was die Außenwelt berührt, auf Ihrer Seite.

Die Dokumentation von OpenAI vergibt für jeden Aufruf eine Kennung und verlangt, dass Sie das Ergebnis dieser Kennung zuordnen. So weiß das Modell, welches Ergebnis zu welchem Aufruf gehört. Ebenso nutzt Anthropic dieselbe Zuordnung.

Führt das Modell die Funktion wirklich selbst aus?

Nein. Die Gemini Dokumentation von Google sagt es klar: Das Modell führt die Funktion nicht aus, Ihre Anwendung entnimmt Name und Argumente und führt sie aus. Außerdem beschreiben auch OpenAI und Anthropic diesen Ablauf.

Diese Trennung ist in der Praxis sehr wichtig. Berechtigungen, Protokolle, Fehlerbehandlung und Sicherheitsentscheidungen liegen nämlich vollständig in Ihrem Code. Das Modell verbindet sich nicht von allein mit einer Datenbank, nimmt keine Zahlung an und versendet keine E-Mail.

Allerdings gibt es eine Ausnahme. Manche Anbieter stellen fertige Werkzeuge bereit, die auf ihrer eigenen Infrastruktur laufen, etwa die Websuche. Man nennt sie Server Tools, und der Anbieter führt sie aus. Deshalb gilt der Ablauf in diesem Artikel für Funktionen, die Sie selbst definieren.

Wer ausführt, trägt also auch die Verantwortung. Fällt Ihre eigene Funktion aus, liegt der Fehler somit bei Ihnen. Planen Sie daher Tests, Protokolle und Überwachung von Anfang an ein.

Zum Beispiel fragt ein Kunde im Support Bot: "Wo ist mein Paket?" Das Modell schreibt dann nur die Abfrage. Der Code, der das Versandsystem anspricht, die Identität prüft und die Antwort liefert, gehört Ihnen. Somit fangen Sie Fehler auf Ihrer Seite ab.

Aus welchen Teilen besteht eine Funktionsdefinition?

Eine Funktionsdefinition besteht aus drei Hauptteilen. Je sorgfältiger Sie diese schreiben, desto treffsicherer wählt das Modell, denn es hat nur diese Informationen.

• Name: ein kurzer, aussagekräftiger Name für genau eine Aufgabe, zum Beispiel get_order_status.
• Beschreibung: einfache Sätze, die sagen, was die Funktion tut, wann man sie nutzt und wann nicht.
• Parameterschema: Name, Typ und Pflichtstatus jedes Arguments. Die Anbieter nutzen dafür konkret JSON Schema.

Zunächst: Die Beschreibung ist der am meisten unterschätzte Teil. Das Modell stützt sich bei der Auswahl vor allem auf diesen Text. Eine vage Beschreibung führt deshalb zu falschen Treffern, eine klare zu richtigen.

Außerdem bieten manche Anbieter einen strikten Modus. Dann passen die vom Modell erzeugten Argumente exakt zu Ihrem Schema. Prüfen Sie aktuelle Optionen und Einstellungsnamen in der offiziellen Dokumentation.

Halten Sie daher freie Textfelder knapp. Definieren Sie nach Möglichkeit feste Auswahllisten, denn bei begrenzten Optionen macht das Modell weniger Fehler.

Trennen Sie außerdem Pflichtfelder und optionale Felder bewusst. Fehlt ein Pflichtfeld, sollte das Modell dann den Nutzer fragen. Häufen sich optionale Felder, neigt das Modell zum Raten.

Wie schreiben Sie eine Funktionsbeschreibung, damit das Modell richtig wählt?

Behandeln Sie die Beschreibung wie eine Stellenanzeige für das Modell. Sagen Sie also, was die Funktion tut, wann sie greift und was sie nicht anfasst. Denn eine vage Anzeige zieht den falschen Bewerber an.

• Nennen Sie die Aufgabe in einem Satz: "Liefert den aktuellen Status einer Bestellung zur Bestellnummer."
• Nennen Sie die Grenze: "Startet keine Rückgabe und keinen Umtausch, sie liest nur den Status."
• Zeigen Sie das Argumentformat: "Die Bestellnummer ist ein kurzer Code aus Buchstaben und Ziffern."
• Klingen zwei Funktionen ähnlich, erklären Sie den Unterschied deutlich, denn hier irren Modelle am häufigsten.
• Erklären Sie nicht zu viel. Jeder zusätzliche Satz erhöht außerdem die Tokenkosten.

Verwenden Sie zudem ein einheitliches Namensmuster. Beginnen Sie vor allem jeden Namen mit einem Verb und nennen Sie das Objekt. So finden sowohl das Modell als auch Ihr Team schnell, was sie suchen.

Wie entscheidet das Modell, welche Funktion es wann aufruft?

Das Modell entscheidet anhand der Nutzernachricht, des bisherigen Gesprächs und Ihrer Funktionsbeschreibungen. Die Dokumentation von Anthropic fasst es so zusammen: Passt die Anfrage zur beschriebenen Fähigkeit eines Werkzeugs und fehlt die Antwort im Kontext, ruft das Modell das Werkzeug auf. Bei stabilem Wissen, kreativen Aufgaben und Smalltalk antwortet es dagegen direkt.

Dieses Verhalten steuern Sie daher auf drei Wegen. Erstens schärfen Sie die Beschreibungen. Zweitens ergänzen Sie in der Systemanweisung eine Regel wie "prüfe unbekannte Fakten mit einem Werkzeug". Drittens stellen Sie den Auswahlmodus ein.

Die Modusnamen unterscheiden sich allerdings je nach Anbieter. Prüfen Sie daher die genauen Werte in der offiziellen Dokumentation.

Was ist Function Calling im Vergleich zu Tool Use?

Kurz gesagt, im Kern ist es dieselbe Idee. Anthropic verwendet den Begriff Tool Use und schreibt, dass er auch Function Calling heißt. Dagegen bevorzugen OpenAI und Google den Namen Function Calling. Alle drei beschreiben dasselbe Muster.

Es gibt allerdings einen feinen Unterschied. Ein "Tool" ist der breitere Oberbegriff. Es kann zum Beispiel eine Funktion sein, die Sie geschrieben haben. Es kann aber auch eine Websuche oder ein Werkzeug zur Codeausführung sein, das der Anbieter betreibt.

Kurz gesagt, im Alltag sind beide Begriffe austauschbar. Bei Architekturfragen stellen Sie dagegen diese eine Frage: Wer führt den Aufruf aus, Sie oder der Anbieter?

Bei der Recherche führen die Suchen nach "Tool Calling", "Tool Use" und "Function Calling" meist zu denselben Seiten. Suchen Sie beim Lesen der Dokumentation daher nach allen drei Begriffen.

Kann ein Modell mehrere Funktionen gleichzeitig aufrufen?

Ja, denn die Modelle erlauben das. Die Dokumentation von Google trennt zwei Fälle: parallele Aufrufe für unabhängige Aufgaben und verkettete Aufrufe für Aufgaben, die aufeinander aufbauen.

Zum Beispiel fragt ein Nutzer: "Wie ist der Status meiner Bestellung, und wie lauten die Rückgabebedingungen?" Bestellabfrage und Richtliniensuche brauchen einander nicht, also kann das Modell beide in einer Runde vorschlagen. Bei einer Terminbuchung müssen Sie dagegen zuerst freie Zeiten abfragen und danach den gewählten Termin speichern. Diese Aufrufe laufen dann nacheinander.

Parallele Aufrufe sparen also Zeit. Allerdings kann jeder Aufruf einzeln scheitern, deshalb müssen Sie jedes Ergebnis korrekt zugeordnet zurückgeben.

Die Dokumentationen von OpenAI und Anthropic bieten außerdem eine Einstellung, die pro Runde höchstens einen Aufruf erlaubt. Bei kritischen Aktionen erleichtert sie Ihnen die Arbeit, weil Sie jeden Schritt einzeln prüfen.

Wie unterscheiden sich die Ansätze von OpenAI, Anthropic und Google?

Alle drei Anbieter nutzen denselben Kernablauf, doch Begriffe und Einstellungen unterscheiden sich. Die Tabelle fasst nur die konzeptionellen Unterschiede zusammen, die wir in den offiziellen Dokumentationen gesehen haben. Prüfen Sie Einstellungsnamen und aktuelles Verhalten daher immer dort nach.

Wenn Sie den Anbieter wechseln, können Sie Ihre Funktionslogik also mitnehmen. Die Details der Ausführungsschicht schreiben Sie dagegen neu. Halten Sie diese Schicht deshalb anbieterneutral, dann bleiben Sie später flexibel.

Für welche Geschäftsszenarien lohnt sich Function Calling?

Ein Modell erreicht von allein weder aktuelle Daten noch kann es Aktionen auslösen. Zudem schließt Function Calling beide Lücken. Daher lohnt es sich überall, wo Sie ein Gespräch mit echter Arbeit verbinden wollen.

• Abfrage von Bestell- und Versandstatus.
• Anlegen, Ändern und Stornieren von Terminen.
• Prüfung von Lagerbestand und Preisen.
• Kundendatensatz im CRM finden und Notiz ergänzen.
• Daten für einen Bericht holen und zusammenfassen.
• Support Ticket eröffnen und an das richtige Team leiten.

Allen gemeinsam ist dasselbe Muster: Das Modell versteht die Absicht, der Code erledigt die Arbeit. Hat Ihr Produkt also einen Assistenten, der plaudern, aber nicht handeln kann, fehlt das Function Calling als Bindeglied.

Auch Marketing und Vertrieb profitieren davon. Ein Formular Bot kann zum Beispiel das Interesse eines Besuchers erkennen und den Lead im CRM anlegen. Wichtig ist, dass Sie seine Berechtigung für diesen Eintrag eng halten.

Wie sieht der Ablauf bei einem Terminassistenten aus?

Das ist also ein Beispielszenario. Denken Sie an ein Beratungsunternehmen. Ein Kunde schreibt: "Können wir am Freitagnachmittag ein Gespräch vereinbaren?"

1. Das Modell schlägt vor, die Funktion get_available_slots aufzurufen, und übergibt den Tag als Argument.
2. Danach fragt Ihre Anwendung das Kalendersystem ab und gibt die Liste an das Modell zurück.
3. Das Modell nennt dem Kunden die Optionen, und der Kunde wählt eine Uhrzeit.
4. Danach schlägt das Modell die Funktion create_appointment vor. Fehlt etwas, etwa eine Telefonnummer, fragt es zuerst nach.
5. Ihre Anwendung legt den Eintrag an und sendet das Ergebnis zurück. Dann schreibt das Modell die Bestätigung.

Beachten Sie: Das Anlegen des Eintrags ist konkret eine Schreibaktion. Deshalb ist die ausdrückliche Zustimmung des Nutzers sinnvoll. Darauf kommen wir in den Sicherheitsabschnitten zurück.

Überlegen Sie außerdem, was geschieht, wenn das Kalendersystem in Schritt zwei ausfällt. Meldet Ihre Anwendung den Fehler an das Modell, antwortet es dem Kunden ehrlich. Schweigt sie stattdessen, erfindet das Modell womöglich eine Uhrzeit.

Fragen Sie am Ende zudem nach einer Zusammenfassung. Sagt das Modell "Ich habe ein Gespräch für Freitag gebucht", muss dieser Satz auf einem echten, erfolgreichen Eintrag beruhen. Gibt es keinen Eintrag, darf folglich auch keine Bestätigung erscheinen.

Wie unterscheidet sich Function Calling von MCP?

Function Calling ist die Fähigkeit eines Modells, einen Werkzeugaufruf vorzuschlagen. MCP ist dagegen ein offenes Protokoll, das standardisiert, wie Werkzeuge dem Modell angeboten werden. Anders gesagt: Das eine ist eine Fähigkeit, das andere ein Verbindungsstandard.

Folglich schlägt das Modell auch mit MCP im Hintergrund weiterhin einen Aufruf vor. Der Unterschied: Sie holen die Werkzeugdefinitionen von einem gemeinsamen Server, statt sie in jeder App von Hand zu schreiben. Mehr dazu lesen Sie in unserem Ratgeber Was ist MCP.

In der Praxis reicht in kleinen Projekten mit nur einer Anwendung reines Function Calling meist aus. Nutzen Sie dieselben Werkzeuge in mehreren Anwendungen, lohnt sich ein Blick auf MCP.

Als Faustregel gilt: Haben Sie wenige Werkzeuge in einer App, bleiben Sie einfach. Teilen mehrere Teams viele Werkzeuge, senkt ein gemeinsamer Standard den Pflegeaufwand. Außerdem schließen sich beide nicht aus.

Wie unterscheidet sich Function Calling von Structured Outputs?

Bei Structured Outputs wollen Sie die Antwort des Modells als Daten erhalten, die zu Ihrem Schema passen. Beim Function Calling wollen Sie dagegen eine Aktion auslösen. Beide nutzen Schemas, doch ihre Ziele unterscheiden sich deutlich.

Zum Beispiel genügen Structured Outputs, wenn Sie aus einer E-Mail Bestellnummer und Betrag herausziehen möchten. Wollen Sie die Bestellung des Kunden in Ihrem System nachschlagen, brauchen Sie Function Calling. Manchmal kombinieren Sie beides: Das Modell ruft zuerst die Funktion auf und formuliert die Antwort danach im passenden Schema.

Das Thema behandeln wir ausführlich im Artikel über Structured Outputs. Daher erwähnen wir es hier nur zum Vergleich.

Wie verhalten sich Function Calling, MCP, Structured Outputs und RAG zueinander?

Diese vier Konzepte werden oft verwechselt, deshalb lohnt der Vergleich. Die Tabelle fasst die Kernaufgabe jedes Konzepts zusammen und zeigt, wer die Arbeit ausführt.

Den Abruf von Dokumenten behandeln wir im Ratgeber Was ist RAG. In der Praxis kann ein Agent die Dokumentensuche sogar als Funktion aufrufen. Die Konzepte ergänzen sich also, statt zu konkurrieren.

Wie hängen Function Calling und KI Agenten zusammen?

Ein KI Agent ist oft Function Calling in einer Schleife. Das Modell schlägt eine Funktion vor, die Anwendung führt sie aus, und das Modell schaut aufs Ergebnis und entscheidet den nächsten Schritt. Die Schleife läuft, bis das Modell sagt, dass es fertig ist.

Function Calling ist also der Baustein, der Agent das größere Konzept. Ein Agent setzt ein Ziel, plant Schritte und nutzt Werkzeuge nacheinander. Ein einzelner Aufruf macht dagegen noch keinen Agenten.

Sobald Sie eine Schleife bauen, gelten zwei Sicherheitsregeln. Erstens begrenzen Sie die Zahl der Schritte. Zweitens wiederholen Sie die Rechteprüfung in jedem Schritt. Sonst könnte das Modell endlos Werkzeuge aufrufen oder seinen Spielraum selbst erweitern.

Zur Agenten Architektur finden Sie am Ende dieses Artikels weiterführende Links. Hier ziehen wir daher nur die Verbindung.

Welche Sicherheitsrisiken bringt Function Calling mit sich?

Wer einem Modell die Fähigkeit zum Handeln gibt, vergrößert die Angriffsfläche. Denn Nutzernachrichten und gelesene Inhalte beeinflussen das Modell. Ein böswilliger Text kann es zur falschen Funktion oder zum falschen Argument lenken.

• Zu viele Rechte: Läuft eine Funktion mit mehr Rechten als nötig, richtet ein kleiner Fehler großen Schaden an.
• Prompt Injection: Eine in einem Dokument oder auf einer Webseite versteckte Anweisung kann das Modell in die Irre führen.
• Falsche Argumente: Das Modell kann fehlende Angaben raten und einen Wert erfinden.
• Datenabfluss: Weil das Funktionsergebnis zurück zum Modell geht, tauchen dort auch sensible Felder auf.

Das Thema behandeln wir in einem eigenen Artikel zu Prompt Injection. Kurz gesagt, Schemaprüfung ist keine Sicherheit. Ein Schema kontrolliert das Format, aber trotzdem nicht die Berechtigung.

Betrachten Sie außerdem Funktionsergebnisse als nicht vertrauenswürdige Eingaben. Ein Text von einer Webseite oder aus einer E-Mail kann für das Modell wie eine neue Anweisung aussehen.

Wie legen Sie Freigaben und Berechtigungsgrenzen fest?

Zunächst gilt das Grundprinzip minimale Rechte. Führen Sie jede Funktion nur mit den Berechtigungen aus, die ihre Aufgabe braucht. Trennen Sie Lese- und Schreibaktionen in eigene Funktionen.

• Bei Leseaktionen wie Abfragen und Listen kann die automatische Ausführung genügen.
• Bei Schreibaktionen wie Speichern, Stornieren und Senden holen Sie die ausdrückliche Zustimmung des Nutzers ein.
• Geben Sie unumkehrbare Aktionen wie Löschen und Bezahlen nie an das Modell oder binden Sie sie an eine menschliche Freigabe.
• Nehmen Sie außerdem die Identität des Nutzers aus der Sitzung. Überlassen Sie sie niemals einem Argument des Modells.
• Protokollieren Sie jeden Aufruf: welche Funktion, welche Argumente, für wen und mit welchem Ergebnis.

Legen Sie die Rechteprüfung daher in die Funktion und vertrauen Sie nicht dem Modell. Selbst bei einem falschen Vorschlag muss Ihr Code sagen können: "Dieser Nutzer darf das nicht."

Bereiten Sie sich außerdem auf wiederholte Aufrufe vor. Zum Beispiel kann nach einem Netzabbruch dieselbe Schreibaktion zweimal eintreffen. Entwerfen Sie sie so, dass ein zweiter Durchlauf keinen Schaden anrichtet.

Was passiert, wenn das Modell ein falsches Argument erzeugt?

Allerdings schlägt das Modell manchmal ein fehlendes oder falsches Argument vor. Lässt ein Nutzer eine Angabe aus, raten manche Modelle einen plausiblen Wert. Die Dokumentation von Anthropic sagt ausdrücklich, dass dieses Verhalten nicht garantiert ist.

Prüfen Sie deshalb jeden Aufruf vor der Ausführung. Kontrollieren Sie Typ, Wertebereich, Pflichtfelder und Geschäftsregeln. Lehnen Sie zum Beispiel einen Aufruf ab, der einen Termin in der Vergangenheit bucht.

Lehnen Sie einen Aufruf ab, senden Sie die Fehlermeldung an das Modell zurück. Danach versucht es meist erneut, indem es den Nutzer richtig fragt oder das Argument korrigiert. Setzen Sie allerdings eine Obergrenze für Wiederholungen, um Endlosschleifen zu vermeiden.

Der strikte Modus senkt dieses Risiko, beseitigt es aber nicht. Auch bei richtigem Format kann der Wert dennoch falsch sein. Ein Datum, das zum Schema passt, kann trotzdem das falsche Datum sein.

Wie wirkt sich Function Calling auf Kosten und Latenz aus?

Jede Funktionsdefinition geht als Teil der Anfrage an das Modell. Die Dokumentation von Anthropic nennt Namen, Beschreibungen und Schemas der Werkzeuge als Eingabe Tokens. Viele lange Definitionen erhöhen daher die Kosten.

Außerdem bedeutet der Ablauf mindestens zwei Modellaufrufe: einen für den Vorschlag und einen für die Auswertung des Ergebnisses. Das verlängert folglich die Antwortzeit. Aktuelle Preise und Limits finden Sie auf der offiziellen Seite des Anbieters.

Um Kosten zu senken, begrenzen Sie die Zahl der Funktionen auf das wirklich Nötige und halten Beschreibungen kurz. Die Logik der Tokens erklären wir im Ratgeber Was ist ein Token.

Fragen Sie sich, was ist Function Calling für Ihr Geschäft wert, dann beziehen Sie die Kosten ein, denn jede zusätzliche Definition und jede zusätzliche Runde kostet. Richtig aufgesetzt, senkt es dennoch manuelle Arbeit.

Ein Tipp gegen Latenz: Rufen Sie unabhängige Abfragen parallel auf. Dann wartet der Nutzer einmal und nicht viermal.

Welche typischen Fehler passieren bei Function Calling?

Das sind die Fallen, in die Teams bei den ersten Versuchen am häufigsten tappen. Zum Glück lassen sich alle vermeiden.

• Zu viele Funktionen anbieten. Je mehr Optionen, desto wahrscheinlicher die falsche Wahl.
• Mehrere Aufgaben in eine Funktion packen. Funktionen mit einer Aufgabe erzeugen weniger Fehler.
• Identität und Berechtigung aus Argumenten übernehmen. Die Nutzeridentität muss immer aus der Sitzung kommen.
• Fehlerzustände vor dem Modell verbergen. Bei Schweigen rät das Modell nämlich.
• Den Freigabeschritt überspringen. Schreibaktionen brauchen die Zustimmung des Nutzers oder eines Menschen.
• Keine Protokolle führen. Sonst sehen Sie bei einer Störung nicht, was aufgerufen wurde.
• Rohe Ergebnisse zurückgeben. Entfernen Sie vorher unnötige und sensible Felder.

Die meisten dieser Fehler stammen aus dem Code rund um das Modell, nicht vom Modell. Anders gesagt, der Erfolg hängt ebenso von Ihrer Technik ab wie von der Intelligenz des Modells.

Wie testen Sie einen Function Calling Ablauf?

Beginnen Sie mit Testfunktionen, bevor Sie echte Systeme anbinden. Denn eine Testfunktion liefert feste, vorhersehbare Antworten. So messen Sie ausschließlich die Entscheidungsqualität des Modells.

1. Erstellen Sie zunächst eine Szenarioliste aus echten Nutzernachrichten. Mischen Sie klare, vage und unvollständige Beispiele.
2. Notieren Sie pro Szenario die erwartete Funktion und die erwarteten Argumente.
3. Halten Sie fest, ob das Modell die richtige Funktion gewählt und die Argumente korrekt gefüllt hat.
4. Probieren Sie feindliche Eingaben getrennt aus: Aufforderungen, den Rahmen zu verlassen, Fragen nach fremden Daten, Texte mit versteckten Anweisungen.
5. Lassen Sie nach jeder Änderung dieselbe Liste erneut laufen, damit Sie Rückschritte erkennen.

Beobachten Sie zudem echte Aufrufe in Ihren Protokollen. Nach dem Start ergänzen Sie neue Situationen in der Szenarioliste. Wächst die Liste, wächst somit auch Ihre Qualität.

Was ist Function Calling nicht: Wann brauchen Sie es nicht?

Allerdings braucht nicht jede Aufgabe Function Calling. Hat ein Prozess feste Schritte und klare Regeln, sind normaler Code oder ein Formular oft günstiger, schneller und sicherer.

• Sind die zu erfassenden Angaben bekannt, ist ein Formular vorhersehbarer als ein Modell.
• Stammen Antworten nur aus einem festen Dokument, kann RAG oder eine einfache Suche genügen.
• Bei Aktionen ohne Fehlertoleranz machen Sie das Modell nicht zum Entscheider.
• Automatisieren Sie unumkehrbare Aktionen nicht ohne menschliche Freigabe.

Fragen Sie sich also: Ist es hier wirklich schwer, die Absicht zu verstehen? Lautet die Antwort nein, gewinnt dann klassische Software. Function Calling lohnt sich, wo die Absicht in freier Sprache ankommt und die Aufgabe Ihre Systeme berührt.

Rechnen Sie vor dem Bau außerdem einen kleinen Nutzencheck. Wie viele Gespräche haben Sie pro Monat, und wie viele werden zu echten Aktionen? Ermitteln Sie diese Zahl mit Ihren eigenen Daten, denn Beispielrechnungen unterscheiden sich von Betrieb zu Betrieb.

Was ist Function Calling: Welche Checkliste sollte ein Unternehmen abarbeiten?

Beantworten Sie die folgenden Punkte, bevor Sie starten. Sonst kehrt jeder offene Punkt später als Fehler oder Sicherheitslücke zurück.

• Welche Aufgaben werden wirklich zu Funktionen, und welche bleiben bei Menschen?
• Erledigt jede Funktion genau eine Aufgabe mit klarer Beschreibung?
• Sind Lese- und Schreibaktionen getrennt?
• Verlangen Schreibaktionen die Zustimmung des Nutzers?
• Liegen Identitäts- und Rechteprüfung im Code oder im Modell?
• Sind Argumentprüfung und Fehlerrückmeldung definiert?
• Haben Sie eine Obergrenze für Wiederholungen gesetzt?
• Protokollieren Sie jeden Aufruf?
• Haben Sie eine Testumgebung mit Testdaten, bevor Sie echte Daten berühren?

Bedenken Sie, dass diese Liste ein allgemeiner Startpunkt ist und keine rechtliche oder sicherheitstechnische Prüfung ersetzt. Verarbeiten Sie personenbezogene Daten, lassen Sie sich zu den geltenden Regeln von einer Fachperson beraten.

Wo starten Sie mit einem Function Calling Projekt?

Starten Sie mit der kleinsten, risikoärmsten und am häufigsten wiederkehrenden Aufgabe. Zum Beispiel ist eine Bestellabfrage, die nur liest, ein guter erster Schritt. Läuft sie, ergänzen Sie Schreibaktionen mit einem Freigabeschritt.

Vergleichen Sie bei der Anbieterwahl, wie jeder den Ablauf dokumentiert, denn die Logik ähnelt sich, die Details nicht. Für die API Grundlagen eignet sich unser Ratgeber OpenAI API nutzen. Möchten Sie aus Funktionen einen Agenten machen, sind unsere Artikel zu KI Agenten im Marketing und zum Selbst Hosten eines KI Agenten die nächsten Stationen.

Planen Sie einen Assistenten, der sich mit Ihren Systemen verbindet, sprechen Sie mit unserem Team über unsere Entwicklung von KI Agenten.

Als offizielle Quellen lesen Sie die Dokumentationen der Anbieter: den Leitfaden zu Function Calling von OpenAI, die Übersicht zu Tool Use von Anthropic und die Dokumentation zu Function Calling der Gemini API. Dokumentationen ändern sich oft, prüfen Sie Einstellungsnamen daher dort.