الحلقة المفقودة في حوار الذكاء الاصطناعي
الجميع يتحدث عن وكلاء الذكاء الاصطناعي (AI agents). تصفح أي موجز تقني وستجد العشرات من العروض التوضيحية التي تظهر نموذج لغة كبيرًا (LLM) وهو يحجز رحلات طيران، أو يكتب كودًا، أو يجيب على تذاكر الدعم في محادثة واحدة مذهلة. تبدو الرسالة الضمنية واضحة: إذا قمت بربط المستخدم بنموذج LLM، فسيحدث السحر.
هذا الوهم يعمل بشكل رائع في عرض توضيحي مدته خمس دقائق. لكنه ينهار في اللحظة التي يدخل فيها المستخدمون الحقيقيون، والبيانات الحقيقية، والأموال الحقيقية إلى المشهد. في بيئة الإنتاج، لا تكون العلاقة مجرد مستخدم ↔ LLM. بل هي مستخدم ↔ نظام معقد يحتوي بالصدفة على LLM. الجزء من هذا النظام الذي لا يتحدث عنه أحد هو "الحزام" (the harness) — وهو الهيكل الذي يختار، ويوجه، ويحمي، وينظم كل شيء حول النموذج. بدون هذا الهيكل، لن يكون لديك منتج، بل مجرد نموذج أولي.
لماذا ينكسر المسار البسيط
العرض التوضيحي هو بيئة محكومة. الاستعلامات قصيرة، والسياق محدود، والمخاطر منخفضة. يقوم المطور بإجراء استدعاء API واحد، ويحصل على استجابة سلسة، ويصفق الجمهور. لكن بيئة الإنتاج فوضوية. يطرح المستخدمون أسئلة متابعة غامضة. تتوقف واجهات برمجة التطبيقات (APIs) التابعة لجهات خارجية عن الاستجابة (timeout). النموذج الذي أنتج JSON مثاليًا بالأمس قد يبدأ فجأة في إنتاج markdown بدلاً من ذلك. تمتلئ نوافذ السياق (Context windows). وتفعل حدود معدل الاستخدام (Rate limits) في أسوأ لحظة ممكنة.
حلقة "المطالبة-الاستجابة" (prompt-response) الخام ليس لديها إجابة لأي من هذا. فهي لا تعرف أي إصدار من النموذج يجب أن يتعامل مع مهمة معينة. ولا تتذكر ما حدث قبل ثلاث جولات. ولا يمكنها إعادة محاولة استدعاء فاشل، أو تقنين الطلبات عندما ترتفع التكاليف، أو تنقية المخرجات قبل وصولها إلى قاعدة بياناتك. هذه ليست حالات استثنائية، بل هي السمات المحددة للبرمجيات في العالم الحقيقي. والتعامل معها هو مهمة "الحزام" (the harness).
ما الذي يفعله "الحزام" فعليًا
فكر في "الحزام" كطبقة هندسية تحول نموذج اللغة من مجرد مولد نصوص ذكي إلى مكون خدمة موثوق. مسؤولياته ملموسة وغير براقة، وهذا هو بالضبط السبب في تجاهلها.
اختيار النموذج للمهمة الحالية. لا يحتاج كل تفاعل إلى أقوى نموذج أساسي متاح. فبعض المهام تتطلب قدرة استدلال خام؛ بينما تحتاج مهام أخرى ببساطة إلى السرعة والتكلفة المنخفضة. يقوم "الحزام" المبني جيدًا بتوجيه الطلبات بذكاء. على سبيل المثال، قد يستخدم وكيل دعم العملاء نموذجًا سريعًا وغير مكلف لتصنيف نية الرسالة الواردة — سواء كانت طلب استرداد أم سؤالاً عن الشحن. إذا أشارت النية إلى نزاع معقد حول السياسات، يقوم "الحزام" بتصعيد المهمة إلى نموذج استدلال أثقل. وإذا أراد المستخدم فقط رابط تتبع، فإن النموذج الخفيف يجيب فورًا وتظل معدلات استهلاكك للموارد (burn rate) معقولة.
إدارة تدفق البيانات. التطبيقات الحقيقية لا تعيش في فراغ. غالبًا ما يحتاج وكيل الذكاء الاصطناعي إلى سحب مستندات من مخزن متجه (vector store)، والاستعلام عن نظام إدارة علاقات العملاء (CRM)، وقراءة نشاط المستخدم الأخير، ثم دمج كل ذلك في استجابة متماسكة. يدير "الحزام" عملية الاستيعاب هذه. فهو يجلب أجزاء السياق الصحيحة، ويتأكد من ملاءمتها لحدود الرموز (tokens) دون فقدان الصلة، وينظمها للنموذج، ويمرر المخرجات الناتجة إلى النظام التالي في السلسلة. بدون هذا التنظيم، سيعاني النموذج إما من نقص السياق أو الغرق في الضجيج.
إدارة الأخطاء. تفشل نماذج LLM بطرق لا تفشل بها الخدمات التقليدية. فهي تهلوس بمخرجات مهيكلة. وتعيد إكمالات فارغة. وتخالف تعليمات التنسيق بمجرد تغير إصدار النموذج الأساسي قليلاً. يتعامل "الحزام" مع هذه الإخفاقات كأمر متوقع وليس كمفاجآت. فهو يتحقق من صحة المخططات (schemas)، ويلتقط الاستجابات المشوهة، ويطبق منطق إعادة المحاولة مع التراجع الأسي (exponential backoff)، ويلجأ إلى مزود ثانوي أو نتيجة مخبأة (cached) عندما يتعثر الطرف النهائي الأساسي. وعندما يفشل كل شيء، فإنه يصعد الأمر إلى مشغل بشري بدلاً من تقديم هراء صامت لعميل يدفع مقابل الخدمة.
ضمان موثوقية النظام. تعني بيئة الإنتاج مستخدمين متزامنين، وسقوفًا للتكاليف، وزمن استجابة (latency) غير متوقع. يفرض "الحزام" حدود معدل الاستخدام، ويدير تجميع الاتصالات (connection pooling)، وينفذ قواطع الدائرة (circuit breakers) حتى لا يتسبب مزود نموذج واحد بطيء في تجميد تطبيقك بالكامل. كما يقوم بتسجيل كل تفاعل حتى تتمكن من تتبع سبب انحراف جلسة معينة، ويقوم بإصدار نسخ من مطالباتك (prompts) حتى لا يؤدي أي نشر (deployment) إلى إعادة كتابة شخصية وكيلك عن طريق الخطأ دون وجود سجلات تدقيق (audit trails).
نفس النموذج، ونتائج مختلفة تمامًا
يشرح هذا ظاهرة تُربك الكثير من فرق المنتجات. يمكن لشركتين أن تبدآ بنفس النموذج الأساسي (foundation model) تماماً—نفس الأوزان، ونفس نافذة السياق، ونفس تاريخ انقطاع التدريب—وتقدمان تجارب تبدو وكأنها من عالمين مختلفين. إحداهما تبدو هشة، بطيئة، ونسّاءة بشكل غريب. والأخرى تبدو سريعة الاستجابة، متسقة، وموثوقة.
الفرق لا يكمن أبداً في النموذج نفسه، بل في النظام المحيط به. فقد تعامل فريقٌ مع النموذج باعتباره المنتج بأكمله، بينما تعامل الفريق الآخر معه كعنصر واحد داخل بنية هندسية منضبطة. يكمن هذا الانضباط في "الإطار" (harness) المحيط بالنموذج.
التحول من الأوامر (Prompts) إلى البنية التحتية (Architecture)
ركزت بدايات تطوير الذكاء الاصطناعي على هندسة الأوامر (prompt engineering) وجعلتها في الصدارة. كان تعديل الصياغة، وإضافة الأمثلة، وإدراج تعليمات لعب الأدوار كفيلاً بتحسين جودة المخرجات بشكل كبير. لا تزال هذه المهارة مهمة، لكن عوائدها بدأت تتناقص كميزة تنافسية. لا يمكنك حل مشكلة غياب سياسة إعادة المحاولة (retry policy) أو مسار بيانات متشابك يسرب سياقاً خاصاً إلى استجابة عامة، بمجرد تحسين الأوامر.
التحول الحقيقي الذي يحدث الآن هو الانتقال نحو هندسة البرمجيات. يقوم المهندسون بتصميم آلات الحالة (state machines)، وتحديد واجهات صارمة بين طبقة النموذج ومنطق التطبيق، والتعامل مع "عدم الحتمية" (non-determinism) كأولوية هندسية أساسية. إنهم يطرحون أسئلة تتعلق بالأنظمة الموزعة: كيف تستمر الحالة عبر محادثة متعددة الأدوار؟ ماذا يحدث عندما تكون أداة تابعة غير متاحة؟ كيف نختبر نظاماً مكونه الأساسي احتمالي؟ هذه هي الأسئلة التي تفرق بين "اللعبة" و"الأداة".
البناء من أجل الإنتاج: القابلية للملاحظة والتحكم
إذا كنت جاداً بشأن إطلاق منتجك، فإن الإطار المحيط يتطلب صفتين فوق كل شيء: القابلية للملاحظة (observability) والتنسيق (orchestration).
تعني القابلية للملاحظة (Observability) قدرتك على رؤية ما استلمه النموذج، وما أعاده، والوقت الذي استغرقته كل خطوة. تعني تتبع حلقة اتخاذ القرار للوكيل (agent) عبر أربع عشرة عملية استدعاء للأدوات، وتحديد المكان الذي بدأ فيه التكرار أو الانحراف عن المهمة بدقة. بدون هذه الرؤية، يصبح تصحيح أخطاء نظام الذكاء الاصطناعي مثل إصلاح محرك سيارة في الظلام.
أما التنسيق (Orchestration) فيعني بقاء منطق العمل الخاص بك منفصلاً عن طبقة التفاعل مع النموذج. يعني إصدار نسخ من الأوامر (versioning prompts) بنفس الطريقة التي تصدر بها نسخاً من الكود، حتى لا يؤدي أي نشر جديد إلى تغيير السلوك بصمت. يعني اختبار أنماط الفشل عمداً—مثل قطع اتصال واجهة برمجة التطبيقات (API) في منتصف الطلب، أو تقديم نتائج أدوات مشوهة، أو محاكاة تجاوز نافذة السياق—لمعرفة ما إذا كان الإطار سيحافظ على استقرار النظام. تظهر أطر العمل وتختفي، وسواء اعتمدت مكتبة تنسيق جاهزة أو قمت ببناء مكتبتك الخاصة، فإن الانضباط أهم من اسم العلامة التجارية.
الخلاصة الحقيقية
ستستمر النماذج الأساسية في التحسن؛ ستصبح أسرع، وأرخص، وأكثر قدرة. لكن المحرك الأقوى لا يصلح الهيكل المكسور. الفرق التي ستنتصر في السنوات القليلة القادمة ليست تلك التي تملك وصولاً لأفخم النماذج، بل هي الفرق التي بنت إطاراً موثوقاً، وقابلاً للملاحظة، ومنسقاً بشكل جيد. سيتمكنون من تبديل النماذج دون إعادة كتابة تطبيقاتهم. سيتحكمون في التكاليف لأن الإطار يحكم كل رمز (token). وسينامون بهدوء طوال الليل لأن أنظمتهم تتعامل مع الفشل بسلاسة.
توقف عن الهوس بالنموذج بمعزل عن غيره، وابدأ بالهوس بالنظام الذي يشغله. المستقبل ينتمي للمهندسين الذين يبنون أنظمة أذكى حول نماذج ذكية.
هذا المقال يستند إلى أفكار نوقشت في الأصل بواسطة Abdulaziz Zos في "Beyond The Model".
لمزيد من النقاشات حول هندسة الذكاء الاصطناعي وتصميم الأنظمة، تفضل بزيارة GyaanSetu learning community.