الأتمتة بالقواعد حتمية السلوك، وقابلة للتدقيق، وتشغيلها شبه مجاني، وتفعل الشيء نفسه بالضبط في كل مرة. هذه مزايا لا قيود. إذا كان سير العمل لديكم يناسب محرك قواعد، فوكيل الذكاء الاصطناعي خطوة إلى الوراء: أبطأ وأغلى وغير حتمي، مقابل قدرة على الحكم لا تحتاجونها.
السؤال ليس أيّ التقنيتين أحدث. السؤال هو هل يعاني سير العمل لديكم مشكلة استثناءات.
ما الذي تجيده القواعد؟
كل ما يمكن التعبير عنه بصيغة «إذا حدث كذا فافعل كذا» مع مجموعة شروط محدودة ومعروفة. التوجيه بحسب قيم الحقول، ونقل البيانات بين الأنظمة، والتشغيل عند تجاوز حدّ معيّن، والدفعات المجدولة. أدوات مثل Zapier، Make، n8n، ومعها أدوات أتمتة العمليات الروبوتية (RPA)، تؤدي هذا كله بإتقان وستواصل ذلك.
ولها خصائص لا يستطيع الوكيل مجاراتها: تستطيعون قراءة المنطق، ويستطيع مدقق أن يتحقق منه، وتكلفة كل تنفيذ تكاد تكون صفرًا، وسلوكها في المرة العشرة آلاف مطابق لسلوكها في المرة الأولى. وفي القطاعات الخاضعة للتنظيم تكون هذه الحتمية أحيانًا شرطًا لا تفضيلًا.
لا تضعوا وكيلًا مكان قواعد تعمل جيدًا لمجرد أن الوكلاء أحدث. هذا أكثر الأخطاء المكلفة شيوعًا في هذا المجال.
ما العلامة على أن القواعد لم تعد تكفي؟
ليست التعقيد، بل معدل الاستثناءات. القواعد تعالج الحالات التي توقعتموها. والسؤال هو: أي نسبة من الحجم الفعلي تقع خارجها وتنتهي عند موظف؟
قيسوه لمدة شهر: من كل ما يدخل سير العمل، ما النسبة التي توجّهها الأتمتة توجيهًا صحيحًا دون أي تدخل بشري؟ وبالتقريب:
| معدل الاستثناءات | ماذا يعني | ما العمل |
|---|---|---|
| أقل من 10% | القواعد تناسب العمل | أبقوا عليها واضبطوا الحالات الطرفية |
| من 10% إلى 25% | القواعد تحت ضغط | جرّبوا إضافة قواعد أولًا، ثم قيسوا من جديد |
| أكثر من 25% | العمل يحتاج إلى حكم | الوكيل مبرَّر على الأرجح |
| عدد القواعد يزداد باستمرار | أنتم تكتبون الحكم البشري على شكل فروع | وكيل، أو إعادة تصميم |
الصف الأخير هو العلامة الحقيقية. حين يتراكم في نظام القواعد عشرات الشروط التي لا يفهمها إلا شخص واحد، فأنتم لم تؤتمتوا الحكم البشري، بل كتبتموه في صورة لا يستطيع أحد صيانتها. وتصير الصيانة هي التكلفة، لا الترخيص.
الفروق الثلاثة المهمة
- المدخلات غير المنظَّمة. القواعد تحتاج إلى حقول. إذا وصل العمل نصًّا حرًّا، أو سلسلة رسائل بريد، أو ملف PDF، أو صورة، فالقواعد لا تعمل إلا على ما نظّمه شخص آخر قبلها، وهذا الشخص في الغالب موظف يفرز يدويًا.
- الحكم عند الغموض. سؤال «هل هذه الشكوى عاجلة؟» ليس له حدّ رقمي. القواعد تقرّبه بمؤشرات غير مباشرة (كلمات مفتاحية، نطاق بريد المرسِل) تنجح إلى أن تتوقف عن النجاح.
- العمل المتعدد الخطوات مع الاحتفاظ بالحالة. الوكيل يحمل السياق من خطوة إلى أخرى ويتكيّف حين تفشل خطوة. أما سلسلة القواعد فتنفّذ فرعها ثم تتوقف.
إذا لم ينطبق أي من هذه الثلاثة على سير العمل لديكم، فأنتم لا تحتاجون إلى وكيل. وهذه نتيجة جيدة، لأنها أرخص.
ما التصميم الذي ينجح غالبًا؟
الاثنان معًا. أفضل تصاميم الإنتاج التي نبنيها تضع القواعد أولًا والوكيل على الاستثناءات: المنطق الحتمي يعالج نسبة من 70% إلى 80% من الحالات، ويعالجها بإتقان وبتكلفة قليلة، والوكيل يأخذ فقط ما يخرج عنها.
وهذا أفضل من كل منهما منفردًا. تحتفظون بالحتمية وقابلية التدقيق حيث تتوفران، وتدفعون تكلفة النموذج في الحالات الصعبة فعلًا فقط، ومن المفيد أيضًا أن قائمة الاستثناءات لديكم هي أصلًا مجموعة بيانات مصنَّفة تبيّن بدقة ما على الوكيل أن يعالجه. ويتقلص كذلك حجم الضرر المحتمل، لأن الوكيل يمسّ أقلية من الحجم لا كله.
ما الذي يتغير حين تنتقلون إلى وكيل؟
الوكيل ليس بديلًا يُركَّب مكان القواعد كما هي، وطبيعة تشغيله مختلفة. القواعد إما تعمل وإما تُظهر خطأ، أما الوكيل فقد يخطئ بصمت وبثقة. لذلك ترثون التزامات لم تعرفها القواعد قط: مجموعة تقييمات (evals) لقياس الصحة، وسجلات تتبع (traces) لإعادة بناء القرارات، وضوابط تحصر أسوأ الاحتمالات، وشخص يشغّله بعد الإطلاق (بالإنجليزية).
هذه هي التكلفة الحقيقية للانتقال، لا الرموز (tokens) التي تكلّف سنتات لكل عملية. ولهذا يجب أن يبرّر معدل الاستثناءات هذا الانتقال فعلًا. إذا كنتم تفاضلون بين توسيع قواعدكم وتكليف جهة ببناء وكيل، فمقال البناء أم الشراء يتناول سؤال المصدر، ومقال العلامات الخمس (بالإنجليزية) يختبر هل سير العمل مؤهَّل أصلًا. وحين يكون مؤهَّلًا، يُبنى الوكيل ضمن Gigabit Agents برسوم ثابتة ابتداءً من 8,000 دولار لكل وكيل.
