التطوير المدفوع بالتقييمات لموظفي الذكاء الاصطناعي: دورة مكثفة متعددة المسارات

15 مفهوماً · أربعة مسارات تعلم. مسار القارئ: 3 إلى 4 ساعات قراءة مفاهيمية. مسارات المبتدئ والمتوسط والمتقدم: من يوم إلى ثلاثة أيام مع مختبر متزايد العمق.

ثلاثة مصطلحات قبل البدء.

• Agent: برنامج يستطيع اتخاذ أفعال: استدعاء أدوات، البحث، إرسال رسائل، أو تسليم العمل.
• Tool: دالة محددة يستخدمها الوكيل، مثل customer_lookup(email) أو refund_issue(...).
• Trace: سجل كامل لتشغيل واحد: model calls، tool calls، handoffs، guardrails، وترتيبها.

النسخة البشرية المبسطة. بنينا في الدورات السابقة وكلاء يعملون. السؤال الصادق الآن: كيف نعرف أنهم يعملون بصورة صحيحة؟ ليس "هل اشتغل الكود"، بل هل اختار الوكيل الأداة الصحيحة، استخدم المعاملات الصحيحة، احترم envelope، استند إلى المصدر الصحيح، وصعّد عندما كان يجب. هذه ليست مشكلة unit tests فقط. هذه مشكلة evals.

هل أنت جاهز؟

هذه الدورة تغلف الدورات 3 إلى 8. إذا لم تبنِ أمثلة Maya، يمكنك استخدام المسار المحاكى. أما التنفيذ الكامل فيفترض وجود agents وtraces وبيانات وموافقات.

أربعة مسارات تعلم

المسار	لمن	المخرج
Reader	قادة واستراتيجيون	فهم الانضباط والهرم
Beginner	باني جديد	أول eval outputs
Intermediate	فريق يبني agents	trace/tool/RAG evals
Advanced	فريق شحن	CI/CD، Phoenix، regression loop

ما سيكون لديك في النهاية

• golden dataset أولي.
• eval outputs عبر DeepEval.
• trace evals عبر OpenAI Agent Evals أو Phoenix بحسب runtime.
• safety/tool-use evals لenvelope.
• RAG evals للطبقة المعرفية.
• regression suite في CI/CD.
• production observability loop.

مفردات ستقابلها

Eval اختبار سلوك. Rubric معيار تصحيح. Golden dataset أمثلة مرجعية. LLM-as-judge نموذج يقيم مخرجاً وفق rubric. Trace grading تقييم مسار التشغيل لا الرد النهائي فقط.

ما تحمله من الدورات 3 إلى 8

الدورة 3 أعطتك agent loop. الدورة 4 أعطتك system of record وMCP. الدورة 5 أعطتك runtime متيناً. الدورة 6 أعطتك management plane وapproval primitive. الدورة 7 أعطتك hiring API. الدورة 8 أعطتك Owner Identic AI. هذه الدورة تسأل: كيف نقيس كل ذلك؟

خريطة تقييم عبر الدورات

الدورة	ما يقيّم
3	agent loop، outputs، traces
4	RAG، grounding، MCP tools
5	durability، replay، regression
6	approvals، safety envelope
7	hire-time eval packs
8	delegated decisions، signed governance

بطاقة المفاهيم الخمسة عشر

1. الاختبارات التقليدية لا تكفي للagents.
2. تشبيه TDD مفيد ومحدود.
3. السلوك قد يكون final answer أو trace أو path.
4. هرم التقييم من 9 طبقات.
5. output evals البداية الأسهل.
6. tool-use وtrace evals تقيس الطريق.
7. RAG evals تفصل retrieval عن reasoning.
8. trace-eval layer حسب runtime.
9. DeepEval إطار repo-level.
10. Ragas/Phoenix للمعرفة والإنتاج.
11. golden dataset أهم artifact.
12. حلقة تحسين eval.
13. trace-to-eval pipeline.
14. ما لا تقيسه evals.
15. EDD انضباط تأسيسي لما بعد الدورات.

الجزء 1: الانضباط

Concept 1: لماذا لا تكفي الاختبارات التقليدية

unit tests تثبت أن الدوال تعمل. integration tests تثبت أن أجزاء النظام تتكلم. لكنها لا تثبت أن الوكيل اختار الأداة الصحيحة، أو اتبع الطريق الآمن، أو عرف متى يصعد. الوكلاء أنظمة سلوكية، لذلك تحتاج اختبارات سلوك.

Concept 2: تشبيه TDD وحدوده

EDD يشبه TDD: اكتب مثالاً، شغله، اجعل النظام يتحسن، واجعل regression واضحاً. لكنه يختلف لأن السلوك probabilistic، والgrader قد يخطئ، والtrace مهم بقدر الرد.

