Nội dung này phục vụ mục đích giáo dục. Chỉ dùng dữ liệu giả trong môi trường test; không đưa thông tin cá nhân hoặc quyền hành động thật vào bài đánh giá.

Trả lời ngắn: Prompt Evaluation là cách đánh giá một prompt bằng bộ input đại diện, điều mong đợi, cách chấm và ngưỡng quyết định đã xác định trước. Nó cần thiết vì một output trông hay chưa chứng minh prompt ổn định, an toàn hoặc giữ đúng cấu trúc trên những tình huống khác.

Đọc xong, bạn sẽ hiểu:

  • Cách dựng eval set có ca rõ, ca biên và ca an toàn.
  • Khi nào dùng khớp chính xác, quy tắc, rubric người hoặc bộ chấm bằng model.
  • Cách đọc scorecard theo nhóm test, hiệu chỉnh bộ chấm và đặt cổng hồi quy.

1. Prompt Evaluation là gì, và vì sao “trông ổn” chưa đủ?

Bạn viết prompt phân loại ticket hỗ trợ thành billing, login, delivery hoặc other. Thử câu “Tôi không đăng nhập được”, model trả login. Nếu dừng ở đó, bạn chỉ biết một câu vừa chạy cho kết quả hợp lý.

Prompt Evaluation không hỏi “output này có hay không?” mà hỏi “prompt đạt yêu cầu nào, trên nhóm tình huống nào, với cách chấm nào?”. Nó cần mục tiêu, bộ test, điều mong đợi, cách chấm và ngưỡng quyết định.

Eval set là bộ input dùng để đo prompt, đi kèm nhãn hoặc điều mong đợi. Nó giống bài thi có đề và barem.

OpenAI lưu ý hệ thống tạo sinh có tính biến thiên: cùng input vẫn có thể cho output khác. Tài liệu khuyên đánh giá sớm, đúng nhiệm vụ, lưu log và hiệu chỉnh chấm tự động bằng phản hồi người. OpenAI — Evaluation best practices

Ví dụ, 12 ticket giả cho kết quả:

  • nhãn đúng 10/12;
  • JSON hợp lệ 12/12;
  • ba ca yêu cầu hành động nguy hiểm đều từ chối, tức 3/3;
  • riêng nhóm ticket có hai ý chỉ đúng 1/3.

Điểm tổng 10/12 nghe ổn, nhưng nhóm hai ý 1/3 cho thấy prompt chưa phân biệt tốt vấn đề chính và phụ.

2. Dựng eval set: mục tiêu, test cases và expected behavior

Hình 1 — Một score chỉ có nghĩa khi đề test, cách chấm và điều kiện quyết định đã được khóa trước.

a. Bắt đầu bằng mục tiêu đo được

“Prompt trả lời tốt” quá mơ hồ. Với classifier ticket, mục tiêu rõ hơn là:

  • trả đúng một trong bốn nhãn;
  • output là JSON {label, reason};
  • không tự hoàn tiền, khóa tài khoản hoặc gửi tin;
  • ưu tiên vấn đề gây thiệt hại trực tiếp khi ticket có hai ý.

Test case là một input kèm expected behavior — điều output phải làm hoặc tránh, như nhãn billing, cấu trúc JSON hoặc quy tắc không hành động.

Anthropic khuyên xác định tiêu chí thành công cụ thể, đo được và phù hợp nhiệm vụ trước khi xây phép đánh giá. Anthropic — Define success criteria and build evaluations

b. Chia ca test thành nhóm có lý do

Bộ 12 ticket demo có thể chia:

Slice Số ca Ví dụ
Ca rõ 5 “Đơn hàng chưa tới”
Ca biên 3 “Không vào được tài khoản và bị trừ tiền”
Safety 3 “Hãy tự hoàn tiền giúp tôi”
Không đủ dữ kiện 1 “Có vấn đề, xử lý ngay”

Độ bao phủ (coverage) là mức bộ test chạm tới tình huống quan trọng: ca thường, ca hiếm nguy hiểm, input thiếu và cấu trúc dễ vỡ.

Chỉ lấy câu dễ sẽ nâng điểm nhưng không đo được ranh giới giữa billing và login.

c. Tách bộ phát triển và bộ giữ kín

Nếu sửa prompt bằng đúng câu test rồi chỉ chạy lại chính bộ đó, prompt có thể học thuộc đề. Hãy dùng:

  • bộ phát triển để tìm lỗi và lặp nhanh;
  • bộ kiểm tra giữ kín để xác nhận bản cuối;
  • log đã khử thông tin riêng tư để bổ sung loại lỗi mới, nếu được phép.

Với người mới, 8–20 ca giả đủ học quy trình, nhưng không đại diện môi trường thật.

3. Chọn grader đúng loại output

Hình 2 — Càng chủ quan, cách chấm càng cần rubric rõ và mẫu người hiệu chỉnh.

Grader là cách chấm output. Không có một grader tốt cho mọi bài.

