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

ما هي اختبارات التقييم المستضافة ذاتياً لوكلاء الذكاء الاصطناعي

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

نجح الوكيل في العرض التوضيحي لأنك اخترت المدخلات الخمسة بنفسك. لكنه تعطل في الأسبوع الثاني لأن سطراً في prompt تغيّر، أو لأن model تغيّر، أو لأن وصف أداة تغيّر، ولم يشمل أي قياس هذه التغييرات. تحوّل دورة التقييم عبارة «يبدو الآن أسوأ» إلى عبارة «انخفض معدل النجاح من 58 من 60 إلى 51 من 60 في commit 4f1c9ab».

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

لماذا يتعطل الوكيل في الأسبوع الثاني

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

السبب الأكثر شيوعاً هو تعديل المطالبة. تضيف جملة واحدة لمنع رد فظ. تغيّر هذه الجملة السلوك في مدخلات لم يُعِد أحد اختبارها، وتعرض الآثار ذلك بوضوح: يحتوي أثر الأسبوع الماضي للسؤال نفسه على استدعاء أداة create_refund، بينما لا يحتوي أثر هذا الأسبوع على أي استدعاء، ويكون الرد اعتذاراً مهذباً بدلاً من ذلك. لم يُسجَّل أي خطأ، لذلك لم يُطلَق أي تنبيه.

السبب الثاني هو النموذج. سجّل سلسلة النموذج الدقيقة التي أرسلتها مع كل تشغيل، claude-haiku-4-5-20251001 بدلاً من اختصار تحتفظ به في ذاكرتك، لأن انخفاض معدل النجاح في اليوم الذي بدّلت فيه النماذج لا يمكن تشخيصه إلا عندما يكون النموذج موجوداً في السجل.

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

أنشئ المجموعة المرجعية من آثار التتبع التي تجمعها بالفعل

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

صدّر فترة من ملاحظات root عبر الواجهة العامة للـAPI. تستخدم الواجهة المصادقة الأساسية، بحيث يكون مفتاحك العام هو اسم المستخدم ومفتاحك السري هو كلمة المرور.

export LF_HOST="https://langfuse.example.com"
curl -sS -u "$LF_PUBLIC_KEY:$LF_SECRET_KEY" \
  "$LF_HOST/api/public/v2/observations?limit=50&isRootObservation=true&fromStartTime=2026-07-01T00:00:00Z" \
  | jq '.data[0]'

اقرأ سجلاً واحداً قبل أن تكتب أي منطق لتحليل البيانات. تعود الصفوف ضمن data، لكن أسماء الحقول التي تحتوي على السؤال والرد تعتمد على طريقة تسجيل وكيلك للـspans. لذلك اربط الحقول بما تراه فعلياً، لا بما توقعت رؤيته. ثم اكتب الحالات يدوياً، بحيث يحتوي كل سطر على كائن JSON واحد، في evals/cases.jsonl:

{"id": "refund-double-charge", "tags": ["smoke"], "input": "I was charged twice for order 41822.", "must_call": ["lookup_order", "create_refund"], "must_not_include": ["I cannot help"], "rubric": "The reply confirms exactly one refund for order 41822 and states the amount."}

تحافظ القواعد الخمس التالية على فائدة المجموعة عند تشغيلها:

• تكفي من 40 إلى 80 حالة للبدء. إذا قل العدد عن 20، يمكن لحالة واحدة متذبذبة أن تغيّر معدل النجاح بمقدار 5 نقاط، وسيتجاهل الناس رقماً يتغير بلا سبب.
• كل خطأ في بيئة الإنتاج تصلحه يصبح حالة في يوم إصلاحه. هذه العادة هي ما يجعل المجموعة تنمو في الاتجاه الصحيح.
• سلوك واحد لكل حالة. الحالة التي تتحقق من مبلغ الاسترداد ونبرة الرد معاً لا تخبرك بشيء عند فشلها.
• لا يتغير id أبداً، لأن المعرّف هو ما يتيح مقارنة تشغيل اليوم بتشغيل الشهر الماضي.
• احجب البيانات الحساسة قبل إجراء commit. سيدخل هذا الملف إلى git، لذلك احذف أسماء العملاء وأي أرقام طلبات لا تملكها.

ابدأ بالتحققات الحتمية، لأنها مجانية

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

تعرف دالة واحدة فقط تفاصيل عاملك. وكل ما عدا ذلك في إطار الاختبار عام.

import json, os, urllib.request

def run_agent(case):
    req = urllib.request.Request(
        os.environ["AGENT_URL"],
        data=json.dumps({"input": case["input"]}).encode(),
        headers={"content-type": "application/json"},
    )
    with urllib.request.urlopen(req, timeout=120) as resp:
        return json.load(resp)


