Kupac menja adresu na porudžbini. U poruci takođe traži povraćaj novca, pominje oštećen paket i nagoveštava da je ovo treći put da je nešto pošlo naopako. Pretvaranje te poruke u koristan odgovor jedan je zadatak. Odluka o tome koje evidencije treba ažurirati, koji tim treba da interveniše i za koje radnje je potrebno odobrenje predstavlja drugi zadatak.
Jev, model koji je TypeSafe AI predstavio u ranom pristupu 15. septembra 2026, namenjen je upravo takvim odlukama. On proizvodi ograničene, strukturisane odgovore za softver. Njegovo predstavljanje poziv je da preispitamo koliko delova aplikacije treba da zavisi od dugog razgovora sa modelom opšte namene. Saopštenje TypeSafe-a o predstavljanju
Argument je najpotpunije iznet u intervjuu sa suosnivačem i direktorom TypeSafe-a Diogom Almeidom, koji je Swyx vodio za Latent Space 21. septembra. Pregledali smo potpune engleske titlove razgovora dugog dva sata i 22 minuta i proverili dokumentaciju proizvoda. Ovo je analiza intervjua i javnih dokaza; Jev nismo nezavisno testirali. Pogledajte originalni intervju
Po našem tumačenju, najvažniji predlog Jeva tiče se jedinice automatizacije. Preduzeće možda može da automatizuje ograničeno prosuđivanje unutar postojećeg postupka pre nego što može odgovorno da prepusti čitav postupak. Ako odluka postane dovoljno jeftina za ponavljanje i dovoljno jasna za merenje, uobičajeni poslovni softver mogao bi da dobije korisne mogućnosti, a da svaka interakcija ne postane četovanje.
To bi uticalo i na ljude koji osmišljavaju tokove rada i na one koji ih koriste. Neko i dalje mora da odluči koje su radnje dozvoljene, šta se računa kao greška i ko rešava izuzetke. Kvalitet tih odluka odrediće da li ovaj pristup stvara pouzdane usluge ili samo ubrzava greške.
Šta je TypeSafe zaista predstavio
Dokumentovani interfejs Jeva prima stanje i skup tipiziranih pitanja. Tri osnovne funkcije su Choice, koja bira između navedenih opcija; Score, koja procenjuje prema rubrici; i Noul, koja izražava verovatnoću neke tvrdnje na skali od nula do jedan. Choice i Score vraćaju raspodele i polje za pouzdanost. Noul nema to zasebno polje za pouzdanost. Pitanja mogu da dele dostavljeno stanje, a da se procenjuju nezavisno. Dokumentacija interfejsa TypeSafe-a
U aplikaciji za korisničku podršku programer bi mogao da koristi te funkcije da razlikuje zahtev za promenu adrese od otkazivanja, proceni hitnost i proveri da li poruka sadrži dokaze o oštećenju. To su hipotetički primeri, a ne rezultati primene Jeva. Aplikacija bi zatim odlučila šta da uradi sa odgovorima.
Ta podela je korisna zato što su tumačenje i ovlašćenje različite odgovornosti. AI može zaključiti da kupac želi povraćaj novca. Samim tim zaključkom ne treba da stekne dozvolu da ga odobri. Aplikacija može da proveri porudžbinu, primeni ograničenje povraćaja i zatraži odobrenje kada je to primereno.
TypeSafe ovu kategoriju modela naziva System One, pozajmljujući izraz za brzo, intuitivno mišljenje. Naziv treba shvatiti kao opis predviđenog posla. Ne potvrđuje ljudsku spoznaju niti uspostavlja jasnu granicu između lakih i teških zadataka. Kratko pitanje može da prikriva složeno prosuđivanje, naročito kada nedostaju potrebne informacije.
Inženjerska promena: manje odluke koje mogu da se provere
Almeida zagovara razlaganje: postavljati usko određena pitanja, a zatim objediniti odgovore u kodu. Intervju, 1:03:02
Vratimo se primeru porudžbine sa oštećenjem. Jedno uputstvo da se reši pritužba sakriva više odluka unutar jednog odgovora. Dizajn koji se lakše proverava odvojeno bi utvrdio koju radnju kupac traži, da li se porudžbina može identifikovati i da li dostupni dokazi potkrepljuju tvrdnju o oštećenju. Pravila bi ostala izvan tih procena.
Zbog toga je lakše ispitati grešku. Ako sistem prosledi zahtev za promenu adrese timu za povraćaj robe, operater može da pregleda odluku o prosleđivanju. Ako je procena oštećenja pogrešna, tu komponentu je moguće testirati na ranijim slučajevima. Promena pravila može izmeniti izričito pravilo, a da tim ne mora da prepravlja široko uputstvo i nada se da će ga model dosledno tumačiti.
To ima svoju cenu. Više komponenti znači više interfejsa za održavanje. Pitanja mogu slučajno izostaviti kontekst koji bi razjasnio odgovor. Dve naizgled nezavisne procene mogu zavisiti od istih obmanjujućih dokaza. Tok rada sastavljen od pojedinačnih delova koji su svaki zasebno prihvatljivi i dalje može dati neprihvatljiv rezultat.
Dokumentovani obrasci TypeSafe-a obuhvataju istovremeno postavljanje više pitanja, kombinovanje rezultata i prosleđivanje neizvesnih slučajeva na dodatnu obradu. Oni opisuju arhitektonske mogućnosti, a ne dokazuju da je određeni postupak kod kupca spreman za rad bez nadzora. Obrasci TypeSafe-a
Koristan test je da li razlaganje poboljšava i dijagnostiku i rezultate. Mogućnost da se objasni koji korak je zakazao ima vrednost. Poslovni argument čine smanjenje učestalosti i posledica tih grešaka.
Odgovor može biti ispravan po formatu, a ipak pogrešan
Tvrdnju iz predstavljanja da Jev „ne može da halucinira“ treba usko tumačiti. TypeSafe svoju garanciju vezuje za pridržavanje dozvoljene šeme izlaza. To ne dokazuje tačnost izabranog odgovora. I samo saopštenje razlikuje garancije šeme od empirijske procene. Objašnjenje tipne bezbednosti kompanije TypeSafe
Recimo da aplikacija dozvoljava vrednosti damaged, late i other. Vraćanje damaged je potpuno ispravno čak i ako je paket samo kasnio. Model koji ne može da izmisli četvrtu kategoriju i dalje može da izabere pogrešnu. Ako lista izostavlja zaista neophodnu kategoriju, sama šema postaje deo problema.
Strukturisani izlaz je i postojeći inženjerski pristup. OpenAI je u avgustu 2024. predstavio izlaze ograničene šemom, Structured Outputs, i izričito napomenuo da model i dalje može pogrešiti u okviru vraćenih vrednosti. Zato Jev treba proceniti prema njegovoj konkretnoj kombinaciji kvaliteta odluka, prikaza neizvesnosti, odziva i cene, a ne pripisivati mu izum celokupnog strukturisanog izlaza AI-ja. Izvorno saopštenje i ograničenja OpenAI-ja
Za kupce ova razlika menja plan procene. Provera šeme pita može li softver da obradi odgovor. Provera činjenica pita da li je odgovor u skladu sa dokazima. Provera pravila pita da li je radnja koja iz toga sledi dozvoljena. Uspeh na jednoj proveri ne zamenjuje uspeh na ostalima.
Najvažniji izazov iz intervjua odnosi se na kalibraciju
U 1:09 Almeida odbacuje sugestiju da je kalibracija savršena i priznaje greške modela. Intervju, 1:08:50
Kalibracija se odnosi na poređenje predviđenih verovatnoća sa zabeleženim ishodima u grupama predviđanja. Model može korisno ukazivati na neizvesnost, a da ne bude tačan u svakom slučaju sa visokom procenjenom verovatnoćom. U uvodnom tekstu TypeSafe-a ova razlika je izričito sačuvana. Objašnjenje kalibracije kompanije TypeSafe
Polje pouzdanosti u API-ju zahteva još jedno razgraničenje. TypeSafe ga opisuje kao statistiku izvedenu iz raspodele odgovora. Ono nije isto što i nezavisno izmerena verovatnoća da je izabrani odgovor tačan. Dokumentacija preporučuje izbor pragova prema zadatku i njegovim posledicama. Dokumentacija TypeSafe-a o pouzdanosti
Ovo su praktična pitanja. Zamislimo da model za usmeravanje dobro radi na kratkim porukama na engleskom, ali ima problema sa dugim pritužbama koje sadrže više zahteva. Jedan zbirni rezultat može prikriti tu slabost. Odluka visoke pouzdanosti iz slabije grupe možda zaslužuje više provere nego isti prikazani broj iz poznate grupe.
Tim zato treba da proceni slučajeve koje očekuje, uključujući nedostajuće informacije, neuobičajene formulacije i namerno zbunjujuće unose. Treba da pregleda greške po kategorijama i uporedi cenu prosleđivanja slučaja na proveru sa cenom pogrešnog postupanja. Pragovi postaju operativne odluke zasnovane na dokazima, a ne brojevi prepisani iz demonstracije.
Istraživanje kalibracije prethodilo je Jevu mnogo godina. Uticajan rad Čuana Guoa i saradnika iz 2017. ispitivao je lošu kalibraciju savremenih neuronskih mreža i metode za njeno poboljšanje. Taj rad pruža kontekst za problem; ne potvrđuje valjanost modela TypeSafe-a. Kalibracija savremenih neuronskih mreža
Pouzdanost obuhvata i ono što se dešava kada se usluga promeni
U razgovoru se razlikuju robusnost i determinizam, a razmatra se stabilnost verzija bez opšteg obećanja dugoročne podrške. Intervju, 41:24 i 49:40
To su zasebna pitanja pri kupovini. Determinizam pita da li isti ulazi daju iste izlaze. Robusnost pita da li nebitna izmena, poput drugog identifikatora zapisa, izaziva nerazumnu promenu ponašanja. Model bi mogao neprekidno da ponavlja isti pogrešan odgovor i pritom bude deterministički. Mogao bi i malo da varira, dok okolni tok rada ostaje pouzdan.
Nijedno svojstvo ne rešava rizike životnog ciklusa. Preduzeće mora znati koja revizija modela je proizvela odluku, da li će ta revizija ostati dostupna i kako će se procenjivati njena zamena. Poboljšanje rezultata na testovima dobavljača ipak može promeniti ponašanje pažljivo podešenog toka rada kod kupca.
Razumno je sačuvati reprezentativne slučajeve, beležiti verzije i uporediti zamene pre prebacivanja važnih poslova. Važno je imati i rezervni postupak: usluga za odlučivanje koja je inače tačna može postati nedostupna. Ako aplikacija nema bezbedan način da pauzira rad ili ga usmeri drugde, dostupnost u praksi postaje deo kvaliteta odluka.
Tu se privlačan API pretvara u operativnu zavisnost. Nabavka, nadzor i planiranje prelaska ne nestaju kada model postane brži. Lakše ih je zanemariti jer pojedinačni poziv deluje tako jednostavno.
Zašto brojeve brzine i cene treba tumačiti u kontekstu
Među istaknutim rezultatima tokova rada kompanije TypeSafe navode se 193,6 puta veća brzina i 444,6 puta niža cena. Saopštenje navodi da je reč o najvećim poboljšanjima u tokovima rada koje je osmislila kompanija. Referentni odgovori dobijeni su iz procena verovatnoće drugih modela, a ne iz nezavisno proverenih stvarnih klasifikacija. Kompanija takođe upozorava da kratka demonstracija ide u prilog Jevu i da održive dugoročne cene tek treba utvrditi. Ograničenja procene kompanije TypeSafe
Te napomene treba da idu uz navedene brojke. Slaganje sa referentnim modelom može biti informativno, ali meri nešto drugo od tačnosti u odnosu na razrešeni slučaj kupca. Tok rada koji je osmislio dobavljač može biti važan kupcu, a da ne predstavlja raspodelu zahteva kod tog kupca.
Ispravno poređenje obuhvata ceo posao: prikupljanje konteksta, donošenje odluka, primenu pravila, rešavanje izuzetaka i oporavak od greške. Jeftiniji poziv modelu može ići uz veći ukupan trošak ako previše posla prosledi ljudima na proveru. Sporiji poziv može biti ekonomičan ako izbegne skupu doradu.
Latenciju takođe treba meriti iz stvarnog regiona aplikacije. Demonstracija u blizini infrastrukture usluge ne garantuje isto iskustvo korisniku na drugom mestu. Interaktivni sistemi treba da prate spore zahteve, a ne samo prosek; za pozadinsku obradu mogu biti važniji protok i ukupan trošak.
Naziv Jev priziva ideju da veća efikasnost može proširiti potrošnju. Za pojedinačno preduzeće to otvara pitanje planiranja budžeta: koje nove odluke sada vredi procenjivati, a koje su samo dovoljno jeftine da bi se nepotrebno procenjivale? Veći broj poziva modelu sam po sebi nije rezultat.
Drugačiji istraživački cilj, uz dokaze koji još nisu potpuni
Almeidino istraživačko obrazloženje povezuje podatke, izbor zadataka i RLCD sa njegovom kritikom optimizacije ljudskih preferencija. Intervju, 7:23 i 22:12
RLCD je skraćenica za učenje potkrepljivanjem za kalibrisane odluke. TypeSafe ga predstavlja kao obuku usmerenu na upotrebljive odluke i verovatnoće, nasuprot pristupima zasnovanim na ljudskim preferencijama i proverljivim nagradama. To je opis cilja kompanije. Ne treba ga mešati sa nezavisnom proverom celokupne metode obuke. Uvodni tekst o AI-ju kompanije TypeSafe
Vredi istražiti šire pitanje i dok se metoda procenjuje: kakvo ponašanje nagrađuje cilj obuke? Model optimizovan za uverljivo objašnjenje može biti prijatan za korišćenje, a da ne prikaže neizvesnost u obliku na koji kod može da reaguje. Interfejs usmeren na odluke može olakšati obradu neizvesnosti, ali njegove izlaze i dalje treba spolja proveravati prema stvarnosti.
TypeSafe povezuje ovu zabrinutost sa sužavanjem raspodele: optimizacija prema preferencijama može suziti skup verovatnih izlaza ka odgovorima koje ljudi nagrađuju. To je objašnjenje jednog mogućeg načina otkaza, a ne nalaz da je svaki model obučen prema preferencijama neupotrebljiv za odlučivanje. Rasprava kompanije TypeSafe o optimizaciji preferencija
Almeidina stručna biografija čini argument posebno zanimljivim. On je koautor rada InstructGPT, koji je proučavao obuku jezičkih modela za praćenje uputstava uz povratne informacije ljudi. To koautorstvo se može proveriti; široke tvrdnje o greškama svih laboratorija sasvim su druga stvar. Rad InstructGPT
Njegovi prigovori trošenju na predobuku i osnivanju novih laboratorija bez jasnog pravca deo su istog argumenta o izboru korisnih zadataka. Intervju, 1:49:32 i 2:03:10
Za kupca je važna pouka da pita šta proizvod može da uradi za konkretan postupak. Istraživačko iskustvo, računarska potrošnja i posebna arhitektura modela mogu da objasne kako je kompanija došla do proizvoda. Ne mogu da utvrde ekonomsku opravdanost njegove primene u tuđem preduzeću.
U intervjuu se govori i o Almeidinom odlasku iz OpenAI-ja, teškom ranom usvajanju i rastu koji predvode programeri. Intervju, 1:31:27 i 1:56:48
Ta sećanja objašnjavaju prioritete kompanije. Ona nisu nezavisno provereni podaci o usvajanju proizvoda. Platformu za programere na kraju treba procenjivati prema održivom korisnom radu i podršci kada taj rad zakaže. Početno oduševljenje razlog je za ispitivanje, a ne zamena za takve podatke.
Postojeći softver može dobiti više od novog prozora za čet
Almeida predviđa bolje SaaS proizvode i povlačenje AI-ja u pozadinu. Intervju, 1:19:57
To je uverljiv pravac za ispitivanje jer softver već sadrži mesta na kojima korisna odluka može da promeni sledeći korak. Aplikacija za zakazivanje mogla bi da prepozna nejasan zahtev pre rezervacije. Medijska arhiva mogla bi istraživaču da organizuje građu. Služba za podršku mogla bi da razlikuje rutinsko ažuriranje od pritužbe kojoj treba posvetiti pažnju. To su mogući dizajni, a ne prijavljene primene Jeva.
Interfejs bi se jedva promenio. Korisnici bi primetili manje grešaka, manje ponavljanih klasifikacija ili kraće čekanje na odgovarajuću osobu. Komercijalnu prednost mogle bi steći kompanije koje već poznaju postupak i umeju da u njega uključe bolje odlučivanje.
Postojeće softverske kompanije i dalje bi se suočavale sa konkurencijom. Ako ista procena postane dostupna mnogim programerima, sam poziv modelu pruža malu razliku. Okolni proizvod mora da obezbedi korisne podatke, promišljen dizajn interakcije i pouzdan način dovršavanja posla.
Tvrdnje o zapošljavanju zahtevaju veću uzdržanost. Manji napor za jedan zadatak mogao bi da promeni broj zaposlenih, poveća obim usluge ili prebaci rad na izuzetke. Ishodi zavise od organizacije i potražnje za njenom uslugom. Ni intervju ni rano predstavljanje ne dokazuju da će radna mesta biti sačuvana, ukinuta ili otvorena u određenom broju.
Za industrijski pregled BIG CHANGE-a merljiv događaj je dostupnost još jednog pristupa automatizaciji odluka. Široko usvajanje, rast produktivnosti i posledice po tržište rada kasnija su pitanja za koja su potrebni drugi dokazi.
Tamni podaci, softver u stvarnom vremenu i ograničenja demonstracije
Intervju obrađuje sačuvane podatke, interaktivne aplikacije, proveru i demonstracije korišćenja računara. Intervju, 1:34:50
Svaka kategorija traži drugačiju procenu. Zadatak obrade arhive može podneti kašnjenje, ali zahteva plan uzorkovanja rezultata i njihovog povezivanja sa izvornim evidencijama. Interfejsu u stvarnom vremenu potreban je predvidljiv odziv. Proveru koja ocenjuje drugi model treba testirati na greškama koje taj model zaista pravi, uključujući slučajeve u kojima oba sistema greše na isti način.
Kod korišćenja računara, izbor radnje je samo jedan deo sistema. Potrebni su mu i tačan prikaz interfejsa, način izvršavanja radnje i provera da je očekivana promena zaista nastala. Upečatljiva demonstracija može da pokaže da se niz radnji jednom dogodio; pouzdana automatizacija zahteva ponovljene probe i oporavak od prekida.
Isti oprez važi za igre. Lik kojim upravlja model mogao bi da reaguje na bogatije stanje igre, dok mehanizam igre i dalje određuje koje su radnje moguće. Da li to poboljšava igru zavisi od odziva, doslednosti i dizajna iskustva. Dodavanje zaključivanja u svaki kadar ne bi automatski učinilo igru zanimljivijom.
Ove razlike sprečavaju grešku u kategorisanju: korisnoj komponenti treba pripisati njenu ulogu, bez pripisivanja svih mogućnosti šire aplikacije u koju je ugrađena.
Mogućnosti finog podešavanja, vida i dodatnih oblika modela pominju se kao buduće opcije u intervjuu. Intervju, 1:10:27 i 1:26:23
Razgovor o planovima ne treba pretvoriti u preduslov za plan pokretanja proizvoda. Gradite na dostupnom interfejsu, utvrdite šta mora da obezbedi posebna komponenta i procenite svaku novu mogućnost tek kada zaista stigne. Tako ostaje prostor za buduća poboljšanja, bez predstavljanja nagađanja kao funkcije proizvoda.
Agenti za programiranje mogli bi drugačije da podele posao
Almeida predlaže jeftiniju obradu stanja i zajednički kontekst za agente za programiranje, umesto petlje sa jednim modelom. Intervju, 1:40:17 i 2:09:29
Jedna moguća arhitektura koristila bi sposoban model za programiranje da razvije izmenu, manje pozive za odlučivanje da klasifikuje relevantne datoteke, a uobičajeni softver da upravlja narednim zadacima. Poseban proveravač mogao bi da pregleda završnu zakrpu. Ovo je predlog dizajna, a ne preporuka potvrđena testovima niti dokaz da Jev već zamenjuje postojećeg agenta za programiranje.
Privlačna strana je selektivni kontekst. Ako je podzadatku potreban samo jedan interfejs i nekoliko ograničenja, možda je rasipno slati mu čitav razgovor. Izričite evidencije zadataka mogle bi da olakšaju utvrđivanje važnih činjenica, već donetih odluka i preostalih izmena.
Opasnost je u mešanju predloga za koordinaciju sa garancijom paralelnog rada. Dva agenta mogu istovremeno zaključiti da treba da menjaju istu datoteku. Verovatnosni model ne treba da zameni softverske mehanizme koji sprečavaju sukobljene izmene. Ovlašćenja, provere verzija i zaključavanja i dalje moraju da obezbede željeni ishod.
Isto tako, jeftinije pronalaženje ranijeg rada moglo bi da poboljša upravljanje memorijom, a da ne reši svaki problem koji se naziva kontinuiranim učenjem. Sećanje na raniji pokušaj, razumevanje razloga neuspeha i pouzdano prilagođavanje novoj situaciji različite su sposobnosti. Uverljiva procena ispitala bi završene zadatke, regresije, sukobe i ljudske intervencije, a ne samo broj agenata ili poziva.
Bezbednost se prenosi kroz sistem; ne nestaje
Almeida daje prednost bezbednosnim kontrolama u aplikaciji umesto odbijanjima modela; Swyx osporava posledice. Intervju, 13:11 i 1:42:29
Ovde postoji stvaran problem dizajna: aplikacija bez nadzora mora da se nosi sa situacijama kada zavisna usluga odbije zahtev, zakaže ili vrati neizvestan rezultat. Potreban joj je jasan postupak za takve slučajeve. To zapažanje samo po sebi ne utvrđuje gde treba da bude svaka zaštitna mera.
Aplikacija treba da primenjuje dozvole pristupa čak i kada model tačno prepozna nameravanu radnju. Zahtev za brisanje evidencije može biti savršeno shvaćen, a ipak neovlašćen. Zahtev može biti tehnički ispravan, a istovremeno kršiti pravila operatera. Služba za odlučivanje ne može odgovorno da odgovori na ta pitanja bez odgovarajućeg konteksta, a aplikacija mora zadržati kontrolu nad radnjom.
Zato premeštanje sve većeg broja odluka u softver još više naglašava važnost preciznog definisanja granica pre puštanja u rad. Timovi moraju odlučiti koji su dokazi potrebni, koje operacije moraju ostati povratne i kako čovek može osporiti ili ispraviti ishod. Uklanjanje nezgodne interakcije sa modelom nije dovoljan dokaz da je ceo sistem bezbedan.
Šta bi dokazalo veliku promenu
Predstavljanje omogućava jasan ogled. Izaberite ograničen postupak sa merljivim ishodom. Zabeležite kako se danas obavlja, uključujući greške i vreme koje ljudi utroše na njihovu ispravku. Testirajte verziju zasnovanu na odlučivanju na reprezentativnim slučajevima pre nego što joj date ovlašćenje za delovanje.
Izmerite udeo slučajeva završenih tačno bez intervencije, greške koje promaknu proveri, obim posla prosleđen ljudima i ukupan trošak po završenom slučaju. Sačuvajte izvorne dokaze kako bi proveravač mogao da ispita zašto je rezultat prihvaćen. Ponovite poređenje kada se promene model, pravila ili populacija ulaznih podataka.
Ova procena može pokazati da je samo deo postupka spreman. To je koristan rezultat. Automatizacija rutinske klasifikacije uz zadržavanje nejasnih slučajeva kod iskusnog operatera može biti isplativa, a da ne opravdava širu autonomiju.
Jevovo predstavljanje i Almeidin intervju iznose ambicioznu hipotezu o tome kako AI ulazi u privredu: ponovljene, ograničene odluke mogu poboljšati softver od kojeg ljudi već zavise. Sledeći dokazi treba da dođu iz sistema koji taj posao obavljaju tokom vremena, uz uračunate greške i izuzetke. Tako zanimljiva arhitektura modela postaje promena koju čitaoci zaista mogu da uoče.
