शुरुआत उस आउटपुट से करें जिसकी आपको वास्तव में ज़रूरत है
यदि अगले कदम के लिए श्रेणी, मूल्यांकन या हाँ या नहीं की प्रायिकता चाहिए, तो Jev एक विकल्प है जिसका मूल्यांकन किया जा सकता है। यदि अगले कदम के लिए नया पाठ या कोड लिखना है, तो टेक्स्ट बनाने वाला मॉडल उस ज़रूरत को पूरा करता है। Jev का दस्तावेज़ों में वर्णित इंटरफ़ेस मुक्त रूप से टेक्स्ट नहीं लिखता। System One का दस्तावेज़
यह कार्यप्रक्रियाओं की तुलना है, यह दावा नहीं कि कोई एक मॉडल परिवार हर काम में बेहतर है।
| आपका काम | Jev कहाँ काम आ सकता है | कार्यप्रक्रिया को और क्या चाहिए |
|---|---|---|
| सहायता संदेश को उचित जगह भेजना | ज्ञात कतारों में से चुनाव | आवंटन के नियम और समीक्षा का रास्ता |
| जवाब का मसौदा लिखना | मसौदे को दिए गए मानदंडों पर परखना | टेक्स्ट बनाने वाला मॉडल या स्वीकृत टेम्पलेट |
| लेखों की प्राथमिकता तय करना | अपने मानदंडों के अनुसार प्रासंगिकता या उपयोगिता आँकना | खोज, दोहराव हटाना और स्रोतों के लिंक |
| रिपोर्ट बनाना | अलग-अलग, स्पष्ट रूप से परिभाषित पहलुओं का मूल्यांकन | शोध, जानकारी का संयोजन और टेक्स्ट लेखन |
| उपलब्ध कार्रवाई चुनना | सीमित सूची से क्रम तय करना या चुनाव करना | अनुमतियों की जाँच और कार्रवाई चलाने वाला कोड |
| लिखित नियम के अनुसार पुल अनुरोध जाँचना | अर्थ से जुड़ी संभावित समस्या चिह्नित करना | कंपाइलर, परीक्षण, सामान्य लिंट नियम और समीक्षक |
| RAG उत्तर के लिए खोजे गए अंश छाँटना | साक्ष्य और विरोधों का आकलन | खोज, स्रोत तक पहुँच की जाँच और टेक्स्ट बनाने वाला मॉडल |
| सुरक्षा चेतावनी की प्राथमिक छँटाई करना | समीक्षा के लिए एक संकेत जोड़ना | स्थापित पहचान प्रणालियाँ, विश्लेषक की जाँच और अनुमति |
| सटीक कुल निकालना | आम तौर पर आवश्यक नहीं | निश्चित नियमों पर आधारित गणना |
ये काम चुनने के लिए हमारी सिफ़ारिशें हैं। उत्पादन प्रणाली की रूपरेखा चुनने से पहले वास्तविक मॉडल, प्रॉम्प्ट और अनुप्रयोग की आवश्यकताओं का मूल्यांकन करें।
संरचित आउटपुट ही पूरी तुलना नहीं है
टेक्स्ट बनाने वाले मॉडल को भी संरचित आउटपुट की शर्तों के साथ जोड़ा जा सकता है; TypeSafe की अपनी लॉन्च सामग्री स्वीकार करती है कि LLM तय डेटा प्रकारों वाले संरचित मान लौटा सकते हैं। Jev का प्रस्ताव यह है कि मॉडल को शुरू से ही सीमित निर्णयों और प्रायिकताओं को केंद्र में रखकर बनाया गया है। लॉन्च की व्याख्या
फिर भी दो अलग परीक्षण आवश्यक हैं:
- इंटरफ़ेस की शुद्धता: क्या अनुप्रयोग आउटपुट का भरोसेमंद ढंग से उपयोग कर सकता है?
- निर्णय की गुणवत्ता: क्या वह आउटपुट दिए गए साक्ष्य के आधार पर सही आकलन दर्शाता है?
एक वैध सूची से technical चुनना पहला परीक्षण पूरा करता है। ऐसे संदेश के लिए इसे चुनना जिसे बिलिंग टीम के पास जाना चाहिए, दूसरे परीक्षण में विफल होता है।
गति और लागत के दावों को कैसे पढ़ें
TypeSafe अपनी लॉन्च तुलनाओं में बड़े सुधार बताता है। उसका मूल्यांकन चार बनाई गई कार्यप्रक्रियाओं का औसत लेता है और संदर्भ लेबल के रूप में दूसरे मॉडलों के सहमति वाले आउटपुट इस्तेमाल करता है। ये संदर्भ तुलना की एक पद्धति हैं, स्वतंत्र रूप से स्थापित व्यावसायिक परिणाम नहीं। मूल्यांकन पद्धति
लॉन्च लेख सीमाएँ भी बताता है: कार्यप्रक्रियाएँ टीम ने बनाई थीं, तुलना की सेटिंग परिणामों को प्रभावित करती हैं और छोटे इनपुट वाला एक प्रदर्शन Jev की सैंपलिंग पद्धति के अनुकूल था। प्रकाशित संख्याओं को उन्हीं परिस्थितियों में विक्रेता के प्राप्त परिणाम मानें। इस साइट ने उन्हें स्वतंत्र रूप से दोहराया नहीं है। लॉन्च दावों की शर्तें
अपनी तुलना में इनपुट के उदाहरण और सफलता के मानदंड समान रखें। शुरुआत से अंत तक लगने वाला समय, स्वीकार्य निर्णय, अनिश्चित मामले और कुल खर्च दर्ज करें। यदि आपका वर्तमान गैर-AI तरीका भी वही समस्या हल कर सकता है, तो उसे भी तुलना में शामिल करें।
काम की प्रकृति अलग हो तो मॉडल साथ इस्तेमाल करें
कोई सहायता अनुप्रयोग Jev से अनुरोध का वर्गीकरण करा सकता है, सामान्य कोड से संबंधित नीति ला सकता है और टेक्स्ट बनाने वाले मॉडल से जवाब का मसौदा लिखवा सकता है। उसके बाद एक और जाँच यह चिह्नित कर सकती है कि मसौदा अनुरोध को संबोधित करता है या नहीं, और ज़रूरत होने पर कोई व्यक्ति उसकी समीक्षा कर सकता है।
TypeSafe इससे संबंधित आशय के अनुसार रूटिंग का पैटर्न बताता है, जिसमें वर्गीकरण के बाद कोड अलग-अलग हैंडलर चुनता है। ऊपर दी गई विशिष्ट कार्यप्रक्रिया संरचना का सुझाव है, इस वेबसाइट की ओर से उपलब्ध कराया गया परीक्षित एकीकरण नहीं।
कार्रवाई से पहले अपने अनुप्रयोग की अनुमति जाँचें लागू करें। मॉडल द्वारा किसी टूल का चयन उस टूल के डेटा तक पहुँच या उससे होने वाले बदलावों की अनुमति नहीं देता।
जब सरल टूल बेहतर हो
जब नियम पहले से सटीक हों, तो हूबहू मिलान, गणना, तारीखें, अनुमतियाँ और ज्ञात अवस्था परिवर्तन सामान्य कोड में रखें। प्रायिकता पर आधारित निर्णय जोड़ने से विफलता का एक और रास्ता और संचालन के लिए एक और निर्भरता जुड़ती है।
जहाँ अंतर भाषा के अर्थ में हो, वहाँ Jev का मूल्यांकन करें: क्या दो विवरण एक ही समस्या बताते हैं, क्या साक्ष्य किसी प्रश्न को संबोधित करता है, या कई अच्छी तरह परिभाषित रास्तों में कौन-सा सबसे उपयुक्त है। जहाँ नया पाठ, कोड या जानकारी का संयोजन तैयार करना हो, वहाँ टेक्स्ट बनाने वाला मॉडल इस्तेमाल करें। इन टूल को जोड़ना तभी उपयोगी है जब हर चरण अंतिम परिणाम में इतना सुधार करे कि उसकी अतिरिक्त जटिलता उचित हो।
एक छोटी तुलना जिसे आप पूरा कर सकें
बार-बार आने वाला एक निर्णय चुनें और अपेक्षित परिणामों के साथ उदाहरणों का संग्रह तैयार करें। केवल स्पष्ट उदाहरण नहीं, अस्पष्ट मामले भी शामिल करें। एक समान समीक्षा नीति के तहत बुनियादी नियमों वाले क्रियान्वयन, अपने वर्तमान मॉडल, यदि आप कोई इस्तेमाल करते हैं, और Jev की तुलना करें।
उन गलतियों को देखें जो उत्पाद के लिए मायने रखती हैं। किसी तात्कालिक टिकट का छूट जाना और किसी मामले को अनावश्यक रूप से उच्च स्तर की समीक्षा के लिए भेज देना, दोनों की लागत अलग है; समग्र सटीकता का एक अंक यह अंतर छिपा सकता है। सीमा-मान बदलने से पहले तय करें कि आप कौन-सी त्रुटियाँ स्वीकार कर सकते हैं।
सहायता का विस्तृत उदाहरण देखें, पहले अनुरोध की मार्गदर्शिका अपनाएँ और तुलना में खर्च जोड़ने के लिए मूल्य कैलकुलेटर का उपयोग करें।
स्रोत और आगे की पढ़ाई
यह मार्गदर्शिका आधिकारिक दस्तावेज़ों और लिंक की गई सामुदायिक रिपोर्टों पर आधारित है। समुदाय के अवलोकनों का श्रेय उनके लेखकों को दिया गया है।
- System One की क्षमताएँ
- Jev के लॉन्च दावे और उनकी शर्तें
- TypeSafe की कार्यप्रक्रिया मूल्यांकन पद्धति
- आशय के अनुसार रूटिंग का पैटर्न