أفضل أطر عمل مفتوحة المصدر لتقييم LLM في 2026 (واحد منها ليس مفتوح المصدر فعلاً)

أفضل أطر عمل مفتوحة المصدر لتقييم LLM في 2026 (واحد منها ليس مفتوح المصدر فعلاً)

السطر الأول من ملف LICENSE في مستودع Arize Phoenix يقول "Elastic License 2.0 (ELv2)". ليس Apache. وليس MIT. أحد أكثر أطر تقييم LLM مفتوحة المصدر توصيةً ليس مفتوح المصدر بحسب تعريف OSI، وتكاد كل صفحة تتصدّر نتائج هذا البحث تكرر الادعاء ذاته. وهذا ما فعلته إحدى صفحاتنا أيضًا، حتى اليوم. في 2026-08-04 قرأنا يدويًا ملف الترخيص وسجل الالتزامات على الفرع الرئيسي لثمانية أطر عمل، إضافة إلى ثلاثة أخرى ما زالت الصفحات المتصدّرة توصي بها، ثم ثبّتنا ستة منها وشغّلنا نفس الحالات العشر عبر كل واحد. نحن لا نبيع إطار تقييم، فلا حكم أدناه يحمي منتجًا.

أبرز النقاط

• Arize Phoenix يُنشر بترخيص Elastic License 2.0، وهو ترخيص لا تعتمده OSI كمفتوح المصدر.
• آخر التزام لـ UpTrain على main كان في 2024-07-29. لا تبدأ مشروعًا جديدًا عليه.
• أمر pip install promptfoo يجلب حزمة مغلّفة من طرف ثالث. المشروع الحقيقي يُنشر على npm.
• Ragas لم يشهد أي التزام منذ 2026-02-24، وانتقل إلى منظمة GitHub جديدة باسم vibrantlabsai.

أي إطار عمل مفتوح المصدر لتقييم LLM يجب أن تثبّته في 2026؟

اختر بناءً على القيد، لا الترتيب. للتأكيدات على هيئة pytest داخل مجموعة اختبارات قائمة، ثبّت DeepEval. لملف YAML وواجهة سطر أوامر تناسب أي مكدّس لغوي، ثبّت promptfoo. لأنظف فصل بين الجيد والسيئ رصدناه، ثبّت Opik. الثلاثة جميعًا مرخّصة بـ Apache-2.0 أو MIT.

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

التواريخ هي تاريخ آخر التزام على الفرع الرئيسي لكل مشروع حتى 2026-08-04. صفحة المستودع في GitHub تعرض آخر دفعة على أي فرع، وهو تاريخ لاحق لمشروعين هنا: UpTrain في 2024-08-18 وDeepchecks في 2025-12-28. لا مستودع منهما مؤرشف.

عمود تكلفة التبديل هو ما يتجاهله الناس ثم يندمون عليه. الدرجات مجرد أرقام، فالانتقال بين DeepEval وRagas وOpik وأداة phoenix-evals يعني غالبًا إعادة كتابة حلقة تكرار فقط. أما ترك promptfoo أو Inspect AI فيعني إعادة كتابة صيغة إعداد أو مهام لا مكافئ لها في مكان آخر، وترك Evidently يعني تدقيق كل عتبة كتبتها، لأن مقياسه يعمل بالاتجاه المعاكس. اثنان من الأطر التي ما زالت الصفحات المتصدّرة توصي بها لم يصدرا إصدارًا جديدًا منذ 2024.

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

أطر تقييم LLM الثمانية مصنّفة بحسب طريقة التثبيت

شكل التثبيت هو ما ستتعايش معه، لذلك اخترناه أساسًا للتصنيف.

مكتبات بايثون تستوردها داخل الاختبارات

DeepEval (pip install deepeval، Apache-2.0) يغلّف مقاييس LLM في تأكيدات على نمط pytest: تبني LLMTestCase، وتسلّمها إلى assert_test، فيفشل الاختبار إذا نزلت الدرجة عن عتبتك. الأفضل في وضع بوابة جودة بجانب اختبارات الوحدة التي يشغّلها الفريق أصلًا. اختره إن كانت تقييماتك يجب أن تعيش في نفس مهمة CI مع كل شيء آخر.

