Nhóm sở hữu dịch vụ phải trực ca cho tác tử AI khi hệ thống gặp sự cố. Trách nhiệm này cần được phân công cụ thể cho triển khai, hạ tầng, cấu hình mô hình, quyền sử dụng công cụ và giám sát. Việc phân công cũng phải bao quát chi phí, bảo mật, khôi phục phiên bản và quyết định vô hiệu hóa tác tử. Mọi hành động rủi ro cao phải được chuyển cho một người đã xác thực phê duyệt.
Lúc 2 giờ 07 phút sáng, một tác tử AI bắt đầu gặp lỗi. Ứng dụng vẫn chạy, nhưng các yêu cầu hết thời gian chờ vì một giao diện lập trình ứng dụng ở phía sau trả về lỗi. Tác tử thử lại hai lần, tiêu thụ nhiều mã thông báo hơn bình thường và mất thời gian phản hồi gần gấp đôi. Tình huống này được mô tả trong bài viết của The New Stack về quyền sở hữu tác tử AI trong môi trường vận hành.
Câu hỏi cần được trả lời ngay không phải là nên dùng mô hình nào, mà là ai đang chịu trách nhiệm cho hệ thống.
Các nhóm phát triển thường dành nhiều công sức cho câu lệnh, truy xuất dữ liệu, công cụ và lựa chọn mô hình. Khi tác tử đi vào môi trường thật, quyền sở hữu vận hành quyết định nó là một dịch vụ đáng tin cậy hay một nguồn rủi ro mới. Đây là phần không thể tách rời khỏi việc xây dựng hạ tầng AI có thể vận hành ổn định.
Nội dung vận hành tác tử AI như một dịch vụ
Một tác tử dùng trong sản xuất cần có danh tính vận hành như mọi dịch vụ khác. Hồ sơ tối thiểu phải nêu tên dịch vụ, nhóm phụ trách, cấp độ quan trọng và kênh báo động khi xảy ra sự cố.
Thông tin sở hữu biến tác tử từ một thử nghiệm chạy trong tiến trình Python thành một dịch vụ chính thức. Dịch vụ đó có nhóm chịu trách nhiệm và đường chuyển cấp rõ ràng. Cùng một bộ thông tin có thể xuất hiện trong nhật ký, dấu vết phân tán, bảng theo dõi, cảnh báo và hồ sơ triển khai.
Một người không nhất thiết phải phụ trách mọi mặt. Tuy nhiên, mỗi trách nhiệm phải có chủ thể cụ thể. Phạm vi này gồm triển khai, hạ tầng, cấu hình mô hình, chi phí, bảo mật, khôi phục phiên bản và quyết định tắt tác tử.
Xác định rõ tác tử được phép làm gì
Quyền sở hữu tác tử AI bao gồm giới hạn hành động mà hệ thống được phép thực hiện. Tác tử chỉ đọc dữ liệu giám sát có mức rủi ro thấp hơn tác tử có thể khởi động lại dịch vụ, thay đổi hạ tầng hoặc triển khai mã nguồn.
Cách kiểm soát trực tiếp là lập danh sách công cụ được phép sử dụng. Tác tử có thể kiểm tra tình trạng dịch vụ, xem các lần triển khai gần đây, tìm sổ tay xử lý sự cố hoặc tóm tắt sự cố nếu những quyền đó đã được cấp. Mọi công cụ không có trong danh sách phải bị từ chối theo mặc định.
Việc bổ sung năng lực mới cần là một quyết định kỹ thuật có chủ đích, không phải hệ quả tự động khi tác tử phát hiện thêm công cụ. Với thao tác có thể gây gián đoạn, như khởi động lại hệ thống hoặc triển khai phiên bản mới, quyết định cuối cùng phải thuộc về một người đã được xác thực. Những tranh luận về mức quyền phù hợp của AI trong trung tâm vận hành an ninh cũng tập trung vào ranh giới này.
Đặt ngân sách cho toàn bộ quá trình thực thi
Mỗi luồng công việc của tác tử cần có mức trần về thời gian chạy, số lần gọi mô hình, số lần gọi công cụ và lượng mã thông báo nếu hệ thống đo được. Khi chạm trần, tác tử phải dừng và chuyển vụ việc cho con người.
Theo ví dụ của The New Stack, giới hạn mặc định là 5 bước và 8 lần gọi công cụ. Một tác tử chẩn đoán đơn giản có thể chỉ cần 3 bước, trong khi một quy trình nghiên cứu phức tạp cần nhiều hơn. Các mức trần nên được truyền qua cấu hình hoặc biến môi trường thay vì chôn cố định trong mã ứng dụng.
Ngân sách phải được tạo một lần và dùng xuyên suốt luồng công việc. Nếu hệ thống tạo ngân sách mới cho từng lần gọi, các bộ đếm sẽ quay về ban đầu và tác tử có thể vượt giới hạn qua nhiều lần thực thi liên tiếp. Tác tử không được tự cấp thêm lượt thử sau khi đã dùng hết ngân sách.
Ghi lại mọi lần gọi mô hình
Mỗi lần gọi mô hình cần ghi lại độ trễ, mô hình được sử dụng, kết quả và công cụ đã gọi. Nhật ký cũng cần có lượng mã thông báo nếu đo được, mã định danh yêu cầu và sự kiện chuyển cấp. Thiếu các dữ liệu này, nhóm phụ trách không thể giải thích tác tử đã làm gì trong một sự cố.
Mã định danh yêu cầu đặc biệt hữu ích khi một sự cố đi qua nhiều dịch vụ. Kỹ sư phải có khả năng đi từ cảnh báo đến yêu cầu của tác tử, sau đó lần theo các lần gọi mô hình và công cụ ở phía dưới.
Nhật ký ứng dụng chỉ là lớp đầu tiên. Trong môi trường vận hành, nhóm kỹ thuật còn cần dấu vết phân tán và số liệu đo lường để xác định tác tử đã làm gì, mất bao lâu và phụ thuộc nào phát sinh lỗi. Việc này liên quan trực tiếp đến cách triển khai tác tử AI trên Kubernetes, nơi nền tảng điều phối phải phân biệt lỗi của tiến trình với lỗi của dịch vụ phụ thuộc.
Tách lỗi kỹ thuật khỏi quyết định chuyển cấp
Lỗi kỹ thuật và quyết định chuyển cấp là hai vấn đề riêng. Một lần gọi mô hình thất bại không nhất thiết khiến toàn bộ dịch vụ ngừng hoạt động, còn một lần gọi thành công không có nghĩa đề xuất của tác tử được phép thực thi tự động.
Hệ thống cần xác định lỗi nào có thể thử lại, lỗi nào phải chặn thao tác và lỗi nào phải chuyển cho con người. Nếu tác tử ngừng hoạt động, đội kỹ thuật vẫn phải xử lý sự cố bằng quy trình và sổ tay có sẵn. Đây là cách hệ thống suy giảm có kiểm soát.
Buộc con người phê duyệt hành động rủi ro cao
Tác tử có thể phân tích và đề xuất, nhưng hành động rủi ro cao cần người đã xác thực phê duyệt. Ranh giới này ngăn một kết quả do mô hình tạo ra tự động trở thành thay đổi trên hệ thống thật.
Ví dụ, tác tử có thể đọc dữ liệu giám sát, đưa ra chẩn đoán và đề nghị tăng kích thước nhóm kết nối cơ sở dữ liệu. Nó không được tự đẩy thay đổi đó vào môi trường thật chỉ vì mô hình đã sinh ra đề xuất.
Luồng kiểm soát nên đi từ dữ liệu giám sát đến tác tử, chẩn đoán, hành động đề xuất, kiểm tra rủi ro, phê duyệt của con người và cuối cùng mới đến thay đổi trên hệ thống. Tác tử có thể đảm nhận suy luận nhưng không mặc nhiên có quyền cho phép.
Tách kiểm tra sống còn và trạng thái sẵn sàng
Kiểm tra sống còn xác nhận tiến trình ứng dụng vẫn phản hồi. Kiểm tra sẵn sàng xác nhận tác tử và các phụ thuộc thiết yếu đang ở trạng thái có thể phục vụ yêu cầu. Hai phép kiểm tra này cần được triển khai riêng.
Các phụ thuộc cần kiểm tra có thể gồm nhà cung cấp mô hình, cơ sở dữ liệu véc tơ hoặc dịch vụ cấu hình. Trong ví dụ của The New Stack, yêu cầu kiểm tra nhà cung cấp có thời gian chờ 2 giây. Điểm kiểm tra sẵn sàng trả về mã HTTP 503 khi phụ thuộc không khả dụng.
Việc tách hai phép kiểm tra giúp nền tảng điều phối nhận biết khi nào cần khởi động lại ứng dụng và khi nào chỉ nên tạm ngừng chuyển lưu lượng đến một dịch vụ chưa sẵn sàng.
Đóng hệ thống khi lớp an toàn bị hỏng
Tác tử phải dừng hoặc từ chối hành động khi cơ chế kiểm soát tương ứng không còn hoạt động. Mỗi loại lỗi cần dẫn đến một kết quả đã được xác định trước.
- Nếu kiểm tra quyền thất bại, thao tác được yêu cầu phải bị chặn.
- Khi ngân sách thực thi đã cạn, vụ việc phải được chuyển cho con người thay vì tiếp tục thử lại.
- Nếu mô hình tạm thời gặp lỗi, hệ thống phải áp dụng chính sách xử lý lỗi đã định trước.
Các biện pháp này phải tồn tại trong toàn bộ quá trình thực thi. Việc dùng lại cùng một ngân sách qua các bước bảo đảm mỗi lần gọi được tính vào giới hạn chung. Khi đạt giới hạn, tác tử phải dừng thay vì bắt đầu lại với bộ đếm mới.
Chuẩn bị sổ tay xử lý sự cố lúc 2 giờ sáng
Sổ tay xử lý sự cố phải giúp kỹ sư trực ca xác định trạng thái của tác tử, các dịch vụ phụ thuộc và hậu quả nếu vô hiệu hóa AI. Theo khung xử lý của The New Stack, kỹ sư cần nhanh chóng trả lời 5 câu hỏi:
- Bản thân tác tử có đang hoạt động bình thường không?
- Nhà cung cấp mô hình có đang hoạt động không?
- Hệ thống truy xuất hoặc các công cụ phụ thuộc có gặp lỗi không?
- Chi phí hoặc độ trễ có vượt phạm vi thông thường không?
- Điều gì xảy ra nếu tắt tác tử?
Câu hỏi cuối xác định đường suy giảm của hệ thống. Nếu tác tử hỗ trợ ứng phó sự cố không khả dụng, hệ thống vẫn phải tạo sự cố, giữ dữ liệu giám sát, kích hoạt sổ tay tiêu chuẩn và cho phép kỹ sư tiếp tục điều tra.
AI nên giúp hoạt động vận hành nhanh hơn. Tổ chức không nên mất khả năng xử lý sự cố chỉ vì tác tử ngừng hoạt động.
Ai sở hữu tác tử AI?
Nhóm sở hữu dịch vụ chịu trách nhiệm vận hành tác tử AI, nhưng từng phần việc có thể thuộc về các nhóm khác nhau. Danh sách trách nhiệm cần nêu rõ chủ thể phụ trách triển khai, hạ tầng, cấu hình mô hình, quyền công cụ và giám sát. Danh sách này cũng phải phân công ứng phó sự cố, chi phí, bảo mật, khôi phục phiên bản và quyết định vô hiệu hóa tác tử.
Phép thử thực tế diễn ra lúc 2 giờ sáng, khi tác tử phản hồi chậm, thử lại nhiều lần và một dịch vụ phụ thuộc đang trả lỗi. Tác tử sẵn sàng cho môi trường thật phải có người nhận cảnh báo và ngân sách ngăn thực thi mất kiểm soát. Hệ thống cũng cần dữ liệu quan sát giải thích được diễn biến, ranh giới quyền hạn rõ ràng và phương án để kỹ sư tiếp tục làm việc khi không có AI.
Mục tiêu là xác định chính xác trách nhiệm của tác tử kết thúc ở đâu và con người phải can thiệp từ điểm nào.
Nếu đang đưa tác tử AI vào hệ thống thật, hãy ghi tên nhóm trực ca và đường chuyển cấp trước khi cấp thêm quyền hành động cho nó.
