إعداد نموذج أساسي للحكم (الجزء 1)

الحصول على تقييمات ذاتية باستخدام نموذج تقييم أساسي:

Maud Nalpas

يمكن أن تتحقّق التقييمات المستندة إلى القواعد من الإجابات المحدّدة. لتقييم الصفات الذاتية، استخدِم تقنية LLM-as-a-judge.

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

إنشاء نموذج تقييمك الأول

1. اختَر طريقة تخصيص النموذج. يمكنك إجراء تعديلات دقيقة أو هندسة الطلبات.
2. اختَر نموذجًا. ويمكن أن يكون هذا النموذج نموذجًا أساسيًا أو نموذجًا لغويًا كبيرًا آخر بدون خبرة في مجال معيّن.
3. اختَر طريقة تسجيل النقاط. تحديد ما إذا كان على القاضي استخدام مقياس ثنائي أو رقمي لتسجيل نتائج المواضيع التي تم إنشاؤها باستخدام ThemeBuilder.
4. ضبط القاضي عدِّل إعدادات النموذج (مثل درجة العشوائية والنتائج المنظَّمة) لجعله مناسبًا لمهام التقييم.
5. اكتب الطلب الأوّلي. صمِّم الإصدار الأول من تعليمات نظام التقييم والطلب، بما في ذلك معايير التقييم والأمثلة.
6. أنشئ مجموعة بيانات محاذاة. أنشئ مجموعة متنوعة وعالية الجودة من النتائج الجيدة والسيئة التي ينتجها ThemeBuilder، وصنِّفها وفقًا لذلك، مثل شعار جيد وشعار مسيء ولوحة ألوان لا تتوافق مع هوية العلامة التجارية.
7. مواءمة أداة التقييم واختبارها استخدِم مجموعة بيانات المطابقة لتحسين موجه التقييم بشكل متكرر (تعليمات النظام والموجه الرئيسي). كرِّر هذه العملية إلى أن تتطابق أحكام القاضي بشكل متسق مع أحكام المراجعين. أخيرًا، اختبِر أداة التقييم للتأكّد من موثوقيتها وقدرتها على تعميم أسلوبها على المدخلات الجديدة.

اختيار طريقة التخصيص

معظم النماذج الأساسية هي نماذج عامة. يعمل نموذج التقييم كـ أخصائي في مجال معيّن.

تشمل الخيارات الرئيسية لإنشاء نموذج تقييم ما يلي:

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

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

اختيار نموذج

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

جرِّب نماذج مختلفة وأساليب متنوعة للعثور على النموذج الأنسب.

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

تستخدم هذه الدورة التدريبية Gemini 3 Flash كنموذج تقييم. يوفّر Gemini 3 Flash السرعة والعمق المطلوبَين في الاستدلال لحالة الاستخدام النموذجية الخاصة بتقييم نتائج ThemeBuilder. ومع ذلك، يمكن تطبيق الأنماط الواردة في هذه الدورة التدريبية على أي نموذج تختاره.

اختيار طريقة تسجيل النقاط

يمكنك تقييم النتائج الذاتية باستخدام التصنيفين الثنائيين PASS وFAIL، أو باستخدام تقييم رقمي، مثلاً: "على مقياس من 1 إلى 5، ما مدى التزام هذا الشعار بالعلامة التجارية؟"

ننصح باستخدام تصنيفات ثنائية.

مع أنّ النتيجة الرقمية قد تبدو بديهية، تُظهر الأبحاث أنّ النماذج اللغوية الكبيرة (والبشر) تميل إلى تجميع نتائجها في المنتصف أو تضخيمها بدافع اللطف. غالبًا ما تؤدي الفئات أو التصنيفات الثنائية، مثل PASS وFAIL، إلى نتائج أفضل لأنّها تجبر النموذج على اتّخاذ قرار واضح. ويُعرف هذا باسم تأثير المقيم.

ضبط القاضي

استخدِم المَعلمات والتعليمات لمساعدة الحكَم في إنشاء نتائج متّسقة ومنظَّمة.

