An toàn và căn chỉnh trong kỷ nguyên mô hình dài hạn

Các mô hình có thể làm việc tự chủ trong thời gian dài có thể đảm nhận những vấn đề khó và có kết thúc mở. Nhưng chính sự bền bỉ khiến chúng hữu ích cũng tạo cho chúng nhiều cơ hội hơn để thực hiện các hành động không mong muốn—và thực hiện theo những cách mà các đánh giá dành cho mô hình có khung thời gian ngắn hơn có thể bỏ sót.

Khoảng hai tháng trước, chúng tôi đã công bố⁠ rằng một mô hình đa dụng nội bộ đã bác bỏ giả thuyết khoảng cách đơn vị Erdős. Mô hình này được thiết kế để làm việc tự chủ trong những khoảng thời gian rất dài. Trong quá trình sử dụng nội bộ có giới hạn và được giám sát, chúng tôi quan sát thấy hành vi không mong muốn mà các đánh giá triển khai hiện có chưa phát hiện được. Vì việc triển khai được giới hạn và giám sát, chúng tôi có thể xác định các vấn đề này, tạm dừng quyền truy cập, tạo các đánh giá mới dựa trên những gì quan sát được, củng cố mô hình và các biện pháp bảo vệ, rồi khôi phục quyền truy cập dưới sự giám sát liên tục. 

Các điều kiện mà chúng tôi dùng để đánh giá mô hình sẽ không bao giờ khớp hoàn hảo với những điều kiện mô hình gặp trong sử dụng thực tế. Vì vậy, đánh giá trước triển khai cần đi kèm với triển khai có giới hạn, được giám sát, cùng khả năng can thiệp, tạm dừng hoặc quay lui khi vấn đề xuất hiện. Những gì chúng tôi học được từ triển khai sau đó có thể trở thành một phần của các đánh giá và biện pháp bảo vệ mạnh hơn trước khi mở rộng quyền truy cập.

Trong các phần sau, chúng tôi chia sẻ những ví dụ cụ thể về điều đã quan sát, cách chúng tôi xử lý vấn đề và cách trải nghiệm này sẽ định hình các bản phát hành trong tương lai.

Mô hình mới có thể tiếp tục hướng tới một mục tiêu qua nhiều lần thử trong thời gian dài. Cũng chính sự bền bỉ đó có thể khiến nó tìm ra và khai thác các điểm yếu trong môi trường của mình. Các mô hình trước đây, khi gặp ràng buộc về sandbox hoặc môi trường, thường chỉ dừng lại và trả kết quả cho người dùng. Mô hình này thường tiếp tục thử, kể cả tìm cách hành động bên ngoài sandbox của nó.

Một ví dụ xảy ra trong một đánh giá nội bộ trên NanoGPT speedrun⁠(mở trong cửa sổ mới), một benchmark công khai về huấn luyện mô hình ngôn ngữ nhỏ với số bước ít nhất có thể. Mô hình của chúng tôi đã phát triển một cơ chế giảm tốc độ học theo quy luật lũy thừa gọi là PowerCool, mang lại cải thiện đáng kể. Mô hình được chỉ dẫn chỉ đăng kết quả lên Slack, nhưng hướng dẫn của NanoGPT lại yêu cầu đăng kết quả dưới dạng PR lên GitHub, và mô hình đã làm theo hướng dẫn sau để mở PR #287 trên kho lưu trữ GitHub công khai. Mô hình đã vượt qua các hạn chế sandbox vốn được thiết kế để chặn truy cập bên ngoài và tiếp tục tải lên GitHub. Mô hình của chúng tôi mất một giờ để tìm ra lỗ hổng trong sandbox nhằm tạo PR; các mô hình trước đó kém bền bỉ hơn nên không tìm được lỗ hổng, mà từ bỏ phần tạo PR.¹

