Bảo trì AI Agent sau khi triển khai: Doanh nghiệp cần làm những việc gì?

Nhiều dự án AI Agent được lên kế hoạch kỹ đến ngày đi vào vận hành rồi dừng ở đó. Một thời gian sau, bảng giá đã đổi nhưng agent vẫn báo giá cũ, một API phía đối tác đổi tên trường khiến lead không vào được CRM, còn nhân viên mới không biết ai chịu trách nhiệm sửa. Agent không hỏng đột ngột mà xuống cấp dần theo từng thay đổi xung quanh nó.

Khác với phần mềm truyền thống, AI Agent phụ thuộc vào nhiều thứ có thể đổi mà không báo trước: dữ liệu nghiệp vụ, mô hình của nhà cung cấp, API của hệ thống khác, quyền của người dùng. Bảo trì vì thế là việc định kỳ, có người sở hữu và có quy trình, không phải chỉ phản ứng khi có người phàn nàn.

Bài viết liệt kê những việc bảo trì cần làm, cách tổ chức quy trình và ai chịu trách nhiệm phần nào.

1. Bản chất của bảo trì AI Agent

Bảo trì AI Agent là giữ cho agent tiếp tục trả lời đúng và thao tác đúng khi mọi thứ xung quanh thay đổi. Có bốn nguồn thay đổi chính: nội dung nghiệp vụ như giá, chính sách, sản phẩm; hệ thống kết nối như CRM, ERP hay nền tảng nhắn tin; mô hình AI và prompt; và con người, gồm người dùng mới, người rời đi, vai trò thay đổi.

Khối lượng bảo trì tăng theo những gì agent được phép làm. Agent chỉ hỏi đáp cần giữ kho kiến thức luôn mới và chạy lại bộ câu hỏi khi nội dung đổi. Agent tra cứu thời gian thực cần theo dõi thêm kết nối và độ trễ. Agent ghi vào hệ thống cần rà quyền định kỳ, theo dõi thao tác lỗi và có cách tạm dừng nhanh. Các chỉ số giúp phát hiện agent đang xuống cấp được trình bày ở bài KPI AI Agent.

2. Các yếu tố cần thiết kế

1. Cập nhật dữ liệu

Mỗi nguồn trong kho kiến thức cần có người sở hữu, lịch rà soát và quy tắc rõ: khi nội dung gốc đổi thì ai cập nhật vào kho và trong bao lâu. Tài liệu cũ phải được gỡ hoặc đánh dấu hết hiệu lực, không chỉ thêm bản mới bên cạnh. Dấu hiệu thiếu bảo trì là agent trả lời theo hai phiên bản chính sách khác nhau tùy cách hỏi.

2. Kiểm thử hồi quy

Bộ kiểm thử hồi quy là tập câu hỏi và tác vụ mẫu có kết quả mong đợi, được chạy lại sau mỗi thay đổi. Bộ này nên lớn dần: mỗi lỗi phát hiện trong vận hành được thêm thành một ca thử để không tái diễn. Nên chạy tự động được, và phải có người đọc kỹ những ca chuyển từ đạt sang không đạt.

3. Theo dõi API

Các kết nối tới CRM, ERP, cổng thanh toán hay nền tảng nhắn tin cần được theo dõi tỷ lệ lỗi, độ trễ và thay đổi cấu trúc dữ liệu trả về. Nên có cảnh báo khi một trường bắt buộc biến mất hoặc đổi kiểu, thay vì để agent âm thầm bỏ qua. Theo dõi cả thông báo đổi phiên bản từ nhà cung cấp để chuẩn bị trước.

4. Rà soát quyền

Theo thời gian, quyền thường được cấp thêm mà ít khi thu hồi. Định kỳ cần đối chiếu tài khoản dịch vụ của agent đang có quyền gì so với danh sách đã duyệt, và người dùng nào còn truy cập được dữ liệu gì. Nhân viên nghỉ việc hoặc chuyển bộ phận phải được cập nhật quyền ở agent cùng lúc với các hệ thống khác.

5. Quản lý phiên bản prompt

Prompt, hướng dẫn hệ thống, danh sách công cụ và cấu hình mô hình nên được lưu có phiên bản như mã nguồn, kèm người sửa và lý do. Sửa một câu trong prompt để chữa một lỗi có thể làm lệch câu trả lời ở chỗ khác, nên mỗi thay đổi đều cần chạy lại bộ hồi quy. Khi có sự cố, phải quay về được phiên bản trước một cách nhanh chóng.

