LLM-First أو Code-First؟ أين ينتمي الذكاء في الذكاء الاصطناعي الإنتاجي

كيفية اتخاذ القرار بشأن ما يجب أن يتعامل معه النموذج، وما يجب أن يتعامل معه الكود الخاص بك، وكيفية ربط الاثنين.

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

هذا التحول قسّم المجال إلى قسمين – LLM-First أو Code-First

في بنية LLM-First، يكون النموذج في المركز ويقرر ما سيحدث بعد ذلك. يقرأ الطلب، يختار أداة، يحدد ترتيب العمليات، يتحقق من النتائج المتوسطة، ويغير مساره عندما يحتاج إلى ذلك.

في بنية code-first، يظل البرنامج/الكود مسؤولاً عن الترتيب، وقواعد الأعمال، والتحقق، والأذونات، والتنفيذ. يكون الـ LLM هنا كأخصائي يستدعيه الكود عندما تكون هناك حاجة لفهم اللغة أو توليدها.

يحب الناس الجدال حول أيهما أفضل. أعتقد أن هذا هو الجدال الخاطئ. السؤال الأفضل هو أين ينتمي كل نوع من الذكاء. أقوى الأنظمة الإنتاجية التي رأيتها نادراً ما تكون إما واحدة فقط أو الأخرى. فهي تمزج بين التفكير الاحتمالي والتحكم الحتمي، وتفعل ذلك عن قصد.

لماذا يُعَدّ LLM-First جذابًا للغاية

يعمل البرنامج التقليدي بشكل ممتاز عندما يمكنك تحديد المتطلبات بوضوح. على سبيل المثال، يختار المستخدم منتجًا، يُدخل مبلغًا، ويُرسل دفعة. تقوم بتعريف الحالات المسموح بها، وقواعد التحقق، وحالات الخطأ، وتسلسل المعاملات في الكود. انتهى.

اللغة الطبيعية لا تتعاون بهذه الطريقة. تخيّل أن يكتب مستخدم: “اعثر على المعاملات التي تبدو غير عادية، واشرح ما حدث، وأخبرني بما يجب أن أتحقق منه أولاً.”

لا يوجد مسار ثابت لهذا الطلب. هنا يجب على النظام أن يقرر ما معنى “غير عادي”، ويحدد أي البيانات مهمة، وربما يستدعي عدة أدوات، ويوازن الرد، ويكتب شرحًا يمكن للشخص استخدامه. لا فريق من المهندسين/لا كود سيتوقع كل صياغة وكل تركيبة من الطلبات مسبقًا.

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

Anthropic’s بناء وكلاء الذكاء الاصطناعي الفعّال دليل يوضح تمييزًا أعود إليه باستمرار. سير عمل, تتبع النماذج والأدوات مسارات يحددها كودك. في وكيل، يوجه الـ LLM عمليته الخاصة ويقرر كيفية استخدام أدواته. يوصي الدليل نفسه بالبدء بأبسط بنية تحل المشكلة، بدلاً من إضافة تعقيد وكالي بالانعكاس. سأؤكد تلك النصيحة مرتين.

حدود “دع النموذج يقرر”

يمكن للنموذج التفكير في ما يجب أن يحدث. التفكير ليس هو نفسه تنفيذ قاعدة.

على سبيل المثال، خذ سير عمل مالي. قد يكون الـ LLM ممتازًا في فهم “أرسل نفس المبلغ الذي أرسلته الشهر الماضي إلى نفس المورد”. لكن هل يجب عليه أيضًا أن يقرر ما إذا كان التحويل مصرحًا به، ويحسب الحدود التنظيمية، ويتحقق من ملكية الحساب، ويتجاوز سياسة الأمان، وينفذ المعاملة؟

على الأرجح لا. هذه الوظائف حتمية، قابلة للاختبار، قابلة للتدقيق، وقابلة للتنفيذ، وهذا بالضبط ما يتقنه البرنامج التقليدي. يزداد الخطر مع حصول النماذج على الأدوات. دليل OWASP لأمن الذكاء الاصطناعي التوليدي يشير إلى الوكالة المفرطة كخطر كبير: إعطاء نظام قائم على الـ LLM مزيدًا من الوظائف أو الأذونات أو الاستقلالية أكثر مما تحتاجه مهمته. مخرجات نموذج غريبة أو مُعدَّلة هي شيء واحد عندما ينتج نصًا. إنها مسألة أكبر بكثير عندما يستطيع النموذج أن يتصرف في العالم الحقيقي.

