Zamieniliśmy nasze LLM-y na Jev. Jest o 39% tańszy.
Explore with AI
Budujemy agenta dyżurnego działającego non-stop, który bez przerwy podejmuje decyzje, na przykład:
- jak poważny jest ten problem?
- czy powinniśmy działać proaktywnie w tym wątku na Slacku?
- czy widzieliśmy już ten incydent wcześniej?
Do zeszłego tygodnia używaliśmy do tych zadań LLM-ów. Jak tylko w tym tygodniu dostaliśmy dostęp do Jev, zaczęliśmy z nim eksperymentować.
Czym jest Jev?
Jev to model decyzyjny od TypeSafe AI. Nie generuje tekstu: odpowiada na pytania o twoje dane typowanymi wartościami i skalibrowanymi prawdopodobieństwami. TypeSafe promuje go jako „inteligentne instrukcje if”, czyli kroki klasyfikacji, routingu i oceny, w których ręcznie pisana logika jest zbyt krucha, i podaje czas odpowiedzi od 70 do 500 ms przy darmowych tokenach wyjściowych. Nasi agenci podejmują takie decyzje przez cały dzień, więc wdrożyliśmy go na produkcji.
Jak to działa
Zapytanie składa się z dwóch części: state, czyli tekstu lub JSON-a, w sprawie którego chcesz podjąć decyzję, oraz questions, na które chcesz uzyskać odpowiedź. Każde pytanie ma jeden z trzech typów:
![graph TB
S["State: a message, thread, or evaluation case"] --> J["Jev"]
Q["Questions"] --> J
J --> N["Noul<br/>yes/no"]
J --> C["Choice<br/>pick an option"]
J --> R["Score<br/>rate against a rubric"]
style J fill:#d1fae5,stroke:#6ee7b7,color:#065f46
style N stroke:#3b7dd8,color:#2b5fa8
style C stroke:#3b7dd8,color:#2b5fa8
style R stroke:#3b7dd8,color:#2b5fa8](/diagrams/e0e6684d.svg)
- Noul zwraca prawdopodobieństwo
yes. - Choice wybiera jedną z podanych opcji.
- Score zwraca wartość ważoną prawdopodobieństwem na uporządkowanej skali ocen.
Przypadek użycia 1: routing, czyli kiedy agent powinien odpowiedzieć?
Nasi agenci działają proaktywnie na Slacku i GitHubie. Odpowiadają na wiadomości na Slacku lub komentarze na GitHubie, jeśli mają dla użytkownika istotną obserwację. Agenci muszą działać, gdy prosi o to użytkownik, bez nadmiernego reagowania na każde zdarzenie. To idealny przypadek użycia dla pytań Noul w Jev.
![flowchart LR
E["New event"] --> M["PR comment<br/>Slack message"]
M --> J["Jev Noul<br/>Triage?"]
J -->|Yes| W["Wake agent<br/>to follow up"]
J -->|No| N["No action"]
style J fill:#77a52d,stroke:#5c8023,color:#ffffff
style W stroke:#77a52d,color:#5c8023
style N fill:#e5e5e8,stroke:#d1d2d6,color:#47484d](/diagrams/872d7787.svg)
- Komentarze pod PR-ami zgłoszonymi przez naszych agentów: recenzent proszący o zmianę budzi agenta. Aktualizacja statusu CI albo „dzięki” tego nie robią.
- Kanały na Slacku: agent wtrąca się bez zaproszenia tylko wtedy, gdy może jednoznacznie pomóc, na przykład przy bezpośrednim pytaniu o infrastrukturę. Nie wtrąca się, gdy ludzie ustalają coś między sobą.
- Wątki na Slacku, w których jest agent: odpowiada na wiadomości skierowane do niego, ignoruje ludzi rozmawiających ze sobą i wychodzi, gdy ktoś go o to poprosi.
Oto przykład zapytania do Jev, które ma określić, czy agent powinien odpowiedzieć na wiadomość na Slacku.
{
"model": "jev-1.13.0",
"state": {
"slack_channel": "#Deployment",
"user_message": "Watch this PR until fully deployed"
},
"questions": {
"respond": {
"type": "noul",
"instructions": {
"question": "Should the agent follow up on this user message?"
}
}
}
}Uruchomiliśmy Jev na około tydzień i porównaliśmy go z LLM-em, którego wcześniej używaliśmy do tego zadania.
P90 latency
Cost per 1,000 calls
Routing stał się 3x szybszy przy P90, z 1.5 sekundy do poniżej 500 ms, a koszt spadł prawie o połowę.
Przypadek użycia 2: klasyfikacja, czyli co oznaczają dowody?
Uruchamiamy też kilka zadań, w których agent musi klasyfikować rzeczy do różnych kategorii. Na przykład, na podstawie dostarczonych dowodów, czy agent powinien zacząć badać problem, czy powinien uznać go za powiązany z istniejącym problemem, czy jest to duplikat wcześniej rozwiązanego problemu?
Pytanie Choice w Jev zamienia te dowody w jedną etykietę na podstawie zdefiniowanych przez nas kryteriów, a kolejny krok zależy od tej etykiety. Wygląda to tak:
![flowchart LR
I["New incident"] --> E["Evidence from tool calls"]
E --> J["Jev Choice"]
J -->|Same root cause| D["Defer to the original"]
J -->|Related| L["Link both incidents"]
J -->|Independent| N["Investigate on its own"]
style J fill:#77a52d,stroke:#5c8023,color:#ffffff
style D stroke:#77a52d,color:#5c8023
style L stroke:#77a52d,color:#5c8023
style N fill:#e5e5e8,stroke:#d1d2d6,color:#47484d](/diagrams/ff499dad.svg)
W ten sposób prowadzimy trzy klasyfikacje. Każda z nich korzysta z pytania Choice z jasno określonymi kryteriami i każda zastąpiła inny LLM, więc zmierzyliśmy je osobno.
Czy te incydenty są powiązane?
Gdy otwiera się nowy incydent, agent porównuje go z istniejącymi incydentami: czy mają wspólną przyczynę źródłową, czy są powiązane, czy są niezależne? Ten poglądowy przykład pokazuje jednego kandydata; w produkcyjnym wywołaniu porównuje się kilku kandydatów z tym samym nowym incydentem.
{
"model": "jev-1.13.0",
"state": {
"incident": "Checkout cannot authenticate to the database.",
"candidate_0": "Billing cannot authenticate to the same database.",
"evidence": "Both services use a credential revoked at 14:00."
},
"questions": {
"candidate_0": {
"type": "choice",
"instructions": "How is candidate_0 connected to the new incident?",
"criteria": {
"duplicate_same_root_cause": "One underlying problem explains both",
"related": "Distinct problems share a trigger or blast radius",
"independent": "No evidenced connection"
}
}
}
}Po przejściu na Jev w tym przypadku użycia jest on prawie 8x szybszy przy P90, z 2.9 sekundy do poniżej 400 ms, i o 27% tańszy.
P90 latency
Cost per 1,000 calls
Dlaczego ten zgłoszony przez nas PR został zamknięty?
Nasi agenci zgłaszają pull requesty deweloperom, a jednym z naszych kluczowych wskaźników sukcesu jest wskaźnik scaleń. Musimy rozumieć, dlaczego pull requesty są zamykane, żeby móc ulepszać produkt.
Gdy jeden z naszych PR-ów zostaje zamknięty bez scalenia, agent czyta przeglądy, dyskusję i odniesienia do innych prac, a następnie wybiera powód: poprawka była błędna, człowiek naprawił to w inny sposób, problem był fałszywym alarmem, PR się zdezaktualizował albo zachowanie było zamierzone.
Po przejściu na Jev w tym przypadku użycia opóźnienie poprawiło się 6x przy P90, ale koszt spadł tylko o 17%.
P90 latency
Cost per 1,000 calls
Jak pilny jest ten pull request?
Zanim agenci zgłoszą pull request deweloperom, muszą go ocenić rangą, tak aby sprawy o wyższej krytyczności trafiały na górę. W tej klasyfikacji agent ocenia leżący u podstaw problem na skali od krytycznego do informacyjnego. Ocenia bieżący wpływ, a nie hipotetyczne ryzyko.
P90 latency
Cost per 1,000 calls
Przejście na Jev znacznie obniżyło tu koszt: o 59% taniej niż DeepSeek V4.1 Flash i prawie 5x szybciej przy P90.
Jev jest szybszy przy każdej klasyfikacji. Tam, gdzie zastąpił GPT-OSS 120B, zysk dotyczy głównie opóźnienia. Tam, gdzie zastąpił DeepSeek V4.1 Flash, obniżył też rachunek o ponad połowę.
Przypadek użycia 3: ranking, czyli jak ważny jest ten zasób chmurowy?
Aby jak najlepiej wykorzystać Polylane, zespoły łączą swoje konta chmurowe. Tworzymy graf kontekstu wszystkich zasobów chmurowych, tak aby agenci mogli szybko zrozumieć relacje między węzłami obliczeniowymi, bazami danych, kolejkami itd.
Na platformie mamy zespoły z niezwykle obciążonymi kontami chmurowymi, liczącymi dziesiątki tysięcy węzłów. Każdy serwer, sandbox, baza danych i kolejka to węzeł w naszym grafie kontekstu. Trzeba ocenić rangą każdy z tych węzłów, tak aby agenci wiedzieli, co jest krytyczne dla twojej aplikacji, a co w zasadzie może bezpiecznie zawieść.
Każdemu zasobowi przypisujemy jeden z czterech poziomów priorytetu: Krytyczny, Standardowy, Niski lub Minimalny.
![flowchart LR
C["Cloud account"] --> G["Context graph"]
G -->|Each node + metrics| J["Jev Choice"]
J --> T1["Critical"]
J --> T2["Standard"]
J --> T3["Low"]
J --> T4["Minimal: fine to fail"]
style J fill:#77a52d,stroke:#5c8023,color:#ffffff
style T1 stroke:#77a52d,color:#5c8023
style T2 stroke:#77a52d,color:#5c8023
style T3 stroke:#77a52d,color:#5c8023
style T4 fill:#e5e5e8,stroke:#d1d2d6,color:#47484d](/diagrams/9bbd794f.svg)
Jev ocenia pytanie Choice dla każdego zasobu, korzystając z kontekstu opartego na konfiguracji, środowisku, ostatnich metrykach i zależnościach.
{
"model": "jev-1.13.0",
"state": {
"instructions": "Assign importance relative to the other resources in this cohort.",
"cohort": [
{
"id": "database-a",
"environment": "production",
"daily_queries": 80000,
"dependents": 6
},
{
"id": "database-b",
"environment": "preview",
"daily_queries": 0,
"dependents": 0
}
]
},
"questions": {
"resource_0": {
"type": "choice",
"instructions": "Assign the importance tier for database-a.",
"criteria": {
"1": "Critical: substantial production traffic or blast radius",
"2": "Standard: active and operationally relevant",
"3": "Low: limited activity or importance",
"4": "Minimal: idle or disposable, without meaningful dependents"
}
}
}
}To właśnie w rankingu Jev błyszczy: ponad 10x szybciej przy P90, z 5.4 sekundy do około pół sekundy, i o 34% taniej. To też nasza decyzja o najwyższym wolumenie, więc odpowiada za większość ogólnych oszczędności.
P90 latency
Cost per 1,000 calls
Podsumowanie
Ogólnie Jev przyniósł znaczące obniżenie opóźnienia i szacowanego kosztu na 1000 wywołań:
- Obniżenie opóźnienia P90: 4,752 ms —> 508 ms.
- Obniżenie kosztu na 1000 wywołań: $0.76199 —> $0.46369.
P90 latency
ms · lower is betterCost per 1,000 calls
USD · lower is betterW ujęciu na model Jev jest zarówno najszybszy, jak i najtańszy: nieco tańszy niż DeepSeek V4.1 Flash i wyraźnie poniżej obu modeli GPT-OSS.
Swipe to see every point.
Wszędzie tam, gdzie nasi agenci wybierają z ustalonego zestawu odpowiedzi, Jev jest teraz domyślny: jest szybszy i tańszy przy każdej decyzji, którą przenieśliśmy.