basal-omni-2.0-mini (podgląd): czytanie w obie strony i 0,811 w Werdykcie

Co to jest podgląd 2.0 mini

Finalne basal-omni 2.0 wydamy później, razem z całą rodziną: nano, mini, max i ultra. Ten podgląd pozwala wypróbować 2.0 mini już teraz. Finalny mini może się od niego różnić.

Model dostroiliśmy z Google Gemma 4 E4B na polskich i angielskich typowanych decyzjach. Wagi mają licencję Apache-2.0, tak jak model bazowy. Repozytorium na Hugging Face to Remek/basal-omni-2.0-mini-preview.

Podgląd obsługuje publiczny silnik basal 2.8.0, z tym samym API co basal-omni-1.0: te same typowane pytania i ten sam endpoint POST /v1/systemone. To model tekstowy: trenowaliśmy go i ocenialiśmy tylko na tekście.

Co nowego w 2.0

• Czytanie w obie strony. Model czyta stan w obu kierunkach, zanim odpowie. Do tego potrzebny jest silnik basal 2.5 lub nowszy. O długich promptach piszemy w ograniczeniach.
• Wyższa trafność w naszym ukrytym, polsko-angielskim teście decyzji Werdykt i w testach odłożonych, które pokazujemy niżej.
• Więcej decyzji do automatyzacji przy zadanym celu błędu. Pokrycie podajemy w części o pewności.
• Bez zmian: skalibrowane prawdopodobieństwo dla każdej dozwolonej odpowiedzi, w jednym przebiegu modelu. Odpowiedź nigdy nie wychodzi poza podane opcje, a prawdopodobieństwo mówi, jak pewny jest model.

Typy pytań się nie zmieniają: choice (jedna opcja), noul (tak / nie), score (ocena), a w silniku basal także multi, act i tool. Opcje dostają kody (A–Z, potem kody dwuznakowe, do 255 opcji). Decyzją jest rozkład prawdopodobieństwa tylko po tych kodach, bez generowania tekstu.

Wyniki

Werdykt to nasz ukryty test: 5 000 decyzji po polsku i angielsku w 10 kategoriach. Wynik makro liczy każdą z 20 grup (kategoria × język) z tą samą wagą. Pozostałe wiersze to testy odłożone.

Testy odłożone: publiczny silnik basal 2.8.0 i pliki z wydania, jedna karta NVIDIA H100, --mode eager, bf16, jedna kolejność opcji (domyślna), dołączony CALIBRATION.json. Werdykt: silnik basal 2.5, --mode fast, jedna kolejność opcji, jedna karta NVIDIA RTX PRO 6000 Blackwell (bf16). Publiczny silnik 2.8.0 daje te same prawdopodobieństwa na naszym zestawie kontrolnym (największa różnica 5 × 10⁻⁶).

Panel angielski to dziesięć publicznych zadań. W wyniku panelu każde zadanie waży tyle samo, niezależnie od liczby pytań.

Najsłabsze kategorie Werdyktu to reguły (0,382), długie dokumenty (0,694) i umowy (0,726). Reguły wymagają dokładnych progów i dat; takie obliczenia wykonuj w kodzie. Najmocniejsze kategorie to wybór fragmentu (0,982), rzeczywiste dokumenty (0,978) i routing (0,966).

Więcej o Werdykcie →

Porównanie w Werdykcie

Ten sam test przeszło pięć innych modeli decyzyjnych: najmocniejsze modele klasy 4B, które sprawdziliśmy, oraz polski Bielik-One w wersjach 4B i 11B. To zestawienie wybranych modeli, nie pełny ranking.

