Dikaya Pro में लंबे दस्तावेजों की तुलना कैसे व्यवस्थित करें

न्यूनतम API उदाहरण

समझाने वाला Python कोड, वास्तविक मॉडल उत्तर नहीं। कुंजी वातावरण से ली जाती है और अपने-आप दोहराना बंद है। कनेक्शन टूटने पर परिणाम और खर्च दोनों अज्ञात रह सकते हैं; बिना जाँच दोबारा न भेजें।

import os
from openai import OpenAI

client = OpenAI(
    base_url="https://dikaya.cc/v1",
    api_key=os.environ["DIKAYA_API_KEY"],
    max_retries=0,
)
response = client.chat.completions.create(
    model="seller-pro",
    max_tokens=512,
    messages=[{"role": "user", "content": "मेरे काम के लिए जाँच सूची बनाओ। स्रोत के तथ्यों और धारणाओं को अलग रखो।"}],
)
print(response.choices[0].message.content)

तुलना का उद्देश्य पाठक के निर्णय से जोड़ें

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

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

तुलना से पहले पाठ का नक्शा बनाएँ

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

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

हर जरूरी शर्त को अलग पंक्ति दें

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

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

वापस जाकर नई जोड़ी गई शर्तें खोजें

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

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

बड़े संदर्भ को असीमित आयात न मानें

Dikaya Pro एक अलग ब्रांडेड स्तर है; इसकी आधार मॉडल पहचान यहाँ निर्दिष्ट नहीं है। Pro 2 की स्वीकृत GLM-5.3 पृष्ठभूमि या दूसरे मॉडलों के low, high, max नियंत्रण इस पर न लगाएँ। संदर्भ, अनुरोध का आकार और उत्तर की सीमा अलग नियंत्रण हैं। पूर्ण तुलना का आउटपुट बड़ा हो सकता है, इसलिए जरूरत हो तो अध्यायवार तालिकाएँ बनाएँ और अंत में कवरेज रजिस्टर से उनका मिलान करें।

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

स्वीकार करने से पहले स्रोत और नेटवर्क स्थिति जाँचें

उत्तर की हर महत्वपूर्ण पंक्ति मूल दस्तावेज में खोलें और अनिवार्य शर्तों की गिनती से कवरेज मिलाएँ। भुगतान वाले ब्राउज़र की स्पष्ट खोज बाहरी संदर्भ ला सकती है, लेकिन वह स्कूल की स्वीकृत नीति नहीं बनती। सार्वजनिक API को वही इंटरनेट टूल प्राप्त मानना गलत होगा। अंतिम संदेश में बची अस्पष्टताओं और स्वीकृति देने वाले व्यक्ति को दर्ज करें; केवल «दोनों मेल खाते हैं» जैसा निष्कर्ष पर्याप्त नहीं है।

मसौदा चैट में भेजने से पहले seller-pro की अनुमति और वास्तविक चयन देखें; पुराना सहेजा मसौदा प्राथमिक हो सकता है। डेमो सभी मॉडल नहीं खोलता। SDK में max_retries=0 और स्पष्ट आउटपुट सीमा रखें। ज्ञात HTTP अस्वीकृति तथा अज्ञात नेटवर्क परिणाम अलग हैं। कनेक्शन टूटने से शून्य खर्च साबित नहीं होता; स्थिति देखने के बाद ही किसी बचे अध्याय के लिए हाथ से नया अनुरोध तय करें।

सवाल और जवाब

क्या लंबे संदर्भ का अर्थ है कि पूरा दस्तावेज हमेशा भेजा जाएगा?

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

उल्लेख नहीं मिला और विरोध में क्या अंतर है?

उल्लेख नहीं मिला का अर्थ है कि दिए गए पाठ में संबंधित पुष्टि नहीं मिली। विरोध तब है जब दो कथन एक साथ लागू होने पर अलग या असंगत परिणाम देते हैं। छोटी सूचना में कुछ विवरण जानबूझकर छूट सकते हैं। अनिवार्य बिंदु पहले निर्धारित करें, फिर अनुपस्थिति को बिना कारण गलती घोषित करने के बजाय समीक्षा करें।

क्या Pro की आधार पहचान और effort स्तर ज्ञात हैं?

इस मार्गदर्शिका में Pro को स्वतंत्र ब्रांडेड स्तर माना गया है, जिसकी आधार पहचान निर्दिष्ट नहीं है। Pro 2 की पृष्ठभूमि या अन्य ID के effort विकल्प यहाँ लागू न करें। seller-pro के दस्तावेज में समर्थित पैरामीटर ही उपयोग करें और वर्तमान खाते की अनुमति तथा सीमाएँ भेजने से पहले जाँचें।

बीच में रुकी तुलना को कैसे जारी रखें?

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

स्रोत

यह सामग्री AI की सहायता से तैयार की गई है। उदाहरण समझाने के लिए हैं, वास्तविक मॉडल उत्तर या तुलनात्मक परीक्षण नहीं। बाहरी स्रोत सेवा की शर्तों की जगह नहीं लेते।

• Dikaya मॉडल सूची: Pro की घोषित जानकारी
  dikaya.cc
• Dikaya API दस्तावेज: संदर्भ और क्लाइंट सीमाएँ
  dikaya.cc
• OpenAI Python: त्रुटियाँ और दोहराव की सेटिंग
  github.com
• MDN: Fetch में HTTP और नेटवर्क का अंतर
  developer.mozilla.org