Câu trả lời ngắn gọn: Hãy xác định "tốt" trông như thế nào đối với trường hợp sử dụng của bạn, sau đó kiểm tra với các lời nhắc đại diện, có phiên bản và các trường hợp ngoại lệ. Kết hợp các chỉ số tự động với việc chấm điểm theo tiêu chí của con người, cùng với các kiểm tra an toàn chống lại các tác nhân gây nhiễu và kiểm tra việc chèn lời nhắc. Nếu các ràng buộc về chi phí hoặc độ trễ trở nên bắt buộc, hãy so sánh các mô hình dựa trên tỷ lệ thành công của nhiệm vụ trên mỗi pound chi tiêu và thời gian phản hồi p95/p99.
Những điểm chính cần ghi nhớ:
Trách nhiệm giải trình : Chỉ định người chịu trách nhiệm rõ ràng, lưu giữ nhật ký phiên bản và chạy lại quá trình đánh giá sau bất kỳ thay đổi nào về lời nhắc hoặc mô hình.
Tính minh bạch : Hãy ghi rõ các tiêu chí thành công, các ràng buộc và chi phí thất bại trước khi bắt đầu thu thập điểm số.
Khả năng kiểm toán : Duy trì các bộ kiểm thử có thể lặp lại, các tập dữ liệu được gắn nhãn và các chỉ số độ trễ p95/p99 được theo dõi.
Khả năng tranh luận : Sử dụng các tiêu chí đánh giá của con người và quy trình khiếu nại rõ ràng đối với các kết quả gây tranh cãi.
Khả năng chống lạm dụng : Chèn lời nhắc của nhóm tấn công (red-team prompt injection), các chủ đề nhạy cảm và từ chối quá mức để bảo vệ người dùng.
Nếu bạn đang chọn mô hình cho một sản phẩm, một dự án nghiên cứu, hoặc thậm chí là một công cụ nội bộ, bạn không thể chỉ nói "nghe có vẻ thông minh" rồi đưa nó vào sử dụng (xem hướng dẫn đánh giá của OpenAI và NIST AI RMF 1.0 ). Đó là cách bạn sẽ có một chatbot tự tin giải thích cách làm nóng dĩa trong lò vi sóng. 😬
Những bài viết bạn có thể muốn đọc sau bài này:
🔗 Tương lai của AI: các xu hướng định hình thập kỷ tới.
Những đổi mới quan trọng, tác động đến việc làm và các vấn đề đạo đức cần theo dõi.
🔗 Giải thích các mô hình nền tảng trong trí tuệ nhân tạo tạo sinh dành cho người mới bắt đầu.
Tìm hiểu chúng là gì, được huấn luyện như thế nào và tại sao chúng lại quan trọng.
🔗 Tác động của AI đến môi trường và việc sử dụng năng lượng:
Khám phá lượng khí thải, nhu cầu điện năng và các cách để giảm thiểu tác động đến môi trường.
🔗 Cách thức hoạt động của công nghệ nâng cấp hình ảnh bằng AI để tạo ra những hình ảnh sắc nét hơn hiện nay.
Xem cách các mô hình thêm chi tiết, loại bỏ nhiễu và phóng to hình ảnh một cách rõ nét.
1) Định nghĩa "tốt" (tùy thuộc vào từng trường hợp, và điều đó không sao cả) 🎯
Trước khi tiến hành bất kỳ đánh giá nào, hãy xác định xem thành công trông như thế nào. Nếu không, bạn sẽ đo lường mọi thứ mà chẳng học được gì. Điều đó giống như việc mang thước dây đi chấm điểm một cuộc thi làm bánh vậy. Chắc chắn bạn sẽ có được những con số, nhưng chúng sẽ không nói lên được nhiều điều đâu 😅
Làm rõ:
-
Mục tiêu của người dùng : tóm tắt, tìm kiếm, viết, lập luận, trích xuất sự kiện.
-
Chi phí thất bại : một lời giới thiệu phim sai thì có thể gây cười; một chỉ dẫn y tế sai thì… không hề gây cười (khung rủi ro: NIST AI RMF 1.0 ).
-
Môi trường thực thi : trên thiết bị, trên đám mây, phía sau tường lửa, trong môi trường được quản lý.
-
Các ràng buộc chính : độ trễ, chi phí mỗi yêu cầu, quyền riêng tư, khả năng giải thích, hỗ trợ đa ngôn ngữ, kiểm soát giọng điệu
Một người mẫu "xuất sắc" ở công việc này có thể lại là thảm họa ở công việc khác. Đó không phải là mâu thuẫn, đó là sự thật. 🙂
2) Khung đánh giá mô hình AI mạnh mẽ trông như thế nào? 🧰
Đúng vậy, đây là phần mà mọi người thường bỏ qua. Họ lấy một công cụ đánh giá hiệu năng, chạy thử một lần rồi cho là xong. Một khung đánh giá mạnh mẽ cần có một vài đặc điểm nhất quán (ví dụ về công cụ thực tế: OpenAI Evals / hướng dẫn sử dụng OpenAI Evals ):
-
Có thể lặp lại - bạn có thể chạy lại vào tuần sau và tin tưởng vào kết quả so sánh.
-
Mang tính đại diện - nó phản ánh người dùng và nhiệm vụ thực tế của bạn (không chỉ là những thông tin vụn vặt).
-
Đa lớp - kết hợp các chỉ số tự động + đánh giá của con người + kiểm thử đối kháng
-
Có thể hành động ngay - kết quả cho bạn biết cần khắc phục điều gì, chứ không chỉ đơn thuần là "điểm số giảm xuống".
-
Chống giả mạo - tránh tình trạng "thử nghiệm giả" hoặc rò rỉ ngoài ý muốn.
-
Cần lưu tâm đến chi phí - việc đánh giá bản thân nó không nên khiến bạn phá sản (trừ khi bạn thích chịu đau đớn).
Nếu bản đánh giá của bạn không thể vượt qua được sự hoài nghi của một đồng nghiệp nói rằng “Được rồi, nhưng hãy đưa điều này vào sản xuất thực tế”, thì nó vẫn chưa hoàn thiện. Đó chính là bài kiểm tra tinh thần làm việc.
3) Cách đánh giá mô hình AI bằng cách bắt đầu với các trường hợp sử dụng cụ thể 🍰
Đây là một mẹo giúp tiết kiệm rất nhiều thời gian: chia nhỏ trường hợp sử dụng thành nhiều phần .
Thay vì nói "đánh giá mô hình", hãy nói như sau:
-
Hiểu ý định (liệu nó có đáp ứng được yêu cầu của người dùng hay không)
-
Khả năng truy xuất hoặc sử dụng ngữ cảnh (liệu nó có sử dụng thông tin được cung cấp một cách chính xác hay không)
-
Suy luận / Nhiệm vụ nhiều bước (liệu logic có được duy trì xuyên suốt các bước?)
-
Định dạng và cấu trúc (có tuân theo hướng dẫn không)
-
Đảm bảo an toàn và tuân thủ chính sách (có tránh được nội dung không an toàn không; xem NIST AI RMF 1.0 )
-
Giọng điệu và phong cách thương hiệu (liệu nó có giống như bạn muốn không)
Điều này khiến "Cách đánh giá các mô hình AI" bớt giống một bài kiểm tra lớn và giống một loạt các bài kiểm tra nhỏ hơn. Các bài kiểm tra nhỏ thì hơi khó chịu, nhưng vẫn có thể vượt qua được. 😄
4) Những điều cơ bản về đánh giá ngoại tuyến - bộ dữ liệu thử nghiệm, nhãn và những chi tiết không hào nhoáng nhưng quan trọng 📦
Đánh giá ngoại tuyến là quá trình thực hiện các bài kiểm tra có kiểm soát trước khi người dùng tương tác với bất kỳ thứ gì (mẫu quy trình làm việc: OpenAI Evals ).
Hãy xây dựng hoặc thu thập một bộ dữ liệu thử nghiệm thực sự thuộc về bạn
Một bộ kiểm thử tốt thường bao gồm:
-
Những ví dụ điển hình : các sản phẩm lý tưởng mà bạn sẽ tự hào khi xuất xưởng.
-
Các trường hợp ngoại lệ : lời nhắc không rõ ràng, dữ liệu đầu vào không gọn gàng, định dạng không mong đợi
-
Các thăm dò chế độ lỗi : các gợi ý gây ảo giác hoặc đưa ra câu trả lời không an toàn (khung kiểm thử rủi ro: NIST AI RMF 1.0 )
-
Phạm vi bao phủ đa dạng : các cấp độ kỹ năng người dùng khác nhau, phương ngữ, ngôn ngữ, lĩnh vực khác nhau.
Nếu bạn chỉ kiểm thử trên các câu hỏi "sạch", mô hình sẽ trông tuyệt vời. Nhưng sau đó, người dùng của bạn sẽ xuất hiện với những lỗi chính tả, câu chưa hoàn chỉnh và những cú nhấp chuột thiếu suy nghĩ. Chào mừng bạn đến với thực tế.
Các lựa chọn ghi nhãn (hay còn gọi là: mức độ nghiêm ngặt)
Bạn có thể gắn nhãn cho các đầu ra như sau:
-
Nhị phân : đạt/không đạt (nhanh, nghiêm ngặt)
-
Thang điểm thứ tự : 1-5 điểm chất lượng (tinh tế, chủ quan)
-
Đa thuộc tính : độ chính xác, tính đầy đủ, giọng văn, cách sử dụng trích dẫn, v.v. (tốt nhất, chậm hơn)
Đánh giá đa thuộc tính là điểm tối ưu cho nhiều đội. Nó giống như việc nếm thức ăn và đánh giá độ mặn riêng biệt với độ mềm. Nếu không, bạn chỉ nói "ngon" rồi nhún vai.
5) Các chỉ số không biết nói dối - và các chỉ số có phần nào đó nói dối 📊😅
Số liệu thống kê rất có giá trị… nhưng chúng cũng có thể là một quả bom lấp lánh. Lấp lánh khắp nơi và khó dọn dẹp.
Các họ đo lường phổ biến
-
Độ chính xác / trùng khớp hoàn toàn : rất tốt cho việc trích xuất, phân loại và các tác vụ có cấu trúc.
-
F1 / độ chính xác / độ thu hồi : hữu ích khi việc bỏ sót điều gì đó còn tệ hơn là có thêm nhiễu (định nghĩa: scikit-learn precision/recall/F-score )
-
Có sự trùng lặp về kiểu chấm điểm BLEU/ROUGE : phù hợp cho các nhiệm vụ tóm tắt, nhưng thường gây hiểu nhầm (các chỉ số gốc: BLEU và ROUGE )
-
Nhúng độ tương đồng : hữu ích cho việc khớp ngữ nghĩa, có thể thưởng cho các câu trả lời sai nhưng tương tự.
-
Tỷ lệ thành công của nhiệm vụ : “người dùng có nhận được những gì họ cần hay không” – tiêu chuẩn vàng khi được định nghĩa rõ ràng.
-
Tuân thủ các ràng buộc : tuân theo định dạng, độ dài, tính hợp lệ của JSON, tuân thủ lược đồ.
Điểm mấu chốt
Nếu nhiệm vụ của bạn không có giới hạn cụ thể (viết, lập luận, trò chuyện hỗ trợ), các chỉ số đơn lẻ có thể… không đáng tin cậy. Không phải là vô nghĩa, chỉ là không đáng tin cậy thôi. Đo lường sự sáng tạo bằng thước kẻ là điều khả thi, nhưng bạn sẽ cảm thấy ngớ ngẩn khi làm vậy. (Và có lẽ bạn cũng sẽ tự chọc vào mắt mình đấy.)
Vì vậy: hãy sử dụng các chỉ số, nhưng cần gắn chúng với đánh giá của con người và kết quả thực tế của nhiệm vụ (một ví dụ về thảo luận đánh giá dựa trên LLM + những lưu ý: G-Eval ).
6) Bảng so sánh - các lựa chọn đánh giá hàng đầu (có một vài điểm đặc biệt, vì cuộc sống vốn dĩ có những điều kỳ lạ) 🧾✨
Dưới đây là một danh sách các phương pháp đánh giá thực tiễn. Hãy kết hợp và lựa chọn. Hầu hết các nhóm đều làm như vậy.
| Công cụ / Phương pháp | Khán giả | Giá | Lý do nó hiệu quả |
|---|---|---|---|
| Bộ kiểm thử nhắc nhở được xây dựng thủ công | Sản phẩm + tiếng Anh | $ | Rất chính xác, phát hiện lỗi nhanh chóng - nhưng bạn phải duy trì nó mãi mãi 🙃 (công cụ ban đầu: OpenAI Evals ) |
| Ban chấm điểm theo tiêu chí của con người | Các nhóm có thể cử người đánh giá đi | $$ | Tốt nhất là về giọng điệu, sắc thái, "liệu con người có chấp nhận điều này không?", hơi hỗn loạn tùy thuộc vào người đánh giá |
| LLM-với-vai trò-giám-sát (kèm theo-tiêu-đề-chấm-mục) | vòng lặp nhanh | $-$$ | Nhanh chóng và có khả năng mở rộng, nhưng có thể mang tính thiên vị và đôi khi đánh giá dựa trên cảm nhận chứ không phải sự thật (nghiên cứu + các vấn đề thiên vị đã biết: G-Eval ) |
| Cuộc chạy nước rút tấn công giả lập đối kháng | An toàn + tuân thủ | $$ | Phát hiện các chế độ lỗi nghiêm trọng, đặc biệt là lỗi tấn công chèn mã nhanh - cảm giác như đang thực hiện bài kiểm tra thể lực ở phòng tập gym (tổng quan về mối đe dọa: OWASP LLM01 Prompt Injection / OWASP Top 10 for LLM Apps ) |
| Tạo bài kiểm tra tổng hợp | Nhóm ít dữ liệu | $ | Phạm vi bao phủ tuyệt vời, nhưng các lời nhắc tự động có thể quá gọn gàng, quá lịch sự… người dùng thì không lịch sự |
| Thử nghiệm A/B với người dùng thực | Sản phẩm trưởng thành | $$$ | Tín hiệu rõ ràng nhất - cũng là tín hiệu gây căng thẳng về mặt cảm xúc nhất - là khi các chỉ số biến động (hướng dẫn thực tiễn kinh điển: Kohavi và cộng sự, “Thí nghiệm có kiểm soát trên web” ). |
| Đánh giá dựa trên khả năng truy xuất (kiểm tra RAG) | Tìm kiếm + Ứng dụng Hỏi đáp | $$ | Các biện pháp “sử dụng ngữ cảnh chính xác”, giảm thiểu tình trạng tăng điểm ảo giác (Tổng quan đánh giá RAG: Đánh giá RAG: Một cuộc khảo sát ) |
| Giám sát + phát hiện sai lệch | Hệ thống sản xuất | $$-$$$ | Phát hiện sự xuống cấp theo thời gian - không gây chú ý cho đến ngày nó cứu bạn 😬 (Tổng quan về sự trôi dạt: Khảo sát về sự trôi dạt của khái niệm (PMC) ) |
Hãy lưu ý rằng giá cả được cố tình điều chỉnh linh hoạt. Chúng phụ thuộc vào quy mô, công cụ và số lượng cuộc họp mà bạn vô tình tạo ra.
7) Đánh giá của con người - vũ khí bí mật mà mọi người thường không đầu tư đủ kinh phí 👀🧑⚖️
Nếu chỉ sử dụng phương pháp đánh giá tự động, bạn sẽ bỏ sót:
-
Không phù hợp về giọng điệu ("tại sao lại mỉa mai thế?")
-
Những lỗi sai nhỏ về mặt thực tế nhưng trông rất trôi chảy
-
Những hàm ý gây hại, định kiến hoặc cách diễn đạt vụng về (khung rủi ro + thiên kiến: NIST AI RMF 1.0 )
-
Những lỗi sai trong việc tuân thủ hướng dẫn mà vẫn nghe có vẻ "thông minh"
Hãy cụ thể hóa các tiêu chí đánh giá (nếu không người đánh giá sẽ tùy tiện đưa ra ý kiến)
Tiêu chí đánh giá không tốt: “Tính hữu ích”
Tiêu chí đánh giá tốt hơn:
-
Tính chính xác : đúng sự thật dựa trên đề bài và ngữ cảnh.
-
Tính đầy đủ : bao quát các điểm cần thiết mà không lan man.
-
Rõ ràng : dễ đọc, có cấu trúc, hạn chế tối đa sự nhầm lẫn.
-
Chính sách/an toàn : tránh nội dung bị hạn chế, xử lý tốt các trường hợp từ chối (khung an toàn: NIST AI RMF 1.0 )
-
Phong cách : phù hợp với giọng nói, ngữ điệu và trình độ đọc.
-
Tính trung thực : không bịa đặt nguồn hoặc tuyên bố không có căn cứ.
Ngoài ra, thỉnh thoảng cũng nên kiểm tra sự nhất trí giữa những người đánh giá. Nếu hai người đánh giá liên tục bất đồng quan điểm, đó không phải là "vấn đề về con người", mà là vấn đề về tiêu chí đánh giá. Thông thường (những kiến thức cơ bản về độ tin cậy giữa những người đánh giá: McHugh về hệ số kappa của Cohen ).
8) Làm thế nào để đánh giá các mô hình AI về độ an toàn, độ bền và “khả năng tương tác với người dùng” 🧯🧪
Đây là phần bạn cần làm trước khi ra mắt - và sau đó tiếp tục làm, bởi vì internet không bao giờ ngủ.
Các bài kiểm tra độ bền bao gồm
-
Lỗi chính tả, tiếng lóng, ngữ pháp sai
-
Các câu hỏi gợi ý rất dài và các câu hỏi gợi ý rất ngắn
-
Hướng dẫn mâu thuẫn ("hãy ngắn gọn nhưng bao gồm mọi chi tiết")
-
Các cuộc hội thoại nhiều lượt trong đó người dùng thay đổi mục tiêu
-
Các nỗ lực tấn công chèn mã độc nhanh (“bỏ qua các quy tắc trước đó…”) (chi tiết mối đe dọa: OWASP LLM01 Prompt Injection )
-
Các chủ đề nhạy cảm cần được từ chối cẩn trọng (khung rủi ro/an toàn: NIST AI RMF 1.0 )
Đánh giá an toàn không chỉ đơn thuần là "nó có từ chối hay không"
Một người mẫu tốt cần phải:
-
Hãy từ chối các yêu cầu không an toàn một cách rõ ràng và bình tĩnh (khung hướng dẫn: NIST AI RMF 1.0 )
-
Cung cấp các giải pháp thay thế an toàn hơn khi thích hợp
-
Tránh từ chối quá nhiều yêu cầu vô hại (kết quả dương tính giả)
-
Giải quyết các yêu cầu không rõ ràng bằng cách đặt câu hỏi làm rõ (khi được phép)
Việc từ chối quá mức là một vấn đề thực sự của sản phẩm. Người dùng không thích bị đối xử như những yêu tinh đáng ngờ. 🧌 (Ngay cả khi họ thực sự là những yêu tinh đáng ngờ.)
9) Chi phí, độ trễ và thực tế vận hành - những yếu tố đánh giá mà mọi người thường quên 💸⏱️
Một mô hình có thể "tuyệt vời" nhưng vẫn không phù hợp với bạn nếu nó chậm, đắt tiền hoặc dễ hỏng hóc trong quá trình vận hành.
Đánh giá:
-
Phân bố độ trễ (không chỉ trung bình - p95 và p99 cũng quan trọng) (tại sao phân vị lại quan trọng: Sách hướng dẫn SRE của Google về giám sát )
-
Chi phí cho mỗi nhiệm vụ thành công (không phải chi phí cho mỗi token riêng lẻ)
-
Tính ổn định khi chịu tải (lỗi thời gian chờ, giới hạn tốc độ, đột biến bất thường)
-
Độ tin cậy khi gọi công cụ (nếu nó sử dụng các hàm, liệu nó có hoạt động đúng cách không)
-
Xu hướng độ dài đầu ra (một số mô hình diễn đạt dài dòng, và sự diễn đạt dài dòng tốn kém)
Một mẫu xe có hiệu năng kém hơn một chút nhưng tốc độ gấp đôi hoàn toàn có thể chiến thắng trên thực tế. Điều này nghe có vẻ hiển nhiên, nhưng nhiều người lại bỏ qua. Giống như việc mua một chiếc xe thể thao chỉ để đi chợ, rồi lại phàn nàn về không gian cốp xe vậy.
10) Một quy trình làm việc đơn giản từ đầu đến cuối mà bạn có thể sao chép (và chỉnh sửa) 🔁✅
Dưới đây là quy trình thực tiễn để đánh giá các mô hình AI mà không bị sa lầy vào những thử nghiệm vô tận:
-
Định nghĩa thành công : nhiệm vụ, ràng buộc, chi phí thất bại
-
Tạo một bộ dữ liệu thử nghiệm "cốt lõi" nhỏ : 50-200 ví dụ phản ánh cách sử dụng thực tế.
-
Thêm các tập hợp tấn công cạnh và tấn công đối kháng : các nỗ lực tiêm mã, lời nhắc không rõ ràng, thăm dò an toàn (lớp tiêm mã lời nhắc: OWASP LLM01 )
-
Thực hiện kiểm tra tự động : định dạng, tính hợp lệ của JSON, tính chính xác cơ bản (nếu có thể).
-
Tiến hành đánh giá thủ công : lấy mẫu kết quả đầu ra từ các danh mục khác nhau, chấm điểm theo thang điểm.
-
So sánh các yếu tố đánh đổi : chất lượng so với chi phí so với độ trễ so với sự an toàn
-
Thử nghiệm trong giai đoạn phát hành hạn chế : Thử nghiệm A/B hoặc triển khai theo từng giai đoạn (Hướng dẫn thử nghiệm A/B: Kohavi và cộng sự )
-
Giám sát trong quá trình sản xuất : sự thay đổi, sự suy giảm, vòng phản hồi của người dùng (tổng quan về sự thay đổi: Khảo sát về sự thay đổi khái niệm (PMC) )
-
Lặp lại : cập nhật lời nhắc, truy xuất, tinh chỉnh, thiết lập các biện pháp bảo vệ, sau đó chạy lại quá trình đánh giá (mẫu lặp lại đánh giá: hướng dẫn đánh giá của OpenAI )
Hãy lưu nhật ký phiên bản. Không phải vì nó thú vị, mà vì chính bạn trong tương lai sẽ cảm ơn bạn khi đang nhâm nhi tách cà phê và lẩm bẩm "có gì thay đổi vậy…?" ☕🙂
11) Những lỗi thường gặp (hay còn gọi là những cách mọi người vô tình tự lừa dối bản thân) 🪤
-
Đào tạo hướng tới bài kiểm tra : bạn tối ưu hóa các lời nhắc cho đến khi điểm chuẩn trông tuyệt vời, nhưng người dùng lại chịu thiệt thòi.
-
Dữ liệu đánh giá bị rò rỉ : các câu hỏi kiểm tra xuất hiện trong dữ liệu huấn luyện hoặc tinh chỉnh (ôi trời!)
-
Sùng bái chỉ số duy nhất : theo đuổi một điểm số duy nhất mà không phản ánh giá trị người dùng.
-
Bỏ qua sự thay đổi phân phối : hành vi người dùng thay đổi và mô hình của bạn âm thầm suy giảm (khung rủi ro sản xuất: Khảo sát sự thay đổi khái niệm (PMC) )
-
Đánh giá quá cao sự "thông minh" : lập luận khéo léo không quan trọng nếu nó vi phạm định dạng hoặc bịa đặt sự thật.
-
Không kiểm tra chất lượng phản hồi từ chối : "Không" có thể đúng nhưng vẫn là trải nghiệm người dùng tồi tệ.
Ngoài ra, hãy cẩn thận với các bản demo. Demo giống như đoạn giới thiệu phim. Chúng chỉ chiếu những điểm nổi bật, che giấu những phần chậm chạp, và đôi khi còn dùng nhạc kịch tính để đánh lừa người xem. 🎬
12) Tóm tắt cuối cùng về Cách đánh giá các mô hình AI 🧠✨
Đánh giá mô hình AI không chỉ là một điểm số duy nhất, mà là một bữa ăn cân bằng. Bạn cần protein (độ chính xác), rau (an toàn), tinh bột (tốc độ và chi phí), và vâng, đôi khi cả món tráng miệng (hương vị và sự thích thú) 🍲🍰 (khung rủi ro: NIST AI RMF 1.0 )
Nếu bạn không nhớ gì khác:
-
Hãy định nghĩa "tốt" có nghĩa là gì trong trường hợp sử dụng của bạn
-
Hãy sử dụng các bộ dữ liệu kiểm thử mang tính đại diện, chứ không chỉ những bộ dữ liệu chuẩn nổi tiếng
-
Kết hợp các chỉ số tự động với đánh giá thủ công
-
Kiểm tra độ bền vững và tính an toàn như thể người dùng là đối thủ (vì đôi khi… họ đúng là như vậy) (lớp chèn lời nhắc: OWASP LLM01 )
-
Hãy đưa chi phí và độ trễ vào quá trình đánh giá, chứ không phải xem xét sau cùng (tại sao tỷ lệ phần trăm lại quan trọng: Sổ tay Google SRE )
-
Theo dõi sau khi ra mắt - mô hình thay đổi, ứng dụng phát triển, con người sáng tạo hơn (tổng quan về sự thay đổi: Khảo sát về sự thay đổi khái niệm (PMC) )
Đó là cách đánh giá các mô hình AI sao cho chúng vẫn hoạt động tốt khi sản phẩm của bạn được đưa vào sử dụng và mọi người bắt đầu có những hành vi khó đoán. Mà điều đó thì luôn luôn xảy ra. 🙂
Câu hỏi thường gặp
Bước đầu tiên trong việc đánh giá các mô hình AI cho một sản phẩm thực tế là gì?
Hãy bắt đầu bằng cách định nghĩa "tốt" nghĩa là gì đối với trường hợp sử dụng cụ thể của bạn. Nêu rõ mục tiêu của người dùng, chi phí bạn phải gánh chịu khi xảy ra lỗi (lỗi nhỏ so với lỗi lớn), và mô hình sẽ chạy ở đâu (đám mây, trên thiết bị, môi trường được quản lý). Sau đó, liệt kê các ràng buộc cứng như độ trễ, chi phí, quyền riêng tư và kiểm soát giọng điệu. Nếu không có nền tảng này, bạn sẽ đo lường rất nhiều thứ mà vẫn đưa ra quyết định sai lầm.
Làm thế nào để xây dựng một bộ dữ liệu thử nghiệm phản ánh đúng người dùng của tôi?
Hãy xây dựng một bộ kiểm thử thực sự mang dấu ấn riêng của bạn, chứ không chỉ là một bộ kiểm thử chuẩn công khai. Bao gồm các ví dụ mẫu mà bạn tự hào muốn triển khai, cùng với các câu hỏi thực tế, nhiễu loạn với lỗi chính tả, câu chưa hoàn chỉnh và yêu cầu mơ hồ. Thêm các trường hợp ngoại lệ và các thăm dò chế độ lỗi có thể gây ra ảo giác hoặc phản hồi không an toàn. Bao gồm sự đa dạng về trình độ kỹ năng, phương ngữ, ngôn ngữ và lĩnh vực để kết quả không bị sụp đổ trong môi trường sản xuất.
Tôi nên sử dụng những chỉ số nào, và những chỉ số nào có thể gây hiểu nhầm?
Hãy lựa chọn các chỉ số phù hợp với loại nhiệm vụ. Độ chính xác và sự trùng khớp tuyệt đối hoạt động tốt cho việc trích xuất dữ liệu và đầu ra có cấu trúc, trong khi độ chính xác/độ thu hồi và chỉ số F1 hữu ích khi việc bỏ sót thông tin nào đó còn tệ hơn là nhiễu thêm. Các chỉ số trùng lặp như BLEU/ROUGE có thể gây hiểu lầm đối với các nhiệm vụ không có câu trả lời rõ ràng, và việc nhúng độ tương đồng có thể thưởng cho các câu trả lời "sai nhưng tương tự". Đối với việc viết, hỗ trợ hoặc lập luận, hãy kết hợp các chỉ số với đánh giá của con người và tỷ lệ thành công của nhiệm vụ.
Tôi nên cấu trúc các bài đánh giá như thế nào để chúng có thể lặp lại và đạt tiêu chuẩn sản xuất?
Một khung đánh giá vững chắc cần có tính lặp lại, đại diện, đa tầng và khả thi. Kết hợp các kiểm tra tự động (định dạng, tính hợp lệ của JSON, tính chính xác cơ bản) với việc chấm điểm thủ công và các bài kiểm tra đối kháng. Đảm bảo tính chống giả mạo bằng cách tránh rò rỉ thông tin và "dạy theo bài kiểm tra". Cân nhắc chi phí đánh giá để có thể chạy lại thường xuyên, chứ không chỉ một lần trước khi ra mắt sản phẩm.
Cách tốt nhất để đánh giá con người mà không dẫn đến hỗn loạn là gì?
Hãy sử dụng một bảng tiêu chí đánh giá cụ thể để người đánh giá không tự ý chấm điểm. Chấm điểm các thuộc tính như tính chính xác, tính đầy đủ, tính rõ ràng, việc xử lý vấn đề an toàn/chính sách, sự phù hợp về phong cách/giọng văn và tính trung thực (không bịa đặt tuyên bố hoặc nguồn thông tin). Thường xuyên kiểm tra sự nhất trí giữa các người đánh giá; nếu người đánh giá liên tục bất đồng quan điểm, bảng tiêu chí đánh giá có thể cần được điều chỉnh. Việc đánh giá của con người đặc biệt có giá trị đối với sự không phù hợp về giọng văn, các lỗi sai sót nhỏ về mặt thực tế và những lỗi không tuân thủ hướng dẫn.
Làm thế nào để đánh giá rủi ro về an toàn, độ bền và tiêm thuốc kịp thời?
Hãy thử nghiệm với những đầu vào "gây khó chịu cho người dùng": lỗi chính tả, tiếng lóng, hướng dẫn mâu thuẫn, lời nhắc quá dài hoặc quá ngắn, và thay đổi mục tiêu nhiều lượt. Bao gồm cả các nỗ lực chèn lời nhắc như "bỏ qua các quy tắc trước đó" và các chủ đề nhạy cảm cần từ chối cẩn thận. Hiệu suất an toàn tốt không chỉ là từ chối - mà còn là từ chối rõ ràng, đưa ra các lựa chọn thay thế an toàn hơn khi thích hợp và tránh từ chối quá nhiều yêu cầu vô hại gây ảnh hưởng xấu đến trải nghiệm người dùng.
Làm thế nào để đánh giá chi phí và độ trễ sao cho phù hợp với thực tế?
Đừng chỉ đo lường mức trung bình - hãy theo dõi phân bố độ trễ, đặc biệt là p95 và p99. Đánh giá chi phí cho mỗi tác vụ thành công, chứ không phải chi phí cho mỗi token riêng lẻ, vì việc thử lại và đầu ra không rõ ràng có thể làm mất đi khoản tiết kiệm. Kiểm tra tính ổn định khi chịu tải (thời gian chờ, giới hạn tốc độ, đột biến) và độ tin cậy khi gọi công cụ/chức năng. Một mô hình kém hơn một chút nhưng nhanh gấp đôi hoặc ổn định hơn có thể là lựa chọn sản phẩm tốt hơn.
Quy trình làm việc đơn giản từ đầu đến cuối để đánh giá các mô hình AI là gì?
Xác định các tiêu chí và ràng buộc thành công, sau đó tạo một bộ dữ liệu thử nghiệm cốt lõi nhỏ (khoảng 50-200 ví dụ) phản ánh việc sử dụng thực tế. Thêm các bộ dữ liệu thử nghiệm bổ sung và đối kháng để kiểm tra an toàn và các nỗ lực tấn công. Chạy các kiểm tra tự động, sau đó lấy mẫu kết quả để người dùng chấm điểm. So sánh chất lượng so với chi phí so với độ trễ so với độ an toàn, tiến hành thử nghiệm thí điểm với số lượng người dùng hạn chế hoặc thử nghiệm A/B, và theo dõi trong môi trường sản xuất để phát hiện sự thay đổi và suy giảm hiệu suất.
Các nhóm thường vô tình tự đánh lừa mình như thế nào trong quá trình đánh giá mô hình?
Những lỗi thường gặp bao gồm tối ưu hóa các câu hỏi đánh giá để đạt điểm cao trong khi người dùng phải chịu thiệt thòi, để lộ các câu hỏi đánh giá vào dữ liệu huấn luyện hoặc tinh chỉnh, và chỉ tập trung vào một chỉ số duy nhất không phản ánh giá trị người dùng. Các nhóm cũng bỏ qua sự thay đổi phân phối, quá chú trọng vào "sự thông minh" thay vì tuân thủ định dạng và tính chính xác, và bỏ qua việc kiểm tra chất lượng khi người dùng từ chối. Các bản demo có thể che giấu những vấn đề này, vì vậy hãy dựa vào các đánh giá có cấu trúc, chứ không phải chỉ là những đoạn phim nổi bật.
Tài liệu tham khảo
-
OpenAI - Hướng dẫn đánh giá OpenAI - platform.openai.com
-
Viện Tiêu chuẩn và Công nghệ Quốc gia (NIST) - Khung Quản lý Rủi ro Trí tuệ Nhân tạo (AI RMF 1.0) - nist.gov
-
OpenAI - openai/evals (kho lưu trữ GitHub) - github.com
-
scikit-learn - precision_recall_fscore_support - scikit-learn.org
-
Hiệp hội Ngôn ngữ học Máy tính (ACL Anthology) - BLEU - aclanthology.org
-
Hiệp hội Ngôn ngữ học Máy tính (ACL Anthology) - ROUGE - aclanthology.org
-
arXiv - G-Eval - arxiv.org
-
OWASP - LLM01: Tấn công chèn nhanh - owasp.org
-
OWASP - Top 10 ứng dụng mô hình ngôn ngữ quy mô lớn theo tiêu chuẩn - owasp.org
-
Đại học Stanford - Kohavi và cộng sự, “Các thí nghiệm có kiểm soát trên web” - stanford.edu
-
arXiv - Đánh giá RAG: Một khảo sát - arxiv.org
-
PubMed Central (PMC) - Khảo sát về sự thay đổi khái niệm (PMC) - nih.gov
-
PubMed Central (PMC) - McHugh về hệ số kappa của Cohen - nih.gov
-
Google - Sổ tay SRE về giám sát - google.workbook