يمكنك إضافة نموذج لغوي كبير (LLM) إلى تطبيق قديم من دون أن تُدخله إلى نواة النظام. يستدعي التطبيق خدمة وسيطة منفصلة (Adapter) عبر واجهة ضيقة، وتتصرف هذه الخدمة بهوية المستخدم المسجّل دخوله، وتمنح النموذج عددًا قليلًا من الأدوات محددة المدخلات، وتقرأ البيانات ضمن صلاحيات المستخدم، ولا تملك إلا اقتراح التعديلات، لتمرّ بعدها عبر قواعد التطبيق القائمة.
يجيب المقال عن سؤالين: أين نضع النموذج، وما الذي يحق له أن يلمسه؟ أما ترتيب التنفيذ، من تجربة للقراءة فقط إلى التشغيل الموازي والإطلاق والتراجع، فنتناوله في خطوات دمج نماذج LLM في البرمجيات القديمة.
تتكون البنية المرجعية من خمسة أجزاء:
- النواة القديمة. تبقى المرجع الرسمي للسجلات، فلا تتغير قاعدة بياناتها ولا قواعد عملها ولا دورة إصداراتها.
- الخدمة الوسيطة. خدمة مستقلة تملك التعليمات (Prompts) واستدعاءات النموذج وتعريفات الأدوات وفحص المخرجات وسجلات الذكاء الاصطناعي.
- نقطة النموذج. واجهة مستضافة أو نموذج تستضيفه بنفسك، ولا يتصل بها غير الخدمة الوسيطة.
- جانب القراءة. واجهات تطبّق الصلاحيات، أو نسخة قراءة خلف طبقة استعلام مقيّدة، أو فهرس استرجاع.
- جانب الكتابة. واجهات العمل القائمة في التطبيق، ولا يصل إليها إلا مقترح اجتاز التحقق.
سبب هذا الفصل أن التعليمات وإصدارات النماذج وفحوص المخرجات تتغير بإيقاع يختلف عن إيقاع الكود القديم. اجمعها في خدمة واحدة، فلا تحمل إصدارات النظام القديم أي تغيير في الذكاء الاصطناعي، ويصبح إيقاف الميزة تعديلًا في الإعدادات، وتبقى النواة منشورة كما هي.
والفكرة مستعارة من نمط Strangler Fig، الذي تصفه إرشادات AWS بأنه استبدال تدريجي للنظام القديم خلف طبقة توجيه، مع عمل المكونات القديمة والجديدة جنبًا إلى جنب. هدفنا هنا أضيق: نضيف قدرة ونترك النظام في مكانه، لكن نقطة الفصل تؤدي الدور نفسه. وإن قررت لاحقًا استبدال أجزاء من النواة، فدليلنا عن تحديث الأنظمة القديمة بنمط Strangler Fig يشرح ذلك المسار.
أعطِ التطبيق القديم نقاطًا مصممة على مقاس المهمة. فشاشة الدعم مثلًا تستدعي نقطة تلخيص التذكرة وترسل رقمها فقط، ولا مكان هنا لنقطة عامة من نوع «أرسل هذا النص إلى النموذج». تجلب الخدمة الوسيطة التذكرة من جانب القراءة، وتبني التعليمات من قالب له رقم إصدار، وتستدعي النموذج، وتتحقق من المخرجات وفق مخطط محدد (Schema)، ثم تعيد نتيجة منظمة: ملخصًا يشير إلى الرسائل التي اعتمد عليها، أو حالة فشل معروفة النوع.
واجعل الفشل أمرًا عاديًا: لكل استدعاء مهلة زمنية، وإذا تأخرت الخدمة أو تعطلت أو أعادت ما لا يجتاز التحقق، تعمل الشاشة القديمة كما كانت قبل وجود الميزة. أبعد النموذج عن المعاملات الحرجة مثل إتمام الشراء أو ترحيل المدفوعات، وضع المهام الطويلة، مثل تلخيص مستندات كبيرة أو تصنيف تراكم من الطلبات، في طابور معالجة تظهر نتائجه حين تجهز. واجمع قوالب التعليمات وإصدارات النماذج والأدوات والحدود ومفاتيح التشغيل داخل الخدمة الوسيطة تحت المراجعة، حيث يجدها فريقك في مكان واحد بدل البحث عنها في الكود القديم.
شكل 1: خدمة وسيطة محددة المهمة. طلبات منظمة ونتائج مفحوصة.
يجب أن تعرف الخدمة الوسيطة صاحب الطلب، وأن تعرفه من خادمك. يمرر التطبيق القديم هوية المستخدم الموثّقة في رمز موقّع قصير العمر، أو تضيفها بوابة الواجهات. وتمرر الخدمة هذه الهوية في كل استدعاء لواجهات البيانات، فتخضع كل قراءة للقواعد نفسها التي تحكم الشاشة القديمة.
تجنّب حسابًا واحدًا واسع الصلاحيات للمساعد. فمع حساب مدير مشترك قد يتحول أي سؤال إلى تصعيد للصلاحيات، لأن أحدهم قد يقنع النموذج بطلب سجلات لا يستطيع المستخدم فتحها. ولا شيء في نص السؤال أو في مستند مسترجَع أو في نتيجة أداة يغيّر الهوية؛ فرسالة تدّعي أنها من مدير النظام لا تغيّر شيئًا.
أما المهام الخلفية التي تعمل دون مستخدم، مثل الملخصات الليلية، فلها هوية خدمة خاصة، محصورة في بيانات تلك المهمة ومسجّلة على حدة. وفي استرجاع المستندات تسري القاعدة نفسها عند الفهرس: رشّح حسب الصلاحية قبل أن يصل أي مقطع إلى النموذج، كما يوضح دليلنا عن RAG للشركات الذي يحترم الصلاحيات.
يفرّق دليل Anthropic الهندسي لبناء الوكلاء بين مسارات العمل، حيث يتبع الكود خطوات محددة مسبقًا، والوكلاء الذين يقرر فيهم النموذج بنفسه أي الأدوات يستخدم، ويوصي بالبدء بأبسط تصميم يؤدي المهمة. ومعظم ميزات الأنظمة القديمة يناسبها مسار العمل: يجلب الكود السجل، ويلخّص النموذج أو يصنّف أو يصوغ مسودة. أما الحاجة إلى استقلالية أكبر فقرار عمل قبل أن تكون قرارًا تقنيًا، ويساعدك على حسمه دليل مدير التقنية لوكلاء الذكاء الاصطناعي.
وحين يحتاج النموذج إلى أدوات فعلًا، صمّم كل أداة كما تصمم واجهة عامة لا بابًا خلفيًا:
- ضيقة ومحددة المدخلات. أداة مثل
get_order_status(order_id)، لا أداة «نفّذ أي استعلام SQL» أو «اجلب أي رابط». - مربوطة بواجهات العمل القائمة، فتستفيد من تحققها وصلاحياتها.
- للقراءة افتراضيًا. الأداة التي قد تغيّر البيانات تعيد مقترحًا ينتظر تأكيد أحدهم.
- مقيّدة. قوائم سماح، وحدود لعدد الطلبات، وتحقق من المدخلات كما مع أي طلب غير موثوق.
وتعامل مع نتائج الأدوات والنصوص المسترجعة على أنها بيانات لا تعليمات؛ فسجلّ يتضمن عبارة «تجاهل التعليمات السابقة» يجب ألا يستطيع تشغيل أداة أخرى أو توسيع الصلاحيات.
القراءة تجيب عن الأسئلة، والكتابة تغيّر سجلات العمل. احصر مسار القراءة في صلاحيات المستخدم، ولا تسمح له بتعديل السجلات. وحتى القراءة وحدها قد تكشف معلومات حساسة، وقد تؤدي الإجابة الخاطئة إلى قرار ضار؛ لذلك تظل فحوص الصلاحيات والتقييم والإحالة إلى المصادر ضرورية.
أما مسار الكتابة فضيق، والنموذج لا ينفّذ أي تعديل بنفسه. يُنتج مقترحًا منظمًا يتحقق منه التطبيق بقواعد الإدخال اليدوي نفسها، ثم يرى المستخدم ما سيتغير بندًا بندًا ويؤكده، فتنفّذه الواجهة القائمة بهويته ومع مفتاح يمنع التكرار (Idempotency key). ويسجل التدقيق أن المساعد صاغ المسودة ومن اعتمدها.
مثال توضيحي: يطلب موظف دعم من المساعد ردّ قيمة منتج وصل تالفًا. يقرأ المساعد الطلب وسياسة الاسترداد عبر أدوات للقراءة فقط، ثم يصوغ طلب استرداد بالمبلغ والسبب والبند المعتمد. تتحقق خدمة الاسترداد القديمة منه كما تفعل مع أي طلب يدوي، ويراجعه الموظف ويؤكده، فيُسجَّل باسم حسابه. وإذا فشل التحقق تعود المسودة مع السبب، ولا يتغير شيء. وفي أسئلة التقارير، اعرض عددًا ثابتًا من العروض (Views) على نسخة للقراءة بدل استعلامات SQL حرة على قاعدة الإنتاج.
شكل 2: الكتابة تنتظر التأكيد. قواعد النظام تفحص الطلب أيضًا.
- تتبّع كل طلب بمعرّف ارتباط واحد من الشاشة القديمة إلى الخدمة الوسيطة واستدعاء النموذج وكل أداة.
- سجّل ما تحتاجه المراجعة: المستخدم، وإصدارات التعليمات والنموذج، واستدعاءات الأدوات، ومعرّفات السجلات، والمخرجات، ونتيجة التحقق، مع تقييد الوصول وتحديد مدة الاحتفاظ وتنقيح الحقول الحساسة.
- ضع حدودًا لعدد الطلبات والإنفاق لكل مستخدم ولكل ميزة، حتى تتوقف الحلقة الجامحة أو إساءة الاستخدام عند الحد.
- احتفظ بمفتاح إيقاف لكل ميزة، مستقل عن إصدارات النظام القديم.
- قيّم قبل الإطلاق وبعد كل تغيير في التعليمات أو النماذج أو الأدوات، بحالات تغطي الإجابات الصحيحة والاعتذار وحدود الصلاحيات ومحاولات الحقن. ويشرح دليلنا عن تقييم أنظمة الذكاء الاصطناعي قبل الإطلاق كيف تبني هذه المجموعة.
- استدعاء النموذج مباشرة من المتصفح أو تطبيق الجوال بمفتاح API مضمّن.
- أداة SQL أو HTTP عامة تُضاف «من أجل المرونة».
- حساب مدير مشترك لكل طلبات المساعد.
- استدعاء متزامن للنموذج داخل معاملة لا تحتمل الفشل.
- كتابة مخرجات النموذج في السجلات مباشرة دون تحقق أو تأكيد.
كل واحد من هذه الأخطاء يُدخل النموذج إلى نواتك. ابدأ بميزة واحدة على مقاس المهمة في مسار القراءة، وأضف الأدوات ومسار الكتابة حين تحتاجها الميزة، وأبقِ قاعدة الهوية ثابتة طوال الطريق. وإن أردت مساعدة في إسقاط هذه الحدود على تطبيقك، يمكن لفريق خدمة أنظمة الذكاء الاصطناعي مراجعة التصميم معك.
- Amazon Web Services. Strangler fig pattern، ضمن إرشادات AWS لأنماط التصميم السحابي.
- Anthropic. Building effective agents. وتنبّه الصفحة إلى أن أمثلتها الأصلية من ديسمبر 2024 تاريخية وليست إرشادات حالية لواجهات البرمجة.
البنية والتوصيات الواردة في هذا المقال إرشادات هندسية من تكنوستاك، لا متطلبات من AWS أو Anthropic.
