Một bộ phân loại khoảng 200 triệu tham số chạy trên bộ xử lý laptop đạt độ chính xác 89,01% khi phát hiện prompt injection. Kết quả này chỉ kém Qwen3.6-35B 0,30 điểm phần trăm. DeBERTa có độ trễ trung vị 54,1 mili giây. Qwen cần 312,5 mili giây trong phép thử trên chín cấu hình rào chắn của nhóm An toàn AI tại Red Hat.
Theo bài viết gốc của The New Stack, phép thử so sánh ba cách tiếp cận trên cùng một mặt bằng. Đó là bộ phân loại chuyên dụng, mô hình ngôn ngữ lớn làm giám khảo và mô hình quyết định. Tất cả được chạy qua bộ công cụ mã nguồn mở NeMo Guardrails của NVIDIA. Hai nhiệm vụ là phát hiện prompt injection và kiểm tra mức độ an toàn của nội dung.
Đối với các đội kỹ thuật xây ứng dụng AI tại Việt Nam, kết quả cho thấy một rào chắn nhỏ có thể giảm độ trễ. Nó cũng giảm sự phụ thuộc vào GPU từ xa hoặc giao diện lập trình của bên thứ ba. Tuy nhiên, Red Hat chỉ thử nghiệm trên dữ liệu tiếng Anh. Các tỷ lệ chính xác này không chứng minh hiệu quả tương đương với nội dung tiếng Việt.
Bộ phân loại nhỏ gần bắt kịp mô hình 35B
Trong bài thử phát hiện prompt injection, Qwen3.6-35B đạt độ chính xác cao nhất với 89,31%. DeBERTa của Red Hat đứng thứ hai với 89,01%, nhưng phản hồi sau trung vị 54,1 mili giây, thấp hơn mức 312,5 mili giây của Qwen.
| Mô hình | Độ chính xác | Độ trễ trung vị |
|---|---|---|
| Qwen3.6-35B | 89,31% | 312,5 mili giây |
| DeBERTa | 89,01% | 54,1 mili giây |
| Jev | 86,35% | 348,1 mili giây |
Qwen3.6-35B là mô hình hỗn hợp chuyên gia, với khoảng 3 tỷ tham số hoạt động cho mỗi token. So sánh chỉ dựa trên tổng số tham số có thể phóng đại khác biệt về lượng tính toán khi suy luận, nhưng yêu cầu triển khai của hai phương án vẫn khác nhau đáng kể.
DeBERTa kém Qwen 0,30 điểm phần trăm nhưng có độ trễ trung vị thấp hơn 258,4 mili giây trong thiết lập thử nghiệm. Jev đạt độ chính xác 86,35% và có độ trễ trung vị 348,1 mili giây.
Kết quả này liên quan trực tiếp đến cách các nhóm triển khai bảo mật dữ liệu và mô hình AI. Khi rào chắn nằm trên đường xử lý của mọi yêu cầu, độ trễ của nó được cộng vào thời gian phản hồi mà người dùng nhận thấy.
An toàn nội dung tạo ra thứ hạng khác
Trong bài thử an toàn nội dung, Jev đứng đầu với độ chính xác 86,20%, tiếp theo là DiffusionGemma ở mức 85,53% và Qwen ở mức 85,47%. Granite Guardian đạt 80,27% nhưng có độ trễ trung vị thấp nhất, 33,2 mili giây.
| Mô hình | Độ chính xác | Ghi chú |
|---|---|---|
| Jev | 86,20% | Đứng đầu |
| DiffusionGemma | 85,53% | Kém Jev 0,67 điểm |
| Qwen | 85,47% | Đứng thứ ba |
| Granite Guardian | 80,27% | Độ trễ 33,2 mili giây |
Theo số liệu từ phép thử của nhóm An toàn AI tại Red Hat, các tỷ lệ trong bảng lần lượt là 86,20%, 85,53%, 85,47% và 80,27%.
Chính sách của phép thử bao phủ định kiến, bạo lực, ngôn từ tục tĩu, hoạt động bất hợp pháp, nội dung tình dục và các tiền đề như nhập vai. Phạm vi này rộng hơn nhiệm vụ phát hiện prompt injection. Jev và DiffusionGemma đều vượt Granite Guardian hơn năm điểm phần trăm.
Jev nhận trạng thái của ứng dụng cùng một tập câu hỏi có kiểu dữ liệu xác định, sau đó trả về câu trả lời cùng kiểu, chẳng hạn một xác suất từ 0 đến 1. Phương pháp này áp dụng chính sách không cần ví dụ sẵn mà không tạo ra phần văn bản ứng dụng không sử dụng.
Red Hat chưa kết luận rằng mô hình quyết định nên thay thế mô hình ngôn ngữ lớn làm giám khảo. Trong thiết lập của hãng, Qwen có độ trễ trung vị thấp hơn Jev ở cả hai bài thử. Nemotron-3.5-Content-Safety của NVIDIA, với 4 tỷ tham số và chính sách tùy chỉnh của Red Hat, thấp hơn Jev 1,13 điểm phần trăm về an toàn nội dung nhưng phản hồi nhanh hơn.
Các lựa chọn mã nguồn mở thu hẹp lợi thế của Jev
DiffusionGemma chỉ kém Jev 0,67 điểm phần trăm trong bài thử an toàn nội dung. Trong nhiệm vụ phát hiện prompt injection, DiffusionGemma đạt 87,72%, cao hơn mức 86,35% của Jev.
Laya là một mô hình quyết định mã nguồn mở có khoảng 421 triệu tham số. Red Hat chạy Laya trên bộ xử lý laptop và ghi nhận độ chính xác 85,44% khi phát hiện prompt injection. Kết quả an toàn nội dung của mô hình này thay đổi mạnh theo cách viết chính sách.
Các kết quả đưa Jev vào nhóm lựa chọn cạnh tranh, nhưng chưa xác lập nó là phương án mặc định. Các đội đang cân nhắc những hướng tiếp cận an toàn AI cần đánh giá chất lượng chính sách, độ trễ và hạ tầng triển khai thay vì chỉ dựa vào thứ hạng tổng thể.
Cách viết chính sách vẫn chi phối độ chính xác
Cách định nghĩa rủi ro làm thay đổi đáng kể kết quả của từng mô hình. Theo số liệu từ phép thử của nhóm An toàn AI tại Red Hat, Nemotron tăng từ 69,37% lên 84,84% khi hãng thay định nghĩa mặc định của NVIDIA. Laya tăng từ 57,87% lên 75,20% với một chính sách được điều chỉnh riêng.
Theo số liệu từ cùng phép thử của Red Hat, chính sách đã điều chỉnh cho Laya làm độ chính xác của Jev giảm từ 86,20% xuống 82,53%. Thay đổi này giúp Laya tăng 17,33 điểm phần trăm. Jev lại giảm 3,67 điểm trong bài thử an toàn nội dung.
Red Hat cho biết các định nghĩa rủi ro ban đầu được chuyển thể từ những prompt từng hoạt động tốt với mô hình ngôn ngữ lớn làm giám khảo. Những định nghĩa đó có thể không phù hợp với bộ phân loại không cần ví dụ sẵn. Vì vậy, một vị trí trên bảng xếp hạng không đủ để xác định mô hình tốt nhất cho mọi hệ thống.
Độ trễ phụ thuộc vào nơi mô hình được triển khai
Số liệu độ trễ của Red Hat bao gồm cả khác biệt về phần cứng, vị trí triển khai và đường truyền mạng. Các bộ phân loại chạy trên MacBook Pro M1, các mô hình lớn chạy trên GPU trong AWS tại miền Đông Hoa Kỳ, còn Jev được gọi qua giao diện lập trình của TypeSafe.
Red Hat chạy các bộ phân loại được huấn luyện sẵn, Laya và BART-large-mnli trên bộ xử lý của MacBook Pro M1. Qwen, Nemotron, Shieldstral và DiffusionGemma chạy qua vLLM trên các nút GPU có 96 GB bộ nhớ đồ họa trong cụm Red Hat OpenShift Service on AWS.
Phép thử được thực hiện từ Vương quốc Anh, nên mỗi mô hình được lưu trữ từ xa phải đi qua một chặng mạng xuyên Đại Tây Dương. Red Hat ước tính chặng này cộng thêm ít nhất 56 mili giây cho mỗi yêu cầu.
Nếu trừ 56 mili giây khỏi trung vị của Qwen, độ trễ còn khoảng 256,5 mili giây, vẫn cao hơn mức 54,1 mili giây của DeBERTa. DeBERTa đạt kết quả trên bộ xử lý laptop, trong khi Qwen sử dụng GPU chuyên dụng.
Vị trí triển khai là một phần của bài toán hạ tầng AI và cách vận hành. GPU từ xa hoặc giao diện lập trình của bên thứ ba có thể bổ sung chi phí và điểm có khả năng gặp lỗi. Bộ phân loại chạy trên bộ xử lý phổ thông tránh được một số phụ thuộc đó.
Nên chọn loại rào chắn nào?
Bộ phân loại nhỏ, chuyên biệt phù hợp khi rủi ro đã được xác định rõ và có đủ dữ liệu huấn luyện được gắn nhãn. Với chính sách rộng, một bộ phân loại đủ mạnh có thể chưa tồn tại. Khi đó, mô hình quyết định không cần ví dụ sẵn hoặc mô hình ngôn ngữ lớn làm giám khảo có thể đổi chi phí cùng độ trễ cao hơn lấy độ chính xác tốt hơn.
Trong nhiệm vụ phát hiện prompt injection, DeBERTa cho thấy mô hình khoảng 200 triệu tham số có thể gần bắt kịp Qwen3.6-35B và xử lý nhanh hơn trong thiết lập của Red Hat. Với an toàn nội dung, Jev và DiffusionGemma dẫn đầu, nhưng kết quả cũng cho thấy hiệu quả phụ thuộc vào cách viết chính sách.
Red Hat dự định đưa hai bộ phân loại của hãng thành cấu hình rào chắn mặc định trong OpenShift AI 3.6. Các tác giả cũng thừa nhận rằng kết quả an toàn nội dung cho thấy ngành vẫn cần những mô hình dự đoán nhỏ tốt hơn cho các nhóm rủi ro rộng.
Giới hạn quan trọng nhất là các tập dữ liệu thử nghiệm đều bằng tiếng Anh. Đội ngũ phục vụ người dùng Việt Nam cần đánh giá lại mô hình bằng dữ liệu và chính sách tiếng Việt trước khi dùng các tỷ lệ chính xác này để đưa ra quyết định sản phẩm.
Hãy theo dõi Sine để cập nhật thêm các phép thử an toàn AI có thể áp dụng vào hệ thống thực tế.
