Trên trang này
Một câu trả lời về đơn trả hàng trông sẵn sàng gửi: đúng ngữ pháp, thân thiện và ngắn. Trong ví dụ này, điểm tự động cho tối đa. Trợ lý còn bảo khách đã được hoàn tiền dù chưa ai kiểm hệ thống thanh toán.
Lỗi không nằm ở câu văn. Nó nằm ở định nghĩa tốt yếu.
Trong màn trình diễn đánh giá được thu thập, nhóm tạo điểm cho tác nhân viết tài liệu phần mềm. Khoảnh khắc thú vị là người hiểu việc diễn tả chất lượng, rồi công cụ chuyển mô tả thành tiêu chí. Sau đó điểm thấp gợi nghi vấn đúng: phải sửa tác nhân hay sửa cách đánh giá?
Bảng tiêu chí là lý thuyết về công việc. Hãy kiểm thử lý thuyết.
Bắt đầu từ sai lầm loại trừ
Nhóm thường bắt đầu với chiều dễ chấm: rõ ràng, giọng văn, cấu trúc, đầy đủ. Chúng hữu ích nhưng hiếm khi đủ.
Với câu trả lời hoàn tiền minh họa, “đừng khẳng định đã hoàn tiền nếu chưa được hệ thống thanh toán xác nhận” quan trọng hơn chất lượng câu chữ. Với đồng bộ dữ liệu, “đừng ánh xạ email thanh toán sang email của chủ tài khoản” quan trọng hơn lời giải thích ánh xạ hay.
Hỏi chuyên gia ba loại ca: hiển nhiên tốt, hiển nhiên sai và ca người có hiểu biết có thể bất đồng. Giữ bản ghi nguồn và lý do cho từng đánh giá. Ca phụ thuộc quy tắc có thể đổi thì lưu phiên bản quy tắc cùng nhãn.
Lượt đầu có thể nhỏ. Không thể mơ hồ.
- Chủ công việc
ca tốt, xấu và còn tranh luận
- Kiểm tra chính xác định danh · quyền · đích
mã áp dụng sự thật
- Tiêu chí ngữ nghĩa
chỉ dùng mô hình nơi cần diễn giải
- Xem bất đồng
sửa nhãn và tiêu chí
| Điều kiểm | Chủ phù hợp hơn | Vì sao |
|---|---|---|
| Quyền bắt buộc tồn tại | Mã và bản ghi có thẩm quyền | Sự thật chính xác, có hệ quả |
| ID đích khớp định danh nguồn | Mã và bản ghi thử | Mô hình không nên đoán định danh |
| Câu trả lời giải đáp câu hỏi khách | Bảng tiêu chí do người duyệt, có thể thêm mô hình | Cần hiểu nghĩa |
| Giọng văn phù hợp hoàn cảnh | Bảng tiêu chí do người duyệt, có thể thêm mô hình | Có hơn một cách đạt |
Hướng dẫn triển khai AI trong quy trình hiện có cho thấy ranh giới giữa phán đoán và thực thi: mức độ chắc chắn của mô hình không trở thành quyền. Sau khi mô hình chọn ứng viên, mã phải sao chép giá trị gốc và kiểm ràng buộc.
Điểm số kế thừa điểm mù của tiêu chí
Phản biện hợp lý: “Con người không thể xem từng lượt tác nhân. Chúng ta cần mô hình chấm quy mô lớn.” Đúng. Câu hỏi là nó đang nhân rộng cái gì.
Nếu bảng thưởng câu trả lời trau chuốt mà không kiểm đơn thực sự hoàn tiền, tự động hóa sẽ nhân rộng phần bỏ sót. Con số hai chữ số thập phân trông chính xác nhưng vẫn có thể đo sai thứ.
Tài liệu đánh giá mô hình chấm của Google Cloud mô tả phép kiểm thực tế: chuẩn bị ca có người chấm, chạy thước đo bằng mô hình rồi so điểm. Không phải ý một người luôn đúng. Mô hình cần chuẩn bên ngoài trước khi điểm của nó có trọng lượng.
Xem bất đồng, không chỉ mức khớp trung bình. Mô hình cho qua câu mà trưởng nhóm hỗ trợ bác thì hỏi tiêu chí nào thiếu. Hai chuyên gia bất đồng thì giữ cả hai nhãn và tìm quy tắc họ hiểu khác. Đừng âm thầm lấy trung bình để xóa tranh luận.
Lấy mẫu quan trọng như lời tiêu chí. Tập toàn ca thường thành công có thể làm mô hình chấm trông đáng tin mà ca khó chưa được chạm. Gồm bản ghi thiếu, chỉ dẫn mâu thuẫn và ca câu đúng là dừng hỏi. Giữ một tập riêng mà người viết bảng chưa dùng để chỉnh, để cải thiện trên ví dụ quen phải chứng minh ở nơi khác. Quy tắc kinh doanh đổi thì cập nhật cả nhãn lẫn kết quả mong đợi; tập kiểm thử đóng băng có thể thưởng chính sách hôm qua.
Giữ kết quả gắn với đánh giá
Bảng tiêu chí tác nhân đồng bộ phải đi theo kết quả khách hàng. Đúng liên hệ đã đổi? Quyền đồng ý được tôn trọng? Có thể chạy lại bản ghi lỗi mà không lặp hành động có hệ quả?
Hướng dẫn bộ kết nối Brevo giải thích vì sao API gọi thành công mà thuộc tính vắng. Đánh giá chỉ xem tác nhân đã gọi endpoint sẽ bỏ lỡ kết quả. Chỉ xem đích có thể bỏ lỡ con đường bị cấm tình cờ ra đúng giá trị. Khi con đường có rủi ro, cả hai quan trọng.
Bắt đầu từ một tác vụ hẹp và vài dạng lỗi. Gắn nhãn ca cùng người sở hữu việc. Đặt kiểm tra chính xác trong mã, dùng mô hình chấm chỉ nơi ngôn ngữ hay phán đoán thực sự cần. Chạy lại cùng ca sau khi đổi prompt, mô hình hoặc công cụ. Ghi lỗi sau này tiết lộ gì về bảng tiêu chí.
Chi phí là thời gian chuyên gia ban đầu. Lợi ích là mọi điểm về sau có nghĩa mà ai đó bảo vệ được.
Bảng điều khiển hiển thị điểm. Chỉ bảng tiêu chí cho biết bạn đã đếm gì.
Câu hỏi Thường gặp
Ai nên định nghĩa tiêu chí đánh giá tác nhân AI?
Người hiểu công việc và hệ quả nên xác định kết quả chấp nhận được và lỗi loại. Kỹ sư biến phán đoán đó thành kiểm tra lặp được và đánh giá mô hình chấm có khớp người không.
Điểm chấm cao có chứng minh tác nhân chạy tốt không?
Không. Điểm đo mức khớp với bảng tiêu chí trên ca đã thử. Bảng yếu, ca thiếu đại diện hoặc mô hình chấm lệch có thể cho điểm cao với kết quả hại.
Điều gì nên kiểm bằng mã thay vì mô hình chấm?
Quyền chính xác, định danh bản ghi, lệnh công cụ bắt buộc và trạng thái đích nên dùng mã bất cứ khi nào có thể. Mô hình chấm hữu ích cho phẩm chất ngữ nghĩa mà quy tắc chính xác không quyết được.