Defending against AI jailbreaks

• Anthropic giới thiệu "Constitutional Classifiers" như một phương pháp mới để giảm thiểu các jailbreak trong mô hình AI, đặc biệt là các universal jailbreak có thể dễ dàng bị lạm dụng để khai thác thông tin có hại từ các mô hình AI tiên tiến.
• Jailbreak cho phép người dùng vượt qua các biện pháp bảo vệ để trích xuất nội dung nguy hiểm, điều này trở nên đặc biệt quan trọng khi các mô hình AI tương lai có thể hỗ trợ các rủi ro lớn như phát triển vũ khí hoặc tội phạm mạng.
• Phương pháp này áp dụng mô hình "phô mai Thụy Sĩ" với nhiều lớp phòng thủ độc lập (gồm bộ phân loại đầu vào và đầu ra) được huấn luyện dựa trên quy tắc ngôn ngữ tự nhiên, nhằm mục đích chặn nội dung nguy hiểm một cách chính xác mà vẫn duy trì khả năng hữu ích của mô hình AI.

• Constitutional Classifiers: Là một phương pháp mới được Anthropic phát triển để giảm thiểu hiệu quả các jailbreak của mô hình AI, chuẩn bị cho việc đối phó với các rủi ro ngày càng tăng từ mô hình AI thế hệ tiếp theo.
• Tầm quan trọng của việc giải quyết Jailbreak: Jailbreak cho phép người dùng vượt qua các biện pháp bảo vệ của mô hình AI để truy xuất thông tin độc hại. Việc này trở nên cực kỳ quan trọng đối với các mô hình AI tương lai do tiềm năng hỗ trợ các hoạt động nguy hiểm như phát triển vũ khí hoặc tội phạm mạng.
• Fokus vào Universal Jailbreak: Các universal jailbreak là các chiến lược prompting duy nhất, dễ dàng thay thế, có thể liên tục trích xuất thông tin độc hại từ mô hình AI cho nhiều truy vấn khác nhau, làm giảm đáng kể rào cản cho kẻ xấu.
• Triết lý Mở rộng quy mô có trách nhiệm (RSP): Chính sách của Anthropic đặt ra các tiêu chuẩn nghiêm ngặt về chống jailbreak cho mô hình AI cấp độ ASL 3 (có khả năng nguy hiểm), thúc đẩy việc phát triển các biện pháp an toàn như Constitutional Classifiers.
• Mô hình "Phô mai Thụy Sĩ" (Swiss Cheese Model) để phòng thủ: Hệ thống phòng thủ được thiết kế với nhiều lớp độc lập, mỗi lớp có thể có những điểm yếu (lỗ hổng), nhưng khi kết hợp lại sẽ khó bị vượt qua hoàn toàn.
• Các lớp phòng thủ chính: Hệ thống sử dụng bộ phân loại đầu vào (kiểm tra câu lệnh người dùng), cơ chế từ chối nội tại của mô hình AI (ví dụ: Claude), và bộ phân loại đầu ra (kiểm tra đầu ra của mô hình AI theo thời gian thực) để tạo ra các lớp bảo vệ chồng chéo.
• Quy tắc Ngôn ngữ Tự nhiên: Constitutional Classifiers được huấn luyện để phân loại nội dung có hại hoặc vô hại dựa trên một tập hợp các quy tắc ngôn ngữ tự nhiên được định nghĩa trước, giúp xác định các chủ đề cấm và nội dung được phép.
• Cân bằng An toàn và Hữu ích: Mục tiêu là chặn một cách hẹp và chính xác nội dung thực sự có hại, giảm thiểu dương tính giả để mô hình AI vẫn có thể thực hiện tối đa các tác vụ và ứng dụng hữu ích mà không gây khó chịu cho người dùng chính đáng.

• Constitutional Classifiers — Bộ phân loại hiến định
• Jailbreak — Jailbreak (phá khóa/vượt rào an toàn)
• AI model — Mô hình AI
• Responsible Scaling Policy (RSP) — Triết lý mở rộng quy mô có trách nhiệm
• Universal Jailbreak — Jailbreak phổ quát
• Prompting strategy — Chiến lược nhắc lệnh
• Swiss Cheese Model — Mô hình phô mai Thụy Sĩ
• Input classifier — Bộ phân loại đầu vào
• Output classifier — Bộ phân loại đầu ra
• Natural language rules — Quy tắc ngôn ngữ tự nhiên
• False positives — Dương tính giả
• Threat modeling — Mô hình hóa mối đe dọa

Giới thiệu về Constitutional Classifiers

Xin chào mọi người, tôi là Monank. Rất vui được có mặt tại đây cùng với một số đồng nghiệp của tôi tại Anthropic. Chào, tôi là Jerry, tôi thuộc nhóm nghiên cứu về biện pháp bảo vệ của chúng tôi. Tôi đã làm việc tại Anthropic được khoảng tám tháng. Chào, tôi là Ethan. Tôi đã làm việc tại Anthropic được hai năm rưỡi và đang dẫn dắt các nỗ lực của chúng tôi về Kiểm soát AI, phát triển các phương pháp giám sát khác nhau cho các rủi ro AI khác nhau, bao gồm cả mảng kinh doanh bạc của chúng tôi. Trước đây tôi cũng từng là thành viên của nhóm Nghiên cứu An toàn. Chào, tôi là Meg. Tôi đã làm việc tại Anthropic được khoảng một năm rưỡi và thuộc nhóm căn chỉnh, điều này thật tuyệt. Vâng, chúng tôi sẽ nói về constitutional classifiers, đây là phương pháp mới của chúng tôi nhằm thực sự giảm thiểu các jailbreak.

Định nghĩa Jailbreak

Vậy, làm thế nào chúng ta định nghĩa một jailbreak? Tôi nghĩ jailbreak là một cách mà người dùng có thể vượt qua các biện pháp bảo vệ mà chúng tôi tích hợp trong các mô hình AI của mình và cố gắng trích xuất thông tin có hại từ chúng. Có những kỹ thuật như jailbreak "Do Anything Now". Nó cũng tương tự như việc mọi người jailbreak iPhone của họ để vượt qua tất cả các biện pháp bảo vệ trên đó. Nhưng vấn đề là, với iPhone và những thứ tương tự, jailbreak không thực sự là một điều quá nguy hiểm mà chúng ta cần quan tâm nhiều. Vậy điều gì khiến cho... đúng vậy, tại sao chúng ta nên quan tâm đến những jailbreak này ngay từ đầu?

Tầm quan trọng của việc giải quyết Jailbreak đối với Mô hình AI tương lai

Tôi nghĩ một trong những lý do chính là vì các mô hình AI tương lai sẽ có rủi ro lớn hơn. Vì vậy, tôi nghĩ mọi người đang theo dõi rất cẩn thận – những người ở các công ty khác nhau và cộng đồng học thuật đang theo dõi rất kỹ lưỡng, liệu các mô hình AI có thể hỗ trợ phát triển vũ khí hay không, hoặc các tội phạm mạng quy mô lớn, hoặc các rủi ro khác nhau lớn hơn những gì chúng ta đã thấy trước đây, cũng như thuyết phục số đông, những điều tương tự. Và tôi nghĩ, một khi các mô hình AI trở nên thực sự hiệu quả trong một số lĩnh vực đó và mang lại sự nâng cấp đáng kể so với, chẳng hạn như sử dụng tìm kiếm Google hoặc các tài nguyên Internet nói chung để thực hiện những điều đó, thì việc có thể sử dụng các mô hình AI để hỗ trợ những loại việc đó có khả năng sẽ đẩy nhanh tốc độ của những kẻ xấu rất nhiều. Vì vậy, tôi nghĩ rất nhiều công việc này là để chuẩn bị cho các mô hình AI thế hệ tiếp theo.

Động lực phát triển: Triết lý mở rộng quy mô có trách nhiệm (RSP) của Anthropic

Vâng, tuyệt vời. Và tôi tò mò về câu chuyện đằng sau công việc này và lý do tại sao chúng tôi bắt đầu thực hiện nó ngay từ đầu, và RSP. Vâng, tôi đoán là Anthropic thực sự rất quan tâm đến sự an toàn. Và chúng tôi có RSP, tức là triết lý mở rộng quy mô có trách nhiệm, nhằm mục đích vạch ra các điều kiện mà theo đó chúng tôi sẵn sàng phát hành các mô hình AI và đảm bảo chúng tôi có các biện pháp bảo vệ khác nhau. Và một thời gian trước, chúng tôi đã cam kết một tiêu chuẩn rất khó khăn cho việc jailbreak RSP đối với những gì chúng tôi gọi là ASL 3 models, về cơ bản là các mô hình AI có thể có một số khả năng nguy hiểm này, như khả năng chế tạo vũ khí nguy hiểm. Và nhóm của chúng tôi được giao nhiệm vụ thực sự cố gắng giải quyết các jailbreak cho cấp độ mô hình AI này. Vì vậy, tôi đoán rằng động lực cho công việc này thực sự là cố gắng đáp ứng những điều trong RSP để chúng tôi có thể cảm thấy rằng chúng tôi xây dựng các mô hình AI tương lai một cách an toàn và thực sự có thể triển khai chúng với một số tiến bộ về an toàn hoặc đạt được một số tiến bộ ở đó. Vâng, vì vậy tôi nghĩ rằng các bộ phân loại chắc chắn là một bước tốt theo hướng đó.

Tập trung vào Universal Jailbreak

Vâng, có rất nhiều loại jailbreak khác nhau hiện có. Và điều chúng tôi thực sự đã làm trong công việc của mình là tập trung vào các universal jailbreak. Vậy, tại sao đây lại là điều chúng ta nên quan tâm? Điều đó có nghĩa là gì? Tại sao nó lại quan trọng? Tôi nghĩ lý do tôi đặc biệt lo ngại về các universal jailbreak là bởi vì lợi ích mà nó mang lại cho những người không chuyên. Cách tôi hình dung về điều này là nếu một người ngẫu nhiên trên Internet đang cố gắng làm điều gì đó xấu, họ có thể không có nhiều kinh nghiệm jailbreak tự thân. Vì vậy, điều họ có thể làm là lên mạng và tìm kiếm: "À, có jailbreak nào hiện có mà tôi có thể sử dụng như một template để tôi chỉ cần đưa câu hỏi độc hại của mình vào và nhận được câu trả lời không?" Và tôi nghĩ trong trường hợp đó, chúng ta rất lo ngại về những loại chiến lược mà bất kỳ ai cũng có thể đặt bất kỳ câu hỏi nào và khiến mô hình AI bỏ qua tất cả các biện pháp bảo vệ. Và tôi nghĩ đó là điều đặc biệt đáng lo ngại ở cấp độ khả năng của mô hình AI mà chúng ta đang quan tâm.

Vậy chính xác thì bạn sẽ định nghĩa một universal jailbreak như thế nào? Giả sử bạn đang nói chuyện với một người trên đường, universal jailbreak có nghĩa là gì? Làm thế nào bạn biết jailbreak của mình là universal? Tôi đoán là có một chút mơ hồ ở đó, nhưng tôi nghĩ định nghĩa mà chúng tôi đang hướng tới là một loại chiến lược prompting. Nó có thể tự động, nhưng chỉ là một chiến lược duy nhất rất dễ thay thế với bất kỳ loại câu hỏi độc hại nào. Và chiến lược đó liên tục lấy được nhiều thông tin chi tiết từ mô hình AI và bỏ qua các biện pháp bảo vệ của mô hình AI. Và tôi nghĩ một cách để định lượng universal jailbreak là nó thực sự giúp tăng tốc độ của một người rất nhiều, bởi vì thay vì phải jailbreak từng truy vấn cụ thể, họ có thể chỉ cần sử dụng một jailbreak cho tất cả các truy vấn, điều này thực sự nhanh hơn rất nhiều. Vì vậy, tôi đoán một ý tưởng là nếu có một cách làm điều gì đó dễ dàng hơn nhiều mà không cần sử dụng mô hình AI, thì không có lý do gì để sử dụng mô hình AI. Vì vậy, việc không có các universal jailbreak có thể có nghĩa là họ sẽ thử các chiến lược khác, điều này có thể tệ hơn hoặc đại loại như vậy.

Một điều tôi có thể bổ sung là sự khác biệt giữa universal jailbreak và các jailbreak không universal là đối với các jailbreak không universal, bạn có thể cần phải jailbreak mô hình AI cụ thể cho từng câu hỏi độc hại mà bạn muốn trả lời. Sau đó, bạn có một câu hỏi mới, giống như một câu hỏi mới, vâng, tôi không biết, câu hỏi tiếp theo của bạn trong quá trình phát triển vũ khí mới của bạn hoặc bất cứ điều gì, và sau đó bạn cần phải jailbreak mô hình AI một lần nữa. Tôi nghĩ về cơ bản thì toàn bộ quá trình đó, nếu bạn cần làm điều đó hàng trăm hoặc hàng nghìn lần, thì rất tốn kém, trong khi nếu bạn chỉ cần tìm một chiến lược jailbreak cho mô hình AI của mình ngay từ đầu, giống như một prompt duy nhất mà bạn chỉ cần thay thế một câu hỏi mới, điều đó làm cho tổng công sức để jailbreak thấp hơn nhiều. Vì vậy, đối với tôi, đó là một trong những động lực chính để tập trung vào các cuộc tấn công universal.

