AI nie musi odpowiadać od razu. Kiedy warto użyć Batch API?

Batch API warto rozważyć przy wielu niezależnych zadaniach, których wyniki mogą poczekać. Zamiast wysyłać opis produktu i czekać na odpowiedź, przekazujesz paczkę zadań, a wyniki odbierasz później. To dobry kandydat do porządkowania katalogu, klasyfikowania archiwalnych treści czy przygotowywania propozycji zmian do sprawdzenia przez pracownika.

OpenAI oferuje w tym trybie 50% rabatu względem wywołań synchronicznych oraz 24-godzinne okno realizacji. Nie jest to jednak obietnica, że wszystko wysłane wieczorem będzie gotowe rano. FAQ Batch API przewiduje również wygaśnięcie nieukończonych zadań. Dlatego decyzję warto zacząć od pytania: czy firma może wykorzystać wyniki później, a brakującą część bezpiecznie ponowić?

Stan informacji według dostarczonego researchu: 13 listopada 2026 r. Przed integracją sprawdź aktualne ceny, obsługiwane modele i limity konta.

Kiedy wynik AI naprawdę może poczekać?

Nie każdy proces wymagający AI wymaga rozmowy z AI. Klient pytający o produkt oczekuje odpowiedzi podczas wizyty na stronie. Pracownik porządkujący kilka tysięcy opisów może potrzebować pliku z propozycjami, a nie kolejnych odpowiedzi pojawiających się na ekranie.

Tryb wsadowy jest wart rozważenia, gdy spełnione są trzy warunki:

• Zadania są niezależne. Do przypisania kategorii jednemu produktowi nie potrzebujesz wyniku dla poprzedniego.
• Termin jest elastyczny. Oczekiwanie i ewentualne ponowienie części pracy nie zatrzymują obsługi klienta.
• Masz sposób oceny rezultatów. Potrafisz określić dopuszczalne kategorie, wykryć braki i skierować niejasne przypadki do kontroli.

Proces	Czy rozważyć Batch API?	Powód
Propozycje kategorii dla katalogu produktów	Tak	Zadania można rozdzielić i sprawdzić przed publikacją.
Odpowiedź asystenta podczas rozmowy z klientem	Nie	Użytkownik potrzebuje reakcji w bieżącej sesji.
Analiza archiwalnych opisów pod kątem braków	Tak	Wyniki mogą trafić do późniejszej kolejki poprawek.
Przeliczenie cen według stałego wzoru	Zwykle nie	Wystarczy kod lub formuła, bez modelu językowego.
Raport wymagający kompletnych danych o konkretnej godzinie	Warunkowo	Potrzebny jest zapas czasu i plan na brakujące wyniki.

Duża liczba rekordów sama w sobie nie uzasadnia użycia AI. Jeśli kategoria wynika jednoznacznie z kodu dostawcy, lepszym rozwiązaniem może być zwykła tabela mapowań.

Batch API bez żargonu

W typowym wywołaniu aplikacja wysyła żądanie i oczekuje jego wyniku. W Batch API najpierw przygotowuje plik z wieloma żądaniami, przesyła go i uruchamia przetwarzanie. Następnie sprawdza stan paczki, a po zakończeniu pobiera wyniki oraz informacje o błędach.

Według dokumentacji technicznej Batch API dane wejściowe mają format JSONL: każdy wiersz jest osobnym obiektem JSON opisującym żądanie. Każde zadanie powinno mieć unikalny identyfikator custom_id. To on pozwala później połączyć odpowiedź z właściwym produktem.

Pojedyncza paczka może zawierać maksymalnie 50 000 żądań, a plik wejściowy może mieć do 200 MB. Jeden plik obejmuje żądania do jednego modelu. Oprócz tego obowiązują zależne od konta i modelu limity tokenów wejściowych oczekujących w kolejce. Limity Batch są oddzielne od standardowych limitów wywołań, ale nie oznacza to nieograniczonej przepustowości.

Polska znajduje się na oficjalnej liście krajów obsługiwanych przez OpenAI API. Dostęp regionalny nie oznacza jednak, że każde konto ma dostęp do wszystkich modeli. Przed pracami trzeba potwierdzić dostępność wybranego modelu i jego obsługę w trybie Batch.

Przykład: 4000 opisów produktów do uporządkowania

To przykład hipotetyczny, nie opis wdrożenia Lime Development. Firma otrzymała od dostawców 4000 opisów produktów. Chce zaproponować kategorie oraz oznaczyć opisy wymagające uzupełnienia. Nie chce jeszcze zmieniać danych widocznych w sklepie.

Najpierw reguły, później interpretacja

