हिन्दी AI उत्तर की जाँच: शब्द, मात्राएँ और तथ्य

पहले उत्तर के लिए तथ्य-सूची बनाएँ

मान लीजिए किसी कार्यशाला की सूचना तैयार करनी है। स्रोत में तारीख 18 नवंबर, समय सुबह 10 बजे, स्थान कक्ष 204 और शुल्क ₹750 है। पहले इन चार बातों की सूची बनाएँ। यदि सीटों की संख्या, वापसी नीति या प्रमाणपत्र का उल्लेख नहीं है, तो उन्हें “जानकारी नहीं दी गई” लिखें। मॉडल से सुन्दर विज्ञापन माँगने पर वह आकर्षक लगने वाले ऐसे विवरण जोड़ सकता है जो स्रोत में हैं ही नहीं।

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

देवनागरी में जो दिखता है, वह हमेशा एक code point नहीं होता

देवनागरी में व्यंजन, मात्रा, नुक्ता और अन्य चिह्न मिलकर दृश्य इकाई बना सकते हैं। इसलिए Python का len(text), स्क्रीन पर दिखने वाले अक्षरों की संख्या और UTF-8 बाइट की संख्या अलग हो सकती हैं। किसी फ़ॉर्म की सीमा को “100 अक्षर” कहना अस्पष्ट है, जब असल में सर्वर 100 बाइट गिन रहा हो।

नुक्ते वाले अक्षरों के कुछ रूप अलग Unicode अनुक्रमों से लिखे जा सकते हैं। वे देखने में समान लग सकते हैं, लेकिन सीधी string तुलना में अलग हो सकते हैं। Unicode normalization कुछ canonical रूपों को एक समान प्रस्तुति में लाता है। उसे केवल तुलना या खोज की स्पष्ट नीति के लिए इस्तेमाल करें; ग्राहक का मूल नाम या जमा किया हुआ पाठ बिना कारण न बदलें।

import unicodedata

a = "क़"
b = "क़"

print(a == b)
print(unicodedata.normalize("NFC", a) ==
      unicodedata.normalize("NFC", b))

text = "हिन्दी"
print("code points:", len(text))
print("UTF-8 bytes:", len(text.encode("utf-8")))
for char in text:
    print(f"U+{ord(char):04X}", unicodedata.name(char, "UNKNOWN"))

Normalization को वर्तनी-सुधार समझने की गलती न करें

NFC यह तय नहीं करता कि “हिंदी” या “हिन्दी” में कौन-सा रूप आपकी शैली-पुस्तिका के लिए उचित है। वह किसी व्यक्ति का नाम, गलत तारीख या छूटा हुआ नकार भी नहीं सुधारता। NFKC compatibility normalization और अधिक रूपों को मिला सकता है, इसलिए पहचान, प्रदर्शन या संपादकीय पाठ पर उसका उपयोग सोचकर करें। तकनीकी समानता और भाषाई समानता अलग निर्णय हैं।

यदि खोज प्रणाली में normalized रूप रखना हो, तो मूल पाठ भी सुरक्षित रखें और नीति लिखें: खोज के लिए NFC, प्रदर्शन के लिए मूल पाठ। एक ही रूप को बार-बार लागू करने पर अनपेक्षित बदलाव तो नहीं होता, इसे परीक्षण में देखें। समस्या दिखे तो केवल स्क्रीनशॉट पर निर्भर न रहें; code point सूची देखकर वास्तविक पाठ की तुलना करें।

मॉडल से केवल अनुवाद नहीं, जाँचने योग्य संपादन माँगें

पाठक और काम स्पष्ट करें: विद्यालय की सूचना, उत्पाद सहायता या तकनीकी लेख की भाषा एक जैसी नहीं होती। तकनीकी शब्दों के लिए छोटा शब्दकोश दें। यदि API, token और UTF-8 को मूल रूप में रखना है, तो यह पहले लिखें। हर शब्द का भारी हिन्दी पर्याय बनाना पठनीयता का प्रमाण नहीं है।

