कोई AI साथी गलत महत्वपूर्ण तारीख के लिए रिमाइंडर से कैसे बच सकता है?

किसी तारीख को याद रखना रिमाइंडर शेड्यूल करने जैसा क्यों नहीं है

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

इसलिए एक विश्वसनीय डिज़ाइन इन्हें अलग-अलग रिकॉर्ड के रूप में मानता है:

**याद रखा गया तथ्य:** क्या कहा गया था या प्रदान किया गया था, उसके स्रोत और किसी भी अनिश्चितता के साथ।

**पुष्टि की गई तारीख:** वह व्यक्ति या घटना और कैलेंडर तारीख जिसकी उपयोगकर्ता ने जाँच की है।

**शेड्यूल की गई सूचना:** उपयोगकर्ता द्वारा स्पष्ट रूप से स्वीकृत अलर्ट, डिलीवरी समय, समय क्षेत्र और वर्तमान स्थिति के साथ।

यह पृथक्करण AI साथियों के लिए एक डिज़ाइन अनुशंसा है। Google Calendar के सहायता पृष्ठ बताते हैं कि Calendar में इवेंट कैसे बनाएं और सूचनाओं का प्रबंधन कैसे करें; वे AI साथी की मेमोरी का वर्णन नहीं करते हैं या यहाँ प्रस्तावित वर्कफ़्लो को लागू नहीं करते हैं। केवल एक कैलेंडर उदाहरण के रूप में, Google के निर्देश किसी इवेंट को बनाने की प्रक्रिया को इवेंट विवरण और एक सेव करने के चरण के साथ एक कार्रवाई मानते हैं ([Google Calendar: Create an event](https://support.google.com/calendar/answer/72143?hl=en))।

शेड्यूल करने से पहले किन विवरणों की पुष्टि की जानी चाहिए?

उन विवरणों की पुष्टि करें जो यह तय करते हैं कि अलर्ट का क्या अर्थ है और यह कब सक्रिय हो सकता है। एक संक्षिप्त समीक्षा स्क्रीन या संवादात्मक सारांश में निम्नलिखित दिखना चाहिए:

**व्यक्ति या घटना:** तारीख किसके बारे में है, और यह किस संदर्भ में है?

**पूरी तारीख:** दिन, महीना और वर्ष। वर्ष के बिना महीना और दिन अधूरा हो सकता है, खासकर तब जब यह किसी पिछली या भविष्य की घटना से संबंधित हो सकता है।

**तारीख का स्रोत (प्रोवेनेंस):** तारीख कहाँ से आई—उदाहरण के लिए, उपयोगकर्ता का कोई कथन, आयातित कैलेंडर प्रविष्टि, या कोई अनुमान? अनुमान को तयशुदा के रूप में प्रस्तुत करने के बजाय अनिश्चितता को स्पष्ट करें।

**रिमाइंडर का समय:** अनुरोधित अग्रिम समय (लीड टाइम) और स्थानीय घड़ी का समय, जैसे "एक दिन पहले सुबह 9:00 बजे।"

**समय क्षेत्र (टाइम ज़ोन):** वह क्षेत्र जो डिलीवरी को नियंत्रित करे, विशेष रूप से यदि उपयोगकर्ता यात्रा करता है या तारीख किसी अन्य स्थान के व्यक्ति से संबंधित है।

**अनुमति और डिलीवरी:** क्या उपयोगकर्ता को वास्तव में अलर्ट चाहिए, और यदि उत्पाद एक से अधिक डिलीवरी चैनल प्रदान करता है तो यह कहाँ दिखाई देगा।

Google Calendar उपयोगकर्ताओं को इवेंट के लिए सूचनाएं सेट करने और सूचना सेटिंग्स बदलने की अनुमति देता है; इसके खाता और इवेंट सेटिंग्स यह निर्धारित करते हैं कि वे Calendar सूचनाएं कैसे काम करती हैं ([Google Calendar: Change notifications](https://support.google.com/calendar/answer/37242?hl=en))। यह किसी सूचना को उसके अपने नियंत्रणों के साथ एक कॉन्फ़िगर की गई कार्रवाई के रूप में मानने का एक उपयोगी उदाहरण है, न कि किसी तारीख को जानने के एक स्वचालित परिणाम के रूप में। इसे इस बात के प्रमाण के रूप में नहीं लिया जाना चाहिए कि Calendar में साथी जैसी मेमोरी होती है।

एक काल्पनिक उदाहरण: याद रखे गए विवरण से लेकर पुष्ट अलर्ट तक

मान लीजिए कि कोई उपयोगकर्ता कहता है, "माया का संगीत समारोह 14 मई को है।" साथी इसे **अपुष्ट याद रखे गए तथ्य** के रूप में रख सकता है: व्यक्ति, घटना और महीना/दिन मौजूद हैं, लेकिन वर्ष, समय क्षेत्र और सूचित करने की अनुमति नहीं है। इसे केवल उस वाक्य के आधार पर अलर्ट शेड्यूल नहीं करना चाहिए।

साथी पूछ सकता है: "मैंने ध्यान दिया कि माया का संगीत समारोह 14 मई को हो सकता है। यह कौन सा वर्ष है, मुझे किस समय क्षेत्र का उपयोग करना चाहिए, और क्या आप एक रिमाइंडर चाहेंगे?" उपयोगकर्ता उत्तर देता है: "14 मई, 2027, अमेरिका/लॉस_एंजिल्स। कृपया मुझे एक दिन पहले प्रशांत समय (Pacific time) के अनुसार सुबह 9:00 बजे याद दिलाएं।" साथी संक्षेप में बताता है: "मैं आपको 14 मई के समारोह से एक दिन पहले, 13 मई, 2027 को सुबह 9:00 बजे अमेरिका/लॉस_एंजिल्स समय पर माया के समारोह के बारे में याद दिलाऊंगा। क्या इसे शेड्यूल करें?"

उपयोगकर्ता द्वारा पुष्टि करने के बाद ही डिज़ाइन को एक सूचना रिकॉर्ड बनाना चाहिए जैसे: **माया का संगीत समारोह — 14 मई, 2027 — रिमाइंडर 13 मई, 2027 सुबह 9:00 बजे अमेरिका/लॉस_एंजिल्स — सक्रिय**। ऊपर दी गई तारीख और समय काल्पनिक उदाहरण हैं, किसी वास्तविक व्यक्ति या घटना की रिपोर्ट नहीं। समय क्षेत्र का स्पष्ट रूप से नाम देने से "सुबह 9:00 बजे" को सार्वभौमिक मानने से बचने में मदद मिलती है। Google Calendar का समय-क्षेत्र मार्गदर्शन बताता है कि इवेंट का समय स्थानीय क्षेत्रों में प्रदर्शित होता है और समय-क्षेत्र परिवर्तन कैलेंडर आइटम दिखने के तरीके को प्रभावित कर सकते हैं; यह Calendar के व्यवहार का एक उदाहरण है, AI रिमाइंडर के बारे में कोई दावा नहीं ([Google Calendar: Use Calendar in different time zones](https://support.google.com/calendar/answer/37064?hl=en))।

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

जब कोई तारीख अनसुलझी या परस्पर विरोधी हो तो क्या होना चाहिए?

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

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

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

सुधार, रोक (पॉज़) और रद्दीकरण कैसे काम करने चाहिए?

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

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

**रद्दीकरण:** रद्दीकरण से शेड्यूल की गई सूचना निष्क्रिय होनी चाहिए, न कि केवल बातचीत का कोई नोट हटना चाहिए या आइटम छिपना चाहिए। जब एक से अधिक मेल खा सकते हों तो पुष्टि करें कि कौन सा रिमाइंडर रद्द किया जा रहा है, फिर रद्द की गई स्थिति दिखाएं। यदि याद रखी गई तारीख उपयोगी बनी रहती है, तो इसे रद्द किए गए अलर्ट से अलग रखें और उस तथ्य को संपादित करने या हटाने के लिए समझने योग्य नियंत्रण प्रदान करें। Calendar व्यक्तिगत इवेंट सहित सूचना सेटिंग्स बदलने के नियंत्रण प्रदान करता है; यह सूचना प्रबंधन का एक संकीर्ण उदाहरण है, इस बात का प्रमाण नहीं कि कोई AI साथी रिमाइंडर को कैसे संग्रहीत या रद्द करता है ([Google Calendar notification help](https://support.google.com/calendar/answer/37242?hl=en))।

किसी भी बदलाव के बाद, परिणामी स्थिति और महत्वपूर्ण विवरण दिखाएं: रिमाइंडर किस तारीख से संबंधित है, यह कब सक्रिय होगा, इसका समय क्षेत्र क्या है, और क्या यह सक्रिय है, रोका गया है या रद्द किया गया है। उपयोगकर्ता के लिए किसी शांत (बिना बताए किए गए) बदलाव को सत्यापित करना कठिन होता है और इससे एक पुरानी धारणा बनी रह सकती है।

उपयोगकर्ताओं के लिए एक संक्षिप्त ऑडिट चेकलिस्ट

किसी तारीख के रिमाइंडर पर भरोसा करने से पहले, स्वयं उस आइटम की जांच करें:

क्या व्यक्ति या घटना का नाम सही ढंग से दिया गया है?

क्या वर्ष सहित पूरी तारीख की पुष्टि हो चुकी है?

क्या मैं बता सकता हूँ कि तारीख कहाँ से आई, और क्या कोई अनिश्चितता दिखाई दे रही है?

क्या मैंने केवल तारीख का उल्लेख करने के बजाय स्पष्ट रूप से अलर्ट को मंज़ूरी दी है?

क्या रिमाइंडर का अग्रिम समय (लीड टाइम), घड़ी का समय और समय क्षेत्र सही है?

क्या आइटम शेड्यूल किया गया और सक्रिय बताता है, या इसे अभी भी स्पष्टीकरण की आवश्यकता है?

यदि मैंने इसे सुधारा, रोका या रद्द किया, तो क्या प्रदर्शित स्थिति मेरे अनुरोध से मेल खाती है?

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

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