Tự động hóa thiết kế bộ đánh giá và leo đồi tối ưu hóa cùng Claude

Các nguyên tắc cốt lõi giúp thiết kế bộ đánh giá (evals) và thực hiện thuật toán leo đồi (hillclimbing) để tối ưu hóa mà không tự đánh lừa bản thân, cùng cách mà hai lệnh build-eval và hillclimb trong kỹ năng (skill) claude-api đưa các nguyên tắc này vào vận hành thực tế.

Các bộ đánh giá (evaluations) cung cấp tín hiệu chuẩn xác về hiệu quả thực thi của ứng dụng hoặc kỹ năng trên từng tác vụ cụ thể. Tuy nhiên, việc thiết kế các bộ đánh giá cũng như cải thiện hiệu năng dựa trên chúng mà không tự đánh lừa bản thân là một bài toán khó. Chúng tôi đã bổ sung các hướng dẫn chi tiết cho cả hai quy trình này vào kỹ năng claude-api.

Với kỹ năng này, bạn có thể thực thi lệnh /claude-api build-eval để xây dựng một bộ đánh giá ngay bên trong cơ sở mã (codebase) của mình, đồng thời chạy lệnh /claude-api hillclimb để nâng cấp ứng dụng theo từng thay đổi đơn lẻ, kết hợp tập dữ liệu kiểm thử độc lập (held-out set) nhằm phát hiện hiện tượng quá khớp (overfitting).

Trong bài viết này, chúng tôi sẽ nêu bật các nguyên tắc thiết kế bộ đánh giá và thuật toán leo đồi (hillclimbing) chuẩn mực, sau đó trình bày cách Claude Code kết hợp kỹ năng claude-api áp dụng các nguyên tắc đó. Cuối cùng, chúng tôi sẽ minh họa bằng một số ví dụ thực tế về các câu lệnh này.

Các bộ đánh giá được thiết kế chuẩn mực thường sở hữu những yếu tố chung sau đây (Hình 1):

Tác vụ đánh giá phản ánh sát thực tế sản xuất (production): Hãy lấy mẫu các tác vụ mà bạn thực sự quan tâm trong môi trường vận hành thực tế, nơi tính năng hoặc ứng dụng sẽ được sử dụng. Đôi khi các tác vụ được chọn chỉ vì chúng dễ tạo ra hoặc dễ chấm điểm. Tuy nhiên, điều cốt yếu là phân phối tác vụ phải đại diện đúng cho những gì bạn thực sự kỳ vọng.
Hiệu năng cải thiện khi mô hình mạnh hơn và tư duy sâu hơn: Các mô hình có năng lực cao hơn cùng mức độ nỗ lực (effort level) lớn hơn thường phải đạt kết quả tốt hơn trong bài đánh giá. Nếu không, các tác vụ mơ hồ hoặc một bộ chấm điểm (grader) thiếu chuẩn hóa thường là nguyên nhân kìm hãm hiệu năng.
Còn dư địa vượt qua (headroom) ở ngưỡng biên: Mô hình mạnh nhất ở mức nỗ lực cao nhất cần đạt điểm thấp hơn đáng kể so với mức 100% trên bộ đánh giá; nếu không, bạn không thể đánh giá chuẩn xác tác động của các thay đổi lên hiệu năng. Quan trọng là khoảng cách này không được xuất phát từ các tác vụ bất khả thi hoặc mơ hồ: dấu hiệu nhận biết phổ biến là một tác vụ thất bại trong mọi lượt chạy đánh giá, bất kể số lần lặp lại. Một tác vụ tốt là tác vụ mà hai chuyên gia trong ngành đều đưa ra cùng một phán quyết và mọi tiêu chí mà bộ chấm điểm kiểm tra đều được nêu rõ trong đề bài.
Phương sai giữa các lượt chạy thấp: Phương sai cao thường do các tác vụ mơ hồ, thiết kế kém hoặc do bộ chấm điểm đưa ra các phán quyết khác nhau cho cùng một đầu ra giống hệt. Phương sai cũng có thể tiềm ẩn trong cấu hình. Ví dụ, mức độ nỗ lực tính toán không được áp dụng đồng nhất. Ngoài ra, môi trường cũng có thể ảnh hưởng đến kết quả đánh giá: trạng thái còn sót lại từ một lần thử trước (tệp tin rác, lịch sử git) có thể vô tình cung cấp luôn câu trả lời cho tác tử (agent).

