كيف تُقيّم وكلاء الذكاء الاصطناعي في الإنتاج: نظام الطبقات الثلاث الذي نستخدمه على المسارات الحية

كيف تُقيّم وكلاء الذكاء الاصطناعي في الإنتاج: نظام الطبقات الثلاث الذي نستخدمه على المسارات الحية

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

في تشغيل واحد من يونيو 2026 لخط أنابيب محتوى Techsy الخاص بنا، أنتج الوكيل منشور مدونة يبدو مثالياً، ونجحت درجة المخرج النهائي في اجتيازه. نظيف تماماً. إلا أنه قبل ثلاث خطوات، كان منشئ الملخص (brief-creator) قد استدعى أداة البحث الداخلي الخاطئة، فانتهى الأمر بنصف روابط المجموعة تشير إلى لا مكان. معرفة كيفية تقييم وكلاء الذكاء الاصطناعي في الإنتاج يعني تسجيل نقاط المسار الكامل الذي سلكه الوكيل، لا الإجابة التي انتهى إليها بالصدفة.

أهم النقاط:

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

لماذا يختلف تقييم وكلاء الذكاء الاصطناعي في الإنتاج عن تقييم نماذج اللغة الكبيرة؟

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

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

أربعة أمور تنكسر بمجرد أن يبدأ نموذج اللغة الكبير بالتصرف من تلقاء نفسه:

• متعدد الخطوات. قد يبحث وكيل الدعم في قاعدة معرفة، ثم يستدعي واجهة برمجة طلبات، ثم يصوغ رداً. سجّل الرد فقط وستكون أعمى عن الخطوتين اللتين حدّدتاه.
• غير حتمي. درجة الحرارة (temperature)، وتحديثات أوزان النموذج، وكمون الأدوات تعني أن الطلب ذاته يسلك مساراً مختلفاً في كل تشغيل. يجب أن يصمد تقييمك أمام هدف متحرك.
• ذو حالة. الوكلاء يكتبون إلى قواعد بيانات، ويرسلون رسائل بريد، ويستردون الطلبات. الإجراء الخاطئ ليس جملة سيئة، بل أثر جانبي لا يمكنك التراجع عنه.
• تراكمي. خطوة ثانية خاطئة قليلاً في تشغيل من 12 خطوة تُسمّم كل شيء بعدها، ويمكن للإجابة النهائية أن تبدو جيدة رغم ذلك.

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

الوكيل الذي يُعيد الإجابة الصحيحة عبر مسار خاطئ لم ينجح. لقد فشل بصمت، وسيفشل بصوت عالٍ في المرة القادمة حين لا يحدث الإنقاذ المحظوظ.

ما المقاييس التي تهم فعلاً لوكلاء الذكاء الاصطناعي في الإنتاج؟

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

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

تعتمد معظم هذه المقاييس على LLM كحكم (نموذج يُقيّم مخرجات نموذج آخر). إنها الحيلة القياسية وتتوسّع جيداً، لكنها صاخبة: غالباً ما يشارك الحكم نقاط عمى الوكيل، لذا عامل درجاته كإشارة، لا كحقيقة مطلقة. سنعود إلى معايرة الحكم في القسم السابع.

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

كيف تُقيّم مسار الوكيل بدلاً من إجابته النهائية؟

لتقييم مسار الوكيل، تُقيّم التتبع (trace): السجل المرتب لكل خطوة تفكير واستدعاء أداة ومخرج وسيط أنتجه الوكيل. تقييم المستوى الجزئي (span-level) يُقيّم كل خطوة فردية (span) بحيث تحدد الخطوة الدقيقة التي فشلت، بدلاً من معرفة أن التشغيل العام قد فشل فحسب.

تخيل التتبع كأثر مكدس (stack trace) للتفكير. كل span هو خطوة واحدة: استرجاع، أو استدعاء أداة، أو تسليم لوكيل فرعي. المراقبة (observability) تلتقط تلك الـ spans؛ والتقييم يُقيّمها. (لا تتبع لديك بعد؟ دليلنا لمراقبة الذكاء الاصطناعي يغطي طبقة المراقبة التي يقوم عليها التقييم، ومقارنتنا بين LangGraph وCrewAI وOpenAI Agents SDK توضح كيف يبدو التتبع في كل منها.)