إفصاح واحد، يُذكر مرة واحدة: DeepEval بناه فريق Confident AI، وهو شريك مدفوع في منشورين آخرين على هذا الموقع، منها المقارنة المرتبة التي تحيل إليها هذه الصفحة. لا يحصل على أي معاملة خاصة هنا، وكل رابط لـ DeepEval في هذه الصفحة يشير إلى مستودع GitHub.

Ragas (pip install ragas، Apache-2.0) هو الخيار المخصص لـ RAG: دالة evaluate() تأخذ صفوف السؤال والسياق والإجابة وتُرجع درجات لكل مقياس بشكل غير متزامن. الأفضل في قياس جودة الاسترجاع داخل خط معالجة بايثون. انتقل مستودعه من explodinggradients إلى vibrantlabsai، وكان آخر إصدار له v0.4.3 في 2026-01-13، ولا التزامات منذ 2026-02-24. اختره إن كانت مقاييس RAG هي كل المطلوب وكان مستودع هادئ مقبولًا لديك، وراجع مجموعة أدوات RAG الأوسع.

Opik (pip install opik، Apache-2.0، من Comet) يوفّر مقاييس يمكنك استدعاؤها بشكل مستقل. اضبط OPIK_TRACK_DISABLE=true وستعمل AnswerRelevance().score() دون حساب ودون خادم محلي ودون ملف إعداد، وهو ما لا يُعلن عنه التسويق للمنتج. الأفضل في الحصول على درجة حقيقية في أقل عدد أسطر. اختره إن أردت المقاييس الآن والمنصّة لاحقًا ربما.

Evidently (pip install evidently، Apache-2.0) يعامل التقييمات كواصفات فوق مجموعة بيانات ويكتب تقرير HTML كأثر جانبي. الأفضل في التقارير الدفعية عبر صفوف كثيرة بدلًا من بوابة ثنائية. درجاته لمقاييس LLM معكوسة: 1.0 تعني غير موثوقة الأساس (unfaithful). اختره إن كان ما تدين به لأحد هو تقرير قابل للمشاركة، لا بناء أحمر.

Giskard (pip install giskard، Apache-2.0) يفحص نموذجًا بحثًا عن ثغرات بدلًا من تسجيل درجات لمجموعة بيانات كتبتها. حزمة PyPI تحلّ سلسلة v2، وملف README الخاص بالمشروع نفسه يذكر أن v2 "لم تعد تحت الصيانة النشطة". الأفضل في فحوصات آلية على نمط الفريق الأحمر. اختره إن أردت أن تُكتشف الثغرات لك بدلًا من مقاييس LLM-as-a-judge التي تحددها بنفسك.

أدوات CLI وإعدادات تعمل على ملف YAML

promptfoo (npm install promptfoo، MIT) هو أداة سطر أوامر تقرأ ملف YAML: تعلن عن مزودين وحالات اختبار وتأكيدات، تشغّل npx promptfoo eval، وتحصل على نجاح/فشل لكل حالة إضافة إلى واجهة نتائج محلية. الأفضل في تقييم الموجّهات عندما لا يكون تطبيقك مكتوبًا بلغة بايثون. اختره إن كان يجب أن تكون بوابة الجودة لديك ملف إعداد يستطيع تعديله زميل لا يعرف بايثون.

فئة أدوات القياس المعيارية (harness) والحزم المدمجة بمنصّات

Inspect AI (pip install inspect-ai، MIT) قادم من معهد سلامة الذكاء الاصطناعي البريطاني (UK AI Safety Institute) ويقيّم النماذج مقابل مهام تحددها في بايثون، بتجريدات حقيقية للحلّالين والمُقيّمين ومُشاهد تشغيل. الأفضل في قياس أداء النماذج معياريًا بتعريفات مهام قابلة لإعادة الإنتاج. اختره إن كان الشيء قيد الاختبار نموذجًا لا تطبيقك.

Arize Phoenix (pip install arize-phoenix-evals) يمنحك مُقيّمات جاهزة مثل FaithfulnessEvaluator وCorrectnessEvaluator تُرجع تصنيفًا ثنائيًا إضافة إلى درجة. الأفضل في تصنيفات حتمية يمكنك بناء بوابة عليها دون اختيار عتبة. ترخيصه هو سبب وجود القوس في عنوان هذا المقال، وله قسم مستقل تاليًا.