Lấy mẫu đối kháng (Adversarial sampling)

Năng lực của mô hình thường không đồng đều (jagged). Nếu bạn chọn các trường hợp chỉ vì mô hình hiện tại thất bại trước chúng, bạn đang vô tình lấy mẫu tại các vùng trũng trên bề mặt năng lực của riêng mô hình đó (Hình 2). Bộ đánh giá rốt cuộc có thể chỉ đo lường dấu vết thất bại (failure fingerprint) của mô hình đó thay vì đo lường những gì thực sự khó hoặc có giá trị cốt lõi đối với ứng dụng của bạn.

Hãy chọn các trường hợp khó vì con người đánh giá chúng là khó: một phép thử hữu ích là bạn phải giải thích được lý do vì sao một tác vụ lại khó trước khi đưa nó vào bộ dữ liệu. Hãy đưa vào các trường hợp thất bại cụ thể trong ứng dụng được trích xuất từ lưu lượng thực tế, báo cáo lỗi (bug reports) hoặc phiếu hỗ trợ (tickets). Dù vậy, đừng tin tưởng tuyệt đối vào lưu lượng người dùng: người dùng đôi khi chỉ thử những gì họ dự đoán là sẽ hoạt động, do đó phân phối tác vụ rút ra hoàn toàn từ lưu lượng người dùng có thể bị lệch về phía quá dễ.

/CLAUDE-API BUILD-EVAL

Lệnh build-eval trong kỹ năng claude-api chuyển hóa các nguyên tắc này thành một quy trình làm việc có hướng dẫn. Khi bạn chạy /claude-api build-eval trong Claude Code, Claude sẽ phỏng vấn bạn, xây dựng bộ đánh giá ngay bên trong cơ sở mã và tạm dừng để chờ phê duyệt tại các mốc cụ thể.

Thiết kế các trường hợp mẫu

Claude hỗ trợ bạn lấy mẫu đầu vào để xây dựng các bộ đánh giá theo thứ tự ưu tiên sau:

Bản ghi tương tác thực tế (production transcripts), sau khi đã xác nhận về chính sách lưu trữ và dữ liệu nhạy cảm.
Báo cáo lỗi và phiếu hỗ trợ kỹ thuật.
Khoảng 5 đến 10 trường hợp do chính bạn tự biên soạn thủ công.
Các trường hợp được tổng hợp tự động từ cơ sở mã của bạn.

Kỹ năng ưu tiên dữ liệu vận hành thực tế, nhưng cũng có thể tạo dữ liệu tổng hợp dựa trên một vài ví dụ thực tế do bạn cung cấp. Kỹ năng sẽ yêu cầu Claude tạo một trang đơn giản hiển thị toàn bộ đầu vào và chờ bạn xác nhận. Để minh họa, dưới đây là tập hợp đầu vào mẫu cho ứng dụng định tuyến email mà kỹ năng có thể yêu cầu người dùng xem xét (Hình 3).

Xác thực bộ chấm điểm (grader)

Sau khi có dữ liệu đầu vào, Claude sẽ đề xuất phương án chấm điểm tiết kiệm chi phí nhất phù hợp với đầu ra ứng dụng của bạn:

Kiểm tra bằng chương trình (Programmatic verification): Nếu không gian đầu ra có giới hạn, hệ thống sẽ sử dụng cơ chế kiểm tra dựa trên mã lệnh (khớp chính xác, nhãn từ một tập cố định, JSON khớp cấu trúc schema, hoặc các bài kiểm thử vượt qua thành công).
Mô hình ngôn ngữ lớn làm giám khảo (LLM-as-judge): Hệ thống sẽ mặc định dùng phương pháp này nếu không gian đầu ra ở dạng mở, có nhiều câu trả lời hợp lệ nhưng tiêu chí chất lượng rõ ràng. Trong trường hợp này, một mô hình thứ hai sẽ đọc đầu vào, đầu ra và một biểu điểm chấm được viết dưới dạng các nhận định có thể kiểm chứng (không dùng thang điểm 1 đến 5), sau đó trả về điểm số kèm chuỗi suy luận logic. Nếu bạn có một mốc đối chứng (baseline), giám khảo sẽ đọc cả hai phương án theo thứ tự ngẫu nhiên (không được báo trước phương án nào là chuẩn đối chứng) và chọn ra phương án tốt hơn. Bạn được quyền chọn mô hình làm giám khảo, và mô hình này không được trùng với mô hình đang kiểm thử.

Claude sẽ chấm điểm thử một vài trường hợp và hỏi xem bạn có đánh giá khác biệt ở trường hợp nào không (Hình 4). Nhìn chung, việc trực tiếp đọc một mẫu các bản ghi đã chấm điểm trước khi tin tưởng vào bộ đánh giá là rất quan trọng; lỗi chấm điểm là một trong những nguyên nhân phổ biến nhất khiến bộ đánh giá bị định cấu hình sai.

Khi bạn đã xác thực bộ chấm điểm, kỹ năng sẽ thông báo quy mô của tập đánh giá (số trường hợp × số lần lặp × mô hình, cùng thời gian dự kiến), chạy mốc đối chứng và in ra điểm số kèm khoảng tin cậy (confidence interval). Kết quả trả về gồm: các trường hợp thử nghiệm, bộ chấm điểm, trình thực thi (runner), mỗi trường hợp kèm một dòng JSON và một bản ghi đầy đủ, cùng một trang đơn giản liệt kê điểm số từng trường hợp kèm liên kết đến bản ghi chi tiết. Nếu bạn muốn hiển thị nhiều hơn (chẳng hạn như biểu đồ), chỉ cần yêu cầu và Claude sẽ tạo thêm một trang phụ bên cạnh. Mặc định, các trang này là tệp tĩnh mở cục bộ và không tải bất kỳ tài nguyên nào từ mạng.

Kiểm tra chẩn đoán (Diagnostic checks)

Trong các lượt chạy mốc đối chứng nêu trên, Claude sẽ kiểm tra một số hạng mục:

Bộ chấm điểm: Claude chạy bộ chấm điểm hai lần trên cùng một đầu ra và báo cáo xem phán quyết có bị thay đổi hay không.
Hạ tầng kết nối (Plumbing): Claude kiểm tra lỗi hết thời gian chờ (timeouts), lỗi API và phản hồi bị ngắt quãng để đảm bảo nhiễu hạ tầng không bị nhầm lẫn thành phương sai của mô hình.
Dư địa cải thiện (Headroom): Nếu mốc đối chứng đã đạt khoảng 95% trở lên, kỹ năng sẽ cảnh báo người dùng và lưu ý rằng quá trình leo đồi nên hướng vào việc tối ưu hóa chi phí hoặc độ trễ thay vì chất lượng.

Khi đã có phương thức đáng tin cậy để chấm điểm hiệu năng của ứng dụng, bạn có thể bắt đầu cải thiện nó. Thuật toán leo đồi (hillclimbing) là phương pháp hiệu quả để tinh chỉnh các tham số như mức độ nỗ lực hoặc câu lệnh nhắc (prompts), nhằm cân bằng giữa chi phí và hiệu năng. Dưới đây là một số mẹo chung khi lựa chọn phạm vi áp dụng:

Vòng lặp thử nghiệm chi phí thấp: Việc chỉnh sửa phạm vi tối ưu hóa phải ít tốn kém (về thời gian, chi phí và công sức). Nhiều dự án nội bộ và khách hàng đã tập trung leo đồi trên định dạng văn bản, chẳng hạn như câu lệnh nhắc và kỹ năng. Chúng rất dễ thay đổi và khôi phục. Ngược lại, việc chỉnh sửa mở rộng khung điều phối tác tử (agent harness) có thể đòi hỏi thay đổi mã nguồn trên diện rộng.
Có thể quy gán nguyên nhân (Attributable): Sự thay đổi điểm số trong bài đánh giá phải quy gán được trực tiếp cho phần bạn đang chỉnh sửa trong quá trình leo đồi. Ví dụ, nhiều ứng dụng leo đồi thành công tập trung vào việc kích hoạt kỹ năng. Chỉ số đánh giá (tỷ lệ kích hoạt kỹ năng) gắn liền trực tiếp với phần mô tả kỹ năng đang được sửa đổi.
Mục tiêu được giới hạn rõ ràng: Một lỗi phổ biến là yêu cầu cải thiện hiệu năng chung chung mà không tính toán kỹ dư địa còn lại trong bộ đánh giá; một bộ đánh giá gần mức bão hòa hoặc phạm vi điều chỉnh không rõ ràng (ví dụ: yêu cầu cập nhật khung điều phối một cách mở) sẽ rất dễ bị đình trệ. Một mục tiêu nhất quán và hiệu quả là chi phí: ngay cả khi bài đánh giá đã bão hòa điểm số, bạn vẫn có thể yêu cầu Claude tìm cách giảm chi phí trong khi vẫn giữ nguyên hiệu năng tương đương.

Ngay cả một bộ đánh giá được thiết kế tốt cũng hiếm khi khớp hoàn toàn với phân phối tác vụ thực tế trong môi trường sản xuất. Do đó, hiện tượng quá khớp (overfitting) vào bộ đánh giá là vấn đề phổ biến, dẫn đến hệ thống đạt điểm rất cao trên bài kiểm tra nhưng lại kém hiệu quả khi xử lý lưu lượng thực tế.

Có nhiều cách khiến dữ liệu đánh giá bị “rò rỉ” vào khung điều phối (phần mã bao quanh mô hình, bao gồm prompt, công cụ và vòng lặp gọi Claude). Ví dụ, giả sử một tác vụ đánh giá hưởng lợi từ tính năng nhận dạng ký tự quang học (OCR), nhưng OCR hiếm khi hữu ích trong môi trường sản xuất thực tế. Khung điều phối có thể thêm công cụ OCR vào ứng dụng, giúp tăng điểm chuẩn đối sánh (benchmark) mà không mang lại giá trị thực tế. Mở rộng ra, quá trình leo đồi có thể bổ sung các tính năng vào khung điều phối chỉ để xử lý các trường hợp biên trong bộ đánh giá cụ thể mà bạn đã chọn. Những bổ sung này làm tăng điểm đánh giá nhưng không chuyển hóa thành cải tiến thực tế (Hình 5).

Ba giải pháp sau có thể khắc phục triệt để vấn đề này:

Chia tách các trường hợp thử nghiệm: Sử dụng một tập huấn luyện (train set) mà bộ leo đồi có thể đọc và một tập kiểm thử (test set) hoàn toàn được giữ kín. Nếu điểm số của tập huấn luyện tăng trong khi tập kiểm thử đi ngang, đó là dấu hiệu cảnh báo quá khớp rõ ràng.
Tuyệt đối không dán trực tiếp các ca thất bại vào prompt: Nếu bộ leo đồi đọc các bản ghi thất bại, nó không bao giờ được sao chép trực tiếp nội dung thất bại đó vào câu lệnh nhắc.
Ngăn chặn mô hình tiếp cận câu trả lời về mặt cấu trúc: Các mô hình đôi khi có thể “tối ưu hóa phần thưởng đường tắt” (reward hacking) bằng cách trực tiếp tìm ra đáp án của các bài đánh giá.

