प्रश्न पत्र बनाना देखने में जितना सीधा लगता है, उसकी शर्तें उतनी ही सख़्त हैं। पेपर में सही अध्याय शामिल करने हैं, सही कुल अंक तक पहुँचना है, बोर्ड के अपेक्षित पैटर्न में sections के बीच अंक बाँटने हैं, कठिनाई का संतुलन रखना है, और वह सब दोहराने से बचना है जो उसी कक्षा ने पिछले यूनिट टेस्ट में देख लिया था। इनमें से एक भी चूका, तो पेपर वापस आ जाता है।
ज़्यादातर स्कूल सॉफ्टवेयर इसमें आख़िरी पाँच प्रतिशत में मदद करते हैं — formatting और छपाई — और मुश्किल हिस्सा किसी वरिष्ठ शिक्षक और एक Word फ़ाइल के भरोसे छोड़ देते हैं।
Blueprint का पालन ही असली मुश्किल है
Blueprint दरअसल कई शर्तें एक साथ लागू करना है। Section A में एक-एक अंक के बीस वस्तुनिष्ठ प्रश्न चाहिए। Section B में तीन-तीन अंक के पाँच लघु उत्तर। कुछ पैटर्न में Section C एक ही section के भीतर पाँच अंक और दस अंक के प्रश्न मिलाता है। इन सबके ऊपर, पेपर मोटे तौर पर एक-तिहाई आसान, एक-तिहाई मध्यम और एक-तिहाई कठिन होना चाहिए, और जो अध्याय कवर किए जाएँ वे वही हों जो कक्षा में सचमुच पढ़ाए गए हैं।
इसे हाथ से भरने का मतलब है प्रश्नों की सूची scroll करते हुए दिमाग़ में छह शर्तें एक साथ थामे रखना। यह ठीक वैसा काम है जो इंसान के लिए थकाऊ और सॉफ्टवेयर के लिए यांत्रिक है — बशर्ते सॉफ्टवेयर एक से ज़्यादा blueprint प्रारूप पढ़ सके।
EdunodeX का generator कुछ भी करने से पहले template के एक section को अलग-अलग प्रश्न slots में बदल लेता है, और यह तीन आकार सँभालता है। पहला, प्रश्न-संख्या और प्रति-प्रश्न अंक वाला पुराना template। दूसरा, आयातित आकार जो count और marks-each इस्तेमाल करता है। तीसरा, एक स्पष्ट सूची जिसमें हर मद के अपने अंक होते हैं — मिले-जुले अंकों वाले section, जैसे CBSE SAFAL Grade 3 का Section C, इसी की माँग करते हैं। SAFAL templates से बने sections को उनके साथ आए पैटर्न-चिह्न से पहचाना जाता है, उनके आकार से अंदाज़ा नहीं लगाया जाता।
इस सामान्यीकरण से निकलने वाले हर slot के साथ section का नाम, प्रश्न का प्रकार, अंक और कठिनाई का वितरण जुड़ा रहता है। उसके आगे generator प्रारूप नहीं पढ़ रहा होता, बस slots भर रहा होता है।
ऐसा question bank जिससे कुछ निकाला जा सके
Generator उतना ही कारगर होता है जितना बेहतर उसका question bank, इसलिए bank यहाँ एक पूरा module है, किसी और चीज़ का उप-उत्पाद नहीं।
एक प्रश्न के रिकॉर्ड में उसका विषय, प्रकार, पाठ, अंक और कठिनाई स्तर रहते हैं, और वैकल्पिक रूप से उसके विकल्प व सही उत्तर, एक स्पष्टीकरण, Bloom’s taxonomy स्तर, मिनटों में अनुमानित समय, तथा जिस syllabus node से वह जुड़ा है उसका link। यही syllabus link अध्याय-वार चयन संभव बनाता है: अध्याय एक से चार तक का पेपर syllabus nodes पर चलने वाली एक query है, कोई keyword खोज नहीं।
Bank में समीक्षा की प्रक्रिया भी है, जो तब मायने रखती है जब एक से ज़्यादा शिक्षक प्रश्न देने लगें। परिवीक्षा पर चल रहे शिक्षक का लिखा प्रश्न और विभागाध्यक्ष का लिखा प्रश्न — किसी बोर्ड-पैटर्न पेपर में दोनों का वज़न बिना किसी की नज़र से गुज़रे एक जैसा नहीं होना चाहिए।
मिला-जुला generator blueprint कैसे भरता है
हर slot के लिए generator पहले bank में देखता है। विषय, प्रश्न का प्रकार, अंक और लक्षित कठिनाई उम्मीदवारों को छाँटते हैं, और syllabus का दायरा उन्हें और छाँट देता है। उपयुक्त प्रश्न मौजूद हो तो वही लिया जाता है।
AI से प्रश्न बनाना विकल्प है, पहली पसंद नहीं। यह वही slots भरता है जो bank नहीं भर सका — किसी ऐसे अध्याय पर पाँच अंक का प्रश्न जिस पर किसी ने लिखा ही नहीं, या एक अतिरिक्त कठिन प्रश्न जब उस विषय पर bank में सिर्फ़ आसान प्रश्न हों। यह call EdunodeX के अपने AI proxy से होकर जाती है, जो लागत उसी स्कूल के खाते में डालता है और platform को हर स्कूल के लिए एक सीमा तय करने देता है — किसी provider SDK को सीधे application में जोड़ने के बजाय।
इस क्रम का एक असर है जो आसानी से नज़र से चूक जाता है। जो स्कूल AI से बने जिन प्रश्नों को पसंद करता है उन्हें समीक्षा के बाद रख लेता है, उसका bank अगले टर्म में बेहतर होता है, इसलिए अगला पेपर मॉडल पर कम टिकता है। पूँजी bank है; generator वह औज़ार है जो उस पूँजी का सही लाभ दिलाता है।
छपने से पहले मिलते-जुलते प्रश्न पकड़ना
दो प्रश्न लगभग एक ही हो सकते हैं जबकि उनके शब्द शायद ही मिलते हों। “प्रकाश संश्लेषण की परिभाषा दीजिए” और “प्रकाश संश्लेषण से क्या तात्पर्य है?” — string मिलान में ये कभी नहीं मिलेंगे।
EdunodeX प्रश्न के पाठ से ही एक समानता स्कोर निकालता है — tokens में बाँटकर, छोटे अक्षरों में लाकर, आम शब्द हटाकर, और बहुत छोटे tokens छोड़कर — और फिर उन vectors के बीच के कोण से प्रश्नों की तुलना करता है। यह जान-बूझकर हल्का तरीक़ा है जिसमें बाहरी machine-learning निर्भरता नहीं है, यानी यह मौजूदा application के भीतर ही चलता है, इसके लिए कोई और service चालू रखनी नहीं पड़ती।
इसका उपयोग दो जगह होता है। Bank में यह संभावित दोहराव सामने लाता है, ताकि एक ही प्रश्न पाँच शिक्षक पाँच बार न चढ़ा दें। Generation में यह चयन में विविधता लाता है, ताकि एक ही पेपर अलग शब्दों में एक ही बात दो बार न पूछे।
पहले preview, फिर पेपर
Generation और creation अलग-अलग API calls हैं। Generate call एक प्रस्तावित पेपर लौटाती है। एक दूसरी, स्पष्ट call उसकी पुष्टि करती है और सहेजा हुआ पेपर रिकॉर्ड बनाती है।
इन दो calls के बीच शिक्षक कोई प्रश्न बदल सकते हैं, दोबारा लिख सकते हैं, अंक बदल सकते हैं, या पूरा draft फेंक सकते हैं। स्कूल के रिकॉर्ड में कुछ भी लिखा नहीं गया होता, इसलिए draft रद्द करने का कोई नुक़सान नहीं और साफ़ करने को कोई अधूरा पेपर भी नहीं बचता।
जहाँ विषय प्रमुख को अब भी देखना होगा
पेपर छपने जाने से पहले तीन चीज़ें इंसानी नज़र माँगती हैं।
कठिनाई के लेबल स्कूल का अपना आकलन हैं। जिसने प्रश्न चढ़ाया उसने जिसे “कठिन” कहा, वह उसी के मानक से कठिन है, और generator उस लेबल को मानता है, उस पर दोबारा सवाल नहीं उठाता। Bank की tagging ग़लत हुई, तो पेपर भी गड़बड़ होंगे।
AI से बने प्रश्नों की शुद्धता जाँचनी होगी, ख़ासकर गणित और विज्ञान में, जहाँ सुनने में ठीक लगने वाले प्रश्न का माँगे गए अंक-मान पर कोई साफ़ उत्तर हो ही न, यह मुमकिन है। AI से बने प्रश्नों को सीधे पेपर से उठाने के बजाय समीक्षा करके bank में डालने का सबसे मज़बूत तर्क यही है: समीक्षा एक बार होती है, और हर आने वाले पेपर को उसका लाभ मिलता है।
और जो सचमुच पढ़ाया गया उसके हिसाब से coverage तय करना शिक्षक का काम है। सिस्टम को syllabus का ढाँचा और teaching plan पता है; उसे यह पता नहीं कि खेल-दिवस की वजह से कक्षा का एक हफ़्ता चला गया था।