هل Arize Phoenix مفتوح المصدر؟

لا، ليس بحسب التعريف الذي تتبناه Open Source Initiative. Arize Phoenix يُنشر بترخيص Elastic License 2.0 (ELv2). السطر الأول من ملف LICENSE الخاص بالمستودع يقول ذلك، وPyPI يُعلن بشكل مستقل license: Elastic-2.0 على الإصدار v19.15.0. المصدر قابل للقراءة والتفريع والاستضافة الذاتية. استخدام واحد فقط مقيَّد.

القيد المهم هو التالي: ELv2 يحظر تقديم البرنامج لأطراف ثالثة كخدمة مستضافة أو مُدارة. اقرأ هذا بعناية، لأنه يقيّد عددًا أقل بكثير مما يبدو. إن كنت تثبّت arize-phoenix-evals لتسجيل درجات تطبيقك الخاص، فلن يلمسك ELv2 إطلاقًا. أما إن كنت شركة استشارية أو فريق منصّة يحزم Phoenix ضمن خدمة تقييم تبيعها لعملاء خارجيين، فسيلمسك. هذا هو الفارق كله، وتعريف المصدر المفتوح هو ما يخفق فيه ELv2، تحديدًا البنود المتعلقة بقيود مجال الاستخدام.

كل صفحة تتصدّر نتائج هذا البحث حاليًا تصنّف Phoenix تحت "مفتوح المصدر"، وكذلك فعلنا نحن. مقارنتنا المرتبة لأدوات تقييم LLM تصف Phoenix بأنه مفتوح المصدر بالكامل، وهذا خطأ، ويجري تصحيحه الآن. Phoenix متاح المصدر (source-available)، لا مفتوح المصدر، والفارق لا يهم إلا إن كنت تخطط لبيعه كخدمة. وإن كان ما تحتاجه فعلًا هو التتبّع لا التسجيل، فذلك ينتمي إلى منصات مراقبة الذكاء الاصطناعي، لا إلى هنا.

أي هذه الأطر ما زال يحظى بصيانة نشطة؟

معظمها. ستة من أصل أحد عشر مستودعًا فحصناها تلقّت التزامًا على main في 2026-08-03 أو 2026-08-04: DeepEval وpromptfoo وOpik وArize Phoenix وInspect AI وGiskard. اثنان لم يصدرا إصدارًا منذ 2024. واحد هدأ خلال 2026 بعد تغيير منظمة GitHub.

أطر لن نبدأ عليها مشروعًا جديدًا في 2026

UpTrain ميت. آخر التزام له على main كان في 2024-07-29، وآخر إصدار له، v0.7.1، كان في 2024-05-14، ما يجعله باردًا لسنتين على أي من المقياسين. المستودع لا يزال موجودًا وما زال مرخّصًا بـ Apache-2.0، فلا شيء يمنعك، لكن البدء بعمل جديد على مكتبة تقييم مهجورة قرار ستضطر لتفسيره لاحقًا.

Deepchecks يستحق النسخة الدقيقة. لم يصدر إصدارًا منذ 0.19.1 في 2024-12-15، رغم أن المستودع ما زال يتلقى التزامات، وكان آخرها على main بتاريخ 2025-11-24. أناس ما زالوا يعملون عليه؛ لكن لم يقطع أحد إصدارًا منذ أكثر من ثمانية عشر شهرًا. لا UpTrain ولا Deepchecks مؤرشف على GitHub، ولا أحدهما أُغلق أمام المساهمات.

Ragas له تواريخ ولا شيء غيرها. آخر إصدار v0.4.3 في 2026-01-13، ولا التزامات منذ 2026-02-24، والمستودع انتقل من explodinggradients إلى vibrantlabsai. لم نجد تفسيرًا موثّقًا لسبب تغيير المنظمة، فلن نختلق واحدًا. المستودع الهادئ ليس بالضرورة مستودعًا معطلًا: كود Apache-2.0 الذي يحسب درجة موثوقية اليوم سيحسبها العام المقبل أيضًا. الخطر هو الاعتماديات غير المرقّعة، وهو بالضبط ما آذانا في الاختبار أدناه.

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

