Chống chưng cất mô hình AI: đổi câu trả lời thôi vẫn chưa đủ

Muốn hạn chế việc sao chép năng lực mô hình qua API, đội vận hành cần ghép bốn lớp kiểm soát: danh tính, mạng, hành vi và đầu ra. Thay đổi câu trả lời chỉ nên là phản ứng có điều kiện sau khi hệ thống nhận ra một cụm lưu lượng đáng ngờ, không phải tuyến phòng thủ duy nhất.
Mục tiêu là phát hiện cả chiến dịch thay vì chặn từng API key. Hoạt động thu thập có thể được chia qua nhiều tài khoản, nhà cung cấp đám mây, dịch vụ tổng hợp và tuyến trung gian; vì vậy hạn mức trên một khóa riêng lẻ chỉ xử lý một phần của vấn đề.
Ghép bốn lớp vào cùng một quyết định rủi ro
Mỗi lớp cần cung cấp bằng chứng cho cùng một hồ sơ rủi ro, nhưng hệ thống vẫn phải giữ lại tín hiệu gốc để điều tra và xử lý khiếu nại. Một IP mới, một đợt truy vấn nhanh hoặc một tài khoản dùng nhiều chưa đủ để kết luận có chưng cất trái phép.
- Danh tính: liên kết API key với tài khoản, tổ chức, phương thức thanh toán, thời điểm đăng ký và lịch sử thay đổi hạn mức. Áp dụng hạn mức khởi đầu theo loại khách hàng và xác minh bổ sung trước khi cấp throughput lớn.
- Mạng: tìm quan hệ giữa địa chỉ IP, ASN, vùng địa lý, proxy, dấu vết client và tuyến truy cập. Trọng tâm là nhận ra nhiều danh tính có thời điểm chuyển tuyến hoặc nhịp truy vấn tương quan.
- Hành vi: đo tốc độ, thời lượng hoạt động, độ lặp của prompt, phạm vi năng lực bị khảo sát và tần suất đổi model. So sánh từng tài khoản với nhóm người dùng có mục đích tương tự thay vì dùng một ngưỡng chung.
- Đầu ra: chỉ giảm thông tin, hạ cấp model hoặc giới hạn tính năng khi bằng chứng đủ mạnh. Chính sách phải có phiên bản, có thể hoàn tác và được đánh giá riêng về ảnh hưởng tới người dùng hợp pháp.
Thu telemetry để nối tài khoản thành chiến dịch

Khuyến cáo chung của NSA, CISA và FBI yêu cầu theo dõi đồng thời prompt, tài khoản, mạng và hành vi; các dấu hiệu được nêu gồm tài khoản dùng chung từ nhiều IP hoặc user agent, hoạt động liên tục, tỷ lệ thuê bao so với mức sử dụng API bất thường, tài khoản mới lập tức dùng tối đa và throughput cấp doanh nghiệp.
Để tương quan được các dấu hiệu đó, bản ghi vận hành nên có định danh tài khoản và tổ chức, API key đã băm, model, endpoint, thời điểm, lượng token vào–ra, trạng thái phản hồi, nguồn mạng, dấu vết client và biện pháp hạn chế đã áp dụng. Đội vận hành cũng cần giới hạn người được xem log, xác định thời hạn lưu giữ và tách mục đích an ninh khỏi phân tích sản phẩm.
Hãy tổng hợp tín hiệu theo nhiều cửa sổ thời gian. Cửa sổ ngắn phát hiện đợt tăng đột biến; cửa sổ dài giúp nhận ra nhiều tài khoản duy trì lưu lượng vừa phải nhưng cùng bao phủ một nhóm năng lực hoặc cùng đổi tuyến khi bị hạn chế.
Đặt cảnh báo theo hành vi phối hợp, không theo một ngưỡng cứng
Không có một ngưỡng lưu lượng phù hợp với mọi API. Baseline nên được tách cho người dùng thử, nhà phát triển cá nhân, khách hàng doanh nghiệp và workload theo lô đã khai báo; cảnh báo được tạo khi hành vi lệch đáng kể khỏi nhóm tương ứng.
- Tăng điểm rủi ro khi tài khoản mới nhanh chóng chạm hạn mức, nhất là lúc prompt có cấu trúc lặp lại và được gửi đều đặn.
- Liên kết các tài khoản có dữ liệu đăng ký tương tự, thời điểm đổi tuyến trùng nhau hoặc nhiều biến thể gần giống của cùng một prompt.
- Đánh dấu trường hợp nhiều thuê bao cá nhân cộng lại thành throughput cấp doanh nghiệp mà số người dùng hoặc ứng dụng đã khai báo không tăng tương ứng.
- Tìm chuỗi truy vấn bao phủ có hệ thống một năng lực như toán, lập trình hay sử dụng công cụ; một prompt đơn lẻ thường không cung cấp đủ ngữ cảnh.
Mỗi cảnh báo cần cho biết tín hiệu nào đã đóng góp vào điểm rủi ro và dẫn ngược được tới sự kiện gốc. Trước khi chuyển một luật sang chế độ chặn, nên chạy ở chế độ quan sát, đo tác động lên lưu lượng hợp pháp và thử với kịch bản mô phỏng phân tán qua nhiều tài khoản lẫn tuyến mạng.
DistillGuard chỉ ra giới hạn của phòng vệ ở đầu ra