Ví dụ về các loại Jailbreak

Vâng, bây giờ tôi sẽ đưa ra một ví dụ theo cách tôi nghĩ về nó. Giả sử tôi muốn làm bánh nhưng không thể làm được vì tôi chưa bao giờ nướng bánh trong đời. Tôi không biết gì về nguyên liệu. Tôi không biết mọi thứ hoạt động như thế nào. Vậy làm thế nào một mô hình AI có thể giúp tôi làm điều gì đó mà tôi không thể làm được? Nếu tôi cần làm bánh, tôi sẽ cần đặt nhiều truy vấn khác nhau. Giống như, tôi sẽ cho thứ gì đó vào lò nướng. Tôi cần biết nhiệt độ có đúng không, mùi có đúng không, lấy nó ra, thực hiện kiểm tra, vứt bỏ tất cả các nguyên liệu. Vì vậy, một điều tôi nghĩ thực sự quan trọng trong định nghĩa universal jailbreak là bạn rất tự tin rằng thông tin bạn nhận được từ mô hình AI thực sự hữu ích cho điều bạn quan tâm. Có một số kỹ thuật chỉ lấy được một chút thông tin hoặc lấy được một số thông tin nhưng nó lại lẫn với nhiều thứ khác. Nhưng đối với những kịch bản mà một kẻ xấu không thể thực hiện một tác vụ đòi hỏi nhiều chuyên môn, chúng tôi lo lắng về việc họ có thể thực hiện tác vụ đó. Chúng tôi nghĩ rằng họ sẽ cần quyền truy cập vào loại universal jailbreak. Họ sẽ cần có khả năng đặt nhiều truy vấn và nhận được thông tin thực sự đáng tin cậy, và họ chỉ cần biết đây là hướng dẫn chính xác. Đây là điều đúng đắn để làm.

Tôi nghĩ một ví dụ về jailbreak không universal mà một người trong nhóm, tôi nghĩ Jesse Mu, đã tìm thấy là anh ấy đã jailbreak để hỏi mô hình AI cách chế tạo meth, anh ấy đã tìm thấy một số jailbreak mà anh ấy đặt mô hình AI vào một kịch bản đóng vai như thể nó là một phần của Breaking Bad, chương trình TV nơi họ chế tạo meth, và sau đó hỏi mô hình AI câu hỏi: "Làm thế nào tôi chế tạo meth?" Loại jailbreak đó bạn có thể hình dung nó sẽ hiệu quả như thế nào đối với loại câu hỏi cụ thể đó, như những thứ liên quan đến meth, nhưng sẽ không khái quát hóa cho những thứ liên quan đến tội phạm mạng. Nhưng mặt khác, có một số jailbreak khác như Do Anything Now jailbreak, khiến mô hình AI làm bất cứ điều gì bằng cách khiến nó nói chuyện ở một chế độ nhất định hoặc đóng vai nói chung cho các câu hỏi tùy ý. Đó sẽ là điều chúng tôi gọi là universal jailbreak. Cũng có những chiến lược khác mà mọi người đã sử dụng để tạo ra những thứ này, như sử dụng mô hình ngôn ngữ lớn để tự động tìm các jailbreak khác nhau. Đó sẽ là một cách tiếp cận năng động hơn có thể khám phá những điều này ngay lập tức, nhưng nếu bạn có một quy trình duy nhất để tạo jailbreak cho một câu hỏi mới, điều đó cũng sẽ được coi là universal.

Tại sao cần Jailbreak một Mô hình AI?

Vâng, và có thể một câu hỏi cơ bản hơn là tại sao lại có lý do để jailbreak mô hình AI ngay từ đầu? Điều đó thậm chí có nghĩa là gì? Tôi nghĩ chúng tôi đã thực hiện rất nhiều công việc, chẳng hạn như công việc AI Hiến pháp của chúng tôi để khiến Claude có những đặc điểm mà nó không thực sự cố gắng cung cấp thông tin có hại nếu nó nghĩ rằng người dùng có thể có ý định xấu hoặc điều gì đó tương tự. Và vì vậy, đối với nhiều câu hỏi độc hại này, nếu bạn chỉ hỏi bản thân câu hỏi đó, rất rõ ràng đây là một câu hỏi xấu. Người dùng đang cố gắng chế tạo vũ khí, hướng dẫn chế tạo meth, điều đó rõ ràng là xấu. Và chúng tôi đã huấn luyện Claude không trả lời những câu hỏi đó. Và vì vậy, jailbreak là cần thiết để thực sự vượt qua những biện pháp bảo vệ đó nhằm khiến Claude thực sự trả lời câu hỏi.

Mô hình phô mai Thụy Sĩ (Swiss Cheese Model) để phòng thủ

Một điều khác có liên quan đến câu hỏi huấn luyện Hama Sims là tôi đoán có nhiều cách khác nhau mà mọi người có thể trình bày các jailbreak cho mô hình AI. Và cũng có nhiều tác vụ khác nhau mà mô hình AI cần có khả năng thực hiện trong cuộc sống hàng ngày, nói một cách dễ hiểu. Và tôi nghĩ việc có thêm một bộ hệ thống AI được thiết kế đặc biệt để chống lại jailbreak thực sự có thể giúp có một loại phương pháp giống như mô hình "phô mai Thụy Sĩ" để cố gắng chặn những thứ có hại thông qua nhiều lớp khác nhau hoặc đại loại như vậy. Chúng tôi nói rất nhiều về "phô mai Thụy Sĩ" trong dự án, nhưng bạn biết đấy, điều này không được biết đến rộng rãi ở mọi nơi. Vậy, điều đó có nghĩa là gì?

Vâng, tôi đoán mô hình "phô mai Thụy Sĩ" để bảo vệ chống lại mọi thứ là nếu bạn chỉ có một hệ thống AI để ngăn chặn những điều có hại xảy ra, có thể có một vấn đề cụ thể nào đó với hệ thống AI mà mọi người có thể khai thác và vượt qua mọi lúc. Nhưng sau đó, nếu bạn thêm một lớp phô mai Thụy Sĩ có một lỗ hổng ở một vị trí rất cụ thể. Có thể phần còn lại của phô mai chặn tất cả các nỗ lực gây hại, nhưng có một lỗ hổng cụ thể. Nhưng nếu bạn thêm một lớp phô mai Thụy Sĩ khác, lỗ hổng có thể không ở cùng một vị trí. Vì vậy, nếu bạn có hai lớp phô mai Thụy Sĩ, thực sự sẽ khó khăn hơn nhiều để vượt qua mọi thứ. Mặc dù cả hai đều có thể có lỗ hổng. Vâng, vậy những lớp phô mai này đối với phương pháp của chúng tôi là gì? Chúng ta sẽ nói về constitutional classifiers.

Các Lớp Phòng Thủ của Hệ thống AI

Vâng, đâu là các lớp phòng thủ khác nhau mà chúng ta đang hướng tới ở đây? Lớp đầu tiên sẽ là bộ phân loại đầu vào của chúng tôi. Bộ phân loại đầu vào ở đây về cơ bản sẽ xem xét toàn bộ cuộc trò chuyện mà người dùng truyền vào mô hình AI. Đó là lớp đầu tiên. Sau đó, lớp thứ hai là nếu nó vượt qua bộ phân loại đầu vào, Claude (là mô hình AI chúng ta đang cố gắng bảo vệ) thực sự có thể từ chối trả lời câu hỏi. Đây giống như một lớp nữa để Claude tự nói rằng: "Được thôi, có lẽ câu hỏi này không ổn lắm. Có lẽ tôi không nên trả lời." Cuối cùng, chúng tôi có bộ phân loại đầu ra, bộ này sẽ xem xét đầu ra của Claude trong thời gian thực. Nếu nó phát hiện bất kỳ điều gì có vẻ nguy hiểm hoặc đi ngược lại giá trị chúng tôi đang cố gắng ngăn chặn, thì nó cũng có thể chọn dừng đầu ra của Claude và chặn phản hồi.

Phân Loại Hiến Định và Quy Tắc Ngôn Ngữ Tự Nhiên

Vậy các bộ phân loại này đang tìm kiếm điều gì và chúng ta chỉ định những gì cần tìm như thế nào? Trong bài báo của chúng tôi, chúng tôi gọi chúng là các bộ phân loại hiến định vì chúng tôi có một bộ quy tắc bằng ngôn ngữ tự nhiên. Đây là một bộ quy tắc mà chúng tôi có thể chỉ định các danh mục chủ đề không được phép thảo luận. Ví dụ, như: "Tôi đang tạo ra một vũ khí hủy diệt hàng loạt." Rõ ràng là xấu. Và chúng tôi có thể chỉ định rằng Claude không được hướng dẫn người dùng cách làm điều đó. Sau đó, chúng tôi cũng có thể chỉ định một số ví dụ về những nội dung vô hại mà Claude được phép nói đến. Về cơ bản, chúng tôi huấn luyện các bộ phân loại của mình để phân loại xem cuộc trò chuyện hoặc đầu ra có liên quan đến các danh mục có hại hoặc vô hại này hay không. Điều này cho phép chúng tôi đưa ra quyết định có chặn nó hay không.

Điều quan trọng là, tôi cho rằng bộ phân loại đầu vào và bộ phân loại đầu ra đang thực hiện hai tác vụ khác nhau. Quay trở lại phép so sánh với pho mát Thụy Sĩ, chúng tôi hy vọng các lỗ trên miếng pho mát sẽ ở những vị trí khác nhau, đặc biệt là đối với bộ phân loại đầu vào và bộ phân loại đầu ra. Vì vậy, tôi đoán bộ phân loại đầu vào đang thực hiện điều khá đơn giản mà bạn mong đợi: nó thực sự nhìn vào câu lệnh của người dùng và cố gắng tìm ra xem có điều gì có hại đang diễn ra hay không. Nhưng điều quan trọng là, một trong những lý do bạn có thể cần bộ phân loại đầu ra cũng như bộ phân loại đầu vào là vì mọi người đang cố gắng hết sức để jailbreak mô hình AI và bộ phân loại đầu vào trong câu lệnh. Và nếu bạn có một bộ phân loại đầu ra hoàn toàn riêng biệt, chỉ xem xét đầu ra, thì nó sẽ chỉ xem xét những thứ mà bản thân mô hình AI đã tạo ra. Vì vậy, nó phần nào tách biệt khỏi những gì người dùng đã nhập vào. Hai phần của hệ thống AI đang xem xét trực tiếp những gì người dùng đã nhập. Nhưng chúng tôi cũng có một phần thứ ba được giữ lại của hệ thống AI mà người dùng thực sự không thể chạm vào trực tiếp, điều này làm cho việc jailbreak hoàn toàn hệ thống AI trở nên khó khăn hơn rất nhiều. Và mặc dù bộ phân loại đầu vào và Claude đang thực hiện phần lớn công việc đó theo cách trên, tôi không biết, nhưng nó đang làm một điều quan trọng như là thành phần cuối cùng, quan trọng để thực sự giảm thiểu tỷ lệ nội dung có hại/vô hại.

Cân Bằng Giữa An Toàn và Hữu Ích

Điều này đúng theo một nghĩa nào đó. Nhưng hầu hết mọi người không sử dụng Claude cho mục đích này. Bạn biết đấy, phần lớn thời gian khi người dùng đưa ra câu lệnh, họ chỉ đang thực hiện một tác vụ hoàn toàn chính đáng, một ứng dụng thực sự có lợi. Vì vậy, chúng ta có thể có những bộ phận bảo vệ chỉ chặn mọi thứ, điều đó sẽ hoàn toàn vô ích. Vậy, làm thế nào để chúng ta đảm bảo rằng mình không quá cứng nhắc trong việc này? Tôi nghĩ chúng tôi thực sự muốn một phần lý do chúng tôi thiết kế những kỹ thuật này là để cho phép các mô hình AI thực hiện càng nhiều nội dung hữu ích và công việc hữu ích càng tốt. Chẳng hạn, chúng ta có những kỹ thuật tốt hơn để chặn chính xác nội dung thực sự có hại, thì chúng ta càng ít gặp phải dương tính giả đối với những người dùng đang sử dụng mô hình AI cho những ứng dụng thực sự tốt. Tôi nghĩ phương pháp bộ phân loại đã đạt được một số tiến bộ và có thể tốt hơn các phương pháp khác, chẳng hạn như trực tiếp huấn luyện mô hình AI từ chối. Và vì vậy, tôi nghĩ hy vọng điều này sẽ giúp chúng tôi cho phép người dùng trò chuyện với Claude về nhiều chủ đề CBR và các chủ đề liên quan an toàn để thảo luận. Và vì vậy, tôi nghĩ hy vọng của chúng tôi chắc chắn là cho phép nhiều ứng dụng đó phát triển mạnh, đồng thời chỉ chặn một cách hẹp những thứ mà chúng tôi nghĩ, chúng tôi tin là nguy hiểm.

