Rào chắn Cổng AI: Xác thực Lời nhắc và Kết quả trước khi Người dùng nhìn thấy chúng

Các ứng dụng AI sản xuất cần nhiều hơn một lời nhắc tốt. Chúng cần một lớp kiểm soát có thể kiểm tra những gì đi vào mô hình, kiểm tra những gì quay lại, và đưa ra quyết định rõ ràng trước khi phản hồi đến người dùng hoặc hệ thống hạ nguồn.

Đó là ý tưởng đằng sau các rào chắn cổng AI.

Kiến trúc chính xác sẽ thay đổi tùy theo sản phẩm. Một số nhóm đặt các kiểm tra trong backend ứng dụng. Một số sử dụng cổng hoặc proxy. Một số kết hợp cài đặt an toàn cấp mô hình với xác thực tùy chỉnh. Điểm quan trọng là an toàn không nên phụ thuộc vào việc mỗi nhóm tính năng nhớ kết nối cùng logic vào mỗi điểm cuối.

Đối với các nhà xây dựng, các rào chắn là một phần của trách nhiệm sản phẩm. ShareAI có thể giúp bạn định tuyến việc sử dụng mô hình và kiếm tiền từ lưu lượng AI, nhưng ứng dụng của bạn vẫn sở hữu chính sách, quyền, ghi nhật ký, trải nghiệm khách hàng, và đánh giá của con người.

Tại sao các rào chắn cấp cổng lại quan trọng

Một ứng dụng AI thường bắt đầu đơn giản. Một điểm cuối gọi một mô hình. Sau đó việc sử dụng mở rộng: nhiều tính năng hơn, nhiều khách hàng hơn, nhiều nhà cung cấp mô hình hơn, nhiều công cụ nội bộ hơn, nhiều đầu vào do người dùng tạo hơn, và nhiều nơi mà câu trả lời được tạo ra có thể kích hoạt hành động.

Tại thời điểm đó, logic an toàn theo tính năng trở nên khó tin cậy. Một phiên bản ứng dụng có thể chặn tiêm lời nhắc. Một phiên bản khác chỉ kiểm tra độc hại. Phiên bản thứ ba có thể bỏ qua xác thực đầu ra vì nhóm đang chạy đua để ra mắt.

Các rào chắn cấp cổng giải quyết vấn đề nhất quán bằng cách đặt xác thực gần lưu lượng mô hình. Ứng dụng có thể gửi yêu cầu qua một lớp chia sẻ đánh giá lời nhắc, phản hồi mô hình, hoặc cả hai. Lớp này trả về một phán quyết như cho phép, chặn, chỉnh sửa, xem xét, hoặc thử lại.

Điều này không loại bỏ nhu cầu phán đoán sản phẩm. Nó tạo ra một nơi để thực thi điều đó.

Các rào chắn tốt nên trả lời bốn câu hỏi:

• Lời nhắc này có an toàn để gửi đến một mô hình không?
• Đầu ra của mô hình này có an toàn để hiển thị cho người dùng không?
• Mô hình có giữ vững căn cứ trong bằng chứng mà ứng dụng cung cấp không?
• Điều gì đã xảy ra, và nhóm có thể kiểm tra quyết định sau này không?

Những gì cần xác thực trước khi gọi mô hình

Xác thực đầu vào bắt các rủi ro trước khi chúng đến mô hình.

Danh mục đầu tiên là tiêm lệnh nhắc. Một người dùng, tài liệu, trang web, hoặc kết quả công cụ có thể chứa các hướng dẫn được thiết kế để ghi đè lệnh nhắc hệ thống, rò rỉ ngữ cảnh ẩn, hoặc buộc mô hình gọi một công cụ mà nó không nên sử dụng. OWASP Top 10 cho Ứng dụng LLM coi tiêm lệnh nhắc và quyền hạn quá mức là các rủi ro cốt lõi của ứng dụng LLM vì một lý do: mô hình có thể đang tuân theo hướng dẫn, nhưng sản phẩm vẫn chịu trách nhiệm về kết quả.

Danh mục thứ hai là phù hợp chính sách. Nếu ứng dụng của bạn không hỗ trợ nội dung liên quan đến y tế, pháp lý, tài chính, người lớn, lạm dụng, hoặc tự gây hại, hãy xác thực điều đó trước khi tiêu tốn token mô hình hoặc tạo câu trả lời hướng đến khách hàng.

