Jev का उपयोग किन कामों में कर सकते हैं?

मॉडल चुनने से पहले निर्णय पहचानें

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

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

सामुदायिक उदाहरण: डेवलपर Jev का उपयोग कैसे करते हैं

इन सार्वजनिक विवरणों में वे विशिष्ट निर्णय कार्य हैं जिन्हें डेवलपर ने वास्तव में आज़माया है। हर सारांश में लेखक के मूल विवरण का लिंक है। यहाँ शामिल होने का अर्थ यह नहीं कि TypeSafe या संबंधित टीम इस वेबसाइट का समर्थन करती है।

आधिकारिक Playground में लेखन जाँच आज़माएँ

यह हमारा मौलिक, काल्पनिक शिक्षण उदाहरण है; इसमें मॉडल के रन का परिणाम नहीं है। लेखन समीक्षा के उपयोग से प्रेरित यह एक अलग अभ्यास है, Every का प्रॉम्प्ट या उसके प्रयोग की पुनरावृत्ति नहीं। Orbit Notes एक काल्पनिक उत्पाद है। आसानी से कॉपी करने के लिए सभी भाषाओं में इनपुट और प्रश्न एक ही अंग्रेज़ी पाठ में दिए गए हैं।

आधिकारिक Playground खोलें

यह TypeSafe का बाहरी पृष्ठ खोलता है। अपने खाते से साइन इन करें और सुनिश्चित करें कि आवश्यक पहुँच मिली है। केवल प्रतीक्षा सूची में नाम होने से पहुँच नहीं मिलती।

1. नीचे का उदाहरण state फ़ील्ड में पेस्ट करें।

2. नीचे दिए नामों और निर्देशों से तीन Noul प्रश्न जोड़ें। state और प्रश्न दर्ज करने का तरीका आधिकारिक क्विकस्टार्ट में है।

3. आधिकारिक Playground में अनुरोध चलाएँ। हर प्रश्न के साथ लौटाई गई प्रायिकता पढ़ें, फिर ज़रूरत हो तो उदाहरण बदलकर दोबारा चलाएँ।

काल्पनिक इनपुट

Orbit Notes saves your drafts locally.
Your drafts are stored on your device.
Click Export to download a copy.

दर्ज करने के प्रश्न

repetition (Noul)
Does the text repeat a claim without adding new information?

clear_action (Noul)
Does the text explain what happens when the reader clicks Export?

guaranteed_safety (Noul)
Does the text claim that a draft can never be lost?

देखें कि पहले दो वाक्य अलग जानकारी जोड़ते हैं या नहीं, Export पर क्लिक करने का परिणाम समझाया गया है या नहीं, और क्या पाठ ड्राफ़्ट कभी न खोने का वादा करता है। प्रश्न स्वतंत्र हैं; उनकी प्रायिकताओं का योग एक होना ज़रूरी नहीं। निर्णयों को मानवीय समीक्षा के संकेत मानें। इस अभ्यास में अपेक्षित स्कोर या स्वचालित निर्णय की सीमा नहीं दी गई है।

चार भूमिकाएँ, शुरुआत के चार रास्ते

डेवलपर: अर्थ से जुड़े किसी नियम की समीक्षा करें

कोई सीमित, स्पष्ट लिखित नियम आज़माएँ जिसे सामान्य लिंट जाँच नहीं पकड़ती: क्या कोई बदलाव उपयोगकर्ता को दिखने वाली ऐसी त्रुटि जोड़ता है जिसमें उबरने का तरीका नहीं बताया गया है? संबंधित कोड अंतर और नियम दें, और समीक्षा के लिए संकेत प्राप्त करें। उपयोगों का आधिकारिक मानचित्र अर्थ के आधार पर कोड लिंटिंग शामिल करता है; यह विशेष जाँच हमारा समझाने के लिए दिया गया प्रस्ताव है।

कंपाइलर, परीक्षण समूह और सटीक लिंट नियम बनाए रखें। समीक्षक को चिह्नित पंक्तियाँ देखकर तय करने दें कि चिंता उचित है या नहीं। शुरुआत सलाह वाले कमेंट से करें, ताकि जाँच को मर्ज की शर्त बनाने से पहले आप गलत चेतावनियों की लागत समझ सकें। यह एक सुझाया गया एकीकरण है, इस वेबसाइट से मिलने वाला तैयार PR बॉट नहीं।

सहायता टीमें: ज़िम्मेदारी और तात्कालिकता अलग रखें

परेशान ग्राहक को इंजीनियरिंग के बजाय बिलिंग टीम की ज़रूरत हो सकती है। शांत दिखने वाला संदेश किसी तात्कालिक सेवा-बाधा का वर्णन कर सकता है। संदेश कहाँ जाए और समय की दृष्टि से वह कितना तात्कालिक है, ये प्रश्न अलग-अलग पूछें, फिर कतार की नीति लागू करें। आधिकारिक त्वरित शुरुआत में नीचे दिया गया टिकट उदाहरण है।