def deterministic(case, result):
    text = result.get("output", "")
    called = [c["name"] for c in result.get("tool_calls", [])]
    failures = []
    for tool in case.get("must_call", []):
        if tool not in called:
            failures.append(f"tool not called: {tool}")
    for phrase in case.get("must_not_include", []):
        if phrase.lower() in text.lower():
            failures.append(f"forbidden phrase: {phrase}")
    if len(called) > case.get("max_tool_calls", 12):
        failures.append(f"too many tool calls: {len(called)}")
    return failures

أبقِ ميزانية الأدوات ضمن تلك القائمة. إذا حلّ العامل حالة باستخدام 3 استدعاءات اليوم و11 استدعاءً غداً، فهذا تراجع حتى عندما تكون الإجابة النهائية صحيحة، لأنك تدفع مقابل كل استدعاء يجريه.

نموذج LLM بوصفه حكماً، والطرق الأربع التي يفشل بها

كل ما يجتاز الاختبارات يحتاج إلى مُقيِّم يقرأ الإجابة. حكم LLM هو استدعاء ثانٍ للنموذج: يتلقى السؤال وإجابة الوكيل ومعياراً واحداً، ثم يُرجع حكماً. وهذه هي الطريقة العملية الوحيدة لتقييم سؤال مثل: «هل تجيب الإجابة عما طلبه المستخدم؟».

تجعل أربع قواعد الحكم قابلاً للاستخدام:

• حكم ثنائي، وليس درجة من 1 إلى 10. يُرجع المقياس درجتَي 7 و8 لكل شيء تقريباً، لذلك لا يتغير الرقم ولا تتعلم منه شيئاً.
• معيار واحد في كل استدعاء. اسأل عن مبلغ الاسترداد أو عن النبرة، وليس عنهما معاً.
• امنح الحكم الإجابة المتوقعة كلما كانت للحالة إجابة متوقعة. فالتقييم مقابل مرجع أسهل بكثير من التقييم المجرد.
• ألزِم النموذج بشكل الإخراج وحلّل النتيجة بصرامة.

from anthropic import Anthropic

client = Anthropic()  # reads ANTHROPIC_API_KEY from the environment


def judge_prompt(case, output):
    return (
        "You grade one answer against one criterion.\n"
        "Reply with JSON only, in this exact shape:\n"
        '{"verdict": "pass", "confidence": "high", "reason": "one short sentence"}\n'
        f"Criterion: {case['rubric']}\n"
        f"Question: {case['input']}\n"
        f"Answer: {output}\n"
        "Length is not a criterion. Judge only the criterion above."
    )


def judge(case, output, model):
    msg = client.messages.create(
        model=model,
        max_tokens=200,
        messages=[{"role": "user", "content": judge_prompt(case, output)}],
    )
    return json.loads(msg.content[0].text)

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

انحياز الطول. تجتاز الإجابات الأطول الاختبار بوتيرة أعلى. اختبر ذلك كما يلي: خذ عشر إجابات أخفق الحكم في تقييمها، وأضف إلى كل منها فقرتين من الحشو الواثق اللتين لا تضيفان أي حقيقة جديدة، ثم قيّمها مرة أخرى. إذا تغيّر أي حكم إلى «ناجح»، فهذا انحياز الطول، وعليك إصلاح rubric.

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

انحياز الموضع. إذا استخدمت الحكم لمقارنة إجابتين، A وB، فبدّل الترتيب وشغّل الاختبار مرة أخرى. إذا تغيّر الحكم بعد التبديل، فهذا يعني أن المقارنة الزوجية غير آمنة لهذا rubric بعد.

انجراف rubric. تنتج المعايير الغامضة أحكاماً توافقية. ينجح كل شيء تقريباً في اختبار «هل الإجابة مفيدة؟». أما «هل تذكر الإجابة مبلغ الاسترداد بالدولار؟» فلا ينجح فيه إلا ما قصدته. أعد كتابة كل معيار حتى يذكر الحقيقة التي يجري التحقق منها.

هناك إجراء واحد يحميك من الحالات الأربع كلها. احتفظ بـ30 حالة صنّفتها يدوياً، وقارن أحكام النموذج بتصنيفاتك في كل مرة تغيّر فيها نموذج الحكم أو prompt الحكم. إذا اختلف معك في أكثر من حالة واحدة من كل عشر حالات، فأصلح rubric قبل أن تثق بأي معدل نجاح ينتجه. الحكم شيفرة، ولذلك يجب إصداره ومراجعته مثل الشيفرة.