Danh mục thứ ba là dữ liệu nhạy cảm. Một số lệnh nhắc có thể chứa bí mật, thông tin đăng nhập, dữ liệu cá nhân, hoặc nội dung độc quyền cần được chặn, che giấu, hoặc xử lý qua quy trình nghiêm ngặt hơn.

Danh mục thứ tư là quyền công cụ. Nếu ứng dụng của bạn kết nối mô hình với các công cụ thông qua các mẫu như Giao thức ngữ cảnh mô hình, xác thực nên xem xét những gì mô hình được phép truy cập. Đọc một tệp, truy vấn cơ sở dữ liệu, gửi email, và xóa một bản ghi không nên chia sẻ cùng mức độ tin cậy.

Những gì cần xác thực trước khi người dùng thấy đầu ra

Xác thực đầu ra bắt các vấn đề sau khi tạo nhưng trước khi hiển thị.

Bắt đầu với các kiểm tra an toàn trực tiếp: độc hại, quấy rối, hướng dẫn không an toàn, thông tin nhạy cảm, và vi phạm chính sách. Mô hình có thể tạo ra thứ gì đó mà sản phẩm của bạn không nên hiển thị ngay cả khi lệnh nhắc ban đầu trông vô hại.

Tiếp theo, xác thực cơ sở. Nếu ứng dụng của bạn cung cấp tài liệu tham khảo, đoạn trích truy xuất, hàng cơ sở dữ liệu, hoặc hồ sơ khách hàng, câu trả lời nên được kiểm tra dựa trên ngữ cảnh đó. Một câu trả lời lưu loát nhưng không được hỗ trợ có thể gây hại hơn một thất bại rõ ràng vì người dùng có khả năng tin tưởng nó hơn.

Sau đó, xác thực cấu trúc. Nếu đầu ra được cho là JSON, macro hỗ trợ, điều khoản hợp đồng, cập nhật cơ sở dữ liệu, hoặc lệnh công cụ, hãy kiểm tra schema và các trường được phép. Đừng để mô hình viết văn bản tùy ý vào nơi yêu cầu dữ liệu bị giới hạn.

Cuối cùng, xác thực sự sẵn sàng hành động. Một email nháp có thể được hiển thị cho người dùng để xem xét. Một phê duyệt hoàn tiền, thay đổi tài khoản, hợp nhất mã, hoặc thông báo khách hàng có thể cần một cổng kiểm tra của con người rõ ràng.

Mục tiêu không phải là làm cho mọi câu trả lời hoàn hảo. Đó là ngăn chặn các thất bại có thể dự đoán được đến những nơi mà chúng gây tốn kém.

Chọn chặn, cho phép hoặc xem xét hành vi một cách có chủ ý

Một rào chắn chỉ hữu ích nếu sản phẩm biết cách xử lý kết quả.

Đối với các vấn đề rủi ro thấp, ứng dụng có thể yêu cầu người dùng sửa đổi lời nhắc. Đối với các đầu ra không được hỗ trợ, ứng dụng có thể trả lời bằng một phương án an toàn và giải thích rằng không thể xác minh kết quả. Đối với các hành động rủi ro cao, ứng dụng có thể gửi yêu cầu đến người kiểm duyệt.

Quyết định khó khăn nhất là cách xử lý các lỗi của hệ thống rào chắn. Nếu không có xác minh, ứng dụng nên tiếp tục hoạt động hay dừng lại và chặn yêu cầu?

Không có câu trả lời chung.

Tiếp tục hoạt động có thể hợp lý đối với các tính năng soạn thảo rủi ro thấp, nơi tính khả dụng quan trọng và đầu ra vẫn cần người dùng xem xét. Dừng lại sẽ an toàn hơn đối với các quy trình liên quan đến lời khuyên được quy định, hành động tài chính, thay đổi tài khoản, dữ liệu riêng tư hoặc thực thi công cụ bên ngoài.

Đưa ra quyết định này theo từng quy trình, không áp dụng toàn cầu. Một sản phẩm có thể dễ dãi đối với việc động não và nghiêm ngặt đối với các hành động ảnh hưởng đến khách hàng, tiền bạc, dữ liệu hoặc bảo mật.

