Zum Inhalt

Function Calling

Das Function-Calling-System ermöglicht es KI-Assistenzmodellen (z. B. auf Basis von OpenAI), externe APIs aufzurufen, um Aktionen auszuführen oder Daten abzurufen.

Eine „Function“ beschreibt dabei eine ausführbare Aktion, die das Modell im Rahmen einer Konversation semantisch anstoßen kann. Ein LLM ist von sich aus ein geschlossenes System: Text rein, Text raus. Es hat keinen Internetzugang und kann nicht eigenständig auf externe Systeme zugreifen. Function Calling ist der Mechanismus, mit dem dieses geschlossene System kontrolliert nach außen geöffnet wird – das Modell kann so eigenständig entscheiden, wann und welche externe Aktion es auslösen möchte. Beispiele:

  • „Erstelle ein neues Jira-Ticket“
  • „Hole das aktuelle Wetter für Berlin“
  • „Füge einen Datensatz in einem CRM hinzu“

Jede Funktion wird über eine Funktionsdefinition im System konfiguriert und über eine definierte API-Verbindung (Connection) an eine externe API angebunden.

Aufbau einer Funktion

Beim Erstellen oder Bearbeiten einer Funktion werden folgende Elemente definiert:

Function Name

Ein eindeutiger und beschreibender Funktionsname. Beispiel:

create_jira_ticket

Erzwingen

Wenn aktiviert, wird die Funktion immer ausgeführt, unabhängig von der Benutzereingabe (Prompt).

Hinweis

Im Enforce-Modus wird die Funktion bei jeder Konversation automatisch ausgeführt – unabhängig vom Inhalt der Nutzereingabe. Prüfen Sie sorgfältig, ob dieser Modus für Ihren Anwendungsfall geeignet ist.

Function Beschreibung

Eine kurze Beschreibung, was die Funktion macht und wann sie verwendet werden soll. Beispiel:

Erstellt ein neues Jira-Ticket im angegebenen Projekt. Gibt im Fehlerfall die API-Fehlermeldung an den Benutzer zurück.

Wie entscheidet das LLM, eine Funktion aufzurufen?

Das Modell entscheidet autonom – basierend auf dem Gesprächskontext und der Beschreibung der Funktion. Es gibt keine feste Wenn-Dann-Logik. Lautet die Beschreibung z. B. „Erstellt einen neuen Blogartikel" und der Nutzer schreibt „Schreib mir etwas über Datenschutz", kann das Modell eigenständig entscheiden, diese Funktion aufzurufen.

Deshalb ist eine präzise und eindeutige Beschreibung entscheidend: Sie ist der wichtigste Steuerungsmechanismus dafür, wann eine Funktion ausgelöst wird.

Hinweis

Das LLM formuliert den Funktionsaufruf mit den entsprechenden Parametern. Den eigentlichen HTTP-Request führt jedoch die Applikation aus – nicht das Modell selbst. Das bedeutet: Nutzereingaben, die Parameter-Werte liefern, können als strukturierte Anfragen an externe Systeme weitergeleitet werden.

Funktions-Schema

Das Funktions-Schema beschreibt die Eingabeparameter als JSON-Schema, die das Modell liefern muss.

Bestandteile:

  • parameters: JSON-Schema der erwarteten Eingabeparameter
  • required: Pflichtfelder
  • strict: (optional) Legt fest, ob das Modell strikt an das Schema gebunden ist

Beispiel:

{
  "strict": true,
  "parameters": {
    "type": "object",
    "required": ["summary", "project_key", "issue_type"],
    "properties": {
      "summary": {
        "type": "string",
        "description": "Kurztitel des Tickets"
      },
      "project_key": {
        "type": "string",
        "description": "Projekt-Key (z. B. BGPT)"
      },
      "issue_type": {
        "type": "string",
        "description": "Userstory"
      },
      "description": {
        "type": "string",
        "description": "Detaillierte Beschreibung"
      }
    },
    "additionalProperties": false
  }
}

HTTP Request Body

Das Body-Template definiert die Struktur der HTTP-Anfrage für schreibende Operationen (POST, PUT). Verwenden Sie $parameterName als Platzhalter, um auf Werte aus dem Funktions-Schema zu verweisen.

Beispiel:

{
  "fields": {
    "project": { "key": "$project_key" },
    "summary": "$summary",
    "issuetype": { "name": "$issue_type" },
    "description": "$description"
  }
}

Parameter Hinweise

Verwenden Sie $parameterName, um auf Parameter des Funktions-Schemas zu verweisen. Dynamische Parameter oder Arrays werden nicht unterstützt.

API-Verbindung

Die Verbindung zur externen API wird direkt bei der Funktion konfiguriert:

  • API Endpunkt → z. B. https://jira.example.com/rest/api/2/issue
  • HTTP-Methode (GET, POST, PUT)
  • Authentifizierungsmethode (z. B. Anonymous, API Key, Basic Auth)

Die Authentifizierung wird automatisch in den Request-Header eingefügt.

Ablauf eines Function Calls

  1. Das KI-Modell entscheidet, eine Funktion aufzurufen, z. B.:
{
  "name": "create_jira_ticket",
  "arguments": {
    "summary": "Login-Fehler beheben",
    "project_key": "KEY",
    "issue_type": "Bug",
    "description": "Nutzer können sich nicht einloggen."
  }
}

  1. Das Backend:

  2. liest das Funktions-Schema und das HTTP Request Body-Template aus,

  3. ersetzt Platzhalter ($summary, $project_key, …) im Body-Template,

  4. erstellt die HTTP-Anfrage entsprechend der hinterlegten Verbindung.

  5. Die Anfrage wird ausgeführt, z. B.:

POST https://jira.example.com/rest/api/2/issue
Content-Type: application/json
Authorization: Basic <token>

{
  "fields": {
    "project": { "key": "KEY" },
    "summary": "Login-Fehler beheben",
    "issuetype": { "name": "Bug" },
    "description": "Nutzer können sich nicht einloggen."
  }
}
  1. Die externe API antwortet (z. B. mit JSON). Das System gibt diese Antwort unverändert an das KI-Modell zurück.

5. Request-Typen

Typ Zweck http_request_body erforderlich?
GET Lesen von Daten ❌ Nein
POST Erstellen neuer Ressourcen ✅ Ja
PUT Aktualisieren bestehender Ressourcen ✅ Ja
PATCH Teilweise Aktualisierung ✅ Ja

6. Beispiel: GET Request

{
  "parameters": {
    "type": "object",
    "required": ["city"],
    "properties": {
      "city": {
        "type": "string",
        "description": "Name der Stadt"
      },
      "units": {
        "type": "string",
        "description": "Temperatureinheit",
        "enum": ["metric", "imperial"]
      }
    },
    "additionalProperties": false
  }
}

Beispiel-Aufruf:

{
  "name": "get_weather",
  "arguments": { "city": "Berlin", "units": "metric" }
}

Ergebnis:

GET https://api.open-meteo.com/v1/forecast?city=Berlin&units=metric

Integrationsleitfaden für API-Anbieter

Um sicherzustellen, dass eine API von einem KI-Assistenten über Function Calling angesprochen werden kann, müssen die nachfolgenden Bedingungen und Voraussetzungen erfüllt sein.

1. Ziel

Damit eine API kompatibel ist, muss sie:

  1. Über HTTP erreichbar sein (GET, POST, PUT, PATCH).
  2. JSON als Eingabe- und Ausgabeformat unterstützen.
  3. Klar definierte Felder und erwartete Datentypen besitzen.
  4. Eindeutige Parameterbezeichnungen bereitstellen, die im Function-JSON referenziert werden können.

2. Anforderungen an den Endpoint

Aspekt Beschreibung
HTTP-Methoden Unterstützt GET, POST, PUT oder PATCH
Authentifizierung Wird über die Connection des Systems hinzugefügt (nicht durch den Aufrufer)
Content-Type application/json
Antwortformat JSON (empfohlen)
Fehlerbehandlung HTTP-Statuscodes (z. B. 4xx, 5xx) und Fehlermeldung als Text oder JSON

3. Parameterstruktur

Die API sollte so gestaltet sein, dass die Felder aus der Function-Definition direkt befüllt werden können.

Beispiel:

Funktions-Schema

{
  "parameters": {
    "type": "object",
    "required": ["customer_id", "status"],
    "properties": {
      "customer_id": {
        "type": "string",
        "description": "Eindeutige Kunden-ID"
      },
      "status": {
        "type": "string",
        "description": "Neuer Status (z. B. active/inactive)"
      }
    }
  }
}

HTTP Request Body

{
  "customer": { "id": "$customer_id" },
  "status": "$status"
}

Business GPT ersetzt die Platzhalter mit den tatsächlichen Werten:

{
  "customer": { "id": "C123" },
  "status": "active"
}

4. Antwortstruktur

Die API sollte eine sinnvolle, strukturierte Antwort zurückgeben, z. B.:

{
  "status": "success",
  "ticket_id": "Project-1234",
  "message": "Ticket created successfully"
}

Fehler sollten standardisiert werden, z. B.:

{
  "status": "error",
  "message": "Invalid project key"
}

5. Best Practices

  • Verwenden Sie sprechende Parameternamen, die mit der Business-Logik korrespondieren.
  • Definieren Sie alle Pflichtfelder im JSON-Schema (required).
  • Halten Sie sich an das Prinzip: „LLM liefert nur die semantischen Werte, nicht das Request-Format.“
  • Nutzen Sie Platzhalter ($parameter) konsistent im http_request_body.

6. Beispiel einer vollständigen Integration

Ziel:

Eine API, die ein Support-Ticket anlegt.

Funktions-Schema:

{
  "parameters": {
    "type": "object",
    "required": ["title", "priority"],
    "properties": {
      "title": { "type": "string", "description": "Titel des Tickets" },
      "priority": { "type": "string", "enum": ["Low", "Medium", "High"] },
      "description": { "type": "string" }
    }
  }
}

HTTP Request Body

{
  "ticket": {
    "title": "$title",
    "priority": "$priority",
    "description": "$description"
  }
}

Business GPT generiert:

POST https://api.supportsystem.com/v1/tickets
Authorization: Bearer <token>
Content-Type: application/json

{
  "ticket": {
    "title": "Zugangsdaten verloren",
    "priority": "High",
    "description": "Der Benutzer kann sich nicht anmelden."
  }
}

API antwortet:

{
  "status": "success",
  "ticket_id": "SUP-9876"
}

7. Zusammenfassung

Komponente Verantwortung
KI-Modell Liefert Funktionsname + Parameterwerte
Backend Ersetzt Platzhalter, führt HTTP-Request aus, fügt Authentifizierung hinzu
Externe API Nimmt JSON entgegen, verarbeitet es, liefert Antwort zurück
LLM Nutzt die Antwort, um dem Benutzer die Aktion oder das Ergebnis mitzuteilen