Như được thảo luận dưới đây, kỹ năng claude-api sẽ tự động áp dụng các nguyên tắc này cho bạn.

/CLAUDE-API HILLCLIMB

Lệnh hillclimb trong kỹ năng claude-api biến các nguyên tắc này thành một quy trình tương tác có hướng dẫn. Khi bạn chạy /claude-api hillclimb trong Claude Code, Claude sẽ lặp đi lặp lại để tối ưu hóa theo bộ đánh giá đã cho. Bạn có quyền chọn những thành phần mà mô hình được phép thay đổi, bao gồm:

Câu lệnh nhắc hệ thống (system prompt) của bạn
Các tệp kỹ năng hoặc tệp chỉ dẫn
Mô tả công cụ (tool descriptions)
Lựa chọn mô hình, mức độ nỗ lực tính toán và các tham số API khác
Mã nguồn khung điều phối (harness code) của bạn

Trước khi bắt đầu, Claude sẽ hỏi bạn muốn tối ưu hóa yếu tố nào (ví dụ: tối ưu hiệu năng, hoặc tối ưu chi phí trong khi vẫn giữ nguyên hiệu năng) và sau đó phân chia ngẫu nhiên tập đánh giá thành tập kiểm thử và tập huấn luyện. Với mục tiêu chi phí, hệ thống sẽ xem xét một số yếu tố chi phí phổ biến, bao gồm lưu tạm câu lệnh (prompt caching), kiểm tra câu lệnh nhắc để đảm bảo tương thích với mô hình đã chọn, cũng như thiết lập mô hình và mức nỗ lực phù hợp.

Trước vòng đầu tiên, Claude kiểm tra xem độ nhiễu của bài đánh giá (mức độ điểm số có thể dao động ngẫu nhiên) có nhỏ hơn mức cải thiện tối thiểu mà bạn kỳ vọng hay không; nếu không đạt, hệ thống sẽ thông báo và đề xuất tăng thêm số lần lặp hoặc số trường hợp thử nghiệm.

Ở mỗi vòng, Claude đọc các bản ghi của tập huấn luyện từ vòng trước và đề xuất một thay đổi dưới dạng một bản vá (patch). Mô hình nhắm mục tiêu ở mỗi vòng vào một thay đổi có hiệu ứng vượt trội hơn độ nhiễu của bài đánh giá: khắc phục hành vi thất bại tận gốc (ví dụ: viết lại phần gây ra lỗi hoặc bổ sung quy tắc còn thiếu) thay vì chỉ chỉnh sửa câu chữ đơn thuần. Sau đó, Claude chạy đánh giá với bản vá đã áp dụng. Tại bước này, Claude kiểm tra: nếu tập huấn luyện cải thiện nhưng tập kiểm thử đi ngang, Claude nghi ngờ quá khớp và khôi phục (revert) bản vá. Nếu xảy ra suy giảm hiệu năng (regression), Claude cũng khôi phục. Nếu cả tập huấn luyện và tập kiểm thử đều cải thiện, hệ thống sẽ giữ lại bản vá (Hình 6).

Khi điểm số bị đình trệ trong hai hoặc ba vòng, Claude sẽ đọc từng ca thất bại còn lại của tập huấn luyện và phân loại theo nguyên nhân. Hệ thống cũng làm điều tương tự từ sớm nếu không có giải pháp đơn lẻ nào tạo ra mức cải thiện lớn hơn độ nhiễu đánh giá, đồng thời đề xuất tăng số lần lặp lại hoặc trường hợp thử nghiệm thay vì lãng phí các vòng chạy cho những thay đổi quá nhỏ để đo lường. Bước này có thể phát hiện các trường hợp đánh giá mơ hồ, lỗi khung điều phối hoặc phương sai giữa các lần chạy.

