Phát triển dẫn dắt bởi đánh giá (Eval-Driven)

Bộ eval vừa là đặc tả, vừa là kiểm thử hồi quy, vừa là cổng chặn phát hành — dựng trong một tuần, tiết kiệm hàng tháng.

Bạn đang ở đâu với kỹ năng này?

Làm bài Đánh giá Kỹ năng PM cho Sản phẩm AI — Một lần làm chấm điểm cho tất cả kỹ năng trong nhóm AI, không chỉ kỹ năng này.

Làm bài đánh giá

Kỹ năng này cho bạn điều gì

Bắt đầu từ đây

Hiểu bộ eval đóng cả ba vai mà phần mềm thường tách riêng: định nghĩa "đúng", đích để tối ưu, và cổng chặn hồi quy. Nhận ra không có eval thì mỗi lần sửa prompt đều là canh bạc sửa ca này phá ca khác.

Khi đã làm được

Dựng được bộ eval đầu tiên trong một tuần với 100 ca thật và hai người gán đáp án độc lập, chọn đúng cách chấm theo thứ tự rẻ trước, kiểm chứng người chấm máy trước khi tin nó, nối eval thành cổng chặn phát hành tự động, và nuôi nó bằng quy tắc mỗi lỗi thật thành một ca mới — kèm phần ca giữ riêng chống việc tối ưu vừa bộ đề.

Roadmap — Cách học và đạt kỹ năng

Đã đọc 0/8 mục · còn khoảng 6 phút

Cách chúng tôi ghi nhận

Một mục được tính là đã đọc khi nó nằm giữa màn hình đủ lâu so với độ dài của nó (bảng và sơ đồ tính một nửa), bạn vẫn đang cuộn hoặc bấm phím, và bạn đã thấy tới cuối mục. Lướt nhanh hoặc để tab mở không được tính. Chúng tôi chỉ lưu thời gian đọc từng mục — không lưu gì khác.

Eval là gì — và vì sao nó thay thế cả đặc tả lẫn kiểm thử

Eval (đánh giá) là bộ ca có đáp án kèm cách chấm, chạy tự động mỗi lần bạn đổi bất cứ thứ gì — prompt, mô hình, cách lấy ngữ cảnh.

Trong phần mềm thường, ba thứ này tách biệt: đặc tả mô tả điều cần làm, code thực hiện, kiểm thử xác nhận. Với sản phẩm AI, bộ eval đóng cả ba vai — nó là định nghĩa chính xác nhất về "đúng", nó là thứ đội tối ưu hướng tới, và nó là thứ chặn phát hành khi có hồi quy.

Không có eval thì mọi thay đổi đều là canh bạc. Bạn sửa prompt cho ca khách hàng vừa phàn nàn, thấy ca đó chạy đúng, phát hành — và âm thầm phá ba ca khác mà không ai biết cho tới khi có người khác phàn nàn. Đội không có eval sẽ đi vòng tròn như vậy hàng tháng trời.

Bốn thành phần của một bộ eval

Thành phần	Là gì	Sai lầm thường gặp
Ca kiểm	Đầu vào thật, lấy ngẫu nhiên từ dữ liệu sản xuất	Tự nghĩ ra ca — luôn sạch hơn và dễ hơn thực tế
Đáp án hoặc tiêu chí	Đầu ra đúng, hoặc tiêu chí để chấm khi không có đáp án duy nhất	Đòi khớp từng chữ cho bài toán văn bản tự do
Cách chấm	Hàm chấm tự động, hoặc người chấm theo bảng tiêu chí	Chấm thủ công không có bảng tiêu chí → mỗi người chấm một kiểu
Ngưỡng	Điểm tối thiểu để được phát hành	Không có ngưỡng → eval thành báo cáo, không phải cổng chặn

Về cách chấm khi không có đáp án duy nhất — đây là phần khó nhất. Ba cách, theo thứ tự nên thử:

Chấm theo thuộc tính kiểm được bằng máy: có nhắc tới mã đơn hàng không, có dưới 50 từ không, có đúng định dạng không. Rẻ, chạy được mọi lần, và bắt được phần lớn hồi quy.
Người chấm theo bảng tiêu chí cố định: chậm và tốn, nhưng cần cho phần chất lượng mà máy không nhìn ra. Dùng trên mẫu nhỏ, định kỳ.
Dùng một mô hình để chấm mô hình: rẻ và nhanh, nhưng phải kiểm chứng người chấm máy này trước — cho nó chấm 50 ca đã có người chấm, xem có khớp không. Bỏ qua bước kiểm chứng đó là tự tạo ra một thước đo không ai biết có đúng hay không.

Dựng bộ eval đầu tiên — làm trong một tuần

Ngày 1 — Lấy 100 ca thật, ngẫu nhiên. Không chọn lọc. Nếu dữ liệu sản xuất chưa có, lấy từ quy trình thủ công đang chạy.
Ngày 2–3 — Gán đáp án, hai người độc lập. Đo mức đồng thuận. Nếu hai người chỉ khớp 70%, đó là trần của bài toán và cũng là thông tin quan trọng nhất bạn thu được trong tuần này.
Ngày 3 — Xử lý chỗ bất đồng. Hoặc làm rõ tiêu chí cho tới khi hai người khớp, hoặc đánh dấu ca đó là "vốn dĩ mơ hồ" và tách ra khỏi phần chấm điểm chính.
Ngày 4 — Viết hàm chấm. Bắt đầu từ thuộc tính máy kiểm được. Đừng cố hoàn hảo ngay.
Ngày 5 — Chạy lần đầu, ghi lại điểm cơ sở. Con số này thường thấp hơn kỳ vọng của cả đội, và đó chính là giá trị của nó.
Ngày 5 — Nối vào quy trình phát hành để nó chạy tự động, không phải chạy khi ai đó nhớ ra.