استخدم نموذجاً منخفض التكلفة للتقييم، ثم صعّد إلى نموذج متقدم

إن تقييم كل حالة باستخدام النموذج الأعلى تكلفة عند كل commit يؤدي إلى تضخم فاتورة التقييم بحيث تتجاوز تكلفة الوكيل الذي تختبره. رتّب أدوات التقييم حسب السعر، وتوقف فور اتضاح النتيجة.

[
  {
    "label": "Haiku 4.5, Batch API",
    "usd_per_1000_judge_calls": "0.90"
  },
  {
    "label": "Haiku 4.5",
    "usd_per_1000_judge_calls": "1.80"
  },
  {
    "label": "Sonnet 5",
    "usd_per_1000_judge_calls": "3.60"
  },
  {
    "label": "Opus 5",
    "usd_per_1000_judge_calls": "9.00"
  }
]

تفترض هذه الأرقام نحو 1,200 رمز إدخال و120 رمز إخراج لكل استدعاء للمقيّم، وهو حجم واقعي لسؤال واحد وإجابة واحدة ومعيار واحد. يكلّف تقييم 1,000 حالة 1.80 دولاراً أمريكياً باستخدام Claude Haiku 4.5، و9.00 باستخدام Claude Opus 5. قد يبدو الفرق بسيطاً، لكنه يتضخم عند تكراره. فمجموعة من 60 حالة، تُقيَّم عند كل commit، مع 40 commit أسبوعياً، تعني 2,400 استدعاء للمقيّم أسبوعياً قبل تشغيل المهمة الليلية.

ينطبق خصمان بوضوح على أعمال التقييم، ويمكن جمعهما. لا تكون عمليات التقييم تفاعلية، لذلك تخفّض Batch API سعري الإدخال والإخراج إلى النصف مقابل التسليم غير المتزامن، وهذا هو الصف الأول في المخطط. تكون rubric والتعليمات متطابقة بايتاً ببايت في كل استدعاء، لذلك يناسبها prompt caching: تكلّف قراءة الذاكرة المؤقتة عُشر سعر الإدخال الأساسي، بينما تكلّف كتابة الذاكرة المؤقتة لمدة خمس دقائق 1.25 ضعف سعر الإدخال الأساسي، لذلك تسترد الذاكرة المؤقتة تكلفتها بعد استخدام واحد فقط. هذه هي أسعار Anthropic المعلنة اعتباراً من August 2026، ويستمر التسعير التمهيدي لـSonnet 5 حتى 31 August 2026، لذلك يرتفع العمود الثالث بعد ذلك التاريخ.

التدرّج بالترتيب:

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

CHEAP = "claude-haiku-4-5-20251001"
STRICT = "claude-opus-5"


def grade(case, result):
    hard = deterministic(case, result)
    if hard:
        return False, "deterministic", "; ".join(hard)
    first = judge(case, result["output"], CHEAP)
    if first["verdict"] == "pass" and first["confidence"] == "high":
        return True, CHEAP, first["reason"]
    second = judge(case, result["output"], STRICT)
    return second["verdict"] == "pass", STRICT, second["reason"]

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

تتبّع معدل النجاح بمرور الوقت في نظام تملكه

لا يحمل معدل النجاح الذي لا يمكنك ربطه بـ commit سوى قيمة انطباعية. خزّن صفاً واحداً لكل حالة في كل تشغيل، مع تضمين commit وmodel داخل الصف.

CREATE TABLE IF NOT EXISTS results (
  run_id      TEXT NOT NULL,
  ran_at      TEXT NOT NULL,
  git_sha     TEXT NOT NULL,
  agent_model TEXT NOT NULL,
  case_id     TEXT NOT NULL,
  passed      INTEGER NOT NULL,
  graded_by   TEXT NOT NULL,
  reason      TEXT
);

SELECT run_id, git_sha, agent_model,
       count(*) AS cases,
       round(100.0 * sum(passed) / count(*), 1) AS pass_pct
FROM results
GROUP BY run_id
ORDER BY ran_at DESC
LIMIT 10;

حمّل المخطط باستخدام sqlite3 evals/results.db < evals/schema.sql، ثم اقرأ الاتجاه باستخدام sqlite3 -box evals/results.db < evals/passrate.sql. ينتج عام من التشغيلات اليومية على 60 حالة نحو 22,000 صف، لذلك لا يتحول مخزن البيانات إلى مشروع مستقل. يشرح تشغيل SQLite في بيئة الإنتاج على VPS الإعدادات التي تصبح مهمة إذا تمت مشاركة هذا الملف بين أجهزة متعددة.

يعرض runner المعلومات نفسها لشخص واحد:

run 2026-08-05T09:14:22Z  sha 4f1c9ab  model claude-sonnet-5  58/60 pass (96.7%)
FAIL refund-double-charge  deterministic: tool not called: create_refund
FAIL pto-policy-question   judge(opus): reply gives no dollar amount

شغّل المجموعة على التغييرات التي يمكن أن تكسر agent، أي تعديلات prompt وتغييرات model وتغييرات الأدوات، بدلاً من تشغيلها مع كل commit في أي مكان داخل المستودع. يغطي hook من نوع pre-push المجموعة السريعة:

cat > .git/hooks/pre-push <<'EOF'
#!/bin/sh
python3 evals/run.py --set smoke || exit 1
EOF
chmod +x .git/hooks/pre-push

تكون التشغيلات الكاملة أبطأ، ولذلك يجب جدولتها. يشغّل خدمة systemd ومؤقت على VPS المجموعة الكاملة كل ليلة باستخدام prompt المنشور، وهذا ما يلتقط التغييرات التي تأتي من خارج مستودعك، مثل أداة مستضافة تغيّر سلوكها.

المراجعة البشرية، بعينة لا بمراجعة شاملة

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

تستغرق 15 حالة، بواقع 3 دقائق لكل حالة، 45 دقيقة أسبوعياً. وفي المقابل، تحصل على تصحيحات لمعيار التقييم في المواضع التي تختلف فيها أنت وأداة التقييم، إضافة إلى حالات جديدة لأنواع إخفاق لم يتوقعها أحد. اكتب الحكم البشري في الجدول نفسه، مع ضبط graded_by على human، بحيث يصبح توافق أداة التقييم مع الإنسان استعلاماً بدلاً من أن يبقى في الذاكرة.

ما الذي يتعطل في أداة الاختبار نفسها

anthropic.RateLimitError في أول تشغيل كامل. يؤدي توزيع ستين حالة دفعة واحدة إلى تجاوز حد الطلبات أو الرموز المسموح به في خطتك. حدّد التزامن بأربعة عمال، وانقل التشغيل الليلي إلى Batch API.

json.JSONDecodeError: Expecting value: line 1 column 1 (char 0) من أداة التقييم. أجاب النموذج بنثر، أو وضع JSON داخل كتلة تعليمات برمجية. أعد المحاولة مرة واحدة، ثم سجّل الحالة كخطأ. لا تسمح أبداً بأن يُحتسب فشل التحليل كنجاح، لأن مجموعة تحوّل الأخطاء إلى نجاحات ستقترب من 100% بينما يتراجع أداء الوكيل.

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

تدهور المجموعة المرجعية. يعدّل أحدهم إجابة متوقعة لجعل المجموعة خضراء. راجع الفروقات في evals/cases.jsonl بعناية مساوية لمراجعة الفروقات في الوكيل، لأن هذا الملف هو تعريفك المكتوب للصواب.

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

FAQ

كم عدد الحالات التي تحتاج إليها مجموعة تقييم وكيل ذكاء اصطناعي؟

ابدأ بـ40 إلى 80 حالة، ثم وسّع المجموعة استناداً إلى حالات الفشل الفعلية. عندما يقل العدد عن نحو 20 حالة، تؤدي نتيجة واحدة غير مستقرة إلى تغيير معدل النجاح بمقدار 5 نقاط، لذلك يفقد هذا المعدل قيمته المعلوماتية. بعد بضع مئات من الحالات، تصبح كل عملية تشغيل مكلفة من حيث المال والوقت، بينما تضيف الحالة الهامشية تغطية محدودة. المقياس المهم ليس العدد، بل نسبة أنواع الفشل المعروفة في بيئة الإنتاج التي تظهر في المجموعة مرة واحدة على الأقل.

هل يمكنني الوثوق بحَكَم LLM لتقييم وكيلي؟

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

ما النموذج الذي ينبغي أن يقيّم اختبارات التقييم؟

استخدم التقييم الرخيص أولاً، ثم صعّد الحالات. لا تكلف التأكيدات الحتمية شيئاً، لذلك تُشغَّل أولاً على كل حالة. يتولى نموذج صغير الحالات التي تكون نتائجها واضحة. تُحال حالات الفشل والنتائج منخفضة الثقة فقط إلى نموذج متقدم. وفق الأسعار المعلنة في August 2026، يكلف تقييم 1,000 حالة نحو 1.80 دولاراً أمريكياً باستخدام Claude Haiku 4.5، ونحو 9.00 باستخدام Claude Opus 5. وبما أن عمليات التقييم غير متزامنة، فإن Batch API تخفض أياً من التكلفتين إلى النصف.

هل تحل اختبارات التقييم محل مراقبة الإنتاج؟

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