هل تحتاج إلى إطار تقييم أم أداة قياس معيارية (harness)؟

إطار تقييم التطبيقات يسجّل درجات لمخرجات تطبيقك الخاص مقابل بياناتك الخاصة. DeepEval وRagas وpromptfoo وOpik وphoenix-evals وEvidently تفعل ذلك جميعًا. أما أداة القياس المعيارية للنموذج (harness) فتقيس أداء نموذج مقابل مهام عامة موحّدة بدلًا من ذلك. lm-evaluation-harness وInspect AI تفعلان ذلك. اختيار الفئة الخاطئة هو أغلى خطأ في هذه الصفحة.

نمط الفشل ملموس. شخص ما يوصّل lm-evaluation-harness لاختبار روبوت محادثة RAG خاص به، يحصل على مجموعة درجات MMLU، ولا يتعلّم شيئًا بالضبط عمّا إذا كان مسترجعه يعيد المقاطع الصحيحة. الدرجات حقيقية. لكنها تقيس النموذج الأساسي، وهو ما لم يكن أحد قلقًا بشأنه.

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

ماذا حدث عندما ثبّتنا ستة منها وشغّلنا نفس الحالات العشر

في 2026-08-04 ثبّتنا ستة من هذه الأدوات في بيئات بايثون 3.11.14 جديدة (إضافة إلى npm لـ promptfoo) وسجّلنا درجات لمجموعة RAG واحدة مكوّنة من 10 عناصر متطابقة، بحكَم واحد هو openai/gpt-4o-mini عبر OpenRouter وحرارة (temperature) صفر. سبعة عناصر كانت صحيحة. ثلاثة كانت معطوبة بثلاث طرق مختلفة: واحد يناقض سياقه، وآخر يختلق تفاصيل، وثالث نثر بليغ لا يجيب على السؤال إطلاقًا. شُغّل كل إطار مرتين، تباعًا.

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

مقاييس الصلة ليست مقاييس جودة، ومقياسان منها سجّلا لكذبة واثقة درجة أعلى من إجابة صحيحة. مقياس ResponseRelevancy في Ragas سجّل للعنصر الذي يزعم أن HTTP 404 هو خطأ خادم من فئة 5xx درجة 0.777، أعلى من درجتين من الإجابات الصحيحة السبع، وسجّل للعنصر الذي اختلق حدود معدل استخدام درجة 0.813، أعلى من أربع منها. مقياس answer-relevance في promptfoo فعل الشيء نفسه: 0.800 لعنصر الـ404، نجاح واضح مقابل عتبة 0.7، بينما أخفق مع q01 الصحيح عند 0.679. ليست علة برمجية. الإجابة الخاطئة الواثقة تعالج السؤال بمثالية. لكن إن كانت الصلة هي الرقم على لوحة متابعتك، فسيبدو الهلوسة البليغة أفضل مخرجاتك.

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

المُقيّمات الثنائية كانت مستقرة عند حرارة صفر. أما المُقيّمة تدرجيًا فلم تكن كذلك. Phoenix وDeepEval لم يحرّكا أي عنصر من العشرة عبر تشغيلين متطابقين. Opik حرّك أربعة، جميعها على AnswerRelevance، على شبكة درجات بفواصل 0.05؛ وEvidently حرّك أربعة أيضًا. لم ينقلب أي حكم هنا بسبب الانحراف، لكن q01 الصحيح في promptfoo هبط من 0.679 إلى 0.642 مقابل عتبة 0.700، وهذا هو شكل بوابة CI متقلبة.

ملاحظتان أصغر: ثلاثة من ستة (DeepEval وOpik وPhoenix) ثُبّتت وعملت بسلاسة من المرة الأولى، بينما رفض Ragas الاستيراد حتى ثبّتنا langchain-community<0.4. promptfoo وحده أبلغ عن استهلاك رموز الحكم (judge tokens)، 16,011 رمز تأكيد في التشغيل الأول و16,010 في الثاني.