لا يعني أي من هذا أن النماذج يجب أن لا تتخذ إجراءات أبدًا. بل يعني أن استقلالية النموذج يجب أن تكون مقيدة بالسلطة الحتمية.

ما زال Code-First مهمًا

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

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

هذا يتماشى مع التفكير الأوسع في الحوكمة. الـNIST AI Risk Management Framework يطلب من المؤسسات إدارة مخاطر الذكاء الاصطناعي عبر التصميم، التطوير، النشر، والاستخدام. رفيقه Generative AI Profile يضيف أن الأنظمة التوليدية قد تحتاج إلى إشراف إضافي، توثيق، مراجعة، وضوابط، حسب مستوى المخاطر المعني.

لذا أجد أنه من المفيد تقسيم كل قرار تصميم إلى سؤالين:

ماذا يجب أن يحدث؟

و

ما هو المسموح بحدوثه؟

غالبًا ما يمكن لنموذج اللغة الكبير المساعدة في الأول. عادةً ما يجب أن تتولى الأنظمة الحتمية الثاني.

النمط الهجين: التفكير احتماليًا، التنفيذ حتميًا

في معظم تطبيقات المؤسسات، الجواب العملي هو مزيج. يعمل نموذج اللغة الكبير كطبقة تفسير وتفكير. تعمل الخدمات الحتمية كطبقة تنفيذ وتطبيق.

إليك مثال. لنفترض أن مساعدًا ذكائيًا يساعد المطورين على إنشاء بيئات اختبار API مؤقتة، ويكتب مطور: “أعطني بيئة تجريبية لتدفق عمل إلحاق العملاء.”

يمكن للنموذج اللغوي تفسير ذلك، وتحديد أي تدفق عمل يُقصد على الأرجح، وقراءة الوثائق، واقتراح أي واجهات برمجة تطبيقات قد تكون ذات صلة. لكن إنشاء البيئة فعليًا لا ينبغي أن يعتمد على نص مولد حر. يمكن للكود التأكد من وجود واجهات البرمجة المطلوبة، والتحقق من عقودها، وفحص التفويض، وتطبيق حدود الموارد، وتوليد تكوين معتمد، وتشغيل النشر.

التقسيم التقريبي يبدو هكذا:

• نموذج اللغة الكبير: الفهم، التفكير، التصنيف، الاقتراح، التلخيص.
• الكود: التحقق، التفويض، الحساب، التخزين، التطبيق، التنفيذ.

كل جانب يقوم بالعمل الذي يتقنه، ولا يُطلب من أي منهما أن يتظاهر بقدرات الآخر.

الحدود تصبح أكثر أهمية مع زيادة قوة الوكلاء

تصبح هذه الفجوة أكثر أهمية كلما انتقلنا من المساعدين إلى الوكلاء. المساعد الذي يقدم إجابة سيئة يسبب إزعاجًا لشخص ما. أما الوكيل الذي يمتلك صلاحية كتابة في بيئة الإنتاج فيمكن أن يسبب فوضى أكبر بكثير.

الإصلاح ليس بالضرورة إزالة الاستقلالية. إنه إضافة الاستقلالية تدريجيًا مع الحفاظ على نقاط التحكم الصريحة في مكانها. إرشادات Google حول الأنظمة متعددة الوكلاء توصي بزوج السلوك الديناميكي للذكاء الاصطناعي مع ضوابط أمان حتمية، والرصد، وتعريف واضح للاستقلالية، وإشراف بشري للسيناريوهات الحرجة للأعمال.

يمكن أيضًا دمج موافقة الإنسان في سير العمل نفسه بدلاً من أن تكون شبكة أمان غير رسمية. Microsoft’s agent framework documentation، على سبيل المثال، يدعم استدعاءات الأدوات التي تتوقف حتى يوافق شخص صراحةً على العملية المطلوبة.

المبدأ بسيط: كلما زادت عواقب الفعل، يجب أن تكون الضوابط الحتمية المحيطة به أقوى.

خمسة أسئلة يجب طرحها قبل تسليم مهمة إلى نموذج لغة كبير

عندما أقرر ما إذا كان يجب أن يكون المكوّن LLM أولاً أم كود أولاً، أستعرض هذه الأسئلة:

1. هل للمهمة إجابة صحيحة موضوعية واحدة؟ إذا كان الأمر كذلك، فالميل إلى الكود الحتمي. لا ينبغي أن تتغير حسابات الضرائب، الصلاحيات، والتحقق من صحة المخطط لأن نموذجًا قرأها بشكل مختلف اليوم.
2. هل تتضمن لغة غامضة أو معلومات غير منظمة؟ إذا كان الأمر كذلك، قد يضيف نموذج اللغة الكبير قيمة حقيقية.
3. ماذا يحدث إذا أخطأ النموذج؟ الهندسة الصحيحة لتلخيص اجتماع تختلف كثيرًا عن الهندسة الصحيحة لبدء دفعة مالية.
4. هل يمكن التحقق من صحة المخرجات بشكل مستقل؟ تصبح الخطط التي يولدها نموذج اللغة الكبير أكثر أمانًا عندما يمكن للقواعد الحتمية فحص الإجراء الناتج قبل تنفيذه.
5. هل تحتاج هذه فعلاً إلى وكيل؟ إذا كنت تعرف الخطوات مسبقًا، فإن سير عمل عادي مع عدد قليل من استدعاءات نموذج اللغة الكبير يكون عادةً أبسط، وأرخص، وأسهل في الاختبار، وأسهل في التشغيل.

هذا السؤال الأخير يستحق اهتمامًا إضافيًا. الوكلاء أقوياء بالضبط لأنهم يستطيعون التعامل مع مواقف لا يمكنك فيها توقع كل خطوة. لكن إذا كنت قادرًا على توقع الخطوات، فإن تحويلها إلى مشكلة تفكير مفتوحة غالبًا ما يضيف تباينًا دون إضافة ذكاء.

الموثوقية خاصية معمارية، ليست موجهًا

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

يجب على نظام الإنتاج أن يفترض أن مخرجات النموذج قد تكون أحيانًا غير مكتملة أو مشوهة أو غير متوقعة أو خاطئة تمامًا. تُدرج قائمة OWASP Top 10 لتطبيقات LLM مخاطر مثل حقن المطالبة و معالجة غير صحيحة للمخرجات، مما يعزز عادة أساسية: التعامل مع مخرجات النموذج كمدخل غير موثوق به للأنظمة اللاحقة، وليس كتعليمات تُنفّذ تلقائيًا.

هذا يغيّر السؤال الذي تطرحه. بدلاً من “كيف أكتب مطالبة تجعل النموذج يتبع القاعدة دائمًا؟”، اسأل “كيف أصمم النظام بحيث لا يمكن كسر القاعدة حتى عندما يرتكب النموذج خطأ؟”

هذه مشكلة في هندسة البرمجيات، ليست مشكلة في صياغة المطالبة. يمكن للمطالبة أن تخبر الوكيل بعدم تنفيذ إجراء غير مصرح به. يمكن لخدمة التفويض أن توقفه فعليًا. هذان التحكمان ليسا متكافئين.

ما وراء الجدل: أنظمة النية أولاً

بعد التفكير في كل ذلك، توصلت إلى أن جدال LLM‑first مقابل code‑first يشير إلى فكرة ثالثة: النية أولاً بنية.

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

طلب مثل “ساعدني في حل مشكلة دفع العميل” قد يتحول إلى سلسلة معالجة: فهم النية، استرجاع المعاملة، تحديد سبب الفشل، اقتراح حل، طلب الموافقة، تنفيذ العملية الموافق عليها.

بعض هذه المراحل تستفيد من استدلال نموذج اللغة. الأخرى يجب أن تكون خدمات ثابتة. لا تُحدد الهندسة بناءً على ما إذا كان الذكاء الاصطناعي أو الشيفرة “يفوز”. بل تُحدد بناءً على مكان قبول عدم اليقين.

الخلاصة

مع تحسن النماذج، سيغري ذلك إعطاؤها سيطرة على أجزاء أكبر وأكبر من البنية. أحيانًا سيكون ذلك القرار الصحيح. في أنظمة أخرى، سيكون التصميم الأكثر تعقيدًا هو الذي يمنح النموذج عمدًا أقل سلطة.

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

من المحتمل أن مستقبل الذكاء الاصطناعي للمؤسسات ليس LLM‑first بحتًا ولا code‑first بحتًا. إنه LLM حيث يتطلب عدم اليقين الذكاء، والشفرة حيث تتطلب اليقين السيطرة.

قد يكون هذا التمييز أكثر أهمية بكثير من النموذج الذي تختاره.