Jev vs Agents: सॉफ्टवेयर में डिसीजन प्रिमिटिव्स का एकीकरण

पिछले हफ्ते से पत्थर के नीचे नहीं रह रहे हो, तो आपने @typesafeai के Jev को देखा ही होगा।

https://x.com/CompleteSkeptic/status/2099925682726002904

वे अपने मॉडल्स का वर्णन इस प्रकार करते हैं:

AI मॉडल्स की एक श्रेणी जो तेज़ और संरचित निर्णय लेने के लिए बनाई गई है, जिन्हें सॉफ्टवेयर सीधे उपयोग कर सकता है। एक System One मॉडल एक
state का मूल्यांकन करता है और टाइप्ड उत्तर तथा प्रायिकताएँ (probabilities) लौटाता है।

TypeSafe के बेंचमार्क्स के अनुसार, Jev LLMs की तुलना में 20-200 गुना तेज़ और 40-400 गुना सस्ता है।

लेकिन यह मायने क्यों रखता है? हमने पहले भी क्लासिफायर्स को प्रशिक्षित किया है (आपके फोन में ऑटोकरेक्ट, जीमेल फिल्टरिंग, आदि), लेकिन ट्विटर के मुताबिक Jev कुछ खास है।

इस लेख में, मेरा उद्देश्य आपको सिखाना है कि Jev क्या है, यह क्यों मौजूद है, और आप इसे अपने प्रोडक्शन सिस्टम्स में कैसे शामिल कर सकते हैं।

तो वास्तव में Jev क्या है?

"Jev को एक frontier-intelligence function call के रूप में सोचें: अनसंरचित state इनपुट में, और टाइप्ड प्रायिकतात्मक निर्णय आउटपुट में।" - TypeSafe

Jev 3 primitives प्रदान करता है: Choice, Score, और Noul.

Choice एक प्रश्न प्रकार है जो एक परिभाषित सेट (अधिकतम 255 विकल्पों वाला) में से एक विकल्प चुनता है, जिसका उत्तर चयनित विकल्प, प्रत्येक विकल्प के लिए प्रायिकता और विश्वास स्तर (confidence) शामिल करता है।
Score सामग्री को क्रमबद्ध, वर्णनात्मक स्तरों के विरुद्ध रेट करता है, जिसका उत्तर एक स्कोर, प्रत्येक स्तर के लिए प्रायिकता और विश्वास स्तर शामिल करता है।
Noul मॉडल से हाँ/नहीं प्रश्न का मूल्यांकन करने और 'हाँ' उत्तर होने की प्रायिकता लौटाने का अनुरोध करता है।

यहाँ एक ग्राहक-सहायता (customer-support) उपयोग के मामले के लिए नमूना इनपुट और आउटपुट दिया गया है:

json

1// Input
2{
3  "model": "jev-latest",
4  "state": "Hi, I was charged twice for my monthly subscription. Could you refund the extra charge? My account is working fine.",
5  "questions": {
6    "department": {
7      "type": "choice",
8      "instructions": "Which team should handle this message?",
9      "criteria": {
10        "billing": "Charges, payments, subscriptions, and refunds",
11        "technical": "Bugs, errors, and broken features",
12        "account": "Login, passwords, and account access"
13      }
14    },
15    "requests_refund": {
16      "type": "noul",
17      "instructions": "Is the customer explicitly requesting a refund?"
18    },
19    "frustration": {
20      "type": "score",
21      "instructions": "How frustrated does the customer sound?",
22      "criteria": [
23        "Calm: politely describes the issue without expressing frustration",
24        "Frustrated: expresses annoyance or dissatisfaction",
25        "Very frustrated: expresses strong anger or threatens to leave"
26      ]
27    }
28  }
29}
30// Output
31{
32  "model": "jev-1.13.0",
33  "answers": {
34    "department": {
35      "type": "choice",
36      "choice": "billing",
37      "confidence": 1,
38      "probabilities": {
39        "technical": 0,
40        "account": 0,
41        "billing": 1
42      }
43    },
44    "requests_refund": {
45      "type": "noul",
46      "noul": 0.99
47    },
48    "frustration": {
49      "type": "score",
50      "score": 0,
51      "legend": {
52        "0": "Calm: politely describes the issue without expressing frustration",
53        "1": "Frustrated: expresses annoyance or dissatisfaction",
54        "2": "Very frustrated: expresses strong anger or threatens to leave"
55      },
56      "confidence": 1,
57      "probabilities": {
58        "0": 1,
59        "1": 0,
60        "2": 0
61      }
62    }
63  },
64  "usage": {
65    "input_tokens": 442,
66    "output_tokens": 72
67  },
68  "request_id": "playground_12bbfa4198be5ca4de9818a45c0906a2055",
69  "evaluation_time_ms": 163.01120699790772
70}