حدود هذا الاختبار، بوضوح. n = 10 اختبار دخان لا معيار قياسي: يخبرك عن سهولة الاستخدام والعيوب العمياء، لا عن دقة المقياس. حكم واحد فقط سجّل كل شيء، وحكم أكبر سيغيّر كل رقم، على الأرجح بما في ذلك النتيجتان الإيجابيتان الكاذبتان اللتان أنتجهما DeepEval وRagas على نفس العنصر الصحيح. تشغيلان يثبتان وجود الانحراف ولا يمكنهما وصف طبيعته. الإجابات كانت مكتوبة مسبقًا، فلا شيء هنا يختبر التوليد أو التتبّع أو إدارة مجموعات البيانات، ما يجعل زمن تثبيت promptfoo البالغ 337.9 ثانية يبدو أسوأ مما يستحق. "الأفضل" يعني دائمًا الأفضل لقيد معيّن: بوابة CI أو مقاييس RAG أو واجهة مستخدم، كل منها يغيّر الإجابة، وكذلك الفرق بين التقييم عبر الإنترنت ودون اتصال.

الفحص نفسه، مكتوب بثلاث طرق

أسرع طريقة لاختيار شكل الواجهة هي قراءة نفس التأكيد ثلاث مرات. إليك فحص موثوقية على عنصر واحد في DeepEval وRagas وpromptfoo، مقتطف من السكربتات التي شغّلناها فعلًا. أسماء المقاييس تختلف؛ نحيل إلى كيف تعمل مقاييس LLM-as-a-judge فعلًا بدلًا من إعادة تعريفها هنا.

# DeepEval 4.1.5: على نمط pytest، يُفشل الاختبار إذا نزل عن العتبة
from deepeval import assert_test
from deepeval.models import GPTModel
from deepeval.metrics import FaithfulnessMetric
from deepeval.test_case import LLMTestCase

judge = GPTModel(
    model="openai/gpt-4o-mini",
    base_url="https://openrouter.ai/api/v1",
    api_key=OPENROUTER_KEY,
)

def test_faithfulness():
    case = LLMTestCase(
        input=question,
        actual_output=answer,
        retrieval_context=[context],
    )
    assert_test(case, [FaithfulnessMetric(threshold=0.7, model=judge)])

# Ragas 0.4.3: انتبه لمسار الاستيراد. `from ragas.metrics import Faithfulness`
# يرفع ImportError في هذا الإصدار؛ المقياس المحدد انتقل مكانه.
from ragas import evaluate, EvaluationDataset
from ragas.metrics._faithfulness import Faithfulness
from ragas.llms import LangchainLLMWrapper
from langchain_openai import ChatOpenAI

judge = LangchainLLMWrapper(
    ChatOpenAI(model="openai/gpt-4o-mini",
               base_url="https://openrouter.ai/api/v1")
)

result = evaluate(
    dataset=EvaluationDataset.from_list(rows),
    metrics=[Faithfulness(llm=judge)],
)

# promptfoo 0.121.20: npm install promptfoo، ثم npx promptfoo eval
providers:
  - id: echo          # سجّلنا درجات لإجابات مكتوبة مسبقًا بدلًا من توليدها
defaultTest:
  assert:
    - type: context-faithfulness
      threshold: 0.7
tests:
  - vars:
      query: "Is HTTP 404 a client error or a server error?"
      context: "HTTP 404 Not Found is in the 4xx class, which denotes client errors."
      output: "HTTP 404 is a server error in the 5xx class."

سطور التثبيت تحمل من الفخاخ أكثر مما يحمله الكود، وكل تعليق أدناه هو شيء كلّفنا وقتًا فعليًا في 2026-08-04:

# النسخة الحقيقية من promptfoo تُنشر على npm. حزمة PyPI بنفس الاسم
# هي حزمة مغلّفة من طرف ثالث: https://pypi.org/project/promptfoo/ مقابل
# https://www.npmjs.com/package/promptfoo
npm install promptfoo

# pip install giskard يحلّ سلسلة v2، التي يذكر README الخاص بالمشروع نفسه
# أنها لم تعد تحت الصيانة النشطة.
pip install giskard

# lm-evaluation-harness يُثبَّت باسم الحزمة lm-eval.
pip install lm-eval

