لماذا لا ينبغي عليك الاحتفاظ باتصالات قاعدة البيانات أثناء استدعاءات LLM
زمن استجابة الذكاء الاصطناعي (latency) لا يقتصر فقط على الوقت الذي يقضيه النموذج في التفكير، بل يشمل أيضاً كيفية إدارتك لاتصالات قاعدة البيانات.
إن الاحتفاظ باتصال قاعدة بيانات أثناء انتظار استجابة من LLM أو واجهة برمجة تطبيقات (API) للـ embedding يمكن أن يستنزف مجمع الاتصالات (connection pool) لديك. فالاتصالات الخارجية البطيئة تُبقي الجلسات مفتوحة لفترة أطول بكثير مما ينبغي.
لقد بحثت في مستودع (repo) Honcho لمعرفة الإصلاح الذي قاموا به؛ حيث استبدلوا جلسة واحدة طويلة الأمد بجلسات قصيرة مخصصة لمهام محددة.
النمط القديم
- فتح جلسة قاعدة البيانات
- قراءة إعدادات المستخدم
- استدعاء LLM (بطيء)
- استدعاء Embedding API (بطيء)
- حفظ النتائج
- إغلاق جلسة قاعدة البيانات
النمط الجديد
- فتح جلسة قاعدة البيانات لإجراء فحوصات ما قبل التنفيذ (pre-flight checks)
- قراءة القيم المطلوبة في متغيرات
- إغلاق جلسة قاعدة البيانات
- استدعاء LLM و Embedding APIs (دون الاحتفاظ باتصال قاعدة البيانات)
- فتح جلسة قاعدة بيانات جديدة وقصيرة لحفظ النتائج
- إغلاق جلسة قاعدة البيانات
الهدف ليس التخلي عن قاعدة البيانات، بل الحفاظ على اتساق المعاملات (transaction consistency) بعيداً عن فترات الانتظار عبر الشبكة.
خمس خطوات لإدارة اتصالاتك
- حدد حدود الاتساق (consistency boundaries) الخاصة بك.
- اسحب جميع القيم المطلوبة إلى متغيرات قبل أي استدعاء لواجهة برمجة تطبيقات خارجية.
- أغلق نطاق (scope) قاعدة البيانات.
- قم بتنفيذ المهام الخارجية البطيئة.
- افتح نطاق كتابة جديد وقصير لحفظ النتائج النهائية.
ملاحظة: إذا كنت تستخدم pgvector، فإن البحث يتم داخل قاعدة البيانات، لذا يجب عليك إبقاء الجلسة مفتوحة أثناء تلك العملية.
تقصير عمر الجلسة يحسن من قابلية التوسع (scaling)، ولكن احذر من أخطاء الكائنات المنفصلة (detached-object errors) في الـ ORM الخاص بك، وتأكد من بقاء البيانات متسقة عبر لقطات المعاملات (transaction snapshots).
Source: https://dev.to/junhyun-dev/neurin-llm-hocul-jung-db-connectioneul-jabji-anhneun-iyu-3abg
Optional learning community: https://t.me/GyaanSetuAi