Cách đánh giá một mô hình mới trong 48 giờ: Danh sách kiểm tra ngày ra mắt
Một mô hình mới vừa ra mắt. Các video demo trông rất ấn tượng, trang giá đang được chú ý, ảnh chụp leaderboard đã bắt đầu lan truyền, và kênh roadmap của bạn muốn có câu trả lời vào ngày mai: mô hình này có nên được đưa vào sản phẩm không?
Câu trả lời tệ nhất là "chúng tôi đã thử vài prompt và thấy tốt hơn." Câu trả lời tệ nhì là một dự án đánh giá kéo dài cả tháng và bỏ lỡ cửa sổ ra mắt.
Hướng dẫn này mang đến cho các nhóm sản phẩm AI một cách tiếp cận thực tế ở mức trung gian. Hãy dùng Cách đánh giá một mô hình mới trong 48 giờ: Danh sách kiểm tra ngày ra mắt như một kế hoạch vận hành cho ngày phát hành: xây dựng một bộ eval nhỏ nhưng đại diện, so sánh với lộ trình đang chạy trong production của bạn, chạy các cổng kiểm tra tương thích và an toàn, chuẩn hóa chi phí theo đầu ra được chấp nhận, và kết thúc bằng một bản ghi nhớ quyết định mà các nhóm kỹ thuật, sản phẩm và tài chính của bạn thực sự có thể ký duyệt.
Mục tiêu không phải là chứng minh rằng mô hình mới tốt hơn trên mọi phương diện. Mục tiêu là quyết định xem nó có đủ an toàn, đủ hữu ích và đủ kinh tế cho một quy trình sản phẩm được xác định rõ hay không.
Câu trả lời trong 48 giờ
Nếu bạn chỉ có hai ngày, hãy đánh giá mô hình mới dựa trên một công việc production cụ thể, chứ không phải dựa trên toàn bộ internet.
Hãy chọn một workload đã có người dùng, log, các chế độ lỗi và một baseline hiện tại. Sau đó trả lời sáu câu hỏi:
| Cổng kiểm tra | Câu hỏi | Tín hiệu đạt |
|---|---|---|
| Phù hợp | Mô hình có giải quyết tác vụ mục tiêu tốt hơn lộ trình hiện tại không? | Tỷ lệ đầu ra được chấp nhận cao hơn trên các ví dụ mang hình dạng production |
| Hợp đồng | Mô hình có giữ được schema bắt buộc, lệnh gọi công cụ, trích dẫn, cài đặt media hoặc định dạng phản hồi không? | Không có lỗi chặn trong các bài kiểm tra hợp đồng đầu ra |
| An toàn | Mô hình có tạo ra các lỗi mới về chính sách, quyền riêng tư, ảo giác, hoặc rủi ro thương hiệu không? | Tỷ lệ lỗi nghiêm trọng bằng hoặc thấp hơn baseline |
| Độ tin cậy | Mô hình có thể chịu được độ trễ, thử lại, giới hạn tốc độ và điều kiện ngữ cảnh dài không? | Độ trễ p90 và hành vi lỗi phù hợp với SLO của sản phẩm |
| Chi phí | Mô hình có giảm chi phí trên mỗi đầu ra được chấp nhận, chứ không chỉ giá token không? | Chi phí đầu ra được chấp nhận thấp hơn hoặc ngang bằng một cách hợp lý |
| Ra mắt | Bạn có thể triển khai nó qua shadow traffic, canary routing và rollback không? | Chính sách định tuyến, giám sát và điều kiện dừng rõ ràng |
Đó là cốt lõi của Cách đánh giá một mô hình mới trong 48 giờ: Danh sách kiểm tra ngày ra mắt: rút gọn quyết định thành phép so sánh production nhỏ nhất nhưng đáng tin cậy nhất.
Trước giờ 0: chọn một workload
Đừng bắt đầu bằng câu hỏi, "Mô hình mới có tốt hơn không?" Hãy bắt đầu bằng câu hỏi, "Tốt hơn cho công việc nào?"
Hãy chọn một workflow có đầu ra có thể đo lường:
- Tạo câu trả lời hỗ trợ khách hàng.
- Lập kế hoạch bản vá code.
- Tóm tắt kết quả tìm kiếm.
- Trích xuất OCR.
- Viết lại nội dung sản phẩm.
- Tóm lược nghiên cứu bán hàng.
- Tạo nội dung sáng tạo có kiểm duyệt.
- Bước tác tử gọi công cụ.
- Mở rộng prompt cho video hoặc hình ảnh.
Sau đó xác định baseline hiện tại. Đó có thể là một mô hình của nhà cung cấp trực tiếp, một lộ trình mô hình trong gateway của bạn, một quy trình có hỗ trợ con người, hoặc một phiên bản mô hình trước đó. Baseline là thứ biến sự hào hứng ngày ra mắt thành một phép so sánh có thể đo lường.
Đối với các nhóm Flatkey, đây cũng là nơi bộ định tuyến hợp nhất phát huy tác dụng: giữ hợp đồng ứng dụng ổn định trong khi bạn thử một tuyến mô hình mới, rồi so sánh request ID, chi phí, lỗi và mức chấp nhận đầu ra trong một sổ cái duy nhất. Nếu hệ thống của bạn vẫn còn rải rác qua các khóa trực tiếp, hãy áp dụng cùng nguyên tắc theo cách thủ công: một tác vụ, một đường cơ sở, một bản ghi quyết định.
Giờ 0-3: khóa chặt bản ghi quyết định
Hãy tạo bản ghi trước khi bất kỳ ai nhìn thấy kết quả. Điều này ngăn đội ngũ thay đổi định nghĩa về "tốt" sau khi mô hình tạo ra vài ví dụ ấn tượng.
Sử dụng mẫu này:
Mô hình mới:
Ngày phát hành:
Chủ sở hữu đánh giá:
Quy trình mục tiêu:
Đường cơ sở hiện tại:
Phân khúc người dùng:
Khối lượng lưu lượng bị ảnh hưởng:
Cần quyết định:
[ ] không hành động
[ ] tiếp tục thử nghiệm
[ ] lưu lượng bóng
[ ] canary
[ ] thay thế toàn bộ tuyến
Rào cản cứng:
- Dữ liệu/quyền riêng tư:
- Tuân thủ:
- Hợp đồng đầu ra:
- An toàn:
- Độ trễ/SLO:
- Chi phí:
- Chất lượng sản phẩm:
Tiêu chí đạt:
- Chất lượng:
- Độ tin cậy:
- Chi phí cho mỗi đầu ra được chấp nhận:
- Quay lui:
Hạn chót quyết định:
Người phê duyệt quyết định:
Bản ghi này được cố ý giữ hẹp. Đánh giá mô hình vào ngày phát hành không nên quyết định kiến trúc AI cho cả năm tiếp theo. Nó nên quyết định một thay đổi tuyến duy nhất.
Giờ 3-8: xây dựng tập eval hữu ích nhỏ nhất
Một tập eval 48 giờ hữu ích có bốn phần.
| Nhóm | Kích thước | Mục đích |
|---|---|---|
| Nhiệm vụ vàng | 25-50 ví dụ | Các ví dụ đã biết với đầu ra mong đợi hoặc đã được xem xét |
| Nhiệm vụ sản xuất lộn xộn | 50-100 ví dụ | Các trường hợp biên thực từ log, phiếu hỗ trợ, truy vấn tìm kiếm, lượt tải lên hoặc dấu vết tác nhân |
| Kiểm thử hợp đồng | 20-40 ví dụ | Ràng buộc JSON, gọi công cụ, trích dẫn, định dạng, media hoặc độ trễ |
| Đầu dò red-team | 20-50 ví dụ | An toàn, quyền riêng tư, jailbreak, thương hiệu, ảo giác và hành vi từ chối |
Hướng dẫn eval của OpenAI xem eval như các bài kiểm thử có cấu trúc với bộ dữ liệu, bộ chấm điểm và các lần chạy. Hướng dẫn kiểm thử của Anthropic bắt đầu từ tiêu chí thành công và các ca kiểm thử. Quy trình đánh giá dựa trên tính toán của Google cũng xem đánh giá như một quy trình lặp lại thay vì một phiên chat tùy hứng. Bài học chung rất đơn giản: một mô hình mới nên đối mặt với bộ kiểm thử, không phải một lần cảm nhận chung chung.
Nếu bạn đã có một khung eval, hãy dùng nó. Nếu chưa, một bảng tính cộng với các script quyết định được là đủ cho 48 giờ đầu tiên.
Thêm các cột sau:
| Cột | Ví dụ |
|---|---|
case_id |
support_refund_017 |
workflow |
support_answer |
input |
Câu hỏi của người dùng, vết tích công cụ, tài liệu, prompt hoặc đặc tả phương tiện |
expected_behavior |
Những gì một câu trả lời tốt phải làm |
hard_fail_conditions |
Thiếu trích dẫn, JSON sai, lời khuyên không an toàn, sai ngôn ngữ |
baseline_output |
Kết quả tuyến hiện tại |
new_model_output |
Kết quả ứng viên |
accepted_baseline |
có/không |
accepted_new_model |
có/không |
reviewer_notes |
Vì sao nó đạt hoặc thất bại |
Đừng tối ưu hóa quá mức bộ khung vào ngày ra mắt. Đồng hồ ra mắt mô hình đang chạy. Bạn cần đủ cấu trúc để không tự đánh lừa mình.
Giờ 8-14: chạy kiểm thử khói trước khi kiểm thử chất lượng
Lần chạy đầu tiên không phải về chất lượng. Nó là về việc liệu mô hình có thể được gọi, định tuyến, tính phí, ghi log và phân tích cú pháp mà không làm hỏng sản phẩm hay không.
Chạy các kiểm thử khói sau:
- Xác thực: khóa, base URL và tên mô hình hoạt động từ một môi trường sạch.
- Tương thích điểm cuối: mô hình hỗ trợ điểm cuối mà ứng dụng của bạn gọi.
- Dạng yêu cầu: thông điệp hệ thống, đầu vào đa phương thức, công cụ, định dạng phản hồi, số token tối đa, streaming và các tham số an toàn hoạt động như mong đợi.
- Hợp đồng đầu ra: JSON, XML, Markdown, trích dẫn, lệnh gọi công cụ hoặc đầu ra tệp bắt buộc có thể được phân tích cú pháp.
- Phong bì lỗi: timeout, 400, 429 và lỗi của nhà cung cấp được ánh xạ gọn gàng vào chính sách thử lại của bạn.
- Ghi log: ID yêu cầu, ID mô hình, đơn vị đầu vào/đầu ra, độ trễ, trạng thái và các trường chi phí được ghi lại.
- Khôi phục: tuyến cũ có thể được khôi phục mà không cần thay đổi mã.
Đối với người dùng Flatkey, hãy bắt đầu với thư mục mô hình và cùng mẫu base URL tương thích OpenAI mà bạn dùng trong sản xuất. Nếu mô hình ứng viên chưa được xác nhận trong thư mục mô hình trực tiếp, đừng ngụ ý rằng nó khả dụng trong bài viết, sản phẩm hoặc ghi chú phát hành. Hãy coi đó là một tuyến đang chờ và giữ bản ghi nhớ quyết định ở trạng thái "tiếp tục kiểm thử."
Giờ 14-24: chấm điểm chất lượng tác vụ so với đường cơ sở
Bây giờ hãy so sánh mô hình mới với tuyến hiện tại của bạn.
Hãy dùng đánh giá theo cặp. Với mỗi trường hợp, hiển thị đầu ra baseline và đầu ra ứng viên cạnh nhau. Ẩn tên mô hình nếu người đánh giá có thể bị thiên lệch bởi câu chuyện ra mắt.
Chỉ chấm những gì quan trọng đối với quy trình làm việc đã chọn:
| Tiêu chí | 0 | 1 | 2 |
|---|---|---|---|
| Hoàn thành nhiệm vụ | Không đáp ứng nhu cầu của người dùng | Giải quyết một phần | Giải quyết được |
| Tính xác thực | Không được hỗ trợ hoặc sai | Không chắc chắn nhỏ | Đủ có cơ sở để ra mắt |
| Tuân thủ định dạng | Vi phạm hợp đồng | Cần sửa chữa | Đầu ra hợp lệ |
| Sử dụng công cụ/trích dẫn | Thiếu hoặc sai | Dùng được sau khi chỉnh sửa | Đúng và đầy đủ |
| Công sức của người dùng | Nhiều việc hơn mức cơ bản | Tương tự | Ít việc hơn mức cơ bản |
| Độ phù hợp với thương hiệu/sản phẩm | Giọng điệu không thể dùng | Chấp nhận được | Tốt hơn mức cơ bản |
Sau đó chuyển điểm thành tỷ lệ chấp nhận:
accepted_output_rate =
accepted_outputs / total_cases
candidate_lift =
candidate_accepted_output_rate - baseline_accepted_output_rate
Đây là chỗ nhiều bài kiểm tra ngày ra mắt đi sai hướng. Giá token thì dễ thấy, nhưng đầu ra được chấp nhận mới là thứ được triển khai. Một mô hình rẻ hơn 30 phần trăm trên mỗi token vẫn có thể đắt hơn nếu nó thất bại gấp đôi, cần các prompt sửa lỗi, hoặc tạo ra đầu ra bị người duyệt từ chối.
Với phương pháp luận rộng hơn, HELM là lời nhắc hữu ích rằng đánh giá mô hình nên xem xét nhiều hơn độ chính xác. Nó thảo luận các kịch bản và chỉ số như độ bền vững, công bằng, độc hại, hiệu chỉnh và hiệu quả. Phiên bản 48 giờ của bạn sẽ nhỏ hơn, nhưng vẫn nên đa chỉ số.
Gio 24-30: kiem tra hop dong, cong cu va cac ria dinh tuyen
Hầu hết các lỗi sản xuất không trông giống như "câu trả lời tệ." Chúng trông như:
- Lược đồ JSON lỗi trên 7 phần trăm yêu cầu.
- Một lời gọi công cụ âm thầm bỏ sót đối số bắt buộc.
- Mô hình từ chối một tác vụ an toàn mà sản phẩm của bạn phải hỗ trợ.
- Mô hình bỏ qua các ràng buộc về ngôn ngữ hoặc miền địa phương.
- Mô hình lạm dụng đầu ra suy luận dài và phá vỡ mục tiêu độ trễ.
- Một tuyến dự phòng làm thay đổi hình dạng phản hồi.
- Một mô hình đa phương tiện mới trả về tỷ lệ khung hình, thời lượng hoặc trường trạng thái tệp khác.
Chạy bộ kiểm tra hợp đồng trước khi bạn ăn mừng một chiến thắng về chất lượng.
contract_pass_rate =
valid_contract_outputs / total_contract_cases
fallback_mismatch_rate =
fallback_outputs_with_contract_or_semantic_mismatch / fallback_cases
Nếu mô hình chỉ tốt hơn khi mọi thứ diễn ra suôn sẻ, nó chưa sẵn sàng cho định tuyến sản xuất. Nó vẫn có thể hữu ích sau một cờ tính năng, trong quy trình xem xét thủ công, hoặc như một ứng viên dự phòng, nhưng bản ghi quyết định nên nói rõ điều đó.
Gio 30-36: chuan hoa do tre, gioi han va chi phi
Một mô hình mới có thể thất bại về mặt bài toán kinh doanh ngay cả khi nó thắng trong đánh giá định tính.
Ghi nhận:
| Chỉ số | Vì sao nó quan trọng |
|---|---|
| độ trễ p50 và p90 | Người dùng trải nghiệm phần đuôi chậm, không phải bản demo trung bình |
| tỷ lệ timeout | Phản hồi chậm có thể trở thành lỗi sản phẩm |
| tỷ lệ thử lại | Các lần thử lại làm tăng độ trễ và chi phí |
| tỷ lệ 429/giới hạn tốc độ | Nhu cầu trong ngày ra mắt có thể vượt quá hạn mức thực tế |
| mức sử dụng ngữ cảnh | Ngữ cảnh lớn có thể che giấu chi phí prompt tăng vọt ngoài kiểm soát |
| độ dài đầu ra | Các mô hình dài dòng có thể đắt hơn trên mỗi kết quả được chấp nhận |
| chi phí đầu ra được chấp nhận | Mẫu số thực sự dành cho các nhóm sản phẩm |
Hãy dùng công thức chi phí này:
cost_per_accepted_output =
total_candidate_cost / accepted_candidate_outputs
Sau đó so sánh nó với đường cơ sở:
cost_delta =
candidate_cost_per_accepted_output - baseline_cost_per_accepted_output
Đừng phê duyệt một mô hình chỉ vì giá trên mỗi token đầu vào nhìn có vẻ tốt hơn. Hãy phê duyệt nó vì chi phí đầu ra được chấp nhận, độ tin cậy và chất lượng sản phẩm phù hợp với nhau.
Giờ 36-42: chạy lưu lượng shadow hoặc replay lưu lượng
Nếu mô hình vượt qua đánh giá ngoại tuyến, hãy chạy replay hoặc shadow traffic trước canary.
Replay traffic nghĩa là bạn chạy các yêu cầu lịch sử qua mô hình mới và so sánh đầu ra mà không ảnh hưởng đến người dùng. Shadow traffic nghĩa là các yêu cầu trực tiếp được sao chép sang tuyến mới, nhưng người dùng vẫn nhận đầu ra của baseline.
Với mỗi yêu cầu được shadow, hãy ghi lại:
- Phân khúc người dùng hoặc quy trình làm việc.
- Mô hình baseline và mô hình ứng viên.
- ID yêu cầu.
- Kích thước đầu vào và kích thước đầu ra.
- Độ trễ.
- Loại lỗi.
- Tính hợp lệ của hợp đồng.
- Chi phí.
- Sự chấp nhận của người đánh giá hoặc tự động.
- Bất kỳ cờ an toàn hoặc quyền riêng tư nào.
Đây là lúc một gateway hoặc router trở nên hữu dụng. Bài viết Cách đánh giá một mô hình mới trong 48 giờ: Danh sách kiểm tra ngày ra mắt giả định rằng nhóm của bạn có thể chuyển tuyến mà không cần viết lại ứng dụng mỗi lần. Nếu bạn dùng Flatkey, hãy giữ ứng dụng trỏ tới lớp tương thích OpenAI ổn định, kiểm tra tên mô hình và chính sách trong một tuyến được kiểm soát, và xem xét các bản ghi sử dụng trước khi canary.
Giờ 42-48: chỉ canary nếu các quy tắc dừng thật rõ ràng
Canary không phải là "bật nó cho 10 phần trăm rồi theo dõi Slack." Canary là một bài kiểm tra sản xuất có kiểm soát với quy tắc rollback.
Hãy dùng kế hoạch canary tối thiểu này:
| Trường | Ví dụ |
|---|---|
| Phạm vi | 2 phần trăm người dùng beta đã đăng nhập trên một quy trình làm việc |
| Thời lượng | 2 giờ hoặc 1.000 yêu cầu, tùy điều kiện nào đến trước |
| Rào chắn | Tỷ lệ lỗi thấp hơn baseline cộng 1 điểm phần trăm |
| Cổng hợp đồng | Tỷ lệ lỗi phân tích cú pháp JSON dưới 0,5 phần trăm |
| Cổng an toàn | Không có sự cố an toàn nghiêm trọng nào chưa được giải quyết |
| Cổng chi phí | Chi phí đầu ra được chấp nhận không cao hơn baseline quá 10 phần trăm trừ khi việc nâng chất lượng được phê duyệt |
| Người chịu trách nhiệm rollback | Kỹ sư trực on-call |
| Người chịu trách nhiệm quyết định | PM cộng với lead kỹ thuật |
Canary nên tạo ra một trong bốn quyết định:
- Không triển khai: ứng viên không vượt qua một ngưỡng chặn cứng.
- Tiếp tục kiểm thử: có triển vọng nhưng chưa đủ an toàn cho môi trường sản xuất.
- Triển khai hạn chế: hữu ích cho một phân khúc hoặc quy trình làm việc hẹp.
- Triển khai với chính sách định tuyến: là lựa chọn tốt nhất cho khối lượng công việc đã kiểm thử, với các điều kiện rollback được ghi rõ.
Thẻ điểm trong ngày ra mắt
Sao chép thẻ điểm này vào bản ghi nhớ quyết định.
| Khía cạnh | Trọng số | Cơ sở | Ứng viên | Ghi chú quyết định |
|---|---|---|---|---|
| Tỷ lệ đầu ra được chấp nhận | 25 | |||
| Tỷ lệ vượt qua hợp đồng | 20 | |||
| Tỷ lệ lỗi nghiêm trọng về an toàn | 15 | |||
| Độ trễ p90 | 10 | |||
| Hành vi 429/thử lại | 10 | |||
| Chi phí trên mỗi đầu ra được chấp nhận | 15 | |||
| Mức sẵn sàng rollback | 5 |
Quy tắc được đề xuất:
approve_for_canary =
no_hard_blockers
and candidate_accepted_output_rate >= baseline_accepted_output_rate
and candidate_contract_pass_rate >= minimum_contract_gate
and candidate_severe_failure_rate <= baseline_severe_failure_rate
and rollback_ready == true
Quy tắc này được cố ý đặt theo hướng thận trọng. Một mô hình mới có thể rất thú vị nhưng hôm nay vẫn chưa phù hợp để đưa vào sản phẩm của bạn.
Những gì nên bỏ qua trong 48 giờ đầu tiên
Bỏ qua bất kỳ thứ gì trông có vẻ chặt chẽ nhưng không làm thay đổi quyết định phát hành:
- Một bộ benchmark khổng lồ không liên quan đến sản phẩm của bạn.
- Các thử nghiệm prompt không có bộ kiểm thử cố định.
- Đánh giá so sánh trực diện không mù từ những người hâm mộ mô hình.
- So sánh giá token mà không có tỷ lệ chấp nhận.
- Lập kế hoạch di chuyển toàn bộ trước khi mô hình vượt qua các bài kiểm tra hợp đồng.
- Bản sao ra mắt công khai trước quyết định canary.
Các công cụ benchmark mở như Language Model Evaluation Harness của EleutherAI có thể hữu ích khi bạn cần các lần chạy benchmark có thể tái tạo trên nhiều tác vụ. Đối với các quyết định sản phẩm trong ngày ra mắt, hãy dùng chúng như một phần của bộ bằng chứng, chứ không phải để thay thế cho các bài kiểm thử được thiết kế theo thực tế sản xuất của riêng bạn.
Flatkey phù hợp ở đâu
Flatkey hữu ích khi một nhóm muốn quy trình đánh giá luôn gần với môi trường sản xuất:
- Sử dụng một lớp API ổn định duy nhất trong khi so sánh các tuyến mô hình.
- Kiểm tra thư mục mô hình trước khi giả định rằng một tuyến đường tồn tại.
- Giữ ID yêu cầu, mức sử dụng, chi phí và các lớp lỗi trong một sổ cái duy nhất.
- Kiểm thử chính sách fallback và rollback mà không làm phân tán các khóa nhà cung cấp.
- So sánh các mô hình theo công việc được chấp nhận, chứ không chỉ theo giá niêm yết.
CTA thực tế rất đơn giản: bắt đầu với Flatkey API quickstart, xem AI model catalog guide, và dùng bài viết AI routing API metrics để quyết định những trường telemetry nào nên bắt buộc trong bài đánh giá 48 giờ của bạn.
Nếu đội ngũ của bạn vẫn đang xây dựng khung tổng thể, hãy đọc tiếp AI Routing API Tools: Evaluation Framework for Production Teams. Nếu bạn đang thay thế nhà cung cấp, hãy dùng AI model evaluation workflow checklist như một tài liệu đồng hành dài hạn cho quá trình di chuyển.
Cau hoi thuong gap
48 giờ có đủ để đánh giá một mô hình mới không?
48 giờ không đủ để chứng minh một mô hình là lựa chọn tốt nhất cho dài hạn. Nhưng đủ để quyết định liệu mô hình đó có xứng đáng không cần hành động, cần kiểm thử thêm, shadow traffic, canary giới hạn, hay một tuyến sản xuất hẹp.
Chúng ta cần bao nhiêu ví dụ cho một bài đánh giá mô hình vào ngày ra mắt?
Đối với vòng đánh giá đầu tiên, hãy dùng 25-50 tác vụ vàng, 50-100 tác vụ sản xuất lộn xộn, 20-40 bài kiểm thử hợp đồng, và 20-50 probe red-team. Tăng quy mô bộ dữ liệu trước khi triển khai rộng.
Chúng ta nên dùng benchmark công khai hay đánh giá nội bộ?
Hãy dùng cả hai khi thời gian cho phép. Benchmark công khai cho thấy năng lực tổng quát và khả năng tái lập. Đánh giá nội bộ cho thấy mô hình có hoạt động tốt cho người dùng thực, prompt, schema, công cụ, mục tiêu độ trễ và ràng buộc chi phí của bạn hay không.
Chỉ số quan trọng nhất trong một bài đánh giá 48 giờ là gì?
Tỷ lệ đầu ra được chấp nhận thường là chỉ số tổng quan thực tế nhất vì nó kết hợp chất lượng, khả năng sử dụng và mức phù hợp với sản phẩm. Hãy ghép nó với tỷ lệ đạt kiểm tra hợp đồng, tỷ lệ lỗi nghiêm trọng, độ trễ và chi phí trên mỗi đầu ra được chấp nhận.
Đội ngũ nên so sánh chi phí mô hình vào ngày ra mắt như thế nào?
Hãy so sánh chi phí trên mỗi đầu ra được chấp nhận, không chỉ giá token. Bao gồm các lần thử lại, đầu ra bị từ chối, prompt sửa lỗi, độ dài đầu ra lớn hơn, và khối lượng xem xét thủ công nếu bạn có thể đo lường.
Khi nào một đội nên tránh canary một mô hình mới?
Hãy tránh canary khi mô hình phá vỡ các ràng buộc đầu ra cứng, gây ra lỗi an toàn nghiêm trọng, không đáp ứng được nhu cầu độ trễ hoặc giới hạn tốc độ, thiếu phạm vi rollback, hoặc không thể ghi log đủ tốt để gỡ lỗi.
Danh sách kiểm tra cuối cùng
Hãy dùng Cách đánh giá một mô hình mới trong 48 giờ: Danh sách kiểm tra ngày ra mắt như một kỷ luật để chống lại nhiễu trong ngày ra mắt.
Trước khi phê duyệt một mô hình mới để canary, hãy xác nhận:
- Khối lượng công việc hẹp và đã được đặt tên.
- Baseline đã được cố định.
- Bộ đánh giá bao gồm các trường hợp vàng, lộn xộn, hợp đồng và red-team.
- Đầu ra được chấm theo mức chấp nhận, không theo cảm tính.
- Chi phí được chuẩn hóa theo đầu ra được chấp nhận.
- Hành vi độ trễ, retry và giới hạn tốc độ được ghi log.
- Đã chạy shadow traffic hoặc replay traffic.
- Phạm vi canary và quy tắc rollback đã được viết rõ.
- Bản ghi quyết định nêu rõ: áp dụng, tiếp tục kiểm thử, triển khai giới hạn, hoặc không hành động.
Các mô hình mới sẽ tiếp tục xuất hiện. Đội thắng cuộc không phải là đội thử mọi mô hình đầu tiên. Đó là đội có thể đưa ra quyết định trong ngày ra mắt mà không làm hỏng sản phẩm.