# Evidently لا يسحب openai، والحكم ينهار وقت الاستدعاء لا وقت الاستيراد،
# بعد أن تكون قد بنيت مجموعة البيانات بالفعل.
pip install evidently openai

# Ragas 0.4.3 لن يستورد ضد langchain-community 0.4.x.
pip install ragas "langchain-community<0.4"

هل يمكنك إفشال بناء اعتمادًا على درجة تقييم؟

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

هذا هو شكل سير العمل الذي نشغّله، مثبّت على الإصدارات من اختبارنا في 2026-08-04:

name: evals
on: [pull_request]

jobs:
  eval:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: "3.11.14"
      - run: pip install deepeval==4.1.5

      - name: Score the golden set
        env:
          # ثبّت الحكم. ترقية النموذج منتصف الربع تغيّر كل درجة.
          JUDGE_MODEL: openai/gpt-4o-mini
          # العتبات تعيش في مكان واحد، تقرأها منشئات المقاييس.
          EVAL_THRESHOLD: "0.7"
          OPENROUTER_API_KEY: ${{ secrets.OPENROUTER_API_KEY }}
        run: deepeval test run tests/evals/

مشكلتان تظهران قبل العتبة نفسها. أولًا، استدعاءات الحكم هي استدعاءات شبكة: تشغيل DeepEval لدينا من 10 عناصر استغرق 126.8 ثانية لأن .measure() تسلسلية، ومجموعة بيانات ذهبية من 200 عنصر على هذا المسار استراحة قهوة في كل طلب سحب. كل إطار آخر في الاختبار يوازي التنفيذ افتراضيًا، وهو أكبر رافعة منفردة لزمن جدار CI.

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

للمقارنة على نطاق أوسع: استطلاع حالة هندسة الوكلاء من LangChain (1,340 ردًا، جُمعت بين 18 نوفمبر و2 ديسمبر 2025، ونُشرت في 12 يونيو 2026) وجد أن 89% من المؤسسات طبّقت شكلًا ما من المراقبة لوكلائها، بينما 52.4% فقط تشغّل تقييمات دون اتصال على مجموعات اختبار. المراقبة شائعة. أما البوابة فليست كذلك.

ما الذي كنا سنثبّته هذا الأسبوع

أربعة أشياء يجب أخذها بعين الاعتبار. Arize Phoenix متاح المصدر تحت رخصة Elastic License 2.0 وغير معتمد من OSI كمفتوح مصدر، ما لا يغيّر شيئًا لمعظم القراء ويغيّر كل شيء إن كنت تعيد بيع أدوات التقييم. UpTrain ميت، وصفحات دون تاريخ ما زالت توصي به. Deepchecks لم يقطع إصدارًا منذ ديسمبر 2024 أيضًا، رغم أن مستودعه ما زال يتلقى التزامات. ولكل مقياس موثوقية ومقياس صلة ثغرة يغطيها الآخر، فابنِ بوابتك على الاثنين معًا. والدرجات المتدرجة تنحرف حتى عند حرارة صفر، فثبّت حكمك وأعطِ العتبات هامشًا.

لو كنت أبدأ مجموعة تقييمات جديدة هذا الأسبوع، لثبّت DeepEval لبوابة CI لأن التأكيدات تنتمي بجانب الاختبارات (الإفصاح أعلاه)، وأضفت مقاييس Opik المستقلة لأنظف فصل قسناه. ولو لم يكن مكدّسنا بايثون، لاخترت promptfoo دون تردد. وإن كنت تفضّل أن يتولى شخص آخر توصيل المجموعة الذهبية وسير العمل، هذه محادثة يسرّنا أن نجريها.

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

ما هو أفضل إطار عمل مفتوح المصدر لتقييم LLM؟

لا يوجد فائز واحد، بل أفضل ملاءمة لكل قيد. لبوابة نجاح/فشل داخل مجموعة اختبارات بايثون، DeepEval. لإعداد YAML وCLI مستقل عن اللغة، promptfoo. لمقاييس استرجاع RAG، Ragas، إن كان بإمكانك قبول مستودع بلا التزامات منذ 2026-02-24. لأنظف فصل بين الإجابات الجيدة والسيئة في اختبارنا بتاريخ 2026-08-04، Opik.

هل Arize Phoenix مفتوح المصدر؟