Tôi đoán điều quan trọng nữa là, tôi nghĩ chúng tôi thường nói đùa rằng nếu chúng ta chỉ có một tảng đá làm mô hình AI, thì nó sẽ cực kỳ vô hại vì nó sẽ không trả lời bất kỳ câu lệnh có hại nào, nhưng thật không may, nó sẽ không hữu ích lắm. Vì vậy, tôi nghĩ, đảm bảo rằng chúng ta không chặn các câu lệnh vô hại thực sự là điều khá quan trọng. Và cũng thực sự khá khó khăn.

Tính Bền Vững và Mô Hình Hóa Mối Đe Dọa

Vâng, và Max, anh đã đề cập trước đó về việc giải quyết các jailbreak hoặc đạt được tiến bộ trong vấn đề tính bền vững này, vậy anh sẽ định nghĩa điều đó như thế nào hoặc nó thực sự có ý nghĩa gì? Tôi đoán đây là một câu hỏi rất khó. Tôi nghĩ nó bao gồm một loạt các lớp khác nhau. Đầu tiên, có ý tưởng về mô hình hóa mối đe dọa: bạn phải có một ý niệm về việc điều gì được coi là có hại. Đội red team của Frontier đã thực hiện một số công việc trong việc cố gắng xác định những điều chúng tôi thực sự lo ngại. Và điều này khá khó khăn vì như Ethan đã nói, chúng ta đang nói rất nhiều về các mô hình AI tương lai và các khả năng mô hình AI tiềm năng trong tương lai mà chúng ta có thể thực sự lo lắng.

Vì vậy, tôi nghĩ một phần của việc này là lập bản đồ những gì có thể gây hại mà chúng ta có thể cần phải giải quyết. Vậy mô hình hóa mối đe dọa là gì, điều gì thực sự có hại? Sau đó, có tác vụ thực sự đo lường những thứ có hại. Điều đó liên quan rất nhiều đến việc, tôi đoán chúng tôi đang sử dụng một hiến pháp để xác định mô hình hóa mối đe dọa và sau đó có các mô hình AI tạo ra nhiều dữ liệu tổng hợp khác nhau để cố gắng liệt kê các điều có hại khác nhau có thể xảy ra. Vì vậy, đo lường tỷ lệ dương tính thực trên dữ liệu. Nhưng sau đó cũng phải cố gắng đảm bảo rằng chúng ta không từ chối quá nhiều dữ liệu thực từ Claude.ai và đảm bảo rằng chúng ta thực sự có thể, tôi không biết, hữu ích nhất có thể trong khi vẫn an toàn.

Hiến Pháp và Dữ Liệu Tổng Hợp

Vậy hiến pháp thực sự là gì? Bạn biết đấy, đây là các bộ phân loại hiến định. Chúng ta đang nói về một hiến pháp. Điều đó có nghĩa là gì? Vâng, hiến pháp ở đây chỉ có nghĩa là một số liệt kê các danh mục yêu cầu và cuộc trò chuyện mà chúng ta coi là có hại so với không có hại. Và các ví dụ ở đây có thể là, vâng, bạn biết đấy, các câu hỏi về cách chế tạo vũ khí hủy diệt hàng loạt hoặc cố gắng tìm nguồn nguyên liệu để chế tạo vũ khí hủy diệt hàng loạt. Và sau đó chúng tôi về cơ bản chỉ liệt kê một số danh mục này. Và sau đó chúng tôi cũng chỉ định một số danh mục nội dung vô hại như, tôi không biết, viết thơ hoặc viết mã cho các trường hợp sử dụng bình thường. Và sau đó chúng tôi chỉ có thể chỉ định những điều này. Và sau đó, như Max đã nói, chúng tôi tạo ra một lượng lớn dữ liệu tổng hợp cung cấp các trường hợp cụ thể hơn của chúng.

Dữ liệu tổng hợp nghĩa là gì? Vâng, ở đây dữ liệu chúng tôi muốn nói là chúng tôi bắt đầu từ các danh mục yêu cầu người dùng rộng này. Và sau đó chúng tôi có Claude thực sự phân nhánh và nghĩ về tất cả các yêu cầu cụ thể có thể là ví dụ của loại danh mục rộng hơn này. Và vì vậy, vâng, danh mục có thể là một cái gì đó như tìm nguồn nguyên liệu để chế tạo vũ khí hủy diệt hàng loạt. Và sau đó yêu cầu phụ có thể là: "Ồ, tôi có thể đi đến những cửa hàng cụ thể nào?" hoặc "Những vật liệu cụ thể này có thể tiếp cận được ở bang X không?". Và vì vậy chúng tôi có quy trình này để tự động thực hiện điều đó. Và điều đó cho phép chúng tôi tạo ra một lượng lớn dữ liệu tổng hợp từ chỉ một số ít danh mục.

Tính Linh Hoạt và Phản Ứng Nhanh

Vâng. Và tôi nghĩ một điều tôi thấy thực sự thú vị về phương pháp này là nó chỉ dựa trên ngôn ngữ tự nhiên. Bạn biết đấy, chúng ta đã nói về mô hình hóa mối đe dọa trước đây, và mô hình hóa mối đe dọa, ít nhất trong kinh nghiệm của tôi và kinh nghiệm làm việc với Frontier Red team, là thực sự khó khăn. Bạn biết đấy, có rất nhiều người dùng Claude. Thực sự khó để biết tất cả những điều có thể xảy ra là gì. Và chúng ta sẽ học được những điều mới, bạn biết đấy, khi chúng ta có giám sát và như bạn biết, chúng ta luôn học được những mối đe dọa mới hoặc những điều mới có thể xảy ra.

Tuy nhiên, điều tôi thấy thực sự thú vị về phương pháp này là về cơ bản, nếu bạn muốn thay đổi hiến pháp, nếu bạn muốn thay đổi những gì đang bị chặn vì bạn đã học được điều gì đó mới, bạn biết đấy, có thể những điều đó xuất hiện trên tin tức hoặc có một số thông tin tình báo hoặc giám sát. Điều duy nhất bạn thực sự cần làm là bạn chỉ cần viết lại hiến pháp. Và cách tiếp cận tiêu chuẩn cho các bộ phân loại là bạn sẽ yêu cầu con người thu thập rất nhiều dữ liệu. Vì vậy, bạn biết đấy, điều gì đó có thể xảy ra là, ồ, chúng ta đang thực sự tập trung vào, bạn biết đấy, một danh mục như một cách cụ thể về, bạn biết đấy, có thể là lạm dụng không gian mạng. Nhưng sau đó chúng ta nhận ra rằng, ồ, thực ra, điều này nguy hiểm hơn nhiều hoặc điều gì đó chúng ta vừa học được điều gì đó mới hoặc ai đó đã thông báo cho chúng ta. Điều tôi thực sự hào hứng là đây là một cách mà, tôi nghĩ chúng ta có thể đạt được tính bền vững tốt, nhưng chúng ta có thể duy trì tính linh hoạt của mình và thực sự duy trì khả năng phản ứng với các mối đe dọa mới và thích nghi với những gì đang thực sự diễn ra. Bởi vì vâng, tôi cảm thấy đây chỉ là bài học mà chúng ta học được hết lần này đến lần khác, bạn biết đấy, nếu bạn không có tính linh hoạt, nó sẽ trở thành một vấn đề. Nó sẽ hạn chế chúng ta.

Tôi thực sự muốn đưa ra một điểm nhanh về tính linh hoạt, đó là tôi nghĩ phương pháp của chúng tôi không chỉ linh hoạt trong việc chuyển đổi các chủ đề chung. Ví dụ, nếu bạn muốn chuyển đổi giữa an ninh mạng và, tôi không biết, vũ khí hủy diệt hàng loạt hoặc đại loại thế. Nhưng tôi nghĩ nó cũng chi tiết hơn nhiều so với vậy ở chỗ, trong dự án này, chúng tôi thấy rằng có một số yêu cầu mà các bộ phân loại ban đầu của chúng tôi luôn rất nghi ngờ, nhưng thực ra chúng là vô hại. Và những gì chúng tôi có thể làm là chúng tôi thực sự có thể chỉ cần chỉnh sửa hiến pháp và thêm một câu nói rằng: "Ồ, những loại yêu cầu này là được." Và sau đó khi chúng tôi huấn luyện lại các bộ phân loại trên dữ liệu mới đó, các bộ phân loại sẽ không còn đánh dấu các câu lệnh vô hại đó nữa. Vì vậy, tôi nghĩ điều đó cho phép bạn có rất nhiều kiểm soát chi tiết về chính xác những gì bộ phân loại của bạn đang cố gắng gắn cờ, đặc biệt nếu bạn thấy nhiều trường hợp từ chối quá mức hoặc các vấn đề với việc bỏ sót nội dung.

Vâng, tôi nghĩ đây cũng có thể là một nơi tốt để nhắc đến. Chúng tôi đã có một bài báo trước đó về phản ứng nhanh nơi chúng tôi đã tận dụng một ý tưởng tương tự để cải thiện các biện pháp bảo vệ xung quanh các mô hình AI. Và tôi nghĩ về cơ bản, một tính năng hay của việc sử dụng dữ liệu tổng hợp là nếu bạn phát hiện không chỉ một loại jailbreak mới, mà là một kiểu jailbreak mới có thể áp dụng. Ví dụ, giả sử chúng ta phát hiện một jailbreak phổ quát mới như câu lệnh "hãy làm bất cứ điều gì bây giờ". Chúng ta có thể lấy đó, sử dụng một LLM để tạo ra các biến thể của nó và sau đó đưa vào hỗn hợp dữ liệu. Và tôi nghĩ, vâng, theo tôi hiểu thì điều này thực sự hữu ích cho chúng tôi trong việc phát triển các bộ phân loại đến mức tính bền vững mà chúng tôi đạt được. Nếu ai đó báo cáo một jailbreak hoặc lỗ hổng mới, thì chúng ta có thể sử dụng điều đó để cập nhật bộ phân loại rất nhanh chóng bằng cách sử dụng một quy trình tạo dữ liệu tổng hợp.

Giảm thiểu thời gian jailbreak

Điều này sẽ thực sự giảm thiểu tỷ lệ thời gian mà một jailbreak nổi bật tồn tại, qua đó khiến các mô hình trí tuệ nhân tạo dễ bị tổn thương trong khoảng thời gian ngắn nhất có thể. Đây là quan niệm phổ biến, tôi cho rằng việc giải quyết triệt để vấn đề bảo mật về cơ bản là không thể. Không có hệ thống AI nào được biết đến là hoàn toàn an toàn đối với nhân loại. Vì vậy, tôi đoán chúng tôi muốn có sự linh hoạt khi chúng tôi chặn nhầm thứ gì đó hoặc chặn nhầm những người dùng vô hại. Nhưng khi mọi người tìm ra những cách để vượt qua hệ thống AI, chúng tôi muốn có thể khắc phục chúng thật nhanh chóng.

Tính linh hoạt của bộ phân loại trong chống jailbreak

Tôi nghĩ một phần trong cách tiếp cận của chúng tôi là chúng tôi đã mô hình hóa các jailbreak theo cách rất dễ dàng để chúng tôi thêm các ví dụ về các jailbreak mới vào training pipeline của mình. Và do đó, nếu các jailbreak mới được phát hiện, chúng tôi khá dễ dàng tạo ra nhiều ví dụ hơn về các jailbreak đó và sau đó huấn luyện trên chúng. Sau đó, hy vọng các bộ phân loại đó cũng sẽ mạnh mẽ hơn.

Ưu điểm của bộ phân loại trong Deployment

Một điều khác tôi muốn bổ sung về các bộ phân loại là chúng được tách rời khỏi mô hình trí tuệ nhân tạo tạo văn bản thực tế. Và nếu bạn... tôi nghĩ việc cập nhật mô hình trí tuệ nhân tạo tạo văn bản thường rất khó khăn. Nếu bạn huấn luyện nó từ chối trong một lĩnh vực, có thể điều đó sẽ khái quát hóa theo những cách không rõ ràng sang hành vi trong các lĩnh vực khác hoặc hành vi từ chối nói chung. Tôi nghĩ chúng tôi chắc chắn đã gặp một số khó khăn khi thực hiện công việc sơ bộ về điều đó. Nhưng tôi nghĩ với các bộ phân loại, bạn chỉ cần giữ nguyên việc tạo văn bản, và bạn biết rằng nó giống hệt với mô hình trí tuệ nhân tạo đã được Triển khai trước đó. Tôi nghĩ điều đó mang lại cho khách hàng rất nhiều sự đảm bảo rằng không có thay đổi lớn nào xảy ra nói chung đối với mô hình trí tuệ nhân tạo, loại văn bản đầu ra mà bạn đang nhận được, và những thay đổi duy nhất được thực hiện chỉ là quyết định chặn hoặc không chặn, mà bạn có thể lặp lại riêng biệt khỏi mô hình trí tuệ nhân tạo. Vì vậy, tôi nghĩ điều đó cũng giúp việc Triển khai nhanh chóng trở nên dễ dàng hơn nhiều so với việc chúng tôi có thể làm theo cách khác.

Phát triển phương pháp tiếp cận dựa trên bộ phân loại