Werdykt v1: te same 5 000 ukrytych pytań (PL + EN) i ten sam klient (16 równoległych żądań, ukryte klucze opcji), przez typowane API decyzji każdego modelu (/v1/systemone). Każdy model działa na serwerze zalecanym przez jego twórcę; protokół i pytania są te same. KnowLine-4B-Gen5.5 działał w FP8, pozostałe modele w bf16. Zbiór jest ukryty i nie ma publicznych pytań, więc pokazujemy tylko wyniki zbiorcze. Wynik makro: każda z 20 grup (kategoria × język) waży tyle samo. Przewaga to sparowany bootstrap na tych samych 5 000 pytaniach. Pomiary z 8 października – 13 listopada 2026: podgląd w silniku basal 2.5 (--mode fast, jedna kolejność opcji), H2O-Lightning-4B v1.1 na H100 (ten sam wynik co na publicznej tablicy), pozostałe na RTX PRO 6000. Rewizje: torchcast-ai/torchcast-decision-4b @492bfb19, PelaAI/KnowLine-4B-Gen5.5 @779944d2, speakleash/Bielik-One-11B-v3.1-r1-Adapter @aab0a71f, speakleash/Bielik-One-4B-r1 @a5a17dad.

Podgląd wyprzedza każdy z tych modeli, a w każdej parze 95% przedział przewagi nie obejmuje zera. Najbliżej jest torchcast-decision-4b: 1,22 pkt różnicy. Nad Bielik-One 11B i 4B przewaga wynosi 10,82 i 11,46 pkt.

Trafność a długość dokumentu

Tak wygląda trafność w Werdykcie (5 000 pytań, po polsku i angielsku) według długości stanu w znakach. Token to około 2 znaki, a 1 000 znaków to mniej więcej pół strony. Łącznie: 81,1%. Zbiór jest ukryty, więc pokazujemy tylko te sumy.

Krótkie stany to głównie pytania o reguły i pytania, w których właściwą odpowiedzią jest wstrzymanie się od decyzji. To trudniejsze zadania, więc wiersze pokazują trafność w danym przedziale, a nie wpływ samej długości. Rodzina długich dokumentów zachowuje to samo zadanie i zmienia tylko długość:

Ten sam przebieg co wynik Werdyktu powyżej. Przedziały Wilsona opisują niepewność wynikającą z liczby pytań, a nie zmienność między przebiegami.

W rodzinie długich dokumentów trafność spada wraz z długością, najmocniej powyżej 30 tys. znaków. Jeśli Twoje dokumenty są tak długie, sprawdź model na własnych przykładach.

Pewność i automatyzacja

W repozytorium modelu plik CALIBRATION.json zawiera temperatury dla każdego typu pytania i certyfikowane progi pewności dla celu 1% albo 5% błędu wśród przyjętych decyzji. Progi wybraliśmy na danych kalibracyjnych, zanim uruchomiliśmy testy, w silniku, który serwuje model (--mode eager, bf16, jedna kolejność opcji). Decyzje powyżej progu przyjmujesz automatycznie, a resztę kierujesz do człowieka.

Testy odłożone: decyzje PL i test korpusu EN, razem 8 560 decyzji, z progami dla każdego typu pytania z dołączonego CALIBRATION.json, tak jak stosuje je serwer.

Przy celu 1% pytania score nie mają certyfikowanego progu i trafiają do człowieka. Według typu: choice 78,2% przy błędzie 0,74%, tak / nie 43,8% przy błędzie 0,15%. Przy celu 5%: choice 94,7%, tak / nie 88,0%, score 47,6%.

Dla --orders 2, czyli pytania w obu kolejnościach opcji, model ma osobny plik CALIBRATION.o2.json.

Szybkość

W pierwszych trzech wierszach jedno pytanie na żądanie. fast jest domyślny na GPU Hopper z FlashAttention 3; eager mierzyliśmy z --media on. Pamięć GPU podczas serwowania: 20,6 GB (fast), 31,7 GB (eager, --media on). --orders 2 kosztuje mniej więcej dwa razy więcej na pytanie.

Szybkość na tle innych modeli

W tych samych przebiegach Werdyktu mierzyliśmy też szybkość. Na wykresie jest pięć modeli z tabeli porównania, które działały na tym samym GPU.

Ograniczenia