لماذا تُقيّم كل span بدلاً من نقطة النهاية فقط؟ الأخطاء التراكمية. إذا استرجعت الخطوة الثانية المستند الخاطئ، فإن الخطوات من 3 إلى 12 تُبنى على أساس فاسد، ويمكن لصياغة نهائية محظوظة أن تتجاوز فحصاً يعتمد على المخرج فقط. التقييم على مستوى span يخبرك أن التشغيل فشل عند الخطوة الثانية، لا أنه فشل في مكان ما فقط.

إليك النسخة المستقلة عن الإطار أولاً (تأكيد بسيط على كائن التتبع)، ثم اختصار DeepEval باستخدام مقياس إتمام المهمة المعتمد على التتبع:

# Framework-agnostic: did the trajectory reach the goal via valid steps?
def score_trace(trace):
    assert trace.steps[-1].status == "success", "final step failed"
    assert all(s.error is None for s in trace.steps), "a mid-run step errored"
    assert "internal_link_lookup" in [s.tool for s in trace.steps], "skipped a required step"

# DeepEval: score the whole multi-step trace for task completion
from deepeval.tracing import observe
from deepeval.metrics import TaskCompletionMetric

@observe(metrics=[TaskCompletionMetric(threshold=0.7, model="gpt-4o")])
def content_pipeline(topic):
    ...  # your researcher -> brief -> writer -> validator run
    return final_post

التأكيد المستقل عن الإطار مناسب للفحوصات الحتمية الصارمة. إتمام المهمة (Task Completion) هو ما تلجأ إليه حين يكون النجاح أكثر ضبابية من فحص التساوي: فهو يستخرج المهمة المقصودة والنتيجة المُحققة من التتبع ويقيس مدى تطابقهما.

كيف تتحقق من أن الوكيل استدعى الأداة الصحيحة؟

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

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

1. الاختيار. من بين الأدوات المتاحة، هل اختار الوكيل الأداة الصحيحة؟ استدعاء أي أداة ليس مثل استدعاء الأداة الصحيحة.
2. الوسائط. هل مرّر المعاملات الصحيحة؟ الأداة الصحيحة بـ slug خاطئ أو تاريخ مُشوَّه لا تزال فشلاً.
3. مسار التنفيذ. هل استدعى تلك الأداة في الخطوة الصحيحة، بالترتيب الصحيح؟ استرداد الأموال قبل التحقق من الطلب هو الأدوات الصحيحة بترتيب خاطئ.

مقياس صحة الأداة من DeepEval يتعامل مع الأمور الثلاثة: يقارن tools_called مقابل expected_tools، ويمكنه المطابقة على معاملات الإدخال، ومع should_consider_ordering=True يُقيّم الترتيب أيضاً.

# Framework-agnostic: right tool, right args, right step
call = trace.steps[2].tool_call
assert call.name == "internal_link_lookup", f"wrong tool: {call.name}"
assert call.args == {"slug": "llm-evals-guide"}, f"wrong args: {call.args}"

# DeepEval: score tool selection + arguments, order-aware
from deepeval.test_case import LLMTestCase, ToolCall, ToolCallParams
from deepeval.metrics import ToolCorrectnessMetric

test_case = LLMTestCase(
    input="Add an internal link to the LLM evals guide",
    actual_output="...",
    tools_called=[ToolCall(name="sitemap_search")],
    expected_tools=[ToolCall(name="internal_link_lookup")],
)
metric = ToolCorrectnessMetric(
    evaluation_params=[ToolCallParams.INPUT_PARAMETERS],
    should_consider_ordering=True,
)
metric.measure(test_case)
print(metric.score, metric.reason)  # 0.0  "expected tool not called"

