Câu trả lời ngắn gọn: Để đánh giá mô hình AI một cách hiệu quả, trước tiên hãy xác định "tốt" trông như thế nào đối với người dùng thực và quyết định cần đưa ra. Sau đó, xây dựng các đánh giá có thể lặp lại với dữ liệu đại diện, kiểm soát rò rỉ chặt chẽ và nhiều chỉ số đo lường. Thêm các bước kiểm tra độ bền, độ lệch và an toàn, và bất cứ khi nào có sự thay đổi (dữ liệu, lời nhắc, chính sách), hãy chạy lại hệ thống và tiếp tục giám sát sau khi triển khai.
Những điểm chính cần ghi nhớ:
Tiêu chí thành công : Xác định người dùng, quyết định, ràng buộc và các trường hợp thất bại tồi tệ nhất trước khi lựa chọn các chỉ số đo lường.
Khả năng lặp lại : Xây dựng một hệ thống đánh giá cho phép chạy lại các bài kiểm tra tương tự với mỗi thay đổi.
Vệ sinh dữ liệu : Duy trì các phân vùng ổn định, ngăn ngừa dữ liệu trùng lặp và chặn rò rỉ tính năng từ sớm.
Kiểm tra độ tin cậy : Kiểm tra độ bền vững, tính công bằng và các hành vi an toàn của LLM bằng các tiêu chí rõ ràng.
Nguyên tắc vòng đời sản phẩm : Triển khai theo từng giai đoạn, theo dõi sự thay đổi và các sự cố, đồng thời ghi lại những thiếu sót đã biết.
Những bài viết bạn có thể muốn đọc sau bài này:
🔗 Đạo đức AI là gì
Khám phá các nguyên tắc định hướng thiết kế, sử dụng và quản trị trí tuệ nhân tạo một cách có trách nhiệm.
🔗 Thiên kiến trong trí tuệ nhân tạo là gì?
Tìm hiểu cách dữ liệu thiên vị làm sai lệch các quyết định và kết quả của AI.
🔗 Khả năng mở rộng AI là gì
Hiểu rõ cách mở rộng quy mô hệ thống AI để tối ưu hiệu suất, chi phí và độ tin cậy.
🔗 Trí tuệ nhân tạo là gì?
Tổng quan rõ ràng về trí tuệ nhân tạo, các loại và ứng dụng thực tiễn.
1) Hãy bắt đầu với định nghĩa không mấy hào nhoáng về từ "tốt"
Trước khi có số liệu, trước khi có bảng điều khiển, trước khi so sánh hiệu suất - hãy xác định xem thành công được định nghĩa như thế nào.
Làm rõ:
-
Người dùng: nhà phân tích nội bộ, khách hàng, bác sĩ lâm sàng, tài xế, một nhân viên hỗ trợ mệt mỏi lúc 4 giờ chiều…
-
Quyết định: phê duyệt khoản vay, báo cáo gian lận, đề xuất nội dung, tóm tắt ghi chú.
-
Những thất bại quan trọng nhất:
-
Kết quả dương tính giả (gây khó chịu) so với kết quả âm tính giả (nguy hiểm)
-
-
Các ràng buộc: độ trễ, chi phí mỗi yêu cầu, quy tắc bảo mật, yêu cầu về khả năng giải thích, khả năng truy cập
Đây là giai đoạn mà các nhóm thường sa đà vào việc tối ưu hóa "các chỉ số đẹp mắt" thay vì "kết quả có ý nghĩa". Điều này xảy ra rất thường xuyên. Thật sự là rất thường xuyên.
Một cách chắc chắn để duy trì nhận thức rủi ro này (và không dựa trên cảm tính) là xây dựng thử nghiệm xoay quanh độ tin cậy và quản lý rủi ro vòng đời, giống như cách NIST thực hiện trong Khung quản lý rủi ro AI (AI RMF 1.0) [1].
2) Điều gì tạo nên một phiên bản tốt của "hướng dẫn kiểm thử mô hình AI" ✅
Một phương pháp kiểm thử hiệu quả cần có một vài nguyên tắc bất di bất dịch:
-
Dữ liệu mang tính đại diện (không chỉ là dữ liệu thí nghiệm sạch)
-
Các khe hở trong suốt với chức năng chống rò rỉ (sẽ nói chi tiết hơn ở phần sau)
-
Đường cơ sở (các mô hình đơn giản mà bạn nên đánh bại - các ước lượng giả tồn tại vì một lý do [4])
-
Nhiều chỉ số khác nhau (vì một con số duy nhất có thể đánh lừa bạn, một cách lịch sự, ngay trước mặt bạn)
-
Kiểm tra khả năng chịu tải (các trường hợp ngoại lệ, dữ liệu đầu vào bất thường, các kịch bản mang tính đối kháng)
-
Các vòng đánh giá của con người (đặc biệt đối với các mô hình tạo sinh)
-
Giám sát sau khi ra mắt (vì thế giới thay đổi, đường ống bị hỏng và người dùng… sáng tạo [1])
Ngoài ra: một cách tiếp cận tốt bao gồm việc ghi lại những gì bạn đã thử nghiệm, những gì bạn chưa thử nghiệm và những gì bạn lo lắng. Phần "những gì tôi lo lắng" nghe có vẻ gượng gạo - và đó cũng là nơi mà sự tin tưởng bắt đầu được xây dựng.
Hai mô hình ghi chép tài liệu giúp các nhóm luôn duy trì sự minh bạch:
-
Thẻ mô hình (mô hình dùng để làm gì, nó được đánh giá như thế nào, nó thất bại ở đâu) [2]
-
Bảng dữ liệu cho các tập dữ liệu (dữ liệu là gì, được thu thập như thế nào, nên/không nên sử dụng cho mục đích gì) [3]
3) Thực tế về công cụ: những gì mọi người sử dụng trong thực tế 🧰
Công cụ là tùy chọn. Thói quen đánh giá tốt thì không thể thiếu.
Nếu bạn muốn một cách sắp xếp thực tế, hầu hết các nhóm sẽ chia thành ba nhóm:
-
Theo dõi thí nghiệm (các lần chạy, cấu hình, kết quả)
-
Bộ công cụ đánh giá (các bài kiểm tra ngoại tuyến có thể lặp lại + bộ kiểm tra hồi quy)
-
Giám sát (tín hiệu thay đổi đột ngột, chỉ số hiệu suất, cảnh báo sự cố)
Một số ví dụ bạn sẽ thấy rất nhiều trong thực tế (không phải là sự chứng thực, và đúng vậy - tính năng/giá cả có thể thay đổi): MLflow, Weights & Biases, Great Expectations, Evidently, Deepchecks, OpenAI Evals, TruLens, LangSmith.
Nếu bạn chỉ chọn một ý tưởng từ phần này: hãy xây dựng một bộ công cụ đánh giá có thể lặp lại . Bạn muốn "nhấn nút → nhận được kết quả có thể so sánh được", chứ không phải "chạy lại notebook và cầu nguyện".
4) Xây dựng bộ kiểm thử phù hợp (và ngăn chặn rò rỉ dữ liệu) 🚧
Một số lượng đáng kinh ngạc các người mẫu "tuyệt vời" lại vô tình gian lận.
Đối với ML tiêu chuẩn
Một vài quy tắc không mấy hấp dẫn nhưng có thể cứu vãn sự nghiệp:
-
Giữ tập huấn luyện/kiểm chứng/kiểm thử (và ghi lại logic phân chia).
-
Ngăn chặn các bản sao trùng lặp giữa các bản phân tách (cùng người dùng, cùng tài liệu, cùng sản phẩm, các bản sao gần giống nhau)
-
Hãy cảnh giác với hiện tượng rò rỉ tính năng (thông tin trong tương lai được lồng ghép vào các tính năng "hiện tại").
-
Sử dụng các đường cơ sở (ước lượng giả) để bạn không ăn mừng chiến thắng… không có gì [4]
Định nghĩa rò rỉ thông tin (phiên bản ngắn gọn): bất cứ điều gì trong quá trình huấn luyện/đánh giá cung cấp cho mô hình quyền truy cập vào thông tin mà nó không có được tại thời điểm đưa ra quyết định. Nó có thể rõ ràng ("nhãn tương lai") hoặc tinh tế ("nhóm dấu thời gian sau sự kiện").
Đối với LLM và các mô hình tạo sinh
Bạn đang xây dựng một hệ thống nhắc nhở và chính sách , chứ không chỉ là "một mô hình".
-
Tạo một bộ gợi ý vàng (nhỏ gọn, chất lượng cao, ổn định)
-
Thêm các mẫu thực tế gần đây (đã được ẩn danh và bảo mật thông tin)
-
Hãy chuẩn bị sẵn một bộ công cụ xử lý các trường hợp đặc biệt : lỗi chính tả, tiếng lóng, định dạng không chuẩn, ô nhập liệu trống, những tình huống bất ngờ liên quan đến nhiều ngôn ngữ 🌍
Một điều thực tế tôi đã chứng kiến xảy ra nhiều lần: một nhóm phát triển đưa ra kết quả kiểm thử ngoại tuyến "tốt", sau đó bộ phận hỗ trợ khách hàng nói, "Tuyệt. Nó tự tin chỉ thiếu một câu quan trọng." Giải pháp không phải là "sử dụng mô hình lớn hơn". Mà là các câu hỏi kiểm thử tốt hơn , tiêu chí đánh giá rõ ràng hơn và bộ kiểm thử hồi quy tập trung vào chính lỗi đó. Đơn giản. Hiệu quả.
5) Đánh giá ngoại tuyến: các chỉ số có ý nghĩa 📏
Số liệu thống kê rất tốt. Nhưng việc chỉ sử dụng một loại số liệu duy nhất thì không.
Phân loại (thư rác, gian lận, mục đích, phân loại ưu tiên)
Hãy sử dụng nhiều hơn là chỉ độ chính xác.
-
Độ chính xác, khả năng nhớ lại, F1
-
Điều chỉnh ngưỡng (ngưỡng mặc định của bạn hiếm khi “chính xác” đối với chi phí của bạn) [4]
-
Ma trận nhầm lẫn theo từng phân khúc (khu vực, loại thiết bị, nhóm người dùng)
Hồi quy (dự báo, định giá, chấm điểm)
-
MAE / RMSE (lựa chọn dựa trên cách bạn muốn xử lý lỗi)
-
Các bước kiểm tra mang tính chất hiệu chỉnh khi sử dụng kết quả đầu ra làm "điểm số" (điểm số có khớp với thực tế không?)
Hệ thống xếp hạng/đề xuất
-
NDCG, MAP, MRR
-
Phân tích theo loại truy vấn (đầu hay cuối)
Thị giác máy tính
-
mAP, IoU
-
Hiệu suất theo từng hạng mục (một số hạng mục hiếm hoi là nơi người mẫu khiến bạn phải xấu hổ)
Mô hình tạo sinh (LLM)
Đây là lúc mọi người bắt đầu… triết lý 😵💫
Các giải pháp thiết thực, hiệu quả trong các nhóm thực tế:
-
Đánh giá của con người (tín hiệu tốt nhất, vòng lặp chậm nhất)
-
Sự ưu tiên theo từng cặp / tỷ lệ thắng (so sánh A với B dễ hơn so với việc tính điểm tuyệt đối)
-
Các chỉ số văn bản tự động (hữu ích cho một số tác vụ, nhưng gây hiểu nhầm cho những tác vụ khác)
-
Kiểm tra dựa trên nhiệm vụ: “Nó đã trích xuất đúng các trường dữ liệu chưa?” “Nó đã tuân thủ chính sách chưa?” “Nó đã trích dẫn nguồn khi cần thiết chưa?”
Nếu bạn muốn có một điểm tham chiếu “đa số liệu, nhiều kịch bản” có cấu trúc, HELM là một điểm tựa tốt: nó thúc đẩy việc đánh giá một cách rõ ràng vượt ra ngoài độ chính xác sang các yếu tố như hiệu chuẩn, độ bền, độ lệch/độc tính và sự đánh đổi về hiệu quả [5].
Nói ngoài lề một chút: các chỉ số tự động đánh giá chất lượng bài viết đôi khi giống như việc đánh giá một chiếc bánh mì bằng cách cân nó vậy. Nó không phải là vô nghĩa, nhưng… thôi nào 🥪
6) Kiểm tra độ bền: khiến nó phải đổ mồ hôi một chút 🥵🧪
Nếu mô hình của bạn chỉ hoạt động với dữ liệu đầu vào gọn gàng, về cơ bản nó giống như một chiếc bình thủy tinh. Đẹp, dễ vỡ, đắt tiền.
Bài kiểm tra:
-
Nhiễu: lỗi chính tả, thiếu giá trị, mã Unicode không chuẩn, lỗi định dạng
-
Sự thay đổi trong phân phối: các danh mục sản phẩm mới, tiếng lóng mới, cảm biến mới
-
Các giá trị cực đoan: số nằm ngoài phạm vi, tải trọng khổng lồ, chuỗi rỗng
-
Các dữ liệu đầu vào "có phần đối nghịch" không giống với tập dữ liệu huấn luyện của bạn nhưng lại giống với dữ liệu người dùng.
Đối với chương trình LLM, cần bao gồm:
-
Các nỗ lực tấn công chèn mã độc (hướng dẫn được ẩn bên trong nội dung người dùng)
-
Các mẫu “bỏ qua các hướng dẫn trước đó”
-
Các trường hợp ngoại lệ khi sử dụng công cụ (URL không hợp lệ, hết thời gian chờ, đầu ra không đầy đủ)
Tính bền vững là một trong những thuộc tính đáng tin cậy nghe có vẻ trừu tượng cho đến khi xảy ra sự cố. Khi đó nó trở nên… rất hữu hình [1].
7) Thiên kiến, sự công bằng và lợi ích của nó đối với ai ⚖️
Một mô hình có thể "chính xác" về tổng thể nhưng lại liên tục hoạt động kém hiệu quả hơn đối với các nhóm cụ thể. Đó không phải là một lỗi nhỏ. Đó là vấn đề về sản phẩm và lòng tin.
Các bước thực hành:
-
Đánh giá hiệu quả hoạt động theo từng phân khúc có ý nghĩa (phù hợp về mặt pháp lý/đạo đức để đo lường).
-
So sánh tỷ lệ lỗi và hiệu chuẩn giữa các nhóm
-
Kiểm tra các tính năng proxy (mã bưu chính, loại thiết bị, ngôn ngữ) có thể mã hóa các đặc điểm nhạy cảm
Nếu bạn không ghi lại điều này ở đâu đó, về cơ bản bạn đang yêu cầu chính mình trong tương lai gỡ lỗi một cuộc khủng hoảng niềm tin mà không có bản đồ. Thẻ mô hình là một nơi vững chắc để đặt nó [2] và khung độ tin cậy của NIST cung cấp cho bạn một danh sách kiểm tra mạnh mẽ về những gì "tốt" thậm chí nên bao gồm [1].
8) Kiểm tra an toàn và bảo mật (đặc biệt đối với LLM) 🛡️
Nếu mô hình của bạn có thể tạo ra nội dung, bạn đang kiểm tra nhiều hơn là độ chính xác. Bạn đang kiểm tra hành vi.
Bao gồm các bài kiểm tra cho:
-
Việc tạo nội dung bị cấm (vi phạm chính sách)
-
Rò rỉ thông tin cá nhân (liệu có tiết lộ bí mật?)
-
Ảo giác trong các lĩnh vực có tính rủi ro cao
-
Từ chối quá mức (mẫu từ chối các yêu cầu thông thường)
-
Các hành vi độc hại và quấy rối
-
Các nỗ lực lọc dữ liệu thông qua việc tiêm nhắc nhở
Một cách tiếp cận thực tế là: xác định các quy tắc chính sách → xây dựng các câu hỏi kiểm thử → chấm điểm kết quả bằng kiểm tra thủ công và tự động → chạy lại mỗi khi có bất kỳ thay đổi nào. Phần "mỗi khi" đó chính là chi phí.
Điều này phù hợp một cách gọn gàng với tư duy rủi ro vòng đời: quản lý, lập bản đồ bối cảnh, đo lường, quản lý, lặp lại [1].
9) Thử nghiệm trực tuyến: triển khai theo từng giai đoạn (nơi sự thật được phơi bày) 🚀
Các bài kiểm tra trực tiếp là cần thiết. Tiếp xúc trực tuyến là nơi thực tế hiện ra, với đôi giày lấm lem bùn đất.
Bạn không cần phải cầu kỳ. Bạn chỉ cần có kỷ luật:
-
Chạy ở chế độ ẩn (mô hình vẫn chạy, không ảnh hưởng đến người dùng)
-
Triển khai dần dần (ban đầu với lưu lượng truy cập nhỏ, sau đó mở rộng nếu hoạt động tốt)
-
Theo dõi kết quả và sự cố (khiếu nại, leo thang vấn đề, vi phạm chính sách)
Ngay cả khi bạn không thể nhận được nhãn ngay lập tức, bạn vẫn có thể theo dõi tín hiệu proxy và tình trạng hoạt động (độ trễ, tỷ lệ lỗi, chi phí). Điểm chính: bạn muốn có một cách kiểm soát để phát hiện lỗi trước khi toàn bộ người dùng của bạn phát hiện ra [1].
10) Giám sát sau khi triển khai: sự thay đổi, suy giảm và lỗi âm thầm 📉👀
Mô hình bạn thử nghiệm không phải là mô hình bạn sẽ sử dụng lâu dài. Dữ liệu thay đổi. Người dùng thay đổi. Thế giới thay đổi. Hệ thống có thể gặp sự cố lúc 2 giờ sáng. Bạn biết đấy…
Màn hình:
-
Sự thay đổi dữ liệu đầu vào (thay đổi lược đồ, dữ liệu thiếu, sự dịch chuyển phân bố)
-
Sự thay đổi kết quả đầu ra (sự thay đổi cân bằng lớp học, sự thay đổi điểm số)
-
Các chỉ số thay thế cho hiệu năng (vì độ trễ ghi nhãn là có thật)
-
Các tín hiệu phản hồi (biểu tượng ngón tay cái hướng xuống, chỉnh sửa lại, khiếu nại)
-
Các phép hồi quy cấp phân đoạn (những kẻ giết người thầm lặng)
Và hãy đặt ngưỡng cảnh báo không quá nhạy. Một thiết bị giám sát liên tục báo động sẽ bị bỏ qua - giống như còi báo động xe hơi trong thành phố vậy.
Vòng lặp “giám sát + cải thiện theo thời gian” này không phải là tùy chọn nếu bạn quan tâm đến độ tin cậy [1].
11) Một quy trình làm việc thực tế bạn có thể sao chép 🧩
Đây là một vòng lặp đơn giản có thể mở rộng quy mô:
-
Xác định các chế độ thành công + thất bại (bao gồm chi phí/độ trễ/an toàn) [1]
-
Tạo tập dữ liệu:
-
bộ vàng
-
gói vỏ cạnh
-
Các mẫu thực tế gần đây (bảo mật thông tin cá nhân)
-
-
Chọn các chỉ số:
-
số liệu nhiệm vụ (F1, MAE, tỷ lệ thắng) [4][5]
-
số liệu an toàn (tỷ lệ thông qua chính sách) [1][5]
-
các chỉ số hoạt động (độ trễ, chi phí)
-
-
Xây dựng một bộ công cụ đánh giá (chạy trên mọi thay đổi mô hình/lời nhắc) [4][5]
-
Thêm các bài kiểm tra căng thẳng + các bài kiểm tra gần giống đối thủ [1][5]
-
Đánh giá của con người đối với một mẫu (đặc biệt là đối với đầu ra LLM) [5]
-
Vận chuyển thông qua bóng tối + triển khai theo từng giai đoạn [1]
-
Theo dõi + cảnh báo + đào tạo lại với kỷ luật [1]
-
Kết quả tài liệu được viết theo kiểu thẻ mẫu [2][3]
Đào tạo thì hào nhoáng. Kiểm tra thì chỉ để trả tiền thuê nhà.
12) Lời kết + Tóm tắt nhanh 🧠✨
Nếu bạn chỉ nhớ một vài điều về cách kiểm thử mô hình AI :
-
Sử dụng dữ liệu thử nghiệm đại diện và tránh rò rỉ [4]
-
Chọn nhiều số liệu gắn liền với kết quả thực tế [4][5]
-
Đối với LLM, hãy dựa vào đánh giá của con người + so sánh theo kiểu tỷ lệ thắng [5]
-
Độ bền của thử nghiệm - đầu vào bất thường là đầu vào bình thường được ngụy trang [1]
-
Triển khai một cách an toàn và theo dõi, vì các mô hình có thể thay đổi và đường ống bị đứt [1]
-
Ghi lại những gì bạn đã làm và những gì bạn chưa thử (khó chịu nhưng hiệu quả) [2][3]
Kiểm thử không chỉ đơn thuần là "chứng minh nó hoạt động". Mà còn là "tìm ra lỗi trước khi người dùng phát hiện ra". Và đúng vậy, điều đó nghe có vẻ kém hấp dẫn hơn - nhưng đó là phần giúp hệ thống của bạn đứng vững khi mọi thứ trở nên lung lay… 🧱🙂
Câu hỏi thường gặp
Cách tốt nhất để kiểm tra các mô hình AI sao cho phù hợp với nhu cầu thực tế của người dùng là gì?
Hãy bắt đầu bằng cách định nghĩa "tốt" dựa trên trải nghiệm thực tế của người dùng và quyết định mà mô hình hỗ trợ, chứ không chỉ là một chỉ số trên bảng xếp hạng. Xác định các chế độ lỗi có chi phí cao nhất (sai dương tính so với sai âm tính) và nêu rõ các ràng buộc cứng như độ trễ, chi phí, quyền riêng tư và khả năng giải thích. Sau đó, chọn các chỉ số và trường hợp thử nghiệm phản ánh những kết quả đó. Điều này giúp bạn tránh việc tối ưu hóa một "chỉ số đẹp" mà không bao giờ dẫn đến một sản phẩm tốt hơn.
Xác định tiêu chí thành công trước khi lựa chọn các chỉ số đánh giá
Hãy ghi rõ người dùng là ai, mô hình cần hỗ trợ quyết định nào và "tình huống xấu nhất" khi vận hành thực tế sẽ ra sao. Thêm các ràng buộc về mặt vận hành như độ trễ chấp nhận được và chi phí mỗi yêu cầu, cùng với các nhu cầu quản trị như quy tắc bảo mật và chính sách an toàn. Khi những điều đó đã rõ ràng, các chỉ số sẽ trở thành cách để đo lường đúng thứ cần đo. Nếu không có khung phân tích như vậy, các nhóm thường có xu hướng tối ưu hóa bất cứ thứ gì dễ đo lường nhất.
Ngăn ngừa rò rỉ dữ liệu và gian lận vô tình trong quá trình đánh giá mô hình
Giữ ổn định các tập dữ liệu huấn luyện/kiểm định/thử nghiệm và ghi lại logic phân chia để kết quả luôn có thể tái tạo. Chủ động chặn các dữ liệu trùng lặp và gần trùng lặp giữa các tập dữ liệu (cùng người dùng, tài liệu, sản phẩm hoặc các mẫu lặp lại). Cẩn thận với hiện tượng rò rỉ thông tin, nơi thông tin "tương lai" lọt vào dữ liệu đầu vào thông qua dấu thời gian hoặc các trường sau sự kiện. Một đường cơ sở vững chắc (ngay cả các ước lượng giả) giúp bạn nhận ra khi nào bạn đang bỏ qua những dữ liệu nhiễu.
Bộ công cụ đánh giá cần bao gồm những gì để đảm bảo các bài kiểm tra có thể lặp lại được ngay cả khi có thay đổi?
Một công cụ kiểm thử thực tiễn sẽ chạy lại các bài kiểm tra tương đương trên mọi mô hình, lời nhắc hoặc thay đổi chính sách bằng cách sử dụng cùng một tập dữ liệu và quy tắc chấm điểm. Nó thường bao gồm một bộ kiểm thử hồi quy, bảng điều khiển số liệu rõ ràng và các cấu hình cũng như hiện vật được lưu trữ để dễ dàng truy vết. Đối với các hệ thống LLM, nó cũng cần một "bộ chuẩn" các lời nhắc ổn định cộng với một bộ xử lý các trường hợp ngoại lệ. Mục tiêu là "nhấn nút → kết quả tương đương", chứ không phải "chạy lại notebook và cầu nguyện"
Các chỉ số để kiểm tra mô hình AI ngoài độ chính xác
Hãy sử dụng nhiều chỉ số đo lường, vì một con số duy nhất có thể che giấu những sự đánh đổi quan trọng. Đối với phân loại, hãy kết hợp độ chính xác/độ thu hồi/F1 với việc điều chỉnh ngưỡng và ma trận nhầm lẫn theo từng phân đoạn. Đối với hồi quy, hãy chọn MAE hoặc RMSE dựa trên cách bạn muốn xử phạt lỗi và thêm các kiểm tra kiểu hiệu chuẩn khi đầu ra hoạt động giống như điểm số. Đối với xếp hạng, hãy sử dụng NDCG/MAP/MRR và phân tích theo truy vấn đầu so với đuôi để phát hiện hiệu suất không đồng đều.
Đánh giá kết quả đầu ra của LLM khi các chỉ số tự động không đạt yêu cầu
Hãy coi nó như một hệ thống dựa trên lời nhắc và chính sách, chấm điểm hành vi chứ không chỉ dựa trên sự tương đồng về văn bản. Nhiều nhóm kết hợp đánh giá của con người với sự ưu tiên theo cặp (tỷ lệ thắng A/B), cùng với các kiểm tra dựa trên nhiệm vụ như "nó đã trích xuất đúng các trường chưa" hoặc "nó đã tuân thủ chính sách chưa". Các chỉ số văn bản tự động có thể hữu ích trong những trường hợp cụ thể, nhưng chúng thường bỏ sót những gì người dùng quan tâm. Các tiêu chí rõ ràng và bộ kiểm thử hồi quy thường quan trọng hơn một điểm số duy nhất.
Cần chạy các bài kiểm tra độ bền để đảm bảo mô hình không bị lỗi khi gặp dữ liệu đầu vào nhiễu
Kiểm tra độ bền của mô hình bằng cách xử lý lỗi chính tả, giá trị thiếu, định dạng lạ và Unicode không chuẩn, vì người dùng thực tế hiếm khi gọn gàng. Thêm các trường hợp thay đổi phân phối như danh mục mới, tiếng lóng, cảm biến hoặc mẫu ngôn ngữ. Bao gồm các giá trị cực đoan (chuỗi rỗng, tải trọng lớn, số nằm ngoài phạm vi) để làm nổi bật hành vi dễ bị lỗi. Đối với LLM, cũng kiểm tra các mẫu chèn lời nhắc và các lỗi khi sử dụng công cụ như hết thời gian chờ hoặc đầu ra không đầy đủ.
Kiểm tra các vấn đề về thiên vị và công bằng mà không sa đà vào lý thuyết
Đánh giá hiệu suất trên các phân khúc dữ liệu có ý nghĩa và so sánh tỷ lệ lỗi cũng như độ chính xác giữa các nhóm khi việc đo lường là phù hợp về mặt pháp lý và đạo đức. Tìm kiếm các đặc điểm gián tiếp (như mã bưu chính, loại thiết bị hoặc ngôn ngữ) có thể mã hóa các đặc điểm nhạy cảm một cách gián tiếp. Một mô hình có thể trông "chính xác tổng thể" trong khi vẫn liên tục thất bại đối với các nhóm cụ thể. Ghi lại những gì bạn đã đo lường và những gì bạn chưa đo lường, để những thay đổi trong tương lai không âm thầm gây ra sự suy giảm hiệu suất.
Các bài kiểm tra an toàn và bảo mật bao gồm cả cho hệ thống AI tạo sinh và LLM
Kiểm tra việc tạo nội dung không được phép, rò rỉ thông tin cá nhân, ảo giác trong các lĩnh vực có rủi ro cao và việc từ chối quá mức khi mô hình chặn các yêu cầu thông thường. Bao gồm cả các nỗ lực chèn lời nhắc và đánh cắp dữ liệu, đặc biệt khi hệ thống sử dụng các công cụ hoặc truy xuất nội dung. Một quy trình làm việc hiệu quả là: xác định các quy tắc chính sách, xây dựng một bộ lời nhắc thử nghiệm, chấm điểm bằng kiểm tra thủ công và tự động, và chạy lại bất cứ khi nào lời nhắc, dữ liệu hoặc chính sách thay đổi. Tính nhất quán là cái giá bạn phải trả.
Triển khai và giám sát các mô hình AI sau khi ra mắt để phát hiện sự sai lệch và các sự cố
Sử dụng các mô hình triển khai theo từng giai đoạn như chế độ ẩn và tăng lưu lượng truy cập dần dần để phát hiện lỗi trước khi toàn bộ người dùng gặp sự cố. Giám sát sự thay đổi đầu vào (thay đổi lược đồ, dữ liệu thiếu, sự dịch chuyển phân phối) và sự thay đổi đầu ra (sự dịch chuyển điểm số, sự dịch chuyển cân bằng lớp), cùng với tình trạng hoạt động như độ trễ và chi phí. Theo dõi các tín hiệu phản hồi như chỉnh sửa, leo thang vấn đề và khiếu nại, đồng thời theo dõi sự suy giảm ở cấp độ phân đoạn. Khi có bất kỳ thay đổi nào, hãy chạy lại cùng một bộ kiểm tra và tiếp tục giám sát liên tục.
Tài liệu tham khảo
[1] NIST - Khung quản lý rủi ro trí tuệ nhân tạo (AI RMF 1.0) (PDF)
[2] Mitchell và cộng sự - “Thẻ mô hình để báo cáo mô hình” (arXiv:1810.03993)
[3] Gebru và cộng sự - “Bảng dữ liệu cho tập dữ liệu” (arXiv:1803.09010)
[4] scikit-learn - Tài liệu “Lựa chọn và đánh giá mô hình”
[5] Liang và cộng sự - “Đánh giá toàn diện các mô hình ngôn ngữ” (arXiv:2211.09110)