Trợ lý chủ động: tích hợp lịch và Gmail an toàn
Bởi Win.AI Editorial
Lời khẳng định của tôi: việc xây dựng các trợ lý chủ động an toàn, có thể sử dụng để hành động trên lịch, Gmail và các ứng dụng liên kết đòi hỏi phải thiết kế một môi trường thực thi ưu tiên quyền truy cập, tách biệt lập kế hoạch khỏi hành động và tích hợp quy trình kiểm tra và hoàn tác vào lớp thực thi ngay từ ngày đầu tiên. Bài viết này cung cấp một danh sách kiểm tra kỹ thuật chặt chẽ và các yêu cầu có thể chạy được để đạt được điều đó.
THIẾT KẾ QUYỀN TRUY CẬP CHO CÁC TRỢ LÝ CHỦ ĐỘNG
Bắt đầu với OAuth theo người dùng và quyền truy cập tối thiểu. Sử dụng OAuth ràng buộc người dùng thay vì tài khoản dịch vụ chung trừ khi một quản trị viên yêu cầu rõ ràng việc ủy quyền tên miền. Tài liệu của Google về các quyền truy cập chi tiết là cơ sở tối thiểu; ánh xạ mọi khả năng của trợ lý với một quyền truy cập OAuth duy nhất và ghi lại ý định dễ hiểu cho quyền truy cập đó. Giữ cho mã thông báo không xuất hiện trong yêu cầu. Lưu trữ chúng trong một kho lưu trữ và chèn thông tin xác thực chỉ tại thời điểm gọi trong một dịch vụ thực thi tuân thủ chính sách.
Chúng tôi quan sát thấy rằng các đội ngũ coi quyền truy cập là trải nghiệm người dùng sản phẩm, với các màn hình đồng ý rõ ràng và xem trước quyền truy cập, nhận được rất ít yêu cầu hỗ trợ hơn. Một vấn đề mà chúng tôi gặp phải là sự gia tăng mã thông báo từ logic làm mới ngây thơ; tập trung việc làm mới và định kỳ thay đổi mã thông báo làm mới.
LẬP KẾ HOẠCH VÀ HÀNH ĐỘNG
Tách trợ lý thành một người lập kế hoạch và một người thực thi. Người lập kế hoạch tạo ra một kế hoạch hành động riêng biệt: đọc các chuỗi gần đây, đề xuất hai thời gian họp, soạn thảo một email dự thảo. Người thực thi chỉ thực hiện sau khi kiểm tra chính sách và, đối với các hành động nhạy cảm, cần bước xác nhận của con người. Mô hình này giữ cho mô hình không có khả năng thực hiện các thao tác quyền truy cập và làm cho việc ủy quyền có thể kiểm tra.
Thực tiễn thương lượng: độ trễ lâu hơn cho sự đồng ý của con người so với rủi ro thấp hơn. Đối với nhiều hành động lịch và email, một khoảng dừng có con người tham gia từ 30 đến 60 giây là chấp nhận được. Đối với các tác vụ có tần suất cao, việc phê duyệt theo lô hoạt động tốt hơn so với việc nhấp từng hành động một.
THỬ NGHIỆM, NHẬT KÝ VÀ PHỤC HỒI
Mỗi hành động phải tạo ra một mục kiểm toán không thể thay đổi chứa ý định yêu cầu, đầu ra của người lập kế hoạch, quyết định chính sách, cuộc gọi của người thực thi và phản hồi API nhận được. Giữ định dạng lệnh có thể phát lại để bạn có thể phát lại và hoàn tác. Cung cấp một nút nhấp để thu hồi cho N hành động cuối cùng và một quy trình phục hồi tạo ra các sự kiện bù đắp, ví dụ như hủy một sự kiện và gửi một thông báo theo dõi điều chỉnh.
Chúng tôi đã quan sát thấy rằng các hàng rào ở cấp độ yêu cầu thất bại mà không có động cơ chính sách bên ngoài. Trong thực tế, các mô hình sẽ đề xuất các thay đổi có vẻ hợp lý nhưng vi phạm chính sách. Một cổng thực thi từ chối bất kỳ phép viết nào khi độ tin cậy dưới một ngưỡng đã được hiệu chuẩn giảm bớt những sự cố này.
DANH SÁCH KIỂM TRA CHO SẢN PHẨM VÀ KỸ THUẬT
- OAuth theo người dùng với các quyền hạn tối thiểu và văn bản đồng ý rõ ràng. 2. Kho lưu trữ mã thông báo và dịch vụ thực thi chèn thông tin xác thực tại thời điểm chạy. 3. Tách biệt lập kế hoạch/người thực thi với các kiểm tra chính sách. 4. Tăng cường con người tham gia cho các hành động nhạy cảm. 5. Nhật ký kiểm toán không thể thay đổi và định dạng hành động có thể phát lại. 6. Quy trình hoàn tác và bù đắp với giao diện người dùng rõ ràng.
Liên kết trải nghiệm người dùng sản phẩm với các mô hình quy trình công việc được mô tả trong Thiết kế quy trình làm việc giữa người và AI và sử dụng phần giới thiệu về sự khác biệt của các trợ lý trong Trợ lý AI so với chatbot để biện minh cho sự tách biệt giữa người lập kế hoạch và người thực thi.
Hãy tự mình thử nghiệm. Các yêu cầu dưới đây minh chứng đầu ra của người lập kế hoạch so với các chỉ dẫn an toàn của người thực thi. Mong đợi các kế hoạch ngắn gọn như JSON từ người lập kế hoạch và các xác nhận ngắn từ người thực thi.
Yêu cầu này yêu cầu mô hình tạo ra một kế hoạch giới hạn về các thời gian họp ứng viên và lý do; hãy sử dụng nó làm người lập kế hoạch. Mong đợi 2 đến 3 khoảng thời gian ứng viên và một lý do một câu.
Bạn là một người lập kế hoạch họp. Người dùng có 3 khoảng thời gian trống hôm nay: 10:00 AM, 2:30 PM, 4:00 PM. Trả về đúng ba thời gian họp ứng viên ở định dạng ISO với một lý do cho mỗi thời gian và một ghi chú về quyền riêng tư một dòng cho biết liệu lời mời có chạm đến email bên ngoài hay không.
Yêu cầu này dành cho người thực thi. Nó yêu cầu một mã thông báo xác nhận của con người và một kiểm tra chính sách rõ ràng trước khi tạo sự kiện.
Người thực thi: với mã xác nhận của người dùng X và kế hoạch người lập kế hoạch Y, gọi Calendar.CreateEvent với các trường {start,end,attendees,summary} chỉ khi policy_check(policy_id:calendar_write) trả về pass. Nếu policy_check thất bại, trả về mã thất bại và hành động con người cần thiết.
Một phản biện là việc kiểm soát nghiêm ngặt làm chậm việc áp dụng. Ước tính của tôi là khi các đội ngũ thi hành các mô hình này, việc giữ chân người dùng sớm sẽ cải thiện vì niềm tin tăng lên, ngay cả khi sự kích hoạt ban đầu chậm hơn. Sự thương lượng là rõ ràng: phát hành nhanh hơn mà không có các kiểm soát này tạo ra rủi ro có thể đo lường và chi phí phục hồi cao hơn.