• Podgląd. To wczesne wydanie 2.0 mini; finalna rodzina 2.0 (nano, mini, max, ultra) pojawi się później. Sprawdź model na własnych dokumentach, zanim się na nim oprzesz.
• Długie prompty. Stan jest czytany w obie strony do 4 096 tokenów promptu (8 192 tokeny na żądanie). Dłuższe prompty model czyta w jedną stronę, jak basal-omni-1.0, a odpowiedź nie mówi, który sposób czytania zastosowano. Na najdłuższych dokumentach trafność jest niższa (zob. trafność a długość dokumentu).
• Funkcje serwera. Dla modelu czytającego w obie strony silnik wyłącza cache stanu, cache prefiksu, jednokrotne czytanie stanu dla wielu pytań (SOAM) i osobny tor dla długich żądań (long lane). Kilka pytań o ten sam stan zadawaj w jednym żądaniu.
• Tylko tekst. Pliki modelu zawierają niezmienione kodery obrazu i dźwięku z Gemma 4, ale ten podgląd trenowaliśmy i ocenialiśmy tylko na tekście. Używaj go do tekstu; odpowiedzi dla mediów nie były tu oceniane.
• Dokładna arytmetyka i progi to słaby punkt decyzji w jednym przebiegu (reguły w Werdykcie: 0,382). Licz je w kodzie.
• Kolejność opcji. Domyślnie model widzi jedną kolejność opcji. --orders 2 zmniejsza wrażliwość na kolejność, mniej więcej za dwukrotny koszt obliczeń.
• Silnik 2.8.0: tylko bf16; ten podgląd nie ma wersji FP8 ani GGUF.
• Nadzór człowieka. Decyzje o poważnych skutkach dla ludzi powinien sprawdzać człowiek.

Jak zacząć

Link do wag aktywuje się, gdy repozytorium będzie publicznie dostępne na Hugging Face.

• basal-omni-2.0-mini-preview · BF16 ↗

Zainstaluj silnik 2.8.0 w nowym środowisku uv:

uv venv --python 3.12 --allow-existing ~/basal-env && source ~/basal-env/bin/activate
uv pip install torch==2.11.0 torchvision==0.26.0 --index-url https://download.pytorch.org/whl/cu128
uv pip install "basal[media] @ https://github.com/rkinas/basal/archive/refs/tags/v2.8.0.tar.gz"

Uruchom serwer. Gdy model jest gotowy, serwer wypisuje basal: model ... ready.

basal-serve --model Remek/basal-omni-2.0-mini-preview --name basal-omni-2.0-mini-preview --port 8000

Na GPU NVIDIA silnik sam wybiera tryb: fast (CUDA graphs) na Hopperze z FlashAttention 3 i na kartach Blackwell do stacji roboczych, a eager (PyTorch, bf16) na pozostałych GPU. Wagi zajmują około 16 GB. Model czytający w obie strony działa tylko w trybach --mode eager i --mode fast. Na Apple Silicon podaj --mode eager, bo domyślny tryb silnika na tym sprzęcie nie obsługuje modeli czytających w obie strony. Domyślnie model dostaje jedną kolejność opcji; --orders 2 sam korzysta z pliku CALIBRATION.o2.json.

Zadaj pytania. W jednym żądaniu wybieramy dział dla zgłoszenia klienta i pytamy, czy klient nie może korzystać z usługi:

curl -s localhost:8000/v1/systemone -H 'content-type: application/json' -d '{
  "state": "Klient: od wczoraj nie mogę zalogować się do bankowości internetowej, system pokazuje błąd hasła.",
  "questions": {
    "dept":   {"type": "choice", "instructions": "Do którego działu skierować zgłoszenie?",
               "criteria": {"cards": "Reklamacje kart", "online": "Wsparcie bankowości elektronicznej", "loans": "Kredyty"}},
    "urgent": {"type": "noul", "instructions": "Czy klient nie może korzystać z usługi?"}}}'

Pełne API (multi, act, tool, klucze opcji, max_error) opisuje dokumentacja silnika. Licencja: Apache-2.0; model dostrojony z google/gemma-4-E4B-it (Apache-2.0).

Wydanie silnika 2.8.0 → · REST, MCP i serwer inferencji → · Więcej o Werdykcie →