खाते से जुड़े तथ्य जुटाना, दोहराए गए टिकट हटाना और धनवापसी या खाते में बदलाव के नियम लागू करना अब भी आपके अनुप्रयोग का काम है। वर्गीकरण इस बात की पुष्टि नहीं करता कि बताई गई विफलता वास्तव में हुई थी।

खोज और RAG टीमें: लिखने से पहले साक्ष्य चुनें

पुनर्प्राप्त जानकारी की सहायता से टेक्स्ट निर्माण, यानी RAG, खोजी गई सामग्री टेक्स्ट बनाने वाले मॉडल को देता है। जानकारी खोजने और उत्तर लिखने के बीच Jev का मूल्यांकन किया जा सकता है। TypeSafe का RAG अंशों वाला उदाहरण प्रासंगिकता, उपयोग योग्य साक्ष्य, विरोधाभास और निर्देश देने की कोशिशों को अलग-अलग जाँचता है, फिर कोड से किसी अंश को शामिल, चिह्नित या बाहर करता है।

आकलन के साथ स्रोत का पहचानकर्ता रखें। विरोधी साक्ष्य को चुपचाप हटाने के बजाय उसके बारे में स्पष्ट चेतावनी दिखाना उचित हो सकता है। जाँचें कि कहीं आपका फ़िल्टर किसी कठिन प्रश्न का उत्तर देने के लिए ज़रूरी एकमात्र अंश तो नहीं हटा देता। अंतिम शब्दों की ज़िम्मेदारी अब भी टेक्स्ट बनाने वाले मॉडल की है; किसी भी चरण को दस्तावेज़ की पहुँच संबंधी अनुमतियाँ दरकिनार नहीं करनी चाहिए।

सुरक्षा टीमें: विश्लेषकों का ध्यान सही मामलों पर लगाएँ

TypeSafe का सुरक्षा जाँचों वाला उदाहरण आने वाले संदेशों और बनाए गए उत्तरों की जाँच दिखाता है, जिसमें ख़तरों की प्रायिकताएँ और गंभीरता का क्रमबद्ध आकलन मिलता है। इसके बाद कोड प्रतिक्रिया की नीति लागू करता है।

शुरुआती एकीकरण में अपनी वर्तमान पहचान प्रक्रिया बनाए रखें और प्रस्तावित समीक्षा कतार की तुलना विश्लेषकों के निर्णयों से करें। छूटी हुई घटनाओं और अनावश्यक रूप से आगे समीक्षा के लिए भेजे गए मामलों को अलग-अलग दर्ज करें। मॉडल का कम स्कोर किसी टूल को अनुमति न दे, किसी मौजूदा नियंत्रण को बंद न करे और न ही यह स्थापित करे कि कोई संलग्न फ़ाइल हानिरहित है। दुर्भावनापूर्ण इनपुट से जुड़ी सीमाएँ देखें।

पूरा उदाहरण: दस्तावेज़ में उत्तर खोजना

1. काम और इनपुट

उदाहरण में दिए GitHub Terms of Service के टेक्स्ट में jev-1.12 से खोज करें: इसमें पहचानकर्ताओं वाली 218 पंक्तियाँ हैं। उदाहरण और पूरी स्क्रिप्ट में संपूर्ण इनपुट का लिंक और पहले से दर्ज परिणाम दोहराने की व्याख्या है।

2. प्रश्न

एक अनुरोध में where पूछा जाता है, जो पंक्ति पहचानकर्ताओं पर Choice है, और exists, जो Noul प्रश्न है: क्या दस्तावेज़ में उत्तर मौजूद है?

3. प्रकाशित आउटपुट का अंश

ये चुनिंदा मान हैं, पूरा API उत्तर नहीं:

query: who owns the code I upload?
exists: 0.98
L052: 0.95

मिली हुई स्रोत पंक्ति इस तरह शुरू होती है: L052 | You own Your Content.

4. परिणाम के बाद की प्रक्रिया

यह उदाहरण पंक्तियों की प्रायिकताओं को क्रम में रखता है और पहचानकर्ताओं को दोबारा स्रोत टेक्स्ट से जोड़ता है। उत्तर मौजूद होने की उसकी नीति कम से कम 0.7 वाले मान को उत्तर मौजूद, 0.35 से कम को अनुपस्थित और बीच के अंतराल को आंशिक मानती है। इसलिए यह उदाहरण L052 की ओर संकेत करता है और उत्तर की मौजूदगी की जाँच में पास होता है।

5. सीमाएँ और स्रोत

ये सीमा-मान और पुराना मॉडल संस्करण इसी उदाहरण के हैं। दर्ज परिणाम दोबारा दिखाना नया मापन नहीं है। यह जानकारी खोजना दिखाता है, कानूनी व्याख्या या दूसरे दस्तावेज़ों पर सटीकता नहीं। मूल उदाहरण और प्रदर्शित आउटपुट

दो संकेत क्यों इस्तेमाल करें?