आउटपुट के लिए state और questions कैसे मिलकर काम करते हैं, इसके बेहतर समझ के लिए मैं उनके dashboard onboarding पर जाने की सलाह दूंगा।

क्या यह सिर्फ एक classifier नहीं है?

खैर, हाँ और नहीं दोनों। यह ऐसा है जैसे एक LLM और एक classifier का बच्चा हो।

पारंपरिक classifiers उच्च मात्रा वाले, निश्चित taxonomy कार्यों के लिए अच्छे होते हैं। सोचिए LeNet-5 के बारे में जो पहचान सकता है कि एक छवि किस अंक का प्रतिनिधित्व करती है। हालाँकि, classifiers आमतौर पर अत्यंत विशेषीकृत और डोमेन-विशिष्ट होते हैं। LLMs अनुक्रम (sequences) उत्पन्न करने में अच्छे होते हैं। वे लचीले होते हैं और रनटाइम पर परिभाषित खुले-सिर वाले (open-ended) कार्यों के लिए महान होते हैं, लेकिन वे धीमे भी होते हैं (classifier की तुलना में), अधिक महंगे होते हैं, और कम पूर्वानुमानित (predictable) होते हैं।

Jev एक "foundation model for classification" है, जो LLM की natural-language लचीलापन को classifier के संकुचित, प्रायिकतात्मक आउटपुट के साथ जोड़ता है। आप एक नया मॉडल प्रशिक्षित किए बिना विभिन्न प्रकार के कार्यों को पूरा कर सकते हैं, जबकि विभिन्न डोमेन्स (कोड, टेक्स्ट, लॉग्स, UI states, events, आदि) में विशेषज्ञता बनाए रख सकते हैं। Jev समानांतर में आउटपुट भी उत्पन्न कर सकता है, जिससे यह अनुक्रमिक जनरेशन तक सीमित LLM की तुलना में बहुत तेज़ हो जाता है।

TL;DR यह एक वास्तव में स्मार्ट, सामान्यीकरण योग्य (generalizable) classifier है।

Jev क्यों मौजूद है?

TypeSafe के CEO और सह-संस्थापक Diogo Almeida ने OpenAI में RLHF (reinforcement learning from human feedback) और ChatGPT उत्पाद बनाने में मदद करने के लिए समय बिताया। RLHF ने हमें LLMs को निर्देशों और prompts का पालन करने में वास्तव में अच्छा बनाने के लिए प्रशिक्षित करने की अनुमति दी, जो उनकी autoregressive प्रकृति से मेल खाता है।

फिर उन्होंने AI-संचालित सॉफ्टवेयर को सक्षम करने के लिए एक अलग श्रेणी के मॉडल्स को प्रशिक्षित करने के लिए OpenAI छोड़ दिया, एजेंट्स के बजाय। Jev को RLCD (reinforcement learning from calibrated decisions) के साथ प्रशिक्षित किया जाता है, जो शोध भाषा में इस बात का संकेत है कि वे मॉडल को उत्तरों के बजाय विश्वास स्तर (confidence) और प्रायिकताओं को आउटपुट करने में वास्तव में अच्छा बनाने के लिए प्रशिक्षित करते हैं।

TypeSafe का मानना है कि सॉफ्टवेयर बुद्धिमान होना चाहिए। एजेंट्स स्वाभाविक रूप से उस तरह से सॉफ्टवेयर के ऐतिहासिक कार्यप्रणाली में विलीन नहीं होते, और human-in-the-loop बुद्धिमान और स्वतंत्र (autonomous) सॉफ्टवेयर को कठिन बना देता है। Jev सॉफ्टवेयर सिस्टम्स के भीतर एक संयोजनीय (composable), भरोसेमंद primitive के रूप में बुद्धिमत्ता की ओर एक कदम है।

