Thiết lập mô hình cơ bản để đánh giá (phần 1)

Chạy các phần đánh giá chủ quan bằng một mô hình giám khảo cơ bản.

Maud Nalpas

Các phần đánh giá dựa trên quy tắc có thể kiểm tra câu trả lời mang tính xác định. Để đánh giá các phẩm chất chủ quan, hãy sử dụng kỹ thuật LLM-as-a-judge (LLM dưới dạng giám khảo).

Trong mô-đun này, bạn sẽ tìm hiểu cách tạo giám khảo đầu tiên bằng cách tự gắn nhãn dữ liệu hoặc gắn nhãn cùng nhóm và bằng cách sử dụng các chỉ số thống kê cơ bản.

Các bước tạo mô hình giám khảo đầu tiên

Chọn phương thức tuỳ chỉnh mô hình. Quyết định tinh chỉnh hoặc kỹ sư câu lệnh.
Chọn một mô hình. Đây có thể là mô hình nền tảng hoặc một LLM khác không có kiến thức chuyên môn về lĩnh vực.
Chọn phương thức tính điểm. Xác định xem giám khảo có nên sử dụng thang điểm nhị phân hay thang điểm số để tính điểm cho các giao diện do ThemeBuilder tạo hay không.
Định cấu hình giám khảo. Sửa đổi chế độ cài đặt của mô hình (chẳng hạn như nhiệt độ và đầu ra có cấu trúc) để phù hợp với các nhiệm vụ đánh giá.
Viết câu lệnh ban đầu. Thiết kế phiên bản đầu tiên của hướng dẫn hệ thống giám khảo và câu lệnh, bao gồm tiêu chí chấm điểm và ví dụ.
Tạo tập dữ liệu căn chỉnh. Tạo hoặc tập hợp một tập hợp đa dạng, chất lượng cao gồm các đầu ra tốt và xấu của ThemeBuilder, đồng thời gắn nhãn cho các đầu ra đó (chẳng hạn như một phương châm hay, phương châm độc hại và bảng màu không phù hợp với thương hiệu).
Căn chỉnh và kiểm thử giám khảo. Sử dụng tập dữ liệu căn chỉnh để tinh chỉnh câu lệnh giám khảo (hướng dẫn hệ thống và câu lệnh chính) một cách lặp đi lặp lại. Lặp lại quy trình này cho đến khi các phán quyết của giám khảo luôn khớp với phán quyết của con người. Cuối cùng, hãy kiểm thử giám khảo để xác nhận rằng giám khảo đáng tin cậy và có thể khái quát hoá phương pháp của mình cho các dữ liệu đầu vào mới.

Một mô hình đánh giá có LLM, chế độ cài đặt, câu lệnh hệ thống và câu lệnh chấm điểm.

Chọn phương thức tuỳ chỉnh

Hầu hết các mô hình nền tảng đều là mô hình đa năng. Mô hình giám khảo nên suy nghĩ như một chuyên gia trong lĩnh vực.

Các lựa chọn chính để tạo mô hình giám khảo bao gồm:

Kỹ sư câu lệnh một LLM.
Tinh chỉnh mô hình.
Sử dụng LLM đã tinh chỉnh được tối ưu hoá cho các phần đánh giá, chẳng hạn như JudgeLM. Lựa chọn này yêu cầu bạn tự lưu trữ trọng số mô hình tuỳ chỉnh hoặc sử dụng nhà cung cấp dịch vụ đám mây hỗ trợ lưu trữ mô hình nguồn mở.

Đối với các phần đánh giá ThemeBuilder trong khoá học này, chúng tôi đề xuất thiết kế câu lệnh. Thiết kế câu lệnh có thể mang lại kết quả tuyệt vời với ít nỗ lực phát triển hơn so với các lựa chọn thay thế.

Chọn một mô hình

Khi chọn mô hình cho giám khảo, hãy tìm kiếm khả năng suy luận mạnh mẽ. Vì bạn sẽ chạy các phần đánh giá trong quy trình CI/CD, nên tốc độ và chi phí cũng rất quan trọng.

Hãy thử nghiệm nhiều mô hình và kỹ thuật để tìm ra mô hình phù hợp nhất.

Bắt đầu với một mô hình lớn hơn, mạnh mẽ hơn để thiết lập một tiêu chuẩn cao, sau đó giảm dần xuống các mô hình nhỏ hơn. Hoặc ngược lại.
Kết hợp: Sử dụng mô hình nhanh chóng, tiết kiệm chi phí để kiểm tra yêu cầu kéo (PR) hằng ngày và mô hình mạnh mẽ hơn cho các bài kiểm thử bản phát hành cuối cùng. Hoặc kết hợp một LLM chung với một mô hình nhỏ, chuyên biệt cho các nhiệm vụ cụ thể như phát hiện nội dung độc hại để tăng tốc độ.

Khoá học này sử dụng Gemini 3 Flash làm mô hình giám khảo. Gemini 3 Flash cung cấp tốc độ và độ sâu suy luận cần thiết cho trường hợp sử dụng mẫu để đánh giá đầu ra của ThemeBuilder. Tuy nhiên, bạn có thể áp dụng các mẫu trong khoá học này cho bất kỳ mô hình nào bạn chọn.

Chọn phương thức tính điểm