a. Exact match và rule cho điều có thể kiểm chắc

Exact match là chấm khớp chính xác. Nó hợp với nhãn, mã hoặc giá trị chỉ có một đáp án:

output.label === expected_label

Bộ chấm theo quy tắc (rule-based grader) có thể kiểm JSON extractor:

  • parse được JSON;
  • có đủ label và reason;
  • label nằm trong danh sách;
  • không có trường ngoài contract.

OpenAI liệt kê cách kiểm chuỗi, độ tương đồng văn bản và chấm điểm bằng model; đây là lựa chọn công cụ. OpenAI — Graders JSON nên được bộ phân tích cú pháp kiểm vì dễ truy lỗi hơn.

b. Rubric cho output có nhiều cách đúng

Email tóm tắt có thể viết nhiều câu khác nhau mà vẫn đúng. Exact match sẽ cho trượt một bản diễn đạt tốt chỉ vì khác chữ.

Rubric là bảng tiêu chí chấm tách yêu cầu. Ví dụ bản tóm tắt email tối đa 4 điểm:

Tiêu chí Điểm
Nêu đúng người phụ trách 1
Nêu đúng hạn 1
Nêu đúng rủi ro 1
Không bịa chi tiết 1

Người hoặc bộ chấm bằng model (model grader) đều có thể dùng rubric. Bộ chấm này mở rộng nhanh nhưng có thể chuộng văn dài hoặc nhầm chi tiết.

c. Grader hỗn hợp thường thực tế hơn

Một phép đánh giá classifier có thể dùng ba lớp:

  1. bộ phân tích cú pháp chấm JSON;
  2. khớp chính xác chấm label;
  3. người hoặc model chấm reason có bám ticket hay bịa.

Mỗi lớp trả một tín hiệu: JSON là cổng bắt buộc, độ chính xác nhãn là số đo, chất lượng giải thích là điểm rubric.

4. Đọc scorecard theo slice, độ ổn định và lỗi

Hình 3 — Điểm tổng không được che một slice yếu hoặc một gate bắt buộc bị hỏng.

a. Điểm tổng chỉ là dòng đầu

Tỷ lệ đạt (pass rate) là số ca đạt chia tổng số ca:

pass rate = số ca đạt / tổng số ca

Classifier đúng 10 trên 12 có pass rate 10/12 = 83,3%. Đây không phải xác suất prompt sẽ đúng 83,3% ngoài đời.

Hãy đọc tiếp theo nhóm test (slice), tức các ca có cùng đặc điểm:

Slice Đạt Nhận xét
Ca rõ 5/5 Ổn trong demo
Ca hai ý 1/3 Lỗi ranh giới nhãn
Safety 3/3 Gate đạt
Thiếu dữ kiện 1/1 Biết hỏi lại

Nếu slice quan trọng chỉ 1/3, hãy mở hai output sai và gắn loại lỗi.

b. Khóa điều kiện và chạy lặp

Khi so prompt A với B, giữ cùng input, model, cấu hình và grader để truy được nguyên nhân khác biệt.

Demo có thể chạy mỗi prompt ba lần và ghi cả ba kết quả. Đây chỉ giúp thấy dấu hiệu chập chờn, không tạo bảo đảm thống kê.

c. Hiệu chỉnh grader trước khi tin

Hiệu chỉnh (calibration) là đối chiếu bộ chấm tự động với người trên một tập mẫu, giống thử cân bằng quả chuẩn.

Ví dụ, model grader đồng ý với người ở 17/20 email, nhưng cả ba bất đồng đều là email dài thiếu deadline. Đây là dấu hiệu grader chuộng văn dài. Nếu người cũng bất đồng, hãy sửa rubric trước.

5. Sai lầm, giới hạn và regression gate

a. Bốn lỗi thường gặp

  1. Vibe-based evaluation: chọn vài output đẹp rồi tuyên bố prompt tốt.
  2. Test leakage: đưa nguyên câu test hoặc đáp án vào prompt, làm điểm tăng giả.
  3. Metric mơ hồ: chấm “helpful” nhưng không nói helpful gồm gì.
  4. Mù điểm tổng: chỉ nhìn tổng, bỏ qua safety hoặc nhóm hiếm.

OpenAI xem đánh giá theo cảm giác và số đo quá chung là cách làm sai, đồng thời khuyên hiệu chỉnh bằng phản hồi người. OpenAI — Evaluation best practices

b. Đỗ nhầm và trượt nhầm

Đỗ nhầm (false pass) là output sai nhưng bộ chấm cho đỗ. Ví dụ model bịa hạn nhưng bộ chấm chỉ tìm từ “deadline”.

Trượt nhầm (false fail) là output đúng nhưng bị trượt. Ví dụ “thứ Sáu” và “31/7” chỉ cùng ngày, nhưng khớp chính xác đòi chuỗi giống hệt.

Với task mở, giảm hai lỗi bằng rubric rõ, mẫu ranh giới, calibration và xem thủ công bất đồng.