6. Kiểm tra chi phí

Chi phí gọi mô hình tăng khi lượng người dùng tăng, khi kho kiến thức lớn lên hoặc khi prompt dài thêm sau mỗi lần sửa. Nên xem chi phí theo từng loại tác vụ và đặt hạn mức cảnh báo để sớm phát hiện vòng lặp lỗi hay lượng truy cập bất thường. Các khoản chi phí liên quan xem thêm ở bài chi phí triển khai AI Agent.

7. Xử lý phản hồi người dùng

Đánh giá không hài lòng, câu hỏi bị chuyển người và góp ý của nhân viên là nguồn tìm lỗi tốt nhất. Cần một nơi tập trung các phản hồi này, người phân loại theo nguyên nhân và hạn xử lý. Phản hồi nào dẫn tới sửa dữ liệu hay prompt thì báo lại cho người góp ý để họ tiếp tục phản hồi.

8. Kế hoạch thay đổi nhà cung cấp

Nhà cung cấp mô hình có thể ngừng một phiên bản, đổi giá hoặc đổi điều khoản sử dụng. Doanh nghiệp nên biết trước nếu phải đổi mô hình thì làm những gì: chạy bộ hồi quy trên mô hình mới, so chất lượng và chi phí, điều chỉnh prompt. Tránh gắn chặt logic nghiệp vụ vào đặc điểm riêng của một mô hình.

3. Quy trình triển khai thực tế

Bước 1: Xác định phạm vi và kết quả cần đo

Liệt kê agent đang phục vụ quy trình nào, dùng những nguồn dữ liệu, kết nối và quyền gì, và chỉ số nào cho biết agent còn hoạt động tốt. Đầu ra là bản mô tả hiện trạng vận hành kèm danh sách thành phần cần bảo trì và nhịp rà soát từng thành phần. Chủ nghiệp vụ và đội kỹ thuật cùng xác nhận bản này.

Bước 2: Chuẩn hóa dữ liệu cùng quyền truy cập

Gán người sở hữu cho từng nguồn dữ liệu và từng kết nối, ghi rõ quy trình cập nhật: ai sửa, ai duyệt, sửa xong chạy lại những ca thử nào. Lập danh sách quyền hiện có của agent để làm mốc so sánh cho các lần rà soát sau.

Bước 3: Thiết kế tích hợp ngoại lệ và phê duyệt

Thiết lập cảnh báo cho các sự cố cần xử lý ngay: API lỗi liên tục, chi phí vượt hạn mức, tỷ lệ chuyển người tăng đột biến, thao tác ghi bị trùng. Mỗi cảnh báo gắn với người nhận và hành động mặc định, chẳng hạn tạm dừng tác vụ ghi và chuyển sang quy trình thủ công. Thay đổi lớn như đổi mô hình hay mở thêm quyền phải được duyệt trước khi áp dụng.

Bước 4: Kiểm thử vận hành rồi cải thiện theo log

Duy trì lịch định kỳ: xem nhật ký lỗi và phản hồi, chạy bộ hồi quy, rà quyền, xem chi phí. Mỗi lần xử lý sự cố, ghi nguyên nhân và bổ sung ca thử tương ứng. Cách ghi nhật ký đủ để điều tra xem thêm bài nhật ký AI Agent.

4. Ví dụ giả định

Sau khi bảng giá đổi, đội vận hành cập nhật nguồn và chạy lại bộ câu hỏi giá, chiết khấu và ngoại lệ. Một API CRM thay đổi trường dữ liệu được phát hiện qua cảnh báo trước khi làm mất lead.

Tình huống này cho hai ca thử cần có sẵn trong bộ hồi quy. Ca thứ nhất: sau khi đổi nguồn bảng giá, hỏi giá từng gói, giá có chiết khấu và các trường hợp ngoại lệ, rồi đối chiếu với bảng giá mới. Ca thứ hai: giả lập API CRM trả về thiếu trường số điện thoại, hệ thống phải cảnh báo và giữ lead ở hàng chờ thay vì bỏ qua. Bài học là cảnh báo và bộ hồi quy phải có từ trước, không đợi sự cố xảy ra mới dựng.

5. Rủi ro và giới hạn

• Không coi ngày go live là kết thúc
• Mọi thay đổi cần kiểm thử lại
• Theo dõi phụ thuộc bên thứ ba
• Duy trì người sở hữu nghiệp vụ