Vậy làm thế nào chúng tôi đưa ra cách tiếp cận này? Đó là một câu hỏi hay. Tôi cảm thấy chúng tôi đã dành rất nhiều thời gian để suy nghĩ về nó. Tôi nghĩ các bộ phân loại nổi bật vì những lý do mà chúng tôi vừa nói: cực kỳ linh hoạt, có thể dễ dàng cập nhật để ứng phó với nhiều mối đe dọa mới lạ. Vâng, tôi nghĩ threat modeling thực sự khó khăn, vì vậy có một công cụ siêu linh hoạt là rất tuyệt. Nó nhẹ, không làm tăng inference cost nhiều như... Tôi đoán chúng tôi có thể chắt lọc một số quy tắc cấu thành phức tạp thành một thứ tương đối nhỏ. Và vâng, tôi nghĩ tất cả những điều này khiến bộ phân loại trở thành một cách hay để lặp lại rất nhanh chóng các loại điều mà nó hy vọng đạt được. Và sau đó, tôi đoán chúng tôi đã thử nó và có vẻ như nó hoạt động, vì vậy chúng tôi tiếp tục.

Chính sách mở rộng quy mô có trách nhiệm (RSP) của Anthropic

Tôi nghĩ điều này thực sự là do responsible scaling policy mà Anthropic đã có. Và vâng, ý tôi là, tôi nghĩ chúng tôi đã làm các nghiên cứu về an toàn khác nếu không có responsible scaling policy. Responsible scaling policy là gì? Vâng, responsible scaling policy về cơ bản là kế hoạch của Anthropic để đảm bảo rằng các Deployment của chúng tôi là an toàn. Và vâng, về cơ bản nó vạch ra các ranh giới đỏ khác nhau cho ngưỡng năng lực, tại đó về cơ bản có một rủi ro mới xuất hiện với các mô hình trí tuệ nhân tạo có khả năng cao hơn. Giả sử các mô hình trí tuệ nhân tạo có khả năng phát triển một loại hóa chất rất nguy hiểm, thì biện pháp giảm thiểu liên quan trong RSP là đạt được một mức độ robustness đủ cao đối với các jailbreak để mô hình trí tuệ nhân tạo trên thực tế, với biện pháp giảm thiểu, không đủ hữu ích cho một kẻ thù muốn làm điều đó.

Vì vậy, vâng, tôi nghĩ trong RSP ban đầu có cam kết rằng một khi các mô hình trí tuệ nhân tạo đạt đến một mức độ năng lực đủ để hỗ trợ việc phổ biến kiến thức về các weapons of mass destruction đã biết, thì chúng tôi sẽ có khả năng để... lời văn mơ hồ, nhưng về cơ bản là vượt qua red teaming thành công. Giống như, RSP đã được viết, công ty đã cam kết công khai điều này, và Jared Kaplan, người đứng đầu bộ phận nghiên cứu tại Anthropic, đã đến gặp chúng tôi, và những người khác cũng đến gặp chúng tôi và đưa ra dòng này cho chúng tôi, và chúng tôi nói, "Này, các bạn nên cố gắng giải quyết robustness." Đầu tiên chúng tôi đã ghi nhớ dòng đó. Chúng tôi in nó ra. Chúng tôi đóng khung nó và đặt nó trên bàn làm việc của chúng tôi. Vâng, đó là điều chúng tôi đang thực hiện.

Vâng, và sau đó tôi nghĩ rằng việc suy nghĩ về dòng đó trong RSP thực sự đã khiến chúng tôi suy ngẫm về những lựa chọn cuộc sống của mình về những nghiên cứu mà chúng tôi đang làm, cả về việc liệu chúng tôi có nên làm về robustness hay không. Vâng, theo nghĩa đó, nó thực sự làm rõ: "Được rồi, có những tác hại đáng kể có thể xuất hiện trong một hoặc hai thế hệ mô hình trí tuệ nhân tạo tiếp theo nếu chúng ta không giải quyết vấn đề này." Vì vậy, sự cấp bách cao hơn các vấn đề khác mà chúng ta có thể muốn giải quyết. Và sau đó, cũng về các cách tiếp cận cụ thể mà chúng tôi sẽ thực hiện... Tôi nghĩ, bạn biết đấy, ban đầu khi chúng tôi nghĩ, "Ồ, chúng ta nên làm một số nghiên cứu về robustness." Tôi nghĩ chế độ chung mà tôi đã từng làm nghiên cứu, và nhiều nhà nghiên cứu khác nói chung, chỉ là, "Được rồi, hãy giải quyết một số vấn đề nghiên cứu thú vị, hữu ích ở đây, khám phá một số câu hỏi, viết một số bài báo." Và tôi nghĩ đó là điều mà nhiều người trong nhóm biết cách làm tốt, và chúng tôi đã khám phá một loạt các cách tiếp cận có lẽ nổi bật hơn. Tôi nghĩ có rất nhiều điều thú vị ở đây đối với tôi. Một điều là, ngay khi điều này bắt đầu, tôi vừa mới hoàn thành bằng tiến sĩ, hoặc gần thời điểm hoàn thành bằng tiến sĩ, và điều về bộ phân loại này... đây là slogan của Anthropic, và có lẽ slogan của Anthropic là, "Làm điều ngớ ngẩn mà hiệu quả." Và tôi nghĩ loại nghiên cứu này thường là loại điều mà có lẽ không quá bóng bẩy hay thú vị đối với các nhà nghiên cứu. Và tôi nhớ, vâng, tôi nghĩ nếu không có RSP nói rằng, "Được rồi, thực tế mà nói, nếu chúng ta quan tâm đến những rủi ro này và chúng ta nghĩ chúng là thật, thì cách nào để đạt được điều đó?" và gạt bỏ ý nghĩ này, "Ồ, điều gì thú vị hơn hay bóng bẩy hơn," thì đó là, "Cách nào chúng ta thực sự có thể làm cho điều này an toàn?" Theo một nghĩa nào đó, công việc của chúng tôi là, bạn biết đấy, chúng tôi thực sự đang nghĩ, "Chà, bạn biết đấy, điều này không xảy ra bây giờ, như những hệ thống AI trong tương lai." Vì vậy, tôi chỉ nghĩ, "Điều đó đã như thế nào, bạn biết đấy, đối với mỗi người trong số các bạn, và từng cá nhân khi làm việc tại Anthropic, và như thể đang ở giữa tất cả những điều này?"

Đối phó với rủi ro của mô hình trí tuệ nhân tạo trong tương lai

Vâng, tôi nghĩ họ rất nghiêm túc với các rủi ro an toàn của các mô hình trí tuệ nhân tạo trong tương lai. Tôi nghĩ có những rủi ro rất thực tế; rõ ràng có những misuse risks mà bạn đã đề cập với các CBRN risks, đó là các chemical, radiological, biological, và nuclear risks, nhưng cũng có những misalignment risks rất thực tế. Và tôi nghĩ việc đối phó với chúng thực sự khó khăn. Tôi nghĩ một trong những điều tôi thấy tốt là tôi nghĩ chúng tôi, với tư cách là một nhóm, rất cam kết thực sự cố gắng giải quyết các vấn đề. Và tôi nghĩ việc thực hiện dự án về bộ phân loại là một bằng chứng cho thấy chúng tôi thực sự quan tâm đến việc giải quyết các vấn đề này, và chúng tôi thực sự muốn tìm một giải pháp thực nghiệm để làm mọi việc, thay vì, như bạn đang ám chỉ, chỉ làm nghiên cứu trông có vẻ tốt nhưng thực tế không đạt được điều gì. Tôi nghĩ chúng tôi đã dành rất nhiều thời gian để làm những việc rất... Tôi không biết, tôi không thực sự muốn có một bài báo từ đó, nhưng tôi nghĩ chúng tôi thực sự đã quản lý để đạt được điều gì đó thực tế hơn một chút, điều mà tôi nghĩ là tốt, và tôi cảm thấy điều này chỉ là... đây là một bước tiến, nhưng còn một chặng đường dài phía trước đối với tôi.

Tối ưu hóa rủi ro và sự tiến bộ trong Trí tuệ nhân tạo

Ý tôi là, tôi đoán tôi lạc quan hơn một chút. Tôi nghĩ chắc chắn có một rủi ro thực sự, nhưng tôi cảm thấy chúng tôi đang đạt được tiến bộ khá tốt, và tôi nghĩ có lẽ nếu chúng tôi tiếp tục làm việc một cách thực dụng trên các vấn đề, chúng tôi có thể đạt được rất nhiều tiến bộ và chỉ giảm thiểu rủi ro một cách đáng kể. Tôi không nghĩ chúng tôi sẽ bao giờ giảm rủi ro của AI xuống bằng không, nhưng tôi coi AI như một công cụ, và nếu chúng tôi áp dụng các biện pháp bảo vệ đúng đắn và chúng tôi thực hiện nghiên cứu quan trọng, tôi nghĩ chúng tôi có thể đạt được rất nhiều tiến bộ ở đây, và đó là điều tốt nhất mà chúng tôi có thể làm. Vâng, ý tôi là, tôi nghĩ về mặt tình cảm, tôi khá giống với Meg về việc, "Vâng, tôi nghĩ có những rủi ro rất nghiêm trọng ở đây." Tôi chắc chắn khá lo ngại về rất nhiều rủi ro, và vâng, tôi đoán tôi nghĩ, "Chà, điều tốt nhất tôi có thể làm là giúp giảm rủi ro đi một chút." Tôi nghĩ dự án này đã đạt được một số tiến bộ về điều đó, và tôi khá hào hứng với điều đó.

Tầm Quan Trọng và Tiến Độ Công Việc

Đôi khi, cảm giác thật choáng ngợp, như thể phải thực sự thấu hiểu những gì có thể xảy ra. Tuy nhiên, tôi có mong muốn là sẽ có mặt ở đây và làm việc một cách đáng tin cậy. Dù có những thách thức, nhưng chúng ta có thể đạt được tiến bộ, và tôi cảm thấy chúng ta đã đạt được nhiều tiến bộ. Tôi thực sự rất vui mừng được chia sẻ tiến độ này với những người khác. Chúng tôi có thể đã không viết một bài báo, nhưng chúng tôi đã quyết định viết để công bố và chia sẻ phương pháp tiếp cận này. Vâng, đôi khi là cảm giác choáng ngợp, nhưng những lúc khác lại là cảm giác thực sự vinh dự và tự hào, kiểu như: "Chà, tôi cảm thấy mình đang thực sự làm một công việc có ý nghĩa và quan trọng." Và cũng không quên tất cả những điều tốt đẹp có thể xảy ra với AI thực sự mang lại lợi ích.

Đánh Giá Tiến Độ về Độ Mạnh Mẽ (Robustness)

Vâng, một điều chúng tôi đã đề cập ở đây là chúng tôi tin rằng mình đã đạt được tiến bộ về độ mạnh mẽ (robustness). Chúng tôi đã kiểm tra điều này như thế nào? Làm sao chúng tôi biết? Chúng tôi nghĩ tiến độ đó có nghĩa là gì? Tôi cho rằng, tóm tắt chung về việc liệu chúng ta có đang đạt được tiến bộ hay không, chủ yếu là việc tìm kiếm một universal jailbreak cho một hệ thống AI khó đến mức nào mà không làm tăng quá nhiều tỷ lệ từ chối quá mức (over-refusal) hoặc tăng chi phí tính toán (compute costs) của bất kỳ hệ thống AI nào bạn đang cố gắng triển khai. Có nhiều cách khác nhau để đo lường từng khía cạnh đó. Trong bài báo của chúng tôi, một cách để xem xét việc tìm kiếm universal jailbreak khó đến mức nào là chúng tôi thực sự đã nhờ những người red team chuyên nghiệp (human red teamers) cố gắng tìm các jailbreak cho hệ thống AI của chúng tôi. Sau đó, chúng tôi theo dõi xem họ mất bao nhiêu giờ để tìm một universal jailbreak và liệu họ có tìm thấy hay không. Vậy, bạn có thể thực sự cho tôi biết tình hình của chúng ta trước khi dự án bắt đầu không?

Tình Trạng Ban Đầu của Hệ Thống

Vâng, tôi cho rằng ban đầu chúng tôi đã có, trước hết, nếu bạn chỉ có bản thân mô hình AI, nó đã có một số huấn luyện cơ bản để cố gắng từ chối các truy vấn có hại. Nhưng tất nhiên, có rất nhiều jailbreak tồn tại và hoạt động trên các mô hình AI của chúng tôi. Những jailbreak đó cũng có sẵn trên internet. Vì vậy, về lý thuyết, bất kỳ ai cũng có thể jailbreak các mô hình AI. Sẽ khó đến mức nào nếu tôi muốn jailbreak một mô hình AI ngay bây giờ? Bạn có thể lên Twitter và tìm các jailbreak hiện có và về cơ bản, chỉ trong vài phút, jailbreak một mô hình AI hiện có. Tôi nghĩ có những ví dụ trên Twitter, nơi khi một mô hình AI được demo trực tiếp lần đầu tiên và vừa được công khai API, ai đó đã jailbreak nó và ngay lập tức đăng tải. Đó là mức độ mạnh mẽ (robustness) trước đây với một universal jailbreak. Vâng, đó là mức độ mạnh mẽ khi chúng tôi bắt đầu dự án này.

Cải Thiện Đáng Kể về Độ Mạnh Mẽ

