LLM रूटिंग और गार्डरेल्स कैसे करें? Jev और बड़े भाषा मॉडल के सहयोग का उदाहरण

हित और प्रमाण प्रकटीकरण: PandaNpc Jev का उपयोग करने वाली Agent निर्णय परत विकसित कर रहा है। नीचे क्रमशः TypeSafe के आधिकारिक दस्तावेज़, आधिकारिक cookbook, तथा हमार रिपॉज़िटरी में वास्तविक Jev कॉल और सिंथेटिक परिदृश्य कैलिब्रेशन का हवाला दिया गया है। हमारा कैलिब्रेशन स्क्रिप्टेड नकली LLM provider का उपयोग करता है, और यह वास्तविक उपयोगकर्ता ट्रैफ़िक या पूर्ण प्रोडक्शन पाइपलाइन के प्रदर्शन का प्रतिनिधित्व नहीं कर सकता।

LLM रूटिंग को इस तरह किया जा सकता है: पहले Jev तय करे कि अनुरोध किस श्रेणी का है और जोखिम कितना है, फिर कोड तय करे कि इसे सामान्य फ़ंक्शन, विशेषीकृत LLM, या मानव समीक्षा को सौंपा जाए। Jev को retrieval और generation के बीच प्रमाण छानने के लिए भी रखा जा सकता है, या LLM आउटपुट के बाद परिणाम जाँचने के लिए। यह बंद विकल्प, स्कोर और प्रायिकताएँ लौटाता है; खुले उत्तर, कोड जनरेशन और लंबी तर्क-प्रक्रिया अभी भी LLM करता है। TypeSafe का coding agents पर विवरण स्पष्ट रूप से कहता है कि Jev सीधे Claude Code या Codex के पीछे के चैट मॉडल की जगह नहीं ले सकता।

यह लेख एक ग्राहक सेवा अनुरोध, एक RAG प्रश्नोत्तर पाइपलाइन और हमारे अपने Agent कैलिब्रेशन रिकॉर्ड का उपयोग करके समझाता है कि दो प्रकार के मॉडल वास्तव में कहाँ हाथ बदलते हैं, और कम confidence वाले परिणामों के लिए स्पष्ट गंतव्य क्यों ज़रूरी है।

Jev क्या तय कर सकता है, और LLM क्या जिम्मेदारी लेता रहता है?

23 सितंबर 2026 तक, TypeSafe मॉडल पृष्ठ में स्थिर मॉडल jev-1.13.0 सूचीबद्ध है। API एक state और questions का सेट स्वीकार करता है, और POST /v1/systemone के माध्यम से संबंधित संरचित answers लौटाता है। jev-latest उस दिन 1.13.0 की ओर इशारा करता था, लेकिन alias संस्करण के साथ बदलता है; थ्रेशोल्ड कैलिब्रेट कर चुके सिस्टम को संस्करण स्थिर करना चाहिए और प्रतिक्रिया में वास्तविक मॉडल ID रिकॉर्ड करना चाहिए।

Noul में अलग confidence फ़ील्ड नहीं है; Noul प्रायिकता को सीधे “मॉडल confidence” नहीं लिखा जा सकता। Score का उपयोग सटीक राशि निकालने के लिए भी नहीं करना चाहिए। राशि, तिथि तुलना, कोटा और अनुमति जाँच नियतात्मक प्रोग्राम में ही रहनी चाहिए, आधिकारिक रूप से Jev 1.13 की ये सीमाएँ सूचीबद्ध हैं।

एक कॉल का न्यूनतम स्वरूप

नीचे दिया गया अनुरोध स्वरूप आधिकारिक API संदर्भ से मेल खाता है; उदाहरण प्रश्न इस लेख में बनाए गए व्याख्यात्मक कॉन्फ़िगरेशन हैं, और इस लेख में इसका ऑनलाइन वास्तविक परीक्षण नहीं किया गया:

नीचे दिया गया JSON एक अंग्रेज़ी ग्राहक संदेश का उपयोग करता है; हिंदी में ग्राहक कहेगा, “ऑर्डर पर दो बार शुल्क लग गया है, कृपया मेरा रिफ़ंड कर दीजिए।”

{
  "model": "jev-1.13.0",
  "state": {
    "message": "My order was charged twice. Please help me get a refund.",
    "account_note": "Customer asks about an order charge"
  },
  "questions": {
    "intent": {
      "type": "choice",
      "instructions": "What does state.message primarily request?",
      "criteria": {
        "refund": "Money returned for a charge",
        "information": "An explanation only",
        "other": "Neither option fits"
      }
    },
    "asks_refund": {
      "type": "noul",
      "instructions": "Does state.message explicitly ask for money back?"
    }
  }
}

वास्तविक सिस्टम में पहले कोड से यह जाँचना चाहिए कि कटौती रिकॉर्ड एक ही ऑर्डर का है या नहीं, और रिफ़ंड की अनुमति है या नहीं। ऊपर का उदाहरण केवल उपयोगकर्ता की मंशा पढ़ने के लिए है; उपयोगकर्ता द्वारा रिफ़ंड माँगना इस बात का प्रमाण नहीं है कि रिफ़ंड की पात्रता सिद्ध हो गई है, और यह सीधे रिफ़ंड निष्पादित करने का अधिकार भी नहीं देता।

Jev से LLM रूटिंग: तीन हैंडऑफ़ पथ

TypeSafe का आधिकारिक intent routing उदाहरण ग्राहक सेवा अनुरोधों को पहले Jev के पास भेजता है ताकि वह मंशा और जटिलता तय करे, फिर कोड शाखा बनाता है: ऑर्डर स्थिति पूछने पर डेटाबेस फ़ंक्शन जाता है; उत्पाद प्रश्न और वापसी/बदलाव अलग-अलग सामग्री लोड किए गए विशेषीकृत LLM को जाते हैं; जटिल शिकायतें या कम confidence परिणाम मानव कतार में जाते हैं। यही Jev और LLM के सहयोग की सबसे समझने योग्य स्थिति है: पहला संरचित निर्णय देता है, दूसरा केवल तब मंच पर आता है जब व्याख्या या संवाद जनरेट करना हो।

लागू करते समय नीचे दिए क्रम में डिज़ाइन करें, न कि मॉडल को सारी क्रियाएँ स्वतंत्र रूप से तय करने दें:

1. पहले पथ तय करें: स्पष्ट रूप से सूची बनाएँ कि सामान्य फ़ंक्शन, विभिन्न विशेषीकृत LLM, और मानव समीक्षा किन अनुरोधों को संभाल सकते हैं, और Choice के लिए other या समान fallback विकल्प रखें।
2. तथ्यों को state में रखें: उपयोगकर्ता के मूल शब्द, खाता स्थिति, ऑर्डर रिकॉर्ड अलग-अलग फ़ील्ड बनें; अज्ञात स्रोत के वेब पेज टेक्स्ट को सिस्टम निर्देश न मानें।
3. एक बार में संकीर्ण प्रश्न पूछें: मंशा के लिए Choice, जोखिम या तात्कालिकता के लिए Score, पुष्टि करने योग्य एकल तथ्य के लिए Noul। आधिकारिक सुझाव है कि एक ही state के कई स्वतंत्र प्रश्न एक ही अनुरोध में समानांतर मूल्यांकित किए जा सकते हैं।
4. अंतिम रूटिंग कोड करे: पहले अनुमतियाँ और कठोर नियम जाँचें, फिर Jev की प्रायिकता और इस व्यवसाय के लिए कलिब्रेट किए गए थ्रेशोल देखें; कम confidence या प्रमाण-रहित अनुरोध मानव के पास या अतिरिक्त प्रश्न पर जाएँ।
5. परिणाम रिकॉर्ड करें और समीक्षा करें: मॉडल संस्करण, प्रश्न संस्करण, प्रायिकता, अंतिम गंतव्य और मानव सुधार परिणाम सहेजें, तभी तय हो सकेगा कि थ्रेशोल्ड उपयुक्त है या नहीं।