यह पूरी तरह से नया विचार नहीं है, 2017 में शोधकर्ताओं ने पाया कि मजबूत predictive accuracy का मतलब विश्वसनीय confidence estimates नहीं होता (इसलिए LLMs यहाँ एक पूर्ण समाधान नहीं हैं)।

RLHF के बजाय RLCD क्यों?

RLHF की समस्या यह है कि जो इंसान चाहते हैं, वह हमेशा वस्तुनिष्ठ रूप से सही नहीं होता। केवल इसलिए कि हम किसी निश्चित प्रारूप में एक निश्चित उत्तर को प्राथमिकता देते हैं, इसका मतलब यह नहीं है कि मॉडल अधिक बुद्धिमान हो जाते हैं, बल्कि वे काम करने में अधिक सुखद हो जाते हैं।

यह mode collapse भी पेश करता है, RLHF LLMs को एक एकल उत्तर की ओर अभिसरण (converge) करता है, जहाँ कभी-कभी कई trajectories "सही" हो सकती हैं।

"एक आउटपुट किसी व्यक्ति के लिए आकर्षक हो सकता है बिना unattended automation के लिए पर्याप्त विश्वसनीय हुए। Human preference और machine trustworthiness अलग-अलग optimization targets हैं।"

Jev's Docs द्वारा Mode collapse

Jev को एजेंट्स बनाने के लिए नहीं बनाया गया था

आपकी timeline पर जो सब कुछ दिख रहा है, उसके विपरीत, Jev एक standalone agent के रूप में बहुत अच्छा नहीं है। हमने इसके संस्करणों को बनाने की कोशिश की है, दोनों Jev only और LLM + Jev।

https://x.com/kylejeong/status/2100622054945095934

ईमानदारी से कहूं तो, Jev agents ठंडे demos बनाते हैं। उनमें से बहुत सारे lightning speed के साथ agent tasks करने के लिए Jev का उपयोग कर रहे हैं। लेकिन सबसे अच्छे demos भी production में deploy होने के लिए तैयार नहीं हैं।

Jev जैसे मॉडल का उद्देश्य AI-संचालित सॉफ्टवेयर है, यह deterministic code में composed निर्णय लेने में आपकी मदद कर सकता है। reasoning या generative capabilities के बिना, इसे standalone agent के रूप में उपयोग करना केवल अज्ञानता है।

AI-powered Software

एक standalone computer use agent के रूप में Jev को छोड़ने के बजाय, इसे customer support routing, invoice processing, security alerts और triaging, या एक agent monitor के रूप में उपयोग किया जाना चाहिए।

आंकड़े

उनका पहला मॉडल Jev 1.13.0 input tokens के लिए $42/btok (या $0.042/mtok) और output tokens के लिए $0 खर्च करता है। संदर्भ के लिए, Fable 5.1 input के लिए $10/mtok है, जो $10,000 / Btok है। विशिष्ट enterprise workloads में input-output tokens का अनुपात 3:1 या 4:1 होता है, इसलिए Fable ~$20,000/Btok तक चला जाता है ($50/mtok output के साथ)।

Context window प्रति request 64k tokens है, जहाँ state + सबसे लंबा प्रश्न 32k tokens में फिट होना चाहिए।

हालाँकि, उनके आंतरिक benchmarks में वे OpenAI, Anthropic, और Deepseek (inference के लिए Fireworks के माध्यम से) के सभी मॉडल्स से accuracy/cost और accuracy/speed में बेहतर प्रदर्शन करते हैं।

accuracy/cost

बहुत हो गया बातें, मैं इसका उपयोग कैसे करूं?

अब आपके पास Jev के बारे में पर्याप्त समझ होनी चाहिए ताकि आप अपने वर्तमान काम के लिए कुछ उपयोग के मामलों (use cases) के बारे में सोच सकें। (यदि नहीं, तो यहाँ TypeSafe द्वारा अनुशंसित उपयोग के मामलों की एक सूची है)।

आपकी रचनात्मकता को इसका उपयोग कैसे करना चाहिए, इस पर सीमित करने के बजाय, मैं आपको दिखाऊंगा कि हमने अपने framework Stagehand में Jev को कैसे retrofit किया है।