• ضبط تعليمات النظام: امنح القاضي شخصية خبير صارمة.
• ضبط درجة الحرارة أو مستوى التفكير: يجب أن يكون الحكم متسقًا. إذا كنت تستخدم نموذجًا للاستدلال، مثل Gemini Flash، يتطلّب بعض العشوائية للتنقّل بين الخطوات المنطقية، اترك درجة العشوائية على الإعداد التلقائي، ولكن اضبط thinking_level على HIGH. إذا كنت تستخدم نموذجًا آخر، اضبط قيمة درجة الحرارة على 0 أو قيمة قريبة من 0. في أي حال، استخدِم أسلوب سلسلة الأفكار، لكي يفكر النموذج قبل اتخاذ قرار بشأن الحكم.
• تنظيم نتائج التقييم: من الأسهل بكثير إعادة استخدام كائن JSON يمكن توقّعه في بقية قاعدة الرموز البرمجية. استخدِم مخطط EvalResult يتطلّب label (PASS أو FAIL) وسلسلة rationale.

في مثال ThemeBuilder:

// LLM judge config
const response = await client.models.generateContent({
  model: modelVersion,
  config: {
      systemInstruction: "You are a senior brand strategist, brand identity
      specialist, and expert color psychologist. You also act as a strict
      content moderator for a brand safety tool. Be rigorous regarding brand
      alignment. Always formulate your rationale before assigning the final
      PASS or FAIL label to ensure thorough consideration of the criteria.",
      temperature: 0,
      thinkingConfig: {
          thinkingLevel: ThinkingLevel.HIGH,
      },
      responseJsonSchema: schemaConfig.responseSchema
  },
  contents: [{ role: "user", parts: [{ text: prompt }] }]
});

const schemaConfig = {
  responseMimeType: "application/json",
  responseSchema: {
      type: "OBJECT",
      properties: {
          label: { type: "STRING", enum: [EvalLabel.PASS, EvalLabel.FAIL] },
          rationale: { type: "STRING" }
      },
      required: ["label", "rationale"],
      propertyOrdering: ["rationale", "label"]
  }
};

// Classification label for an evaluation (PASS/FAIL is the judge's verdict)
export enum EvalLabel {
    PASS = "PASS",
    FAIL = "FAIL"
}

راجِع مثال الرمز الكامل.

كتابة الطلب الأوّلي

لقد سبق لك إعداد تعليمات النظام، والآن صمِّم طلب التقييم الرئيسي. في هذه المرحلة، أنشئ الإصدار الأول من هذا الطلب. يمكنك تحسينها بشكل متكرّر عند مواءمة الحكم في الخطوة التالية.

لا يمكن للحكم أن يكون فعّالاً إلا إذا كانت التعليمات المقدَّمة إليه واضحة. تجنَّب طرح سؤال عام، مثل "هل هذا الشعار جيد؟" حيث أنّ كلمة جيد غير محددة. بدلاً من ذلك، قدِّم بنية للحصول على نواتج واضحة ومتّسقة.

• تحديد نموذج التقييم: قدِّم للمقيّم إرشادات تفصيلية حول التقييم. ما الذي يصف النبرة المتوقّعة للناتج المثالي؟ يمكن أن يساعدك نموذج لغوي كبير في كتابة قواعد التقييم.
• استخدام التلقين ببضعة أمثلة: أدرِج أمثلة PASS وFAIL.
• استخدام مطالبات سلسلة الأفكار: اطلب من النموذج كتابة الأساس المنطقي قبل تعيين تصنيف، لأنّ ذلك يمكن أن يحسّن الدقة بشكل كبير. في HIGH وضع التفكير، لا تكون هذه الخطوة ضرورية، ولكنّها تبقى ممارسة جيدة.

اكتب ثلاثة طلبات منفصلة للتقييم وفقًا للمعايير المحدّدة الثلاثة:

• ملاءمة الشعار للعلامة التجارية
• ملاءمة العلامة التجارية للألوان
• مستوى السُمية يمكن بدء تشغيل طلب اللغة غير اللائقة من خلال سمات اللغة غير اللائقة المستندة إلى مصادر جماعية.

في كل طلب، أدرِج معايير تقييم واضحة وأمثلة قليلة اللقطات مع توضيح الأساس المنطقي. في الأمثلة القليلة، أدرِج الأساس المنطقي قبل النتيجة الفعلية لتطبيق نمط سلسلة الأفكار وتوضيح طريقة تفكير الحكم.

يمكنك العثور على الطلبات الكاملة في مستودع الرموز. على سبيل المثال، يبدو طلب التقييم الخاص بمطابقة الشعار مع العلامة التجارية على النحو التالي:

export function getMottoBrandFitJudgePrompt(companyName: string, description: string, audience: string, tone: string | string[], motto: string) {
  return `Evaluate the following generated motto for a company.

${companyName ? `Company name: ${companyName}\n` : ""}${description ? `Description: ${description}\n` : ""}${audience ? `Target audience: ${audience}\n` : ""}${Array.isArray(tone) ? (tone.length > 0 ? `Desired tone: ${tone.join(", ")}\n` : "") : (tone ? `Desired tone: ${tone}\n` : "")}

Generated motto: "${motto}"

Does this motto effectively match the company description, appeal to the
target audience, and embody the desired tone?

CRITICAL INSTRUCTIONS:
1. **Brand fit vs. toxicity**: You are evaluating ONLY brand fit. Another system
  will evaluate toxicity separately. DO NOT evaluate toxicity, ethics, profanity,
  or offensiveness. A motto can be a GREAT brand fit for an edgy or aggressive
  brand. If the brand requests an "offensive" or "aggressive" tone, you MUST
  pass it for brand fit, regardless of how inappropriate it is.
1. **Primary tone and literal relevance**: Do not over-penalize a motto if it
  perfectly captures the primary literal vibe just because it might loosely
  conflict with a secondary adjective.
1. **Core promises and professionalism**: For B2B/Enterprise, the motto MUST NOT
  violate core promises.
1. **Resilience to input messiness**: The Company Name, Description, Target
  Audience, or Tone may contain typos, slang, or mixed-language. You must
  decipher the *intended* meaning and judge the output against that intent,
  rather than penalizing the output for not matching the literal typo or slang.

Criteria:
1. **Relevance**: Does the motto relate to the company's core business and
  value proposition? Does it uphold core brand promises?
1. **Audience appeal**: Is the language engaging for the target audience without
  alienating them (such as through forced or inappropriate slang)?
1. **Tone consistency**: Does the motto reflect the general desired emotional
  tone perfectly, without imposing moral judgments?

Examples:

Input:
Company Name: "Summit Bank"
Description: "Secure, reliable banking for families"
Tone: "Trustworthy, serious"
Motto: "YOLO with your money!"
Result:
  "rationale": "The motto 'YOLO with your money!' is too casual and risky, contradicting the 'trustworthy, serious' tone required for a family bank.",
  "label": "${EvalLabel.FAIL}"
}

Input:
Company Name: "GymTiger"
Description: "Gym for heavy lifters."
Tone: "Aggressive, high-performance, technical"
Motto: "Lift big or be a loser."
Result:
  "rationale": "The motto matches the required 'aggressive' tone and appeals directly to the hardcore bodybuilding audience. While calling the audience a 'loser' is toxic and insulting, it successfully fulfills the brand fit and tone criteria requested.",
  "label": "${EvalLabel.PASS}"
}

Return a JSON object with:
- "rationale": A brief explanation of why it passes or fails based on the description, audience, and tone.
- "label": "${EvalLabel.PASS}" or "${EvalLabel.FAIL}"`;
}

المواءمة والاختبار

اطّلِع على إعداد مقيّم أساسي، الجزء 2 للانتهاء من إنشاء المقيّم باستخدام المواءمة والاختبار.