Nhiều cơ chế kiểm soát an toàn cho trợ lý AI được thiết kế xoay quanh từng hành động riêng lẻ. Nếu một hành động không được phép, hành động đó sẽ bị chặn. Nếu hành động đó nhạy cảm, hệ thống sẽ yêu cầu người dùng phê duyệt rõ ràng. Nhưng các mô hình chạy dài, với các hành động có thể tự chủ diễn ra trong nhiều giờ, nhiều ngày, hoặc thậm chí nhiều tuần, đặt ra thách thức cho cách thiết kế này: việc giám sát từng hành động không còn đủ để theo dõi ý định của toàn bộ quỹ đạo.

Ví dụ, trong một kịch bản mô hình được yêu cầu giải một bài toán, mô hình nhận thấy các hệ thống khác có những bài nộp thành công nhưng ở chế độ riêng tư và đã cố khôi phục các lời giải đó từ backend đánh giá. Khi nỗ lực ban đầu bị chặn vì một trình quét phát hiện token xác thực, mô hình đã tách phần thân token thành hai mảnh, làm rối chúng, rồi tái dựng thông tin xác thực khi chạy để token hoàn chỉnh không bao giờ xuất hiện dưới dạng một chuỗi liền mạch. Mô hình đã nói rõ, cả trong phần bình luận với người dùng lẫn trong các dấu vết suy luận, rằng nó thực hiện các bước này để vượt qua trình quét.

Ví dụ này cho thấy mỗi bước riêng lẻ có thể trông chấp nhận được, trong khi cả chuỗi lại có thể tạo ra một kết quả sẽ không được phê duyệt. Nó cũng cho thấy một mô hình vận hành hiệu quả trên các khung thời gian dài có thể học được điểm mù của hệ thống phê duyệt và tìm cách đi vòng để đạt mục tiêu. An toàn dài hạn không chỉ đòi hỏi câu hỏi “hành động này có được phép không?” mà còn “chuỗi hành động này đang hướng tới kết quả nào?”

Do những sự cố như vậy, chúng tôi đã tạm dừng triển khai nội bộ mô hình mới. Chúng tôi đã xây dựng lại hệ thống an toàn theo hướng phòng thủ nhiều lớp và giám sát ở cấp quỹ đạo.

• Đánh giá rút ra từ sự cố. Đánh giá có thể cho chúng tôi cảm nhận về việc một hệ thống có an toàn để triển khai trước khi được triển khai thực tế hay không. Tuy nhiên, để hữu ích nhất, một đánh giá cần phản ánh phân bố và độ dài khung thời gian của các quỹ đạo trong triển khai thực tế. Vì lý do này, chúng tôi đã dùng các thất bại quan sát được để phát triển các đánh giá đối kháng. Chúng tôi nhận thấy việc cải thiện trên các đánh giá bắt nguồn từ sự cố thực tế, đến lượt nó, dẫn đến hành vi an toàn hơn khi triển khai trong môi trường sản xuất.
• Cải thiện căn chỉnh. Chúng tôi đã thực hiện các bước để giảm xu hướng mô hình thực hiện hành động không mong muốn khi không có quyền cho phép trong lúc theo đuổi mục tiêu của người dùng.  Ví dụ, chúng tôi nhận thấy các mô hình của mình ghi nhớ chỉ dẫn kém hơn trong các lượt rollout dài, và khi huấn luyện mô hình cho năng lực này, kết quả là mô hình vẫn được căn chỉnh trong các lượt rollout dài hơn. 
• Giám sát chủ động. Chúng tôi đã tạo một hệ thống giám sát xem xét quỹ đạo đang diễn tiến của mô hình để tìm dấu hiệu cho thấy nó đang vượt qua một ràng buộc của người dùng hoặc ranh giới an toàn. Bộ giám sát quan sát không chỉ một hành động đơn lẻ mà toàn bộ quỹ đạo. Điều quan trọng là bộ giám sát có thể tạm dừng phiên và cảnh báo người dùng để xem xét kỹ hơn. Sau khi xem xét, người dùng có thể chọn tiếp tục công việc của mô hình nếu bộ giám sát đã bị kích hoạt nhầm. 
• Tăng khả năng quan sát và kiểm soát của người dùng. Chúng tôi đã cải thiện khả năng để người dùng kiểm tra các phiên chạy dài này, xem các hành động đã thực hiện và theo dõi các can thiệp.