ذلك الـ0.0 هو الفشل بعينه الذي رصدناه في خط أنابيبنا الخاص: استدعى الوكيل sitemap_search بينما كانت الأداة المتوقعة internal_link_lookup. المنشور النهائي اجتاز درجة مخرجه رغم ذلك. مقياس استدعاء الأداة كان الشيء الوحيد الذي كشف المسار المكسور.

كيف تُشغّل التقييمات عبر الإنترنت، على مسارات إنتاج حية؟

التقييم عبر الإنترنت (online) يُشغّل مقاييسك مقابل مسارات إنتاج حية في الوقت الفعلي، بدلاً من مقابل مجموعة اختبار قبل النشر فقط. إنه الطبقة الثالثة من نظام ثلاثي الطبقات: اختبارات دون اتصال على مجموعة بيانات ذهبية، وبوابة ضمان جودة قبل النشر، ثم تقييمات عبر الإنترنت على حركة حية، مع تنقيح مسارات الإنتاج مجدداً في مجموعات البيانات بحيث تستمر الحلقة في التحسن.

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

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

ربط تقييم عبر الإنترنت هو نفس تجهيز التتبع، بالإضافة إلى تجميع مقياس. تُشغّل Confident AI أكثر من 50 مقياساً من DeepEval مقابل المسارات الحية، وهي متوافقة مع OpenTelemetry، لذا فإن LangGraph وCrewAI وOpenAI وVercel AI SDK تُصدّر بياناتها دون محولات مخصصة:

# Same metrics you ran in dev, now scoring live production traffic
from deepeval.tracing import observe, update_current_span
from deepeval.test_case import LLMTestCase

@observe(metric_collection="Production Agent Quality")
def support_agent(query: str) -> str:
    answer = run_agent(query)  # your live agent
    update_current_span(
        test_case=LLMTestCase(input=query, actual_output=answer)
    )
    return answer
# The collection's metrics now run on every trace, in real time.

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

اربط النشر ببوابة أمان، لا بالدقة فقط

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

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

بعد ذلك، شغّل تقييمات عدائية مقابل تلك الفئات. OWASP Top 10 لتطبيقات LLM، وإطار إدارة مخاطر الذكاء الاصطناعي من NIST، وMITRE ATLAS تمنحك المفردات المشتركة؛ وفريق العمل الأحمر يمنحك الاختبار. DeepTeam، إطار العمل الأحمر مفتوح المصدر من الفريق ذاته الذي بنى DeepEval، يشحن أكثر من 120 ثغرة عبر 8 فئات وأكثر من 20 متجه هجوم، كل منها مُطابَق مع OWASP وNIST AI RMF وMITRE ATLAS.

تفصيل صادق واحد بشأن الأدوات: DeepTeam مفتوح المصدر هو المسار المجاني ويغطي مجموعة الثغرات؛ أما وحدة العمل الأحمر المُدارة داخل منصة Confident AI فهي ميزة من مستوى Enterprise، وليست شيئاً تحزمه خطة Starter بسعر $9.99. في كلتا الحالتين، اربط العمل الأحمر كبوابة من الدرجة الأولى، لا كفكرة لاحقة تُشغّلها مرة واحدة قبل الإطلاق.

ما رصدناه عند تشغيل هذا على خط أنابيبنا الخاص

نُشغّل هذا النظام ثلاثي الطبقات على خط أنابيب المحتوى متعدد الوكلاء الخاص بنا: أربعة وكلاء (الباحث، ومنشئ الملخص، وكاتب المحتوى، والمُدقق) يُسلّمون العمل عبر سلسلة. ربط DeepEval v4.0.5 بذلك الخط طوال يونيو ويوليو 2026، مقابل مساحة عمل Confident AI الخاصة بنا، هو كيف رصدنا الفشل الذي ذكرناه في المقدمة. كان مخرج المُقيّم يبدو كالتالي:

ToolCorrectnessMetric  score=0.00  threshold=0.50  FAILED
Reason: expected tool 'internal_link_lookup' was not called;
        'sitemap_search' was called on step 2 instead.

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

