88% dự án thử nghiệm tính khả thi AI không đi đến giai đoạn vận hành thực tế, theo nghiên cứu chung của IDC và Lenovo được dẫn trong bài phân tích của The New Stack. Ba nguyên nhân được nêu là mục tiêu chưa rõ, dữ liệu chưa sẵn sàng và thiếu chuyên môn nội bộ về AI tác tử. Muốn thu hẹp khoảng cách này, doanh nghiệp phải kiểm thử bằng dữ liệu thật, giới hạn quyền truy cập, giám sát từng bước và phân công trách nhiệm xử lý sự cố.
Phần lớn dự án AI không thất bại ở màn trình diễn. Chúng thất bại khi phải xử lý dữ liệu thật, quyền truy cập thật và những tình huống không xuất hiện trong kịch bản thử nghiệm. Một bản trình diễn có thể chạy trơn tru với dữ liệu đã được làm sạch, còn hệ thống thật phải đối mặt với dữ liệu thiếu, yêu cầu mơ hồ, lỗi kết nối và người dùng hành xử ngoài dự tính.
Khoảng cách giữa bản trình diễn và hệ thống thật
Bản trình diễn hoạt động trong môi trường được kiểm soát, còn hệ thống thật phải chịu dữ liệu không đồng nhất, lỗi tích hợp và nhiều trường hợp ngoại lệ. Vì vậy, chất lượng câu trả lời chỉ là một phần của đánh giá. Khả năng truy vết, phát hiện bất thường và dừng hệ thống mới quyết định tác tử có thể vận hành lâu dài hay không.
Serhii Semenchenko, Giám đốc công nghệ của Dedicatted, mô tả bản trình diễn là một môi trường sạch với dữ liệu được chuẩn bị trước. Đầu vào và đầu ra đều đã xác định, còn các trường hợp ngoại lệ gần như bị loại bỏ. Môi trường vận hành không có sự thuận lợi đó.
Khoảng cách cũng xuất hiện giữa đội xây dựng và đội vận hành. Đơn vị thiết kế, triển khai tác tử có thể không phải đơn vị trực tiếp chạy hệ thống trong quy trình kinh doanh. Khi đội vận hành chỉ quen với bản trình diễn và không có hỗ trợ bên ngoài, một sai lệch nhỏ của tác tử có thể lan qua nhiều bước rồi gây hậu quả lớn.
Doanh nghiệp không nên chỉ đánh giá tác tử qua câu trả lời đẹp mắt. Khả năng ghi nhật ký, theo dõi luồng xử lý, phát hiện bất thường và dừng đúng lúc mới quyết định hệ thống có thể hoạt động lâu dài hay không. Câu hỏi tác tử được phép làm gì cũng quan trọng không kém khả năng của mô hình, như cuộc thảo luận về việc AI nên được cấp bao nhiêu quyền trong hệ thống đã chỉ ra.
Mỗi tác tử cần được quản lý như một dịch vụ riêng
Mỗi tác tử cần có giới hạn thời gian, phạm vi quyền và danh sách công cụ riêng. Hệ thống phải ghi lại kết quả của từng bước và xác định trước tác tử nên tiếp tục, thử lại hay dừng khi gặp sự kiện bất thường. Cách quản lý này hạn chế lỗi lan rộng và tạo dữ liệu cần thiết để điều tra sự cố.
Semenchenko cho rằng mỗi tác tử phải có thời gian chờ tối đa. Mỗi bước tạo ra kết quả cũng phải được ghi lại để có thể truy vết. Khi gặp sự kiện bất thường, hệ thống cần tự đánh giá nên tiếp tục, thử lại hay lên lịch xử lý sau.
Cách tổ chức này gần với kiến trúc vi dịch vụ. Mỗi tác tử có một tập quyền riêng và dùng khóa tồn tại trong thời gian ngắn để truy cập công cụ, dịch vụ hoặc cơ sở dữ liệu cần thiết. Không nên cấp khóa dài hạn với phạm vi rộng cho toàn bộ hệ thống.
Giới hạn công cụ mà từng tác tử được gọi giúp giảm nguy cơ rò rỉ dữ liệu, sử dụng sai mục đích và tấn công chèn chỉ dẫn. Quan điểm này phù hợp với nguyên tắc phân quyền dữ liệu và mô hình trong hệ thống AI: quyền truy cập phải bám theo nhiệm vụ thay vì được cấp đồng loạt.
Điều phối nhiều tác tử cần quy tắc bàn giao rõ ràng
Hệ thống nhiều tác tử cần xác định tác tử nào nhận việc, trạng thái nào được giữ lại và cách xử lý khi một bước thất bại. Tác tử tổng hợp không được tự tạo phần thông tin còn thiếu. Nó phải thử lại theo quy tắc, chuyển lỗi hoặc đánh dấu kết quả chưa hoàn thành để tránh biến lỗi kỹ thuật thành thông tin sai.
Trong mô hình nhiều tác tử, một bộ định tuyến có thể nhận dữ liệu từ người dùng, hệ thống và nền tảng rồi quyết định bước tiếp theo. Công việc sau đó được chuyển tới tác tử chuyên trách tài liệu, phân tích, hình ảnh, âm thanh hoặc phát trực tiếp. Mỗi tác tử chỉ dùng những công cụ phù hợp với nhiệm vụ của mình.
Quy tắc xử lý khi một bước thất bại
Một tác tử cuối cùng tổng hợp kết quả từ các công cụ và tác tử trước đó. Nếu một phần bị lỗi, nó không được tự nghĩ ra mảnh thông tin còn thiếu. Hệ thống phải thử lại hoặc đánh dấu thất bại. Quy trình cần xác định rõ ai nhận công việc, trạng thái nào được giữ lại sau mỗi bước và điều gì xảy ra nếu một bước dừng giữa chừng.
Bộ nhớ của tác tử cũng có thể bị làm sai lệch. Semenchenko gọi hiện tượng này là “đầu độc bộ nhớ”. Biện pháp bảo vệ là kiểm tra tài liệu và dữ liệu theo quy tắc xác định trước, đồng thời truy ngược điểm không nhất quán về bản ghi, cơ sở dữ liệu hoặc dữ liệu trùng lặp.
Những yêu cầu này cho thấy lớp hạ tầng AI và cơ chế vận hành không phải phần bổ sung sau cùng. Chúng phải được thiết kế cùng tác tử ngay từ đầu.
Dữ liệu thật làm lộ những trường hợp khó dự đoán
Dữ liệu thật không chỉ làm lộ lỗi đầu vào. Nó còn cho thấy đầu ra có thể chưa dùng được nếu cách trình bày không phù hợp với quy trình làm việc của con người. Kiểm thử vận hành vì thế phải bao gồm quy ước nội bộ, cách trình bày và yêu cầu của người trực tiếp sử dụng kết quả, thay vì chỉ kiểm tra độ chính xác.
Dedicatted từng xây dựng hệ thống nhiều tác tử cho CASSEN Testing Laboratories, một phòng thí nghiệm hóa học, môi trường và sức khỏe nghề nghiệp tại Canada. Trước đó, việc kiểm tra thủ công theo quy định và thời gian xử lý dài khiến báo cáo mất nhiều ngày mới hoàn thành.
Dự án có đầu vào và đầu ra rõ ràng, nhưng cách con người trình bày báo cáo lại tạo ra trường hợp ngoại lệ. Các nhà hóa học có quan điểm riêng về cách thể hiện báo cáo và các hợp chất trong quá trình điều tra mẫu lỗi. Khi bước vào vận hành, phong cách báo cáo nội bộ còn quan trọng hơn cách trình bày chung của ngành.
Đội dự án phải điều chỉnh luồng xử lý và tác tử tổng hợp báo cáo. Sau thay đổi, báo cáo cuối cùng có hình thức giống tài liệu do các nhà hóa học tự chuẩn bị. Trường hợp này cho thấy đầu ra vẫn có thể chưa dùng được nếu cách trình bày không phù hợp với quy trình làm việc của người nhận.
Di chuyển nền tảng phải kiểm tra lại toàn bộ hệ thống
Di chuyển hệ thống AI giữa các nền tảng đám mây đòi hỏi kiểm tra lại quyền truy cập, công cụ, mô hình và từng luồng người dùng. Đội dự án không thể giả định cấu hình cũ sẽ hoạt động nguyên vẹn trên nền tảng mới. Việc xác thực phải đo cả tỷ lệ thành công, độ trễ và chi phí xử lý.
Zivian Health, một nền tảng tuân thủ tại Mỹ dành cho các tổ chức quản lý lực lượng điều dưỡng thực hành nâng cao và trợ lý bác sĩ ở nhiều bang, đã chuyển từ AWS sang Azure. Hai nền tảng sử dụng hệ thống truy cập khác nhau, nên mọi quyền hạn phải được lập bản đồ, điều chỉnh và xác thực trước khi di chuyển.
Hệ thống cũng cần công cụ không phụ thuộc vào một nhà cung cấp đám mây để theo dõi toàn bộ hoạt động. Một số mô hình có thể không cùng hiện diện trên cả hai nền tảng, khiến việc chuyển đổi không đơn thuần là sao chép cấu hình.
Semenchenko đề xuất một bộ dữ liệu kiểm thử bao phủ mọi trường hợp và yêu cầu mà nền tảng phải xử lý. Sau khi di chuyển, đội dự án cần xác thực từng tác tử, trường hợp sử dụng và luồng người dùng. Các chỉ số cuối cùng phải gồm tỷ lệ thành công, độ trễ và chi phí token.
Khả năng tạo giá trị sau khi vượt qua các bước này đã được ghi nhận. Theo khảo sát AI của PwC, khoảng hai phần ba, tương đương 66%, tác tử AI tạo ra giá trị và cải thiện năng suất.
Sự cố lúc 3 giờ sáng mới là phép thử thật
Khả năng vận hành được kiểm chứng khi tác tử lặp lại một hành động, tiêu tốn tài nguyên hoặc vượt khỏi phạm vi cho phép mà không có người theo dõi trực tiếp. Hệ thống cần cơ chế ngắt, cảnh báo và quy trình khôi phục. Trách nhiệm phản ứng cũng phải được giao rõ cho đối tác hoặc đội nội bộ trước khi triển khai.
Một tác tử có thể quyết định kết quả từ công cụ chưa đủ rồi gọi lại 2, 3 hoặc 5 lần với hy vọng có dữ liệu mới. Nếu không có giới hạn, hành vi này tiếp tục tiêu tốn tài nguyên hoặc đẩy hệ thống ra ngoài phạm vi được phép.
Cơ chế ngắt phải phát hiện hành vi bất thường và chuyển lỗi tới hệ thống giám sát. Người nhận cảnh báo có thể là đối tác vận hành AI hoặc đội nội bộ của khách hàng, tùy theo hợp đồng dịch vụ.
Ai nhận cảnh báo và khôi phục hệ thống?
Nếu đối tác chịu trách nhiệm vận hành, họ có thể theo dõi bảng điều khiển, nhận cảnh báo và phản ứng ngay trong đêm. Nếu doanh nghiệp tự vận hành, đội nội bộ cần nhận thông báo lỗi và dùng quy trình xử lý sự cố do nhà phát triển bàn giao. Không thể đợi đến sáng nếu tác tử đang thực hiện hành động ngoài phạm vi.
Denys Yermakov, Giám đốc điều hành Dedicatted, lưu ý rằng lỗi tác tử đôi khi không gây ra sự cố dễ nhìn thấy ngay. Doanh nghiệp cần nhiều lớp giám sát, kiểm thử hồi quy, các chỉ dẫn khác nhau và kiểm tra nhiều hành vi. Cách phát hành bản sửa lỗi quan trọng ngang với khả năng phát hiện lỗi, đặc biệt khi sự cố đến từ hạ tầng hoặc một lần triển khai sai.
Chọn đối tác bằng dữ liệu và quy trình thật
Một đối tác triển khai AI cần chứng minh năng lực bằng dữ liệu, quy trình và khó khăn thật của doanh nghiệp. Bản trình diễn dựng sẵn không cho thấy hệ thống sẽ xử lý các ngoại lệ cụ thể ra sao. Trước khi hợp tác, hai bên cũng phải thống nhất phạm vi, quyền sở hữu mã nguồn, trách nhiệm bảo trì và kế hoạch bàn giao.
Yermakov đề xuất bắt đầu bằng một phần nhỏ của thử nghiệm tính khả thi hoặc môi trường trình diễn. Tuy nhiên, phần thử nghiệm đó phải dùng dữ liệu, quy trình và khó khăn thật của doanh nghiệp. Một kịch bản dựng sẵn không liên quan đến bài toán của khách hàng chỉ cho thấy khả năng bán lại dịch vụ, không chứng minh năng lực triển khai.
Đối tác phù hợp thường đặt câu hỏi chi tiết về lớp dữ liệu và nhận ra vấn đề ngay trong giai đoạn thử nghiệm. Doanh nghiệp cũng phải làm rõ phạm vi dự án, quyền sở hữu mã nguồn, quyền sở hữu nền tảng và trách nhiệm bảo trì sau bàn giao.
Chất lượng dữ liệu là một rào cản phổ biến. Theo báo cáo khảo sát của Modern Data Company, 75,9% lãnh đạo và chuyên gia dữ liệu doanh nghiệp tại 66 quốc gia cho rằng chất lượng và độ tin cậy của dữ liệu cản trở hệ thống AI đi vào vận hành thực tế.
Dữ liệu nhạy cảm không được rời khỏi vùng bảo vệ
Dữ liệu nhạy cảm phải được bảo vệ tại đầu vào, đầu ra, nhật ký và các công cụ bên ngoài. Bảo vệ cơ sở dữ liệu chính là chưa đủ nếu thông tin nhận dạng vẫn xuất hiện trong lịch sử gọi công cụ hoặc nền tảng quan sát. Kiến trúc cần loại bỏ dữ liệu nhạy cảm trước khi chuyển bản ghi sang hệ thống giám sát.
Yermakov cho rằng dữ liệu của doanh nghiệp phải ở trong vùng bảo mật hiện có. Đây là thách thức với các tổ chức có khối lượng lớn dữ liệu được lưu trữ tại chỗ, bởi nhà cung cấp AI có thể dùng dữ liệu đó để huấn luyện mô hình công khai nếu kiến trúc và điều khoản không được kiểm soát.
Trong một số dự án y tế, Dedicatted phải xử lý thông tin nhận dạng cá nhân liên quan đến sức khỏe. Dữ liệu này cần thiết để tác tử tạo hoặc xử lý kết quả nhưng không được lưu lại. Đội dự án đã bổ sung một lớp loại bỏ toàn bộ thông tin nhận dạng khỏi đầu ra trước khi dữ liệu truy vết được chuyển tới nền tảng quan sát. Vì vậy, nhật ký và hệ thống giám sát không chứa thông tin nhận dạng cá nhân.
Nguyên tắc này phải được kiểm tra ở cả đầu vào, đầu ra, nhật ký và công cụ bên ngoài. Chỉ bảo vệ cơ sở dữ liệu chính là chưa đủ nếu dữ liệu nhạy cảm vẫn xuất hiện trong lịch sử gọi công cụ hoặc bản ghi giám sát.
Doanh nghiệp vẫn phải xây năng lực nội bộ
Đối tác có thể cung cấp kinh nghiệm kiến trúc và vận hành, nhưng không thể thay thế hiểu biết nội bộ về quy trình kinh doanh. Chuyên gia nghiệp vụ phải tham gia từ đầu, tiếp nhận kiến thức trong suốt dự án và chuẩn bị khả năng xử lý sự cố. Doanh nghiệp vẫn cần sở hữu các quyết định liên quan đến quy trình và rủi ro.
AI tác tử còn mới với nhiều hệ thống doanh nghiệp. Các tổ chức vẫn đang trả lời những câu hỏi cơ bản về kiến trúc nền tảng, lợi ích, cách thiết lập và chi phí sử dụng. Đối tác đã triển khai hệ thống thực tế có thể rút ngắn giai đoạn thử sai, nhưng không thể thay thế hiểu biết nội bộ về quy trình kinh doanh.
Yermakov cảnh báo rằng thuê ngoài toàn bộ sẽ không hiệu quả vì đối tác không thể hiểu doanh nghiệp đến mức chi tiết như đội ngũ bên trong. Chuyên gia nghiệp vụ và đối tác cần tham gia từ đầu để việc chuyển giao kiến thức diễn ra trong suốt dự án.
Cách phân chia phù hợp là đội nội bộ sở hữu và bảo vệ quy trình kinh doanh, còn đối tác thiết kế kiến trúc và vận hành lõi hệ thống. Doanh nghiệp cũng cần đào tạo người có thể tiếp nhận xử lý sự cố, bảo trì và những yêu cầu thay đổi trong tương lai. Doanh nghiệp cũng cần xác định rõ vai trò của kỹ sư trong thời AI để phân công trách nhiệm vận hành và bảo trì hệ thống.
Nội dung cần kiểm tra để thử nghiệm AI đi vào vận hành
Một thử nghiệm AI chỉ sẵn sàng vận hành khi doanh nghiệp đã xác định mục tiêu, kiểm thử bằng dữ liệu thật, giới hạn quyền của từng tác tử và quan sát được toàn bộ luồng xử lý. Đội dự án cũng phải có cơ chế ngắt, quy trình khôi phục, người chịu trách nhiệm và kế hoạch chuyển giao kiến thức trước khi mở rộng.
Theo nghiên cứu chung của IDC và Lenovo, tỷ lệ 88% không nói rằng AI không thể tạo giá trị. Nó cho thấy một bản trình diễn thành công mới chỉ xác nhận hệ thống hoạt động trong điều kiện đã chuẩn bị. Trước khi đưa vào quy trình thật, doanh nghiệp phải xác định mục tiêu, chuẩn bị dữ liệu, giới hạn quyền của từng tác tử, ghi lại mọi bước, thiết lập cơ chế ngắt và phân công người xử lý sự cố.
- Xác định mục tiêu và phạm vi của thử nghiệm.
- Dùng dữ liệu và quy trình thật ngay từ giai đoạn kiểm chứng.
- Giới hạn quyền, công cụ và thời gian chờ của từng tác tử.
- Ghi lại từng bước để truy vết và phát hiện bất thường.
- Kiểm thử trường hợp ngoại lệ, lỗi bàn giao và thay đổi nền tảng.
- Bảo vệ dữ liệu nhạy cảm trong đầu vào, đầu ra và nhật ký.
- Phân công người nhận cảnh báo, dừng và khôi phục hệ thống.
- Thống nhất quyền sở hữu và kế hoạch chuyển giao kiến thức.
Hãy bắt đầu bằng một quy trình nhỏ nhưng dùng dữ liệu thật, rồi chỉ mở rộng khi đội ngũ có thể quan sát, dừng và khôi phục từng tác tử một cách an toàn.