इस नमूने में उत्तर को तीन भागों में माँगा गया है। पहला भाग तथ्य-जाँच को आसान बनाता है, दूसरा प्रकाशित करने योग्य मसौदा देता है, तीसरा अनिश्चितता बचाकर रखता है। मॉडल से यह भी कहें कि स्रोत में न मिलने वाली बात को प्रश्न की तरह रखे, अनुमान को सूचना में न बदल दे।

इस सूचना को सरल हिन्दी में संपादित करें।
पाठक: कार्यशाला में पहली बार आने वाले प्रतिभागी।
तथ्य नहीं बदलने हैं:
- तारीख: 18 नवंबर
- समय: सुबह 10 बजे
- स्थान: कक्ष 204
- शुल्क: ₹750

उत्तर के तीन भाग दें:
1. मूल तथ्य-सूची
2. संपादित सूचना
3. जिन बातों की जानकारी नहीं है, उनके प्रश्न

सीटें, प्रमाणपत्र या वापसी नीति न गढ़ें।
मूल पाठ:

चैट और फ़ाइल में बाइट सीमा अलग से जाँचें

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

बड़ी सामग्री को शीर्षक और स्थिर अनुच्छेद संख्या के साथ हिस्सों में बाँटें। मात्रा या संयुक्त अनुक्रम के बीच काटने वाली मनमानी बाइट slicing से बचें। फ़ाइल पढ़ते समय decoding त्रुटि को चुपचाप हटाना मूल सामग्री बदल सकता है; त्रुटि पर रुकें और फ़ाइल की encoding ठीक करें। पहले छोटे अंश से काम की गुणवत्ता जाँचें, फिर दायरा बढ़ाएँ।

प्रकाशन से पहले आखिरी चार जाँच

एक बार पूरा पाठ आवाज़ में पढ़ें। फिर केवल नाम, तारीखें, रकम और इकाइयाँ पढ़ें। तीसरे चरण में नकार और शर्तें देखें: “नहीं”, “यदि”, “तक” और “लगभग” हटने से अर्थ बदल सकता है। अंत में जिस जगह पाठ प्रकाशित होना है, वहाँ कॉपी करके जाँचें कि पंक्तियाँ, लिंक और देवनागरी सही दिख रही हैं।

खोज से मिली जानकारी का मूल पृष्ठ खोलें और उसकी तारीख देखें। AI द्वारा दिया गया उद्धरण स्वयं प्रमाण नहीं है। संशोधित पाठ, तथ्य-सूची और स्रोत साथ रखने से अगली बार बदलाव जाँचना आसान होता है। अच्छा हिन्दी AI उत्तर केवल स्वाभाविक नहीं लगता; उसके महत्वपूर्ण दावे और तकनीकी रूप दोनों जाँचे जा सकते हैं।

सवाल और जवाब

क्या len(text) से हिन्दी के दिखाई देने वाले अक्षर गिन सकते हैं?

ज़रूरी नहीं। Python string में len code point गिनता है। मात्रा और अन्य चिह्न दृश्य इकाई का हिस्सा हो सकते हैं। UTF-8 बाइट गिनने के लिए len(text.encode("utf-8")) अलग गणना है। फ़ॉर्म या फ़ाइल की सीमा किस इकाई में है, यह स्पष्ट करें।

क्या NFC से गलत हिन्दी अपने आप ठीक हो जाती है?

नहीं। NFC Unicode के canonical रूपों को सामान्य करने की प्रक्रिया है, भाषा-संपादन या तथ्य-जाँच नहीं। वह गलत नाम, तारीख, व्याकरण या बदला अर्थ नहीं पकड़ता। मूल पाठ सुरक्षित रखें और normalization का उपयोग स्पष्ट तुलना या खोज नीति के अनुसार करें।

क्या अच्छा लिखा हुआ AI उत्तर बिना जाँच प्रकाशित कर सकते हैं?

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

स्रोत

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

• Python unicodedata: normalization और नाम
  docs.python.org
• MDN TextEncoder: UTF-8 encoding
  developer.mozilla.org