ایک ڈویلپر گائیڈ خبردار کرتی ہے کہ AI سے چلنے والی چیٹ کے دوران ڈیٹا بیس ٹرانزیکشن کو کھلا رکھنے سے جوابات غلط ہو سکتے ہیں اور بنیادی DBMS پر بوجھ پڑ سکتا ہے۔ یہ نوٹ، جو LLM پر مبنی ٹولز بنانے والی ٹیموں کے لیے ہے، کہتا ہے کہ یہ طریقہ کار "نہیں اپنایا جانا چاہیے" اور اس کے بجائے چار مختصر مدتی تسلسل کے پیٹرنز (consistency patterns) پیش کرتا ہے۔
یہ وارننگ کیوں اہم ہے
LLM سے چلنے والے اسسٹنٹس اکثر فالو اپ سوالات کا ایک سلسلہ پوچھتے ہیں: وہ ایک ریکارڈ پڑھتے ہیں، ایک تفصیل کی درخواست کرتے ہیں، اور پھر کل (total) کے لیے پوچھتے ہیں۔ اگر ان مراحل کے درمیان بنیادی ڈیٹا تبدیل ہو جائے، تو اسسٹنٹ متضاد اعداد و شمار دے سکتا ہے—ایک جواب غلط ہوگا۔ اس کا ایک پرکشش حل یہ ہے کہ گفتگو کے آغاز میں ایک ہی ٹرانزیکشن کھول دی جائے اور اسے چیٹ ختم ہونے تک برقرار رکھا جائے۔ عملی طور پر، یہ طریقہ row versions کو روک لیتا ہے، tempdb کو بھر دیتا ہے، locks برقرار رکھتا ہے، اور connection pooling میں مداخلت کرتا ہے۔
طویل مدتی ٹرانزیکشنز کی وجوہات
- ملٹی ٹرن پرومپٹنگ (Multi-turn prompting) – LLMs عام طور پر صارف کے جواب دیکھنے سے پہلے کئی پرومپٹس تیار کرتے ہیں۔
- ٹول کالز جو ڈیٹا بیس تک پہنچتی ہیں – ہر مرحلہ ایک stored procedure، SELECT، یا UPDATE کو کال کر سکتا ہے۔
- غیر منظم ٹرانزیکشن اسکوپ (Uncontrolled transaction scope) – ڈویلپرز کبھی کبھی یہ سمجھتے ہوئے کہ اس سے تسلسل (consistency) کی ضمانت ملے گی، پوری چیٹ کو ایک BEGIN…COMMIT بلاک میں لپیٹ دیتے ہیں۔
جب چیٹ طویل ہوتی ہے، تو DB انجن کو اصل row versions کو برقرار رکھنا پڑتا ہے تاکہ ٹرانزیکشن کو ایک مستحکم ویو (view) نظر آئے۔ وہ ورژنز tempdb میں رہتے ہیں، جو جگہ اور I/O استعمال کرتے ہیں۔ اسی مدت کے لیے برقرار رکھے گئے locks متوازی رائٹرز (concurrent writers) کو روک دیتے ہیں، اور غیر فعال کنکشن پول (connection pool) کو ختم کر سکتا ہے، جس سے نئے کالرز کو خالی سلاٹ کے لیے انتظار کرنا پڑتا ہے۔
چار مختصر مدتی پیٹرنز
گائیڈ یہ سفارش کرتی ہے کہ تسلسل (consistency) کو پوری گفتگو کے بجائے ہر ٹول کال (per-tool-call) کے حوالے سے دیکھا جائے۔ چار پیٹرنز یہ ہیں:
- لائیو سٹیٹمنٹس (Live statements) – ہر کال ڈیفالٹ آئسولیشن لیول (isolation level) کے تحت چلتی ہے، اور صرف وہی ڈیٹا دیکھتی ہے جو ایگزیکیوشن کے وقت کمٹ (commit) کیا گیا ہو۔ یہ سادہ ترین ماڈل ہے؛ کال کرنے والا یہ تسلیم کرتا ہے کہ پچھلے مرحلے کے بعد ڈیٹا تبدیل ہو سکتا ہے۔
- محدود ٹرانزیکشنز (Bounded transactions) – ایک ڈویلپر چند سٹیٹمنٹس کو ایک ہی مختصر ٹرانزیکشن کے اندر گروپ کرتا ہے جو اگلے LLM مرحلے سے پہلے ختم ہو جاتی ہے۔ یہ ٹول کال سے آگے بڑھے بغیر اس بیچ (batch) کے لیے ایٹومیسیٹی (atomicity) کی ضمانت دیتا ہے۔
- اسنیپ شاٹ ریڈز (Snapshot reads) – آپریشن ایک متعین اسنیپ شاٹ ٹائم اسٹیمپ کے ساتھ شروع ہوتا ہے، جو کال کے دوران ڈیٹا بیس کا ایک مستحکم ویو فراہم کرتا ہے۔ کال کے اندر تمام ریڈز ایک ہی ڈیٹا دیکھتی ہیں، چاہے متوازی رائٹس (concurrent writes) ہو رہی ہوں۔
- میٹیریلائزڈ رپورٹس (Materialized reports) – ٹول ایک پہلے سے تیار کردہ، ورژن شدہ رزلٹ سیٹ سے ڈیٹا پڑھتا ہے جو ایک معلوم کٹ آف پوائنٹ پر ڈیٹا بیس کی عکاسی کرتا ہے۔ اس کے بعد پیجینیشن (pagination) یا مزید حساب کتاب اسی منجمد ڈیٹا سیٹ پر کیے جاتے ہیں۔
SQL Server میں، چیک کریں کہ آیا READ_COMMITTED_SNAPSHOT فعال ہے۔ یہ فرض نہ کریں کہ نام ہی پوری کہانی بتا دیتا ہے۔
LLM سے چلنے والی ایپس کے لیے عملی اصول
- ضرورت کے مطابق بیچ (Batch) بنائیں – اگر کسی سوال کے لیے بہت سی ویلیوز کی ضرورت ہے، تو الگ الگ کوئریز جاری کرنے کے بجائے جو ہر بار ایک نئی ٹرانزیکشن شروع کرتی ہیں، انہیں ایک ہی ٹول کال میں کمپیوٹ کریں۔
- ڈیٹرمینسٹک پیجینیشن (Deterministic pagination) – جب صفحات کے ذریعے نتائج پیش کیے جا رہے ہوں، تو ایک مستحکم آرڈرنگ کی (ordering key)، کرسر (cursor)، یا میٹیریلائزڈ رزلٹ سیٹ استعمال کریں۔ جب صارف اسکرول کر رہا ہو تو کبھی بھی ٹرانزیکشن کو کھلا نہ رکھیں۔
- ثبوت فراہم کریں – ڈیٹا کے ساتھ ساتھ، ایسا میٹا ڈیٹا شامل کریں جو تسلسل کے ماڈل کو واضح کرے: تسلسل کی کلاس (consistency class)، اسنیپ شاٹ کا آغاز کا وقت، رپورٹنگ کٹ آف، ڈیٹا کی تازگی، رو کاؤنٹ، ڈیٹا بیس کی شناخت، اور ایک ٹریس آئی ڈی (trace ID)۔
- کنکرنسی (concurrency) کے ساتھ اسٹریس ٹیسٹ کریں – جب LLM پرومپٹ کر رہا ہو تو متوازی رائٹس (concurrent writes) کا تجربہ کریں، اور اس بات کی تصدیق کریں کہ ایپلی کیشن کامیابی سے دوبارہ کوشش کرتی ہے یا متبادل راستہ اختیار کرتی ہے۔
خلاصہ یہ ہے کہ: ایک AI چیٹ کو ڈیٹا بیس ٹرانزیکشن کی مدت کا فیصلہ نہیں کرنا چاہیے۔ تسلسل کو ہر ٹول کال تک محدود کر کے، ڈویلپرز ڈیٹا بیس کو صحت مند رکھتے ہیں، تمام صارفین کے لیے کارکردگی برقرار رکھتے ہیں، اور پھر بھی LLM کو درست جواب دینے کے لیے کافی قابل اعتماد ڈیٹا فراہم کرتے ہیں۔