पिछले 2 वर्षों से Stagehand AI और Agents के लिए एक remote browser को नियंत्रित करने के framework के रूप में विकसित हुआ है। Agents पर्याप्त अच्छे होने से पहले, हमने developers को self-healing scripts लिखने में मदद करने के लिए web को automate करने के लिए AI-primitives Act (एक action को पूरा करें), Extract (structured data निकालें), और Observe (page पर संभावित actions की खोज करें) बनाए थे।

Playwright (या अन्य legacy frameworks) का उपयोग करने और actions में selectors प्रदान करने के लिए DOM को हाथ से parse करने के बजाय, Stagehand A/E/O आपको automations बनाने के लिए natural language का उपयोग करने की अनुमति देता है।

typescript

1// Playwright
2await page.click('button[type="submit"]');
3
4// Stagehand
5stagehand.act("click the submit button")

यह पहली बार scripts लिखते समय मददगार होता है (development speed बहुत तेज़ होती है), लेकिन script maintenance के लिए विशेष रूप से मददगार होता है। यदि कोई website बदल जाती है और DOM selectors अपडेट हो जाते हैं, तो Playwright scripts को नए page से मेल खाने के लिए दोबारा लिखना पड़ता है। Stagehand runtime पर selectors और actions चुनता है, और ये "self-healing" होते हैं।

आप थोड़ा सा देख सकते हैं कि हम कहाँ जा रहे हैं। Jev इन primitives में बेहद अच्छी तरह फिट बैठता है। हम मूल रूप से एक LLM का उपयोग करते थे (page कैसा दिखता है और goal क्या है, इस पर context देकर) यह तय करने के लिए कि क्या करना है। Jev के साथ, हम Choice का उपयोग यह तय करने के लिए कर सकते हैं कि किन selectors के साथ इंटरैक्ट करना है।

आइए विशेष रूप से Act का उपयोग करके flow पर चर्चा करें। आम तौर पर, हम hybrid a11y-tree का उपयोग करके page का एक संक्षिप्त representation LLM को देते थे। Jev के साथ, हम पहले a11y tree में nodes को mark करते हैं कि वे interact-able हैं (even rich-text editors) या नहीं।

जब stagehand.act call किया जाता है:

Jev instruction को एक action में classify करता है (जैसे click, fill, या scroll)
Stagehand arguments को parse करता है और उस action के लिए candidate list बनाता है (जिसमें nearby page context शामिल होता है)
Jev उत्तर देता है "कौन सा candidate सबसे अच्छा है" और "क्या कोई candidate match करता है" 0.7 के acceptance threshold के साथ
यदि candidate action स्वीकार किया जाता है, तो Stagehand execution को संभालता है
यदि action स्वीकार नहीं किया जाता है, तो Stagehand एक LLM पर fallback करता है

Act Flow

प्रारंभिक testing में, Act median latency 1.97 seconds से घटकर 0.46 seconds हो जाती है, जो लगभग 4.3× तेज़ है (या 77% कम समय)। पूरा PR stack देखें।

Computer use के साथ, Jev pie का एक टुकड़ा है लेकिन standalone solution नहीं है। अब हम ऐसे अधिक deterministic software tools बना सकते हैं जिन्हें agents उपयोग कर सकें।

Jev का उपयोग कब करें

वास्तविक दुनिया में AI को वितरित करना (Diffusing)

क्या Jev production grade computer use agents बनाएगा? नहीं। क्या यह puzzle का एक उपयोगी टुकड़ा है? मुझे लगता है कि यह होगा।

ऐसा लगता है कि विचारों की भरमार है जो Jev से पहले समझ में नहीं आते थे। मैंने लोगों को instant search, smart copy paste, और अधिक सरल लेकिन अत्यंत मददगार tools बनाते हुए देखा है।

AI को chat interface के किसी संस्करण में, sync या async, सीमित नहीं होना चाहिए। Jev जैसे मॉडल्स के साथ, हम such software बना सकते हैं जो prediction models को include करता है बिना chat input box के। भले ही classifiers इतने लंबे समय से उपलब्ध रहे हैं, वे कभी भी इतने उपयोगी नहीं लगे थे। शायद हमें बस प्रेरणा की ज़रूरत थी।

-> Kyle