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

Nhận các bản đánh giá chủ quan đang chạy bằng một mô hình cơ bản để đánh giá.

Maud Nalpas

Các quy trình đánh giá dựa trên quy tắc có thể kiểm tra câu trả lời 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 đóng vai trò là người đánh giá).

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

Xây dựng mô hình đánh giá đầu tiên

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

Chọn một 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ột mô hình đánh giá đóng vai trò là một chuyên gia về lĩnh vực.

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

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

Đối với các hoạt động đánh giá ThemeBuilder trong khoá học này, bạn nên sử dụng thiết kế câu lệnh. Thiết kế câu lệnh có thể mang lại kết quả xuất sắc mà không tốn nhiều công sức phát triển như các phương á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 những mô hình có khả năng suy luận mạnh mẽ. Vì bạn chạy các quy trình đánh giá trong quy trình CI/CD, nên tốc độ và chi phí cũng là những yếu 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 bằng 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 quy mô xuống các mô hình nhỏ hơn. Ngoài ra, hãy bắt đầu với các mô hình nhỏ hơn và mở rộng quy mô.
• Kết hợp: Sử dụng một mô hình nhanh chóng và tiết kiệm chi phí cho các hoạt động kiểm tra yêu cầu kéo hằng ngày, đồng thời sử dụng một mô hình mạnh mẽ hơn cho các kiểm thử 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 tác 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 đánh giá. Gemini 3 Flash mang đến tốc độ và khả năng suy luận chuyên sâu cần thiết cho trường hợp sử dụng ví dụ về việc đánh giá kết quả đầ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 một phương pháp tính điểm

Bạn có thể chấm điểm các kết quả chủ quan bằng nhãn nhị phân PASS và FAIL hoặc bằng điểm số, ví dụ: "Theo thang điểm từ 1 đến 5, khẩu hiệu này phù hợp với thương hiệu đến mức nào?"

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

Mặc dù điểm số bằng số có vẻ trực quan, nhưng nghiên cứu cho thấy các LLM (và con người) có xu hướng tập trung điểm số ở mức trung bình hoặc tăng điểm số để tỏ ra 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, hiện tượng nà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 người đánh giá tạo ra kết quả nhất quán và có cấu trúc.

• Đặt hướng dẫn cho hệ thống: Đưa ra cho giám khảo một tính cách chuyên gia nghiêm khắc.
• Đặt nhiệt độ hoặc mức độ suy nghĩ: Giám khảo phải nhất quán. Nếu bạn sử dụng một mô hình suy luận như Gemini Flash, mô hình này cần 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 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 suy luận từng bước để mô hình suy nghĩ trước khi quyết định đưa ra phán đoán.
• Cấu trúc đầu ra của chương trình đánh giá: Đối tượng JSON có thể dự đoán sẽ dễ dàng tái sử dụng hơn trong phần còn lại của cơ sở mã. Sử dụng giản đồ EvalResult yêu cầu phải có label (PASS hoặc FAIL) và chuỗi rationale.

Trong ví dụ về 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"
}

Xem ví dụ đầy đủ về mã.

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

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

Thẩm phán chỉ có hiệu quả khi có hướng dẫn. Tránh đặt câu hỏi chung chung, chẳng hạn như "Khẩu hiệu này có hay không?" trong đó hay là một khái niệm không xác định. Thay vào đó, hãy cung cấp cấu trúc để nhận được kết quả rõ ràng và nhất quán.

• Xác định rubric: Đưa ra hướng dẫn chấm điểm chi tiết cho giám khảo. Câu nào mô tả giọng điệu dự kiến cho một kết quả đầu ra lý tưởng? Mô hình ngôn ngữ lớn (LLM) có thể giúp bạn viết tiêu chí chấm điểm.
• Sử dụng đặt câu lệnh dựa trên một vài ví dụ: Thêm ví dụ về PASS và FAIL.
• Sử dụng cách tạo câu lệnh theo chuỗi suy luận: Hướng dẫn mô hình viết ra lý do trước khi chỉ định nhãn, vì điều này có thể cải thiện đáng kể độ chính xác. Trong 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 3 câu lệnh chấm điểm riêng biệt cho 3 tiêu chí cụ thể:

• Mức độ phù hợp của thương hiệu với phương châm.
• Màu sắc phù hợp với thương hiệu.
• Hành vi bôi xấu. Bạn có thể khởi động nhanh câu lệnh về nội dung độc hại từ các thuộc tính độc hại do cộng đồng đóng góp.

Trong mỗi câu lệnh, hãy thêm một tiêu chí chấm điểm rõ ràng và ví dụ có vài câu kèm theo lý do. Trong các ví dụ ít lần, 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à minh hoạ cách giám khảo suy luận.

Bạn có thể tìm thấy toàn bộ câu lệnh trong kho lưu trữ mã. Ví dụ: câu lệnh đánh giá mức độ phù hợp của thương hiệu với phương châm sẽ 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 (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}"`;
}

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

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