Concept 3: معنى "السلوك" للوكيل

السلوك قد يكون:

• الرد النهائي.
• الأدوات التي استدعيت.
• ترتيب الخطوات.
• ما لم يفعله الوكيل.
• هل صعّد عند الحد الصحيح.

الجزء 2: هرم التقييم

Concept 4: هرم التقييم من 9 طبقات

الطبقة	ما تقيس
unit	كود الأدوات
integration	اتصال الأدوات والخدمات
output	جودة الرد
tool-use	اختيار الأداة والمعاملات
trace	مسار التنفيذ
RAG	الاسترجاع والgrounding
safety	احترام envelope والسياسة
regression	عدم تراجع السلوك
production	إشارات حية من traces

شاهد eval قبل دراسة الانضباط

# Rubric: answer_correctness
criteria:
  - answer addresses the customer question
  - cites the relevant account fact
  - does not promise unauthorized refund

Concept 5: Output evals

Output evals هي البداية الأسهل: أعط input، expected traits، وrubric. لكنها لا ترى الطريق. قد يعطي الوكيل جواباً جيداً بعد أن استدعى أداة خاطئة أو خرق سياسة.

Concept 6: Tool-use وtrace evals

هنا تقيس الطريق: هل استدعى customer_lookup قبل refund_issue؟ هل مر عبر approval؟ هل تجنب tool غير مصرح؟ هذه evals أقرب إلى إنتاج حقيقي.

Concept 7: RAG evals

RAG evals تفصل فشلين: هل فشل الاسترجاع في جلب المصدر الصحيح؟ أم جلبه لكن النموذج استدل خطأ؟ لا تصلح الخطأين بالعلاج نفسه.

الجزء 3: الحزمة

Concept 8: طبقة trace-eval

في runtime مبني على OpenAI، استخدم OpenAI Agent Evals وTrace Grading. في runtime Claude أو بيئات أوسع، Phoenix evaluators وOpenTelemetry يعطيان طبقة trace قابلة للتحليل.

Concept 9: DeepEval كإطار repo-level

DeepEval مناسب لاختبارات pytest-style داخل repo. استخدمه لأول output evals، custom metrics، وربطها بـ CI.

Concept 10: Ragas وPhoenix

Ragas قوي لطبقة المعرفة وRAG. Phoenix قوي للملاحظة الإنتاجية وتحويل traces إلى أمثلة eval. لا تختصر الحزمة في أداة واحدة؛ كل طبقة لها وظيفة.

الجزء 4: المختبر

Lab Setup قبل Decision 1

1. ثبّت Claude Code أو OpenCode

claude update
opencode upgrade

2. أنشئ مجلد المختبر

mkdir course-nine-evals
cd course-nine-evals

3. ثبت اعتماديات الأطر الأربعة

استخدم uv أو مدير حزم الفريق. وثّق الإصدارات لأن APIs eval تتغير بسرعة.

4. اكتب ملف قواعد المشروع

# Course Nine Lab - Eval-Driven Development

## What this is
Eval suite for Maya's customer-support workforce.

## Stack
- pytest
- DeepEval
- Ragas
- Phoenix

## Critical rules
- Do not invent golden rows.
- Every eval must name the behavior it protects.

5. اضبط الصلاحيات

ابدأ read-only على traces والبيانات. لا تسمح للوكيل بتغيير CI أو أسرار الإنتاج قبل خطة وموافقة.

6. أضف hooks أو plugins للحواجز الحتمية

اجعل الاختبارات تمنع commit إذا كُسر eval أساسي. الحارس الحتمي أقوى من prompt.

7. احفظ workflows المتكررة كأوامر

احفظ "أنشئ eval من trace"، "راجع rubric"، "أضف golden row" كأوامر أو skills.

Decision 1: إعداد workspace وإنشاء golden dataset

ابدأ بعشر صفوف. كل صف يحتوي task، input، context، expected behavior، expected tools، unacceptable patterns، difficulty. لا تكتب مئة صف قبل أن تثبت schema.

Decision 2: Output evals بـ DeepEval

اكتب أول test يقيس answer correctness أو policy adherence. اجعل threshold واضحاً، واشرح لماذا.

Decision 3: Trace evals مع OpenAI Agent Evals

قيّم المسار: ترتيب tools، guardrails، handoffs، وapproval. لا تكتف بالرد النهائي.

Decision 4: Tool-use وsafety evals

اختبر أن Claudia أو عامل الدعم يحترم envelope. مثال: refund فوق الحد يجب أن يصعد، لا أن ينفذ.