إذا كنت تتابع الممارسين على r/LLMDevs أو r/MachineLearning أو r/LocalLLaMA، فإن الشكوى ذاتها تتكرر باستمرار، وتتطابق تقريباً واحدة لواحدة مع ما بُني النظام ثلاثي الطبقات لرصده:

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

تلك النقطة الأخيرة هي المهمة. خبراء المجال يُعلّقون على المخرجات التي يكون الحكم غير متأكد منها، وتلك التسميات تُغذّي معايرة المقياس مجدداً، الحلقة المغلقة ذاتها التي وصفناها في مراجعتنا لـConfident AI والمجاورة لكيفية تعاملنا مع ذاكرة الوكيل. الحكم يتوسع؛ والبشر يبقونه صادقاً.

أي منصة تناسب منظومتك؟

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

في المرتبة الأولى للاستخدام المؤسسي وعبر الفرق تقف Confident AI. فهي تغطي دورة حياة الجودة كاملة في مكان واحد (تقييمات وقت التطوير، ومراقبة الإنتاج، والأمان العدائي عبر DeepTeam، وبوابة جودة على مستوى المؤسسة بأكملها)، وميزتها الحقيقية هي وصول الفريق بدون كود: يربطها المهندسون مرة واحدة، ثم يُشغّل مديرو المنتج وفرق ضمان الجودة وخبراء المجال دورات تقييم كاملة بأنفسهم. نقطة الدخول $9.99/مستخدم/شهر مع طبقة مجانية. إنها المرتبة الأولى في استعراضنا لأدوات تقييم LLM والمرتبة الثانية في مقارنتنا لـمنصات مراقبة الذكاء الاصطناعي، فهذه ليست المرة الأولى التي تتصدر فيها قائمة لنا.

تُوضع بشكل منفصل DeepEval، الإطار الرائد مفتوح المصدر، المبني من الفريق ذاته، بأكثر من 50 مقياساً واختبار أصيل مع pytest. Confident AI هي المنصة؛ وDeepEval هي المكتبة مفتوحة المصدر، لا نسخة مُخفَّفة منها. اختر هذه إذا:

• DeepEval: تريد المعيار مفتوح المصدر وتعيش في Python وpytest.
• Langfuse: تريد تتبعاً مفتوح المصدر يمكنك استضافته ذاتياً.
• LangSmith: منظومتك هي LangChain وLangGraph من البداية للنهاية.
• Arize Phoenix: تريد تتبعاً أصيلاً لـOpenTelemetry مفتوح المصدر بالكامل.
• Braintrust: تريد تقييمات شاملة مع تجارب وطبقة مجانية سخية.
• Promptfoo: تعيش في سطر الأوامر (CLI) وتريد العمل الأحمر في الأداة ذاتها.
• Ragas: وكيلك في الحقيقة خط أنابيب RAG وتريد مقاييس مخصصة للاسترجاع.
• Galileo: تريد مؤشر هلوسة وجودة مُدار جاهزاً من الصندوق.
• Maxim: تريد سير عمل محاكاة وتقييم للوكلاء متعددي الأدوار.
• W&B Weave: أنت بالفعل في Weights & Biases وتريد تتبعاً بجانب تشغيلات تدريبك.

حد صادق واحد على Confident AI: وحدة العمل الأحمر المُدارة والنشر داخل المنشأة (on-prem) هما ميزتان من مستوى Enterprise، وإقامة البيانات الأمريكية/الأوروبية هي ميزة Team/Enterprise لا مفتاحاً عالمياً عند التسجيل. المطور الفردي الذي يُشغّل وكيلاً واحداً يمكنه البدء بـDeepEval مفتوح المصدر مجاناً وإضافة المنصة حين يحتاج فريق كامل لتشغيل التقييمات.

عن الكاتب