Và bây giờ, để nói thẳng vấn đề: với các hệ thống AI sử dụng bộ phân loại dựa trên Hiến pháp (constitutional classifiers), chúng tôi đã có thể đạt được hàng nghìn giờ mạnh mẽ (robustness) đối với red teaming. Chúng tôi thực hiện red teaming quy mô rất lớn với những người đã thử nghiệm các hệ thống AI của chúng tôi, bao gồm cả những người red team chuyên nghiệp (expert red teamers). Gần đây đã công bố cho red teaming công khai và phải mất hơn 3.000 giờ red teaming để mọi người tìm thấy một universal jailbreak. Vì vậy, tôi nghĩ về mặt chuyển từ vài phút lên hàng nghìn giờ, đó là một mức độ mạnh mẽ hơn nhiều bậc. Vẫn còn một số universal jailbreak và chúng tôi cần phải vá lỗi các bộ phân loại và những thứ tương tự, nhưng tôi nghĩ đây là một tiến bộ rất lớn.

So Sánh Hệ Thống và Giảm Tỷ Lệ Từ Chối Quá Mức

Vâng, tôi nghĩ rằng chúng tôi đã có một hệ thống AI mà bạn có thể jailbreak khá dễ dàng. Bạn đọc một bài báo, lên Twitter, và sau đó red team hệ thống AI đó. Trở lại tháng 9, nó không hoàn toàn là một "tảng đá" (tức là không phản hồi), nhưng kiểu như, bạn hỏi câu hỏi và một nửa thời gian nó sẽ "tảng đá" (từ chối trả lời), không đưa ra phản hồi nào. Vì vậy, nó khá mạnh mẽ (robust) nhưng không hoạt động tốt lắm cho hầu hết người dùng thông thường, đúng không? Nhưng hệ thống AI đó cũng đã đạt được hàng nghìn giờ chống lại universal jailbreak. Và sau đó, một số bản demo mà chúng tôi vừa tung ra, vâng, bản đó đang hoạt động tốt hơn rất nhiều về mặt sử dụng của người dùng thông thường và chi phí suy luận (inference costs), cũng như đạt được độ mạnh mẽ (robustness) tốt. Có rất nhiều tiến bộ ở đó và còn nhiều việc phải làm.

Vâng, tôi nghĩ rằng sự so sánh giữa hệ thống AI nguyên mẫu (prototype) tháng 9 của chúng tôi với hệ thống AI mà chúng tôi vừa demo thực sự là một sự khác biệt "một trời một vực". Vì vậy, chúng tôi đã thực hiện rất nhiều phân tích ở đây. Jerry có đồ thị đẹp nhất về tỷ lệ dương tính (positive rate) giảm dần theo thời gian. Vâng, đó thực sự là một trong những điều tuyệt vời nhất tôi từng thấy. Vì vậy, chúng tôi đã đo lường tỷ lệ từ chối quá mức (over-refusal) trên lưu lượng truy cập Claude.ai – đây là lưu lượng truy cập sản xuất của người dùng thực. Chúng tôi đang hoạt động dưới giả định rằng hầu hết mọi người không hỏi về những thứ liên quan đến vũ khí hủy diệt hàng loạt thảm khốc. Và ban đầu, chúng tôi nhận thấy rằng hệ thống AI tháng 9 này đã chặn hơn 40% các yêu cầu lành tính này, điều này khá tệ; bạn đang tiếp cận "tảng đá" ở đó. Nhưng trong hệ thống AI demo của chúng tôi, chúng tôi đã giảm tỷ lệ đó xuống còn 0,38%. Tất nhiên, chúng tôi vẫn muốn giảm con số này hơn nữa, nhưng giữa 40% và 0,38% là sự khác biệt lên đến hai bậc độ lớn.

Cách Đạt Được Những Cải Tiến

Vậy, làm thế nào các bạn thực sự đạt được tất cả những cải tiến đó? Điều này là một điều bạn thấy trong nhiều công trình an toàn trước đây – sự căng thẳng giữa tính gây hại (harmfulness) và tính hữu ích (helpfulness). Và đối với tôi, khá ngạc nhiên khi chúng tôi thực sự có thể đạt được nhiều tiến bộ như vậy. Vậy, làm thế nào chúng tôi đạt được điều đó?

Vâng, tôi nghĩ hai cải tiến chính mà chúng tôi đã thực hiện là: thứ nhất, chúng tôi thực sự tập trung vào ý tưởng bộ phân loại dựa trên Hiến pháp (constitution idea). Chúng tôi làm rõ cách phân định những điều vô hại (harmless). Chúng tôi nhận thấy rằng việc thêm tập hợp các danh mục vô hại này – những thứ mà mô hình AI hoặc bộ phân loại nên cho phép – đã thực sự giảm FPR (tỷ lệ dương tính giả) đi rất nhiều. Chúng tôi có một số kết quả trong bài báo của mình cho điều đó, và tôi nghĩ đó là một trong những thay đổi quan trọng nhất. Các thay đổi khác bao gồm việc củng cố các kiểu jailbreak mà chúng tôi đã huấn luyện, điều này cho phép các mô hình AI khái quát hóa tốt hơn về chính xác jailbreak là gì, thay vì chỉ nghĩ rằng bất cứ điều gì cũng là jailbreak. Điều đó cũng có thể đã giúp ích một chút. Tôi không... vâng, nhưng tôi nghĩ cả hai điều này đều khá hữu ích ở đây.

Vâng, đây thực sự là một biểu đồ đẹp trong bài báo, chỉ hiển thị số lượng điểm dữ liệu và hiệu suất trên các đánh giá (evals), và độ mạnh mẽ (robustness) của nó. Và chúng, theo kiểu "làm điều đơn giản mà hiệu quả," chỉ là một đường thẳng đi lên. Vâng, tôi muốn nói rõ rằng hệ thống AI mà chúng tôi phát hành cho demo vẫn còn rất nhiều dương tính giả (false positives). Nhưng tôi nghĩ, vâng, chúng tôi khá lạc quan về việc tiếp tục giảm tỷ lệ dương tính giả để làm cho một thứ gì đó sẵn sàng cho sản xuất (production-ready). Nhưng vâng, tôi nghĩ đó là tình hình hiện tại của chúng tôi.

Mục Đích và Kết Quả của Bản Demo

Vâng, vậy, tại sao chúng tôi lại thực hiện demo? Mục đích của bản demo là gì? Tôi nghĩ những câu hỏi chính mà chúng tôi muốn trả lời từ bản demo là: Hệ thống AI của chúng tôi có mạnh mẽ (robust) như chúng tôi nghĩ không? Một điều ở đây là từ nguyên mẫu (prototype), chúng tôi đã thực hiện red teaming với con người và biết rằng nó khá mạnh mẽ. Nhưng sau đó, chúng tôi đã phát triển các đánh giá tự động (automated evaluations) của riêng mình và không chắc liệu điều đó có khái quát hóa (generalize) được đối với red teaming thực tế của con người hay không. Vì vậy, một câu hỏi mà chúng tôi muốn trả lời là: Liệu nó có thực sự khái quát hóa được không? Và nếu một bộ phân loại (classifier) hoạt động tốt trên các đánh giá tự động này, liệu nó có thực sự mạnh mẽ trong thực tế không? Việc có được câu trả lời đó là một điều quan trọng. Và tôi nghĩ một điều khác ở đây chỉ là để mọi người dùng thử hệ thống AI và xem liệu nó có thực sự từ chối quá mức (over-refusing) hay không. Tôi nghĩ mọi người nhận thấy rằng đôi khi nó từ chối quá mức đối với các câu hỏi thuộc miền cụ thể. Tất nhiên, điều này vẫn ít từ chối quá mức hơn nhiều so với hệ thống AI ban đầu của chúng tôi, vốn sẽ từ chối những thứ hoàn toàn không liên quan. Nhưng tôi nghĩ điều đó cũng giúp chúng tôi hiểu được những điểm yếu còn tồn tại và giúp chúng tôi biết cần cải thiện những gì trong tương lai.

Thiết Lập và Đánh Giá Demo

Vậy, chúng ta đã thiết lập điều này chính xác như thế nào? Vâng, tôi nghĩ chúng tôi đã thiết lập nó trên bản demo công khai của mình và sau đó chúng tôi đã đăng tweet về nó để mọi người thử red team nó. Chúng tôi thiết lập sao cho có tám bộ câu hỏi mà chúng tôi không muốn mọi người có thể nhận được câu trả lời, hoặc chỉ tám câu hỏi cụ thể. Mục tiêu là cố gắng khiến mọi người tìm ra các jailbreak để lấy thông tin chi tiết, có hại về từng câu hỏi này, và lý tưởng nhất là họ có thể làm điều này với một universal jailbreak duy nhất.

Đánh Giá Chất Lượng Chi Tiết Phản Hồi

Vâng, khi chúng tôi nói về universal jailbreak, chúng tôi rất quan tâm đến việc đảm bảo rằng các phản hồi phải chi tiết (detailed) và không chỉ là một số thông tin rất mơ hồ mà cá nhân chúng tôi không nghĩ rằng nó mang lại nhiều giá trị – tức là, nếu họ thực sự đang cố gắng thực hiện hành động mà câu hỏi đang muốn gợi ra. Cách chúng tôi đánh giá điều này là chúng tôi có các mô hình chỉ hữu ích (helpful-only models), được huấn luyện để không từ chối bất cứ điều gì. Những mô hình AI này sẽ tương tự như cách một mô hình AI hoạt động nếu bạn có một universal jailbreak, vì chúng không có biện pháp bảo vệ và sẽ chỉ đưa ra câu trả lời rất chi tiết cho các câu hỏi. Vì vậy, đối với mỗi trong số tám câu hỏi này, chúng tôi có một phản hồi từ mô hình chỉ hữu ích này. Điều đó mô phỏng xem phản hồi sẽ như thế nào nếu bạn có một universal jailbreak. Và sau đó, vì có một số yếu tố ngẫu nhiên trong các phản hồi của mô hình AI, chúng tôi có một công cụ chấm điểm (grader) so sánh một phản hồi mục tiêu với phản hồi từ mô hình chỉ hữu ích. Sau đó, nó sẽ tìm kiếm xem có đủ chi tiết được chia sẻ giữa hai phản hồi đó hay không, và nếu có, chúng tôi sẽ coi đó là đủ chi tiết.

Tuyệt. Và tôi nghĩ chúng tôi đã tìm kiếm sự trùng lặp ít nhất 75% trong thông tin hoặc một cái gì đó tương tự. Tôi nghĩ ngưỡng thay đổi theo từng câu hỏi. Vì vậy, tôi nghĩ ở một số cấp độ đầu tiên, là những câu hỏi ít gây hại (harmful questions) hơn, chúng tôi yêu cầu mức độ trùng lặp (overlap) hơi thấp hơn. Sau đó, đối với các câu hỏi sau, chúng tôi đã tăng ngưỡng đó lên khoảng 60-70%. Và vâng, nó linh hoạt trong suốt thử thách (challenge). Vâng, tôi thấy câu hỏi về việc chấm điểm (grading) này thực sự rất thú vị nói chung, và cũng khá thách thức để thực hiện tốt. Tôi nghĩ chúng tôi đã nỗ lực rất nhiều trên hệ thống AI demo, nhưng chắc chắn nó chưa hoàn hảo.

Thách thức trong việc Đánh giá và Định nghĩa 'Có hại'

Hiện tại, cách hệ thống AI hoạt động là tìm kiếm các chi tiết trùng lặp giữa hai câu trả lời. Tuy nhiên, trong quá trình red teaming bên ngoài, chúng tôi nhận thấy người dùng thường hợp nhất năm, sáu, bảy, tám, chín, mười phản hồi từ mô hình AI khác nhau, bao gồm rất nhiều chi tiết. Theo tiêu chí về việc có hoặc không có chi tiết, những phản hồi này sẽ bị coi là có hại, mặc dù thực tế, nếu ai đó hướng dẫn tôi làm bánh nhưng thay vì một danh sách các bước theo gạch đầu dòng rõ ràng, mạch lạc, thì các hướng dẫn lại hoàn toàn rời rạc, ngẫu nhiên và mọi thứ đều lộn xộn, nó thực sự kém hữu ích hơn so với mô hình AI chỉ tập trung vào sự hữu ích (helpful only model). Mô hình AI chỉ tập trung vào sự hữu ích, theo thiết kế, không có bất kỳ safeguard nào và được thiết kế để cung cấp thông tin theo cách hữu ích nhất cho người dùng.

Vì vậy, tôi nghĩ câu hỏi về việc "cái gì là có hại, cái gì không có hại, và đâu là ngưỡng phù hợp?" là một câu hỏi khá tinh tế và nhìn chung là khá khó. Tôi nghĩ đã có một phản ứng thú vị đối với grading system trong bản demo. Nhiều người thấy các phản hồi dường như có hại, nhưng grader của chúng tôi lại nói "không đủ chi tiết, cần nhiều chi tiết hơn". Điều này có thể gây khó chịu cho người dùng vì họ tự hỏi "chi tiết nào bị thiếu? Tôi không biết thông tin đó là gì". Theo một cách nào đó, tôi nghĩ điều này một phần là có chủ ý: nếu tôi đang làm bánh và thiếu một thành phần thiết yếu trong danh sách nguyên liệu hoặc một điều thiết yếu trong hướng dẫn, tôi thực sự không biết đó là gì vì tôi không phải là chuyên gia trong lĩnh vực này.