Pierwszy krok to ustalenie listy kategorii i wyodrębnienie rekordów, które da się przypisać bez modelu. Jeżeli dostawca przesyła wiarygodny kod kategorii, Python może przetłumaczyć go na kategorię sklepu. AI warto zostawić przypadki wymagające interpretacji tekstu.

Następnie trzeba określić, co znaczy „opis wymagający uzupełnienia”. Dla mebla może to być brak wymiarów, dla przewodu brak długości. Bez takich reguł model będzie oceniał kompletność według niejasnych kryteriów. Nie powinien dopowiadać brakujących parametrów.

Próbka przed pełną paczką

Do pilotażu wybierz zarówno proste, jak i trudne opisy: krótkie, wieloznaczne, z błędami oraz należące do podobnych kategorii. Przykładowa próbka 100 produktów jest propozycją organizacyjną, nie uniwersalnym minimum. Ważniejsze od samej liczby jest pokrycie typowych problemów.

Oczekiwany wynik może zawierać kod kategorii, listę brakujących informacji i krótkie uzasadnienie. Warto dopuścić odpowiedź „nie można rozstrzygnąć”. Zmuszanie modelu do wyboru jednej kategorii mimo niedostatecznych danych utrudnia późniejszą kontrolę.

W pilotażu wszystkie propozycje trafiają do osobnej tabeli, nie do opublikowanego katalogu. Pracownik sprawdza je i zapisuje decyzję: przyjąć, poprawić albo odrzucić. Dopiero ten etap pokazuje, czy automatyzacja ogranicza pracę, czy tylko przenosi ją na weryfikację.

Co przygotować przed integracją w Pythonie?

Programista potrzebuje więcej niż pliku z opisami i polecenia „przypisz kategorie”. Minimalna specyfikacja powinna określać wejście, wynik i zasady obsługi wyjątków.

• Stabilny identyfikator produktu: niezależny od numeru wiersza w Excelu.
• Wersję danych: informację, do którego opisu odnosi się wynik.
• Słownik kategorii: kody, definicje i zasady rozróżniania podobnych grup.
• Format odpowiedzi: wymagane pola, ich typy oraz dozwolone wartości.
• Limity: budżet, liczba prób i maksymalny zakres paczki.
• Zasady kontroli: kto sprawdza propozycje i co blokuje ich import.

Jeżeli dane pochodzą z kilku arkuszy, najpierw trzeba usunąć konflikty identyfikatorów i ustalić źródło aktualnego opisu. Ten etap opisuje poradnik o łączeniu firmowych plików CSV i Excel za pomocą Pythona. Model nie powinien rozstrzygać problemów, które wynikają z błędnego połączenia tabel.

Niewielka integracja też potrzebuje zapisu stanu

Rozsądny podział aplikacji obejmuje przygotowanie danych, utworzenie JSONL, wysłanie paczki, zapis jej identyfikatora, okresowe sprawdzanie statusu oraz pobranie i walidację wyników. Zapis stanu pozwala wznowić obsługę po restarcie programu bez wysyłania wszystkiego ponownie.

Dla każdego zadania warto przechowywać identyfikator produktu, wersję opisu, wersję instrukcji, wybrany model oraz historię prób. Jeśli opis zmienił się podczas oczekiwania, stara propozycja nie powinna automatycznie nadpisać nowszych danych. Taka kontrola bywa ważniejsza niż sam fragment kodu wywołujący API.

Opisy dostawców traktuj jako dane, nie instrukcje. Tekst „zignoruj poprzednie polecenia” znaleziony w opisie nie może zmienić celu zadania ani uruchomić działania w firmowym systemie. Oddziel instrukcję od treści produktu, sprawdzaj wynik i nie przyznawaj temu etapowi uprawnień do publikowania zmian.

Jak policzyć koszt całego procesu?

Rabat na API nie oznacza automatyzacji tańszej o połowę. Rachunek dostawcy jest tylko jednym składnikiem. Pozostałe to przygotowanie danych, integracja, kontrola, poprawki i utrzymanie. W krótkim, jednorazowym zadaniu właśnie te elementy mogą dominować.

Do porównania wariantów użyj prostego wzoru:

Koszt procesu = przygotowanie + integracja + przetwarzanie
              + ponowienia + kontrola + utrzymanie

Koszt zaakceptowanego wyniku = koszt procesu
                            / liczba zaakceptowanych wyników

Hipotetyczna kalkulacja: przyjmijmy, że porównywalne wywołania synchroniczne kosztowałyby 200 zł, a przygotowanie i kontrola 800 zł. Rabat 50% na przetwarzanie obniżyłby ten składnik do 100 zł. Całość spadłaby z 1000 do 900 zł, czyli o 10%, przy założeniu niezmienionych pozostałych kosztów. To ilustracja rachunku, nie wycena 4000 produktów ani prognoza oszczędności.

