Kích hoạt Skill & Độ tin cậy Kép pass^k
Cơ chế kích hoạt là chốt chặn đầu tiên, ma trận nhầm lẫn trigger, đánh giá Exact/In_order/Any_order và bài toán suy giảm độ tin cậy lũy thừa pass^k.
Đánh giá các vùng dễ phát sinh lỗi, không chỉ nhìn vào câu trả lời
Một câu trả lời trau chuốt có thể che giấu một hệ thống đang gặp sự cố. Có thể một skill sai đã được kích hoạt, skill đúng lại gọi một tool không an toàn, hoặc một skill mới cài đặt làm giảm chất lượng của các yêu cầu không liên quan. Sơ đồ phân vùng lỗi bên dưới tách biệt bốn bề mặt cần các loại bằng chứng khác nhau.
Bản đồ các vùng lỗi của Agent Skill
Một câu trả lời trau chuốt có thể che giấu hệ thống đang hỏng. Bốn vùng lỗi cần bốn loại bằng chứng khác nhau.
Lỗi kích hoạt (Trigger)
Skill dự kiến có chạy không, và các skill lân cận có giữ yên lặng không?
Trường hợp hợp lệ và không hợp lệ, ma trận nhầm lẫn, mục tiêu độ chính xác kích hoạt.
Lỗi kích hoạt (Trigger failure) xảy ra khi skill chạy cho một yêu cầu sai hoặc không chạy cho một yêu cầu đúng. Lỗi thực thi (Execution failure) là khi định tuyến đúng nhưng quy trình hoặc luồng gọi tool (tool trajectory) bị sai. Lỗi ngân sách token (Token budget failure) xuất hiện khi skill tiêu tốn quá nhiều context đến mức làm giảm chất lượng phần còn lại của phiên làm việc. Lỗi suy thoái (Regression) xảy ra khi một skill mới chồng lấn lên skill khác hoặc làm thay đổi định tuyến trên toàn bộ thư viện.
Hãy coi bốn bề mặt này là định nghĩa tối thiểu của khả năng bao phủ đánh giá toàn diện (complete eval coverage):
Hãy dùng skill hoàn tiền để hiểu tại sao các bề mặt này phải được kiểm thử riêng biệt. Đầu tiên, gửi các yêu cầu thanh toán hợp lệ và không hợp lệ rồi xác minh quyết định định tuyến: đó là bằng chứng kích hoạt (trigger evidence). Thứ hai, với mỗi lượt kích hoạt đúng, xác minh lời giải thích hoàn tiền và chuỗi gọi tool chỉ đọc: đó là bằng chứng thực thi (execution evidence). Thứ ba, thêm skill vào thư viện thanh toán hiện có rồi chạy lại các trường hợp giao hàng, thẻ bị từ chối và trạng thái hoàn tiền: đó là bằng chứng suy thoái (regression evidence). Cuối cùng, lặp lại các trường hợp không liên quan đó với lịch sử hội thoại thực tế, schema của tool và 5–15 skill thường xuyên hoạt động cùng lúc: đó là bằng chứng ngân sách token (token-budget evidence). Sự cố ở mỗi bước sẽ chỉ ra một bên chịu trách nhiệm và cách khắc phục hoàn toàn khác nhau.
Bảng dưới đây là tóm tắt điều kiện phát hành sau bốn thử nghiệm đó:
| Vùng đánh giá (Surface) | Câu hỏi phát hành | Chỉ số hoặc thành phẩm (Metric / Artifact) |
|---|---|---|
| Kích hoạt (Trigger) | Skill dự kiến có chạy không, và các skill lân cận có giữ yên lặng không? | Trường hợp hợp lệ/không hợp lệ, ma trận nhầm lẫn (confusion matrix), mục tiêu độ chính xác kích hoạt |
| Thực thi (Execution) | Kết quả có đúng không, và có đạt được qua con đường an toàn không? | Rubric đầu ra, tool dự kiến, khẳng định luồng gọi (trajectory assertions), unit test cho tool |
| Suy thoái (Regression) | Skill mới có làm hỏng năng lực hiện có không? | So sánh với baseline của toàn thư viện, không chấp nhận suy giảm hiệu năng |
| Ngân sách token (Token budget) | Việc nạp đồng thời thực tế có làm giảm chất lượng công việc không liên quan không? | Dung lượng token, chênh lệch độ trễ/chi phí, chất lượng tác vụ không liên quan khi nạp chung 5–15 skill |
Một kịch bản thuận lợi (happy path) chạy qua không thể bù đắp cho một bề mặt đánh giá còn thiếu. Nếu chưa có bằng chứng về nạp token hoặc suy thoái, trạng thái phải được ghi nhận là chưa được đánh giá, chứ không phải “có lẽ đã sẵn sàng.” Thành phẩm cho PM nên là một ma trận bao phủ ngắn gọn, ghi rõ chủ sở hữu, phiên bản tập test, ngưỡng đạt, kết quả và đường dẫn bằng chứng cho từng dòng.
Bốn bề mặt trên cho biết cái gì cần được bao phủ. Bộ công cụ đánh giá cho biết khi nào và làm thế nào để tích lũy bằng chứng. Bắt đầu bằng kiểm thử đơn vị đánh giá (eval-as-unit-test) cho mọi chỉnh sửa. Thêm tập dữ liệu chuẩn () khi hành vi kinh doanh dự kiến đã ổn định. Sử dụng LLM-as-Judge đã được hiệu chuẩn để mở rộng việc đánh giá đầu ra vượt giới hạn kiểm tra thủ công, nhưng vẫn giữ lại các trường hợp do con người đánh giá. Trước khi cấp quyền thực thi (write authority), hãy dùng các bài kiểm thử tấn công () để kiểm tra ranh giới và phân quyền. Cuối cùng, quan sát ở chế độ hoặc triển khai thử nghiệm diện hẹp () trên lưu lượng thực tế trước khi phát hành toàn bộ. Không có công cụ đơn lẻ nào có thể thay thế cho giai đoạn trước đó.
Năm mô hình đánh giá được tóm tắt như sau:
| Mô hình (Pattern) | Chứng minh điều gì | Bằng chứng yêu cầu / Cấp độ |
|---|---|---|
| Eval-as-Unit-Test | Hành vi dự kiến giữ ổn định sau mỗi thay đổi | Trường hợp CI cho định tuyến, tool, đầu ra và suy thoái; áp dụng cho mọi skill |
| Golden Dataset | Đầu vào đại diện giữ đúng đầu ra và luồng gọi đã thống nhất | Các cặp đầu vào/kết quả dự kiến có phiên bản; cấp độ nháp (draft tier) trở lên |
LLM-as-Judge | Chất lượng đầu ra chấm theo rubric mở rộng vượt giới hạn thủ công | Rubric đã hiệu chuẩn theo con người và đảo vị trí chấm; read-only và draft |
| Adversarial / Red-Team | Làm lộ các lỗi diễn đạt lại, ranh giới, tiêm lệnh (injection), phân quyền và khôi phục | Ít nhất một lỗi diễn đạt và một ranh giới không hợp lệ cho mỗi trường hợp hợp lệ; trước khi cho phép hành động |
| Canary / Shadow Mode | Hành vi offline đứng vững trong điều kiện production có kiểm soát | So sánh shadow hoặc canary tỷ lệ thấp có cảnh báo và rollback; trước mỗi đợt phát hành cho phép hành động |
Gói hồ sơ phát hành (release packet) phải liên kết đủ cả năm thành phẩm và tuyên bố rõ những mục nào không áp dụng. Câu nói “team đã chạy đánh giá” là quá mơ hồ để tiến hành kiểm toán.
Thang leo bằng chứng đánh giá
Mỗi bậc tích lũy loại bằng chứng mà bậc trước không tạo ra được. Không công cụ nào thay thế được giai đoạn trước nó.
Eval-as-Unit-Test
Hành vi dự kiến giữ ổn định sau mỗi thay đổi.
Trường hợp CI cho định tuyến, tool, đầu ra và suy thoái; bắt buộc với mọi skill.
Các kết quả benchmark cho thấy lý do tại sao sự nghiêm ngặt này lại quan trọng. SkillsBench phát hiện 19% trong số 84 tác vụ agent thực tế hoạt động tệ hơn khi có skill so với khi không có. Một phân tích production khác ghi nhận 56% trường hợp không được kích hoạt (non-invocation) ở các skill lẽ ra phải chạy; các skill bị rút gọn chỉ dẫn đạt 58% so với 63% của base agent, trong khi chỉ mục quy ước thụ động AGENTS.md đạt 100% so với baseline 53%. Những kết quả này không có nghĩa là skill luôn thất bại. Chúng cho thấy quy trình hẹp, quy ước chung và lớp truy xuất là các thành tố sản phẩm (product primitives) hoàn toàn khác nhau, và một skill đặt sai chỗ có thể làm suy giảm năng lực của hệ thống.
Hai bề mặt đầu tiên thường có thể quan sát được trong một yêu cầu đơn lẻ. Hai bề mặt sau chỉ bộc lộ khi thư viện thực tế và ngữ cảnh thực tế được nạp cùng nhau. Một bản demo chỉ chạy thử một skill riêng lẻ không thể chứng minh độ sẵn sàng cho môi trường production.
Đối với PM, điều này làm thay đổi tiêu chí nghiệm thu (acceptance criteria). "Câu trả lời trông có vẻ ổn" chỉ là một tín hiệu, không phải là cổng phát hành (release gate). Team phải biết rõ skill nào đã kích hoạt, tài nguyên nào đã nạp, tool nào đã được gọi, trạng thái nào đã thay đổi và các skill lân cận có còn hoạt động đúng hay không.