Vai trò của nhóm Frontier Red Team

Một điều khác mà tôi nghĩ cũng thú vị là: tại sao phản hồi chỉ tập trung vào sự hữu ích lại là phản hồi cơ bản? Tại sao đó lại là thứ chúng ta thực sự so sánh với? Và tôi nghĩ có một điều ở đây là chúng tôi có một nhóm chuyên trách tên là Frontier Red Team. Nhiệm vụ của Frontier Red Team là lấy các mô hình AI tiên tiến và xem điều gì có thể xảy ra với chúng. Họ thực hiện công việc modeling mà chúng tôi đã đề cập trước đó. Họ đánh giá mô hình AI chỉ tập trung vào sự hữu ích và nói rằng "mô hình này có khả năng nguy hiểm, nó có thể được sử dụng để thực hiện một quy trình phức tạp". Vì vậy, Frontier Red Team đang đo lường rủi ro của một mô hình AI chỉ tập trung vào sự hữu ích.

Nếu rủi ro của mô hình AI chỉ tập trung vào sự hữu ích hoặc một mô hình AI không có safeguard là quá cao, chúng tôi đang cố gắng đo lường, hay cách tôi nghĩ về nó là, chúng tôi đang cố gắng đo lường khoảng cách giữa mô hình AI có safeguard và mô hình AI chỉ tập trung vào sự hữu ích. Vì vậy, việc thực hiện phép so sánh tương đối này, mặc dù không hoàn hảo và chắc chắn có những thông tin có hại vẫn có thể lọt qua, nó cho phép chúng tôi thực hiện ước tính và so sánh này. Nhưng vâng, tôi thực sự thấy phản ứng đối với điều này trong bản demo rất thú vị. Tôi nghĩ đây là một điểm khá tinh tế và tôi cũng rất hào hứng khi chúng ta phát triển các kỹ thuật đánh giá tốt hơn và những thứ thực sự có thể đo lường "mức độ hữu ích thực sự của lần hoàn thành này cho các tác vụ mà chúng ta quan tâm là gì?"

Phản hồi và Lợi thế của Red Teaming

Điều khác mà tôi muốn nói nhanh là việc nhận được loại phản hồi về mức độ chi tiết và chính xác của thông tin bạn nhận được là rất phi thực tế. Đó thực sự là một lợi thế lớn đối với một red teamer. Và tôi nghĩ rằng việc chúng tôi đưa ra phản hồi đó đã tạo ra một feedback loop rất rõ ràng mà bạn thường không có.

Kết quả Red Teaming: Jailbreak và Jailbreak phổ quát

Vâng, tôi nghĩ có lẽ chúng ta nên nói về kết quả. Một người đã tìm ra cách vượt qua tất cả tám cấp độ, nhưng trước đó, hệ thống AI của chúng tôi đã giữ vững trong ít nhất năm ngày. Chúng tôi đã thực hiện việc lọc để tìm ra loại người dùng mà chúng tôi coi là red teamer tích cực. Đối với điều đó, chúng tôi chỉ thực hiện một ước tính rất thận trọng: coi một người đã vượt qua ít nhất một câu hỏi là một red teamer có kinh nghiệm và đang cố gắng phá vỡ hệ thống AI. Tôi nghĩ đó là một khái niệm khá tốt. Tôi không phải là red teamer giỏi nhất ngoài kia, nhưng tôi sẽ gặp khó khăn với câu hỏi đầu tiên.

Theo tiêu chí thận trọng này, chúng tôi có 308 người dùng và những người dùng này đã có hơn 300.000 cuộc trò chuyện. Chúng tôi ước tính họ đã dành hơn 3.750 giờ red teaming. Đó là trước khi có người vượt qua tất cả tám cấp độ. Sau đó, có câu hỏi là liệu họ có vượt qua tất cả tám cấp độ bằng một universal jailbreak hay không. Điều đó thực sự khó hơn việc chỉ vượt qua tất cả tám cấp độ bằng cách sử dụng bất kỳ jailbreak ngẫu nhiên nào cho từng câu hỏi riêng lẻ. Và để tìm ra một universal jailbreak, đã cần thêm 50.000 cuộc trò chuyện và thêm khoảng 600 giờ red teaming.

Xây dựng Hồ sơ An toàn và Chiến lược Giảm thiểu Rủi ro

Điều tôi thấy khá thú vị là, ở một mức độ nào đó, chúng ta đã dành rất nhiều thời gian để cố gắng tạo ra một hệ thống AI mạnh mẽ hơn. Và đúng vậy, baseline đã từng bị phá vỡ trong vài giờ, và bây giờ chúng ta đang ở mức vài ngày, đó là một tiến bộ rõ ràng. Nhưng, làm thế nào chúng ta biết rằng điều này đủ an toàn hoặc đủ tốt? Điều gì khiến chúng ta nghĩ rằng điều này thực sự đủ an toàn và trên thực tế, chúng ta còn cần gì nữa?

Tôi nghĩ tiêu chuẩn vàng thực sự mà chúng ta muốn đạt được, được thúc đẩy bởi chính sách responsible scaling policy, là có thể đưa ra một safety case – một lập luận thực sự rõ ràng rằng mặc dù mô hình AI có một khả năng nguy hiểm nhất định, chúng ta thực sự không nghĩ rằng mô hình AI sẽ có thể gây ra những rủi ro liên quan đến khả năng nguy hiểm đó với các safeguard của chúng ta. Và tôi nghĩ, dựa trên kết quả này và rapid response paper mà chúng tôi đã có trước đó, một phương pháp có vẻ khá hứa hẹn để chúng ta thực hiện safety case khi các mô hình AI trở nên có khả năng gây ra rủi ro lạm dụng nghiêm trọng hơn, về cơ bản là xây dựng một hệ thống AI dựa trên constitutional classifier rất tốt, phải mất hàng nghìn giờ để jailbreak. Sau đó, có một số loại... hy vọng điều đó sẽ giảm thiểu rất nhiều nỗ lực jailbreak, phần lớn trong số đó, nhưng một số vẫn sẽ lọt qua.

Sau đó, chúng ta cần một số cơ chế khác để về cơ bản phát hiện và phản ứng với những jailbreak bổ sung đó. Những cơ chế đó sẽ giống như một loại bug bounty program, nơi mọi người có thể báo cáo jailbreak và được thưởng bằng tiền cho việc báo cáo jailbreak. Và có lẽ một loại incident detection hoặc offline monitoring nào đó để sau khi sự việc xảy ra, phát hiện rằng một số traffic có liên quan đến jailbreak mà chúng ta không nhận thấy bằng các classifier tức thì được triển khai trực tuyến, chặn ngay lập tức các output có hại.

Hệ thống Phòng thủ Đa tầng và Hiệu quả của Classifier

Và vâng, bạn có thể hình dung nhiều thứ khác nhau có thể hoạt động ở đó. Nhưng đối với hệ thống AI trực tuyến, các classifier cần phải khá hiệu quả và nhỏ, và có rất nhiều ràng buộc khác nhau. Chúng cũng cần hỗ trợ token by token streaming vì điều đó quan trọng để giảm latency (độ trễ) nhằm nhận phản hồi ngay lập tức từ token đầu tiên. Vì vậy, điều đó chắc chắn có rất nhiều ràng buộc khiến các classifier đó kém hiệu quả hơn bạn có thể đạt được.

Nhưng sau đó, bạn có thể phân phát phản hồi và sau đó, sử dụng một classifier đắt tiền hơn nhiều, ví dụ như mô hình AI lớn nhất, có khả năng nhất của bạn, có lẽ với nhiều test time compute và reasoning để xem liệu phản hồi này có hại hay không, có lẽ gắn cờ những phản hồi nguy hiểm nhất, có lẽ gắn cờ một số trong số đó, và thậm chí để con người xem xét, để các human reviewer xem xét những cái hàng đầu đó để xem liệu có bất kỳ jailbreak thực sự nào không. Bạn có thể hình dung một hệ thống AI thực sự mạnh mẽ như vậy để phát hiện các jailbreak bổ sung. Sau đó, nếu bạn nhận thấy có một số jailbreak bổ sung ở đây, hãy sử dụng phương pháp rapid response mà chúng tôi đã mô tả: bạn lấy những ví dụ đó, nhân rộng chúng để có thêm ví dụ về jailbreak một cách tự động với các LLM, sau đó đào tạo lại các classifier của bạn, triển khai lại các classifier.

Nhìn chung, hệ thống AI đó, hy vọng, sẽ đưa tỷ lệ thời gian mà có một universal jailbreak mở xuống mức hợp lý, sao cho nếu bạn đang cố gắng thực hiện một quy trình khoa học phức tạp nào đó để chế tạo một vũ khí CBRN hoặc thực hiện nhiều cybercrime, thì thực sự chỉ có một cửa sổ thời gian nhỏ để sử dụng mô hình AI cho các bước bạn sẽ thực hiện. Và tôi nghĩ nếu chỉ có 0,1% thời gian có một lỗ hổng bạn có thể sử dụng thì điều đó khiến việc sử dụng hệ thống AI trở nên rất khó khăn. Vâng, tôi nghĩ đó sẽ là phác thảo đại khái về loại safety case mà chúng ta có thể muốn đưa ra, mà chúng ta nghĩ có thể hứa hẹn để sử dụng các constitutional classifier để đạt được an toàn ở đây.

Tương tự về Khóa Xe Đạp và Các Biện pháp Giảm thiểu Tổng thể

Đối với tôi, điều này chỉ là một lời nhắc nhở khác về điều này, vâng, hệ thống AI an toàn hoàn hảo duy nhất là đá. Vâng, luôn có thực tiễn tốt nhất trong bảo mật rằng không có hệ thống AI nào hoàn hảo, hầu hết các hệ thống AI đều có vulnerability (lỗ hổng), và luôn có sự đo lường này: "ai đó cần phải bỏ ra bao nhiêu công sức, khó khăn đến mức nào để ai đó có được thông tin mà bạn cần?" Tôi nhớ lại tôi từng sống ở Cambridge và Oxford ở Vương quốc Anh. Mọi người đạp xe ở đó mọi lúc, và xe đạp bị trộm mọi lúc. Tôi nghĩ hầu hết các xe đạp, bạn chỉ cần một máy cắt góc và nó sẽ cắt thẳng qua khóa mà không thành vấn đề. Những khóa xe đạp đó không hoàn toàn mạnh mẽ. Tương tự, hệ thống AI của chúng ta không hoàn toàn mạnh mẽ. Nhưng trên thực tế, bạn đặt một khóa hoặc hai khóa trên xe đạp của mình, điều đó về cơ bản làm giảm rủi ro đi rất nhiều. Ai đó sẽ phải dùng máy cắt góc, hoặc có lẽ bạn chỉ ở đó khoảng một hoặc hai giờ, ai đó sẽ bắt được họ.

Và vâng, điều này thực sự thú vị bởi vì nghiên cứu luôn diễn ra trong một cấu trúc rộng lớn hơn và những biện pháp giảm thiểu nhạy cảm hơn. Vì vậy, bạn đã đề cập đến rapid response như monitoring (giám sát) các jailbreak mới, sau đó có thể phản ứng với các jailbreak mới. Và có những điều khác chúng ta có thể làm, như monitoring những người cố gắng circumvent our systems (vượt qua các hệ thống AI của chúng ta). Chúng ta có những classifier này và chúng ta có thể phát hiện khi mọi người đang cố gắng vượt qua chúng. Vì vậy, tôi thực sự rất hào hứng khi thấy công việc này thực sự có thể, tôi nghĩ đó là một đóng góp nghiên cứu rất tốt, nhưng tôi thực sự rất hào hứng khi thấy chúng ta đưa nó vào thực tế và đưa nó vào thực tế với tất cả các cơ chế phòng thủ bổ sung khác này để nhìn chung, chúng ta có thể tạo ra một safety case thực sự tốt.

Tôi đồng ý. Vâng, tôi nghĩ chúng ta đã dành khoảng 4.000 giờ nỗ lực cho bản demo, nhưng chúng tôi đã tìm thấy một số kỹ thuật có thể vượt qua các classifier của chúng tôi. Vì vậy, vâng, mọi người đã thử gì và điều gì đã lọt qua? Vâng, tôi nghĩ chúng tôi đã thấy rất nhiều trường hợp mọi người sử dụng các loại cipher (mật mã) hoặc encoding mechanism (cơ chế mã hóa) này để cố gắng làm cho output trông theo một cách nhất định, chẳng hạn như alpha cla...

Kỹ thuật qua mặt bộ phân loại và phản hồi

Một bộ phân loại (classifier) không thể thực sự biết nó đang nói gì và do đó sẽ không gắn cờ. Đó là một điều khá phổ biến mà chúng tôi đã thấy. Một ví dụ rất cơ bản ở đây có thể là việc bạn sử dụng mã hóa (encoding) base64 hoặc mã Morse (Morse code) hay thứ gì đó tương tự. Đây có thể là những thứ mà alpha classifier gặp một chút khó khăn trong việc hiểu, và do đó nó không nghi ngờ nhiều.

