Jev na Cloudflare Workers AI: gdzie się sprawdził, a gdzie nie

Jev to model, który zamiast tekstu zwraca decyzję z prawdopodobieństwem: wybór z listy, ocenę albo tak/nie. Przez Cloudflare Workers AI wywołuje się go jednym zapytaniem HTTP. Użyliśmy go w trzech projektach. W ASAPChat oznacza tematy wiadomości klientów i te, którymi powinien zająć się człowiek. Przy dopasowaniu katalogu produktów wyłapywał błędne kody EAN. W projekcie weryfikacji dokumentów w branży regulowanej nie mógł zostać użyty, a jego otwarty odpowiednik nie dał nic ponad model, który już tam działał.

Czym jest Jev i czym różni się od modelu językowego?

Zwykły model językowy na pytanie „czy klient jest zdenerwowany” odpowiada zdaniem, które trzeba potem sparsować. Jev dostaje pytanie w ustalonym formacie i zwraca liczbę albo klucz z listy. Typy pytań są trzy:

• choice: wybór jednej opcji z listy, którą podajesz, razem z pewnością wyboru,
• score: ocena według poziomów opisanych w pytaniu,
• noul: prawdopodobieństwo odpowiedzi „tak” od 0 do 1.

Kontekst ma 32 tys. tokenów. Cloudflare deklaruje dla tego modelu brak przechowywania danych. Model jest dostępny tylko przez API: wag nie da się pobrać ani uruchomić u siebie. To zdecydowało o tym, gdzie mogliśmy go użyć.

Chcesz, żeby AI podejmowało proste decyzje w Twoim systemie? Klasyfikacja zgłoszeń, dopasowanie produktów, wykrywanie oszustw. Najpierw test na Twoich danych, potem tryb cienia, dopiero wtedy przełączenie. Agenci AI →

Jak Jev sprawdził się w ASAPChat?

ASAPChat to nasz system do obsługi klientów sklepów: czat na stronie, wiadomości z Allegro, Messengera i poczty w jednym panelu. Przed Jev o tym, czy rozmowę przejąć, decydowały reguły i słowa kluczowe, a phishing podszywający się pod Meta wyłapywał regex.

Najpierw zrobiliśmy test offline na 32 przygotowanych polskich wiadomościach z etykietami. Jev dostawał trzy pytania naraz: temat wiadomości (jeden z sześciu, np. status zamówienia, zwrot, reklamacja), czy wiadomość powinien obsłużyć człowiek i czy to próba oszustwa.

Test od razu znalazł błąd w starym regexie. Klientka, która pisała o zablokowanym koncie w banku i opóźnionej płatności, była oznaczana jako phishing, bo pasowała do wzorca „blokada konta”. Jev ocenił tę wiadomość poprawnie.

32 przypadki to za mało, żeby zastąpić reguły, ale wystarczy, żeby zbierać dane na produkcji. Od 30 września 2026 r. każda nowa wiadomość klienta trafia do Jev w tle. Wynik jest widoczny w panelu jako plakietka tematu i flaga „Potrzebny człowiek” przy prawdopodobieństwie od 0,7. Tematy rozmów pojawiają się też w analityce. Odpowiedzi AI i szkice się nie zmieniły: decyzję o wysyłce dalej podejmują dotychczasowe reguły.

Przed wysłaniem treści do Cloudflare system zamienia adresy e-mail, linki i numery telefonów na znaczniki. Cloudflare dopisaliśmy do polityki prywatności jako podmiot przetwarzający. Jedno wywołanie trwa około 320–390 ms i zużywa około 850 tokenów. Zastąpienie regexu phishingu i filtra spamu w poczcie zaplanowaliśmy dopiero po porównaniu wyników z produkcji z decyzjami operatorów.

Jak Jev pomógł przy dopasowaniu katalogu produktów?

W projekcie porównania katalogu producenta z ofertami na Allegro mieliśmy ponad 10 tys. pozycji. Większość dopasowań załatwia kod EAN. Jev dostał dwa zadania tam, gdzie kod nie wystarcza:

• Wybór z kandydatów (choice), gdy jeden numer katalogowy pasuje do kilku produktów. Test na trzech kandydatach dał poprawną odpowiedź z pewnością 1,0 w około 450 ms i za około 0,000025 USD.
• Weryfikacja dopasowania (noul): czy produkt z Allegro to ten sam produkt co w katalogu. Katalog Allegro myli kody EAN w części kart. Mata trafiła pod kod innego producenta, a osłona twarzy pod przyłbicę dziecięcą. Jev dał tym parom 0,06 i 0,28, a poprawnym dopasowaniom od 0,65 do 0,96. Przy progu 0,5 oba błędy trafiły do ręcznej weryfikacji.