Chỉ những trường hợp thất bại thực sự hợp lệ mới được đưa vào các vòng leo đồi tiếp theo.

Khi quá trình leo đồi hoàn tất, Claude sẽ giữ lại mã nguồn ở phiên bản đạt kết quả tốt nhất trên tập kiểm thử theo mục tiêu của bạn. Hệ thống báo cáo kết quả kiểm thử so với mốc đối chứng kèm theo các khoảng tin cậy (Hình 7). Nếu mức cải thiện nằm trong phạm vi nhiễu, Claude sẽ nêu rõ và khuyến nghị không nên hợp nhất (merge) thay đổi.

Tối ưu hóa leo đồi để giảm chi phí

Chúng tôi đã thử nghiệm lệnh /claude-api hillclimb trên bộ chuẩn đối sánh hỗ trợ khách hàng nội bộ nhằm mục tiêu giảm chi phí và nâng cao hiệu năng. Bộ kiểm thử gồm 44 phiếu hỗ trợ, trong đó 30 phiếu dùng cho tìm kiếm tối ưu và 14 phiếu được giữ kín để kiểm thử. Hệ thống bắt đầu trên Opus 4.8 ở cấu hình nỗ lực mặc định (cao) với độ chính xác ra quyết định đạt 74,4% trên các phiếu tìm kiếm và chi phí mã token là 4,6 cent mỗi phiếu.

Quá trình leo đồi trước tiên đã kiểm tra câu lệnh nhắc, loại bỏ các bước gọi công cụ bắt buộc rườm rà, bước ghi chép nháp (scratchpad) và các quy tắc mâu thuẫn. Sau đó, hệ thống thử nghiệm Opus 5.5 ở mức nỗ lực thấp. Cấu hình này đã vượt qua ngưỡng chính xác cơ sở khi đạt 87,8% và giảm chi phí xuống còn 1,9 cent mỗi phiếu, tức giảm hơn một nửa chi phí ban đầu.

Một phần khoản tiết kiệm đến từ biểu giá của Opus 5.5: chi phí token đầu vào và đầu ra thấp hơn 20% so với Opus 4.8, và chi phí đọc bộ nhớ đệm (cache reads) thấp hơn 60%. Vì Opus 5.5 đã vượt qua mốc chuẩn, quá trình leo đồi tiếp tục thử nghiệm hạ xuống một bậc mô hình thấp hơn để kiểm tra xem mô hình rẻ hơn có thể đáp ứng hay không. Sonnet 5 ở mức nỗ lực thấp đạt điểm số tương đương, 88,9%, với chi phí chỉ bằng khoảng một nửa, tức 1 cent mỗi phiếu (Hình 8).

Cuối cùng, Claude cải thiện câu lệnh nhắc bằng các quy tắc định tuyến và đối chiếu giới hạn hoàn tiền, đưa Sonnet 5 lên mức 98,9% với chi phí gần như không đổi. Trên 14 phiếu kiểm thử độc lập mà quá trình tìm kiếm chưa từng thấy, cấu hình cuối cùng đạt 90,5% so với mức 78,6% của thiết lập gốc ban đầu, với chi phí chỉ bằng khoảng một phần năm.

Tối ưu hóa leo đồi để nâng cao hiệu năng

Một ví dụ khác là kỹ năng claude-api của chính chúng tôi, công cụ cung cấp hướng dẫn sử dụng API và các mẹo làm việc với Claude (bao gồm các lệnh con được thảo luận trong bài viết này). Chúng tôi muốn đảm bảo kỹ năng có thể triển khai mã nguồn sử dụng API một cách chuẩn xác, nên đã xây dựng một bộ đánh giá trích xuất từ tài liệu hướng dẫn để kiểm thử kỹ năng này.

Trong bài đánh giá, kỹ năng bắt đầu ở mức 66%. Chúng tôi cấp cho bộ leo đồi quyền truy cập tài liệu và các bộ phát triển phần mềm (SDKs), cho phép Claude tự nhận diện lỗi và tự sửa đổi (Hình 9). Claude phát hiện ra rằng kỹ năng này đang thiếu hướng dẫn về 8 tính năng.

