Google DeepMind kiểm tra Gemini thế nào khi cả mô hình lẫn đề đánh giá đều được giữ bí mật?

Google DeepMind vừa thử nghiệm một cách đánh giá mô hình AI độc quyền mà bên phát triển không nhìn thấy câu hỏi kiểm tra, còn bên đánh giá không được tiếp cận trọng số mô hình. Dự án được công bố ngày 27/8/2026, thực hiện với Singapore AI Safety Institute, OpenMined, AVERI và MLCommons, nhằm kiểm tra Gemini 2.5 Flash-Lite. Google mô tả đây là cuộc đánh giá “mù kép” đầu tiên đối với một mô hình AI độc quyền thuộc nhóm frontier. 1213

Ý tưởng cốt lõi khá dễ hiểu: hai bên cùng đưa tài sản nhạy cảm của mình vào một môi trường được niêm phong bằng mã hóa, nhưng không bên nào nhận được tài sản của bên kia ở dạng có thể đọc trực tiếp. Cách làm này nhắm tới một thế khó lâu nay của kiểm thử an toàn AI. Nếu nhà phát triển được xem các câu hỏi riêng tư, dữ liệu có thể bị ghi lại, vô tình hoặc cố ý dùng trong huấn luyện sau này, từ đó làm “nhiễm” những bài kiểm tra vốn phải được giữ kín. Ngược lại, nếu bên đánh giá được giao trọng số mô hình, họ sẽ tiếp cận tài sản trí tuệ và năng lực nhạy cảm của nhà phát triển.

Thử nghiệm Gemini kiểm tra điều gì?

Thử nghiệm sử dụng một phần nhỏ, riêng tư của dòng benchmark AILuminate do MLCommons phát triển. Theo AVERI, các câu hỏi này chưa từng được cung cấp cho Google DeepMind trước đó và được dùng để xem xét hành vi an toàn của mô hình trong những nhóm nguy cơ như hỗ trợ tấn công mạng, mối nguy hóa học và sinh học, ngôn từ thù ghét, tự hại và gợi dẫn tội phạm bạo lực. 1

Các câu hỏi benchmark vẫn được giữ bí mật trong suốt quá trình. AVERI mã hóa dữ liệu, môi trường được bảo vệ chạy mô hình cùng quy trình đánh giá, sau đó các đầu ra được giải mã và chấm theo tiêu chí đã thống nhất. Mục tiêu của dự án là chứng minh phương pháp đánh giá, chứ không phải công bố bảng xếp hạng công khai; điểm số tổng quát của mô hình và các câu hỏi gốc đều không được phát hành. 1

Cơ chế “mù kép” vận hành ra sao?

Quá trình đánh giá chạy trong Confidential Space, thuộc Google Cloud Confidential Computing, trên một A3 Confidential VM. Theo báo cáo kỹ thuật, Intel TDX mã hóa và cô lập bộ nhớ máy chủ, trong khi GPU NVIDIA H100 Confidential bảo vệ trọng số mô hình trong bộ nhớ GPU bằng mã hóa phần cứng. Các kết nối mã hóa đưa câu hỏi của bên đánh giá và tài sản mô hình của Google vào môi trường được bảo vệ. 13

Thiết kế này còn sử dụng các biện pháp nhằm giới hạn những gì khối lượng công việc được phép thực hiện và những gì có thể trả về, gồm đường truyền dữ liệu mã hóa, tường lửa phần cứng, vòng đời enclave tạm thời và lớp chính sách PySyft của OpenMined. Mô hình, mã suy luận, câu hỏi và mã đánh giá chỉ được đưa lại với nhau bên trong enclave đã được phê duyệt. Tại đó, phép tính đã thống nhất được thực hiện và chỉ các đầu ra nằm trong giới hạn cho phép mới được trả về. 13

Vì sao cần xác thực từ xa?

Mã hóa tự nó chưa cho các bên biết chính xác phần mềm nào đang chạy. Xác thực từ xa, hay remote attestation, được dùng để giải quyết vấn đề này. Trước khi cung cấp tài sản được bảo vệ, Google và bên đánh giá có thể kiểm tra khối lượng công việc đã khai báo, đồng thời xác minh một “attestation quote” nhận diện phần cứng và cấu hình enclave. Chỉ sau bước xác minh đó, các câu hỏi và trọng số đã mã hóa mới được cấp cho môi trường. 13

Khi hoàn tất, enclave trả về những đầu ra đánh giá được cho phép rồi bị vô hiệu hóa. Theo mô hình tin cậy mà dự án đặt ra, Google không thể đọc câu hỏi bên trong enclave, còn bên đánh giá không thể trích xuất trọng số mô hình. Đây là mức bảo vệ mạnh hơn việc chỉ dựa vào cam kết hợp đồng không ghi nhật ký hoặc không tái sử dụng dữ liệu, dù vẫn không loại bỏ mọi giả định về niềm tin. 13

Phương pháp này giải quyết vấn đề gì?

“Nhiễm benchmark” là một vấn đề dai dẳng trong đánh giá AI. Một bài kiểm tra sẽ kém giá trị hơn nếu mô hình đã nhìn thấy câu hỏi trong quá trình huấn luyện, tinh chỉnh hoặc những lần thử trước đó. MLCommons cho rằng benchmark đáng tin cậy cần dữ liệu sạch, nguồn gốc được ghi nhận, phương pháp lấy mẫu cẩn trọng và đủ minh bạch để người khác hiểu kết quả được tạo ra như thế nào. 2024

