Đánh giá và cải thiện một ứng dụng AI, giải thích qua một kỳ thi

Hãy nhớ lại một kỳ thi tốt. Đề thi giống với công việc mà nó chuẩn bị cho bạn. Học sinh giỏi nhất được điểm cao nhất, nhưng không ai đúng hết. Cùng một bài, chấm hai lần, vẫn ra cùng một điểm. Còn những bạn thuộc lòng đề cũ thì làm bài thi thử rất tốt, rồi vấp ngã vào ngày thi thật.

Đánh giá một ứng dụng AI cũng y như vậy, chỉ khác là bạn phải tự soạn đề, tự chấm, rồi ôn theo đề mà không tự lừa mình. Anthropic đã bổ sung hướng dẫn cho cả hai bước vào skill claude-api, đi kèm Claude Code. Bài viết này mở rộng phiếu số 3 trong loạt Claude · Hướng dẫn của tôi trên consonance.fyi, kèm thêm chi tiết từ bài gốc trên claude.dev.

Trong một câu: build-eval dựng một bài đánh giá ngay trong code của bạn, khi bạn đồng ý, và hillclimb cải thiện ứng dụng theo bài đó, mỗi lần một thay đổi, giữ riêng một phần ví dụ để phát hiện overfitting.

Thế nào là một đề thi tốt

Bài viết trên claude.dev nêu bốn đặc điểm chung của một eval được thiết kế tốt. Mỗi đặc điểm đều gợi lại một kỷ niệm thời đi học:

• Tác vụ giống production. Một đề thi giống đời thật: chọn những tác vụ bạn thực sự quan tâm, chứ không phải những tác vụ dễ sinh ra hay dễ chấm.
• Model mạnh hơn thì điểm cao hơn. Học sinh giỏi nhất có điểm cao nhất. Nếu một model mạnh hơn, hoặc mức effort cao hơn, mà không làm tốt hơn, hãy nghi ngờ tác vụ mơ hồ hoặc người chấm bị lệch.
• Vẫn còn khoảng trống ở đỉnh. Không ai được 100 %. Model mạnh nhất ở mức effort cao nhất phải còn cách xa điểm tuyệt đối, nếu không bạn sẽ không biết một thay đổi có giúp ích hay không. Nhưng khoảng cách đó không được đến từ những tác vụ bất khả thi: một tác vụ lần nào chạy cũng sai là dấu hiệu rõ ràng.
• Ít dao động giữa các lần chạy. Cùng một bài, cùng một điểm. Nhiễu đến từ tác vụ mơ hồ, từ người chấm đổi ý trên cùng một kết quả, hoặc từ dấu vết của lần chạy trước (một file, một lịch sử git) vô tình mách đáp án cho agent.

Một cái bẫy tinh vi hơn là lấy mẫu đối nghịch (adversarial sampling): thầy giáo chỉ ra câu bẫy cho đúng một học sinh. Nếu chỉ giữ những trường hợp mà model hôm nay làm sai, eval sẽ đo điểm yếu của riêng model đó, chứ không đo điều thực sự khó với ứng dụng của bạn. Hãy chọn ca khó vì một con người đánh giá là khó, và phải nói được tại sao. Những lỗi thật từ bug report và ticket rất đáng giá, nhưng traffic người dùng thô có thể nghiêng về phía dễ: người ta chủ yếu thử những gì họ nghĩ sẽ chạy được.

build-eval: cùng nhau soạn đề

Chạy /claude-api build-eval: Claude phỏng vấn bạn, dựng eval ngay trong code, và dừng lại xin bạn duyệt ở những thời điểm nhất định.

Đề bài. Claude lấy dữ liệu đầu vào theo thứ tự: transcript production (sau khi hỏi về thời hạn lưu trữ và dữ liệu nhạy cảm), bug report và ticket hỗ trợ, năm đến mười ca bạn tự viết, rồi đến các ca tổng hợp từ code của bạn. Một trang đơn giản liệt kê từng đầu vào và chờ bạn xác nhận.

Người chấm. Tiếp theo, Claude đề xuất cách chấm rẻ nhất mà vẫn phù hợp. Kết quả có giới hạn thì dùng kiểm tra bằng code: khớp chính xác, một nhãn trong danh sách cố định, JSON đúng schema, test chạy qua. Kết quả mở thì dùng LLM-làm-giám-khảo, đọc một bảng tiêu chí viết thành các nhận định kiểm chứng được, thay vì thang điểm 1 đến 5; giám khảo không nên là chính model đang được kiểm tra. Claude chấm thử vài ca và hỏi xem bạn có chấm khác không.