Bạn có thể tính điểm cho các đầu ra chủ quan bằng nhãn nhị phân PASS và FAIL hoặc bằng điểm số, ví dụ: "Trên thang điểm từ 1 đến 5, phương châm này tuân thủ thương hiệu ở mức độ nào?".

Bạn nên sử dụng nhãn nhị phân.

Tiêu chí đánh giá	Phương thức đánh giá	Chỉ số
Phương châm phù hợp với thương hiệu, đối tượng và giọng điệu	Giám khảo LLM	Nhãn `PASS` hoặc `FAIL`
Bảng màu phù hợp với thương hiệu, đối tượng và giọng điệu	Giám khảo LLM	Nhãn `PASS` hoặc `FAIL`
Phương châm không độc hại	Giám khảo LLM	Nhãn `PASS` hoặc `FAIL`

Mặc dù điểm số (1-10) có thể trực quan, nghiên cứu cho thấy rằng LLM (và con người) có xu hướng tập trung điểm số ở giữa hoặc tăng điểm số để lịch sự. Các danh mục hoặc nhãn nhị phân như PASS và FAIL thường mang lại kết quả tốt hơn vì chúng buộc mô hình phải đưa ra quyết định rõ ràng. Đối với con người, đây được gọi là hiệu ứng người gán nhãn.

Định cấu hình giám khảo

Sử dụng các tham số và hướng dẫn để giúp giám khảo tạo ra các đầu ra có cấu trúc, nhất quán.

Đặt hướng dẫn hệ thống: Cung cấp cho giám khảo của bạn một cá tính chuyên gia nghiêm ngặt.
Set the temperature or thinking level: Giám khảo phải nhất quán. Nếu bạn đang sử dụng mô hình suy luận như Gemini Flash, mô hình này yêu cầu một chút ngẫu nhiên để chuyển đổi giữa các bước logic, hãy giữ nhiệt độ ở mức mặc định nhưng đặt thinking_level thành HIGH. Nếu bạn đang sử dụng một mô hình khác, hãy đặt nhiệt độ thành 0 hoặc gần 0. Trong mọi trường hợp, hãy sử dụng kỹ thuật chuỗi suy nghĩ để mô hình suy nghĩ trước khi quyết định đánh giá.
Cấu trúc đầu ra của người đánh giá: Một đối tượng JSON có thể dự đoán sẽ dễ dàng tái sử dụng hơn nhiều trong phần còn lại của cơ sở mã. Sử dụng lược đồ EvalResult yêu cầu label (PASS hoặc FAIL) và chuỗi rationale.

Trong ví dụ ThemeBuilder:

Cấu hình giám khảo

// 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 }] }]
});

responseJsonSchema

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"
}

Xem lại ví dụ về đoạn mã hoàn chỉnh .

Viết câu lệnh ban đầu

Bạn đã định cấu hình hướng dẫn hệ thống, giờ hãy thiết kế câu lệnh giám khảo chính. Ở giai đoạn này, bạn chỉ tạo phiên bản đầu tiên của câu lệnh này. Bạn sẽ tinh chỉnh câu lệnh này một cách lặp đi lặp lại khi căn chỉnh giám khảo ở bước tiếp theo.

Giám khảo chỉ hoạt động hiệu quả khi có hướng dẫn mà bạn cung cấp. Tránh hỏi câu hỏi chung chung, chẳng hạn như "Phương châm này có hay không?" trong đó hay không được xác định. Thay vào đó, hãy cung cấp cấu trúc để nhận được đầu ra rõ ràng, nhất quán.

Xác định tiêu chí chấm điểm: Cung cấp cho giám khảo hướng dẫn chấm điểm chi tiết. Điều gì mô tả giọng điệu dự kiến cho đầu ra lý tưởng? Bạn có thể yêu cầu LLM giúp bạn viết tiêu chí chấm điểm.
Sử dụng few-shot prompting: Bao gồm các ví dụ PASS và FAIL.
Sử dụng lời nhắc chuỗi suy nghĩ: Hướng dẫn mô hình viết ra lý do trước khi gán nhãn, vì điều này có thể cải thiện đáng kể độ chính xác. Ở chế độ tư duy HIGH, điều này không quan trọng bằng, nhưng vẫn là một phương pháp hay.

Viết ba câu lệnh chấm điểm riêng biệt cho ba tiêu chí cụ thể:

Phương châm phù hợp với thương hiệu.
Màu sắc phù hợp với thương hiệu.
Nội dung độc hại. Bạn có thể khởi động câu lệnh nội dung độc hại từ các thuộc tính nội dung độc hại được lấy từ cộng đồng.

Trong mỗi câu lệnh, hãy đưa vào tiêu chí chấm điểm rõ ràng và các ví dụ few-shot có lý do. Trong các ví dụ few-shot, hãy liệt kê lý do trước điểm số thực tế để áp dụng mẫu chuỗi suy nghĩ và cho giám khảo biết cách suy luận.

Bạn có thể tìm thấy các câu lệnh đầy đủ trong kho lưu trữ mã. Ví dụ: câu lệnh giám khảo phù hợp với thương hiệu phương châm có dạng như sau:

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 (e.g. 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}"`;
}

Căn chỉnh và kiểm thử

Đọc bài viết thiết lập giám khảo cơ bản, phần 2 để hoàn tất việc tạo giám khảo bằng cách căn chỉnh và kiểm thử.

Đánh giá dựa trên quy tắc

Tiếp

Phần 2