Chọn mô hình dựa trên bằng chứng

Xác định quyết định cần đưa ra

So sánh mô hình cần có mục đích sử dụng cụ thể. Mô hình giải thích tốt một hàm nhỏ có thể không xử lý tốt tương đương một thay đổi lớn trong repository. Mô hình chi phí thấp hơn có thể đáp ứng yêu cầu chất lượng cho các phép biến đổi thông thường. Điều tra khó có thể cần năng lực suy luận cao hơn.

Viết tác vụ và ràng buộc trước. Bao gồm dữ liệu được phép, công cụ cần dùng, thời gian phản hồi và chi phí tối đa chấp nhận được. Một số ràng buộc là bắt buộc. Không dùng điểm trung bình cao ở phần khác để bỏ qua hạn chế xử lý dữ liệu.

Sử dụng tác vụ tiêu biểu

Tạo bộ đánh giá nhỏ từ công việc nhóm thực sự làm. Loại bỏ dữ liệu nhạy cảm trừ khi môi trường đánh giá đã được phê duyệt cho dữ liệu đó. Bao gồm tác vụ đơn giản, tác vụ khó và tác vụ mà phản hồi đúng là yêu cầu thông tin còn thiếu.

Với một dịch vụ báo cáo giả định, sử dụng lỗi ngày tháng đã biết, tính năng lọc nhỏ và phần giải thích quy tắc phân quyền. Chuẩn bị kết quả mong đợi trước khi chạy so sánh. Thêm một test kiểm tra tình huống không hợp lệ và phát hiện lỗi đã biết.

Giữ riêng một số tác vụ khỏi quá trình phát triển prompt. Nếu liên tục tinh chỉnh prompt trên mọi ví dụ, điểm cuối cùng có thể phóng đại hiệu quả tổng quát. Một bộ riêng giúp phát hiện liệu prompt đã cải thiện có hoạt động ngoài các ví dụ dùng để tạo nó hay không.

Giữ phép so sánh công bằng

Ghi chính xác phiên bản mô hình, prompt, ngữ cảnh được cung cấp, công cụ và quyền. Sử dụng trạng thái khởi đầu tương đương. Nếu một mô hình nhận toàn bộ repository còn mô hình kia nhận một tệp, kết quả đang so sánh cả quy trình làm việc lẫn mô hình.

So sánh quy trình làm việc có thể hữu ích. Hãy gọi đúng tên. Một sản phẩm agent có nhiều thành phần hơn mô hình: lựa chọn ngữ cảnh, công cụ, giới hạn thực thi và hành vi khôi phục đều có thể ảnh hưởng đến kết quả.

Chạy lặp lại khi độ biến thiên đầu ra quan trọng. Ghi các lần thử thất bại thay vì chỉ báo cáo kết quả tốt nhất. Với tiêu chí chủ quan, dùng thang đánh giá bằng văn bản và nhiều người review nếu có thể.

Chấm chất lượng trước tốc độ

Trước hết, kiểm tra tiêu chí nghiệm thu bắt buộc. Thay đổi có đáp ứng yêu cầu không? Có giữ nguyên kiểm soát truy cập không? Các test liên quan có đạt không? Người review có thể hiểu diff không?

Sau đó so sánh công sức, thời gian đã trôi qua và chi phí của các kết quả chấp nhận được. Tính cả lần thử lại và review của con người. Câu trả lời rẻ nhưng cần sửa nhiều lần có thể đắt khi tính toàn tác vụ.

Benchmark công khai có thể giúp tìm ứng viên. Chúng dùng bộ tác vụ và phương pháp chấm điểm cụ thể. Không xem điểm benchmark là phép đo trực tiếp năng suất của nhóm.

Ghi quyết định và điều kiện hết hiệu lực

Kết quả có thể là một khuyến nghị hẹp. Ví dụ: “Dùng mô hình này để thêm test nhỏ trong repository này, với các yêu cầu review hiện có.” Bạn không cần một mô hình cho mọi tác vụ.

Nêu điều gì sẽ buộc phải đánh giá lại. Ví dụ gồm thay đổi phiên bản mô hình, cấu hình công cụ khác, loại dữ liệu mới hoặc kiểu lỗi lặp lại kéo dài. Duy trì phương án dự phòng cho tác vụ vượt quá khả năng của mô hình đã chọn.

Mục đích đánh giá là giảm sự chưa chắc chắn cho một quyết định thực tế. Tránh một cuộc thi mô hình kéo dài liên tục và tốn nhiều công sức hơn công việc mà nó hỗ trợ.