Scalable Inference Architectures for Compound AI Systems: A Production Deployment Study
تقدم هذه الورقة دراسة لنشر إنتاجي لبنية استدلال معيارية ومستقلة عن المنصة في Salesforce، تتيح تقديم أنظمة الذكاء الاصطناعي المركبة مثل Agentforce وApexGuru بشكل قابل للتوسع، وفعال من حيث التكلفة، ومنخفض التأخير، محققةً تحسينات كبيرة في معدل الإنتاجية، وتأخير الذيل، والتكاليف التشغيلية، مع معالجة تحديات فريدة مثل التوزيع المتعدد للنماذج (multi-model fan-out) والبدء البارد المتتالي (cascading cold starts).
البحث الأصلي مرخَّص بموجب CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). هذا شرح مولَّده بالذكاء الاصطناعي للبحث أدناه. لم يكتبه المؤلفون ولم يصادقوا عليه. وللتحقق من الدقة التقنية، يرجى الرجوع إلى البحث الأصلي. اقرأ إخلاء المسؤولية الكامل
تخيل أنك تدير مطعماً فاخراً ومزدحماً يسمى Agentforce. في الماضي، كان هذا المطعم يمتلك مطبخاً واحداً ضخماً (إعداد "ثابت") حيث يحاول رئيس طهاة واحد القيام بكل شيء: تقطيع الخضروات، وشواء شرائح اللحم، وخبز الحلويات، وغسل الأطبق. إذا ازداد الضغط في المطعم، ينسد المطبخ. وإذا احتاج الطاهي إلى أخذ استراحة للراحة ("البداية الباردة" - cold start)، يتوقف المطعم بأكمله عن تقديم الطعام. والأسوأ من ذلك، كان عليك دفع راتب الطاهي على مدار الساعة طوال أيام الأسبوع، حتى عندما لا يأكل أحد.
تصف هذه الورقة كيف أعادت Salesforce بناء "مطعمها" للتعامل مع أنظمة الذكاء الاصطناعي المركبة (Compound AI Systems). فبدلاً من مطبخ واحد كبير، قامت ببناء شبكة توصيل طعام نمطية عند الطلب.
إليك كيف فعلوا ذلك، مشروحاً بتبسيط شديد:
1. المشكلة: مطبخ "مقاس واحد يناسب الجميع"
تطبيقات الذكاء الاصطناعي الحديثة (مثل Agentforce أو ApexGuru) معقدة. عندما يسأل العميل سؤالاً، لا يطلب النظام روبوتاً واحداً للإجابة فحسب. بل يشبه الأمر فريقاً من المتخصصين يعملون معاً:
- المتخصص (أ) (نموذج التضمين - Embedding Model): يبحث في تاريخ العميل.
- المتخصص (ب) (النموذج اللغوي الكبير - LLM): يكتب الرد.
- المتخصص (ج) (منفذ لغة SQL): يفحص قاعدة البيانات.
- المتخصص (د) (المصنف - Classifier): يقرر ما الذي يريده العميل بالفعل.
في الإعداد "الثابت" القديم، كان هؤلاء المتخصصون عالقين في نفس الغرفة وعلى نفس الأجهزة.
- عنق الزجاجة: إذا كان متخصص قاعدة البيانات بطيئاً، يتأخر الطلب بأكمله.
- الهدر: كان عليك إبقاء جميع المتخصصين مستيقظين وجاهزين على مدار الساعة، حتى لو كان المطلوب فقط هو متخصص "التقطيع" في الثالثة صباحاً.
- كابوس "البداية البدة" (Cold Start): إذا أغلق المطعم لمدة ساعة ثم أعاد الفتح، كان على كل متخصص أن يستيقظ، ويتمدد، ويجهز أدواته. كان على العميل انتظار أبطأ متخصص فيهم ليستيقظ قبل الحصول على أي طعام.
2. الحل: "شبكة توصيل ذكية"
بنت Salesforce بنية تحتية جديدة تعمل مثل خدمة توصيل ذكية وديناميكية.
- متلقي الطلبات (خدمة التنبؤ): عندما يطلب العميل طلباً، لا يرسل الموزع الذكي الطلب إلى مطبخ واحد كبير. بدلاً من ذلك، يقوم بتفكيك الطلب إلى أجزاء ويرسله إلى المتخصصين المعنيين بالأمر وهم الأنسب للمهمة.
- التوسع المستقل: إذا طلب 100 شخص "شريحة لحم" (نداءات LLM)، فإن النظام يوظف فوراً 100 طاهٍ للحوم. وإذا طلب 5 أشخاص فقط "سلطة" (نداءات تضمين)، فإنه يوظف 5 طهاة سلطة فقط. هم لا يتنافسون على المساحة في نفس المطبخ.
- بدون خادم (الدفع مقابل الاستخدام): المتخصصون لا يجلسون في مبنى ينتظرون الطلبات. إنهم "عمال سحابيون" يظهرون فقط عند وصول طلب، ويغادرون عند انتهائهم. أنت تدفع فقط مقابل الدقائق التي يعملون فيها فعلياً.
3. حل مشكلة "الاستيقاظ" (البدايات الباردة المتتالية)
اكتشفت الورقة مشكلة معقدة: في النظام المركب، يعتمد المتخصصون على بعضهم البعض. يجب أن ينتهي المتخصص (أ) قبل أن يبدأ المتخصص (ب).
- الطريقة القديمة: إذا أعاد المطعم الفتح، يستيقظ المتخصص (أ) (30 ثانية)، ثم يستيقظ المتخصص (ب) (150 ثانية)، ثم يستيقظ المتخصص (ج) (20 ثانية). ينتظر العميل 180 ثانية إجمالاً.
- خدعة "التحمية المسبقة" الجديدة: النظام ذكي بما يكفي لمعرفة الوصفة. بمجرد استدعاء المتخصص (أ)، يقوم النظام في وقت واحد بإيقاظ المتخصصين (ب) و(ج) في الخلفية.
- النتيجة: بدلاً من الانتظار 180 ثانية، ينتظر العميل حوالي 65 ثانية فقط. تقول الورقة إن هذا قلل وقت "الاستيقاظ" بنسبة 65%.
4. النتائج: أسرع، أرخص، وأكثر سلاسة
بعد تشغيل هذا النظام الجديد لأكثر من عام مع عملاء حقيقيين، إليكم ما حدث:
- السرعة: انخفض "زمن الاستجابة في الحالات القصوى" (tail latency) - أي أسوأ أوقات الانتظار للعملاء البطيئين - بنسبة 50%. الطلبات التي كانت تستغرق 37 ثانية أصبحت تستغرق حوالي 10-11 ثانية.
- السعة: يمكن للنظام التعامل مع 3.9 ضعف عدد الطلبات في نفس الوقت مقارنة بالمطبخ القديم.
- التكلفة: لأنهم توقفوا عن الدفع مقابل العمال غير المستغلين، وفروا 30-40% من التكاليف.
- الموثوقية: إذا مرض أحد المتخصصين (فشل)، فإن النظام لا يغلق المطعم بأكمله. بل يقوم فقط بتوجيه الطلب حول ذلك الشخص (مثلاً: "لا يمكننا فحص قاعدة البيانات، لذا دعونا نعطي إجابة عامة فقط"). يظل المطعم مفتوحاً بنسبة 95% من الوقت، حتى عندما تتعطل بعض الأجزاء.
5. الدروس الرئيسية المستفادة ("أسرار الطهاة")
شارك المؤلفون بعض النقاط الجوهرية لأي شخص يبني هذه الأنظمة:
- البدايات الباردة تتضاعف، ولا تُجمع فقط. إذا كان لديك سلسلة من المهام، فإن وقت الانتظار يتراكم. يجب عليك إيقاظ السلسلة بأكملها دفعة واحدة، وليس واحداً تلو الآخر.
- راقب المسار بالكامل، وليس العمال بشكل فردي. قد يكون العامل سريعاً بمفرده، ولكن إذا كان عالقاً في انتظار شخص آخر، فسيكون الطلب بأكمله بطيئاً. يجب أن ترى "الصورة الكبيرة" للطلب.
- اختبر القطع بشكل فردي. نظرًا لأن النظام نمطي، يمكنك استبدال "طاهي السلطة" فقط بطاهٍ جديد دون طرد "طاهي اللحم". هذا يسمح لهم بتحسين نماذج الذكاء الاصطناوي الخاصة بهم في غض_ين بدلاً من أسابيع.
- التراجع التدريجي أفضل من المثالية. إذا فشل جزء صغير من النظام، فلا ينبغي أن ينهار النظام بأكمله. من الأفضل تقديم إجابة أقل تفصيلاً بدلاً من عدم تقديم أي إجابة على الإطلاق.
الملخص
تتحدث هذه الورقة عن الانتقال من إعداد ذكاء اصطناعي صلب ومكلف بـ "مطبخ واحد"، إلى شبكة مرنة بأسلوب "اقتصاد الأعمال الحرة" (Gig Economy). من خلال معاملة كل أداة ذكاء اصطناعي كعامل منفصل عند الطلب يمكن توسيع نطاقه أو تقليصه فوراً، جعلت Salesforce وكلاء الذكاء الاصطناعي الخاص بها أسرع، وأرخص، وأكثر موثوقية لآلاف المستخدمين من الشركات.
غارق في أبحاث مجالك؟
تصلك نشرة يومية بأحدث الأبحاث المطابقة لكلماتك البحثية المفتاحية — مع ملخصات تقنية، بلغتك.