Rzeczywisty koszt API zależy między innymi od modelu oraz liczby tokenów wejściowych i wyjściowych. Tokeny są jednostkami rozliczania tekstu, nie liczbą produktów. Długi opis i rozbudowane uzasadnienie kosztują inaczej niż krótki rekord i zwięzła odpowiedź.

FAQ OpenAI wskazuje również, że przy wygaśnięciu lub anulowaniu paczki wykonana praca pozostaje płatna. W budżecie uwzględnij więc ponowienia, ale nie zakładaj, że trzeba powtarzać całą paczkę.

W pilotażu mierz koszt zaakceptowanego wyniku, odsetek propozycji wymagających poprawek, czas kontroli oraz kompletność paczki. Oddziel koszt jednorazowego przygotowania integracji od kosztu kolejnego uruchomienia. Dzięki temu nie pomylisz drogiego startu z drogim utrzymaniem procesu.

Jak odebrać wyniki bez pomylenia produktów?

Nie łącz wyników po kolejności wierszy. Dokumentacja Batch API zaznacza, że kolejność odpowiedzi może różnić się od kolejności wejścia. Łącz je po custom_id i sprawdzaj, czy każdy identyfikator jest znany oraz występuje zgodnie z oczekiwaniami.

Odbiór powinien obejmować trzy osobne kontrole:

1. Kompletność: które zadania mają wynik, które zakończyły się błędem, a których brakuje?
2. Poprawność techniczna: czy odpowiedź daje się odczytać i zawiera wymagane pola oraz dozwolone kategorie?
3. Poprawność merytoryczna: czy kategoria wynika z opisu, a wskazane braki odpowiadają ustalonym regułom?

Poprawnie wykonane żądanie nie oznacza poprawnej klasyfikacji. Model może zwrócić prawidłowy format, ale wybrać niewłaściwą kategorię. Status techniczny nie powinien więc automatycznie zmieniać się w status „zaakceptowane”.

Ponawiaj tylko zadania, dla których jest to uzasadnione. Błąd formatu wymaga poprawienia żądania, problem przejściowy może uzasadniać kolejną próbę, a niejednoznaczny opis często wymaga decyzji pracownika. Ustal limit prób i zachowaj powiązanie między nimi. Zasady bezpiecznego powtarzania operacji opisuje także tekst o ponowieniach i kontroli duplikatów w automatyzacji.

Kiedy Batch API nie będzie dobrym wyborem?

Nie wybieraj tego trybu do interaktywnego asystenta ani procesu, który wymaga natychmiastowej reakcji. Batch API nie obsługuje streamingu odpowiedzi, a nie wszystkie modele są z nim zgodne. Samo przeniesienie zadań do paczki nie poprawi też jakości źle zdefiniowanej klasyfikacji.

Sprawdź wymagania dotyczące danych. Zgodnie z FAQ ustawienie Zero Data Retention nie obejmuje Batch API. Nie zakładaj więc, że ustawienia stosowane w innych wywołaniach automatycznie dotyczą również plików i artefaktów przetwarzania wsadowego.

Przekazuj tylko pola potrzebne do zadania. Do przypisania kategorii zwykle nie potrzebujesz danych klientów, marży ani historii zamówień. Ustal również, kto ma dostęp do plików wejściowych, wyników i logów oraz kiedy są usuwane. Jeżeli wymagania firmy nie pasują do zasad usługi, wybierz inne rozwiązanie.

Lista kontrolna przed pilotażem

• Czy wybrany proces może poczekać także na ponowienie części zadań?
• Czy sprawdzono, które rekordy da się obsłużyć prostymi regułami?
• Czy próbka obejmuje przypadki łatwe, trudne i niejednoznaczne?
• Czy każdy rekord ma identyfikator oraz rozpoznawalną wersję danych?
• Czy ustalono budżet, limit prób i kryteria akceptacji?
• Czy wyniki trafią do kontroli zamiast bezpośrednio do publikacji?
• Czy proces wykryje brakujące odpowiedzi i zablokuje ponowny import?
• Czy zasady przekazywania i przechowywania danych są akceptowalne dla firmy?

Przed startem określ również warunki przerwania testu: przekroczenie budżetu, zbyt duży nakład kontroli lub błędy uznane za niedopuszczalne. Nie trzeba od razu integrować całego katalogu. Pierwszym użytecznym rezultatem może być tabela propozycji wraz z pomiarem czasu ich sprawdzania.

Jeżeli chcesz zaplanować taki pilotaż, zakres rozwiązań AI i automatyzacji Lime Development obejmuje pracę nad konkretnym procesem i integracją. Punktem wyjścia powinny być próbka danych, dopuszczalny czas oczekiwania oraz kryterium, po którym poznasz, że nowe rozwiązanie jest lepsze od obecnego.