- Terence Tao đề cập đến tầm quan trọng về mặt logic của việc phân biệt giữa đội xanh và đội đỏ trong lĩnh vực an ninh mạng
- Constructive logic (logic kiến tạo) đại diện cho đội xanh, còn co-constructive logic (logic đồng kiến tạo) đại diện cho nguyên tắc của đội đỏ
- Mike Shulman đang nghiên cứu một hệ logic mới kết hợp hai nền tảng logic này
- Diễn giải Brouwer–Heyting–Kolmogorov (BHK) tập trung vào chứng minh, nhưng cũng nhấn mạnh tầm quan trọng của phản chứng
- Hướng nghiên cứu này có thể được áp dụng cho nhiều lĩnh vực như an toàn AI
Thảo luận về việc phân biệt và kết hợp logic của LLM đội xanh và đội đỏ
- Terence Tao gần đây cho biết các nhà logic học đang suy nghĩ sâu hơn về sự khác biệt giữa đội xanh (phòng thủ) và đội đỏ (tấn công) trong lĩnh vực bảo mật và thuật toán
- Constructive logic (logic kiến tạo) tập trung vào quá trình xác minh, tức là quá trình chứng minh một mệnh đề, và định hình nguyên tắc của đội xanh
- Ngược lại, co-constructive logic (logic đồng kiến tạo) là logic về quá trình phản chứng, tức phản bác hay tấn công, đang được chú ý gần đây và thể hiện nguyên tắc của đội đỏ
Nghiên cứu kết hợp logic của Mike Shulman
- Mike Shulman đang nghiên cứu một dạng logic kết hợp hai hệ logic này
- Theo nội dung được trích dẫn trong bài báo của ông, diễn giải Brouwer–Heyting–Kolmogorov (BHK) hiện có xu hướng chỉ tập trung vào tiêu chuẩn chứng minh, nhưng các nhà toán học thực hành cho rằng tiêu chuẩn phản chứng, tức tiêu chuẩn để nhận diện một mệnh đề là sai, cũng quan trọng không kém
- Qua đó, ông chỉ ra giới hạn của lối tư duy lấy chứng minh làm trung tâm trong các diễn giải logic hiện có
Sự cần thiết phải mở rộng diễn giải logic
- Có ý kiến cho rằng cần giải thích từ cả hai phía xem chứng minh và phản chứng lần lượt có ý nghĩa gì đối với các liên từ logic
- Nghiên cứu đang được Mike Shulman tiến hành khám phá xem kiểu diễn giải mở rộng này trên thực tế sẽ có cấu trúc như thế nào
Hàm ý và khả năng ứng dụng
- Nếu hướng nghiên cứu logic kết hợp như trên tiếp tục tiến triển, nó có khả năng được ứng dụng thực tiễn cao trong thiết kế an toàn AI cũng như phát triển các hệ thống kiểm chứng và phản chứng thuật toán trong lĩnh vực an ninh mạng
- Có thể xem chi tiết bài báo liên quan qua liên kết arXiv
1 bình luận
Ý kiến trên Hacker News
Có vài suy nghĩ
(a) AI hữu ích cho cả đội "đỏ" lẫn đội "xanh"
Đội xanh đóng vai trò như một hình thức brainstorm
(b) AlphaEvolve là một ví dụ áp dụng khá rõ cách tiếp cận 'đội đỏ/đội xanh' theo nghĩa này, chỉ là không dùng các thuật ngữ đó
Terence Tao cũng là cố vấn cho bài báo đó
(c) Điều này gợi nhớ đến sự phân vai 'người kiểm chứng/người phản chứng' trong ngữ nghĩa trò chơi
Bản thân Tao cũng từng công khai nhắc đến lối tư duy này, nên có lẽ thực tế ông cũng nhìn theo góc độ đó
Cách diễn đạt "xanh/đỏ" có lẽ là cách đóng gói cho phù hợp với lập trình viên
(d) Nói thêm thì, không phải lúc nào cũng có thể nói hệ thống bảo mật chỉ mạnh bằng mắt xích yếu nhất của nó
Điều đó còn tùy việc bảo mật được tổ chức theo tầng hay theo cấu trúc song song
Nếu là một hành lang với nhiều cánh cửa mạnh và yếu xếp nối tiếp nhau, thì độ mạnh tổng thể được quyết định bởi cánh cửa mạnh nhất
Và nếu kết hợp nhiều bộ phân loại yếu để tạo ra một thuật toán phát hiện gian lận, thì kết quả thậm chí có thể mạnh hơn rất nhiều so với bộ phân loại yếu nhất
Bài báo AlphaEvolve
Hỏi đáp về lối tư duy của Tao
Ở đó LLM chỉ đơn giản tạo mã mới dựa trên ví dụ, chứ không tự đánh giá mã
Tôi cảm thấy khái niệm đội đỏ vs đội xanh là một khung khá tốt để hiểu LLM hữu ích đến đâu cho người làm chuyên môn
Việc thêm test thì tôi gần như sẵn sàng giao cho LLM mà không do dự
Vì test thường rẻ, nếu sai thì dễ xóa hoặc sửa, còn nếu đúng thì nó tạo thêm giá trị
Tuy vậy, vì LLM thường không test các chức năng cốt lõi, nên những test quan trọng nhất vẫn phải tự viết thì mới yên tâm
Ngược lại, dùng LLM để sửa bug hoặc thêm tính năng thì rủi ro hơn
Vì LLM có thể dùng mánh khóe, hoặc viết mã chỉ để qua test chứ không giải quyết đúng bản chất vấn đề
Khi làm việc với codebase legacy, tôi thực sự cảm nhận rõ rằng suy nghĩ kiểu "test sai thì sau này sửa lại là được" rất nguy hiểm
Test đôi khi còn là bằng chứng gần với sự thật hơn cả mã, nên test sai có thể nguy hiểm hơn mã sai
Đặc biệt, khi trộn lẫn những test vô dụng hoặc test không rõ ý nghĩa, thì việc phân biệt xem cái nào thật sự đang đảm bảo chức năng quan trọng là điều tệ nhất
Tôi nghĩ AI giống như máy tính cầm tay
Cũng như máy tính cầm tay làm tốt những phép tính mà đa số con người không thể làm, AI là một loại trí tuệ mới đóng vai trò công cụ hỗ trợ để tăng cường con người
Nhiều người nghĩ rằng "AI sẽ thay thế con người", nhưng trên thực tế giá trị thật của nó là bổ trợ cho công việc của con người
Tôi ở phía ngược lại
Tôi nghĩ phải tự viết test và hiểu hoàn toàn chúng thì mới có được tiêu chuẩn thực sự, sau đó mới có thể yên tâm để AI tự do sửa mã
Nếu test cũng do LLM tạo ra thì khi giao phần còn lại của mã cho AI tôi lại càng thấy bất an hơn
Tôi đã thử dùng LLM tạo test cho mã Rust, nhưng thực tế hại nhiều hơn lợi
Số lượng test thì nhiều, nhưng lại dễ bỏ sót những phạm vi quan trọng
Mã quá nhiều nên rất khó kiểm tra phần nào chưa được cover
Và khi sau này muốn thay đổi logic mã, tôi từng phải chỉnh lại toàn bộ đống test được sinh ra đó
Có câu kiểu như "test thì chẳng ai xác minh, nên người ta mặc nhiên cho là đúng"
Vì thế mới có pattern Arrange-Act-Assert
Kiểu unit test tôi thích nhất dạo này là lưu sẵn giá trị đầu vào và đầu ra kỳ vọng, rồi dùng chúng để kiểm chứng kết quả của mã
Vì có thể dễ dàng kiểm tra cả các trường hợp biên, nên rất thuận tiện để xác nhận nó có hoạt động đúng như mong muốn hay không
Theo hiểu biết của tôi thì thuật toán RSA cũng được tạo ra theo kiểu này
Theo "The Code Book" của Simon Singh (tôi cất đâu đó mà giờ không tìm ra), Rivest và Shamir nghĩ ra ý tưởng, còn Adleman đóng vai trò tìm lỗi
Xem Wikipedia về RSA
Đây cũng là một ví dụ cộng tác kiểu đội xanh/đội đỏ trong toán học
Một người có rất nhiều ý tưởng, nói nhiều và khá lan man
Người còn lại thì logic và chính xác, nên khi một người viết bản thảo bài báo thì người kia sẽ xóa hết những phần thừa thãi
Tôi đồng ý về mặt tổng thể, nhưng cách đóng khung theo góc nhìn infosec có vẻ hơi lạ
Cách nhìn kiểu "độ mạnh bảo mật bằng phần yếu nhất" là quá đơn giản và nguy hiểm
Chiến lược bảo mật nên được xây nhiều lớp
Không thể kỳ vọng sự hoàn hảo ở một lớp đơn lẻ, nên cần nhiều lớp phòng thủ
Tấn công và phòng thủ không khác nhau quá nhiều, nhưng nhiều kẻ tấn công nếu phạm sai lầm thì chịu ít trách nhiệm hơn, còn người phòng thủ, nhất là ở các công ty lớn, lại phải chịu trách nhiệm nặng hơn về hậu quả
Nhưng người phòng thủ có lợi thế được chiến đấu trên sân nhà. Bỏ qua điều này thì có thể gặp tình huống rất tệ
Ví dụ kiểu khóa cửa nhưng để mở cửa sổ thì vô ích là một phép so sánh đúng
Phòng thủ nhiều lớp chỉ có ý nghĩa khi có nhiều lớp chướng ngại mà kẻ tấn công buộc phải đi qua để tới mục tiêu
Nhưng nếu các yếu tố ở cùng một tầng, như cửa và cửa sổ, thì phần yếu nhất sẽ quyết định toàn bộ
Ví dụ trên web, nếu đăng nhập chính rất hoàn hảo nhưng một endpoint cũ kiểu
/v1/legacy/external_backofficelại cho phép truy cập mạng nội bộ mà không cần xác thực, thì toàn bộ phòng thủ coi như sụp đổDù vậy, nếu bên trong vẫn còn thêm cơ chế chặn khác thì thiệt hại có thể bị giới hạn, nên rốt cuộc các lớp phòng thủ vẫn rất quan trọng
Câu "phòng thủ chỉ mạnh bằng mắt xích yếu nhất" được dùng theo nghĩa bao quát hơn
Tôi đã thêm cụm 'toàn bộ nỗ lực phòng thủ' vượt ra ngoài cách diễn đạt của bài gốc, nhưng thực ra cả hai phía đều có lý
Như Terence nói, mắt xích yếu nhất thực sự có thể bị xuyên thủng, và vì vậy cần nhiều lớp phòng thủ
Có một ví dụ thực tế gần đây là nhân viên helpdesk reset mật khẩu khách hàng mà không hề xác minh
Dù đã triển khai công nghệ bảo mật vững như VPN, 2FA, v.v., chỉ một mắt xích yếu là 'khôi phục tài khoản' cũng đủ làm sụp đổ toàn bộ
Dù bên trong có thêm lớp phát hiện và chặn nên chỉ mất 3 giờ để ngăn kẻ xâm nhập, thì đó vẫn là 'giảm thiểu thiệt hại' chứ không phải 'ngăn chặn từ trước'
Cuối cùng vẫn cần nhiều lớp để chặn thiệt hại
Gần đây, ngay cả ngành infosec cũng đang chuyển trọng tâm từ "phòng ngừa 100%" sang "giảm nhẹ thiệt hại"
Vì rất khó ngăn ngừa mọi rủi ro, nên hướng đi chiến lược đang là giảm rủi ro, thu hẹp bề mặt tấn công, và hạ mức độ tin cậy
Tôi hoàn toàn không phải chuyên gia bảo mật, nhưng nghe nói rằng "bề mặt tấn công được thu nhỏ đến mức tối đa, sử dụng các giao thức mã nguồn mở đã được kiểm chứng" mới là cách phòng thủ tốt nhất
Tôi tò mò điều đó khác gì với những gì đang được bàn ở đây
Chỉ đơn giản là phép suy diễn được chọn chưa phù hợp
Câu "mắt xích yếu nhất" đúng khi phải xuyên qua nhiều bước nối tiếp nhau
Còn nếu có nhiều lớp chồng lên nhau trong cùng một tầng thì sẽ nhắm vào phần yếu nhất trong số đó
Đúng như lo ngại, nó vẫn có chỗ để diễn giải mơ hồ
Tôi xem tấn công cũng là một lớp phòng thủ khác
Kiểu như câu 'tấn công tốt nhất là phòng thủ tốt nhất'
Trong an ninh mạng, đội đỏ và đội xanh là hai đội có sức mạnh tương đương
Nhưng trong phát triển phần mềm thì tôi thấy phép so sánh này hơi cường điệu
Test cũng là code, và vẫn có bug
Nó tạo ra một kiểu nghịch lý như câu "Who polices the police?"
Một câu tiếng Anh lặp lại đầy hàm ý như Buffalo sentence
Tôi nhớ đến câu chuyện tinh thần "chế độ mở vs chế độ đóng" của John Cleese
Ý tưởng thì nên được đưa ra thật đa dạng trong trạng thái cởi mở tối đa
Rồi sau đó chuyển sang chế độ đóng để lọc bỏ ý tưởng tệ và phát triển những ý tưởng tốt
Nhà văn ở mọi lĩnh vực thường cũng có biên tập viên
Thiết kế game bài Magic: the Gathering cũng tương tự, khi đội thiết kế làm bản nháp một bộ thẻ rồi chuyển cho một đội phát triển hoàn toàn riêng biệt để kiểm chứng
Nếu có thêm ví dụ hợp tác kiểu này thì tôi rất muốn nghe
Thực tế tôi lại thấy ngược với bài này
LLM rất giỏi trong việc tạo bản nháp nhanh, còn con người được đào tạo tốt thì phù hợp hơn để xem xét kết quả của LLM một cách phê phán
Vì vậy, LLM hợp với vai đội xanh hơn, còn con người hợp với vai đội đỏ hơn
Có vẻ Tao cũng đang nhắc đến những tình huống cực hạn như vậy
Gần đây khi dùng các model và workflow dựa trên agent, tôi có cảm nhận như sau
Những agent này phát huy tốt nhất không chỉ ở viết code mà còn ở test, quản trị, thậm chí cả vai trò management
Developer dần biến thành một kiểu manager, tức là supervisor
Họ ở vị trí giám sát toàn bộ quá trình từ lập kế hoạch task (viết prompt, sắp xếp phạm vi công việc), viết test đến viết code
Đúng là lượng review tăng lên rất nhiều, nhưng khi trực tiếp đóng vai đội đỏ để kiểm tra xem mọi thứ có ít vỡ hơn không thì tôi lại thấy quyền kiểm soát còn lớn hơn
Góc nhìn này khá ấn tượng
Trong kinh doanh cũng có thể chia thành 'đội xanh' (các ngành hạ tầng xã hội: điện, dầu khí, viễn thông, phần mềm, tài chính, v.v.) và 'đội đỏ' (các ngành gia tăng giá trị: ăn uống, bán lẻ chuyên biệt, hàng xa xỉ, du lịch, v.v.)
Về kinh tế, phía đội xanh quan trọng hơn nhiều, vì các ngành này là nền tảng của toàn bộ nền kinh tế, có nhu cầu lớn, và đội này phải giảm sai sót đến mức thấp nhất
Ngược lại, các ngành đội đỏ dù không có thì nền kinh tế vẫn vận hành, nhưng càng nhiều thì chất lượng tổng thể càng được cải thiện
Trong ví dụ của Tao cũng là cùng một cấu trúc: kỹ sư phần mềm được trả cao hơn QA, và việc viết chứng minh được xem là có giá trị kinh tế hơn việc xác minh
Khi Sam Altman gọi vốn cho việc huấn luyện LLM, ông phải nhấn mạnh rằng "chúng tôi hữu ích như đội xanh" thì mới dễ được đầu tư, và điều đó tác động tới toàn bộ câu chuyện truyền thông
Thực ra LLM hợp với vai trò đội đỏ hơn, nhưng vì phải nêu bật khả năng thu hồi vốn nên các công ty sẽ chỉ đẩy LLM theo hướng đội xanh
Google Glasses, VR và các thiết bị wearable cũng theo mô thức tương tự
Đây là những công nghệ đội đỏ hữu ích trong các ngành ngách, nhưng vì không tạo ra hệ sinh thái khổng lồ hay lợi nhuận lớn nên bị giới vốn phớt lờ
(Tôi làm ở Microsoft)
Tôi trực tiếp vận hành việc kiểm chứng đội đỏ tự động cho các mẫu RAG bằng SDK azure-ai-evaluation
Ở đây, một adversarial LLM vượt khỏi rail kết hợp với package pyrit sẽ tự động tạo ra các câu hỏi kỳ quặc để ném vào ứng dụng, rồi còn biến đổi chính câu hỏi đó bằng base64, mã Caesar, urldecode, v.v.
Kết quả thực tế rất thú vị, và tôi đồng ý rằng LLM khá hữu ích cho hoạt động đội đỏ
Video demo trên YouTube
(Mong thông cảm nếu giọng nói hơi to, tôi quay ở một địa điểm khá đặc biệt)