التقييم الآلي (Evaluation): كيف تتأكد أن إجابات الذكاء الاصطناعي دقيقة وليست خيالية؟

ما هو التقييم الآلي ولماذا أصبح طبقة إلزامية في تطبيقات LLMs؟

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

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

عملياً، إذا كنت تبني نظام RAG أو Agent أو أداة Text-to-SQL، فأنت تحتاج إلى طبقة تقييم تقيس هل الإجابة مدعومة بالمصدر؟ هل استخدمت السياق المسترجع فعلاً؟ هل أنتجت النموذج حقائق غير موجودة؟ وهل تكرار تشغيل نفس السؤال ضمن إعدادات ثابتة يعطي نتائج مستقرة؟

البنية الهندسية لنظام التقييم الآلي داخل تطبيقات الذكاء الاصطناعي

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

مكونات البنية الأساسية

• مجموعة أسئلة مرجعية Evaluation Dataset.
• إجابات صحيحة متوقعة أو معايير تحكيم Ground Truth.
• طبقة تشغيل التطبيق الفعلي: Chain أو Retriever أو Agent.
• محرك قياس يقارن بين الناتج الفعلي والمعيار.
• لوحة نتائج تجمع الدرجات، المتوسطات، حالات الفشل، وأنماط الأخطاء المتكررة.

في أنظمة دمج المعلومات المسترجعة مع الـ LLM لتوليد إجابة دقيقة وبدون هلوسة، يتدفق السؤال أولاً إلى Retriever لجلب المقاطع المناسبة، ثم تُرسل المقاطع مع السؤال إلى النموذج، وبعد ذلك تأتي طبقة التقييم لتسأل: هل الإجابة النهائية مدعومة بالمقاطع المسترجعة؟ إن لم تكن كذلك فهذه إشارة هلوسة حتى لو بدا النص مقنعاً.

أنواع المقاييس التي يجب قياسها فعلياً

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

1) الدقة الواقعية Factual Accuracy

تقيس هل المعلومة صحيحة بالنسبة للمصدر أو الحقيقة المرجعية. هذا مهم جداً في التطبيقات التعليمية والطبية والمالية.

2) الارتباط بالسياق Context Relevance

إذا كنت تعمل على الخطوة الثالثة في RAG: استرجاع المعلومات المطابقة لسؤال المستخدم (Retriever)، فيجب التحقق أن المستندات المسترجعة مناسبة أصلاً قبل لوم النموذج على النتيجة.

3) الإسناد للمصدر Faithfulness

هذا المقياس يسأل: هل الإجابة مستندة إلى السياق المتاح أم أضاف النموذج معلومات من عنده؟ وهو من أهم مؤشرات كشف الهلوسة.

4) الاكتمال Completeness

قد تكون الإجابة صحيحة لكنها ناقصة. لذلك نقيس هل أجابت على كل أجزاء السؤال أم على جزء واحد فقط.

5) الالتزام بالبنية Format Compliance

خصوصاً إذا كنت تستخدم استخراج بيانات مهيكلة (Output Parsers): إجبار الذكاء الاصطناعي على الرد بصيغة JSON فقط، فالتقييم يجب أن يفحص هل خرجت الاستجابة بصيغة JSON صالحة أم لا.

كيف تبني مجموعة اختبار قوية بدلاً من الاعتماد على الانطباع الشخصي؟

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

• أسئلة مباشرة بإجابات قصيرة.
• أسئلة متعددة الخطوات تحتاج استدلالاً.
• أسئلة غامضة لاختبار إدارة عدم اليقين.
• أسئلة خارج النطاق لاختبار قدرة النظام على الرفض الآمن.
• أسئلة فيها وثائق طويلة لاختبار جودة الاسترجاع والتقطيع، كما في تقطيع النصوص الضخمة (Text Splitters) إلى أجزاء صغيرة تتناسب مع حجم الـ LLMs.

يفضل تخزين بيانات التقييم في ملف JSON أو CSV يحتوي على الحقول: السؤال، السياق المتوقع، الإجابة المرجعية، ونوع الاختبار.

evaluation_samples = [
    {
        "question": "What is retrieval augmented generation?",
        "ground_truth": "RAG is a method that retrieves external knowledge before generation.",
        "expected_topic": "rag",
        "test_type": "factual"
    },
    {
        "question": "Return the answer as JSON with keys: answer, confidence",
        "ground_truth": {"answer": "valid", "confidence": "float"},
        "expected_topic": "formatting",
        "test_type": "json_schema"
    }
]

التقييم بالقواعد مقابل التقييم بواسطة نموذج حاكم