Choice दिए गए विकल्पों के बीच प्रायिकता बाँटता है, जिनका कुल योग एक होता है। इसलिए सबसे आगे का विकल्प सापेक्ष रूप से विजेता है; यह इस बात की स्वतंत्र गारंटी नहीं कि कोई उपयुक्त विकल्प मौजूद है। TypeSafe अधिकतम 255 Choice विकल्पों का उल्लेख करता है। Choice का अर्थ और सीमाएँ

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

इस रूपरेखा को अपनाते समय अपनी समीक्षा के उदाहरणों में ऐसे दस्तावेज़ शामिल करें जिनमें उत्तर नहीं है। कई पंक्तियों में फैले उत्तर और ऐसे प्रश्न भी शामिल करें जिनकी भाषा में कोई गलत मान्यता छिपी हो। ये मामले केवल यह देखने से आगे जाते हैं कि पहले स्थान की पंक्ति विश्वसनीय लगती है या नहीं; इनसे उस खोज नीति की जाँच होती है जिसकी आपको वास्तव में ज़रूरत है।

पूरा उदाहरण: सहायता टिकट की प्राथमिक छँटाई

इनपुट, प्रश्न और दस्तावेज़ में दिया गया आउटपुट

नमूने में ग्राहक तीन दिनों से विफल Stripe कनेक्शन, बिक्री के नुकसान और तुरंत मदद की ज़रूरत बताता है। अनुरोध विभाग, परेशानी के स्तर और तात्कालिकता के बारे में पूछता है। यहाँ संदेश का भावानुवाद दिया गया है।

स्रोत: त्वरित शुरुआत का अनुरोध और उत्तर।

परिणाम को प्रस्ताव में बदलें

नीचे हमारा समझाने के लिए लिखा गया कोड है। इसके सीमा-मान नीति के उदाहरण हैं, सत्यापित सेटिंग नहीं:

function proposeRoute(response) {
  const department = response.answers.department;
  const urgency = response.answers.is_urgent.noul;

  return {
    queue: department.confidence >= 0.7
      ? department.choice
      : "manual-triage",
    priority: urgency >= 0.9 ? "urgent" : "normal",
    suggestedTeam: department.choice,
  };
}

प्रकाशित मानों के लिए यह फ़ंक्शन तत्काल मानवीय छँटाई का प्रस्ताव देता है और तकनीकी सहायता सुझाता है। सबसे आगे का विभाग हमारे चुने हुए विश्वास-मान की सीमा को पार नहीं करता। इस उदाहरण से वास्तव में किसी टिकट का आवंटन नहीं होता।

प्रायिकता और विश्वास-मान अलग फ़ील्ड हैं। TypeSafe, Choice और Score का विश्वास-मान वितरण से निकालता है; Noul में विश्वास-मान का अलग फ़ील्ड नहीं होता। विश्वास-मान का दस्तावेज़

ऐसे प्रस्ताव को टिकट प्रणाली से जोड़ने से पहले उत्तर सत्यापित करें, विरोधों को सुलझाने का तरीका परिभाषित करें और विफलताओं को देखने योग्य बनाएँ। गलत जगह भेजे गए और छूट गए तात्कालिक टिकटों का मूल्यांकन अलग-अलग करें। यह नमूना ग्राहक के खाते की स्थिति स्थापित नहीं करता और न ही एकीकरण की समस्या हल करता है।

समुदाय की रिपोर्ट: फ़िशिंग ईमेल की प्राथमिक छँटाई का प्रयोग

एक Discord सहभागी ने 17 सितंबर 2026 को 14:24–14:27 UTC पर शुरुआती Python SDK प्रयोग का वर्णन किया। उनका उद्देश्य सुरक्षा संचालन में मदद करना और बाद में उसे SOAR कार्यप्रक्रिया से जोड़ना था। उन्होंने शुरुआती परिणामों को उत्साहजनक बताया और कहा कि परिणाम मानदंडों की शब्दावली तथा विस्तार के प्रति संवेदनशील थे। प्रयोग का परिचय, बाद के अवलोकन

यह समुदाय के सहभागी की अपनी रिपोर्ट है। इससे पहचान की सटीकता, गलत सकारात्मक परिणामों की दर, गति, बचत, हर बार एक जैसा व्यवहार या उत्पादन प्रणाली में एकीकरण स्थापित नहीं होता। हमने इसे दोहराया नहीं है। सुरक्षित की गई बातचीत में कोई सत्यापित आधिकारिक उत्तर दिखाई नहीं दिया; शोध में चुनी हुई चर्चाएँ शामिल थीं, समुदाय का पूरा इतिहास नहीं। लिंक खोलने के लिए समुदाय तक पहुँच आवश्यक हो सकती है।

एक अगला कदम चुनें

ऐसा एक निर्णय चुनें जिसका परिणाम जाँचा जा सके और जिसकी समीक्षा प्रक्रिया सँभालने योग्य हो। पहुँच पाने और अनुरोध भेजने से शुरुआत करें, मूल्य मार्गदर्शिका से पूरी प्रक्रिया का बजट बनाएँ और आउटपुट को स्वचालित कार्रवाइयों से जोड़ने से पहले सीमाएँ पढ़ें।