O czym jest ten film
- OpenAI udostępniło wyczekiwaną Decisions API — swoją odpowiedź na Jeva, usługę, którą kilka tygodni wcześniej podbiła internet.
- Zasada działania: przekazujesz tekst albo obraz, zadajesz pytanie, a w odpowiedzi dostajesz wynik, którego aplikacja może od razu użyć.
- Są trzy typy pytań: tak/nie (OpenAI nazywa to „predykatem”), wybór najlepszej opcji oraz ocena na zdefiniowanej skali.
- Każda odpowiedź wraca z prawdopodobieństwem — model nie tylko rozstrzyga, ale mówi, jak bardzo jest pewny.
- Zapytanie trafia do klasyfikatora GPT-6 Luna i zawsze składa się z trzech elementów: modelu, dostarczonych dowodów i osądu do wydania.
- Kashef pokazuje praktyczny przykład: automatyczna klasyfikacja zgłoszeń zwrotów w e-commerce.
- Główna funkcjonalna przewaga OpenAI: multimodalność — Decisions API rozumie zdjęcia, Jev (stan na nagranie) wyłącznie tekst.
- Cena: Jev kosztuje 0,042 dolara za milion tokenów wejściowych, Decisions API — 10 centów; Jev wychodzi o 58% taniej.
- Decisions API przewiduje możliwość odmowy odpowiedzi, Jev zawsze odpowiada w granicach zdefiniowanych opcji.
- W praktycznych testach obie usługi dochodziły do identycznych wniosków; OpenAI była zwykle odrobinę szybsza, Jev wyraźnie tańszy.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Decisions API to klasyfikator decyzyjny, nie czat
Na czym polega: Usługa zwraca ustrukturyzowaną, gotową do użycia odpowiedź z prawdopodobieństwem — dokładnie to, czego potrzebuje kod aplikacji, a nie swobodna wypowiedź.
Jak stosować: Wdrażaj tam, gdzie liczy się szybka, powtarzalna decyzja: filtrowanie spamu, tagowanie zgłoszeń, kwalifikacja spraw, routing.
Na co uważać: To nie generator tekstu. Złożone, otwarte zadania trzeba najpierw rozbić na serię prostych, jednoznacznych pytań.
2.Trzy typy pytań pokrywają większość potrzeb
Na czym polega: Pytanie zero-jedynkowe (tak/nie), wybór z listy opcji albo ocena na skali z opisanymi poziomami — między tymi formatami mieści się niemal każda decyzja automatyczna.
Jak stosować: Zanim wyślesz zapytanie, dopasuj problem do jednego z typów i precyzyjnie opisz, co oznacza każda możliwa odpowiedź.
Na co uważać: Niejednoznaczne lub nakładające się opcje to najczęstsza przyczyna błędnej klasyfikacji — przetestuj definicje na prawdziwych danych.
3.Próg pewności zamiast ślepego zaufania
Na czym polega: Każdy wynik wraca z procentową pewnością, więc decyzję można uzależnić od tego, jak bardzo model jest przekonany.
Jak stosować: Ustaw próg (np. 80%): wszystko poniżej kieruj do weryfikacji człowieka, wszystko powyżej obsługuj automatycznie.
Na co uważać: Próg za niski wpuszcza błędy do automatyzacji, za wysoki przerzuca na ludzi zbyt dużo spraw. Kalibruj go na własnych danych historycznych.
4.Najszybszy start: dokumentacja plus ulubiony model
Na czym polega: Wystarczy wrzucić link do dokumentacji Decisions API do dowolnego asystenta kodującego — Codexa, Claude’a, Gemini — i podać klucz API, a pierwszy działający przykład złoży się praktycznie sam.
Jak stosować: Zacznij od jednego małego scenariusza testowego, zanim zbudujesz całą integrację.
Na co uważać: Klucz produkcyjny podłączaj dopiero po próbach na małej skali; od początku pilnuj limitów i kosztów.
5.Jakość osądu zależy od jakości dowodów
Na czym polega: Zapytanie składa się z modelu, dowodów i osądu — Luna ocenia wyłącznie to, co jej dostarczysz, nic więcej.
Jak stosować: Zbierz kompletny kontekst: pełną wiadomość klienta, całe logi, komplet zdjęć, a nie wycinki.
Na co uważać: Model z okrojonymi danymi zwróci pewną, ale błędną odpowiedź. Wysoka pewność nie oznacza trafności.
6.Zwroty w e-commerce: gotowy wzorzec do skopiowania
Na czym polega: Kashef pokazuje kompletny przykład: typ „wybór”, instrukcja „przeczytaj wiadomość klienta i zdecyduj, jaki problem zgłasza” oraz trzy opcje — uszkodzony, bez śladu uszkodzeń, za mało informacji.
Jak stosować: Ten sam schemat przeniesiesz na reklamacje, obsługę zgłoszeń, kwalifikację leadów — wszędzie tam, gdzie trzeba przypisać wiadomość do kategorii.
Na co uważać: Zawsze zostawiaj opcję „za mało informacji”. Wymuszenie odpowiedzi, gdy dane nie wystarczają, produkuje fałszywie pewne kategorie.
7.Multimodalność to przewaga, której Jev nie ma
Na czym polega: Decisions API przyjmuje i tekst, i obrazy — z prostego powodu: modele OpenAI (Luna, Astra, Terra, Sol) od dawna są multimodalne, więc żadne dodatkowe trenowanie nie było potrzebne.
Jak stosować: Ocena uszkodzeń przesyłek ze zdjęć, kontrola jakości, moderacja grafik — przypadki, w których tekst nie istnieje.
Na co uważać: Analiza obrazów podlega odmowom i kosztuje — przewiduj fallback na wypadek, gdy usługa odmówi odpowiedzi.
8.Koszt licz na swoim wolumenie, nie na stu zapytaniach
Na czym polega: Jev: 0,042 dolara za milion tokenów wejściowych, Decisions API: 10 centów. Jev wychodzi o 58% taniej — przy dziesiątkach czy tysiącach zapytań różnica jest pomijalna, przy milionach robi się o niebotyczna.
Jak stosować: Jeśli planujesz masową, tekstową klasyfikację — liczony koszt wskazuje na Jeva. Przy małych wolumenach decyduj funkcjonalnościami, nie ceną.
Na co uważać: Tokeny wejściowe to nie zawsze cały rachunek. Sprawdź, co dokładnie liczy się jako dowód w zapytaniu, zanim porównasz oferty.
9.Odmowa odpowiedzi to zaprojektowany stan, nie awaria
Na czym polega: Decisions API ma zdefiniowaną możliwość odmowy — niektóre pytania lub zdjęcia po prostu odrzuci. Jev zawsze odpowie w granicach podanych opcji.
Jak stosować: Obsłuż odmowę w kodzie jako osobny stan, obok „tak”, „nie” i „nie wiem” — z kolejką do ponownej próby lub człowieka.
Na co uważać: Przy wrażliwych lub granicznych obrazach odmowy mogą pojawiać się częściej. Kashef domniemuje, że to właśnie zabezpieczenie przed nadużyciami — przetestuj wcześniej na własnym materiale.
10.Wybór sprowadza się do jednego kryterium
Na czym polega: W testach Kashefa skuteczność to remis, średni czas pojedynczego wywołania minimalnie po stronie OpenAI (146 versus 155 ms), mediana pełnych dochodzeń po stronie Jeva, a koszt zdecydowanie po stronie Jeva.
Jak stosować: Potrzebujesz obrazów — bierz Decisions API. Masz czysty tekst i dużą skalę — Jev. Pozostałe różnice są na tyle małe, że nie powinny decydować.
Na co uważać: To mikrobenchmarki na małych próbkach, a rynek zmienia się z tygodnia na tydzień — przed decyzją powtórz testy na własnych danych i aktualnych cennikach.
Redakcyjne tłumaczenie
Szał na punkcie Jeva i odpowiedź OpenAI
Kilka tygodni temu cały świat oszalał na punkcie Jeva. Od tamtej pory w sieci pojawiły się dziesiątki otwartych interpretacji tego pomysłu. Dziś OpenAI udostępniło wyczekiwaną Decisions API — swoją wersję usługi z tej rodziny. W tym materiale pokażę, czym właściwie jest Decisions API, jak działa i — co ważniejsze — jak wypada na tle Jeva. Postawię oba narzędzia twarzą w twarz w kilku testach na żywych przykładach, żeby było widać, jak radzą sobie pod względem ceny, szybkości i jakości. Zaczynajmy.
Czym jest Decisions API
Działanie jest proste: przekazujesz tekst albo obraz, zadajesz pytanie, a w odpowiedzi dostajesz wynik, którego aplikacja może od razu użyć. Podobnie jak w Jevie, są trzy podstawowe sposoby zadawania pytań.
Pierwszy: czy coś jest prawdą — rozstrzygnięcie zero-jedynkowe, tak albo nie. Drugi: która opcja pasuje najlepiej — pytanie zamknięte z kilkoma wariantami do wyboru. Trzeci: pytanie o stopień, na przykład „ile” — definiujesz skalę ocen, a model dobiera poziom pasujący do opisanej sytuacji. W każdym przypadku to ty wybierasz pytanie i wyjaśniasz, co oznaczają poszczególne odpowiedzi.
Najprostsza droga na start: wejdźcie w dokumentację Decisions API, wrzućcie link do ulubionego modelu — Codexa, Claude’a, Gemini czy czegoś innego — przekażcie mu klucz API i dalej wszystko ułoży się praktycznie samo. Model przejrzy dokumentację i przeprowadzi was przez konfigurację.
Jedna uwaga dotycząca wszystkich trzech typów pytań: dokładnie tak jak w Jevie, każdy z nich zwraca pewną postać prawdopodobieństwa. Jeśli zapytacie „czy ta wiadomość to spam”, OpenAI nazwie taki wynik predykatem — Jev ma na to własną nazwę, przy czym sam przyznaję, że nigdy nie jestem pewien, jak ją wymówić.
(Informacja dodatkowa: „predykat” to termin z logiki — zdanie orzekające, któremu można przypisać prawdziwość albo fałszywość; stąd nazwa dla pytań typu tak/nie.)
Jak płynie zapytanie: model, dowody, osąd
Ogólny przebieg wygląda tak: podłączona do usługi aplikacja wysyła do OpenAI zapytanie — jedno z trzech typów, o których wspomniałem. Pytanie trafia do klasyfikatora, którym jest tu GPT-6 Luna. Żeby ocenić sprawę, trzeba razem z pytaniem dostarczyć dowody — materiał, na którym model oprze rozstrzygnięcie. Luna interpretuje te materiały w trakcie ustalania odpowiedzi i przypisywania pewności każdemu z możliwych rozwiązań. Każde zapytanie składa się więc z trzech elementów: modelu, dowodów i osądu, który ma zostać wydany.
Przykład z praktyki: zwroty w sklepie internetowym
Zanim postawię obie usługi naprzeciwko siebie, pokażę na praktycznym przykładzie, o co chodzi — zwłaszcza tym, którzy z Jevem jeszcze nie pracowali.
Wyobraźcie sobie firmę detaliczną albo sklep internetowy i proces obsługi zwrotów. Chcecie ustalić, na co klient się skarży w zgłoszeniu zwrotu. Jako typ pytania wybieracie „wybór opcji”. Następnie piszecie instrukcję wyjaśniającą zadanie, na przykład: „Przeczytaj wiadomość klienta i zdecyduj, jaki problem z produktem zgłasza”. Potem definiujecie warianty, między którymi model ma wybierać: produkt uszkodzony, brak sygnałów uszkodzenia albo za mało informacji — czyli w praktyce „nie wiem”. Można też nadać temu typowi pytania własną nazwę, ale to parametr całkowicie opcjonalny. Usługa błyskawicznie analizuje treść wiadomości i wraca z odpowiedzią oraz procentową pewnością, że właśnie ona jest trafna.
Gdzie Jev, a gdzie OpenAI: miejsca, które się różnią
Mamy punkt odniesienia, więc pora na bezpośrednie zestawienie — w formie przejrzystego przeglądu, żeby od razu było widać, co jest bliżej, a co naprawdę się różni.
Dowody: Jev, przynajmniej według stanu na dzień nagrania, przyjmuje wyłącznie tekst. Decisions API przyjmuje i tekst, i obrazy — to klasyfikator multimodalny. Nie dziwi to zresztą, bo pod spodem pracuje Luna, a Luna, Astra, Terra i Sol od dawna obsługują różne rodzaje danych. OpenAI nie trenowało więc żadnego specjalnego modelu do klasyfikowania — wszystkie ich modele z natury są klasyfikatorami.
Typy odpowiedzi: niemal identyczne w obu usługach. Każda daje prawdopodobieństwo tak/nie, wybór opcji albo pewną formę oceny punktowej. Obie potrafią też odpowiedzieć na kilka pytań dotyczących tych samych dowodów w ramach jednego zapytania.
I tu dochodzimy do pierwszej wyraźnej różnicy — ceny. Jev kosztuje 0,042 dolara za milion tokenów wejściowych, Decisions API — 10 centów za milion. Na papierze, poza multimodalnością, te usługi są więc praktycznie nie do odróżnienia; pod względem kosztów Jev wychodzi jednak o 58% taniej.
(Informacja dodatkowa: token to najmniejsza jednostka tekstu, którą rozliczają się modele językowe; milion tokenów to orientacyjnie 700–750 tysięcy słów.)
Jest jeszcze jedna drobna, ale subtelna różnica: Decisions API przewiduje możliwość odmowy. Są pytania, na które po prostu nie odpowie. Jev natomiast zawsze udzieli odpowiedzi w granicach opcji, które mu zdefiniujesz. Domyślam się, że ta ostrożność ma zapobiegać nadużyciom — zwłaszcza przy rozumieniu obrazów.
Test 1: zdjęcia uszkodzonych urządzeń
Rozumienia obrazów nie da się porównać z Jevem, bo Jev obrazów po prostu nie przyjmuje. Pokażę za to, jak szybko radzi sobie Decisions API.
Zadanie: seria zdjęć — na niektórych urządzenie jest uszkodzone, na innych wygląda nienagannie. Model ma przypisać każde do jednej z trzech kategorii: widoczne uszkodzenie, brak widocznych uszkodzeń albo nie da się ocenić. Klikamy start i niemal natychmiast mamy wynik: „widoczne uszkodzenie”. Widać czas odpowiedzi i koszt zapytania — przy kilkudziesięciu próbach kwota jest pomijalna. Zdjęcie nieskazitelnie wyglądającego urządzenia: „brak widocznych uszkodzeń”, podobny czas, podobny koszt. Ostatnia próba: zdjęcie zamkniętego pudełka. Tu prawidłowa ocena brzmi „nie da się ocenić” — i tak też się stało, choć analiza zajęła odrobinę więcej czasu; koszt bez zmian.
Test 2: dochodzenie po awariach serwisu
Teraz coś trudniejszego — i porównywalnego dla obu usług. Wyobraźmy sobie serwis internetowy, który przeżywa serię awarii, i klasyfikator, którego zadaniem jest ustalić, czym był problem i skąd się wziął. Z listy rozwijanej wybieramy scenariusz, a do każdego przypisanych jest pięciu potencjalnych winowajców: sama strona, płatności, autoryzacja, baza danych albo dostawca zewnętrzny.
Mogłem pozwolić modelom na samodzielne dochodzenie, w którym same wybierają głębokość analizy. Żeby jednak porównać je jak równy z równym, przekazałem obu usługom to samo pytanie, te same dowody i te same opcje do wyboru.
Scenariusz „klienci nie mogą otworzyć sklepu”: odpowiedź odrobinę szybsza po stronie OpenAI, koszt wyraźnie niższy po stronie Jeva. „Klienci nie mogą się zalogować”: ten sam układ. I tak za każdym razem — we wszystkich moich testach Decisions API była zawsze ciut szybsza, ale też zawsze wyraźnie droższa. Przy jednym z wariantów mieliśmy 165 versus 144 milisekundy — bardzo blisko; przy kolejnym 198 versus 134. Koszt trzymał się wciąż tego samego rozkładu.
Był też tryb pełnego dochodzenia, w którym model dostaje większą swobodę i może zejść głębiej w analizę, jeśli uzna to za zasadne. Widoczna jest różnica w przebiegu — model przechodzi przez kolejne rozstrzygnięcia — ale obie usługi doszły do dokładnie tego samego wniosku, a prędkość i koszt nie odbiegły od tego, co widzieliśmy wcześniej.
Test 3: sprawdzanie tez w raporcie firmowym
Ostatnia sytuacja: przeglądacie raport firmowy i chcecie zweryfikować pięć kluczowych stwierdzeń. Bierzemy na przykład sierpniowy raport biznesowy — jest w nim pięć tez. Po kliknięciu start każda z nich dostaje werdykt: sprzeczna z dowodami, dowodów za mało albo potwierdzona. Obie usługi zgadzały się w stu procentach, czasy odpowiedzi były bardzo zbliżone, a koszt — jak zwykle — o jakieś 40–50% niższy na Jevie. Ten sam schemat powtórzył się w drugim i trzecim przykładzie; największa pojedyncza rozbieżność, jaką wyłapałem, to około 50 milisekund.
Zbierając całą weryfikację raportów do kupy: obie usługi odpowiedziały poprawnie na wszystko — pytania zresztą nie były specjalnie trudne. Średnie zapytanie trwało 155 milisekund na Jevie przeciw 146 na OpenAI, mediana była niemal identyczna, a koszt wyraźnie korzystniejszy dla Jeva. W dochodzeniach po awariach, które były bardziej złożone, cały test kosztował na Jevie prawie połowę mniej, a różnica w szybkości okazała się większa: 181 versus 143 milisekundy. Przy tak małych próbkach to niuanse — ale przy milionach rekordów mnożenie robi swoje. Przy dziesiątkach, tysiącach, a nawet dziesiątkach tysięcy zapytań różnica pozostaje praktycznie niezauważalna.
Werdykt: którą usługę wybrać
Podsumujmy. Obrazy? Decisions API, bez dyskusji. Niższy koszt przy dużej skali? Jev. Szybsze pojedyncze wywołanie w średniej? OpenAI. Szybsze pełne dochodzenie w medianie? Jev. Skuteczność? Remis.
Ujmując rzecz krótko: jeśli liczy się cena — Jev. Jeśli potrzebujesz multimodalności i szybszych pojedynczych zapytań — Decisions API. Ten rynek zmienia się z dnia na dzień, więc jeśli wydarzy się coś istotnego, będę śledzić sprawę i dam znać. Jeśli materiał był pomocny, łapka w górę i komentarz pod filmem bardzo wspierają zasięgi kanału. Do zobaczenia w następnym.