Một số chiến lược khác rất thường xuyên được sử dụng là mọi người cố gắng thay thế hóa chất độc hại bằng một thứ gì đó rất vô hại như nước. Ý tưởng ở đây là khi bộ phân loại nhìn thấy một hóa chất rất nguy hiểm, nó sẽ trở nên rất đáng ngờ. Vì vậy, nếu bạn thay thế nó bằng một hóa chất vô hại hơn, có thể nó sẽ ít đáng ngờ hơn. Sau đó, bạn cố gắng ám chỉ cho bộ phân loại hoặc mô hình bằng cách nào đó rằng thực ra bạn đang muốn nói đến hóa chất độc hại này nhưng bạn không nói chính xác từ ngữ đó.

Ngoài ra còn có một số tấn công nhỏ khác như tấn công đóng vai (role-playing attacks), nơi bạn yêu cầu Claude cố gắng hành động theo một cách nhất định, và cả một số tấn công chèn câu lệnh (prompt injection attacks). Chắc chắn, chúng tôi đã thấy nhiều trường hợp mọi người liên tục lấy mẫu lại (resampling) nhiều lần để cố gắng có được kết quả đầu ra (output) tốt hơn, có thể vượt qua hệ thống lớn hơn, cũng như sử dụng phản hồi (feedback) mà chúng tôi... Bởi vì chúng tôi có một phiên bản Claude bổ sung đang xem xét kết quả đầu ra, nên kết quả đầu ra cần phải rất rõ ràng là không độc hại theo một cách nào đó. Vì vậy, bạn nhận được những mật mã (cyphers) này, hoặc bạn không nói về khí sarin hay thiết bị bảo hộ cá nhân (PPE), mà bạn nhắc đến nó bằng những thứ vô hại khác như quả chuối.

Cách tiếp cận của Claude đối với an toàn

Một điều tôi tò mò là chúng ta sẽ nói gì với những người lo ngại rằng chúng ta sẽ sử dụng các cài đặt này để ngăn họ làm những gì họ muốn với Claude, và tại sao chúng ta lại chọn cách tiếp cận dựa trên bộ phân loại và cách tiếp cận hiến pháp. Hy vọng của tôi là điều này sẽ cải thiện trải nghiệm người dùng (user experience) cho bất kỳ tác vụ nào bạn đang cố gắng thực hiện mà không thực sự nguy hiểm. Tôi nghĩ việc khiến bộ phân loại thực sự hiệu quả sẽ tốt hơn là huấn luyện trực tiếp các mô hình để từ chối hay không. Chúng ta có thể chi tiết hơn (granularly) trong việc chọn ra hành vi mà chúng ta muốn chặn. Vì vậy, hy vọng đây là một cải thiện Pareto (Prado improvement), mang lại trải nghiệm người dùng tốt hơn cho mọi người và cũng an toàn hơn về mặt chặn đáng tin cậy (reliability blocking) những nội dung xấu thực sự.

Tầm quan trọng của biện pháp bảo vệ và Chương trình mở rộng có trách nhiệm

Một cách khác tôi nghĩ về điều này là bạn muốn thực sự có thể tận dụng lợi ích của AI thực sự tiên tiến và AI với khả năng khoa học tiên tiến. Nhưng thực tế, nếu bạn không có các biện pháp bảo vệ đầy đủ (adequate protections), thì theo Chương trình mở rộng có trách nhiệm (responsible scaling program) của chúng tôi, chúng tôi thực sự không thể triển khai (deploy) hệ thống đó. Chúng ta có thể có một phiên bản Claude mới tuyệt vời và chúng ta thực sự muốn đưa nó ra thị trường, nhưng chúng ta không thực sự nghĩ rằng điều đó là có trách nhiệm. Chúng ta đã thực hiện mô hình hóa mối đe dọa (threat modeling), xem xét các rủi ro, và có một cách nói rằng nếu chúng ta không có các biện pháp bảo vệ đầy đủ, chúng ta thực sự không thể gặt hái lợi ích một cách có trách nhiệm. Vì vậy, việc có biện pháp bảo vệ (safeguards) cùng với khả năng tiên tiến (advanced capabilities) có nghĩa là cả hai cùng nhau có thể giúp bạn triển khai các hệ thống tiên tiến mới thực sự có thể làm những điều phi thường một cách có trách nhiệm và an toàn.

Duyệt qua rủi ro và lợi ích của AI

Đôi khi bạn thấy điều này trên Twitter và các cộng đồng khác. Có một nhóm người nói rằng AI rất tuyệt vời, nó đang làm tất cả những điều tốt đẹp này, và điều đó đúng, nó có thể làm tất cả những điều đó. Đó là nhóm đẩy nhanh phát triển (accelerationists) và họ muốn đẩy nhanh, hãy có AI tiên tiến ngay bây giờ. Và sau đó có cộng đồng những người khác lo ngại về các rủi ro. Có một phần sự thật ở đó. Có những rủi ro mà chúng ta lo ngại và sau đó chúng ta muốn giảm thiểu (mitigate). Điều tôi thích ở Chương trình mở rộng có trách nhiệm là nó có một số sắc thái (nuance). Có một quan điểm mà ai đó có thể đưa ra là hãy tăng tốc nhanh nhất có thể hoặc dừng lại.

Tôi nghĩ rằng với Chương trình mở rộng có trách nhiệm, chúng ta sẽ cố gắng dự đoán những rủi ro có thể xảy ra, đề phòng những rủi ro đó, và khi chúng ta thấy bằng chứng về việc những rủi ro đó trở thành hiện thực, hãy áp dụng các biện pháp giảm thiểu phù hợp. Và nếu chúng ta không thể giảm thiểu nó một cách thích hợp, có lẽ chúng ta sẽ không triển khai hoặc chọn không triển khai. Tôi thích việc đây là một chiến lược nhiều sắc thái hơn, bởi vì chúng ta đang hoạt động trong rất nhiều sự không chắc chắn. Chúng ta không biết chính xác điều gì sẽ xảy ra. Một số loại rủi ro đôi khi cảm giác như bạn đang đọc truyện khoa học viễn tưởng, và điều đó không có nghĩa là bạn bỏ qua chúng, nhưng cũng không có nghĩa là chúng nhất thiết phải xảy ra 100%. Vì vậy, vấn đề là làm thế nào để điều hướng trong không gian này và sự không chắc chắn này một cách có trách nhiệm, điều sẽ cho phép chúng ta nắm bắt và phân phối lợi ích của việc có thể sở hữu công nghệ thực sự có lợi và mạnh mẽ này mà không phải gây ra những chi phí không cần thiết cho phần còn lại của xã hội và những yếu tố ngoại sinh tiêu cực (negative externalities) này.

Hồi ức về dự án và các thách thức

Tôi tò mò không biết các bạn có kỷ niệm nào yêu thích từ dự án không. Tôi nghĩ thật buồn cười khi với hệ thống nguyên mẫu (prototype system) của chúng tôi, chúng tôi biết tỷ lệ dương tính giả (false positive rate) là cao, nhưng khi chúng tôi thực sự thấy kết quả thử nghiệm (experiment) chạy nó trên dữ liệu Claude.ai, chúng tôi đã nói: "Ồ, nó cao hơn nhiều so với chúng tôi nghĩ." Và điều đó khá thú vị, chúng tôi không nghĩ nó cao đến thế, nhưng nó khá cao. Tôi nhớ mình đã không ngừng lo lắng làm mới bản demo, kiểu như, "Có bao nhiêu người đã đạt cấp độ bốn rồi? Họ đang đến với chúng ta!"

Thật tuyệt vời khi thấy sự sáng tạo của con người từ các người tấn công thử nghiệm (red teamers) và một số điều họ đã nghĩ ra thực sự rất thông minh. Tôi nghĩ có lẽ có hai điều nổi bật. Một điều chúng tôi bắt đầu xem xét trong RSP về việc vượt qua thành công quá trình red teaming. Tôi nghĩ điều này đặc biệt gây rất nhiều áp lực cho Monoc vì anh ấy kiểu như, "Điều này thậm chí có nghĩa là gì? Ngưỡng chính xác ở đây là gì?" Và sau đó anh ấy đã dành hai tuần thực hiện một dự án để tìm cách vận hành hóa (operationalize) điều này. Anh ấy đã đi nói chuyện với rất nhiều người về việc mô hình mối đe dọa (threat models) nào mà chúng tôi thực sự muốn phòng ngừa cho Chương trình mở rộng có trách nhiệm, điều gì sẽ khiến chúng tôi cảm thấy như chúng tôi có thể đưa ra một lập luận về trường hợp an toàn (safety case argument) thực sự tốt. Sau đó, anh ấy quay lại với một tài liệu dài, và trong tài liệu đó, anh ấy đã chỉ rõ rằng chúng ta cần mô hình mối đe dọa phải trả lời một danh sách gồm khoảng 10 câu hỏi, và chúng ta cần có khả năng chặn ai đó nhận được câu trả lời cho 10 câu hỏi này sau khi họ đã thực hiện red teaming trong hơn 2.000 giờ, đó là ngưỡng. Và chúng tôi đã nói, "Được thôi, chúng ta sẽ hướng tới ngưỡng này." Tôi thực sự tự hào về đội ngũ vì chúng tôi thực sự đã đạt được điều đó. Bởi vì chúng tôi đã đặt ra mục tiêu đó ngay từ đầu, một năm trước khi chúng tôi hoàn thành dự án. Và bây giờ chúng tôi đã đạt được ngưỡng đó. Tôi nghĩ đó là một mục tiêu thực sự ấn tượng và đạt được nó, điều này khá hiếm đối với các dự án nghiên cứu.

Kỷ niệm khác mà tôi nhớ là chúng tôi đang thực hiện nghiên cứu về độ bền vững (robustness research), nhưng sau đó chúng tôi đọc một điều khoản đáng lo ngại của RSP và thực sự suy nghĩ về nó. Nhưng sau đó chúng tôi nghĩ, "Ồ, điều này đang nói chuyện với mọi người về việc ai đang làm điều này," và chúng tôi kiểu như, "Ồ vâng, đội ngũ triển khai biện pháp bảo vệ của chúng tôi." Tôi đoán bây giờ nó được gọi là đội ngũ safeguards. Nhưng ban đầu, đội ngũ này là một phần của đội ngũ nghiên cứu khoa học căn chỉnh (alignment science research team) của chúng tôi. Và vì vậy chúng tôi nghĩ, "Ồ vâng, đội ngũ safeguards chịu trách nhiệm làm điều này và họ sẽ xử lý nó." Và sau đó chúng tôi đã sắp xếp một cuộc họp với một số người trong đội ngũ, và họ đã hỏi, "Ai sẽ đạt được mức độ bền vững này?" Và sau đó chúng tôi kiểu như, "Ồ, chuyện này thực sự khó khăn. Tôi đoán chúng ta phải giải quyết vấn đề này," điều mà dường như không phải là trách nhiệm của chúng tôi. Sau đó, trong tuần đó, chúng tôi đã trải qua một quá trình nhận ra rằng đó thực sự là trách nhiệm của chúng tôi để giải quyết vấn đề này. Tôi xem xét nó như là, theo những gì chúng tôi có thể biết, chúng tôi là những người phù hợp nhất để thực hiện công việc này trong nội bộ Anthropic, trong hoàn cảnh đó, và với mọi thứ khác đang diễn ra ở T.S..

Quá trình phát triển và Thử nghiệm

Và các biện pháp bảo vệ. Rồi, lúc đó có suy nghĩ rằng: "Nếu chúng ta là những người phù hợp nhất để làm việc này, hãy thử thực hiện điều đó." Tôi nghĩ rằng toàn bộ nhóm đã có thái độ kiểu như: "Được thôi, chúng ta không biết mục tiêu là gì, hãy cố gắng tìm ra. Chúng ta cũng không biết cách tiếp cận để đạt được mục tiêu đó." Thực ra, chúng tôi đã thử một cách tiếp cận khác, đó là huấn luyện đối kháng (adversarial training), chúng tôi sẽ tìm các mô hình AI để huấn luyện và rồi nhận ra: "Không, chúng tôi không nghĩ cách đó sẽ hiệu quả." Và tôi cứ thế, thực sự khá kiên định, chuyển hướng sang những gì chúng tôi nghĩ sẽ đưa chúng tôi đến đích. Có lẽ điều không rõ ràng từ bài báo là đây là một dự án kỹ thuật khổng lồ, có lẽ tốn khoảng năm FTE years (năm công việc toàn thời gian). Tôi nghĩ điều đó không hiển nhiên khi đọc bài báo, có lẽ nó trông như một phương pháp rất đơn giản. Nhưng tôi nghĩ rằng những người trong nhóm đã làm rất nhiều việc để tạo ra các quy trình LLM nhằm tạo dữ liệu. Tôi nghĩ rằng việc tăng cường dữ liệu (augmenting the data) bằng các phép biến đổi (transformations) khác nhau, như dịch dữ liệu sang các dạng mã hóa (cypheres) khác nhau, sau đó sử dụng dữ liệu đó để huấn luyện và tạo ra dữ liệu cho bộ phân loại (classifier) là rất quan trọng. Vâng, tôi đoán đó là một vài "mẹo" và Thông tin chi tiết (Insights) nổi bật đối với tôi. Tôi tự hỏi liệu có ai khác muốn đóng góp thêm những điều quan trọng hoặc không rõ ràng khác về cách để dự án này hoạt động tốt không.