Decision 5: RAG evals مع Ragas

اختبر retrieval، faithfulness، context precision، وanswer groundedness. فشل retrieval يحتاج عمل index؛ فشل faithfulness يحتاج تعليمات أو نموذجاً مختلفاً.

Decision 6: Regression evals وCI/CD

أدخل evals الأساسية في CI. لا تجعل كل eval blocking في البداية؛ صنفها إلى critical وinformational حتى لا تصبح suite عائقاً غير مفهوم.

Decision 7: Production observability مع Phoenix

صدّر traces، راقب failure clusters، وحوّل الحالات السيئة إلى golden rows. هذه هي حلقة trace-to-eval.

الجزء 5: الجبهات الصادقة

Concept 11: Golden dataset أهم artifact

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

Concept 12: حلقة تحسين eval

الحلقة: فشل -> تشخيص -> تعديل agent أو tool أو prompt -> تشغيل eval -> حفظ regression. لا تغير threshold لإخفاء الفشل.

Concept 13: الملاحظة الإنتاجية وخط trace-to-eval

الإنتاج يكشف ما لم تتوقعه. اختر traces تمثل فشلاً أو حداً جديداً، ثم حوّلها إلى golden rows. بهذه الطريقة تعيش suite مع النظام.

Concept 14: ما لا تستطيع evals قياسه

لا تقيس evals كل شيء: نوايا المستخدم الغامضة، القيم العميقة، adversarial novelty، أو صحة grader المطلقة. لذلك تحتاج human review وred teaming ومراقبة إنتاجية.

خمسة أشياء لا تفعلها

1. لا تجعل LLM judge بلا rubric.
2. لا تختبر الرد النهائي فقط.
3. لا تستخدم بيانات ذهبية مخترعة بالكامل.
4. لا تخفي الفشل بتغيير threshold.
5. لا تعامل evals كحدث مرة واحدة؛ هي ممارسة مستمرة.

الجزء 6: الخاتمة

Concept 15: EDD كانضباط تأسيسي

التطوير المدفوع بالتقييمات هو ما يحول Agent Factory من demo إلى نظام يمكن الاعتماد عليه. الوكلاء يعملون، لكن الثقة تأتي عندما تقيس السلوك الذي يهم وتمنع regressions من العودة.

مرجع سريع: المفاهيم الخمسة عشر

#	المفهوم	معنى عملي
1	tests لا تكفي	agents تحتاج سلوكاً مقاساً
2	TDD analogy	مفيد لكن probabilistic
3	behavior	answer أو trace أو path
4	pyramid	طبقات مختلفة للفشل
5	output evals	بداية سهلة
6	trace evals	الطريق يهم
7	RAG evals	retrieval != reasoning
8	trace layer	حسب runtime
9	DeepEval	repo-level
10	Ragas/Phoenix	معرفة وإنتاج
11	golden dataset	الأصل الأهم
12	improvement loop	فشل يصبح regression
13	observability	production -> evals
14	limits	لا ثقة عمياء
15	EDD	ممارسة تأسيسية

ملخص عبر الدورات

الدورة	ما يقاس
3	agent loop وoutputs وtraces
4	RAG وMCP والgrounding
5	durability وreplay
6	approvals وsafety
7	hire-time eval packs
8	signed delegated decisions

ما التالي للقارئ

إذا أكملت الدورات 3 إلى 9، لديك بنية شركة AI-native وانضباط قياسها. أمامك ثلاثة مسارات:

1. شغّل. ضع agents في traffic حقيقي، واجعل eval suite تعيش مع الإنتاج.
2. وسّع. طبّق EDD على مجال لم تغطه الدورة: قانون، طب، مالية، أو multi-agent evals.
3. ساهم. الأطر مفتوحة ومتغيرة. الممارسة تحتاج أمثلة حقيقية من فرق تشحن.

تمرين ختامي. افتح Claude Code أو OpenCode واطلب منه أن يطبق EDD على وكيل إنتاجي حقيقي لديك: يبدأ بعشر صفوف golden dataset، يختار طبقتين من الهرم تؤلمان المستخدمين أكثر، ثم يكتب أول test في DeepEval للمقياس الأكثر أهمية.

المراجع

حزمة Agent Factory: الأطروحة والدورات 3 إلى 8.

الأدوات الأساسية: OpenAI Agent Evals، OpenAI Trace Grading، DeepEval، Ragas، Phoenix، Braintrust.

الخلفية البحثية: Kent Beck عن TDD، أبحاث LLM-as-judge، RAG، وMLOps. استخدم هذه المراجع لتأصيل الانضباط، لا لاستبدال ممارسة الفريق اليومية.

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