هناك مساران أساسيان. الأول هو Rule-based Evaluation مثل فحص بنية JSON أو وجود كلمات إلزامية أو التحقق من مطابقة ناتج SQL لصياغة معينة. الثاني هو LLM-as-a-Judge حيث نستخدم نموذجاً آخر لتحكيم جودة الإجابة.

التحكيم بالنموذج مفيد عندما تكون الصياغات الصحيحة متعددة، لكنه يحتاج برومبت واضحاً جداً حتى لا تصبح عملية القياس نفسها غير مستقرة. إذا سبق وطبقت هندسة الأوامر (Prompt Engineering) داخل الكود: قوالب النصوص المتغيرة (F-Strings) فستلاحظ أن جودة التقييم نفسها تعتمد على وضوح تعليمات الحكم.

You are an evaluation judge. Score the answer from 0 to 1 based on factual consistency with the provided context only. Do not use outside knowledge. Return JSON with keys: score, reason.

def build_judge_prompt(question, context, answer):
    return f"""
You are an evaluation judge.
Question: {question}
Context: {context}
Answer: {answer}

Score the answer from 0 to 1 based only on factual consistency with the context.
Return JSON with keys: score, reason.
"""

مثال هندسي باستخدام Python لتقييم إجابات التطبيق

في المثال التالي نفترض أن لديك دالة اسمها run_app() تستقبل السؤال وتعيد الإجابة. ثم نضيف طبقة تقييم تلقائية تجمع النتائج في تقرير واحد.

import json

def simple_exact_match(prediction, ground_truth):
    return prediction.strip().lower() == ground_truth.strip().lower()

def evaluate_app(samples, run_app):
    results = []

    for sample in samples:
        prediction = run_app(sample["question"])

        if sample["test_type"] == "factual":
            score = 1.0 if simple_exact_match(prediction, sample["ground_truth"]) else 0.0
            results.append({
                "question": sample["question"],
                "prediction": prediction,
                "score": score,
                "test_type": sample["test_type"]
            })

        elif sample["test_type"] == "json_schema":
            try:
                parsed = json.loads(prediction)
                valid = "answer" in parsed and "confidence" in parsed
                score = 1.0 if valid else 0.0
            except Exception:
                score = 0.0

            results.append({
                "question": sample["question"],
                "prediction": prediction,
                "score": score,
                "test_type": sample["test_type"]
            })

    return results

هذا المثال بسيط، لكنه يوضح الفكرة: التقييم ليس تعليقاً يدوياً، بل برنامج مستقل يمكن تشغيله بعد كل تعديل على Prompt أو بعد تحديث قاعدة المعرفة أو تغيير إعدادات التحكم في إبداع الذكاء الاصطناعي: فهم وإعداد معاملات Temperature و Top-K برمجياً.

أين تظهر الهلوسة فعلياً داخل خط المعالجة؟

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

• إذا كانت المقاطع المسترجعة ضعيفة، راجع تحسين RAG: استخدام خوارزمية (MMR) لضمان تنوع ودقة المعلومات المسترجعة.
• إذا كانت الإجابة تخرج خارج البنية المطلوبة، راجع طبقة Output Parsing.
• إذا كان الانحراف يظهر مع الحوارات الطويلة، افحص الذاكرة كما في الذاكرة في الذكاء الاصطناعي: لماذا ينسى الـ API المحادثات السابقة وكيف نعالج ذلك؟.
• إذا كانت النتائج تتدهور بعد تحديثات الكود، استخدم المراقبة المستمرة مثل مراقبة أداء التطبيقات: تتبع استهلاك الرموز (Tokens) والتكلفة لكل مستخدم عبر LangSmith.

أفضل ممارسات عملية لبناء نظام تقييم موثوق

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

الخلاصة الهندسية

التقييم الآلي ليس مرحلة تجميلية بعد بناء التطبيق، بل هو جزء أساسي من هندسة الجودة في منتجات الذكاء الاصطناعي. بدون Evaluation Pipeline ستبقى قراراتك مبنية على الانطباع، بينما المطلوب مخرجات قابلة للقياس والتحسين. وعندما تبني نظاماً يربط بين مقدمة في إطار عمل LangChain: ثورة ربط وتطوير تطبيقات الذكاء الاصطناعي، وما هي التضمينات (Embeddings)؟ تحويل النصوص البشرية إلى أرقام (Vectors)، ومقدمة في قواعد البيانات المتجهة (Vector Databases): الخيار الأمثل للذكاء الاصطناعي، فإن طبقة التقييم هي ما يثبت فعلياً أن النظام لا يجيب فقط، بل يجيب بشكل يمكن الوثوق به.