basal-1.0 - dynamiczny klasyfikator
Otwarty klasyfikator dla języka polskiego i angielskiego. Jak działa, co potrafi i ile czasu potrzebuje na decyzję — od serwera z B300 po biurkowy HP ZGX Nano (Nvidia DGX Spark).
W wielu procesach najważniejsza odpowiedź jest krótka: wybór zespołu, ocena pilności albo decyzja, czy zebrane informacje wystarczą do kolejnego kroku. Właśnie do takich zadań powstał basal-1.0 — rodzina otwartych modeli decyzyjnych wyspecjalizowanych w języku polskim, obsługujących również angielski.
Klasyfikator definiujesz dynamicznie w każdym zapytaniu, zależnie od potrzeb — bez konieczności trenowania modelu do nowego zadania. Podajesz kontekst, pytanie i dozwolone odpowiedzi, a basal zwraca rozkład prawdopodobieństw oraz wynik w określonym formacie.
Model możesz uruchomić lokalnie, na własnym komputerze lub we własnej infrastrukturze, bez powierzania danych innym podmiotom.
Jedno pytanie, konkretna decyzja
Wyobraź sobie wspólny formularz kontaktowy dla kilku zespołów. Do basal przekazujesz treść wiadomości, pytasz o właściwy dział i opisujesz dostępne kolejki. Odpowiedź wskazuje jedną z nich, razem z prawdopodobieństwami dla pozostałych opcji. To wystarcza, by aplikacja skierowała sprawę dalej.
Model odczytuje prawdopodobieństwa przypisane do dopuszczonych odpowiedzi, bez generowania tekstu. Dzięki temu wynik mieści się w zdefiniowanym zbiorze, a jego format łatwo wykorzystać w kodzie. Domyślnie silnik sprawdza dwie kolejności opcji i uśrednia wynik, ograniczając wpływ ich ułożenia.
choice- Wybór jednej opcji. Który zespół, jaka kategoria dokumentu, które narzędzie agenta?
noul- Prawdopodobieństwo „tak”. Czy opis jest kompletny? Czy w tekście występuje wskazany warunek?
score- Ocena na opisanej skali. Na przykład pilność od 0 do 3. Odpowiedź zawiera prawdopodobieństwa poziomów i ich wartość oczekiwaną.
Jedno pytanie może mieć od 2 do 10 opcji. Nazwa basal nawiązuje do basal ganglia, czyli jąder podstawy mózgu uczestniczących w wyborze działania. Opis interfejsu znajdziesz w dokumentacji API na GitHubie.
Dwa rozmiary, ten sam sposób użycia
basal-1.0-4.5B to wariant o najwyższej jakości w tej rodzinie. basal-1.0-1.5B potrzebuje mniej zasobów i na testowanych urządzeniach podejmuje decyzje zwykle około dwa razy szybciej, kosztem części trafności. Oba używają tego samego API i tych samych typów pytań.
Oznaczenie 1.5B mówi o 1,5 miliarda parametrów — to mniejszy model z rodziny basal-1.0. Dostępne są również warianty wag FP8 i NVFP4; ich dobór zależy od sprzętu i akceptowanej zmiany jakości.
Wagi oraz silnik inferencji udostępniono na licencji Apache 2.0. Możesz uruchomić model we własnej infrastrukturze i wykorzystać go komercyjnie zgodnie z warunkami licencji. Szczegóły pochodzenia modeli i wymaganej atrybucji opisują LICENSE oraz NOTICE.
Polska specjalizacja widoczna w wynikach
Na zbiorze 7 081 polskich decyzji testowych wariant 4.5B osiągnął 88,4% trafności, a 1.5B — 84,9%. Wynik większego modelu jest o 10,5 punktu procentowego wyższy od najlepszego z 11 porównywanych otwartych systemów decyzyjnych.
| Model | Decyzje PL | Decyzje EN |
|---|---|---|
| basal-1.0-4.5B | 88,4% | 74,1% |
| basal-1.0-1.5B | 84,9% | 73,4% |
| Jev 1.13.0 · API | 78,0% | 73,6% |
| AutoJev-27B | 77,9% | 75,3% |
PL: 7 081 przykładów; EN: 1 479. Wyniki basal z silnika w trybie fast, po uśrednieniu dwóch kolejności opcji. Źródło: tabela jakości w README.
W angielskich zadaniach decyzyjnych różnice między basal-1.0-4.5B, Jev i najlepszymi otwartymi modelami mieszczą się w podanych w raporcie 95-procentowych przedziałach ufności. Z kolei na ogólnym, publicznym benchmarku po angielsku basal-1.0-4.5B uzyskuje 74,0%, przy 87,9% dla Cygnet. Specjalizacja w polskich decyzjach nie oznacza przewagi w każdym zadaniu.
To ewaluacja na danych generowanych, osadzonych w źródłach lub weryfikowanych. Zbiór testowy był konsultowany podczas rozwoju modelu, co również trzeba uwzględnić przy interpretacji wyników. Przed wdrożeniem potrzebny jest sprawdzian na własnych przykładach. Pełne porównanie zawiera raport techniczny basal-1.0.
Milisekundy na serwerze i na biurku
Jedna decyzja wariantu 4.5B zajmuje w pomiarach offline 8,8 ms na B300 w trybie bf16 i 44,6 ms na HP ZGX Nano (Nvidia DGX Spark) (GB10) w FP8. Mniejszy model na tym samym urządzeniu potrzebuje 18,1 ms.
| Urządzenie i tryb | 4.5B | 1.5B |
|---|---|---|
| NVIDIA B300 · bf16 | 8,8 ms | 4,7 ms |
| NVIDIA H100 · bf16 | 12,5 ms | 6,2 ms |
| GeForce RTX 5090 · FP8 | 19,4 ms | 9,3 ms |
| HP ZGX Nano (Nvidia DGX Spark) (GB10) · FP8 | 44,6 ms | 18,1 ms |
Batch 1, obie kolejności opcji, prywatna próbka 500 przypadków PL/EN. Pomiar przez HTTP obejmuje dodatkowy narzut: dla 4.5B na B300 w trybie fast mediana wynosi 9,7 ms. Warunki i komplet pomiarów sprzętowych.
Niższa precyzja wag może przyspieszyć pracę, ale zmienia część decyzji. W testach FP8 zmieniało około 2–4% wyborów względem referencji, a NVFP4 obniżało trafność o około 3 punkty procentowe. Tryb i progi pewności warto sprawdzić razem na docelowym sprzęcie.
Od wiadomości do właściwej kolejki
Na początek wybierz jedno małe zadanie. Dobrze sprawdzają się routing zgłoszeń, kategoryzacja dokumentów, ocena pilności oraz wybór następnego narzędzia agenta. Opisz kategorie tak, by były rozłączne, i dodaj opcję dla spraw niepasujących do pozostałych.
Po instalacji silnika i uruchomieniu lokalnego serwera wywołanie z Pythona może wyglądać tak:
from basal.client import Basal
model = Basal("http://127.0.0.1:8000")
answer = model.choice(
"Po zmianie telefonu nie mogę wejść na konto.",
"Do której kolejki skierować zgłoszenie?",
{
"account": "Dostęp do konta",
"payments": "Płatności i rozliczenia",
"other": "Inny temat",
},
)
print(answer["choice"])
print(answer["confidence"])HTTP udostępnia tę samą decyzję przez POST /v1/systemone. Wysyłasz state i questions, a odpowiedź zawiera answers, w tym wybór, prawdopodobieństwa i poziom pewności. Na stronie są także przykłady TypeScript i cURL.
Dalszy krok należy do aplikacji: mapuje etykietę na kolejkę, uruchamia dozwoloną funkcję albo kieruje niepewny przypadek do człowieka. W katalogu 18 zastosowań znajdziesz gotowe definicje wejścia i przykładowe odpowiedzi JSON.
Pewność pomaga. Weryfikacja nadal jest potrzebna.
Wysokie prawdopodobieństwo nie gwarantuje poprawnej decyzji. Silnik kalibruje odpowiedzi osobno dla typów pytań, ale gotowe progi z dokumentacji były sprawdzane dla konkretnego formatu wejścia. Po zmianie opisów, widoczności kluczy opcji lub precyzji wag należy dobrać próg na oznaczonych danych z własnego procesu.
- Obliczenia zostaw kodowi. Model może pomylić sumę, dokładny próg liczbowy lub złożoną regułę, również z wysoką pewnością. Przekaż mu obliczone wartości i rozbij trudną ocenę na prostsze pytania.
- Dostarczaj fakty i aktualne zasady. Wiedza małego modelu jest ograniczona. W
statepowinny znaleźć się informacje potrzebne do rozstrzygnięcia. - Sprawdzaj znane błędy. Dokumentacja basal-1.0 opisuje m.in. błędnie nauczony przypadek okresu wypowiedzenia. Poprawienie etykiety w benchmarku nie poprawia automatycznie wag modelu.
- Zachowaj nadzór nad istotnymi decyzjami. Kontrola uprawnień, wykonanie akcji i rozpatrywanie przypadków o poważnych skutkach dla ludzi pozostają po stronie aplikacji i jej operatorów.
Raport opisuje również pochodzenie danych treningowych i ograniczenia ich identyfikowalności. Przed użyciem produkcyjnym przeczytaj pełną listę ograniczeń i oceń model na przypadkach istotnych dla Twojego zastosowania.
Materiały do pierwszego wdrożenia
Więcej informacji o basal-1.0 znajdziesz w dokumentacji projektu — od instrukcji uruchomienia i opisu API po szczegółowe wyniki testów i pomiary sprzętowe.