وكيل أم مساعد أم نص برمجي: أيها تحتاج فعلا؟

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

الإجابة المختصرة

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

ما هو كل واحد منها فعلا

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

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

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

المقارنة التي ينبغي أن تقود القرار

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

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

اختبار تطبقه في دقيقة

خذ المهمة واسأل أربعة أسئلة بالترتيب.

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

أين التنوع: في الأسئلة أم في الإجراءات؟ أسئلة كثيرة مختلفة بإجابات مستقرة تعني مساعدا. وتسلسلات إجراءات كثيرة مختلفة هي حيث يبدأ الوكيل يستحق موضعه.

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

كيف ستثبت أنه فعل الصواب؟ إن لم تستطع الإجابة فلن تستطيع تشغيله، أيا كان النوع الذي اشتريته.

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

هذه النصيحة ليست معاكسة للتيار

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

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

ثلاث حالات من الواقع

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

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

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

ولاحظ أن الثلاث تختلف في بعد واحد حاسم: أين يقع التنوع، وما كلفة الخطأ. ولا تختلف في مدى «تقدم» التقنية.

لماذا يباع الوكيل رغم ذلك

سببان صادقان وثالث أقل صدقا. الصادقان: أن الوكلاء فعلا الإجابة الصحيحة لبعض الأعمال المفتوحة، وأنهم يبهرون في العرض التجريبي لأن العرض أفضل مسار ممكن. والأقل صدقا: أن «وكيل» هي الكلمة التي تبيع الآن، فكثير من البرمجيات التي هي نص برمجي في وسطه نموذج لغوي تسوق بوصفها كذلك.

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

الهجين الذي يكون صحيحا غالبا

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

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

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

كيف تقرأ عرضا

افتح العرض وابحث عن ثلاثة أشياء قبل السعر.

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

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

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

الكلفة الخفية للقدرة الزائدة

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

الأول عبء المراجعة. فالمخرج الحتمي يراجع بالعينة، والمخرج الاحتمالي يراجع أكثر ولمدة أطول، لأن نجاحه في مئة حالة لا يعني نجاحه في الحالة التالية. وهذه ساعات موظفين لا تظهر في العرض.

والثاني كلفة التغيير. فتعديل خطوة في نص برمجي تحرير سطر، وتعديل سلوك وكيل تعديل تعليمات ثم اختبار أنه لم يغير شيئا آخر. والفرق يظهر في المرة العاشرة التي تتغير فيها سياستك لا في الأولى.

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

ماذا تسأل المورد

خمسة أسئلة تفصل من شغل هذه الأنظمة عمن باعها.

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

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

أسئلة شائعة

هل الوكلاء مجرد مساعدات محادثة بخطوات إضافية؟

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

هل الأرخص أن نبدأ بسيطا ونرقي لاحقا؟

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

هل نحتاج وكيلا لاستخدام الذكاء الاصطناعي كما ينبغي؟

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

متى يكون الوكيل هو الإجابة الصحيحة فعلا؟

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

كيف نمنع الوكيل من الانفلات؟

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