jev-latest

Jev to flagowy model TypeSafe i pierwszy model nowej klasy System One. Nie pisze tekstu, lecz szybko podejmuje decyzje, które program może od razu wykorzystać: przekazujesz stan (state) — tekst lub JSON — oraz zestaw pytań, a w odpowiedzi otrzymujesz wartości o określonych typach ze skalibrowanymi prawdopodobieństwami.

Modele językowe piszą słowa dla ludzi, natomiast Jev według TypeSafe jest bliższy kodowi: odpowiedź od razu ma formę potrzebną w kodzie, szybkość jest wysoka i nie pojawia się żadna wartość spoza zadanych wariantów. Model zaprojektowano tak, aby udzielał stabilnych odpowiedzi przy powtarzanych żądaniach.

Czym System One różni się od modelu językowego

• Nie generuje. Jev nie pisze odpowiedzi dla użytkownika, nie pisze kodu i nie wyjaśnia przebiegu rozumowania. Możliwe odpowiedzi określasz sam — przez jeden z trzech typów pytań.
• Jest trenowany do skalibrowanych decyzji. TypeSafe trenuje model metodą RLCD (Reinforcement Learning for Calibrated Decisions): prawdopodobieństwa są dopasowywane do rzeczywistych wyników i odzwierciedlają niepewność. Wśród wielu odpowiedzi z prawdopodobieństwem 0,8 około 80% powinno być poprawnych. Kalibracja jest właściwością dużej próby, a nie gwarancją poprawności pojedynczej odpowiedzi.
• Inny cel trenowania. Modele czatu są uczone, aby podobać się ludziom (RLHF), co według obserwacji TypeSafe sprzyja nadmiernemu przypodobywaniu się i pewnie brzmiącym błędom. Jeden ze współautorów RLHF, Diogo Almeida, jest współzałożycielem TypeSafe.

Nazwa nawiązuje do „Systemu 1” z książki Daniela Kahnemana „Pułapki myślenia. O myśleniu szybkim i wolnym”: szybkiego intuicyjnego osądu w przeciwieństwie do powolnego, przemyślanego myślenia „Systemu 2”. Jev został stworzony do szybkich, wąskich ocen.

Trzy typy pytań

Pytanie jest pojedynczym osądem stanu, a odpowiedź — wartością, którą kod porównuje z progiem, sortuje lub przekazuje dalej.

1. Choice — wybór wariantu. Dział obsługujący zgłoszenie, kategoria produktu, język fragmentu kodu. Warianty to słownik „wariant → opis”, do 255 pozycji. Odpowiedź zawiera wybrany choice, prawdopodobieństwa probabilities wszystkich wariantów (o sumie 1) i pewność confidence. Jeśli lista może nie obejmować wszystkich przypadków, dodaj „inne” lub „żadne z wymienionych”.
2. Score — ocena na skali. Miejsce na uporządkowanej skali opisanej przez użytkownika: istotność błędu, irytacja klienta, poziom umiejętności. Od 2 do 10 poziomów, od najniższego do najwyższego; każdy poziom model ocenia osobno, nie widząc jego numeru ani sąsiadów. Odpowiedź zawiera score (sumę numerów poziomów pomnożonych przez ich prawdopodobieństwa, więc wartość może znaleźć się między poziomami), legend z opisami poziomów, probabilities i confidence.
3. Noul — tak lub nie. Czy stwierdzenie jest prawdziwe. Odpowiedź noul jest prawdopodobieństwem „tak” od 0 do 1: blisko 1 — pewne „tak”, blisko 0 — pewne „nie”, blisko 0,5 — model się waha. Nie ma osobnego confidence: jedna liczba opisuje odpowiedź w całości. Opcjonalne criteria doprecyzowuje, co uznawać za „tak”, a co za „nie”.