Chẩn đoán. Trong lần chạy baseline, người chấm được chạy hai lần trên cùng một kết quả để xem phán quyết có đổi không, và Claude dò timeout, lỗi API, câu trả lời bị cắt ngang. Nếu baseline đã đạt khoảng 95 % trở lên, nó cảnh báo rằng nên nhắm vào chi phí hoặc độ trễ thay vì chất lượng.

Bạn nhận lại các ca, người chấm, runner, một transcript cho mỗi ca, và một trang kết quả đơn giản.

hillclimb: ôn bài, mỗi lần một thứ

Có đề thi đáng tin rồi, /claude-api hillclimb ôn bài như một học sinh có kỷ luật, mỗi lần một thứ. Bạn chọn những gì nó được phép sửa: system prompt, skill, mô tả công cụ, model, effort và các tham số API khác, hoặc code harness. Nó hỏi mục tiêu của bạn (hiệu năng, hoặc chi phí khi hiệu năng giữ nguyên), chia ngẫu nhiên các ca thành train và test, và kiểm tra rằng nhiễu của eval nhỏ hơn mức cải thiện nhỏ nhất mà bạn quan tâm. Sau đó mỗi vòng đều theo cùng một vòng lặp:

Claude đọc transcript train của vòng trước và đề xuất đúng một patch, sửa tận gốc (viết lại một đoạn, thêm một quy tắc còn thiếu) thay vì chỉ đổi chữ một dòng, để hiệu quả nổi lên trên mức nhiễu. Nếu cả train lẫn test cùng tăng, patch được giữ. Nếu có thụt lùi, patch bị huỷ. Nếu train tăng mà test đứng yên, Claude nghi overfitting và huỷ.

Khi điểm chững lại hai hoặc ba vòng, Claude phân loại từng lỗi còn lại theo nguyên nhân, thường nhờ đó phát hiện một ca mơ hồ hay một lỗi harness. Cuối cùng, code của bạn dừng ở phiên bản làm tốt nhất trên tập test, kèm khoảng tin cậy so với baseline. Nếu mức cải thiện nằm trong nhiễu, Claude khuyên không nên merge.

Kết quả thực tế

Bài viết trên claude.dev chia sẻ hai lần chạy. Lần đầu nhắm vào chi phí, trên một benchmark hỗ trợ khách hàng gồm 44 ticket, 30 ticket để tìm kiếm và 14 ticket để riêng. Baseline là Opus 4.8 với effort cao, đạt 74,4 % với 4,6 cent mỗi ticket. Sau khi rà soát prompt, Opus 5.5 với effort thấp đạt 87,8 % với 1,9 cent; Sonnet 5 với effort thấp đạt 88,9 % với khoảng 1 cent; một prompt tốt hơn sau đó đưa nó lên 98,9 %. Trên 14 ticket chưa từng thấy, cấu hình cuối cùng đạt 90,5 % so với 78,6 % ban đầu, với chi phí chỉ khoảng một phần năm.

Lần thứ hai nhắm vào hiệu năng của chính skill claude-api: từ 66 % lên khoảng 88 %, một phần nhờ bổ sung các tính năng còn thiếu, một phần nhờ sửa những tác vụ và người chấm có vấn đề.

Để thử

1. Cập nhật Claude Code. Skill claude-api đi kèm theo nó, nên cập nhật là có ngay phiên bản mới nhất của các lệnh này.

   claude update

2. Dựng eval ngay trong code của bạn. Claude hỏi bạn và chờ bạn đồng ý về các ví dụ và người chấm.

   /claude-api build-eval

3. Cải thiện ứng dụng theo eval đó, tuỳ mục tiêu của bạn (hiệu năng, hoặc chi phí khi hiệu năng giữ nguyên).

   /claude-api hillclimb

Kết luận

Hình ảnh kỳ thi chính là danh sách kiểm tra. Soạn một đề giống đời thật, giữ người chấm công bằng và nhất quán, ôn mỗi lần một thứ, và luôn giữ một bài thi thử chưa từng thấy. build-eval và hillclimb không thay thế phán đoán của bạn: chúng dừng lại đúng chỗ phán đoán đó quan trọng, và tập test để riêng giữ cho mọi người trung thực, kể cả model.