Function calling — jak model AI wywołuje Twój kod

Co to właściwie jest?#

Function calling (u części dostawców: tool calling) to umowa między Twoim kodem a modelem:

1. Ty deklarujesz funkcje — nazwa, opis, schemat parametrów.
2. Model, gdy uzna, że funkcja pomoże w zadaniu, zwraca żądanie wywołania z konkretnymi argumentami.
3. Twój system funkcję wykonuje (albo nie!) i odsyła wynik.
4. Model kontynuuje z nową wiedzą.

Najważniejsze zdanie tego artykułu: model nie wykonuje niczego — on tylko prosi. Cała władza (i cała odpowiedzialność) zostaje w Twoim kodzie.

Krok po kroku na przykładzie#

Deklaracja narzędzia (tu: składnia Anthropic, u innych dostawców niemal identyczna):

{
  "name": "sprawdz_stan_magazynu",
  "description": "Zwraca dostepna ilosc produktu w magazynie po SKU",
  "input_schema": {
    "type": "object",
    "properties": {
      "sku": { "type": "string", "description": "kod produktu, np. BUT-42-CZ" }
    },
    "required": ["sku"]
  }
}

Użytkownik pyta: „czy macie jeszcze czarne czterdziestkidwójki?”. Model odpowiada żądaniem:

{
  "type": "tool_use",
  "name": "sprawdz_stan_magazynu",
  "input": { "sku": "BUT-42-CZ" }
}

Twój kod wywołuje magazyn i odsyła wynik:

{
  "type": "tool_result",
  "content": "{ \"sku\": \"BUT-42-CZ\", \"dostepne\": 7 }"
}

Model kończy: „Tak, mamy 7 par na stanie”. Pętla może mieć wiele rund — i dokładnie ta pętla, obudowana limitami i uprawnieniami, robi z modelu agenta.

Zasady, które oszczędzają problemów#

• Waliduj argumenty przed wykonaniem. Schemat to deklaracja intencji, nie gwarancja — SKU sprawdź regexem, zakresy dat logiką.
• Opisy pisz jak dokumentację. Model wybiera funkcję po opisie; „zwraca stan po SKU” działa, „handler magazynu” — nie. Dobre opisy plus przykłady w opisie parametrów potrafią podnieść trafność wywołań bardziej niż zmiana modelu na droższy.
• Funkcje odczytu i zapisu rozdzielaj. Odczyty mogą być swobodne; zapisy chcesz móc wyłączyć jedną flagą albo obłożyć potwierdzeniem.
• Loguj każdą rundę. Żądanie, argumenty, wynik — bez tego nie zdiagnozujesz, czemu model „dziwnie się zachował” w czwartek o 16:40.

Co zrobić, gdy model wywołuje źle#

Trzy typowe awarie i ich przyczyny — w kolejności częstości, nie dramatyzmu.

Wywołuje niewłaściwą funkcję. Prawie zawsze wina opisu, nie modelu. Dwie funkcje o podobnych opisach („pobierz dane klienta” i „pobierz historię klienta”) będą mylone. Lekarstwo: opisy, które mówią, kiedy użyć, a nie tylko co robi — „użyj, gdy potrzebujesz danych kontaktowych; do historii zamówień użyj X”.

Halucynuje argumenty. Model wypełnia wymagane pole zmyśloną wartością, bo schemat mówi „required”. Lekarstwo dwustopniowe: pola, których nie da się wywnioskować, oznaczaj jako opcjonalne, a w opisie napisz wprost „jeśli użytkownik nie podał numeru, zapytaj zamiast zgadywać”.

Wpada w pętlę. Wywołuje to samo w kółko, bo wynik go nie zadowala. Lekarstwo jest po Waszej stronie i musi być twarde: limit rund i limit wywołań na sprawę, po przekroczeniu — przekazanie człowiekowi. Bez tego pierwszy nietypowy przypadek wygeneruje rachunek, który zapamiętacie.

Wspólny mianownik całej trójki: żadnej z tych awarii nie naprawia zmiana modelu na mocniejszy. Wszystkie trzy mają źródło w tym, co sami podaliśmy modelowi — w opisach, schematach i braku limitów. To dobra wiadomość, bo są to rzeczy w pełni pod kontrolą zespołu.

Koszt, o którym się zapomina#

Każda runda to pełny kontekst wysłany od nowa: instrukcja systemowa, definicje wszystkich narzędzi, cała dotychczasowa rozmowa i wyniki funkcji. Sprawa rozwiązana w pięciu rundach nie kosztuje pięciu wywołań — kosztuje znacznie więcej, bo kontekst rośnie z każdą rundą.

Dwa wnioski praktyczne: nie podawaj modelowi wszystkich narzędzi naraz (zestaw dobrany do etapu sprawy jest tańszy i trafniejszy) oraz skracaj wyniki funkcji — zwracanie całego rekordu z bazy, gdy potrzebne są trzy pola, płacisz w każdej kolejnej rundzie.