Jak wybierać: znane warianty bez kolejności — choice; stopnie spektrum — score; czyste „tak/nie”, gdy ważne jest samo prawdopodobieństwo — noul. Noul 0,5 oznacza równe szanse „tak” i „nie”, a nie „średni poziom”: stopień mierzy score. Z dwóch odpowiednich typów wybieraj ten, na podstawie którego kod od razu działa: choice — gałęzie, score — próg, noul — if.

Typy można łączyć w jednym żądaniu. Odpowiedź zawsze jest ograniczona do twoich wariantów i nie zależy od innych pytań: pytania można dodawać i usuwać bez zmieniania pozostałych odpowiedzi.

Stan

Stan jest tym, co model ocenia: wiadomością klienta, fragmentem dokumentu, rekordem bazy lub stanem aplikacji.

• Ciąg tekstowy — gdy tekst jest jeden: wiadomość, artykuł, fragment.
• Obiekt — nazwane pola, powiązane rekordy, stan aplikacji. TypeSafe zaleca obiekt dla większości żądań: każda część ma zrozumiałą nazwę.
• Tablica — sekwencja wiadomości lub rekordów.

Przygotowuj go jak materiały dla ekspertów: korespondencję, zamówienie i reguły zwrotów umieszczaj razem, jeśli decyzja wymaga ich porównania. Treść trzymaj w stanie, a osądy — w pytaniach. Jeśli pytanie dotyczy jednej części stanu, wskaż w nim ścieżkę do niej w grawisach, na przykład ticket.messages[0].text.

Jak formułować pytania

• Jeden szybki osąd na pytanie. Dobre pytanie to takie, na które znająca temat osoba z potrzebnym kontekstem odpowie w sekundę: „Czy wiadomość wskazuje na pilność?”. „Przeanalizuj wiadomość i zdecyduj, co zrobić” wymaga już powolnego rozumowania; trzeba je podzielić na proste pytania.
• Całe pytanie w instructions. Klucz pytania, na przykład refund_requested, służy tylko twojemu kodowi i nie jest przekazywany modelowi.
• Wszystkie pytania do jednego stanu w jednym żądaniu. Model ocenia je równolegle: według TypeSafe dodatkowe pytania prawie nie wydłużają czasu odpowiedzi i kosztują tylko własne tokeny. Pytanie „na wszelki wypadek” kosztuje niemal nic — kod sam określi, które odpowiedzi są potrzebne.
• Złożony osąd po częściach. Zamiast „oceń wniosek startupu” pytaj osobno o wielkość rynku, wykonalność techniczną i różnice względem konkurencji, a wynik oblicz w kodzie z wagami. Zmieniły się priorytety — zmieniasz wagi, zamiast przepisywać pytanie.
• Pytania zależne w drugim żądaniu. Odpowiedzi jednego żądania nie stanowią wzajemnie swojego kontekstu. Drugie żądanie jest potrzebne tylko wtedy, gdy nie można go zbudować bez pierwszej odpowiedzi: trzeba pobrać dane lub wybrać warianty następnego pytania.
• Długie pytanie jako obiekt. instructions i criteria zwykle są ciągami tekstowymi, lecz mogą też być obiektem lub tablicą: pytanie w jednym polu, dane w innych. Ułatwia to porównywanie CV z rekordami bazy za pomocą jednego pytania.

Pewność

W choice i score confidence od 0 do 1 pokazuje, jak bardzo prawdopodobieństwo koncentruje się na jednej odpowiedzi: 1 — całe na jednym wariancie, 0 — równo na wszystkich. W score sąsiedni poziom zmniejsza pewność mniej niż odległy. W noul pewnością jest sama wartość: im dalej od 0,5, tym mocniejsza odpowiedź.

TypeSafe zaleca trzy zakresy:

1. Wysoka pewność — działaj automatycznie.
2. Średnia — działaj ostrożnie, na przykład poproś użytkownika o potwierdzenie.
3. Niska — przekaż przypadek człowiekowi, doprecyzuj żądanie lub połącz ścieżkę zapasową, na przykład silniejszy model z rozumowaniem.