Việc bổ sung các phần này vào kỹ năng đã giúp nâng hiệu năng lên 74%. Sau đó, hệ thống phát hiện thêm các lỗi trong bảng kiểu dữ liệu của C# và Java, giúp hiệu năng tăng tiếp lên 77%.

Sau khi điểm số chững lại trong hai vòng, Claude đã phân tích các lỗi còn lại và gom nhóm theo nguyên nhân gốc rễ. Một vòng thông thường chỉ thực hiện một chỉnh sửa cho lỗi phổ biến nhất. Bước này không thực hiện chỉnh sửa nào; nó chỉ phân loại mọi thất bại còn lại theo nguyên nhân. Bước phản tư (reflection) này mang lại hiệu quả rõ rệt:

Khi phản tư trên tập hợp các ca thất bại, bộ leo đồi nhận ra nội dung kỹ năng đã có sẵn nhưng Claude chỉ đơn giản là đang viết cấu trúc API cũ (do kiến thức được huấn luyện trước đó). Để xử lý, bộ leo đồi đã thêm một bảng đối chiếu ở gần đầu tệp kỹ năng nhằm định hướng Claude từ các định dạng cũ sang định dạng hiện tại: ví dụ: chuyển từ suy luận mở rộng (extended thinking) với ngân sách token cố định—vốn đã bị API từ chối trên các dòng Opus mới—sang suy luận thích ứng (adaptive thinking), và từ các phiên bản cũ của công cụ tìm kiếm web sang phiên bản hiện hành. Hệ thống cũng di chuyển các cảnh báo C# và Java về tư duy ngân sách cố định lên phía trên các ví dụ về tư duy thích ứng. Điều này giúp nâng hiệu năng lên 80%.
Những tác vụ không bao giờ cải thiện hiệu năng dù đã giải quyết các lỗ hổng nội dung rõ ràng chính là dấu hiệu cho thấy ví dụ hoặc bộ chấm điểm có sai sót. Một tác vụ yêu cầu viết mã bắt một loại ngoại lệ, trong khi bộ chấm điểm lại đòi hỏi một chuỗi bắt ít nhất ba lỗi. Claude đã viết lại yêu cầu tác vụ. Một chỉ dẫn chấm điểm khác lại mâu thuẫn với tài liệu hướng dẫn của chúng tôi, và kiểm tra API thực tế cho thấy tài liệu là chính xác. Việc xử lý các điểm này cùng với một số tinh chỉnh kỹ năng khác đã đưa hiệu năng đạt mức ~88%.

Lưu ý: Hãy chạy lệnh claude update trước tiên. Kỹ năng claude-api được tích hợp sẵn bên trong Claude Code, do đó việc cập nhật sẽ giúp bạn có phiên bản mới nhất của các lệnh này.

claude update

Sau đó, trong Claude Code:

/claude-api build-eval
/claude-api hillclimb

Các lệnh con này có thể được sử dụng trực tiếp trong Claude Code thông qua kỹ năng claude-api:

Hãy chạy /claude-api build-eval nếu bạn muốn khởi tạo một bộ đánh giá cho một bài toán cụ thể. Bạn có thể định hướng quá trình này bằng cách cung cấp quyền truy cập vào các ví dụ (chẳng hạn như lịch sử tương tác – traces). Claude sẽ vận dụng toàn bộ hướng dẫn được chia sẻ trong bài viết này để thiết kế bộ đánh giá chuẩn xác nhất cho bạn.

Nguồn: Claude Blog (Anthropic)

LIÊN HỆ TƯ VẤN CÁC DỊCH VỤ AI

Hỗ trợ tư vấn, đào tạo và chuyển giao AI cho cá nhân, doanh nghiệp và tổ chức.

📞 Điện thoại: 0981243678

Liên hệ qua Zalo