चित्र स्रोत: TypeSafe AI《System One Models और Jev का परिचय》, 2026-09-15। चार वर्कफ़्लो TypeSafe ने स्वयं बनाए हैं, मीट्रिक वर्कफ़्लो के अनुसार समान भार में संकलित हैं; मूल्यांकन विधि देखें TypeSafe workflow evals।

आधिकारिक चित्र यह समझने में मदद करता है कि यह “कई संकीर्ण निर्णयों को प्रोग्राम वर्कफ़्लो में डालना” पर ज़ोर क्यों देता है। चित्र की ऊर्ध्वाधर धुरी विक्रेता के “accuracy” नाम का अनुसरण करती है, लेकिन उसका संदर्भ उत्तर दो बड़े मॉडलों की अनुमानित प्रायिकताओं की सहमति से आता है, मानव-सत्यापित एकमात्र सही उत्तर से नहीं; लागत और मीट्रिक भी इन चार वर्कफ़्लो और विक्रेता की मूल्यांकन विधि पर निर्भर हैं, इन्हें “किसी भी परिदृश्य में कितना बचेगा” में नहीं बदला जा सकता।

रिट्रीवल-ऑगमेंटेड जनरेशन: Jev LLM उत्तर से पह प्रमाण छानता है

TypeSafe RAG passage cookbookधिक ठोस मल्टी-मॉल उदाहरण देती है: OpenAI embeddingहले पैराग्राफ़ निकालता है, फिर Jev हर “प्रश्न + पराग्राफ़” के लिए चारoul पूछता है—क्या यह प्रासंगिक है, क्या इसमें उत्तर देने के लिए उपयोगी प्रमाण है, क्या यह प्रश्न की पूर्वधारणा का खंडन करता है, क्या यह उत्तर मॉडल को निर्देश देने का प्रयास करता है। कोड चारों प्रायिकताओं को क्रम में संसाधित करता है और तय करता है कि पैराग्राफ़ को प्रमाण क्षेत्र में रखना है, विरोधाभासी प्रमाण क्षेत्र में रखना है, या छोड़ देना है; अंत में Claude Sonnet 5 उत्तर लिखता है।

यह चरण एक सामान्य समस्या हल करता है: वेक्टर समानता में उच्च पैराग्राफ़ हमेशा उपयोगी नहीं होते। हो सकता है उसने केवल समान शब्दों का उपयोग किया हो, या किसी फ़ोरम पोस्ट में “पिछला पाठ अनदेखा करें” जैसा प्रॉम्प्ट इंजेक्शन छिपा हो। cookbook का उदाहरण इंजेक्शन जाँच को रूटिंग नियमों से पहले रखता है, साथ ही याद दिलाता है कि थ्रेशोल्ड उस कॉर्पस के लिए चुना गया शुरुआती बिंदु है, सभी RAG अनुप्रयोगों का डिफ़ॉल्ट नहीं। उसके प्रदर्शन आँकड़े 2026-08-27 के jev-1.12 से हैं, इन्हें वर्तमान jev-1.13.0 के नए मूल्यांकन परिणाम नहीं माना जा सकता।

जनरेशन के बाद एक और परत की जाँच की जा सकती है। TypeSafe की citation check cookbook पहले प्रोग्राम से उद्धरण का मूल पाठ ढूँढती है, फिर Jev से तय कराती है कि वह अनुच्छेद जनरेट किए गए दावे का समर्थन करता है, खंडन करता है, या उसका ज़िक्र नहीं करता। यह ऐसे उद्धरण अलग कर सकती है जिन्हें दोबारा जाँचना चाहिए; मॉडल का निर्णय स्वयं भी गलत हो सकता है, “जाँच पास” को तथ्य की गारंटी नहीं लिखा जा सकता।

