क्या Jev AI एजेंट की लागत घटा सकता है? मॉडल रूटिंग से परिणाम सत्यापन तक पूरी गणना
Jev की एक कॉल सस्ती है, लेकिन किसी AI एजेंट में कम लागत वाला निर्णय मॉडल जोड़ने से पूरी प्रणाली अपने-आप सस्ती नहीं हो जाती। यह लेख तीन सामान्य आर्किटेक्चर—प्री-रूटिंग, कॉन्टेक्स्ट फ़िल्टरिंग और पोस्ट-जनरेशन सत्यापन—का विश्लेषण करता है और बताता है कि रीट्राई, मानव समीक्षा, लेटेंसी तथा गलत रूटिंग को जोड़कर वास्तविक बचत कैसे मापी जाए।
विषय-सूची
सारांश
Jev की एक कॉल बहुत सस्ती है, लेकिन किसी AI एजेंट में कम लागत वाला निर्णय मॉडल जोड़ देने से पूरी प्रक्रिया अपने-आप सस्ती नहीं हो जाती।
असल प्रश्न यह है कि क्या Jev कुछ अनुरोधों को सामान्य कोड या सस्ते मॉडल की ओर भेज सकता है, मुख्य मॉडल को भेजे जाने वाले कॉन्टेक्स्ट को घटा सकता है और परिणाम की जाँच करके बेकार रीट्राई रोक सकता है। साथ ही, उसकी गलत वर्गीकरण, लेटेंसी, मानव समीक्षा और इंजीनियरिंग रखरखाव की अपनी लागत भी होती है।
यह लेख मॉडल रूटिंग, कॉन्टेक्स्ट फ़िल्टरिंग और परिणाम सत्यापन—इन तीन सामान्य आर्किटेक्चर—का विश्लेषण करता है और एक पूरी लागत-गणना देता है, ताकि यह समझा जा सके कि Jev किन परिस्थितियों में एजेंट की कुल लागत घटा सकता है और किन परिस्थितियों में वह केवल एक अतिरिक्त API कॉल बनकर रह जाता है।
कई AI एजेंटों में लागत की समस्या ऊपर से देखने पर “मुख्य मॉडल बहुत महँगा है” जैसी लगती है। व्यवहार में असली समस्या अक्सर यह होती है कि वर्कफ़्लो अलग-अलग प्रकार के कामों में अंतर नहीं करता।
“मेरे ऑर्डर की स्थिति बताइए” जैसे अनुरोध के लिए केवल एक डेटाबेस क्वेरी पर्याप्त हो सकती है। “पिछले छह महीनों में ऑर्डर की असामान्यताओं के कारणों का विश्लेषण कीजिए” जैसे अनुरोध के लिए कई स्रोतों को जोड़ने वाला शक्तिशाली मॉडल चाहिए हो सकता है। कुछ अनुरोधों में पर्याप्त जानकारी ही नहीं होती; ऐसे में किसी मॉडल को बुलाने के बजाय पहले उपयोगकर्ता से स्पष्टीकरण माँगना अधिक उचित है।
यदि हर अनुरोध सीधे उसी शक्तिशाली मॉडल को भेज दिया जाए, तो प्रणाली सरल रहती है, लेकिन उन अनेक कामों के लिए भी वही कीमत चुकाती है जिन्हें सामान्य कोड या छोटा मॉडल कर सकता था।
Jev एक अलग तरीका प्रस्तावित करता है।
यह चैट या लंबा टेक्स्ट बनाने के लिए डिज़ाइन नहीं किया गया है। डेवलपर इसे एक state देता है और टाइप किए हुए प्रश्नों का समूह पूछता है; Jev Choice, Score या Noul जैसे संरचित निर्णय और संभावनाएँ लौटाता है। फिर बिज़नेस लॉजिक तय करता है कि टूल बुलाना है, सस्ता मॉडल इस्तेमाल करना है, शक्तिशाली मॉडल तक एस्केलेट करना है या मामला इंसान को देना है। TypeSafe इसे पहला System One मॉडल कहता है—अर्थात ऐसा मॉडल जिसे सॉफ़्टवेयर के भीतर तेज़, संरचित निर्णय लेने के लिए बनाया गया है। (typesafe.ai)
कीमत की दृष्टि से यह निर्णय लगभग नगण्य लगता है।
लॉन्च के समय TypeSafe ने Jev की कीमत प्रति दस लाख इनपुट टोकन 0.042 अमेरिकी डॉलर बताई थी और आउटपुट टोकन के लिए शुल्क नहीं रखा था। कंपनी ने 70–500 मिलीसेकंड की सामान्य एंड-टू-एंड लेटेंसी भी बताई, लेकिन साथ ही स्पष्ट किया कि ये आँकड़े विशेष क्षेत्रों और परीक्षण परिस्थितियों से आए हैं तथा हर डिप्लॉयमेंट वातावरण का प्रतिनिधित्व नहीं करते। (typesafe.ai)
समस्या यह है:
सस्ता निर्णय अपने-आप पूरे एजेंट वर्कफ़्लो को सस्ता नहीं बनाता।
Jev बचत कर पाएगा या नहीं, यह इस बात पर निर्भर करता है कि उसके बाद होने वाला काम बदलता है या नहीं—सिर्फ Jev कॉल की कम कीमत पर नहीं।
AI एजेंट का वास्तविक बिल केवल मॉडल शुल्क नहीं है
एक एजेंट को एक काम पूरा करने में सामान्यतः कम से कम छह तरह की लागत आती है:
| लागत का प्रकार | इसमें क्या शामिल है |
|---|---|
| निर्णय लागत | इंटेंट वर्गीकरण, मॉडल रूटिंग, जोखिम जाँच और यह तय करना कि टूल चाहिए या नहीं |
| कॉन्टेक्स्ट लागत | बातचीत का इतिहास, खोज परिणाम, टूल आउटपुट, लॉग और दस्तावेज़ |
| जनरेशन लागत | मुख्य मॉडल के इनपुट, आउटपुट और रीजनिंग टोकन |
| रीट्राई लागत | मॉडल टाइमआउट, टूल विफलता, फ़ॉर्मेट त्रुटि और दोबारा जनरेशन |
| मानव लागत | समीक्षा, सुधार, अपवाद सँभालना और उच्च जोखिम वाले कार्यों की स्वीकृति |
| गलत निर्णय की लागत | गलत रूटिंग, छूटी जानकारी या गलत कार्रवाई के बाद सुधार |
इसलिए एक काम की अधिक पूरी लागत इस प्रकार लिखी जा सकती है:
कुल लागत
= निर्णय लागत
+ कॉन्टेक्स्ट प्रोसेसिंग लागत
+ आगे के मॉडल और टूल की लागत
+ रीट्राई और फ़ॉलबैक लागत
+ मानव समीक्षा लागत
+ गलत निर्णयों से पैदा हुई सुधार लागतJev की कॉल आम तौर पर इस कुल राशि का बहुत छोटा हिस्सा होती है।
उसकी वास्तविक बचत की संभावना बाद की मदों में है: एक महँगी मॉडल कॉल बचाना, अनावश्यक कॉन्टेक्स्ट न भेजना, विफल काम को दोबारा चलने से रोकना या इंसानों को केवल सचमुच अनिश्चित मामलों की समीक्षा करने देना।
सबसे सामान्य लागत-बचत तरीकों को तीन श्रेणियों में रखा जा सकता है:
- प्री-रूटिंग: पहले निर्णय लें, फिर तय करें कि किसे कॉल करना है।
- कॉन्टेक्स्ट फ़िल्टरिंग: मुख्य मॉडल बुलाने से पहले अनावश्यक जानकारी हटाएँ।
- पोस्ट-वेरिफ़िकेशन: पहले सस्ते मॉडल से काम कराएँ, जाँच विफल होने पर ही एस्केलेट करें।
लागत बचाने का पहला तरीका: Jev को मुख्य मॉडल से पहले राउटर बनाना
सबसे सीधा आर्किटेक्चर है:
उपयोगकर्ता का अनुरोध
↓
Jev इंटेंट, जटिलता और जोखिम का आकलन करता है
↓
सामान्य कोड / सस्ता मॉडल / शक्तिशाली मॉडल / इंसानTypeSafe का आधिकारिक रूटिंग पैटर्न भी यही विचार अपनाता है: हर अनुरोध को उसी LLM में भेजना ज़रूरी नहीं है। कुछ अनुरोध निर्धारक कोड को, कुछ विशेष मॉडल को और जटिल या उच्च जोखिम वाले अनुरोध अधिक महँगे मॉडल या इंसान को दिए जा सकते हैं। (docs.typesafe.ai)
उदाहरण के लिए, ग्राहक सहायता एजेंट पहले यह तय कर सकता है:
- क्या यह केवल ऑर्डर की स्थिति पूछ रहा है?
- क्या इसमें रिफ़ंड या चार्जबैक शामिल है?
- इसे बिलिंग, तकनीकी सहायता या बिक्री में किसे भेजना चाहिए?
- क्या इंसानी हस्तक्षेप चाहिए?
- क्या वास्तव में फ्रंटियर रीजनिंग मॉडल की आवश्यकता है?
Jev केवल ये निर्णय करता है।
डेटाबेस क्वेरी, रिफ़ंड कार्रवाई, उत्तर जनरेशन और मानव टिकट-हैंडलिंग अब भी आसपास की प्रणाली करती है।
एक रूटिंग निर्णय कितना सस्ता है?
स्रोत सामग्री में दर्ज एक वास्तविक API परीक्षण में दस सहायता टिकटों को एक ही अनुरोध में रखा गया था। हर टिकट के लिए रूटिंग और मानव समीक्षा की आवश्यकता जाँची गई, कुल 20 प्रश्न थे:
- कुल इनपुट: 2,571 टोकन;
- कॉल का समय: लगभग 405 मिलीसेकंड;
- सार्वजनिक कीमत पर कुल लागत: लगभग 0.000108 अमेरिकी डॉलर;
- प्रति टिकट औसत: लगभग 0.0000108 अमेरिकी डॉलर;
- समान टोकन प्रोफ़ाइल पर अनुमान: लगभग प्रति दस लाख टिकट 10.8 अमेरिकी डॉलर।
जब इन्हीं दस टिकटों को दस अलग कॉल में भेजा गया, तो कुल समय लगभग 3,664 मिलीसेकंड था। मुख्य रूटिंग परिणाम समान रहे, लेकिन कुछ सीमावर्ती मामलों की संभावनाओं में स्पष्ट बदलाव आया। इससे पता चलता है कि बैचिंग अनुरोध-ओवरहेड को बहुत घटा सकती है, लेकिन यह हर बिज़नेस डोमेन में रूटिंग की सटीकता सिद्ध नहीं करती और न ही यह सिद्ध करती है कि उच्च जोखिम वाले गेट के लिए वही थ्रेशोल्ड उपयुक्त होगा।
मॉडल रूटिंग का ब्रेक-ईवन बिंदु
मान लें:
C_high: शक्तिशाली मॉडल की एक कॉल की लागत;C_low: सस्ते मॉडल की एक कॉल की लागत;C_jev: Jev निर्णय की लागत;P_code: उन अनुरोधों का अनुपात जिन्हें सामान्य कोड पूरा कर सकता है;P_low: उन अनुरोधों का अनुपात जिन्हें सस्ता मॉडल पूरा कर सकता है;P_error: गलत रूटिंग के कारण सुधार चाहने वाले अनुरोधों का अनुपात।
यदि हर अनुरोध सीधे शक्तिशाली मॉडल को जाता है, तो अपेक्षित लागत है:
C_direct = C_highरूटिंग जोड़ने के बाद अपेक्षित लागत बनती है:
C_route
= C_jev
+ P_low × C_low
+ P_high × C_high
+ P_error × C_repairइसलिए रूटिंग तभी पैसा बचाती है जब:
बचाई गई शक्तिशाली मॉडल लागत
>
Jev लागत + गलत रूटिंग से पैदा हुई सुधार लागतक्योंकि Jev स्वयं सस्ता है, अंतिम अर्थशास्त्र आम तौर पर दो प्रश्नों से तय होता है:
- कितने अनुरोध वास्तव में शक्तिशाली मॉडल से बच सकते हैं?
- गलत रूटिंग के परिणाम कितने महँगे हैं?
केवल समझाने के लिए एक गणना
निम्न कीमतें सिर्फ तर्क समझाने के लिए हैं; वे किसी विशिष्ट मॉडल की वास्तविक कीमत नहीं हैं:
- शक्तिशाली मॉडल: प्रति कॉल 0.01 अमेरिकी डॉलर;
- सस्ता मॉडल: प्रति कॉल 0.002 अमेरिकी डॉलर;
- Jev: प्रति कॉल लगभग 0.0000108 अमेरिकी डॉलर;
- कुल मात्रा: 100,000 अनुरोध।
मान लें रूटिंग के बाद:
- 20% सामान्य कोड पूरा करता है;
- 50% सस्ते मॉडल को जाते हैं;
- 30% शक्तिशाली मॉडल को जाते हैं;
- त्रुटि या विफलता के कारण अतिरिक्त 5% को एक शक्तिशाली मॉडल सुधार कॉल चाहिए।
तब:
| मद | लागत |
|---|---|
| बिना रूटिंग: सभी अनुरोध शक्तिशाली मॉडल को | 1,000 अमेरिकी डॉलर |
| 100,000 Jev निर्णय | 1.08 अमेरिकी डॉलर |
| 50,000 सस्ते मॉडल कॉल | 100 अमेरिकी डॉलर |
| 30,000 शक्तिशाली मॉडल कॉल | 300 अमेरिकी डॉलर |
| 5,000 सुधार कॉल | 50 अमेरिकी डॉलर |
| रूटिंग के बाद कुल लागत | 451.08 अमेरिकी डॉलर |
इन मान्यताओं में कुल लागत लगभग 55% घटती है।
लेकिन यदि केवल 10% अनुरोध सस्ते मॉडल को जा सकते हों, 90% अंततः शक्तिशाली मॉडल तक पहुँचते हों और 5% को सुधार चाहिए हो, तो कुल लागत लगभग 971.08 अमेरिकी डॉलर होगी।
इस तरह बचत लगभग 2.9% होगी।
डेवलपमेंट, मॉनिटरिंग, थ्रेशोल्ड कैलिब्रेशन और अतिरिक्त लेटेंसी जोड़ने के बाद यह रूटिंग लेयर बनाना उचित भी न हो सकता है।
इसलिए सबसे पहले Jev की यूनिट कीमत नहीं, बल्कि यह मापना चाहिए:
आपके वास्तविक ट्रैफ़िक का कितना हिस्सा सचमुच शक्तिशाली मॉडल नहीं चाहता?
लागत बचाने का दूसरा तरीका: मुख्य मॉडल को भेजा जाने वाला कॉन्टेक्स्ट घटाना
कॉन्टेक्स्ट एजेंट की दूसरी बड़ी लागत है।
लंबे समय तक चलने वाले एजेंट में ये चीज़ें जमा हो सकती हैं:
- बातचीत का इतिहास;
- कई चरणों के टूल आउटपुट;
- Bash या बिल्ड लॉग;
- वेब पेज की सामग्री;
- खोज से मिले अंश;
- पुराने हो चुके प्लान और मध्यवर्ती परिणाम।
कई प्रणालियाँ यह सब मुख्य मॉडल को दोबारा भेजती हैं। भले वर्तमान काम को इसका छोटा हिस्सा ही चाहिए, हर इनपुट टोकन की कीमत चुकानी पड़ती है।
Jev को मुख्य मॉडल से पहले रखकर यह तय कराया जा सकता है:
- कौन से खोज परिणाम मौजूदा प्रश्न से संबंधित हैं;
- कौन से टूल आउटपुट आगे उपयोगी हो सकते हैं;
- कौन से पुराने संदेश में प्रतिबंध या अधूरा काम है;
- कौन से अंश prompt injection रख सकते हैं;
- कौन सी जानकारी हटाई जा सकती है या केवल सार के रूप में रखी जा सकती है।
TypeSafe की आधिकारिक use-case map में कॉन्टेक्स्ट चयन, semantic retrieval, RAG passage filtering और agent harness के भीतर कॉन्टेक्स्ट प्रबंधन भी शामिल हैं। (docs.typesafe.ai)
आर्थिक प्रभाव का एक अनुमान इस प्रकार लगाया जा सकता है:
कॉन्टेक्स्ट से शुद्ध लाभ
= हटाए गए टोकन × मुख्य मॉडल की इनपुट कीमत
- Jev फ़िल्टरिंग लागत
- छूटी जानकारी से हुई दोबारा खोज और रीट्राई लागतपहली दो मदों की गणना आसान है। तीसरी को अक्सर नज़रअंदाज़ किया जाता है।
दर्जनों अप्रासंगिक लॉग लाइन हटाना आम तौर पर स्पष्ट लाभ है। लेकिन किसी पुराने संदेश से उपयोगकर्ता की महत्वपूर्ण शर्त हट जाने पर मुख्य मॉडल पूरी तरह गलत परिणाम दे सकता है, जिसके बाद फिर से खोज, फिर से मॉडल कॉल या मानव सुधार की आवश्यकता पड़ सकती है।
एक री-रन कई सफल फ़िल्टरिंग ऑपरेशन की पूरी बचत खा सकता है।
इसलिए Jev को यह तय करने के लिए उपयोग करना बेहतर है कि कौन सी सामग्री संभवतः प्रासंगिक है, न कि उसे एकमात्र स्थायी मेमोरी मैनेजर बना देना। उत्पादन प्रणाली को कम से कम:
- सिस्टम निर्देश, उपयोगकर्ता की कठोर शर्तें और सुरक्षा नियम हमेशा सुरक्षित रखने चाहिए;
- हटाई गई सामग्री का इंडेक्स या मूल प्रति रखनी चाहिए;
- जानकारी कम पड़ने पर एजेंट को हटाई गई सामग्री वापस लाने देनी चाहिए;
- सफलता को केवल कम्प्रेशन अनुपात नहीं, बल्कि आगे के कार्य की सफलता से मापना चाहिए।
कॉन्टेक्स्ट कम्प्रेशन में अधिक उपयोगी माप है:
कम्प्रेशन के बाद कुल टोकन
+ दोबारा खोज के टोकन
+ छूटी जानकारी से पैदा हुए रीट्राई टोकनसिर्फ “इस चरण में कितने टोकन हटे” नहीं।
लागत बचाने का तीसरा तरीका: पहले सस्ता मॉडल, फिर Jev से सत्यापन
एक अन्य सामान्य आर्किटेक्चर में Jev यह तय नहीं करता कि कौन सा मॉडल बुलाना है। वह किसी दूसरे मॉडल के परिणाम की जाँच करता है।
प्रवाह इस प्रकार है:
सस्ता मॉडल परिणाम बनाता है
↓
Jev तथ्यात्मक आधार, निकाले गए फ़ील्ड, नीति जोखिम या कार्य-पूर्णता की जाँच करता है
↓
पास: परिणाम का उपयोग करें
फेल: रीट्राई करें, शक्तिशाली मॉडल तक एस्केलेट करें या इंसान को देंTypeSafe इस तरह के पैटर्न को Universal Verification कहता है। उसकी आधिकारिक सामग्री में RAG citation checking, tool-call validation, output-quality assessment और structured-data extraction cascades शामिल हैं। आधिकारिक SDE Cascade उदाहरण “सस्ते मॉडल से extraction → Jev से हर फ़ील्ड की जाँच → red flag होने पर ही reasoning model तक escalation” का ढाँचा अपनाता है। ये vendor cookbook के परिणाम हैं; इन्हें इस प्रमाण की तरह नहीं पढ़ना चाहिए कि हर extraction task में समान लागत कटौती मिलेगी। (docs.typesafe.ai)
ऐसे cascade की अपेक्षित लागत लगभग है:
C_cascade
= C_low
+ C_jev
+ P_escalate × C_high
+ C_failureसबसे महत्वपूर्ण चर P_escalate है: सस्ते मॉडल के कितने परिणाम अंततः शक्तिशाली मॉडल को देने पड़ते हैं।
विफलता लागत को छोड़कर, cascade सीधे शक्तिशाली मॉडल को भेजने से तब सस्ता है जब:
P_escalate
<
1 - (C_low + C_jev) / C_highउसी काल्पनिक कीमत को लें:
- शक्तिशाली मॉडल: 0.01 अमेरिकी डॉलर;
- सस्ता मॉडल: 0.002 अमेरिकी डॉलर;
- Jev: लगभग 0.0000108 अमेरिकी डॉलर।
ब्रेक-ईवन escalation rate लगभग 80% है। अर्थात यदि लगभग 80% से कम अनुरोध अंततः शक्तिशाली मॉडल तक जाते हैं, तो नाममात्र मॉडल बिल “हर अनुरोध के लिए शक्तिशाली मॉडल” वाले आधार से कम रह सकता है।
लेकिन यह कीमत का ब्रेक-ईवन है, गुणवत्ता का नहीं।
“शक्तिशाली मॉडल के करीब” और “शक्तिशाली मॉडल जितनी ही गुणवत्ता” अलग लागत लक्ष्य हैं
एक preregistered स्वतंत्र मूल्यांकन में CLINC150 के नमूने पर Jev से शक्तिशाली मॉडल तक cascade का परीक्षण किया गया:
- जब अंतिम accuracy को शक्तिशाली मॉडल से एक प्रतिशत अंक कम रहने दिया गया, तो Jev को लगभग 22% अनुरोध एस्केलेट करने पड़े;
- जब शक्तिशाली मॉडल के बिल्कुल समान accuracy की माँग की गई, तो cascade को हर अनुरोध एस्केलेट करना पड़ा, यानी वह “हमेशा शक्तिशाली मॉडल बुलाओ” में बदल गया।
इसलिए शोधकर्ताओं ने परिणाम को “कम लागत पर शक्तिशाली मॉडल की गुणवत्ता के करीब पहुँचना” कहा, न कि “कम कॉल में समान accuracy पाना”। प्रयोग में केवल 200 नमूने, एक dataset और एक service path था, इसलिए इसे अन्य एजेंटों पर सीधे लागू नहीं किया जा सकता। फिर भी यह एक महत्वपूर्ण आर्थिक पैटर्न दिखाता है: गुणवत्ता लक्ष्य में थोड़ा सा बढ़ाव escalation rate में बड़ा उछाल ला सकता है। (github.com)
इसलिए cascade मूल्यांकन में केवल ये आँकड़े देना पर्याप्त नहीं है:
- कितनी शक्तिशाली मॉडल कॉल बचीं;
- कितना ट्रैफ़िक स्वतः सँभाला गया।
इनके साथ यह भी बताना चाहिए:
- स्वतः सँभाले गए हिस्से की accuracy;
- अंतिम end-to-end task success rate;
- सभी अनुरोध शक्तिशाली मॉडल को देने की तुलना में कितनी गुणवत्ता घटी;
- कौन सी त्रुटियाँ आगे के निष्पादन में बढ़ जाती हैं।
एक ही कॉल में कई प्रश्न पूछना अक्सर अनुरोधों की बैचिंग से अधिक महत्वपूर्ण है
Jev एक ही state पर कई प्रश्न पूछने और उनके उत्तर समानांतर लौटाने देता है। आधिकारिक दस्तावेज़ जटिल निर्णय को छोटे, परमाणु प्रश्नों में बाँटने और परिणामों को कोड में जोड़ने की सलाह देते हैं, बजाय कई निर्णयों को एक अस्पष्ट प्रश्न में भरने के। (docs.typesafe.ai)
उदाहरण के लिए, यह पूछने के बजाय:
इस सहायता टिकट के साथ क्या करना चाहिए?
इसे इस प्रकार बाँटें:
- इसे किस बिज़नेस क्यू में जाना चाहिए?
- क्या इसमें स्पष्ट रिफ़ंड अनुरोध है?
- क्या इसमें चार्जबैक, कानूनी कार्रवाई या नियामक का उल्लेख है?
- यह किस urgency band में आता है?
- क्या इंसान चाहिए?
- क्या शक्तिशाली मॉडल बुलाना उचित है?
स्रोत सामग्री के मापन में एक state पर प्रश्नों की संख्या 1 से 8 और फिर 32 करने पर warm-up के बाद लेटेंसी लगभग 350–400 मिलीसेकंड के उसी दायरे में रही। प्रश्न बढ़ने के साथ इनपुट टोकन बढ़े, लेकिन network round trip रैखिक रूप से नहीं बढ़े।
इसलिए उचित पैटर्न है:
मौजूदा चरण के लिए वास्तव में आवश्यक सभी परमाणु प्रश्न एक ही अनुरोध में पूछें, हर निर्णय के लिए अलग API कॉल न करें।
फिर भी बैचिंग का अर्थ सभी उपयोगकर्ताओं, दस्तावेज़ों और कार्यों को एक विशाल state में डालना नहीं है। सहायता टिकट परीक्षण में array-based batching ने मुख्य वर्गीकरण सुरक्षित रखा, लेकिन कुछ सीमावर्ती संभावनाएँ बदल गईं।
बैचिंग रणनीति को एप्लिकेशन के वास्तविक data distribution पर जाँचना अभी भी आवश्यक है।
चार छिपी लागतें जिन्हें आसानी से छोड़ दिया जाता है
1. confidence accuracy नहीं है
Typed output यह सुनिश्चित कर सकता है कि उत्तर interface के अनुरूप है। वह business decision की सत्यता सुनिश्चित नहीं करता।
एक स्वतंत्र मूल्यांकन में 200 नमूनों में से 102 के लिए Jev ने confidence बिल्कुल 1.0 लौटाया, और उनमें से छह निर्णय गलत थे। शोधकर्ताओं को यह भी प्रमाण नहीं मिला कि Jev का confidence छोटे LLM की self-reported confidence से बेहतर ढंग से अपनी गलतियों को रैंक करता है। (github.com)
इसका अर्थ है कि production logic को इस रूप में नहीं लिखना चाहिए:
if (confidence === 1) {
executeDestructiveAction();
}अधिक सुरक्षित तरीका है:
- किसी विशिष्ट decision rule की आवश्यकता हो तो option-level
probabilitiesको प्राथमिकता दें; - अपने labeled set पर threshold चुनें;
- अलग risk level के लिए अलग threshold रखें;
- payment, deletion, suspension जैसे कार्यों में human confirmation बनाए रखें;
- model version, probabilities और अंतिम outcome रिकॉर्ड करें, ताकि drift देखा जा सके।
एक अन्य preregistered calibration evaluation में भी मिश्रित परिणाम मिला: CLINC150 पर ECE 0.0204 था और Banking77 पर 0.0936, जहाँ systematic overconfidence देखा गया। इससे पता चलता है कि calibration task और corpus पर निर्भर है; एक dataset पर tuned threshold को दूसरे business domain में सीधे नहीं ले जाना चाहिए। (systemonemodels.org)
2. गलत रूटिंग मुफ़्त नहीं होती
यदि राउटर साधारण अनुरोध को शक्तिशाली मॉडल भेज देता है, तो प्रायः केवल बचत का एक अवसर खोता है। लेकिन यदि जटिल अनुरोध को सामान्य कोड दे दिया जाए, तो गलत उत्तर, दोहरा काम या उपयोगकर्ता का छोड़ जाना परिणाम हो सकता है।
उच्च जोखिम वाले कार्य में एक गलत निर्णय की लागत सभी मॉडल कॉल की लागत से भी अधिक हो सकती है।
इसलिए चार प्रकार की त्रुटियों को अलग-अलग मापना चाहिए:
- गलत escalation: सस्ते में होने वाला अनुरोध शक्तिशाली मॉडल को भेज दिया गया;
- गलत downgrade: शक्तिशाली मॉडल चाहने वाला अनुरोध सस्ते मार्ग पर चला गया;
- गलत pass: verifier ने दोषपूर्ण परिणाम नहीं पकड़ा;
- गलत block: सही परिणाम को रीट्राई या मानव समीक्षा के लिए रोक दिया गया।
एक aggregate accuracy इन चारों तरह की लागत नहीं दिखाती।
3. लेटेंसी और विफलताएँ भी लागत हैं
स्रोत सामग्री में warm serial calls प्रायः 340–450 मिलीसेकंड थीं। 24 concurrent requests के एक परीक्षण में median latency लगभग 1.2 सेकंड हो गई और तीन transport failures हुए। यह एक वातावरण का छोटा परीक्षण था और आधिकारिक सेवा की सामान्य availability नहीं बताता, लेकिन इतना स्पष्ट करता है कि production architecture decision layer को अचूक local function नहीं मान सकता।
कम से कम पहले से तय होना चाहिए:
- timeout होने पर fail-open, fail-closed या human escalation में से क्या होगा;
- retry होगा या नहीं और कितनी बार;
- Jev उपलब्ध न होने पर क्या सीधे मुख्य मॉडल बुलाया जाएगा;
- routing service की विफलता पूरे एजेंट को रोक सकती है या नहीं;
- p95 और p99 latency product के interaction budget में फिट होती हैं या नहीं।
एक third-party preregistered evaluation में Jev की median call time लगभग 0.42–0.44 सेकंड दर्ज हुई, लेकिन लेखकों ने स्पष्ट किया कि यह एक विशिष्ट client, gateway, region और load का परिणाम था, शुद्ध model inference speed नहीं। (github.com)
4. labeled data मौजूद हो तो Jev सबसे सस्ता विकल्प नहीं भी हो सकता है
Jev का एक महत्वपूर्ण लाभ cold start है: labeled data न होने पर वह natural-language descriptions से zero-shot निर्णय कर सकता है।
लेकिन यदि किसी स्थिर business workflow में बहुत से human-labeled examples पहले से हैं, तो पारंपरिक छोटा मॉडल अधिक उपयोगी हो सकता है।
एक preregistered Banking77 evaluation में 10,003 उदाहरणों पर trained frozen bge-small embedding model और logistic regression ने 0.933 accuracy हासिल की, जबकि Jev ने 0.832। परीक्षण हार्डवेयर पर encoder लगभग 9 मिलीसेकंड में चला और हर अनुरोध पर API शुल्क नहीं था। शोधकर्ताओं ने यह भी स्पष्ट किया कि सूचना की स्थितियाँ अलग थीं: encoder ने बड़ी in-distribution labeled dataset देखी थी, जबकि Jev zero-shot था। इसलिए यह समान परिस्थितियों में model capability comparison नहीं, बल्कि वास्तविक deployment alternatives की तुलना थी। (github.com)
एक व्यावहारिक विकास मार्ग इस प्रकार हो सकता है:
| चरण | किस विकल्प का मूल्यांकन करें |
|---|---|
| labeled data नहीं है और नियम बार-बार बदलते हैं | Jev जैसा zero-shot decision model |
| थोड़ा labeled data जमा हो गया है | Jev + threshold calibration + human review |
| labels स्थिर हैं और dataset बड़ा है | local encoder, classifier या fine-tuned model |
| long-tail tasks बदलते रहते हैं | Jev को fallback रखें |
Jev cold-start accelerator और long-tail decision layer के रूप में विशेष रूप से उपयोगी हो सकता है; हर स्थिर classification task का स्थायी अंतिम समाधान होना आवश्यक नहीं।
लॉन्च से पहले अपनी लागत कैसे गणना करें
वास्तविक एप्लिकेशन के historical tasks का एक सेट लें और offline तीन paths की तुलना करें:
A. हर task को शक्तिशाली मॉडल भेजें
B. Jev routing → code / सस्ता मॉडल / शक्तिशाली मॉडल
C. सस्ता मॉडल → Jev verification → आवश्यकता पर शक्तिशाली मॉडल escalationकम से कम ये metrics रिकॉर्ड करें:
| Metric | यह किस प्रश्न का उत्तर देता है |
|---|---|
| औसत कुल लागत | हर सफल task की वास्तविक लागत क्या थी? |
| शक्तिशाली मॉडल call rate | Jev ने कितनी महँगी calls वास्तव में रोकीं? |
| automatic handling coverage | कितने tasks इंसान और शक्तिशाली मॉडल दोनों से बच गए? |
| automatically handled tasks की accuracy | स्वतः सँभाले गए tasks में कितने सच में सही थे? |
| escalation rate | cascade के कितने tasks अंततः शक्तिशाली मॉडल तक गए? |
| retry rate | routing या verification errors से कितनी अतिरिक्त calls हुईं? |
| human review rate | क्या मानव काम घटा, या सिर्फ दूसरी जगह चला गया? |
| p95 latency | उपयोगकर्ताओं ने वास्तविक tail latency कितनी महसूस की? |
| end-to-end success rate | क्या अंतिम task quality baseline से कम हुई? |
सबसे अर्थपूर्ण metric “Jev decision accuracy” नहीं, बल्कि है:
प्रति सफलतापूर्वक पूर्ण task लागतयदि बहुत सस्ता decision API अधिक retries, human review या गलत execution पैदा करता है, तो वह एजेंट को कम आर्थिक बना सकता है।
किन परिस्थितियों में Jev को पहले आज़माना उचित है
निम्न शर्तें जितनी अधिक पूरी हों, Jev से वास्तविक मूल्य मिलने की संभावना उतनी अधिक है:
- अनुरोध मात्रा बड़ी है और निर्णय बार-बार लेने होते हैं;
- task boundaries स्पष्ट हैं और उन्हें single-step semantic questions में बाँटा जा सकता है;
- बहुत से अनुरोध सामान्य कोड या सस्ता मॉडल सँभाल सकता है;
- dedicated classifier बनाने के लिए अभी पर्याप्त labeled data नहीं है;
- मुख्य मॉडल की call decision call से स्पष्ट रूप से अधिक महँगी है;
- गलतियों को escalation, retry या human review से सीमित किया जा सकता है;
- प्रणाली probabilities, thresholds और final outcomes रिकॉर्ड कर सकती है;
- decision criteria तेज़ी से जोड़ने या बदलने पड़ते हैं।
इसके विपरीत, निम्न स्थितियों में Jev जोड़ना पहला कदम नहीं होना चाहिए:
- लगभग हर अनुरोध अंततः शक्तिशाली मॉडल चाहता है;
- traffic कम है, इसलिए API savings engineering complexity को उचित नहीं ठहराती;
- task में multi-step reasoning, arithmetic, date comparison या long-form generation चाहिए;
- गलत निर्णय सीधे irreversible action चला सकता है;
- बड़ा और स्थिर labeled dataset पहले से है, जिस पर local small model बन सकता है;
- reliable fallback और human-review path बनाना संभव नहीं है;
- योजना official demo के thresholds को सीधे production में कॉपी करने की है।
निष्कर्ष: Jev निर्णय शुल्क नहीं, उसके बाद का महँगा काम बचाता है
Jev की एक कॉल सचमुच सस्ती है, लेकिन यही तय नहीं करता कि वह AI एजेंट की कुल लागत घटाएगा या नहीं।
उसका वास्तविक मूल्य इस बात में है कि वह उस workflow को विभाजित कर सकता है जो अन्यथा पूरा का पूरा एक शक्तिशाली मॉडल को जाता:
- सरल अनुरोध सामान्य कोड को;
- नियमित अनुरोध सस्ते मॉडल को;
- जटिल अनुरोध शक्तिशाली मॉडल को;
- अनिश्चित अनुरोध इंसान को;
- अनावश्यक कॉन्टेक्स्ट भेजा नहीं जाता;
- दोषपूर्ण परिणाम उपयोगकर्ता तक पहुँचने से पहले रोक दिए जाते हैं।
यदि Jev मुख्य मॉडल से पहले रखा गया हो लेकिन हर अनुरोध फिर भी उसी मॉडल तक जाता हो, तो उसने केवल एक अतिरिक्त API कॉल जोड़ी है।
यदि वह भरोसेमंद ढंग से महँगी calls, कॉन्टेक्स्ट आकार या rework घटाता है, तभी वह वास्तविक cost lever बनता है।
इसलिए सही प्रश्न यह नहीं है:
Jev की एक कॉल कितनी सस्ती है?
सही प्रश्न है:
इस निर्णय के बाद प्रणाली को कौन सा महँगा काम अब नहीं करना पड़ा?
यही वह पूरी लागत-गणना है जो किसी AI एजेंट को करनी चाहिए।
