كيف أقيس ما إذا كان وكيل الذكاء الاصطناعي يعمل فعلاً

جدول المحتويات

محدّث مايو 2026.

TL;DR: معظم المشغلين يتخطون التقييمات كلياً ويفترضون فقط أن وكلاءهم يعملون. إطاري: بناء مجموعة ذهبية من 5–10 مدخلات معروفة مع مخرجات متوقعة، تعريف معايير النجاح/الفشل بلغة بسيطة، ومراجعة السجلات أسبوعياً. لا تبني نظام تقييم مفصّلاً قبل أن يكون لديك 10 تشغيلات حقيقية — هذا هو الفخ الذي يقتل الزخم.

[منظور المشغّل] أدير أكثر من 30 وكيل ذكاء اصطناعي في الإنتاج عبر علامتي التجارية الاستشارية وPickleland، منشأة بيكلبول في بفلوغرفيل، تكساس. في مرحلة ما أدركت أنني كنت أقضي وقتاً أطول في القلق بشأن انحراف الوكلاء من استخدامهم فعلياً. هذا هو إطار التقييم الذي استقررت عليه — لا دكتوراه مطلوبة، لا منصة تقييم مخصصة، لا Python.

المشكلة التي لا يتحدث عنها أحد: الوكلاء ينحرفون في صمت

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

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

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

ما هو التقييم فعلاً (للمشغّلين)

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

ثلاثة مكوّنات:

1. المجموعة الذهبية — 5–10 مدخلات حقيقية رأيتها من قبل، مع مخرجات متوقعة تعلم بالفعل أنها جيدة
2. معايير النجاح/الفشل — قواعد بلغة بسيطة لما يُعدّ نجاحاً
3. فحص مجدوَل — أنت أو مساعدك ينفّذ الاختبار فعلياً على إيقاع منتظم

هذا كل شيء. لا تحتاج إطاراً. تحتاج انضباطاً.

بناء مجموعتك الذهبية

استخرج من سجلات الإنتاج الخاصة بك. ابحث عن 5–10 مدخلات حقيقية تعرف بالفعل كيف تبدو المخرجات الجيدة لها. هذه هي حقيقتك الأساسية.

بالنسبة لوكيل خط أنابيب المحتوى الخاص بي، المجموعة الذهبية هي 5 منشورات نشرتها اجتازت قائمة التحقق الصوتية عندما كتبتها يدوياً. بالنسبة لمروّج أحداث Pickleland، هي 5 منشورات Facebook سابقة حصلت على تفاعل أعلى من المتوسط (تعليقات + مشاركات، ليس مجرد إعجابات).

قواعد للحصول على مجموعة ذهبية جيدة:

• مدخلات حقيقية، وليست افتراضيات اخترعتها
• تضمين حالة حدّية واحدة على الأقل (مدخل صعب، قصير، أو ذو تنسيق غير مألوف)
• الاحتفاظ بالمخرجات المتوقعة موثّقة — لقطة شاشة، ملف نصي، صف في جدول بيانات
• لا تحذف أبداً من المجموعة الذهبية؛ فقط أضف

عندما يُؤكَّد آخر مرة أن الوكيل كان يعمل، اكتب بالضبط كيف بدا “الجيد”. هذا يصبح مخرجك المتوقع.

تحديد معايير النجاح/الفشل

المعايير الغامضة عديمة الفائدة. “يجب أن تكون المخرجات جيدة” ستنجح دائماً لأنك ستبرّرها.

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

قائمة تحقق النجاح/الفشل لوكيل المحتوى:

• المنشور يحتوي على TL;DR في أول 100 كلمة
• لا عبارات مثل “في عالم اليوم المتسارع” أو “كذكاء اصطناعي”
• رقم ملموس واحد على الأقل أو إحصائية
• عدد الكلمات بين 800 و2000
• جميع الروابط الداخلية تعمل (لا أخطاء 404)

لمروّج أحداث Pickleland:

قائمة تحقق النجاح/الفشل لمروّج الأحداث:

• اسم الحدث يتطابق مع التقويم المصدر
• التاريخ والوقت صحيحان
• رابط التذكرة موجود وغير معطّل
• النص أقل من 280 كلمة
• المنشور لا يستخدم عبارات حشو عامة

إذا اجتاز 4 من 5 بنود قائمة التحقق، فالتشغيل ناجح. إذا اجتاز 3 أو أقل، فهو فاشل وأحقق في الأمر قبل التشغيل التالي.

استخدام Claude كحَكَم

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

إليك موجّه الحكم الذي أستخدمه لوكيل المحتوى:

You are evaluating a blog post written by an AI agent. Your job is to check whether it meets the operator's standards.

Evaluate the following post against these criteria:
1. Starts with a direct answer or TL;DR in the first 100 words (YES/NO)
2. Contains at least one concrete number or specific example (YES/NO)
3. Free of AI-speak filler ("As an AI", "in today's fast-paced world", "delve", "it's worth noting") (YES/NO)
4. Word count is between 800 and 2000 words (YES/NO)
5. Tone matches the reference: direct, first-person, opinionated, no fluff (YES/NO)

For each criterion, respond YES or NO with one sentence of explanation.
At the end, output PASS if 4 or 5 criteria are YES, FAIL otherwise.

Post to evaluate:
---
{{post_content}}
---

أشغّل هذا كـ Cloudflare Worker يسحب أحدث مسوّدة، يطلق هذا الموجّه، ويكتب النتيجة في Google Sheet. العملية بأكملها تستغرق 8 ثوانٍ وتكلّف حوالي $0.003 لكل تشغيل.

لمروّج الأحداث، موجّه الحكم أبسط:

You are checking an AI-generated Facebook event post for accuracy and quality.

Source data:
- Event name: {{event_name}}
- Date: {{event_date}}
- Time: {{event_time}}
- Ticket URL: {{ticket_url}}

Generated post:
---
{{generated_post}}
---

Check:
1. Does the post correctly state the event name? (YES/NO)
2. Does the post correctly state the date and time? (YES/NO)
3. Does the post include the exact ticket URL? (YES/NO)
4. Is the post under 280 words? (YES/NO)
5. Is the tone inviting without using generic filler phrases? (YES/NO)

Output PASS if all 5 are YES, FAIL if any are NO. List which items failed.

أين تنظر: سجلات Cloudflare Worker

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

ما أتحقق منه في المراجعات الأسبوعية النموذجية:

• الأخطاء والاستثناءات — أي شيء تعطّل أو انتهت مهلته
• عدد الرموز المميزة — إذا استخدم تشغيل فجأة 3 أضعاف الرموز المعتادة، فشيء ما تغيّر
• ذروات الكمون — التباطؤ المفاجئ يعني عادةً أن الموجّه أصبح أطول أو أن النموذج يعاني
• انحراف طول المخرجات — إذا انخفض متوسط المخرجات من 600 إلى 200 كلمة، فقد غيّر الوكيل سلوكه

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

تقييم جدول البيانات: قبيح لكنه يعمل

قبل أن أمتلك أي أتمتة، كنت أجري التقييمات في Google Sheet. لا أزال أستخدم هذا للوكلاء الجدد في أول 4 أسابيع.

الهيكل:

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

هذا منخفض التقنية بشكل محرج. وهكذا اكتشفت ثلاث انحدارات في الموجّه قبل وصولها إلى الإنتاج.

ما يجب عدم فعله

لا تبني نظام التقييم قبل أن يكون لديك 10 تشغيلات حقيقية. رأيت مؤسسين يقضون أسبوعين في بناء خط أنابيب تقييم متطور لوكيل شغّلوه مرتين فقط. لا تعرف ما يكفي عن كيفية ظهور “الجيد” حتى يكون لديك بيانات إنتاج حقيقية.

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

لا تقيّم كل شيء. اختر الوكلاء 3–5 الذين سيكون فشلهم مؤلماً فعلاً — المخرجات الموجّهة للعملاء، أي شيء ينشر علناً، أي شيء يفعّل دفعة. تخطّ وكلاء الأدوات الداخلية حتى تتوفر لديك طاقة ذهنية.

لا تؤتمت مبكراً جداً. جدول بيانات تستخدمه فعلاً يتفوق على لوحة تحكم Datadog تنسى فحصها. ابدأ يدوياً، أتمت بعد تشغيل الفحص 10 مرات ومعرفة ما تبحث عنه فعلاً.

خلاصة المشغّل

لا يجب أن تكون التقييمات على مستوى هندسي لتكون مفيدة. مجموعة ذهبية من 5–10 مدخلات حقيقية، وقائمة معايير نجاح/فشل، و15 دقيقة من فحص السجلات كل اثنين ستكتشف 80% من انحراف الوكلاء قبل أن يتراكم. ابدأ من هناك. إذا كنت لا تزال تشغّل وكلاء دون أي تقييم، فأنت تطير بدون رؤية — وفي نهاية المطاف سيفشل شيء بشكل علني كافٍ لتتمنى أنك أمضيت الـ 20 دقيقة.