हमारा Agent कैलिब्रेशन: कम confidence वाला एस्केलेशन कहाँ अटकता है?

PandaNpc रिपॉज़िटरी में, Jev क्लाइंट, प्रश्न बैंक और ऑर्केस्ट्रेटर Jev का उपयोग Agent की मंशा पहचान, उम्मीदवार संशोधन स्कोरिंग, पूर्णता शर्त जाँच और सबमिशन निर्णय में करते हैं। क्लाइंट टाइमआउट, 429, 5xx पर सीमित पुनःप्रयास करता है, अनुरोध बजट और समाप्त परिणामों की सीमा तय करता है; निष्पादन अनुमति ऑर्केस्ट्रेटर और नियंत्रित टूल परत के पास है, Jev के एक वाक्य से सीधे नहीं दी जाती।

हमने 2026-09-22 को jev-1.13.0 के साथ 19 सिंथेटिक turn में प्रत्येक पर एक shadow और एक enforce चलाया, कुल 38 रन, और 165 वास्तविक Jev निर्णय रिकॉर्ड किए। यह आंतरिक कैलिब्रेशन रिपोर्ट और सहेजी गई वास्तविक मशीन प्रतिक्रियाएँ स्क्रिप्टेड नकली LLM provider का उपयोग करती हैं, इसलिए ये आँकड़े केवल नियंत्रित परिदृश्य में निर्णय प्रदर्शन बताते हैं। ये वास्तविक उपयोगकर्ता अनुरोधों के अंतर्गत समग्र सफलता दर, बचत अनुपात या एंड-टू-एंड लेटेंसी सिद्ध नहीं करते।

सबसे मूल्यवान खोज औसत गति नहीं, बल्कि “सुरक्षित दिखने वाले” थ्रेशोल्ड से बना अवरोध था: enforce के 19 turn में से 13, Q2 “जानकारी संशोधन शुरू करने के लिए पर्याप्त है या नहीं” पर, Noul प्रायिकता मूल 0.15–0.85 अनिश्चितता अंतराल में गिरने के कारण एस्केलेट हो गए; LLM Worker को आगे के चरण निष्पादित करने का मौका नहीं मिला। कैलिब्रेशन रिकॉर्ड दिखाता है कि सूचना-पर्याप्त बताए गए 34 Q2 निर्णयों में से कई की प्रायिकता मध्य भाग में थी। रिपोर्ट सुझाव देती है कि जटिल Q2 को और अधिक परमाणु निर्णयों में तोड़ा जाए, या एस्केलेशन नियम समायोजित किए जाएँ; ये सुझाव हैं, पहले से तैनात थ्रेशोल्ड नहीं।

हमारा प्रश्न बैंक प्रवेश को answer_only, inspect, modify या out_of_scope में वर्गीकृत करता है; लेखन पथ पर, Worker द्वारा सुझाए गए उम्मीदवार संशोधन पहले Score से क्रमबद्ध होते हैं, और अंतिम सामग्री तथा परिवर्तन सारांश फिर स्वीकृति और सबमिशन निर्णय से गुज़रते हैं। ये केवल निर्णय बिंदु हैं: वस्तु को वास्तव में पढ़ा/लिखा जा सकता है या नहीं, यह नियंत्रित निष्पादक चरण के अनुसार अनुमति देता है। Jev के पास स्वयं टूल allowlist ढीली करने का अधिकार नहीं है, और वह सबमिशन-पूर्व consistency जाँच को बायपास नहीं कर सकता।