Mert Batur Gurbuz هو المؤسس المشارك لـ Techsy.io، حيث يبني الفريق وكلاء الذكاء الاصطناعي وأنظمة الأتمتة وخطوط أنابيب الصوت/SDR لعملاء B2B. يدرس في جامعة برمنغهام ويكتب عن منظومة أدوات LLM التي يشغّلها فريق Techsy في بيئة الإنتاج الفعلية. تواصل معه عبر LinkedIn.

الأسئلة الشائعة

ما هو تقييم وكلاء الذكاء الاصطناعي؟

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

كيف تُقيّم مسار الوكيل مقارنة بمخرجه النهائي؟

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

كيف تتحقق من أن الوكيل استدعى الأداة الصحيحة؟

افحص ثلاثة أمور منفصلة: اختيار الأداة (الأداة الصحيحة للمهمة)، وصحة الوسائط (المعاملات والقيم الصحيحة)، وصلاحية مسار التنفيذ (الخطوة والترتيب الصحيحان). أطر مثل مقياس صحة الأداة في DeepEval تقارن الأدوات المُستدعاة فعلاً مقابل الأدوات المتوقعة، وتُطابق على معاملات الإدخال، ويمكنها تقييم ترتيب الاستدعاء عند تفعيل ذلك.

ما المقاييس الأكثر أهمية لوكلاء الذكاء الاصطناعي في الإنتاج؟

معدل نجاح المهمة والتكلفة لكل مهمة ناجحة يأتيان أولاً، ثم مئينات الكمون (p50، p90، p99)، ودقة استدعاء الأدوات، والأمانة، ومعدل التدخل البشري، والانحراف، ومعدل اجتياز بوابة الأمان. التكلفة لكل مهمة ناجحة تهم أكثر من التكلفة الخام، لأن التكلفة العادية لكل مهمة تُكافئ بصمت الوكلاء الذين يفشلون بسرعة وبرخص.

ما الفرق بين تقييمات الوكيل دون اتصال وعبر الإنترنت؟

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

كم مرة يجب أن تُعيد تشغيل تقييمات الوكيل؟

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

كيف تكشف الاختراقات وتسريبات البيانات الشخصية قبل الشحن؟

شغّل تقييمات فريق أحمر عدائية كبوابة قبل النشر، وأبقها تعمل عبر الإنترنت أيضاً. اربط أنماط الفشل بـOWASP Top 10 لتطبيقات LLM، وNIST AI RMF، وMITRE ATLAS، ثم حاكِ الهجمات مقابل كل فئة بإطار مثل DeepTeam مفتوح المصدر. امنع الإصدار عند أي ثغرة تخترق البوابة، لا فقط عند درجة متوسطة منخفضة.

هل يجب أن تبني منصة تقييم وكلاء الذكاء الاصطناعي أم تشتريها؟

ابنِ بأدوات مفتوحة المصدر (DeepEval للمقاييس، وPromptfoo لاختبار CLI والعمل الأحمر) حين تكون مطوراً فردياً أو فريق هندسة صغير مرتاح بالكود. اشترِ منصة مثل Confident AI حين يحتاج فريق كامل وصولاً بدون كود على مستوى المؤسسة، واختباراً أمنياً مُداراً، ومراقبة إنتاج موحّدة عبر المشاريع. معظم الفرق تبدأ بمصادر مفتوحة ثم تتخرج.

هل LLM كحكم موثوق لتقييم الوكلاء؟

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

نظام الطبقات الثلاث، بنَفَس واحد

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

ابدأ بأي طبقة تؤلمك أكثر: إذا كنت تشحن بشكل أعمى، اربط التقييمات عبر الإنترنت أولاً؛ وإذا كنت تشحن بشكل غير آمن، ابنِ بوابة الأمان أولاً. ابنِها بـDeepEval وPromptfoo مفتوحي المصدر، أو اشترِ منصة مثل Confident AI حين يحتاج فريق كامل وصولاً بدون كود وأماناً مُداراً. وإذا كنت تفضل أن يربط مهندسون الحلقة كاملة نيابة عنك، فهذا هو نوع العمل الذي يقوم به فريقنا كل أسبوع.