Bản thiết kế của Cloudflare cho Quét Bảo mật AI không phụ thuộc Mô hình

Project Glasswing của Cloudflare tiếp tục cung cấp những hiểu biết thực tế cho các đội kỹ thuật xây dựng công cụ bảo mật hỗ trợ AI. Trong bài đăng mới nhất của mình, nhóm đã trình bày kiến trúc của một bộ khai thác lỗ hổng được thiết kế để không phụ thuộc vào mô hình ngay từ ngày đầu. Luận điểm cốt lõi: không một mô hình đơn lẻ nào, dù có khả năng đến đâu, nên là xương sống của đường ống bảo mật của bạn. Các mô hình là hàng hóa; lớp điều phối mới là thứ tồn tại lâu dài.

Tại sao là một bộ khai thác, không phải một tác nhân

Bài đăng trực tiếp giải quyết hai phản đối phổ biến. Đầu tiên, tại sao không sử dụng các tác nhân phụ? Các tác nhân phụ tốt cho các tác vụ riêng lẻ, nhưng phân tích bảo mật đòi hỏi hàng trăm cuộc điều tra liên tục tồn tại qua nhiều lần chạy, không chia sẻ một cửa sổ ngữ cảnh và có thể được tham chiếu chéo sau đó. Đó là một vấn đề về điều phối, không phải là một vấn đề về nhắc nhở. Thứ hai, đây không phải là một quảng cáo cho các mô hình tiên tiến. Cloudflare chạy bộ khai thác với bất kỳ mô hình nào hiện đang tốt nhất cho công việc, và các mô hình khác nhau phát hiện ra các lỗi khác nhau. Bộ khai thác là tài sản bền vững.

Từ kỹ năng đến đường ống

Cloudflare bắt đầu với một kỹ năng security-audit dài 450 dòng thực hiện kiểm toán 7 giai đoạn trong một phiên duy nhất: trinh sát, săn lùng, xác thực, báo cáo, xác thực cơ học, xác minh lại độc lập và gửi. Kỹ năng đó hoạt động nhưng gặp ba rào cản: cạn kiệt ngữ cảnh (các mô hình quên lỗi sau một giờ), thiếu tính bền vững (sự cố có nghĩa là bắt đầu lại) và mù quáng trước các phụ thuộc giữa các kho lưu trữ. Giải pháp là ngoại hóa trạng thái, coi LLM như một công cụ tính toán không trạng thái, và mã hóa từng giai đoạn thành tác nhân riêng của nó với một cơ sở dữ liệu phía sau và một bộ điều phối phía trước. Việc ánh xạ từ kỹ năng sang đường ống gần như là một-một.

Quy trình làm việc hai giai đoạn

Quy trình nghiên cứu lỗ hổng của Cloudflare chia thành hai giai đoạn: Bộ khai thác Phát hiện Lỗ hổng (VDH) và Hệ thống Xác thực Lỗ hổng (VVS). VDH quét các cơ sở mã để phát hiện các vấn đề tiềm ẩn. VVS xử lý việc loại bỏ trùng lặp, đánh giá và sửa chữa. Quan trọng là, VDH sử dụng một mô hình trong khi VVS sử dụng một mô hình hoàn toàn khác. Điều này buộc mô hình xác thực phải hoạt động như một bên thứ ba đối nghịch, kiểm tra căng thẳng các giả định của mô hình phát hiện với một bộ trọng số logic và dữ liệu huấn luyện hoàn toàn khác. Về mặt vận hành, nó cũng tách hệ thống khỏi sự biến động của bất kỳ nhà cung cấp mô hình đơn lẻ nào—thay đổi nhiệt độ, thay đổi bộ nhớ đệm, điều chỉnh ngân sách suy luận—mà không làm hỏng đường ống.

Lời khuyên thực tế cho người xây dựng

Bài đăng đưa ra hướng dẫn đơn giản: bắt đầu với một bộ khai thác tối thiểu bao gồm các giai đoạn Trinh sát, Săn lùng và Xác thực được hỗ trợ bởi cơ sở dữ liệu. Bỏ qua việc theo dõi chéo kho lưu trữ cho đến khi bạn có nhiều hơn một kho lưu trữ quan trọng. Bỏ qua một tác nhân loại bỏ trùng lặp chuyên dụng cho đến khi bạn bị ngập trong nhiễu. Đầu tiên hãy làm cho các lời nhắc của bạn hoạt động tốt trong môi trường phát triển, sau đó xây dựng giai đoạn kiến trúc tiếp theo chỉ khi việc không có nó là thứ cụ thể đang làm bạn chậm lại.

Đội tàu gồm 128 kho lưu trữ của Cloudflare chạy trên một bộ khai thác thống nhất mà không cần tinh chỉnh theo ngôn ngữ. Bộ khai thác không quan tâm nếu nó đang nhìn vào con trỏ C hay TypeScript—nó tập trung vào điều phối bảo mật, để lại cú pháp cho mô hình. Đó là loại thiết kế thực tế, không phụ thuộc vào mô hình sẽ tồn tại lâu hơn bất kỳ chu kỳ phát hành LLM đơn lẻ nào.