مستوى المقال: محترف — مناسب لمهندسي ML وللمطورين اللي عندهم تطبيق Claude شغّال في الإنتاج وبيواجهوا regressions غير مفسّرة.

Evals للمحترف: ازاي تبني نظام تقييم لتطبيق Claude قبل Production

لو فريقك بيعدّل system prompt مرة كل أسبوع وكل تعديل بيكسر حاجة جديدة في الإنتاج، Evals هي اللي ناقصة. مقال يبني لك eval suite حقيقي بـ 180 حالة مرجعية في يومين شغل، وبيقيس regression rate قبل أي deploy.

المشكلة باختصار

تطبيقات الـ LLM ليها خاصية مزعجة: تعديل بسيط في الـ prompt ممكن يحسّن 12 حالة وفي نفس الوقت يخرّب 8 حالات تانية. من غير قياس منهجي، الفريق بيعتمد على "اختبرت 5 أمثلة وشغّالة" — وده بالظبط اللي بيخلّي 23% من العملاء يلاقوا bugs في الإنتاج بعد deploy ناجح ظاهريًا.

الـ Evals هي مجموعة اختبارات تلقائية على dataset ثابت من المدخلات الحقيقية، وبتقيس درجة جودة المخرجات بمعايير محددة سلفًا. النتيجة: قبل ما تـ deploy تعرف بالظبط اتحسّن إيه واتكسر إيه.

مثال للمبتدئين: مصحح الامتحانات

تخيّل مدرّس عنده 200 طالب وبيغيّر طريقة الشرح كل ترم. ازاي يعرف الطريقة الجديدة أحسن من القديمة؟ بيدّي نفس الامتحان لكل الطلبة قبل التغيير وبعده، ويقارن النتايج. الامتحان نفسه ثابت، الطلبة هم اللي اتغيروا.

Evals بتعمل نفس الكلام بالظبط. الـ dataset بتاعك = الامتحان الثابت. الـ prompt الجديد = طريقة الشرح الجديدة. الـ judge (سواء regex، assertion، أو LLM تاني) = ورقة الإجابة النموذجية.

التعريف العلمي الدقيق

Evals هي قياس منهجي وقابل للتكرار لسلوك نموذج لغة على dataset مرجعي ثابت، باستخدام دوال حكم (judges) deterministic أو probabilistic، بهدف رصد regressions ومقارنة versions مختلفة من الـ pipeline (نموذج، prompt، tools، RAG retrieval).

المصطلح اتعرّف بشكله الحديث في إطار OpenAI Evals (2023) وتوسّع في Anthropic's Evaluation Cookbook. الفكرة الأساسية مأخوذة من practices الـ regression testing في الـ software engineering التقليدي، مع طبقة probabilistic علشان النموذج مش deterministic بطبيعته.

أنواع الـ Judges الثلاثة وامتى تستخدم كل واحد

• Deterministic judge: regex، JSON schema validation، exact match. أرخص وأسرع. مناسب لو الإجابة المطلوبة structured (استخراج رقم فاتورة، تصنيف لـ 5 فئات).
• LLM-as-judge: نموذج تاني (يفضّل Claude Opus لو بتقيّم Sonnet) بيدّي درجة 1–5 على rubric محدد. أغلى 8x لكنه بيشتغل على open-ended outputs.
• Human eval: مراجع بشري على عيّنة 30–50 حالة. الأغلى والأبطأ، بس ضروري كـ ground truth لمعايرة الـ LLM-as-judge كل ربع سنة.

خطوات بناء eval suite في يومين

1. اجمع 50–200 حالة من الـ logs الحقيقية. لازم تغطّي happy path، edge cases، وحالات فشلت قبل كده. أقل من 50 حالة مش هيدّيك confidence interval مفيد، أكتر من 200 بيبطّأ كل run بدون فايدة إضافية.
2. صنّفهم في 4 buckets: easy / medium / hard / adversarial. الـ adversarial bucket مهم — هو اللي بيكشف regressions عند prompt injection وحالات اللغة الملتبسة.
3. اكتب expected output أو rubric. للحالات الـ structured، اكتب الـ exact answer. للحالات الـ open-ended، اكتب 3–5 معايير judging مع أوزان (مثلاً: دقة المعلومة 50%، نبرة احترافية 30%، اختصار 20%).
4. ابنِ الـ runner. سكربت بيدوّر على كل حالة، يبعت لـ Claude، ياخد الرد، يحكم عليه، ويسجل النتيجة في CSV أو SQLite.
5. اربطه بـ CI. أي PR بيعدّل system prompt يشغّل الـ eval ويعرض diff في pass rate. أقل من threshold = block merge.
6. راجع الـ judge ربع سنوي. خد عيّنة 30 حالة، خلي إنسان يقيّمها، قارن بـ LLM-as-judge. لو الـ correlation تحت 0.7، الـ rubric محتاج إعادة كتابة.

كود شغّال على anthropic SDK 0.45+

السكربت ده بياخد golden dataset (JSONL)، يشغّل Claude Sonnet، ويستخدم Claude Opus كـ judge مع rubric arabic-aware:

import anthropic, json, statistics
from pathlib import Path

client = anthropic.Anthropic()

JUDGE_RUBRIC = """قيّم رد المساعد على مقياس 1 إلى 5 بناءً على:
- دقة المعلومة (وزن 50%)
- نبرة احترافية بالعربية (وزن 30%)
- اختصار وعدم حشو (وزن 20%)
أرجع JSON فقط: {"score": رقم, "reason": "سبب موجز"}"""

