Cách đọc điểm đánh giá trước khi chọn mô hình AI

Đọc benchmark AI cùng điều kiện thử và chi phí mỗi kết quả hữu ích. Tạo phép so sánh nhỏ cho công việc, tính cả lỗi, chỉnh sửa và thời gian cần để kiểm tra đầu ra.

Ngày đăng bản gốc · · JKook · Cập nhật bản dịch · Đọc bản gốc tiếng Anh

Các dãy tủ máy chủ tạo thành siêu máy tính Pleiades tại Trung tâm Nghiên cứu NASA Ames
Siêu máy tính Pleiades của NASA tại Trung tâm Nghiên cứu Ames, được chụp vào ngày 8 tháng 10 năm 2008. Hình ảnh nghiên cứu điện toán lưu trữ. Minh họa cơ sở hạ tầng điện toán; nó không mô tả các mô hình AI hoặc các bài kiểm tra chuẩn được thảo luận trong bài luận. Marco Librero / NASA Ames Research Center, via Wikimedia Commons · Public domain — U.S. government work (NASA) · Nguồn và giấy phép hình ảnh

Bảng xếp hạng làm cho một lựa chọn phức tạp trông đơn giản một cách dễ chịu. Tìm điểm cao nhất, chọn mô hình đó và tiếp tục. Khó khăn quay trở lại khi nhiệm vụ thực sự đầu tiên xuất hiện với một tài liệu được định dạng kém, một hướng dẫn mơ hồ hoặc một thời hạn. Đó là nơi tôi sẽ bắt đầu so sánh: với công việc cần hoàn thành và mô tả rõ ràng về kết quả tốt sẽ trông như thế nào.

Điểm số thực sự đo lường điều gì

Một tiêu chuẩn là một tập hợp các nhiệm vụ được xác định và một phương pháp để chấm điểm các phản hồi. Giá trị của nó đến từ việc làm cho việc so sánh có thể lặp lại. Một mô hình hoạt động tốt trên các nhiệm vụ đó đã chứng minh được điều gì đó hữu ích trong những điều kiện đó. Câu hỏi tiếp theo là những điều kiện đó giống với những điều kiện bạn quan tâm đến mức nào.

Nghiên cứu HELM ban đầu của Stanford, được giới thiệu vào năm 2022, đã lập luận rằng cần đánh giá các mô hình ngôn ngữ trong các kịch bản khác nhau và bằng nhiều thước đo. Độ chính xác chỉ là một phần của phương pháp đó; hiệu quả, tính ổn định và các thuộc tính khác cũng rất quan trọng. Nghiên cứu cũ đó hữu ích ở đây vì phương pháp của nó, chứ không phải như một bảng xếp hạng sản phẩm hiện tại.

Hãy làm cho bài kiểm tra giống như một ngày thứ Ba bình thường

Giả sử bạn muốn được giúp đỡ chuyển các tin nhắn của khách hàng thành danh sách các vấn đề thường xuyên xảy ra hàng tuần. Một bài kiểm tra kiến thức tổng quát có thể không cho bạn biết nhiều về việc liệu một hệ thống có giữ nguyên ý nghĩa của khiếu nại, xử lý câu không rõ ràng hay tránh việc tự suy diễn ý định của khách hàng hay không. Bài kiểm tra của riêng bạn có thể sử dụng một tập hợp nhỏ các ví dụ không bí mật với các danh mục dự kiến được viết sẵn.

Bao gồm một ví dụ đơn giản, một ví dụ phức tạp và một trường hợp mà câu trả lời đúng là yêu cầu làm rõ. Giữ nguyên hướng dẫn và tài liệu nguồn có sẵn cho mỗi mô hình. Điều này sẽ không đưa ra phán quyết khoa học về mọi cách sử dụng có thể, nhưng nó có thể tiết lộ sự không phù hợp trước khi bạn xây dựng quy trình làm việc xung quanh nó.

