يحذر دليل للمطورين من أن إبقاء معاملة قاعدة بيانات (database transaction) مفتوحة طوال مدة الدردشة المدفوعة بالذكاء الاصطناعي يمكن أن يؤدي إلى فساد الإجابات وإرهاق نظام إدارة قواعد البيانات (DBMS) الأساسي. وتقول الملحوظة، الموجهة للفرق التي تبني أدوات مدعومة بنماذج اللغة الكبيرة (LLM)، إن هذه الممارسة "يجب ألا تُنفذ" ويقدم بدلاً من ذلك أربعة أنماط اتساق قصيرة الأمد.

لماذا يكتسب هذا التحذير أهمية

غالبًا ما تطرح المساعدات المدعومة بنماذج LLM سلسلة من الأسئلة المتابعة: فهي تقرأ سجلًا، ثم تطلب تفصيلاً، ثم تطلب إجماليًا. إذا تغيرت البيانات الأساسية بين تلك الخطوات، فقد تعطي المساعدة أرقامًا متناقضة — ستكون إحدى الإجابات خاطئة. الحل المغري هو فتح معاملة واحدة في بداية المحادثة وإبقاؤها حية حتى تنتهي الدردشة. ولكن من الناحية العملية، يؤدي هذا النهج إلى حجز إصدارات الصفوف، وملء tempdb، والاحتفاظ بالأقفال (locks)، والتدخل في عملية تجميع الاتصالات (connection pooling).

ما الذي يؤدي إلى معاملات طويلة الأمد

  • التلقين متعدد الأدوار (Multi-turn prompting) – عادةً ما تُنشئ نماذج LLM عدة مطالبات (prompts) قبل أن يرى المستخدم الرد.
  • استدعاءات الأدوات التي تصل إلى قاعدة البيانات – قد يستدعي كل دور إجراءً مخزنًا (stored procedure)، أو عملية SELECT أو UPDATE.
  • نطاق معاملات غير منضبط – يقوم المطورون أحيانًا بتغليف الدردشة بأكملها في كتلة BEGIN…COMMIT ، بافتراض أنها تضمن الاتساق.

عندما تطول الدردشة، يجب على محرك قاعدة البيانات الاحتفاظ بإصدارات الصفوف الأصلية حتى ترى المعاملة عرضًا مستقرًا. وتستقر هذه الإصدارات في tempdb ، مما يستهلك المساحة وعمليات الإدخال/الإخراج (I/O). كما أن الأقفال المحتجزة لنفس الفترة تمنع الكتابة المتزامنة، ويمكن للاتصال الخامل أن يستنفد مجموعة الاتصالات، مما يجبر المتصلين الجدد على انتظار خانة فارغة.

أربعة أنماط قصيرة الأمد

يوصي الدليل بمعاملة الاتساق كمسألة تتعلق بكل استدعاء أداة بدلاً من كونها مسألة تتعلق بالمحادثة بأكملها. والأنماط الأربعة هي:

  1. الاستعلامات الحية (Live statements) – يعمل كل استدعاء بموجب مستوى العزل الافتراضي، حيث لا يرى إلا البيانات التي تم اعتمادها (committed) في لحظة التنفيذ. هذا هو النموذج الأبسط؛ حيث يقبل المستدعي أن البيانات قد تكون تغيرت منذ الدور السابق.
  2. المعاملات المحدودة (Bounded transactions) – يقوم المطور بتجميع مجموعة من البيانات داخل معاملة واحدة قصيرة تنتهي قبل دور LLM التالي. وهذا يضمن الذرية (atomicity) لتلك الدفعة دون البقاء لفترة تتجاوز استدعاء الأداة.
  3. قراءات اللقطة (Snapshot reads) – تبدأ العملية بطابع زمني محدد للقطة (snapshot timestamp)، مما يوفر عرضًا مستقرًا لقاعدة البيانات طوال مدة الاستدعاء. ترى جميع القراءات داخل الاستدعاء نفس البيانات، حتى لو حدثت عمليات كتابة متزامنة.
  4. التقارير المُجسّدة (Materialized reports) – تقرأ الأداة من مجموعة نتائج مُجسّدة ومُصدرة مسبقًا تعكس قاعدة البيانات عند نقطة قطع معروفة. ثم تعمل عملية تقسيم الصفحات (pagination) أو الحسابات الإضافية على تلك المجموعة من البيانات المجمدة.

في SQL Server، تحقق مما إذا كان READ_COMMITTED_SNAPSHOT نشطًا. لا تفترض أن الاسم يوضح الصورة كاملة.

قواعد عملية للتطبيقات المدفوعة بنماذج LLM

  • تجميع ما تحتاجه – إذا كان السؤال يتطلب قيمًا عديدة، فقم بحسابها في استدعاء أداة واحد بدلاً من إصدار استعلامات منفصلة يبدأ كل منها معاملة جديدة.
  • التقسيم الصفحي الحتمي (Deterministic pagination) – عند عرض النتائج عبر صفحات، استخدم مفتاح ترتيب مستقر، أو مؤشرًا (cursor)، أو مجموعة نتائج مُجسّدة. لا تترك أبدًا معاملة مفتوحة أثناء قيام المستخدم بالتمرير.
  • إرجاع الأدلة – إلى جانب البيانات، قم بتضمين بيانات وصفية (metadata) تجعل نموذج الاتساق صريحًا: فئة الاتساق، ووقت بدء اللقطة، ونقطة قطع التقارير، وحداثة البيانات، وعدد الصفوف، وهوية قاعدة البيانات، ومعرف التتبع (trace ID).
  • اختبار الإجهاد مع التزامن – قم بمحاكاة عمليات الكتابة المتزامنة أثناء قيام LLM بالتلقين، وتحقق من أن التطبيق يعيد المحاولة أو يتراجع بسلاسة.

الخلاصة واضحة: لا ينبغي لدردشة الذكاء الاصطناعي أن تملي عمر معاملة قاعدة البيانات. من خلال حصر نطاق الاتساق في كل استدعاء أداة، يحافظ المطورون على صحة قاعدة البيانات، ويحافظون على الأداء لجميع المستخدمين، ومع ذلك يمنحون نماذج LLM بيانات موثوقة كافية للإجابة بدقة.