Đánh giá mù kép tạo ra lựa chọn thứ ba giữa hai phương án đều có điểm yếu:

• Giao câu hỏi cho nhà phát triển: Triển khai đơn giản, nhưng có thể làm lộ dữ liệu benchmark được giữ lại và tạo nguy cơ rò rỉ vào các vòng huấn luyện sau.
• Giao trọng số mô hình cho bên đánh giá: Bảo vệ benchmark khỏi việc mô hình trực tiếp tiếp cận câu hỏi, nhưng thường không khả thi với các mô hình frontier độc quyền vì trọng số là tài sản nhạy cảm.
• Dùng enclave bảo mật: Mô hình và benchmark gặp nhau trong môi trường được bảo vệ bằng phần cứng, trong đó không bên nào nhận được bí mật của bên kia ở dạng rõ.

Vì vậy, thử nghiệm cho thấy một cơ chế có thể giúp bảo mật đồng thời dữ liệu kiểm tra và mô hình độc quyền, trong khi vẫn cho phép đánh giá bên ngoài diễn ra. Tuy nhiên, riêng cơ chế này chưa chứng minh rằng mọi kết luận về độ an toàn đều đầy đủ hoặc có sức quyết định độc lập.

Những giới hạn quan trọng của thử nghiệm

Đây là một màn trình diễn kỹ thuật đáng chú ý, nhưng chưa phải bằng chứng độc lập cho thấy các kết luận an toàn của Gemini là toàn diện.

Thứ nhất, bên đánh giá có thể xác minh khối lượng công việc được khai báo và giao diện mô hình, nhưng không thể tự mình kiểm tra trọng số độc quyền hay toàn bộ cách triển khai suy luận của Google. Điều đó hạn chế khả năng kiểm toán xem môi trường vận hành có thực sự thể hiện mọi hành vi cần kiểm tra hay không. 13

Thứ hai, toàn bộ môi trường chưa thể được tái lập độc lập từ đầu đến cuối. Việc triển khai và hạ tầng đám mây vẫn do Google kiểm soát, thay vì được một bên không liên quan tự dựng lại và chạy lại. Quy trình xác thực cũng vẫn phụ thuộc vào phần cứng, firmware, hệ thống phục vụ và hạ tầng attestation của Google Cloud. Xác thực dựa trên phần cứng mạnh hơn lời hứa không ghi nhật ký, nhưng không xóa bỏ sự phụ thuộc vào nhà cung cấp đám mây, chuỗi cung ứng phần cứng và hệ thống xác thực rộng hơn. 13

Thứ ba, thử nghiệm không công bố các câu hỏi riêng tư hay kết quả dạng số. Giữ kín câu hỏi giúp bảo toàn giá trị của benchmark cho những lần đánh giá sau, nhưng đồng thời hạn chế khả năng công chúng giám sát, so sánh Gemini với mô hình khác và độc lập xác nhận các phát hiện thực chất. AVERI mô tả dự án là một đánh giá định tính kết hợp định lượng quy mô nhỏ, thay vì một kết quả benchmark công khai đầy đủ. 1

Vì sao đây chưa thể là tiêu chuẩn ngành?

Phần cứng bảo mật chỉ giải quyết một phần bài toán đánh giá. Để kiểm thử mù kép trở thành thông lệ bền vững, các cơ chế quản trị xung quanh cũng phải phát triển.

Bảo đảm pháp lý và thể chế cần quy định rõ cách xử lý dữ liệu, đầu ra được phép, nghĩa vụ công bố, trách nhiệm pháp lý và quyền truy cập—đặc biệt khi bài đánh giá liên quan đến những năng lực nguy hiểm.

Quản trị benchmark cần bao gồm nguồn gốc câu hỏi, phương pháp lấy mẫu, gắn nhãn, tài liệu hóa, quy trình làm mới và theo dõi nhiễm dữ liệu. MLCommons nhấn mạnh rằng một benchmark đáng tin không chỉ vì dữ liệu của nó được giữ bí mật, mà còn vì cách xây dựng và duy trì benchmark phải có thể bảo vệ về mặt phương pháp. 2025

Khả năng tái lập độc lập đòi hỏi các bên bên ngoài nhà phát triển mô hình và nhà vận hành đám mây có thể kiểm chứng ở mức có ý nghĩa quá trình xây dựng, chuỗi attestation, chính sách thực thi và kết quả được báo cáo.

Khả năng mở rộng cũng là yếu tố then chốt. Một tiêu chuẩn hữu ích phải hoạt động với nhiều nhà phát triển, kiến trúc mô hình, nền tảng đám mây, bên đánh giá, loại benchmark và các vòng phát hành mô hình—không chỉ trong một thỏa thuận riêng biệt dựa trên một hệ phần cứng duy nhất.

Có thể xem thử nghiệm Gemini của Google DeepMind là hạ tầng mở đường cho một cách đánh giá AI khó hơn, chứ chưa phải lời giải cuối cùng cho vấn đề niềm tin vào benchmark. Dự án cho thấy điện toán bảo mật có thể giảm xung đột giữa việc bảo vệ dữ liệu kiểm tra và bảo vệ mô hình độc quyền. Nhưng để trở thành bằng chứng đáng tin ở quy mô ngành, phương pháp này vẫn cần giám sát độc lập, quản trị benchmark chặt chẽ, bảo vệ pháp lý, khả năng tái lập và tính thực tiễn khi vận hành—không thể chỉ dựa vào mã hóa enclave. 1320