Đếm thời gian dành để sửa chữa câu trả lời

Hãy xem xét một thử nghiệm minh họa với mười bản tóm tắt ngắn. Hệ thống A mất mười phút để chạy và hai mươi phút để kiểm tra và sửa chữa. Hệ thống B mất mười lăm phút để chạy và năm phút để xem xét. Nếu cả hai cuối cùng đều cho kết quả chấp nhận được, tổng thời gian làm việc là ba mươi phút cho A và hai mươi phút cho B. Phản hồi nhanh hơn ban đầu không dẫn đến công việc hoàn thành nhanh hơn.

Đây là ý tưởng đằng sau chi phí trên mỗi kết quả hữu ích. Chi phí có thể bao gồm phí đăng ký, thời gian chờ đợi, kiểm tra và hậu quả của lỗi. Những con số giả định này không phải là số liệu đo lường của bất kỳ sản phẩm cụ thể nào. Chúng cho thấy tại sao sự khác biệt nhỏ về điểm số công khai có thể ít quan trọng hơn so với một vấn đề lặp đi lặp lại trong quy trình thực tế của bạn.

Một câu trả lời trôi chảy vẫn cần bằng chứng

Hiệu chuẩn mô tả mức độ phù hợp giữa độ tin cậy được thể hiện của hệ thống với tính chính xác của nó. Đối với người đọc, vấn đề thực tế là liệu sự không chắc chắn có được thể hiện rõ ràng khi bằng chứng yếu hay không. Một câu trả lời cung cấp một con số gọn gàng mà không có bằng chứng hỗ trợ có thể khó sử dụng hơn một câu trả lời xác định được đầu vào bị thiếu.

Khung quản lý rủi ro AI tự nguyện của NIST đặt việc đánh giá trong câu hỏi rộng hơn về cách sử dụng hệ thống và những rủi ro đi kèm. Tôi rút ra một bài học nhỏ từ đó: hãy quyết định trước những đầu ra nào cần được kiểm tra độc lập, thông tin nào phải được giữ kín khỏi công cụ và điều gì sẽ khiến bạn ngừng sử dụng nó cho một nhiệm vụ cụ thể.

Hãy ghi lại một bản tóm tắt ngắn gọn về quyết định

Lưu lại phiên bản mô hình, ngày kiểm tra, hướng dẫn và một vài kết quả tiêu biểu. Xem xét lại lựa chọn khi sản phẩm hoặc công việc của bạn thay đổi đáng kể. Một ví dụ đã lưu thường cung cấp nhiều thông tin hơn là một ký ức rằng một trợ lý nào đó cảm thấy tốt hơn vài tháng trước.

Tôi thích một danh sách rút gọn được hỗ trợ bởi một quá trình thử nghiệm minh bạch. Bảng xếp hạng có thể giúp bạn tìm ra các ứng viên. Lựa chọn cuối cùng nên dựa trên việc công cụ đó có giúp bạn hoàn thành công việc thực sự của mình một cách đáng tin cậy hay không.

Chọn theo công việc cần hoàn thành

So sánh các mô hình trên các nhiệm vụ đại diện, sử dụng cùng điều kiện, và tính thời gian xem xét cùng với tốc độ phản hồi.

Điểm chuẩn cao hơn có nghĩa là mô hình đó sẽ tốt hơn cho công việc của tôi?

Đó là bằng chứng về các nhiệm vụ và điều kiện của bài kiểm tra chuẩn. Hãy thử nghiệm các ví dụ tiêu biểu từ quy trình làm việc của riêng bạn trước khi coi đó là câu trả lời chung.

Nguồn tham khảo

Ngày kiểm tra nguồn ·

Tham gia thảo luận

Bình luận được hiển thị sau khi xem xét và phê duyệt. Ý kiến khác biệt đúng chủ đề vẫn được chấp nhận.

Giới thiệu và nguyên tắc