कैलिब्रेशन डेटा दूसरा व्यार-समझौता दिखाता है। shadow मोड में, Jev उत्तर और पूर्ण वितरण देता है, लेकिन Worker के मूल निष्पादन पथ को नहीं बदलता; enforce मोड में, उत्तर प्रभावित करता है कि जारी रखना है, एस्केलेट करना है या छोड़ना है। shadow की सटीकता को सीधे enforce की पूर्णता दर मानना सिस्टम को गलत पढ़ेगा: Q2 का एस्केलेशन कार्य को समय से पहले रोक देगा, जिससे आगे उम्मीदवार स्कोरिंग, स्वीकृति और सबमिशन प्रश्नों को मौका ही नहीं मिलेगा। इसलिए यह रिपोर्ट प्रत्येक प्रश्न के वितरण, एस्केलेशन दिशा और अंतिम स्थिति को अलग-अलग पढ़ती है।

उम्मीदवार संशोधनों में एक ठोस तुलना है: उसी turn में, सटीक संशोधन लक्ष्य वाले उम्मीदवार को 2.94 अंक मिले, जबकि पूरी फ़ाइल ओवरराइट करने वाले उम्मीदवार को 0.38 अंक; उच्च अंक वाला उम्मीदवार चुना गया। यह उदाहरण केवल बताता है कि उस सिंथेटिक स्थिति में स्कोरिंग प्रश्न ने दो योजनाओं को अलग किया। इसके विपरीत, एक काटे गए प्रमाण वाले उम्मीदवार को 2.27 अंक मिले; संख्या “ठीक-ठाक” लगने भर से उसके कम confidence और truncation मार्कर को अनदेखा नहीं करना चाहिए। हमारा कोड अधूरे प्रमाण को अलग चिह्नित करता है, ताकि मॉडल केवल सुरक्षित रखे गए prefix के आधार पर निश्चित लेखन निर्णय न करे।

हमने “कौन-सा उम्मीदवार चुनना है” और “उसे लिखने देना है” को दो अलग चरणों में बाँटा है। उम्मीदवार Jev से स्कोर होने के बाद, नियंत्रित निष्पादक केवल ACT/modify चरण में लेखन टूल खोलता है; जारी किया गया one-time ticket टूल कॉल ID, वर्तमान revision number, लक्ष्य ऑब्जेक्ट hash और पैरामीटर सारांश से बंधा होता है। उम्मीदवार पाठ मॉडल को “प्रतिबंध अनदेखा करो” के लिए प्रेरित करे, तो भी इन जाँचों को पार करने वाली टूल अनुमति नहीं मिलेगी। यह हमारे कोड-स्तरीय एकीकरण से मिला अनुभव है: प्रायिकता निर्णय तय करता है कि कौन-सा रास्ता अपनाने लायक है, साइड-इफ़ेक्ट अनुमति समीक्षायोग्य प्रोग्राम शर्तों से तय होती है।

विफलता पथ भी डिज़ाइन करने चाहिए। क्लाइंट केवल टाइमआउट, नेटवर्क त्रुटि, 429 या 5xx पर सीमित पुनःप्रयास करता है; रद्द करने के बाद या turn की समय-सीमा से अधिक उत्तर सीधे छोड़ दिए जाते हैं। यदि enforce मोड में Jev उपलब्ध न हो, तो डाउनग्रेड अनुमति के बिना जारी नहीं रखा जा सकता; llm_only की अनुमति मिलने पर निष्पादक read-only लॉक कर देता है। यदि शाखा में संशोधन हो चुका है और तब Jev खो जाए, तो ऑर्केस्ट्रेटर पूरे दौर को विफल चिह्नित करता है, बजाय इसके कि बाद वाला LLM निर्णय परत के अभाव में लेखन पूरा कर दे। इन पथों की उपयोगकर्ता अनुभव में कीमत है, लेकिन इससे “मॉडल अस्थायी रूप से अनुपलब्ध” चुपचाप “लेखन अनुमति पहले जैसी” नहीं बन जाता।