Giữ vai trò của ShareAI rõ ràng

ShareAI giúp các Nhà xây dựng kết nối việc sử dụng AI với một thị trường và lớp API. Các Nhà xây dựng có thể định tuyến suy luận qua ShareAI, chọn mô hình từ thị trường mô hình, và đặt mức lợi nhuận khi ứng dụng của họ tạo ra việc sử dụng AI.

Điều đó không làm cho ShareAI trở thành chủ sở hữu mô hình an toàn sản phẩm của bạn.

Nhà xây dựng vẫn sở hữu:

• Xác thực và cấp quyền người dùng.
• Chính sách nội dung cụ thể của ứng dụng.
• Xác minh lời nhắc và đầu ra.
• Quyền công cụ và luồng phê duyệt.
• Xử lý lỗi hướng tới khách hàng.
• Ghi nhật ký, giám sát và xem xét hỗ trợ.
• Quyết định về quyền riêng tư và tuân thủ.

Sự phân biệt này rất quan trọng. ShareAI có thể hỗ trợ kinh tế cho sản phẩm AI của bạn, nhưng các rào cản là một phần của hợp đồng ứng dụng bạn thực hiện với khách hàng.

Nếu bạn đang triển khai quy trình làm việc của Builder, hãy bắt đầu với tài liệu ShareAI và Tham khảo API, sau đó kết hợp tích hợp với các kiểm tra chính sách và khả năng quan sát của riêng bạn.

Danh sách kiểm tra triển khai thực tế

Sử dụng danh sách kiểm tra này khi thêm các rào cản xung quanh các cuộc gọi mô hình sản xuất:

• Liệt kê mọi quy trình làm việc AI trong sản phẩm.
• Phân loại từng quy trình làm việc theo rủi ro: soạn thảo, tư vấn, hành động của khách hàng, truy cập dữ liệu, hành động công cụ hoặc lĩnh vực được quy định.
• Xác thực các lời nhắc để phát hiện các nỗ lực tiêm mã, nội dung không an toàn, yêu cầu không được hỗ trợ và dữ liệu nhạy cảm.
• Xác thực đầu ra để phát hiện vi phạm chính sách, tuyên bố không được hỗ trợ, lỗi cấu trúc và rò rỉ dữ liệu.
• Quyết định quy trình làm việc nào có thể thất bại mở và quy trình nào phải thất bại đóng.
• Thêm đánh giá của con người cho các hành động không thể đảo ngược hoặc có tác động cao.
• Ghi lại các phán quyết, ID mô hình, ID quy trình làm việc, ID người dùng và mã lý do.
• Theo dõi độ trễ xác thực và tỷ lệ thất bại.
• Kiểm tra với các lời nhắc đối kháng, tài liệu lộn xộn và tiêm kết quả công cụ.
• Xem lại các chính sách khi việc sử dụng mở rộng.

Đối với khả năng quan sát, Hướng dẫn cơ bản về khả năng quan sát OpenTelemetry là một điểm khởi đầu hữu ích. Các rào cản AI nên tạo ra các dấu vết và nhật ký giải thích không chỉ rằng một yêu cầu đã bị chặn, mà còn tại sao nó bị chặn và ứng dụng đã làm gì tiếp theo.

Câu hỏi thường gặp

Rào cản cổng AI là gì?

Rào cản cổng AI là các kiểm tra xác thực được đặt gần lưu lượng mô hình. Chúng kiểm tra các lời nhắc, đầu ra hoặc các cuộc gọi công cụ và đưa ra các quyết định như cho phép, chặn, xem xét hoặc thử lại trước khi phản hồi AI đến người dùng hoặc hệ thống.

ShareAI có cung cấp một công cụ rào cản AI không?

Bài viết này không định vị ShareAI như một công cụ rào cản. ShareAI giúp các Nhà xây dựng truy cập mô hình, định tuyến việc sử dụng AI và kiếm tiền từ lưu lượng ứng dụng. Các Nhà xây dựng nên triển khai các biện pháp an toàn, chính sách, ghi nhật ký và kiểm tra cụ thể sản phẩm trong ngăn xếp ứng dụng của riêng họ.

