Đưa agent AI vào vận hành: bốn điều phải có trước ngày ra mắt
Agent chạy tốt trong bản demo chưa có nghĩa là sẵn sàng vận hành. Bốn điều cần có trước khi ra mắt, và cách thực hiện trên Databricks.
Dựng một agent AI trả lời được câu hỏi trong bản demo ngày nay chỉ mất vài ngày. Đưa agent đó vào vận hành, nơi người dùng thật đặt câu hỏi thật và agent gọi công cụ tác động lên dữ liệu thật, là việc khác hẳn. Phần lớn dự án dừng ở khoảng giữa hai giai đoạn này, không phải vì mô hình kém, mà vì không ai trả lời được ba câu hỏi: agent có đang trả lời đúng không, khi sai thì sai ở đâu, và ai chịu trách nhiệm với hành động agent đã thực hiện.
Bài viết này điểm lại bốn điều cần có trước ngày ra mắt, dựa trên cách Databricks tổ chức việc đánh giá và vận hành agent.
1. Bộ đánh giá trước khi ra mắt
Cách kiểm thử phần mềm thông thường không áp dụng được cho agent. Cùng một câu hỏi có thể cho ra câu trả lời khác nhau giữa các lần chạy, và agent tự quyết định thứ tự gọi công cụ thay vì đi theo một luồng mã cố định. Không thể viết một phép so sánh bằng nhau rồi chờ kết quả đúng hay sai.
Thay vào đó, đánh giá agent dựa trên ba thành phần:
- Một bộ dữ liệu đánh giá phản ánh đúng cách người dùng sẽ hỏi, có chủ đích đưa vào các trường hợp khó và hiếm, và có câu trả lời tham chiếu hoặc tiêu chí cho từng câu.
- Các bộ chấm điểm: một số dựng sẵn cho các tiêu chí phổ biến như độ chính xác, độ an toàn, mức bám sát tài liệu truy xuất và việc gọi công cụ đúng cách; một số viết riêng cho quy định nghiệp vụ của doanh nghiệp, diễn đạt bằng ngôn ngữ tự nhiên hoặc bằng mã.
- Một ngưỡng chất lượng: phiên bản agent nào không đạt ngưỡng trên bộ đánh giá thì không được triển khai.
Trên Databricks, MLflow đảm nhận việc này. Mỗi lần đánh giá là một lần chạy được lưu lại, nên có thể so sánh phiên bản mới với phiên bản cũ trước khi quyết định thay thế. Mỗi kết quả chấm điểm đi kèm lý do bằng ngôn ngữ tự nhiên, giúp đội ngũ hiểu vì sao một câu trả lời bị đánh trượt.
2. Truy vết từng bước của agent
Khi agent trả lời sai, câu hỏi đầu tiên là sai ở bước nào: tài liệu truy xuất không liên quan, agent chọn nhầm công cụ, truyền sai tham số, hay mô hình suy luận sai từ dữ liệu đúng. Không có truy vết thì không trả lời được câu hỏi này.
MLflow Tracing ghi lại từng bước của mỗi lượt xử lý: lời gọi mô hình, lượt truy xuất, lời gọi công cụ, kèm dữ liệu vào ra và thời gian của từng bước. Dữ liệu truy vết theo chuẩn OpenTelemetry, nên có thể chuyển sang hệ thống giám sát doanh nghiệp đang dùng. Một số tiêu chí đánh giá, chẳng hạn mức đầy đủ của tài liệu truy xuất, chỉ chấm được khi có truy vết đầy đủ.
Truy vết cũng là bằng chứng. Khi cần giải trình một câu trả lời hay một hành động của agent, doanh nghiệp có bản ghi chi tiết thay vì phải dựng lại từ trí nhớ.
3. Giám sát liên tục khi vận hành
Bộ đánh giá trước khi ra mắt có giới hạn: dữ liệu tĩnh dần lỗi thời, và người dùng thật luôn hỏi những câu mà không ai lường trước. Vì vậy các bộ chấm điểm dùng khi phát triển cần được chạy tiếp trên lưu lượng thật sau khi ra mắt.
Không cần chấm mọi lượt bằng mọi tiêu chí. Nguyên tắc là rủi ro bỏ sót càng cao thì tỷ lệ lấy mẫu càng cao: tiêu chí an toàn và bảo mật chạy trên mọi lượt, còn các tiêu chí dùng mô hình ngôn ngữ để chấm, vốn tốn chi phí hơn, có thể chạy trên một phần lưu lượng theo tỷ lệ lấy mẫu đặt riêng cho từng tiêu chí. Khi điểm chất lượng vượt ngưỡng cảnh báo, đội ngũ được báo trước khi người dùng phàn nàn.
Các trường hợp lỗi tìm thấy khi vận hành được đưa ngược vào bộ dữ liệu đánh giá. Nhờ vòng lặp này, bộ đánh giá phản ánh ngày càng sát cách agent thực sự được sử dụng, và mỗi phiên bản mới phải vượt qua cả những lỗi đã từng xảy ra.
4. Phân quyền cho agent và khâu phê duyệt của con người
Agent chỉ nên truy cập đúng những dữ liệu và công cụ cần cho nhiệm vụ. Trên Databricks, agent triển khai dưới dạng ứng dụng có định danh riêng (service principal), và định danh này quyết định agent được đọc bảng nào, gọi công cụ nào. Công cụ có thể là các hàm được quản trị trong Unity Catalog, nên quyền gọi công cụ cũng được cấp và thu hồi như quyền truy cập dữ liệu.
Với những hành động có tác động lớn, như phê duyệt giao dịch, thay đổi dữ liệu khách hàng hay gửi thông báo ra bên ngoài, agent nên đề xuất còn con người quyết định. Đây không chỉ là thực hành tốt. Điểm d khoản 1 Điều 14 Luật Trí tuệ nhân tạo 134/2025/QH15 yêu cầu nhà cung cấp hệ thống AI rủi ro cao thiết kế để bảo đảm khả năng giám sát và can thiệp của con người. Với ngân hàng, như chúng tôi đã phân tích trong bài Quyết định 33/2026 nói gì với ngân hàng, việc có hay không có người phê duyệt còn quyết định hệ thống có thuộc danh mục rủi ro cao hay không.
Khâu phê duyệt chỉ có giá trị khi được ghi lại: ai phê duyệt, vào lúc nào, dựa trên đề xuất nào của agent. Truy vết ở mục 2 và nhật ký phê duyệt kết hợp lại tạo thành hồ sơ giải trình đầy đủ cho từng quyết định.
Sancire làm gì trong việc này
Gói Đưa AI và agent vào vận hành của Sancire kéo dài 8 đến 12 tuần, giá từ 50.000 USD. Kết quả là một agent vận hành thật, có bộ đánh giá, truy vết, rào chắn và khâu phê duyệt của con người, cùng quy trình giám sát sau ra mắt. Nếu doanh nghiệp đang có một agent dừng ở giai đoạn demo, buổi khảo sát 90 phút là điểm bắt đầu phù hợp.
Nguồn: Luật Trí tuệ nhân tạo 134/2025/QH15, Điều 14. Tài liệu Databricks về đánh giá và giám sát ứng dụng GenAI với MLflow, tra cứu ngày 28/9/2026, và về giám sát trong môi trường vận hành, tra cứu ngày 16/10/2026. Tên và trạng thái tính năng thay đổi nhanh; cần đối chiếu tài liệu hiện hành trước khi thiết kế.