कैलिब्रेशन रिपोर्ट “कम confidence एस्केलेशन” और “निष्पादन से इनकार” को भी अलग करती है। उदाहरण के लिए एक सही discard, यदि उसका confidence एक समान 0.85 थ्रेशोल्ड तक नहीं पहुँचता, तो उपयोगकर्ता इनपुट आवश्यक के रूप में दर्ज होगा; यह गलत पास करने के बराबर नहीं है। रिपोर्ट इसके आधार पर सुझाव देती है कि सबमिशन और discard के थ्रेशोल्ड अलग किए जाएँ, पर अभी यह सुझाव ही है। लेखन वर्कफ़्लो बनाते समय गलत पास, गलत अस्वीकार और समीक्षा-लंबित—तीनों परिणाम अलग करने होंगे, वरना एक ही डेटा से गलत थ्रेशोल्ड निष्कर्ष निकलेगा।

यह केस बताता है कि Jev और LLM का सहयोग केवल “पहले Jev निर्णय, फिर LLM काम” चित्र से नहीं बताया जा सकता। हर निर्णय में पूछना चाहिए: अनिश्चितता अंतराल कितना चौड़ा है? क्या इससे आगे के प्रोसेसर को कार्य कभी नहीं मिलेगा? यदि इनपुट प्रमाण काटा गया है, तोुमान लगाने के बजाय स्पष्ट एस्केलेशन हो सकता है? हमारे कार्यान्वयन में, state builder evidence_truncated रिकॉर्ड करता है, और कॉलर से अपेक्षा करता है कि प्रमाण-रहित पथ को अनिश्चित माने; गिनती, क्रमबद्धता जैसी नियतात्मक गणनाएँ पहले कोड में पूरी होती हैं, Jev से अनुमान नहीं कराया जाता। आधिकारिक Jev 1.13 ज्ञात सीमाएँ भी सुझाव देती हैं कि गिनती और अंकगणित कोड में ही रखें।

LLM गार्डरेल्स कहाँ रखे जाने चाहिए?

TypeSafe की LLM guardrails cookbook Jev को LLM के इनपुट और आउटपुट दोनों ओर रखती है। यह Noul के एक समूह से विभिन्न जोखिम पहचानती है, Score से गंभीरता मापती है, फिर कोड नीति के अनुसार पास करने, मानव समीक्षा, रोकने या सपोर्ट को स्थानांतरित करने का निर्णय लेता है। आउटपुट भी जाँचना चाहिए, क्योंकि सामान्य इनपुट से भी अनुपयुक्त जनरेट किया गया परिणाम मिल सकता है।

इस प्रकार के गार्डरेल्स की सीमा भी स्पष्ट है: Jev पहले से लिखे प्रश्नों के अनुसार सामग्री जाँच सकता है, लेकिन यह सर्वशक्तिमान सुरक्षा प्रमाण नहीं है। आधिकारिक सीमा दस्तावेज़ स्पष्ट रूप से कहता है कि दुर्भावनापूर्ण सामग्री निर्णय को प्रभावित कर सकती है, इसलिए criteria स्पष्ट लिखें और सीमाएँ परखें। हमारे सिंथेटिक नमूनों में उम्मीदवार पैरामीटरों के विरुद्ध 16 injection probes किए गए, और 0 ranking flips दर्ज हुए; नमूना बहुत छोटा है, इसलिए “प्रॉम्प्ट इंजेक्शन प्रतिरोध हल हो गया” नहीं निकाला जा सकता। टूल वास्तव में क्या कर सकता है, यह अभी भी कोड में allowlist, चरण गेट और सबमिशन-पूर्व जाँच से तय होता है।

कब उपयोग करना उपयुक्त है, कब नहीं?

