जब कोई AI किसी प्रोजेक्ट का विवरण भूल जाए, तो उसे याद करने से पहले पूछना चाहिए

एक संभावित लगने वाली याददाश्त भी आखिर एक अनुमान ही क्यों होती है

एक रचनात्मक प्रोजेक्ट छोटे-छोटे निर्णयों पर निर्भर करता है: कौन सा शीर्षक शॉर्टलिस्ट किया गया था, ड्राफ्ट में उत्तम पुरुष (first person) का उपयोग किया गया है या मध्यम पुरुष (second person) का, या उपयोगकर्ता ने कौन सा कलर पैलेट चुना था। यदि सहायक इनमें से किसी एक विवरण को खोजने में असमर्थ है, तो उसका एक धाराप्रवाह उत्तर एक विश्वसनीय स्मरण जैसा लग सकता है, जबकि वह चुपके से एक नया विकल्प प्रस्तुत कर रहा होता है।

NIST जनरेटिव AI कॉन्फैबुलेशन (confabulation) को आत्मविश्वास से प्रस्तुत की गई गलत सामग्री के साथ-साथ ऐसे आउटपुट के रूप में परिभाषित करता है जो इनपुट से भटकते हैं या उसका खंडन करते हैं। एक मनगढ़ंत प्रोजेक्ट विवरण इस व्यावहारिक जोखिम में बिल्कुल सटीक बैठता है: इसे पहले से लिए गए निर्णय के रूप में गलत समझा जा सकता है। NIST का Generative AI Profile इस तंत्र को सामान्य शब्दों में वर्णित करता है; यहाँ प्रोजेक्ट-कार्य के परिणाम एक डिज़ाइन संबंधी निष्कर्ष हैं, न कि किसी विशेष उत्पाद के बारे में कोई खोज।

OpenAI का शोध भी इसी तरह यह तर्क देता है कि सामान्य मूल्यांकन प्रोत्साहन अनिश्चितता को स्वीकार करने की तुलना में अनुमान लगाने को पुरस्कृत कर सकते हैं। इसका उदाहरण सामान्य प्रश्नों के उत्तर देना है, लेकिन इसका डिज़ाइन संबंधी सबक यहाँ भी लागू होता है: एक सहायक को आत्मविश्वास से भरी पूर्णता को इस बात का प्रमाण नहीं मानना चाहिए कि कोई पिछली बातचीत उपलब्ध है। Why language models hallucinate

पहले यह स्थापित करें कि सहायक वास्तव में क्या देख सकता है

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

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

Google की People + AI Guidebook प्रासंगिक क्षमताओं और सीमाओं को समझाने और उपयोगकर्ता की समझ और निर्णयों को प्रभावित करने वाली बातों पर स्पष्टीकरण केंद्रित करने की सिफारिश करती है। यहाँ लागू करने पर, यह मॉडल के आंतरिक कामकाज की तकनीकी व्याख्या के बजाय उपलब्ध प्रोजेक्ट संदर्भ के बारे में एक संक्षिप्त विवरण की ओर संकेत करता है। Explainability + Trust

सबसे छोटे उपयोगी स्रोत के बारे में पूछें

कमी को स्पष्ट करने के बाद, एक लक्षित प्रश्न पूछें। उदाहरण के लिए: “क्या आप वह नोट पेस्ट कर सकते हैं या मुझे वह शीर्षक बता सकते हैं जो आपने तय किया था?” यदि उपयोगकर्ता के पास कई स्रोत विकल्प हो सकते हैं, तो एक संक्षिप्त सूची दें: “क्या यह नवीनतम ड्राफ्ट में था, आपके प्रोजेक्ट नोट्स में, या पिछली किसी चैट में?” इसका उद्देश्य किसी नियमित रचनात्मक कार्य को पूछताछ में बदले बिना जानकारी की पुनर्प्राप्ति को आसान बनाना है।

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

स्पष्टीकरण तब उपयोगी होता है जब लापता जानकारी उत्तर को बदल देती है। एक सहयोगी संवाद अध्ययन में, Testoni और Fernández ने पाया कि मॉडल की अनिश्चितता द्वारा निर्देशित एक स्पष्टीकरण रणनीति ने उनके विशिष्ट ड्राइंग कार्य में सफलता में सुधार किया; वे यह भी बताते हैं कि प्रश्न पूछने की एक लागत होती है। यह एक नपे-तुले दृष्टिकोण का समर्थन करता है: जब अनुपस्थित प्रोजेक्ट तथ्य महत्वपूर्ण हो तभी पूछें, और प्रश्न को केंद्रित रखें। Asking the Right Question at the Right Time

उपयोगकर्ता द्वारा पुष्टि करने के बाद ही अपडेट करें

एक बार जब उपयोगकर्ता कोई स्रोत प्रदान कर दे या विवरण की पुष्टि कर दे, तो पुष्टि किए गए तथ्य को संक्षिप्त रूप में दोहराएं: “समझ गया: आपके द्वारा पेस्ट किए गए नोट के आधार पर, वर्तमान शीर्षक ‘Small Garden Notes’ है।” यदि स्रोत में कुछ थोड़ा अलग कहा गया है, तो चुपचाप चुनने के बजाय उस बेमेल (mismatch) को सामने लाएं। उदाहरण के लिए: “आपके नोट में ‘Garden Notes’ लिखा है; आपने अभी ‘Small Garden Notes’ कहा है। मुझे किसका उपयोग करना चाहिए?”

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

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

ऐसे प्रश्नों से बचें जिनमें कोई अनुमान छिपा हो

एक प्रश्न तब भी गुमराह कर सकता है यदि उसमें कोई मनगढ़ंत उत्तर शामिल हो। “आपने टील (teal) रंग चुना था, है ना?” बातचीत को उस विवरण की ओर धकेलता है जिसे सहायक ने सत्यापित नहीं किया है। इसके बजाय एक तटस्थ अनुरोध को प्राथमिकता दें: “आपने कौन सा रंग चुना था?” यदि कोई वास्तविक स्रोत है जो टील कहता है, तो उसकी पहचान करें: “ड्राफ्ट नोट्स में टील सूचीबद्ध है। क्या आप अभी भी यही पैलेट चाहते हैं?” यह वाक्यांश स्रोत के साक्ष्य को वर्तमान पुष्टि से अलग करता है।

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

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

सामान्य प्रोजेक्ट कार्यों के साथ व्यवहार का मूल्यांकन करें

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

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

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

अनिश्चितता को प्रोजेक्ट की निरंतरता का हिस्सा बनाएं

रचनात्मक-प्रोजेक्ट सहायक के लिए, किसी लापता विवरण को स्वीकार करना कोई गतिरोध (dead end) नहीं है। यह निरंतरता की रक्षा करने का एक तरीका है: सिस्टम असत्यापित इतिहास को भरे बिना मदद करना जारी रख सकता है। स्पष्ट अनिश्चितता, एक केंद्रित अनुरोध, और एक दृश्यमान पुष्टि उपयोगकर्ता को यह तय करने देती है कि प्रोजेक्ट रिकॉर्ड में क्या शामिल होना चाहिए—और सहायक को अगले ड्राफ्ट के लिए एक ठोस आधार प्रदान करती है।

इस विषय को आगे पढ़ें