एक डेवलपर गाइड चेतावनी देती है कि AI-संचालित चैट की पूरी अवधि के दौरान डेटाबेस ट्रांजेक्शन (transaction) को खुला रखने से उत्तर दूषित हो सकते हैं और अंतर्निहित DBMS बाधित हो सकता है। LLM-आधारित टूल्स बनाने वाली टीमों के लिए लक्षित यह नोट कहता है कि इस तरह का अभ्यास "नहीं किया जाना चाहिए" और इसके बजाय चार अल्पकालिक कंसिस्टेंसी पैटर्न (consistency patterns) का सुझाव देता है।
यह चेतावनी क्यों महत्वपूर्ण है
LLM-संचालित असिस्टेंट अक्सर फॉलो-अप प्रश्नों की एक श्रृंखला पूछते हैं: वे एक रिकॉर्ड पढ़ते हैं, एक विवरण मांगते हैं, और फिर कुल योग (total) पूछते हैं। यदि उन चरणों के बीच अंतर्निहित डेटा बदल जाता है, तो असिस्टेंट विरोधाभासी आंकड़े दे सकता है—एक उत्तर गलत होगा। इसका एक लुभावना समाधान बातचीत की शुरुआत में एक ही ट्रांजेक्शन खोलना और चैट समाप्त होने तक उसे जीवित रखना है। व्यवहार में, यह दृष्टिकोण रो वर्शन्स (row versions) को बांध देता है, tempdb को भर देता है, लॉक (locks) बनाए रखता है, और कनेक्शन पूलिंग (connection pooling) में बाधा डालता है।
लंबे समय तक चलने वाले ट्रांजेक्शन के कारण
- मल्टी-टर्न प्रॉम्प्टिंग (Multi-turn prompting) – उपयोगकर्ता के जवाब देखने से पहले LLM आमतौर पर कई प्रॉम्प्ट जेनरेट करते हैं।
- डेटाबेस को हिट करने वाले टूल कॉल्स – प्रत्येक टर्न एक स्टॉर्ड प्रोसीजर (stored procedure), SELECT, या UPDATE को कॉल कर सकता है।
- अनियंत्रित ट्रांजेक्शन स्कोप – डेवलपर्स कभी-कभी यह मानकर कि इससे कंसिस्टेंसी सुनिश्चित होगी, पूरी चैट को एक BEGIN…COMMIT ब्लॉक में लपेट देते हैं।
जब चैट लंबी खिंचती है, तो DB इंजन को मूल रो वर्शन्स (row versions) को बनाए रखना पड़ता है ताकि ट्रांजेक्शन एक स्थिर दृश्य (stable view) देख सके। वे वर्शन्स tempdb में रहते हैं, जो स्पेस और I/O का उपभोग करते हैं। समान अवधि के लिए रखे गए लॉक समवर्ती लेखकों (concurrent writers) को ब्लॉक कर देते हैं, और निष्क्रिय कनेक्शन पूल को समाप्त कर सकते हैं, जिससे नए कॉलर्स को खाली स्लॉट के लिए प्रतीक्षा करने पर मजबूर होना पड़ता है।
चार अल्पकालिक पैटर्न
गाइड यह अनुशंसा करती है कि कंसिस्टेंसी को प्रति-बातचीत (per-conversation) के बजाय प्रति-टूल-कॉल (per-tool-call) के रूप में माना जाए। चार पैटर्न इस प्रकार हैं:
- लाइव स्टेटमेंट्स (Live statements) – प्रत्येक कॉल डिफ़ॉल्ट आइसोलेशन लेवल के तहत चलती है, और केवल उसी डेटा को देखती है जो निष्पादन (execution) के समय कमिट (commit) किया गया है। यह सबसे सरल मॉडल है; कॉलर यह स्वीकार करता है कि पिछले टर्न के बाद से डेटा बदल गया होगा।
- बाउंडेड ट्रांजेक्शन (Bounded transactions) – एक डेवलपर कुछ स्टेटमेंट्स को एक ही छोटे ट्रांजेक्शन के भीतर समूहित करता है जो अगले LLM टर्न से पहले समाप्त हो जाता है। यह टूल कॉल से आगे लटके बिना उस बैच के लिए एटॉमिकिटी (atomicity) की गारंटी देता है।
- स्नैपशॉट रीड्स (Snapshot reads) – ऑपरेशन एक परिभाषित स्नैपशॉट टाइमस्टैम्प के साथ शुरू होता है, जो कॉल की अवधि के लिए डेटाबेस का एक स्थिर दृश्य प्रदान करता है। कॉल के भीतर सभी रीड्स एक ही डेटा देखते हैं, भले ही समवर्ती राइट्स (concurrent writes) हों।
- मटेरियलाइज्ड रिपोर्ट्स (Materialized reports) – टूल एक पूर्व-जेनरेटेड, वर्जन वाले रिजल्ट सेट से पढ़ता है जो एक ज्ञात कटऑफ पॉइंट पर डेटाबेस को दर्शाता है। इसके बाद पेजिनेशन (pagination) या आगे की गणनाएँ उस फ्रीज किए गए डेटासेट पर काम करती हैं।
SQL Server में, जाँचें कि क्या READ_COMMITTED_SNAPSHOT सक्रिय है। यह न मानें कि नाम ही पूरी कहानी बताता है।
LLM-संचालित ऐप्स के लिए व्यावहारिक नियम
- ज़रूरी चीज़ों को बैच में करें – यदि किसी प्रश्न के लिए कई मानों (values) की आवश्यकता है, तो अलग-अलग क्वेरी जारी करने के बजाय उन्हें एक ही टूल कॉल में कंप्यूट करें, क्योंकि प्रत्येक क्वेरी एक नया ट्रांजेक्शन शुरू करती है।
- डिटरमिनिस्टिक पेजिनेशन (Deterministic pagination) – पेजों के माध्यम से परिणाम प्रस्तुत करते समय, एक स्थिर ऑर्डरिंग की (ordering key), कर्सर (cursor), या मटेरियलाइज्ड रिजल्ट सेट का उपयोग करें। जब उपयोगकर्ता स्क्रॉल कर रहा हो, तो कभी भी ट्रांजेक्शन खुला न रखें।
- प्रमाण (evidence) वापस करें – डेटा के साथ-साथ, ऐसा मेटाडेटा शामिल करें जो कंसिस्टेंसी मॉडल को स्पष्ट करे: कंसिस्टेंसी क्लास, स्नैपशॉट स्टार्ट टाइम, रिपोर्टिंग कटऑफ, डेटा फ्रेशनेस, रो काउंट, डेटाबेस आइडेंटिटी और एक ट्रेस आईडी (trace ID)।
- कन्करेंसी के साथ स्ट्रेस-टेस्ट करें – जब LLM प्रॉम्प्ट कर रहा हो, तब समवर्ती राइट्स (concurrent writes) का अनुकरण (simulate) करें, और सत्यापित करें कि एप्लिकेशन सुचारू रूप से पुनः प्रयास (retry) करता है या फॉलबैक (fallback) करता है।
निष्कर्ष स्पष्ट है: एक AI चैट को डेटाबेस ट्रांजेक्शन के जीवनकाल को निर्धारित नहीं करना चाहिए। कंसिस्टेंसी को प्रत्येक टूल कॉल तक सीमित करके, डेवलपर्स डेटाबेस को स्वस्थ रखते हैं, सभी उपयोगकर्ताओं के लिए प्रदर्शन (performance) बनाए रखते हैं, और फिर भी LLM को सटीक उत्तर देने के लिए पर्याप्त विश्वसनीय डेटा प्रदान करते हैं।