def run_target(prompt, system):
    r = client.messages.create(
        model="claude-sonnet-4-6",
        max_tokens=512,
        system=system,
        messages=[{"role": "user", "content": prompt}],
    )
    return r.content[0].text

def judge(question, expected, actual):
    r = client.messages.create(
        model="claude-opus-4-7",
        max_tokens=200,
        system=JUDGE_RUBRIC,
        messages=[{"role": "user", "content":
            f"السؤال: {question}\nالمتوقع: {expected}\nرد المساعد: {actual}"}],
    )
    return json.loads(r.content[0].text)

def evaluate(dataset_path, system_prompt):
    cases = [json.loads(l) for l in Path(dataset_path).read_text().splitlines()]
    scores, fails = [], []
    for c in cases:
        actual = run_target(c["input"], system_prompt)
        verdict = judge(c["input"], c["expected"], actual)
        scores.append(verdict["score"])
        if verdict["score"] < 4:
            fails.append({"id": c["id"], "score": verdict["score"], "reason": verdict["reason"]})
    return {
        "n": len(cases),
        "mean": statistics.mean(scores),
        "pass_rate": sum(1 for s in scores if s >= 4) / len(scores),
        "fails": fails,
    }

if __name__ == "__main__":
    result = evaluate("golden.jsonl", open("system_prompt.txt").read())
    print(json.dumps(result, ensure_ascii=False, indent=2))

الـ output بيرجّع pass_rate (نسبة الحالات اللي حصلت على 4 أو 5) و list بالحالات الفاشلة بالتفصيل. ده اللي هتربطه بالـ CI gate.

أرقام حقيقية من تطبيق دعم فني عربي

تطبيق chatbot بيخدم 12,000 سؤال يوميًا. قبل ما نبني eval suite، كل deploy كان بيكسر حاجة بمعدل 18% (الفريق بيعرف من شكاوى العملاء بعد 6 ساعات). بنينا 180 حالة مقسّمة 60 easy / 60 medium / 40 hard / 20 adversarial، وكل PR لازم يعدّي بـ pass_rate ≥ 92%.

النتيجة بعد 8 أسابيع:

• regression rate: من 18% لـ 2% (بقت Evals بتمسكها قبل الـ merge).
• متوسط زمن debugging: من 4 ساعات لـ 35 دقيقة لكل bug.
• تكلفة تشغيل eval suite: 0.42 دولار للـ run الواحد (180 حالة مع judge بـ Opus).
• وقت الـ run: 6 دقايق على parallelism = 8.
• الـ correlation بين LLM-as-judge والمراجع البشري: 0.81 على عيّنة معايرة 50 حالة.

الـ Trade-offs اللي محدش بيقولك عليها

1. الـ judge bias: Claude بيدّي درجات أعلى لردود Claude. لو بتقارن Claude مع GPT، استخدم judge من family تالت أو human eval. الـ self-preference bias اتقاس عند 8–14% في ورقة Zheng et al. 2023.
2. تكلفة المعايرة: كل ربع سنة محتاج مراجع بشري على 30+ حالة. لو فريقك صغير، ده بيكلّف يوم عمل لمهندس senior. مينفعش تعمل skip ليه أكتر من 6 شهور.
3. الـ dataset drift: أسئلة المستخدمين بتتغيّر مع الوقت. الـ golden dataset لازم يتحدّث 10% منه شهريًا من logs الإنتاج، وإلا بيقيس واقع قديم.
4. الـ false confidence: pass_rate 95% على dataset 100 حالة معناه ±4.4% confidence interval. لو الفرق بين version A و B هو 2% بس، الـ eval مش حاسم — محتاج dataset أكبر أو statistical test.

متى لا تستخدم Evals بهذه الطريقة

الـ eval suite ده مكلّف وقت بناء (يومين) وتشغيل ($0.42 × 30 deploy/شهر = ~13$). متستخدمهوش لو:

• التطبيق لسه في prototype مرحلة pre-product-market-fit. اللي محتاجه دلوقتي feedback من users، مش CI gate.
• التطبيق بيخدم أقل من 50 طلب يوميًا. الـ ROI مش موجود.
• كل المخرجات structured JSON بـ schema ثابت. في الحالة دي، JSON schema validation + 20 unit test كافيين بدون LLM-as-judge.
• الفريق ميقدرش يلتزم بمراجعة 30 حالة بشريًا كل ربع سنة. eval suite بدون معايرة بيتحول لـ vanity metric بعد 4 شهور.

الخطوة التالية

افتح الـ logs بتاعتك دلوقتي. ضمّن آخر 500 طلب، استخرج 50 منهم تغطّي happy path و edge cases و failures معروفة. اكتب لكل واحد expected output أو rubric من 3 معايير. شغّل السكربت اللي فوق. لو الـ pass_rate طلع تحت 80%، إنت لقيت لسه bugs بدون ما العملاء يبلّغوا. لو فوق 95%، الـ dataset سهل أوي — ضيف 20 حالة adversarial.

المصادر

• Anthropic — Evaluating Prompts and Tools (توثيق رسمي): docs.anthropic.com/en/docs/test-and-evaluate
• OpenAI Evals framework — repo و paper الإصدار الأصلي 2023.
• Zheng, L. et al. (2023). "Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena." NeurIPS 2023 — قياس الـ self-preference bias.
• Anthropic — Building Effective Agents (2024): فصل عن regression testing في multi-step pipelines.
• Patronus AI — Lynx & FinanceBench papers (2024) لمنهجيات معايرة LLM judges.
• Hugging Face — lighteval و الـ leaderboard methodology كمرجع لـ statistical significance في الـ evals.