كيف تجعل وكلاء AI جَديرين بالثقة؟ قصة Elicit و AshPL — دليل مبسط 2026

المشكلة: لماذا الثقة مهمة في وكلاء AI؟ 🤔

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

عندما نستخدم وكيل ذكاء اصطناعي (AI Agent) — وهو برنامج يستطيع التفكير واتخاذ القرارات بنفسه — لا يكفي أن نرى النتيجة النهائية فقط. الأهم هو آلية العمل (mechanism) التي أوصلت الوكيل إلى هذه النتيجة. تخيّل أن طبيبين شخصا حالتك بنفس التشخيص. ستثق بالطبيب الذي شرح لك خطوات تشخيصه بالتفصيل أكثر من الطبيب الذي قال “هذا هو التشخيص” دون تفسير.

هذه الفكرة البسيطة — “الآلية أهم من النتيجة” — هي التي قادت فريق Elicit لبناء حل مبتكر: لغة برمجة خاصة بهم اسمها AshPL. في هذا المقال، سنشرح هذه القصة بعيداً عن التعقيدات التقنية، بلغة يفهمها الجميع.

ما هي لغة التخصص (DSL)؟ تشبيه بسيط 🧩

قبل أن ندخل في التفاصيل، لنفهم أولاً ما هي لغة التخصص أو DSL (Domain-Specific Language).

تخيّل أنك تريد كتابة وصفة طبخ. يمكنك استخدام لغة عربية كاملة (مثل “خذ البصل وقطّعه إلى مكعبات صغيرة ثم اقله في زيت الزيتون”). لكن لو كان لديك لغة مخصصة للطبخ، ستكتب بدلاً من ذلك: “بصل | مكعبات | قلي | زيت زيتون”. هذه لغة مبسطة لها كلماتها الخاصة التي تفهمها كل من يطبخ.

بالضبط هذا ما تفعله لغة التخصص (DSL) في عالم البرمجة. هي لغة برمجة مبسطة ومختصرة صُمّمت خصيصاً لمجال معين — في حالة Elicit، المجال هو البحث العلمي واتخاذ القرارات المهمة.

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

الثلاثية الذهبية: ما الذي يجعل وكيل AI جَديراً بالثقة؟ 🏆

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

1️⃣ قابلية الفهم (Legibility)

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

2️⃣ الحفاظ على الاتساق (Fidelity Through Iteration)

عندما تطلب من وكيل أن يعدّل أو يضيف خطوة جديدة، يجب ألا ينحرف عن هدفه الأصلي. تخيّل أنك تطلب من مساعد أن يبحث لك عن “أفضل مطاعم البيتزا”. ثم تقول له “أضف تقييمات العملاء”. يجب أن يضيف التقييمات دون أن ينسى أن المطلوب أصلاً هو مطاعم البيتزا! هذا ما تفعله AshPL — كل تعديل يبني على الخطة الأصلية دون “انجراف” (drift).

3️⃣ التنفيذ الأمين (Faithful Execution)

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

تعريف على AshPL: لغة Elicit الخاصة 💻

AshPL (وتُنطق “آش بي إل”) هي لغة التخصص (DSL) التي بنتها شركة Elicit لوكيلها البحثي. لكن ما يميزها ليس تعقيدها — بل بساطتها!

ماذا يعني أن AshPL “ناقصة تورنغ”؟

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

لماذا تشبه Python؟

هذا اختيار ذكي! AshPL هي مجموعة فرعية (subset) من لغة Python — أشهر لغة برمجة في العالم. لماذا؟ لأن نماذج الذكاء الاصطناعي (مثل Claude من Anthropic) مدربة على ملايين الأمثلة من كود Python. عندما يكتب الوكيل بلغة تشبه Python، فهو لا يحتاج “تعلّم قواعد جديدة” — فقط استخدم جزءاً مما يعرفه بالفعل.

أدوات خاصة بالبحث العلمي

ما يميز AshPL حقاً هو الأدوات المضمنة (primitives) التي أضافها فريق Elicit لتتناسب مع مجالهم — البحث العلمي. مثلاً، هناك أدوات لـ “البحث عن الأوراق الأكاديمية” و”جلب التجارب السريرية” و”فلترة النتائج”. هذه ليست أوامر برمجة عامة، بل أدوات صُممت خصيصاً لعمل الباحثين.

كيف تعمل AshPL داخل Elicit؟ رحلة من السؤال إلى الإجابة 🔄

الآن فهمنا ما هي AshPL، لكن كيف تعمل فعلياً؟ تخيّل أن المستخدم يسأل Elicit سؤالاً بحثياً. هذه الرحلة المختصرة:

1. الوكيل الرئيسي (Curator) يكتب خطة AshPL بناءً على سؤال المستخدم
2. الخطة تُفحص ⏩ تلقائياً للتأكد من خلوها من الأخطاء النحوية ونوع البيانات (type check)
3. إذا وجد خطأ → يُعاد الكود للوكيل ليصححه (وهذا رخيص وسريع)
4. بعد التأكد من صحة الكود → مفسِّر (interpreter) يقوم بتنفيذ الخطة حرفياً
5. كل نتيجة تُخزَّن في ذاكرة التخزين المؤقت (cache) لتجنب إعادة العمل
6. عند التعديل → الوكيل يعيد كتابة خطة جديدة → تُفسَّر من الصفر → لكن النتائج القديمة تُستعاد بسرعة من الذاكرة

هذه الدورة: اكتب → فسّر → صحّح → فسّر هي جوهر عمل Elicit. وكما قال جيمس: “نحن نُعيد تفسير البرنامج كاملاً من الصفر في كل مرة، لكن بفضل التخزين المؤقت (memoization)، معظم العمل السابق نستعيده فوراً.”

العرض العملي: كيف تبدو AshPL أثناء العمل 🎬

في المحاضرة، عرض جيمس مثالاً حقيقياً: قام بتوجيه Elicit لعمل “دراسة تنافسية للشركات والمؤسسات المهتمة بنماذج الأساس (Foundation Models) في علم الأحياء.”

الوكيل بدأ بطرح سؤال توضيحي: “هل تريد نظرة عامة واسعة أم تركيز على شيء محدد؟” بعد إجابة المستخدم، بدأت خطة AshPL في العمل:

النتيجة النهائية كانت جدولاً تنظيمياً يضم الشركات المهتمة بمجال البيولوجيا ونماذج AI — مثل Meta و Microsoft Research و GDM وغيرها. كل معلومة في الجدول: أسماء النماذج، الاختصاصات، والتعاونات البارزة، تم استخراجها عبر تنفيذ خطة AshPL خطوة بخطوة.

الأكثر إثارة: يمكن للمستخدم (أو وكيل آخر) النقر على أي نتيجة ورؤية كود AshPL الذي أنتجها! هذا هو معنى “قابلية الفهم” (legibility) — كل شيء مفتوح للفحص.

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

السرعة أم الدقة؟ خيار صعب ⚖️

أحد أهم النقاط التي ناقشها جيمس هو المفاضلة بين السرعة والدقة (speed vs rigor trade-off).

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

إذا كنت تبحث عن فهم أعمق لكيفية بناء أنظمة وكلاء قابلة للمراقبة، ننصحك بقراءة مقالنا عن مراقبة وتقييم وكلاء AI في الإنتاج.

ما الذي يتطلبه بناء نظام كهذا؟

جيمس أشار إلى أن بناء لغة التخصص (DSL) نفسها كان الجزء الأسهل! الأمور الأكثر تعقيداً كانت:

• معالجة المقاطعات (Interrupt handling): عندما يضيف المستخدم أوامر جديدة أثناء عمل الوكيل
• عزل بيانات الاعتماد (Credential isolation): لمنع تسرب مفاتيح API
• إدارة جلسات المستخدم (Session rehydration): العودة لجلسة قديمة واستكمال العمل
• التقييم والاختبار (Evals): اختبار نظام يكتب ويشغّل برامج على الطاير

الخلاصة: الآلية هي الأهم 🎯

في نهاية محاضرته، عاد جيمس إلى سؤاله الأول: “إذا أنتج نظامان نفس النتيجة، هل تثق بهما بالتساوي؟” والإجابة: لا، لأن الآلية هي ما يبني الثقة.

Elicit لم تبنِ AshPL لأنها “أفضل طريقة” لبناء وكلاء AI. بنتها لأن احتياجاتها تستدعي ذلك: جودة عالية، موثوقية، وشفافية كاملة. كل وكيل AI يختلف عن الآخر، وكل شركة لها احتياجاتها الخاصة.

الرسالة الأهم: لا يهم أي أداة أو لغة تستخدم — المهم هو أن تهتم بآلية عمل وكيلك. تأكد من أن خطواته مفهومة، وأنه يلتزم بخطته، وأن تعديلاته لا تنحرف عن الهدف. هذه هي المبادئ التي تجعل AI أداة موثوقة، وليس صندوقاً أسود غامضاً.

تم إعداد هذا المقال من محاضرة لجيمس برادي (شركة Elicit) على منصة Anthropic. شاهد المحاضرة الأصلية على يوتيوب.