ليس بحسب تعريف Open Source Initiative. Arize Phoenix يُنشر بترخيص Elastic License 2.0، الذي يُعلنه PyPI كـ license: Elastic-2.0 على الإصدار v19.15.0، والذي يذكره السطر الأول من ملف LICENSE في المستودع مباشرة. هو متاح المصدر: يمكنك قراءته وتفريعه وتعديله واستضافته ذاتيًا. القيد الوحيد هو تقديم البرنامج لأطراف ثالثة كخدمة مستضافة أو مُدارة.

هل Ragas ما زال تحت الصيانة؟

الحقائق القابلة للتحقق، حتى 2026-08-04: آخر إصدار كان v0.4.3 في 2026-01-13، ولا التزامات منذ 2026-02-24، وانتقل المستودع من منظمة explodinggradients إلى vibrantlabsai. المستودع غير مؤرشف. لم نجد تفسيرًا عامًا موثوقًا لتغيير المنظمة ولن نخمّن واحدًا. كود Apache-2.0 ما زال يعمل؛ والخطر هو الاعتماديات غير المرقّعة.

هل أحتاج إلى إطار تقييم أم منصة مراقبة؟

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

هل يمكنني تشغيل تقييمات LLM في CI/CD؟

نعم. كل إطار غطيناه هنا يخرج برمز غير صفري عند فشل تأكيد عتبة، وهذا كل ما تحتاجه مهمة GitHub Actions. القيود العملية هي زمن الجدار (استدعاءات الحكم هي استدعاءات شبكة، وتشغيل DeepEval التسلسلي لدينا استغرق 126.8 ثانية لـ10 عناصر) وعدم حتمية الحكم. شكل سير العمل والمعالجات موجودان في قسم CI أعلاه.

ما الفرق بين DeepEval وRagas؟

شكل الواجهة والنطاق، لا الجودة. DeepEval على نمط pytest وعام الغرض: تكتب حالات اختبار وتؤكد على عتبات المقاييس، ويغطي مخرجات تطبيقات من أنواع كثيرة. Ragas مكتبة مخصصة لـ RAG تعمل دالتها evaluate() بشكل غير متزامن فوق مجموعة بيانات من صفوف السؤال والسياق والإجابة. DeepEval يناسب بوابة CI بشكل طبيعي أكثر؛ وRagas يتعمّق أكثر في الاسترجاع.

لماذا يمنحني pip install promptfoo الحزمة الخاطئة؟

لأن promptfoo مشروع Node. النسخة الحقيقية منشورة على npm تحت رخصة MIT وتُثبَّت بأمر npm install promptfoo. حزمة PyPI بنفس الاسم هي حزمة مغلّفة من طرف ثالث، لا المشروع الأصلي، وتثبيتها طريقة شائعة لينتهي بك المطاف بتصحيح أخطاء واجهة سطر أوامر ليست تلك التي يصفها التوثيق.

هل lm-evaluation-harness إطار تقييم LLM؟

هو أداة قياس معيارية للنموذج (harness)، وهي مهمة مرتبطة لكنها مختلفة. lm-evaluation-harness (يُثبَّت باسم pip install lm-eval) يقيس أداء نموذج مقابل مهام عامة موحّدة مثل MMLU. لن يخبرك ما إذا كان خط استرجاعك أعاد المقطع الصحيح، لأن تطبيقك ليس مفهومًا يملكه أصلًا. راجع قسم إطار التقييم مقابل أداة القياس المعيارية أعلاه لمعرفة الفارق.

هل هذه الأطر مجانية الاستخدام؟

من ناحية الترخيص، نعم. DeepEval وRagas وOpik وEvidently وGiskard مرخّصة بـ Apache-2.0؛ وpromptfoo وInspect AI وlm-evaluation-harness مرخّصة بـ MIT. كلا الترخيصين يسمحان بالاستخدام التجاري والتعديل وإعادة التوزيع. Arize Phoenix هو الاستثناء: Elastic License 2.0 يسمح بالاستضافة الذاتية لكن لا يسمح بتقديم البرنامج لأطراف ثالثة كخدمة مُدارة. استخدام واجهة برمجة نموذج الحكم يُحاسب عليه مزودك بشكل منفصل.