Rủi ro lớn nhất sau khi vận hành là không ai còn chịu trách nhiệm: đội dự án chuyển sang việc khác, chủ nghiệp vụ nghĩ đội kỹ thuật lo, đội kỹ thuật nghĩ nội dung là việc của nghiệp vụ. Các phụ thuộc bên thứ ba như nhà cung cấp mô hình, nền tảng nhắn tin hay phần mềm quản lý có thể đổi bất cứ lúc nào. Mọi thay đổi, dù nhỏ như sửa một đoạn chính sách, đều có thể ảnh hưởng câu trả lời ở chỗ khác nếu không kiểm thử lại.

6. Phân chia trách nhiệm vận hành

Chủ nghiệp vụ giữ nội dung và quy tắc, gồm bảng giá, chính sách, kịch bản chuyển người, và là người duyệt khi nội dung thay đổi. Người vận hành hằng ngày đọc phản hồi, phân loại lỗi, cập nhật kho kiến thức và chạy bộ hồi quy. Đội kỹ thuật theo dõi kết nối, chi phí, phiên bản mô hình và xử lý sự cố hạ tầng.

Nên có buổi rà soát định kỳ giữa các bên để xem chỉ số, sự cố và các thay đổi sắp tới như bảng giá mới hay hệ thống mới. Người có quyền tạm dừng agent phải được ghi tên cụ thể, cùng phương án thủ công thay thế, để khi có sự cố không phải đi tìm người quyết định.

7. Chỉ số nên theo dõi

• Tỷ lệ hoàn thành đúng theo tiêu chí đã duyệt
• Tỷ lệ từ chối đúng và chuyển người phụ trách
• Lỗi tích hợp, độ trễ và số thao tác phải sửa
• Chi phí cùng tác động kinh doanh của quy trình

Với bảo trì, nên nhìn xu hướng hơn là một thời điểm: độ đúng có giảm dần không, tỷ lệ chuyển người có tăng sau một lần thay đổi không, lỗi tích hợp tập trung ở kết nối nào. Nên đo thêm khoảng thời gian từ khi nội dung gốc đổi đến khi agent trả lời theo nội dung mới, và thời gian khắc phục sự cố. Một chỉ số xấu đi ngay sau lần cập nhật là tín hiệu cần quay về phiên bản trước.

8. Checklist trước khi vận hành

• Nguồn dữ liệu và chủ sở hữu đã xác nhận
• Quyền đọc ghi đã thử với nhiều vai trò
• Có phương án khi hệ thống lỗi hoặc thiếu dữ liệu
• Có log, phê duyệt và cơ chế chống thao tác trùng
• Có bộ kiểm thử hồi quy và người vận hành

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

Có cần bảo trì AI Agent ngay sau khi đưa vào vận hành không? Có. Người sở hữu, bộ kiểm thử hồi quy và cảnh báo nên sẵn sàng từ ngày đầu vận hành, vì giai đoạn đầu là lúc phát hiện nhiều lỗi nhất và nội dung cũng thay đổi nhiều.

Nên bắt đầu bảo trì AI Agent từ việc gì? Từ hai việc: gán người sở hữu cho từng nguồn dữ liệu và dựng bộ kiểm thử hồi quy từ các câu hỏi thật. Có hai thứ này thì mỗi thay đổi về sau đều kiểm soát được.

Khi nào thay đổi trong lúc bảo trì cần người duyệt? Khi sửa nội dung về giá, chính sách hoặc cam kết, khi mở thêm quyền cho agent, khi đổi mô hình hay nhà cung cấp, và khi bộ hồi quy có ca chuyển từ đạt sang không đạt. Những thay đổi này ảnh hưởng trực tiếp đến khách hoặc dữ liệu.

Bao lâu nên rà soát quyền và kho kiến thức một lần? Không có tần suất chung cho mọi doanh nghiệp. Nên rà theo nhịp thay đổi của nghiệp vụ, và rà ngay khi có sự kiện như đổi bảng giá, đổi chính sách hoặc có nhân sự nghỉ việc.

Kết luận

Ngày đưa AI Agent vào vận hành là lúc bắt đầu một chu kỳ mới chứ không phải lúc kết thúc dự án. Agent giữ được chất lượng khi mỗi nguồn dữ liệu có người sở hữu, mỗi thay đổi được kiểm thử lại và mỗi sự cố có người quyết định. Hãy lên kế hoạch bảo trì ngay từ lúc thiết kế, cùng lúc với phạm vi và tích hợp.

Trao đổi với Naventic để lên kế hoạch vận hành và bảo trì AI Agent. Đọc thêm: Dịch vụ.