Przekazujesz wiadomość użytkownika do GPT API, a zamiast odpowiedzi w języku naturalnym model zwraca ustrukturyzowany obiekt JSON, który mówi dokładnie, jaką funkcję wywołać i z jakimi argumentami. To jest właśnie function calling — i zmienia rodzaj aplikacji, które można budować z LLM-ami.
Większość deweloperów słyszy „function calling” i zakłada, że model wykonuje kod w ich imieniu. Nie robi tego.
Korzystając z function calling, samo LLM nie wykonuje funkcji. Zamiast tego identyfikuje odpowiednią funkcję, zbiera wszystkie wymagane parametry i przekazuje informacje w ustrukturyzowanym formacie JSON.
Twoja aplikacja nadal odpowiada za uruchomienie właściwej logiki. Model jedynie mówi, co uruchomić i z jakimi danymi wejściowymi.
To rozróżnienie ma większe znaczenie, niż się wydaje, i wpływa na wszystko — od architektury integracji po sposób myślenia o bezpieczeństwie.
Czym naprawdę jest wywoływanie funkcji — i co ludzie ciągle mylą
Function calling (znane też jako tool calling) zapewnia potężny i elastyczny sposób, aby modele OpenAI interfejsowały z systemami zewnętrznymi i uzyskiwały dostęp do danych spoza zbioru treningowego.
Nazwa to pierwsze źródło nieporozumień. Ludzie myślą, że model coś wykonuje. Nie wykonuje.
Istnieje wiele nazw i wyjaśnień dla function calling, ale wszystko sprowadza się do jednego stwierdzenia: „function calling to rodzaj zdolności LLM do zwracania ustrukturyzowanego outputu”. LLM-y same nie wywołują żadnych funkcji; sugerują, którą funkcję powinieneś wywołać z zestawu z góry zdefiniowanych funkcji, które dostarczasz LLM-owi w promptcie.
Drugie nieporozumienie dotyczy starego interfejsu API.
Parametry functions i function_call zostały oznaczone jako przestarzałe wraz z wydaniem wersji API 2023-12-01-preview. Zastępstwem dla functions jest parametr tools.
Jeśli korzystasz z tutorialu używającego starego parametru functions, to już używasz przestarzałej składni. Zamiast tego używaj tools i tool_choice.
Funkcja jest szczególnym rodzajem narzędzia, zdefiniowanym przez schemat JSON. Definicja funkcji pozwala modelowi przekazywać dane do Twojej aplikacji, gdzie Twój kod może uzyskać dostęp do danych lub podjąć działania zasugerowane przez model.
To właśnie schemat daje function calling przewagę niezawodności nad zwykłym promptowaniem — nie liczysz, że model poprawnie sformatuje output, tylko egzekwujesz strukturę na poziomie API.
Jak działa function calling w OpenAI API — krok po kroku
Tool calling to wieloetapowa rozmowa między Twoją aplikacją a modelem poprzez OpenAI API. Przepływ tool callingu ma pięć kroków wysokiego poziomu: wyślij żądanie do modelu z narzędziami, które mógłby wywołać...
Oto jak każdy z tych kroków wygląda w praktyce.
Krok 1: Zdefiniuj schematy funkcji. Opisujesz każdą dostępną funkcję jako obiekt JSON w parametrze tools. Schemat obejmuje nazwę funkcji, opis w języku naturalnym, którego model używa, by zdecydować, kiedy ją wywołać, oraz blok parameters, który podąża za konwencjami JSON Schema.
Im bardziej szczegółowy jest Twój description — pod kątem sytuacji, w których można i należy wywołać funkcję — tym lepiej. Pamiętaj jednak, że opisy funkcji są częścią promptu i zużywają tokeny.
Krok 2: Wyślij żądanie. Wywołujesz Chat Completions API z wiadomością użytkownika i listą tools. Model widzi oba.
Krok 3: Model decyduje, czy wywołać funkcję.
Wywołanie funkcji to szczególny rodzaj odpowiedzi, którą możesz otrzymać od modelu, jeśli uzna on, że aby wykonać instrukcje, musi wywołać jedno z dostępnych narzędzi. Jeśli model otrzyma prompt w stylu „what is the weather in Paris?”, może odpowiedzieć wywołaniem narzędzia get_weather, z Paryżem jako argumentem lokalizacji.
Krok 4: Twój kod wykonuje funkcję. Parsujesz odpowiedź modelu, wyodrębniasz nazwę funkcji i argumenty, i uruchamiasz właściwy kod w swoim środowisku wykonawczym. API zwróciło ustrukturyzowany JSON — Ty decydujesz, co z nim zrobić.
Krok 5: Odeślij wynik z powrotem.
Następnie przesyłasz z powrotem do modelu wszystkie definicje narzędzi, oryginalny prompt, wywołanie narzędzia przez model oraz output z narzędzia, aby finalnie otrzymać odpowiedź tekstową
— coś w rodzaju „Pogoda w Paryżu dziś to 25°C.”
Jedna rzecz, którą większość tutoriali pomija:
kiedy ustawisz strict: true w definicji funkcji, Structured Outputs gwarantuje, że argumenty wygenerowane przez model dla wywołania funkcji będą dokładnie zgodne z dostarczonym JSON Schema.
Ustawienie strict na true sprawi, że wywołania funkcji będą niezawodnie trzymać się schematu funkcji, zamiast być „best effort”. OpenAI zaleca zawsze włączać tryb ścisły.
Zawsze. Nie ma dobrego powodu, by tego nie robić.
Jest też kwestia równoległego wywoływania funkcji.
W zależności od zapytania użytkownika model wywoła równoległe wywołania funkcji, jeśli używasz najnowszych modeli wydanych 6 listopada 2023 r. lub później.
Oznacza to, że jedno żądanie, takie jak „what's the weather in London and Tokyo?”, może wyzwolić dwa równoczesne wywołania narzędzi, zamiast sekwencyjnego łańcuchowania.
Realne zastosowania function callingu
Przykład z pogodą jest wszędzie, bo jest czysty. Produkcyjne przypadki użycia są bardziej złożone i ciekawsze.
Pipeline’y wsparcia klienta z danymi na żywo
Function calling jest użyteczny w wielu przypadkach — na przykład asystent AI, który musi pobrać najnowsze dane klienta z systemu wewnętrznego, gdy użytkownik pyta „what are my recent orders?”, zanim będzie mógł wygenerować odpowiedź.
Model rozpoznaje intencję, wyciąga ID klienta z kontekstu i wywołuje wewnętrzne API Twojego CRM-a. Bez kruchego regexu. Bez szablonów promptów, które psują się od brakującego przecinka.
Ekstrakcja ustrukturyzowanych danych na skalę
Pipeline ekstrakcji danych, który pobiera surowy tekst, przekształca go w dane o ustalonej strukturze i zapisuje do bazy, to kolejny mocny przypadek. Zyskujesz spójne schematy w tysiącach dokumentów bez ręcznego dostrajania logiki parsowania dla każdego typu dokumentu.
Tłumaczenie języka naturalnego na wywołania API
Rozwiązania oparte na LLM do ekstrakcji i tagowania danych, aplikacje pomagające konwertować język naturalny na wywołania API lub prawidłowe zapytania do bazy, a także konwersacyjne silniki wyszukiwania wiedzy współpracujące z bazą wiedzy — wszystkie te przypadki korzystają z gwarancji formatu outputu, jaką daje function calling. Gdy output ma sterować systemami downstream, nie możesz tolerować zmienności.
Agentowe workflowy z wieloma narzędziami
Dla deweloperów function calling umożliwia dostęp do danych w czasie rzeczywistym, by ominąć cięcia treningowe, pobierając bieżące kursy akcji, pogodę czy świeże wpisy z bazy. Umożliwia też wykonywanie akcji — przekształcając LLM z biernego obserwatora w aktywnego uczestnika, który modyfikuje stan, jak wysyłanie e-maili, aktualizowanie CRM-ów czy wdrażanie kodu.
Kluczowa różnica względem zwykłego chatbota: model nie tylko generuje tekst, ale orkiestruje realne operacje w Twoich systemach.
Najlepsze praktyki function callingu — co deweloperzy zwykle robią źle
To właśnie sekcja, którą większość tutoriali pomija, przez co zespoły debugują dziwne awarie produkcyjne o 2 w nocy.
Pisanie zbyt ogólnikowych opisów. Model używa opisu Twojej funkcji, by zdecydować, kiedy ją wywołać. Jeśli opis jest ogólny — coś w rodzaju „przetwarza żądania użytkownika” — model nie ma wiarygodnej wskazówki, kiedy ją uruchomić. Bądź konkretny co do warunku wyzwolenia i oczekiwanego kształtu wejścia. Traktuj opis jak kontrakt, nie etykietę.
Udostępnianie zbyt wielu funkcji naraz
Opisy funkcji mogą konsumować znaczną liczbę tokenów w wejściowym promptcie.
Załadowanie definicji 50+ narzędzi do system promptu tworzy dwa problemy: koszt i opóźnienie, ponieważ definicje narzędzi konsumują tokeny wejściowe; oraz degradację dokładności, ponieważ wraz ze wzrostem liczby opcji narzędzi maleje zdolność modelu do wyboru właściwego.
Zacznij od najmniejszego zestawu funkcji, których faktycznie potrzebuje Twój przypadek użycia.
Założenie, że model nie będzie halucynował parametrów. Będzie.
Model może halucynować parametry — zwłaszcza dla pól opcjonalnych, które nie są jednoznacznie ograniczone przez enum. Dlatego strict: true jest tak ważne: odbiera modelowi możliwość wymyślania pól spoza schematu.
Brak obsługi pętli wieloturowej. Deweloperzy często budują „happy path” — użytkownik pyta, model wywołuje funkcję, koniec.
Modele mogą generować wywołania funkcji, które nie pasują do zdefiniowanego schematu, lub próbować wywołać funkcję, której nie udostępniłeś. Jeśli model generuje nieoczekiwane wywołania funkcji, spróbuj dodać w system message zdanie: „Only use the functions you have been provided with.”
Buduj z myślą o przypadkach brzegowych.
Pomijanie kroku potwierdzenia przed operacjami zapisu.
Bądź świadomy realnego wpływu wywołań funkcji, które planujesz wykonać, zwłaszcza tych, które inicjują działania, takie jak wykonywanie kodu, aktualizowanie baz danych czy wysyłanie powiadomień. Dla funkcji, które podejmują działania, zdecydowanie zaleca się wdrożenie kroku, w którym użytkownik potwierdza akcję przed jej wykonaniem.
Jeśli wywołanie funkcji może usuwać dane, wysyłać pieniądze lub modyfikować stan zewnętrzny, człowiek powinien to najpierw zatwierdzić.
Aspekty bezpieczeństwa i niezawodności
Function calling poszerza możliwości LLM-u. Poszerza też to, co atakujący może próbować nim zrobić.
Głównym zagrożeniem jest prompt injection.
Cele końcowe takich ataków są różne, ale mogą obejmować wykradanie danych prywatnych poprzez kolejne wywołania narzędzi, podejmowanie niepożądanych działań lub inne zmiany zachowania modelu w sposób niezamierzony.
Gdy Twoje wywołania funkcji mogą wysyłać e-maile, zapytania do baz danych czy wyzwalać webhooki, atak typu injection to nie tylko chatbot schodzący z kursu — to potencjalne naruszenie bezpieczeństwa.
W miarę jak systemy AI wychodzą poza chat i zaczynają wywoływać narzędzia oraz podejmować działania, prompt injection staje się znacznie poważniejszym problemem. Złośliwa instrukcja ukryta na stronie, w dokumencie lub w zewnętrznym narzędziu może próbować nadpisać zachowanie systemu, ujawnić wrażliwe informacje lub wyzwolić działania, których model nigdy nie powinien wykonywać.
Strategia ograniczania ryzyka ma kilka konkretnych warstw.
Projektuj workflowy tak, aby niezaufane dane nigdy bezpośrednio nie sterowały zachowaniem agenta. Wyodrębniaj tylko konkretne, ustrukturyzowane pola — takie jak enumy lub walidowany JSON — aby ograniczyć ryzyko przenikania injection między węzłami.
On top of that,
zawsze weryfikuj wywołania funkcji generowane przez model. Obejmuje to sprawdzenie parametrów, wywoływanej funkcji i upewnienie się, że wywołanie jest zgodne z zamierzonym działaniem.
Jedna niewygodna prawda:
„Prompt injection, podobnie jak oszustwa i socjotechnika w sieci, najprawdopodobniej nigdy nie zostanie w pełni ‘rozwiązany’.”
To własna ocena OpenAI. Praktyczny wniosek jest taki, że nie należy projektować agentowych systemów z function callingiem w założeniu, że model zawsze będzie zachowywał się zgodnie z intencją. Obrona warstwowa — walidacja, ograniczone uprawnienia, człowiek w pętli dla operacji destrukcyjnych — to jedyna rozsądna postawa.
Function Calling vs. Prompt Engineering — kiedy czego używać
To porównanie pojawia się nieustannie. Krótka odpowiedź: rozwiązują różne problemy, a ich mieszanie prowadzi do nadmiernie rozbudowanych promptów tam, gdzie wystarczyłby function calling, lub kruchych schematów funkcji tam, gdzie prostszy system prompt byłby lepszy.
Prompt engineering polega na tworzeniu tekstowych wejść kierujących wewnętrznym rozumowaniem LLM — proszeniu go na przykład, by „myślał krok po kroku”.
Kształtuje to sposób rozumowania modelu. Function calling natomiast kształtuje to, co model produkuje jako output, i kieruje to bezpośrednio do Twojego systemu.
Tool calling to zdolność, która pozwala LLM-owi wchodzić w interakcję z systemami zewnętrznymi. Używasz prompt engineering, aby pomóc modelowi zdecydować, którego narzędzia użyć, ale to tool calling jest mechanizmem, który faktycznie wykonuje akcję. Prawdopodobnie potrzebujesz obu, ale służą różnym celom.
Kluczowa przewaga techniczna function callingu nad ustrukturyzowanym outputem opartym wyłącznie na promptach:
tool calling jest koncepcją wbudowaną w model. Nie musisz marnować tokenów i energii, by tłumaczyć modelowi, że ma zwrócić konkretny format.
Gdy tworzysz prompt, który mówi „zwróć odpowiedź jako JSON z polami X, Y i Z”, wydajesz tokeny na instrukcje, których model może nie przestrzegać konsekwentnie. Przy function callingu egzekwowanie schematu odbywa się na poziomie API.
Interfejsy API do function callingu, obecnie natywnie wspierane w wielu platformach LLM, zapewniają formalny, oparty na schematach interfejs, który umożliwia ścisłą walidację danych i integrację z workflowami programistycznymi.
To realny powód, by wybrać go zamiast samego prompt engineering wszędzie tam, gdzie dane mają trafić do systemów downstream: w produkcji niezawodność nie jest opcjonalna.
| Dimension | Prompt Engineering | Function Calling |
|---|---|---|
| Primary purpose | Kształtowanie rozumowania i tonu modelu | Produkcja ustrukturyzowanego outputu do integracji z systemami |
| Output format | Tekst swobodny (lub tekst-udawany JSON) | Wymuszony schemat JSON |
| Schema reliability | Best effort; podatny na dryf | Gwarantowane przy strict: true |
| Token cost | Niższy dla prostych outputów | Wyższy (definicje funkcji dodają tokeny) |
| When to use | Zadania rozumowania, generacja tekstu, styl | Ekstrakcja danych, orkiestracja API, działania agentowe |
| Prompt injection exposure | Ekspozycja niższa | Ekspozycja wyższa (wywołania mogą uruchamiać realne akcje) |
Praktyczna heurystyka: jeśli output ma sterować systemem downstream — zapis do bazy, wywołanie API, gałąź decyzyjna w kodzie — użyj function callingu. Jeśli output jest przeznaczony do odczytu przez człowieka, prompt engineering zwykle wystarczy i jest tańszy.
Najważniejsze wnioski
| Topic | What to Remember |
|---|---|
| What it is | Model zwraca ustrukturyzowany JSON opisujący, którą funkcję wywołać — sam funkcji nie wykonuje |
| Current API surface | Używaj tools i tool_choice; stare parametry functions i function_call są przestarzałe |
| Strict mode | Zawsze ustawiaj strict: true w definicjach funkcji, aby wymusić zgodność ze schematem |
| Parallel calling | Wspierane w modelach wydanych po listopadzie 2023 r.; jedno żądanie może wyzwolić wiele wywołań narzędzi |
| Token cost | Schematy funkcji konsumują tokeny wejściowe; minimalizuj liczbę udostępnionych funkcji |
| Security | Waliduj wszystkie wyjścia z wywołań funkcji; nigdy nie pozwalaj, by niezaufane treści zewnętrzne bezpośrednio sterowały wywołaniami narzędzi |
| vs. Prompt Engineering | Function calling wymusza strukturę outputu na poziomie API; prompt engineering kształtuje wewnętrzne rozumowanie |
| Confirmation steps | Każda funkcja z efektami w świecie rzeczywistym (zapis, wysyłka, usunięcie) powinna wymagać potwierdzenia użytkownika przed wykonaniem |
Jeśli chcesz poeksperymentować z function callingiem w różnych modelach — GPT-5.4, claude opus 4.7, gemini 3.1 pro — bez utrzymywania oddzielnych poświadczeń API dla każdego, CometAPI daje dostęp do wszystkich przez jeden endpoint i klucz, co znacząco zmniejsza tarcie przy testach między modelami.
CometAPI rozwiązuje narzut infrastrukturalny:
✅ Ujednolicona składnia function callingu w 15+ modelach
✅ Jeden klucz API — bez osobnych kont dla OpenAI/Anthropic/Google
✅ Automatyczne tłumaczenie schematów — napisz raz, testuj wszędzie
✅ Wbudowane śledzenie kosztów — porównuj użycie tokenów na model w czasie rzeczywistym
Zacznij testy z darmowymi kredytami → Uzyskaj dostęp