Im droższy błąd, tym bardziej rygorystyczny próg: dla działań nieodwracalnych wyższy niż dla odczytu. Odpowiedź wskazuje, co wybrać, a pewność — czy warto działać. Progi dobieraj na własnych danych, porównując pewność z dokładnością.

Jak budować system wokół Jev

Jev jest przeznaczony do programów, w których kod steruje procesem, a model odpowiada na wąskie pytania znaczeniowe; nie do agentów samodzielnie wybierających następny krok, które w każdej iteracji mogą zboczyć z drogi. Osiem kroków projektowania według TypeSafe:

1. Wszystko, co można wykonać kodem, wykonuj kodem — niezawodnie i tanio.
2. W stanie umieszczaj tylko to, czego wymagają obecne pytania; świeże fakty czerp z własnej bazy wiedzy, a nie pamięci modelu.
3. Struktura w stanie: zagnieżdżony JSON, a w pytaniu — ścieżka do potrzebnego pola w grawisach, jeśli zmniejsza to niejednoznaczność.
4. Najwęższe i najbardziej konkretne pytania — według TypeSafe być może najważniejsza reguła: szerokie pytanie ukrywa kilka osądów za jedną odpowiedzią.
5. Struktura w pytaniach: samo pytanie krótkie; wyjaśnienia, przykłady i wartości z własnej bazy w sąsiednich polach obiektu instructions lub criteria, zamiast jednego długiego ciągu tekstowego.
6. Wiele niezależnych pytań do jednego stanu w jednym żądaniu — więcej korzyści z każdego dolara.
7. Odpowiedzi łączy kod: regułami, sumą ważoną lub jako cechy klasycznego modelu uczenia maszynowego.
8. Rozgałęzianie według pewności: niepewne przypadki do człowieka lub modelu z rozumowaniem.

Jev nie jest czatem ani modelem do automatycznego uzupełniania kodu i nie może zastąpić modelu językowego w agencie programistycznym. Agent może natomiast napisać dla ciebie kod wywołujący Jev tam, gdzie potrzebna jest szybka skalibrowana odpowiedź.

Zastosowania

• Automatyzacja w tle — decyzje wykonywane milion razy bez człowieka obok.
• Czas rzeczywisty — według TypeSafe większość żądań jest wykonywana w około 100 ms: wystarcza to do przetwarzania na bieżąco i interfejsów.
• Duże dane — wyszukiwanie w ogromnych korpusach, oznaczanie logów pracy agentów, cechy do prognoz.
• Sprawdzanie innych modeli — żądania, wyodrębnienia, rozumowania, wywołania narzędzi: omijanie ograniczeń, błędy cytowania, zmyślone informacje.
• Wyszukiwanie i ranking — istotność pary „zapytanie — kandydat”, ponowne szeregowanie, wybór kontekstu.
• Rozgałęzienie według intencji — czego chce użytkownik i który komponent obsługi jest potrzebny: prosta logika, model specjalistyczny lub człowiek; temat, trudność i ryzyko określają, któremu modelowi językowemu przekazać żądanie.
• Kontrole ochronne — wejście, wyjście i wywołania narzędzi modelu językowego: wstrzyknięte instrukcje, naruszenia reguł, wyciek danych osobowych.
• Wsparcie — temat i intencja zgłoszenia, pilność, irytacja, ryzyko odejścia, prośba o zwrot, kolejka.
• Moderacja — według reguł twojej platformy: toksyczność, nękanie, spam, oszustwa, niebezpieczne porady, dane osobowe; według istotności i pewności — przepuścić, ostrzec, sprawdzić lub zablokować.
• Branże — zdarzenia ubezpieczeniowe, dochodzenia finansowe i KYC, umowy i reklama, karty produktów, rekrutacja, leady, gry, ryzyka, prognozowanie popytu, grafy wiedzy, przeglądy naukowe, znaczeniowe sprawdzenia kodu w CI.