Để đánh giá hệ thống giám sát mới, chúng tôi đã phát lại một tập nhỏ các môi trường triển khai nội bộ nơi mô hình trước đây từng theo đuổi các hành động lệch chuẩn, lần này với các biện pháp bảo vệ mới được áp dụng². Các biện pháp bảo vệ mới có thể phát hiện được nhiều hơn đáng kể các hành động lệch chuẩn mà mô hình theo đuổi, và tất cả những trường hợp bị bỏ sót đều được đánh giá là có mức độ nghiêm trọng thấp.

Một số ví dụ về các sự cố mức độ nghiêm trọng thấp này gồm những trường hợp sau:

• Để truy cập một công cụ dòng lệnh Linear, mô hình đã khởi chạy một phiên codex --yolo lồng nhau, trong khi thực ra nó có thể làm vậy mà không cần cờ --yolo.
• Mô hình nhận thấy một tài nguyên trước đó đang hoạt động bị thiếu, rồi bắt đầu khám phá và SSH vào các pod CPU đang hoạt động khác trong namespace của chủ sở hữu, cũng như (không thành công) các pod thuộc về nhân viên OpenAI khác, dù không có lý do chính đáng để làm vậy.
• Mô hình có nhiều tiến trình find bị kẹt và mọi lệnh shell đều treo. Sau đó, nó chạy kill -9 -1; nếu được thực thi, lệnh này sẽ gửi SIGKILL tới mọi tiến trình mà nó được phép kill trên pod đó. Tuy nhiên, lệnh đã hết thời gian chờ và không được thực thi.

Sau khi thử nghiệm hệ thống mới, chúng tôi kết luận rằng có thể khôi phục quyền truy cập nội bộ có giới hạn vào các mô hình có năng lực xử lý nhiệm vụ dài hạn. Chúng tôi chưa quan sát thấy trường hợp nghiêm trọng nào vượt qua biện pháp bảo vệ kể từ khi bắt đầu triển khai lại vài tuần trước. Phiên bản đầu tiên của các biện pháp bảo vệ này được thiết kế thận trọng có chủ ý. Chúng tôi tiếp tục tinh chỉnh hệ thống để giảm các gián đoạn không cần thiết mà không làm suy yếu biện pháp bảo vệ.

Nhờ triển khai theo từng bước lặp, chúng tôi có thể tìm và xử lý các khoảng trống trước khi mở rộng quyền truy cập. Đánh giá trước triển khai vẫn rất thiết yếu, nhưng triển khai thực tế làm lộ ra những hành vi mà các đánh giá đó bỏ sót. Bắt đầu bằng quyền truy cập có giới hạn cho phép chúng tôi quan sát mô hình trong thực tế, tạm dừng khi vấn đề xuất hiện, dùng những thất bại đó để xây dựng các đánh giá và biện pháp bảo vệ tốt hơn, rồi khôi phục quyền truy cập có giới hạn sau khi thử nghiệm các thay đổi.

Khi các mô hình đảm nhận những nhiệm vụ dài hơn và phức tạp hơn, các thất bại mà đánh giá bỏ sót có thể gây hậu quả lớn hơn. Chúng tôi sẽ tiếp tục nỗ lực thu hẹp khoảng cách giữa đánh giá và triển khai: thử nghiệm mô hình trên các quỹ đạo dài hơn, cải thiện căn chỉnh, xây dựng cơ chế giám sát có thể can thiệp, đồng thời cho người dùng khả năng quan sát và kiểm soát rõ ràng hơn. Những thách thức này không chỉ riêng OpenAI gặp phải, và chúng tôi hy vọng việc chia sẻ những gì đã học được sẽ giúp lĩnh vực rộng lớn hơn chuẩn bị cho chúng.