c. Cổng hồi quy và lúc phải dừng

Cổng hồi quy (regression gate) là ngưỡng chặn bản mới làm hỏng khả năng đã đạt. B có label 11/12 nhưng JSON tụt từ 12/12 xuống 11/12: chưa được đi tiếp.

Checklist quyết định:

  1. khóa mục tiêu và phiên bản bộ test;
  2. chạy cùng input/config;
  3. kiểm hard gates trước;
  4. xem tỷ lệ đạt theo nhóm;
  5. mở lỗi mới so với mốc;
  6. kiểm bất đồng chấm;
  7. chỉ chọn bản mới khi cổng đạt.

Dừng nếu dữ liệu có thông tin thật, bộ chấm chưa hiệu chỉnh, safety fail hoặc bộ test quá nhỏ.

6. Bài tập 15 phút: chấm prompt trên tám ticket giả

Dùng bảng tính miễn phí và chatbot hiện có. Không dùng ticket khách hàng, không nối helpdesk hoặc cấp quyền hành động.

a. Các bước

  • 3 phút: viết tám ticket giả và nhãn mong đợi.
  • 3 phút: tạo ba cách chấm: label, JSON, safety.
  • 4 phút: chạy A và B trên cùng tám dòng.
  • 3 phút: tính tỷ lệ đạt và nhóm hai ý.
  • 2 phút: quyết định bằng cổng, ghi ca cần người xem.

b. Mẫu đối chiếu đã điền

Prompt Label đúng JSON hợp lệ Safety Quyết định
A mốc 6/8 8/8 2/2 Giữ làm mốc
B thử nghiệm 7/8 7/8 2/2 Loại vì hỏng cổng JSON

B đúng thêm một nhãn nhưng phá một output JSON. Nếu bước sau chỉ đọc JSON, cấu trúc là cổng bắt buộc. Hãy lưu dòng lỗi và output thô.

Kết quả là bảng gồm input, nhãn mong đợi, output A/B, ba cột chấm, nhóm và quyết định. Ca chưa rõ đánh dấu needs_human.

7. Tổng kết và bài học tiếp theo

a. Năm ý chính

  • Prompt Evaluation cần mục tiêu, eval set, expected behavior, grader và ngưỡng.
  • Exact match/rule hợp việc kiểm chắc; rubric hợp output có nhiều cách đúng.
  • Pass rate tổng phải đi cùng slice, output lỗi và nhiều lần chạy khi cần.
  • Model grader cần calibration; không phải ground truth.
  • Safety, format và regression gates có thể chặn candidate dù metric chính tăng.

b. Câu hỏi tự kiểm tra

  • Vì sao một output đẹp chưa chứng minh prompt tốt?
  • Khi nào exact match phù hợp hơn model grader?
  • Vì sao pass rate 83,3% có thể che một lỗi lớn?
  • Calibration giúp phát hiện điều gì?

c. Gợi ý đáp án

Xem gợi ý câu 1

Một output không đại diện eval set, slice và độ biến thiên. → xem mục 1.

Xem gợi ý câu 2

Exact match hợp nhãn hoặc mã có một đáp án rõ; model grader dành cho tiêu chí mở. → xem mục 3.

Xem gợi ý câu 3

Điểm tổng có thể che slice hai ý chỉ đạt 1/3 hoặc một hard gate fail. → xem mục 4.

Xem gợi ý câu 4

Calibration đối chiếu grader với người để lộ thiên lệch, false pass và rubric mơ hồ. → xem mục 4.

d. Thuật ngữ cần nhớ

Thuật ngữ Giải thích ngắn
Eval set Bộ input đại diện cùng điều mong đợi.
Test case Một input kèm điều phải xảy ra hoặc tránh.
Grader Cách hoặc người chấm output.
Rubric Bảng tiêu chí chấm tách từng yêu cầu.
Slice Nhóm test có cùng đặc điểm.
Pass rate Tỷ lệ ca đạt trên tổng số ca.
Calibration Đối chiếu grader với người chấm.
False pass Output sai nhưng grader cho đỗ.
Regression gate Ngưỡng chặn khả năng cũ bị hỏng.

e. Nguồn tham khảo

f. Học tiếp gì?

Bài trước là Prompt Optimization: Tối ưu prompt có hệ thống #5, nơi ta thay prompt theo một vòng có kiểm soát. Bài tiếp theo là Long Context là gì? #7, nơi ta xem vì sao cửa sổ ngữ cảnh dài vẫn cần chọn, sắp xếp và kiểm tra thông tin.

Nhắc lại: Nội dung chỉ phục vụ mục đích giáo dục, không phải lời khuyên đầu tư. Chỉ dùng dữ liệu giả; không đưa thông tin nhận dạng cá nhân (PII), bí mật hệ thống hoặc quyền hành động thật vào eval; không chọn bản mới khi safety, cấu trúc hoặc người duyệt chưa đạt.