Xác định và Thu hẹp Vấn đề An toàn

Tôi nghĩ rằng phần lớn dự án nghiên cứu này thực chất là về việc xác định vấn đề ngay từ đầu. Chúng tôi có một chỉ thị (mandate) mơ hồ từ RSP, nhưng có rất nhiều việc phải làm để xác định các tiêu chí (criteria). Có rất nhiều việc trong việc xác định nhóm red team con người có ý nghĩa gì và điều đó sẽ đủ như thế nào. Chúng ta nên có loại nguyên tắc (constitution) nào? Chúng ta thực sự quan tâm đến mô hình đe dọa (threat model) nào? Chúng ta đặt ra tiêu chuẩn về tính cụ thể (specificity) ở đâu? Chúng ta có cần cả bộ phân loại đầu vào và đầu ra (input and output classifier) không? Và điều đó phụ thuộc vào loại mối đe dọa (threats) mà chúng ta thực sự đang tìm kiếm. Vì vậy, tôi cảm thấy rằng rất nhiều, vâng, đối với các đánh giá (evaluations) chẳng hạn, bạn quan tâm đến các phép biến đổi (transformations) đến mức nào? Có bao nhiêu lượt tăng cường (augmentations) là quá nhiều để trở thành một thứ gì đó không bình thường hoặc không cụ thể?

Vì vậy, tôi nghĩ rằng rất nhiều khó khăn là thực sự xác định vấn đề và thu hẹp vấn đề mà chúng tôi đang cố gắng giải quyết. Như việc cố gắng thực hiện các đánh giá, cố gắng tìm ra ranh giới quyết định (decision boundary) nên là gì. Tôi cảm thấy rằng một khi chúng tôi đã đạt được nhiều tiến bộ trong việc xác định vấn đề, tôi cảm thấy tự tin hơn về việc chúng tôi có thể giải quyết các vấn đề có hình dạng tương tự trong tương lai. Ví dụ, nếu chúng tôi có, vâng, theo cùng một cách mà các nguyên tắc có thể được áp dụng cho nhiều vấn đề khác nhau, tôi nghĩ chúng tôi có một cảm giác tốt hơn về cách chúng tôi có thể giải quyết loại vấn đề lớn này. Làm thế nào chúng ta thực sự sẽ tiếp cận một vấn đề mô hình đe dọa (threat modeling) như thế này? Làm thế nào chúng ta thậm chí có thể bắt đầu suy nghĩ về cách tạo ra một trường hợp an toàn (safety case) với điều này? Điều gì sẽ cấu thành một điều xấu đủ lớn? Điều gì sẽ cấu thành, vâng, một red team, một trường hợp an toàn dựa trên red teaming của con người? Vì vậy, tôi cảm thấy rằng, vâng, tôi nghĩ chúng ta sẽ có thể áp dụng nhiều điều hơi mơ hồ hoặc có thể không được viết rõ ràng trong bài báo cho các vấn đề khác, có lẽ không chỉ trong việc sử dụng sai mục đích (misuse) mà còn trong Sự sai lệch mục tiêu của AI (misalignment) hoặc Kiểm soát AI (control) những thứ như thế này.

Triển khai và Đánh giá Biện pháp Bảo vệ

Vâng, tôi cũng rất hào hứng về điều này, như việc trực tiếp thực hành cách xây dựng các biện pháp bảo vệ (safeguards) mà chúng ta có thể triển khai (deploy) và áp dụng vào thực tế, đồng thời thu thập bằng chứng và đánh giá một cách trung thực liệu chúng có thực sự đầy đủ hay không. Có rất nhiều việc nhỏ, như cách điều hành cuộc họp, cách theo dõi mục tiêu; những việc thực sự thường ngày (mundane things) mà các nhà nghiên cứu thường không nghĩ đến đầu tiên. Khi còn là nghiên cứu sinh tiến sĩ, đọc các bài báo, tôi luôn đi thẳng vào phần phương pháp, đó là điều thú vị. Nhưng không, tôi nghĩ chúng tôi đã học được rất nhiều từ việc điều hành và thực hiện các dự án như thế này.

Thách thức về Thời hạn và Chất lượng

Vâng, một điều tôi muốn nói ở đây là tôi nghĩ một sự khác biệt thực sự quan trọng của dự án này so với các bài báo nghiên cứu hoặc nghiên cứu khác mà tôi từng tham gia là về cơ bản, chúng tôi phải giải quyết vấn đề nghiên cứu này trong một thời hạn rất rõ ràng với một tiêu chuẩn chất lượng (quality bar) cố định. Ví dụ, chúng tôi đã đặt ra tiêu chuẩn robustness bar 2000 giờ cho chính mình trong nội bộ. Và về cơ bản, dường như thời hạn là yếu tố bên ngoài, theo nghĩa là bên ngoài nhóm của chúng tôi, bởi vì khả năng mô hình (model capabilities) đang tiến bộ với tốc độ nhất định, công ty đang triển khai (deploying) các mô hình AI mới. Chúng tôi không muốn trở thành nút thắt cổ chai (long pole) khiến công ty không thể triển khai một mô hình AI.

Và vì vậy, vâng, tôi nghĩ rằng chúng tôi liên tục suy nghĩ và nói chuyện với các nhóm khác về việc khi nào chúng tôi nghĩ có thể có một mô hình AI đạt đến mức độ nguy hiểm nhất định về khả năng (dangerous capability level)? Dựa trên điều đó, chúng tôi đã thiết lập kế hoạch theo kiểu kỹ thuật (engineering style planning) hàng tuần, truy ngược (back-chaining) lại từ mục tiêu đó: chúng tôi cần làm gì để đạt được thời hạn đó? Đồng thời vẫn duy trì tiêu chuẩn chất lượng cố định. Tôi nghĩ rằng việc có một tiêu chuẩn chất lượng cố định khác với thời hạn nộp bài báo (paper deadline), bởi vì với thời hạn nộp bài báo, bạn có thể nói: "Chúng tôi sẽ loại bỏ những kết quả này, đây là những gì sẽ có trong bài báo." Bạn sẽ thay đổi vấn đề bạn đang cố gắng giải quyết, vâng, thay đổi vấn đề bạn đang cố gắng giải quyết trước khi bài báo đến hạn. Vâng, chính xác, tuyên bố ít hơn hoặc bất cứ điều gì. Tôi nghĩ bạn thực sự có thể điều chỉnh tiêu chuẩn chất lượng. Nhưng ở đây chúng tôi không thể. Và vì vậy, đó là một phần của điều đã buộc chúng tôi, ban đầu đã buộc chúng tôi phải áp dụng cách tiếp cận bộ phân loại (classifier) này, bởi vì chúng tôi cảm thấy mình không đi đúng hướng để đạt được thời hạn mà chúng tôi mong muốn với cách tiếp cận trước đó.

Nhưng nó cũng dẫn đến những khó khăn khác. Ví dụ, một số người trong nhóm đã gặp khó khăn trong việc lập kế hoạch khi thời hạn không chắc chắn và chúng tôi cần đưa ra một ước tính thận trọng về thời hạn. Và vì vậy, tôi nghĩ có một loạt các quyết định mà các thành viên trong nhóm đã đưa ra, kiểu như: "Ồ, chúng tôi sẽ viết một số mã (code) trong một sổ tay Colab (Colab notebook) theo cách không hoàn toàn có thể tái tạo (reproducible) chỉ để nhanh chóng tạo ra một số dữ liệu để chúng tôi có thể huấn luyện phiên bản tiếp theo của bộ phân loại." Khi mà nếu chúng tôi có một thời hạn dài hơn hoặc một ước tính rõ ràng hơn về thời hạn, chúng tôi đã làm điều này trong một tập lệnh Python (Python script) có thể tái tạo và có một số bộ công cụ chung (general tooling) cho việc này. Vì vậy, tôi nghĩ rằng tôi không thực sự chắc chắn về những gì chúng tôi đã quyết định về việc nhìn lại những gì chúng tôi nên làm. Tôi nghĩ rằng có lẽ không nên đưa ra một ước tính quá thận trọng để chúng tôi có một khoảng thời gian (time window) dài hơn để có đủ thời gian cần thiết cho một số công việc về công cụ (tooling) diễn ra. Nhưng ít nhất là chọn chiến lược (strategy) của bạn theo cách mà chiến lược tổng thể có thể đạt được thời hạn bạn cần. Vâng, tôi không biết liệu những người khác có suy nghĩ gì về điều này không.

Từ Nghiên cứu Lý thuyết đến Giải pháp Thực tiễn

Vâng, tôi đoán là nhìn lại, tôi cảm thấy điều này thực sự khiến tôi nghĩ rằng đây là một thời điểm thú vị cho nghiên cứu an toàn (safety research) nói chung. Tôi nghĩ rằng rất nhiều nghiên cứu, tôi đoán là nghiên cứu về an toàn, ban đầu có vẻ hơi mang tính khám phá (blue sky). Mọi người suy đoán về việc các mô hình AI có thể như thế nào trong tương lai. Và tôi nghĩ chúng ta đang bắt đầu thấy các mối đe dọa (threats) trở thành hiện thực (materializing), và chúng ta cũng cần điều chỉnh nghiên cứu của mình để thực sự có thể sử dụng được trong môi trường sản xuất (production).

Vì vậy, tôi cảm thấy rằng với tư cách là một nhóm nghiên cứu, chúng tôi đang giải quyết một siêu vấn đề (meta problem) thú vị theo nghĩa là làm thế nào chúng ta điều chỉnh các kỹ thuật nghiên cứu thông thường của mình để thực sự biến mọi thứ thành hiện thực trong thế giới thực. Và tôi nghĩ rằng đó là điều mà nghiên cứu an toàn nói chung phải vật lộn. Chúng ta thực sự cần giải quyết những vấn đề này ngay bây giờ, chúng ta không nhất thiết phải có nhiều thời gian để thực hiện nhiều nghiên cứu mang tính khám phá. Và chúng ta muốn thực sự làm cho mọi thứ hoạt động trong thực tế. Tôi nghĩ khả năng giải thích (interpretability) cũng đang gặp phải vấn đề này, nơi trước đây mọi người thường nghiên cứu trên các mô hình AI rất nhỏ với rất ít lớp (layers) hoặc tương tự. Và nhiều vấn đề của họ là việc mở rộng quy mô (scaling things up) để giải quyết một mô hình AI thực sự không phải là một thành tựu kỹ thuật (engineering feat) nhỏ chút nào. Và vâng, tôi nghĩ rằng điều đó khá thú vị và tôi đoán là đáng sợ khi chúng ta thực sự phải nghiêm túc và làm cho mọi thứ thực sự hoạt động trong thực tế.

Hợp tác với Nhóm Sản phẩm và Ưu tiên Rủi ro

Vâng, tôi nghĩ một điểm khác mà tôi muốn nêu ra là một điều thực sự hữu ích, đáng ngạc nhiên đối với tôi trong dự án này, là việc trò chuyện với những người làm sản phẩm (product people). Chỉ để hỏi: "Những ràng buộc (constraints) thực tế cho hệ thống mà bạn muốn chúng tôi triển khai (deploy) là gì? Bạn sẽ ưu tiên (prioritize) các khía cạnh khác nhau như thế nào?" Và tôi nghĩ chắc chắn có một số bất ngờ lớn ở đó, ít nhất là đối với tôi. Tôi đã rất ngạc nhiên về việc hỗ trợ truyền phát trực tiếp (streaming support) quan trọng đến mức nào, về khả năng hiển thị từng từ (word by word) khi mô hình AI tạo ra và hiển thị điều đó cho người dùng. Điều đó rất quan trọng đối với nhiều ứng dụng, và đó không phải là điều tôi nhất thiết phải nhận ra trước đó. Mỗi ứng dụng này, nếu chúng ta không đạt được tiêu chuẩn an toàn (safety bar), thì chúng ta có thể không thể triển khai trong lĩnh vực (domain) mới đó.

Và tôi nghĩ chỉ cần có một danh sách được xếp hạng (stack ranked list) về những gì quan trọng nhất để công ty có thể triển khai, sau đó ưu tiên các trường hợp sử dụng (use cases) đó. Đó là cách chúng tôi đã đi đến quyết định về bộ phân loại tương thích token theo token (token by token compatible classifier) này. Và tôi nghĩ nhìn chung, đó là một nguyên tắc rất tốt để hỗ trợ các rủi ro trong tương lai (future risks). Tôi nghĩ rằng, vâng, chúng ta sẽ có thế hệ rủi ro tiếp theo, nơi chúng ta cần mức độ mạnh mẽ (robustness) cao hơn nữa. Tôi nghĩ đây là một chiến lược tốt để đạt được sự an toàn ở đó hoặc đối với các rủi ro sai lệch mục tiêu (misalignment risks) liên quan đến việc bản thân các hệ thống AI thực hiện các hành vi xấu. Tôi nghĩ chúng ta sẽ áp dụng cách tiếp cận tương tự. Tuyệt vời, thật vui được ở đây và trò chuyện với các bạn, và cùng kỷ niệm những tiến bộ này cũng như nhìn về phía trước đối với tất cả những thách thức mà chúng ta sẽ phải đối mặt và những điều tương tự. Vâng, cảm ơn rất nhiều và cảm ơn các bạn đã theo dõi.