Về kích cỡ: 100 ca là điểm khởi đầu hợp lý. Dưới 50 thì nhiễu quá lớn — một ca đổi làm điểm nhảy 2%, và bạn sẽ đuổi theo tiếng ồn. Trên 500 thì chậm và đắt nếu có người chấm. Bắt đầu 100, thêm dần mỗi khi gặp lỗi thật.

Nuôi bộ eval — phần quyết định nó sống hay chết

Khi nào	Làm gì	Vì sao
Mỗi lỗi thật báo về	Thêm ca đó vào bộ eval	Quy tắc quan trọng nhất. Nó đảm bảo mỗi lỗi chỉ xảy ra một lần
Mỗi lần đổi prompt/mô hình	Chạy toàn bộ, so với lần trước	Bắt hồi quy trước khi người dùng bắt
Hằng tháng	Thêm 20 ca mới từ dữ liệu gần đây	Dữ liệu thật trôi theo thời gian; bộ eval cũ dần mất liên hệ
Hằng quý	Rà lại đáp án cũ	Định nghĩa "đúng" cũng thay đổi khi hiểu biết về bài toán tăng lên

Dấu hiệu bộ eval đã chết: điểm số không đổi qua nhiều lần phát hành liên tiếp, nhưng người dùng vẫn báo lỗi. Nghĩa là bộ eval không còn phản ánh thực tế — nó đang đo một bài toán mà sản phẩm không còn giải nữa.

Và một cạm bẫy nghiêm trọng: khi đội tối ưu quá lâu trên cùng một bộ eval, họ bắt đầu vô tình chỉnh cho vừa bộ đó thay vì cho bài toán thật. Cách chống: giữ một phần ca không bao giờ dùng để tối ưu, chỉ mở ra kiểm trước mỗi lần phát hành lớn.

Ví dụ — một vòng phát hành có eval

Tình huống: khách hàng phàn nàn hệ thống tóm tắt bỏ sót thông tin giá trong email báo giá.

Không có eval: sửa prompt thêm câu "luôn nêu giá nếu có" → thử lại ca đó → đúng → phát hành. Ba tuần sau phát hiện bản tóm tắt giờ dài gấp đôi và nhồi cả những con số không liên quan vào mọi email.
Có eval: thêm ca khách phàn nàn vào bộ eval (giờ 143 ca) → sửa prompt → chạy toàn bộ → ca mới đạt, nhưng 9 ca khác tụt vì tiêu chí "dưới 50 từ" bị vi phạm → sửa lại prompt thành "nêu giá nếu email là báo giá" → chạy lại → ca mới đạt và không ca nào tụt → phát hành.

Khác biệt: nửa ngày so với ba tuần — và khác biệt đó lặp lại ở mọi lần sửa, không chỉ lần này. Đó là lý do bộ eval là khoản đầu tư có lợi tức cao nhất trong một dự án AI.

Hiccups thường gặp và cách xử lý

Hiccup	Vì sao xảy ra	Xử lý
Không ai dựng eval vì "chưa có thời gian"	Nó không tạo ra tính năng nhìn thấy được	Một tuần dựng, tiết kiệm hàng tháng. Dựng trước khi bắt đầu tối ưu prompt.
Ca tự nghĩ ra, không lấy từ thực tế	Nhanh hơn	Ca tự nghĩ luôn dễ hơn; lấy ngẫu nhiên từ dữ liệu thật
Điểm tăng mà người dùng vẫn phàn nàn	Đội đã tối ưu vừa bộ eval	Giữ một phần ca không bao giờ dùng để tối ưu
Chấm thủ công, mỗi người một kiểu	Không có bảng tiêu chí	Viết bảng tiêu chí trước; đo mức đồng thuận giữa người chấm
Dùng mô hình chấm mà không kiểm chứng	Nhanh và rẻ	Cho nó chấm 50 ca đã có người chấm, so kết quả trước khi tin nó
Bộ eval không đổi suốt một năm	Coi là việc làm một lần	Thêm mỗi lỗi thật; bổ sung 20 ca mới mỗi tháng
Eval chạy khi ai đó nhớ ra	Chưa nối vào quy trình phát hành	Tự động hoá và đặt làm cổng chặn, không phải báo cáo

Vì sao vai trò của bạn cần cái này

Vai trò	Bạn dùng nó để
Engineer	Đây là lưới an toàn của bạn — không có nó thì mọi lần sửa prompt đều là canh bạc
QA	Bộ eval là hình thức kiểm thử hồi quy của thế giới xác suất; bạn sở hữu nó
Business Analyst	Bạn gán đáp án và viết bảng tiêu chí — cần hiểu nghiệp vụ, không cần hiểu mô hình
Product Owner	Bạn đặt ngưỡng chặn phát hành và bảo vệ quy tắc "mỗi lỗi thật thành một ca mới"
Team Lead	Bạn bảo vệ một tuần dựng eval trước áp lực làm tính năng

Definition of done

Bộ eval có ít nhất 100 ca lấy ngẫu nhiên từ dữ liệu thật.
Đáp án được gán bởi hai người độc lập, và mức đồng thuận đã được đo.
Có cách chấm tự động cho phần máy kiểm được, và bảng tiêu chí cho phần người chấm.
Nếu dùng mô hình để chấm, nó đã được kiểm chứng trên ca có người chấm.
Có ngưỡng chặn phát hành, và eval chạy tự động trong quy trình phát hành.
Mỗi lỗi thật báo về đều được thêm thành một ca mới.
Có phần ca giữ riêng, không bao giờ dùng để tối ưu.