Bản tiền in DistillGuard đánh giá chín cấu hình thuộc ba nhóm phòng vệ đầu ra, dùng Qwen3-14B làm mô hình giáo viên và Qwen2.5-7B-Instruct làm mô hình học viên trên MATH-500, HumanEval+ và MT-Bench. Trong thiết lập chưng cất cùng họ mô hình trước một đối thủ chưa thích nghi, paraphrase hầu như không làm giảm chất lượng mô hình học viên, còn đầu độc dữ liệu chủ yếu làm giảm độ trôi chảy hội thoại mà không loại bỏ các năng lực theo nhiệm vụ.
Loại bỏ chain-of-thought làm kết quả toán của mô hình học viên giảm từ 67,8% xuống 31,4% trong thí nghiệm, nhưng năng lực sinh mã không bị ảnh hưởng. Đây là kết quả của một cấu hình nghiên cứu cụ thể, không phải bằng chứng rằng mức giảm tương tự sẽ xuất hiện với mọi họ mô hình, tập dữ liệu hoặc đối thủ.
Giới hạn đó giải thích vì sao đổi câu trả lời thôi vẫn chưa đủ. Paraphrase giữ lại nội dung hữu ích cho huấn luyện; dữ liệu bị đầu độc có thể làm hại cả người dùng hợp pháp; còn việc bỏ dấu vết suy luận chỉ tác động mạnh tới một số loại năng lực. Vì vậy, kiểm soát đầu ra phải được đánh giá riêng cho toán, mã nguồn, hội thoại và tác vụ dùng công cụ, đồng thời đặt sau cơ chế phát hiện ở ba lớp còn lại.
Phản ứng theo cấp độ và kiểm tra lại khả năng phát hiện
Khi điểm rủi ro tăng, phản ứng có thể đi từ xác minh bổ sung, giảm tốc độ và giới hạn số yêu cầu đồng thời đến thu hẹp tính năng đầu ra hoặc chuyển sang model ít năng lực hơn. Chỉ nên tạm khóa cụm tài khoản khi bằng chứng đủ mạnh; mọi quyết định cần lưu lý do, phiên bản chính sách và thời điểm áp dụng.
Với sự cố nghiêm trọng, hãy bảo toàn log, dựng quan hệ tài khoản–mạng–prompt và tìm các cụm vẫn hoạt động sau lần can thiệp đầu tiên. Nếu lưu lượng đi qua đối tác đám mây hoặc nhà tổng hợp API, việc chia sẻ chỉ báo hạ tầng và mẫu thời gian theo thỏa thuận phù hợp có thể giúp nhận ra phần chiến dịch mà một nhà cung cấp không tự quan sát được.
Checklist chỉ hoàn tất khi hệ thống chứng minh được bốn điều: nhận ra hoạt động phối hợp, phản ứng theo mức độ tin cậy, hạn chế ảnh hưởng đại trà tới khách hàng hợp pháp và tiếp tục phát hiện sau khi đối thủ đổi tài khoản, tuyến truy cập hoặc cách diễn đạt prompt. Rate limit hay ẩn chain-of-thought riêng lẻ không đáp ứng đủ bốn điều này.
Đọc thêm:
Đăng ký bản tin
Nhận tin Web3, AI và tiền mã hóa mới nhất ngay trong hộp thư.