یک راهنمای توسعه‌دهنده هشدار می‌دهد که باز نگه داشتن یک تراکنش پایگاه داده در طول یک چت مبتنی بر هوش مصنوعی می‌تواند باعث خراب شدن پاسخ‌ها و فشار بیش از حد به DBMS زیرساختی شود. این یادداشت که خطاب به تیم‌های سازنده ابزارهای مبتنی بر LLM نوشته شده، می‌گوید این کار «نباید انجام شود» و در عوض چهار الگوی سازگاری کوتاه‌مدت را پیشنهاد می‌دهد.

چرا این هشدار اهمیت دارد

دستیارهای مبتنی بر LLM اغلب مجموعه‌ای از سوالات تکمیلی را می‌پرسند: آن‌ها یک رکورد را می‌خوانند، جزئیاتی را درخواست می‌کنند و سپس مجموع را می‌پرسند. اگر داده‌های زیرساختی بین این مراحل تغییر کنند، دستیار ممکن است ارقام متناقضی را برگرداند—در نتیجه یک پاسخ اشتباه خواهد بود. راه حل وسوسه‌انگیز این است که یک تراکنش واحد را در شروع گفتگو باز کرده و تا پایان چت آن را زنده نگه دارید. در عمل، این رویکرد باعث اشغال نسخه‌های ردیف (row versions)، پر شدن tempdb، نگه داشتن قفل‌ها و تداخل با مدیریت استخر اتصال (connection pooling) می‌شود.

چه چیزی منجر به تراکنش‌های طولانی‌مدت می‌شود

  • Multi-turn prompting – مدل‌های LLM معمولاً قبل از اینکه کاربر پاسخی را ببیند، چندین پرامپت تولید می‌کنند.
  • فراخوانی ابزارهایی که به پایگاه داده متصل می‌شوند – هر مرحله ممکن است یک stored procedure، یک SELECT یا یک UPDATE را فراخوانی کند.
  • محدوده تراکنش کنترل‌نشده – توسعه‌دهندگان گاهی اوقات کل چت را در یک بلوک BEGIN…COMMIT قرار می‌دهند، با این فرض که این کار سازگاری را تضمین می‌کند.

وقتی چت طولانی می‌شود، موتور پایگاه داده باید نسخه‌های اصلی ردیف‌ها را نگه دارد تا تراکنش یک نمای پایدار را ببیند. این نسخه‌ها در tempdb قرار می‌گیرند و فضا و I/O را مصرف می‌کنند. قفل‌هایی که برای همان مدت نگه داشته می‌شوند، نویسندگان همزمان را مسدود می‌کنند و اتصالِ بیکار می‌تواند استخر (pool) را تخلیه کند و فراخوان‌های جدید را مجبور کند برای یک جای خالی منتظر بمانند.

چهار الگوی کوتاه‌مدت

این راهنما توصیه می‌کند که سازگاری (consistency) را به جای یک موضوع مربوط به کل گفتگو، به عنوان یک موضوع مربوط به هر «فراخوانی ابزار» (per-tool-call) در نظر بگیرید. چهار الگو عبارتند از:

  1. Live statements – هر فراخوانی تحت سطح ایزولاسیون پیش‌فرض اجرا می‌شود و فقط داده‌هایی را می‌بیند که در لحظه اجرا تایید (commit) شده‌اند. این ساده‌ترین مدل است؛ فراخوان‌کننده می‌پذیرد که داده‌ها ممکن است از مرحله قبل تغییر کرده باشند.
  2. Bounded transactions – توسعه‌دهنده تعدادی از دستورات را در یک تراکنش کوتاه واحد گروه‌بندی می‌کند که قبل از مرحله بعدی LLM به پایان می‌رسد. این کار اتمیسیته (atomicity) را برای آن دسته از دستورات تضمین می‌کند بدون اینکه فراتر از فراخوانی ابزار باقی بماند.
  3. Snapshot reads – عملیات با یک برچسب زمانی اسنپ‌شات مشخص شروع می‌شود و نمای پایداری از پایگاه داده را در طول فراخوانی فراهم می‌کند. تمام خواندن‌ها در طول فراخوانی، داده‌های یکسانی را می‌بینند، حتی اگر نوشته‌های همزمان رخ دهد.
  4. Materialized reports – ابزار از یک مجموعه نتایج از پیش تولید شده و نسخه‌بندی شده می‌خواند که منعکس‌کننده پایگاه داده در یک نقطه زمانی مشخص است. سپس صفحه‌بندی یا محاسبات بیشتر روی آن مجموعه داده ثابت انجام می‌شود.

در SQL Server، بررسی کنید که آیا READ_COMMITTED_SNAPSHOT فعال است یا خیر. فرض نکنید که نام آن تمام ماجرا را می‌گوید.

قوانین کاربردی برای اپلیکیشن‌های مبتنی بر LLM

  • دسته‌بندی نیازها (Batching) – اگر یک سوال به مقادیر زیادی نیاز دارد، آن‌ها را در یک فراخوانی ابزار محاسبه کنید، به جای اینکه پرس‌وجوهای جداگانه‌ای صادر کنید که هر کدام یک تراکنش جدید را شروع می‌کنند.
  • صفحه‌بندی قطعی (Deterministic pagination) – هنگام نمایش نتایج در صفحات مختلف، از یک کلید مرتب‌سازی پایدار، یک نشانگر (cursor) یا یک مجموعه نتایج مادی‌شده (materialized result set) استفاده کنید. هرگز در حالی که کاربر در حال اسکرول کردن است، یک تراکنش را باز نگه ندارید.
  • بازگرداندن شواهد (Return evidence) – در کنار داده‌ها، متادیتاهایی را بگنجانید که مدل سازگاری را صریح می‌کند: کلاس سازگاری، زمان شروع اسنپ‌شات، نقطه قطع گزارش‌دهی، تازگی داده‌ها، تعداد ردیف‌ها، هویت پایگاه داده و یک trace ID.
  • تست فشار با همزمانی (Stress-test with concurrency) – در حالی که LLM در حال پرامپت‌نویسی است، نوشتن‌های همزمان را شبیه‌سازی کنید و بررسی کنید که آیا اپلیکیشن به درستی تلاش مجدد (retry) می‌کند یا به حالت جایگزین (fallback) می‌رود.

نتیجه نهایی روشن است: یک چت هوش مصنوعی نباید طول عمر یک تراکنش پایگاه داده را تعیین کند. با محدود کردن محدوده سازگاری به هر فراخوانی ابزار، توسعه‌دهندگان سلامت پایگاه داده را حفظ می‌کنند، عملکرد را برای همه کاربران تضمین می‌کنند و همچنان داده‌های قابل اعتماد کافی را برای پاسخگویی دقیق به LLM ارائه می‌دهند.