Charakterystyka

• jev-latest — alias najnowszej stabilnej wersji, obecnie Jev 1.13; wersja odpowiadająca jest w polu model, na przykład jev-1.13.0. Przy nowej wersji alias przechodzi na nią, a odpowiedzi mogą się zmienić bez zmian po twojej stronie — śledź to pole, jeśli progi dobrano do wersji.
• Kontekst — 64K tokenów na żądanie: stan i wszystkie pytania razem; stan z najdłuższym pytaniem — do 32K. Model czyta stan raz i sprawdza względem niego wszystkie pytania równolegle.
• Wejście — wyłącznie tekst: ciąg tekstowy, obiekt JSON lub tablica tekstów. Obrazy, dźwięk i wideo nie są jeszcze obsługiwane — wcześniej przekształć je w tekst.
• Język — głównym językiem trenowania jest angielski i obecnie dokładność w nim jest najwyższa. Model przyjmuje inne języki, w tym chiński, japoński i koreański, lecz dokładność jest niższa — sprawdź na własnych danych.
• Ceny i rozliczenia w Ailoot API — warunki zależą od wybranej metody i są podane na jej karcie.
• Dostrajanie — Jev nie jest dostrajany na danych klienta: własne materiały w state, reguły dziedziny w instructions i criteria.
• Dane — TypeSafe informuje, że Jev nie jest trenowany na żądaniach i odpowiedziach klientów.

Znane słabe strony Jev 1.13

TypeSafe otwarcie wymienia słabe strony obecnej wersji i obiecuje wiele poprawić w następnych. Model jest szybki, skalibrowany i dobrze ocenia zgodnie ze zdrowym rozsądkiem, lecz:

1. Czyta dosłownie. Odpowiada na napisane pytanie, a nie domyślne: zastrzeżenia, negacje i niejawne warunki rozumie dosłownie. Pisz dokładny warunek i przypadki graniczne w criteria; nieuniknioną interpretację rozdziel na dwa dosłowne pytania.
2. Nie jest kalkulatorem. Liczenie znaków, powtórzeń i elementów listy jest zawodne, a błąd rośnie wraz z rozmiarem — licz w kodzie, z pytaniem na kandydata. Kolory w hex lub RGB model rozumie gorzej od nazw. score nadaje się do progu, lecz nie do dokładnej liczby między poziomami.
3. Daty i czas. Która data jest wcześniejsza, ile jest między nimi, czy data należy do okresu — zawodne, zwłaszcza przy mieszanych formatach i datach względnych. Części daty wyodrębniaj przez choice (z wariantem „nie podano”), a porównuj w kodzie.
4. Pośredniość. Podwójne negacje i pytania o właściwość właściwości zmniejszają dokładność. Pisz wprost i nazywaj części stanu po imieniu.
5. Nadmiar w stanie. Zbędny tekst zmniejsza dokładność. Filtruj w kodzie, a jeśli nie można — odrzucaj nieistotne treści pytaniami noul.
6. Wrogi tekst. Model domyślnie nie spodziewa się podstępów w stanie: wstrzyknięta instrukcja lub tekst podważający własną klasyfikację może przesunąć odpowiedź. Pisz precyzyjne kryteria i sprawdzaj przypadki graniczne przed uruchomieniem.
7. Sprzeczności. Jeśli instructions i criteria żądają czegoś innego — na przykład dla noul „tak” opisano jako „nie” — dokładność spada. Kryteria są kontynuacją pytania.
8. Kolejność wariantów. Model czasem skłania się ku pierwszemu wariantowi choice. Przestaw warianty i sprawdź, czy odpowiedź się nie zmienia.
9. Generowanie. Jev nie był trenowany do pisania tekstu. Przy wyodrębnianiu danych znajdź kandydatów wyrażeniem regularnym lub modelem generatywnym, a Jev niech wybierze poprawnego przez choice.