Jev के लिए उपयुक्त है: उम्मीदवार समुच्चय ज्ञात हो, प्रश्न कुछ छोटे निर्णयों में बाँटे जा सकें, सॉफ़्टवेयर को स्वचालित प्रसंस्करण या मानव एस्केलेशन तय करने के लिए प्रायिकता चाहिए। जैसे ग्राहक सेवा रूटिंग, RAG पैराग्राफ़ छँटाई, Agent उम्मीदवार क्रिया स्कोरिंग, जनरेट किए गए परिणामों में उद्धरण जाँच। यदि कार्य एक उत्तर पत्र लिखना, कोड का एक हिस्सा बदलना या जटिल तर्क समझाना है, तो LLM संभाले। यदि कार्य सटीक पैसा गिनना, तिथियाँ तुलना करना या एक्सेस नियंत्रण जाँचना है, तो प्रोग्राम सीधे गणना करे। मॉडल पृष्ठ यह भी बताता है कि Jev केवल टेक्स्ट स्वीकार करता है, अंग्रेज़ी वर्तमान में सर्वोत्तम प्रदर्शन वाली प्रशिक्षण भाषा है; चीनी परिदृश्यों के लिए अपने डेटा से मूल्यांकन चाहिए, अंग्रेज़ी cookbook के थ्रेशोल्ड सीधे नहीं उठाए जा सकते।

यदि वास्तविक Agent अनुमति और टूल कॉल कैसे संभालता है, यह देखना है, तो पहले PandaNpc एजेंट देखें; कोडिंग Agent की सीमाओं और उपयोग परिदृश्यों के लिए Claude Code बनाम Codex तुलना भी देख सकते हैं।

पाठक एक बहुत छोटे validation set से शुरू कर सकते हैं: “स्पष्ट रूप से स्वचालित रूप से संभालने योग्य”, “स्पष्ट रूप से अस्वीकार करने योग्य”, “अर्थ में अस्पष्ट”, “दुर्भावनापूर्ण निर्देश शामिल” — चार प्रकार के नमूने तैयार करें; पहले मानव लेबल तय करें, फिर Jev के प्रत्येक प्रश्न की प्रायिकता और रूटिंग परिणाम रिकॉर्ड करें। सफलता की कसौटी यह नहीं कि हर आइटम स्वचालित रूप से पास हो, बल्कि यह कि स्वचालित पथ की त्रुटि दर और मानव एस्केलेशन की मात्रा आपके स्वीकार्य दायरे में रहे। यदि अस्पष्ट नमूने बड़ी संख्या में एक ही प्रश्न पर अटकते हैं, तो पहले जाँचें कि प्रश्न में कई निर्णय मिल गए हैं या नहीं, state बहुत लंबा है या नहीं, या थ्रेशोल्ड स्थानीय डेटा पर कैलिब्रेट किया गया है या नहीं।

सामान्य प्रश्न (FAQ)

क्या Jev Claude Code, Codex या चैट मॉडल की जगह ले सकता है? नहीं। TypeSafe इसे सॉफ़्टवेयर के भीतर संरचित निर्णय मॉडल के रूप में रखता है; चैट, लेखन और कोड जनरेशन के लिए अभी भी LLM चाहिए।

वापसी प्रकार तय हैं, तो क्या गलती नहीं होगी? नहीं। तय प्रकार पार्सिंग और सीमा-उल्लंघन आउटपुट की समस्या घटाते हैं, लेकिन वर्गीकरण, स्कोरिंग और तथ्य निर्णय में गलती अभी भी हो सकती है। कम confidence और उच्च जोखिम वाले पथों पर मानव समीक्षा रखनी चाहिए।

एक ही अनुरोध में कितने प्रश्न पूछ सकते हैं? एक ही state साझा करने वाले कई स्वतंत्र Choice, Score, Noul एक अनुरोध में रखे जा सकते हैं। प्रश्न अलग-अलग मूल्यांकित होते हैं, जटिल निर्णय फिर भी अलग करने चाहिए और कोड से संयोजित करने चाहिए।

क्या चीनी भाषा का उपयोग किया जा सकता है? आधिकारिक रूप से कहा गया है कि यह चीनी, जापानी और कोरियाई लिपियों सहित प्राकृतिक भाषाओं का समर्थन करता है, लेकिन अंग्रेज़ी सटीकता इस समय सबसे अच्छी है। चीनी वर्कलोड के लिए अलग सत्यापन और कैलिब्रेशन चाहिए।