Tại sao cần xác thực cả lời nhắc và đầu ra?

Xác thực lời nhắc bắt các đầu vào không an toàn hoặc mang tính thao túng trước khi chúng đến mô hình. Xác thực đầu ra bắt các phản hồi không an toàn, không được hỗ trợ, bị lỗi định dạng hoặc vi phạm chính sách trước khi người dùng hoặc hệ thống hạ nguồn nhìn thấy chúng.

Tiêm lời nhắc là gì?

Tiêm lời nhắc là một nỗ lực để thao túng mô hình bằng các hướng dẫn mâu thuẫn với hành vi dự định của ứng dụng. Nó có thể đến từ đầu vào của người dùng, tài liệu được truy xuất, trang web hoặc kết quả công cụ.

Kiểm tra đầu ra nên kiểm tra những gì?

Kiểm tra đầu ra nên kiểm tra nội dung không an toàn, các tuyên bố không được hỗ trợ, rò rỉ dữ liệu nhạy cảm, lỗi cấu trúc, ảo giác so với ngữ cảnh được cung cấp và sự sẵn sàng cho bất kỳ hành động tiếp theo nào.

Mọi yêu cầu bị chặn có nên thất bại theo cùng một cách không?

Không. Một tính năng động não có thể phản hồi khác với một quy trình làm việc tài chính hoặc công cụ quản lý tài khoản. Hãy điều chỉnh phản hồi theo rủi ro: yêu cầu người dùng chỉnh sửa, hiển thị một phương án an toàn, gửi để xem xét hoặc chặn hoàn toàn.

Thất bại mở so với thất bại đóng là gì?

Thất bại mở có nghĩa là ứng dụng tiếp tục hoạt động khi hệ thống bảo vệ không khả dụng. Thất bại đóng có nghĩa là ứng dụng chặn yêu cầu cho đến khi kiểm tra khả dụng. Các quy trình làm việc có rủi ro cao thường xứng đáng có hành vi nghiêm ngặt hơn so với các tính năng soạn thảo có rủi ro thấp.

Các biện pháp bảo vệ ảnh hưởng như thế nào đến việc kiếm tiền của Builder?

Các biện pháp bảo vệ có thể giảm các cuộc gọi mô hình lãng phí, ngăn chặn các thất bại tốn kém và làm cho các quy trình làm việc AI cao cấp dễ dàng được tin tưởng hơn. Các nhà phát triển vẫn có thể định tuyến sử dụng qua ShareAI và đặt mức lợi nhuận, nhưng sản phẩm nên kiểm soát khi nào một quy trình làm việc được phép tiêu tốn thêm token hoặc tiếp tục.

Các biện pháp bảo vệ có thay thế việc xem xét của con người không?

Không. Các biện pháp bảo vệ giảm rủi ro có thể dự đoán, nhưng việc xem xét của con người vẫn quan trọng đối với các hành động không thể đảo ngược, quy trình làm việc được quy định, kết quả khách hàng nhạy cảm và các trường hợp mà mô hình không chắc chắn.

Các cơ quan nên nghĩ về các biện pháp bảo vệ như thế nào?

Các cơ quan nên coi các biện pháp bảo vệ là một phần của sản phẩm giao cho khách hàng. Xác định chính sách, ghi nhật ký, hành vi leo thang và xem xét trước khi ra mắt, đặc biệt khi tính năng AI liên quan đến dữ liệu khách hàng hoặc công cụ bên ngoài.

Các biện pháp bảo vệ cổng chỉ dành cho các doanh nghiệp lớn?

Không. Các nhóm nhỏ hơn cũng được hưởng lợi từ việc kiểm tra nhất quán khi họ có nhiều hơn một tính năng AI, nhiều hơn một mô hình hoặc bất kỳ quy trình làm việc nào có thể ảnh hưởng đến người dùng, dữ liệu hoặc tiền bạc.

Biện pháp bảo vệ đầu tiên cần thêm là gì?

Bắt đầu với phát hiện tiêm lệnh, kiểm tra chính sách đầu ra và xác thực cấu trúc cho các đầu ra có cấu trúc. Sau đó thêm kiểm tra căn cứ, quyền công cụ và đánh giá của con người khi rủi ro quy trình làm việc yêu cầu.