W pełnym przebiegu weryfikacja zrobiła około 1800 wywołań. Odpowiedzi z niską pewnością nie były odrzucane, tylko trafiały na listę do przejrzenia przez człowieka. Jev nie zastąpił więc dopasowania po kodzie. Pilnował go i odsiewał to, czego kod nie rozstrzyga.

Gdzie Jev się nie sprawdził?

W projekcie weryfikacji dokumentacji w branży regulowanej system czyta skany wypełniane ręcznie i oznacza miejsca do sprawdzenia przez rewidenta. Szukaliśmy modelu, który oceniłby, czy oznaczenie jest trafne. Jev odpadł bez testu z dwóch powodów:

• dokumenty nie mogą opuścić serwera klienta, a Jev działa tylko jako API zewnętrznej firmy,
• model używany w procesie decyzyjnym musi mieć zamrożoną i zwalidowaną wersję, a w hostowanym API nie da się przypiąć wersji na lata.

Sprawdziliśmy więc alternatywy, które da się uruchomić u siebie. Otwarty model decider działa tylko po angielsku, a nasze dane to polskie odczyty pisma ręcznego. Tłumaczenie przed decyzją dokładałoby błędy. Został pplx-decider-v1-27b od Perplexity: otwarte wagi, licencja Apache 2.0, dostrojony Qwen. Zmierzyliśmy go na wynajętym GPU na danych projektu, obok modelu Qwen, który system już miał, z prawdopodobieństwami odczytanymi z logitów.

Wyszedł remis. W ocenie z samego tekstu oba modele były blisko losowego wyniku w obrębie jednego rodzaju uwagi, bo prawdę o błędzie niesie skan, a nie opis uwagi. Na wycinku z datą oba trafiały prawie zawsze, ale Qwen miał lepiej skalibrowane prawdopodobieństwa i był szybszy. pplx-decider dołożyłby do serwera kolejne ok. 49 GB wag i nic poza tym. Nie wdrożyliśmy go.

Wniosek z tego projektu dotyczy nie tylko Jev. Zanim dobierze się model do decyzji, trzeba mieć etykiety. W tym systemie realne decyzje rewidentów dopiero się zbierają, a kalibrację zrobimy po kilkuset z nich. Bez tego żaden model, hostowany ani lokalny, nie da prawdopodobieństwa, któremu można ufać.

Jak użyć Jev przez Cloudflare Workers AI?

1. Załóż konto Cloudflare i zasil środki na Workers AI. Bez nich API odpowiada błędem 2021 „Insufficient balance”.
2. Utwórz token API z uprawnieniem tylko do Workers AI. Nie używaj globalnego klucza konta.
3. Wyślij zapytanie z modelem w treści. Model podany w ścieżce adresu kończy się błędem „No route”.

curl https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/ai/run \
  -H "Authorization: Bearer $CF_AI_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "typesafe/jev",
    "input": {
      "state": "Wiadomość klienta: Paczka miała być wczoraj, a dalej jej nie ma.",
      "questions": {
        "needs_human": {
          "type": "noul",
          "instructions": "Czy tę wiadomość powinien obsłużyć człowiek zamiast AI?",
          "criteria": { "true": "przekazać człowiekowi", "false": "AI może odpowiedzieć" }
        }
      }
    }
  }'

Odpowiedź jest zagnieżdżona dwa razy: wyniki są w result.result.answers, a zużycie tokenów w result.result.usage. Pierwsza wersja naszego klienta czytała jeden poziom niżej i każde wywołanie kończyło się wyjątkiem. Test na tę kopertę mamy dziś w zestawie testów.

Kilka zasad, które przyjęliśmy przy każdym wdrożeniu:

• najpierw test offline na danych z etykietami, potem tryb cienia, a dopiero potem przełączenie,
• zawsze fallback na dotychczasową regułę przy błędzie API, przekroczonym czasie (w ścieżce czatu 1 s) albo niskiej pewności,
• próg pewności w konfiguracji, nie w kodzie, i log każdej decyzji razem z wynikiem reguły,
• żadnej nieodwracalnej akcji, np. zamknięcia wątku albo wysyłki, na podstawie samego Jev,
• dane kontaktowe maskowane przed wysłaniem, dostawca wpisany w politykę prywatności.

Jeśli w Twoim systemie są decyzje, które dziś podejmuje regex albo człowiek, a dane mogą trafić do API, Jev jest tani w sprawdzeniu. Gdy dane muszą zostać u Ciebie, ten sam schemat pytań działa na lokalnym modelu. Szerzej o tym, jak budujemy takie elementy, piszemy w ofercie agentów AI i AI w branżach regulowanych.