Triển khai AI theo nấc là để hệ thống mới gặp một nhóm nhỏ người dùng trước, đo kỹ cách nó cư xử, rồi mới mở rộng từng bước, và lúc nào cũng giữ sẵn đường quay về bản cũ. Một lần ra mắt rủi ro được chia thành nhiều bước nhỏ, bước nào hỏng thì lùi lại mà không ảnh hưởng tới mọi người.
Người làm phần mềm đã quen cách này từ lâu. Với AI nó còn cần thiết hơn, vì hành vi của mô hình khó đoán trước hơn mã viết tay: một thay đổi nhỏ trong lời nhắc hay trong phiên bản mô hình có thể làm đổi cách trả lời ở những chỗ không ai ngờ. Bài thử trước khi phát hành dù kỹ tới đâu cũng không bao phủ được những gì người dùng thật sẽ hỏi.
Vì sao AI cần phát hành từng bước hơn phần mềm thường
Với phần mềm thường, cùng một đầu vào cho cùng một đầu ra. Kỹ sư sửa một hàm tính tiền thì kiểm hàm đó là đủ. Với mô hình AI, đổi một câu trong lời nhắc hệ thống có thể làm câu trả lời về bảo hành dài ra, cách xưng hô thay đổi, hay một chủ đề trước đây trả lời tốt bỗng trả lời kém. Ảnh hưởng lan ra theo những đường không vẽ trước được.
Người dùng thật cũng sáng tạo hơn mọi bộ bài thử. Một nhóm kỹ sư ở Đà Nẵng có thể viết vài trăm câu hỏi thử cho chatbot đặt phòng khách sạn, nhưng khách thật sẽ hỏi bằng tiếng địa phương, viết không dấu, gửi ảnh chụp màn hình, hỏi chuyện chẳng liên quan, hoặc cố tình thử cho chatbot nói bậy. Chỉ có tiếp xúc thật mới cho thấy những tình huống đó.
Vì vậy câu hỏi đúng không phải "đã kiểm đủ chưa" mà là "nếu có lỗi lọt qua, nó ảnh hưởng tới bao nhiêu người trước khi mình phát hiện và lùi lại được". Phát hành theo nấc trả lời câu hỏi đó: lỗi lọt qua chỉ chạm tới một phần nhỏ người dùng, trong một thời gian ngắn.
Ở quy mô lớn hơn, chính các phòng thí nghiệm phát triển mô hình cũng thường phát hành dần: cho một nhóm thử nghiệm hẹp trước, rồi mở cho nhà phát triển, rồi mới mở rộng ra công chúng, kèm theo việc giới hạn một số tính năng lúc đầu. Logic giống hệt: học từ thế giới thật khi tầm ảnh hưởng còn nhỏ.
Các nấc phát hành thường dùng
Chạy bóng. Mô hình mới nhận cùng đầu vào với mô hình cũ, tạo câu trả lời nhưng không gửi cho ai. Nhóm kỹ thuật so hai bên để thấy khác biệt mà không ai bị ảnh hưởng.
Dùng nội bộ. Nhân viên công ty dùng trước vài tuần. Họ hiểu sản phẩm nên phát hiện được câu trả lời sai mà khách ngoài không nhận ra.
Nhóm thử nghiệm tự nguyện. Mời một nhóm khách quen đồng ý dùng thử, biết đây là bản mới và có kênh báo lỗi riêng.
Một phần nhỏ lưu lượng. Chuyển một tỷ lệ nhỏ người dùng ngẫu nhiên sang bản mới, so chỉ số với nhóm còn dùng bản cũ.
Theo khu vực hoặc kênh. Mở trên một kênh trước, như trang web, rồi mới tới ứng dụng và tổng đài; hoặc một chi nhánh trước rồi mới tới chi nhánh khác.
Theo loại việc. Cho AI làm phần việc rủi ro thấp trước, như trả lời giờ mở cửa, rồi mới tới phần rủi ro cao hơn như đổi đơn hàng.
Chế độ gợi ý trước, tự động sau. Giai đoạn đầu AI chỉ soạn nháp cho nhân viên gửi; khi tỷ lệ nhân viên phải sửa đủ thấp mới cho gửi thẳng.
Mở rộng từng bậc. Tăng dần tỷ lệ người dùng qua vài bậc, mỗi bậc giữ đủ lâu để thấy cả ngày thường lẫn giờ cao điểm.
Giữ bản cũ chạy song song. Ngay cả khi đã chuyển hết, giữ bản cũ sẵn sàng một thời gian để quay lại ngay khi cần.
Thời gian quan sát sau khi chuyển hết. Lỗi hiếm cần lưu lượng lớn mới lộ, nên sau khi mở toàn bộ vẫn theo dõi sát thêm một khoảng.
Ghi nhật ký theo phiên bản. Mọi câu trả lời đều gắn với phiên bản đã tạo ra nó, để khi có khiếu nại biết bản nào gây ra.
Tiêu chí để đi tiếp, dừng lại hay lùi về
Viết tiêu chí trước khi bắt đầu. Quyết định trước những con số nào cho phép mở rộng, để không bị cảm xúc và áp lực tiến độ chi phối.
Tỷ lệ chuyển cho người. Bản mới khiến khách phải gặp nhân viên nhiều hơn bản cũ là dấu hiệu cần dừng.
Phản hồi tiêu cực. So với nhóm dùng bản cũ trong cùng thời gian, không so với trung bình tháng trước.
Lỗi nghiêm trọng dù chỉ một. Một lần lộ thông tin khách, một lần cam kết sai về tiền là đủ để lùi về, không cần chờ thống kê.
Chất lượng do người chấm. Chấm mẫu ngẫu nhiên của cả hai bản theo cùng bảng tiêu chí, không để người chấm biết câu nào của bản nào.
Chi phí mỗi phiên. Bản mới tốt hơn mà đắt gấp mấy lần có thể không đáng, cần quyết từ trước mức chấp nhận.
Thời gian phản hồi. Khách chờ lâu hơn hẳn thì trải nghiệm vẫn kém đi dù câu trả lời hay hơn.
Các nhóm người dùng nhỏ. Xem riêng người dùng viết không dấu, người lớn tuổi, khách nước ngoài. Trung bình tốt có thể che một nhóm bị kém đi.
Khiếu nại qua kênh khác. Theo dõi cả tổng đài, mạng xã hội, email, vì không phải ai cũng phản hồi ngay trong khung chat.
Ai có quyền quyết định. Ghi rõ ai được quyền cho mở rộng và ai được quyền lùi về. Quyền lùi về nên trao rộng hơn quyền mở rộng.
Không có dữ liệu thì không đi tiếp. Chưa đủ lượt dùng để kết luận thì giữ nguyên bậc hiện tại, đừng mở rộng vì hết thời gian dự kiến.
Đường lui phải được xây trước, không phải lúc cháy nhà
Quay về bản cũ nghe đơn giản nhưng hay vướng ở những chỗ không ngờ. Bản mới có thể đã ghi dữ liệu theo định dạng mới mà bản cũ không đọc được. Tài liệu tra cứu đã được cập nhật cho bản mới. Mô hình cũ mà nhà cung cấp đã ngừng hỗ trợ thì không còn để quay về. Những thứ này phải được nghĩ tới trước khi bắt đầu, không phải lúc đang có sự cố.
Công tắc tắt tính năng là công cụ quen thuộc của người làm phần mềm: một thiết lập cho phép bật hay tắt một tính năng ngay lập tức mà không cần phát hành lại. Với AI, nên có công tắc cho từng phần: tắt riêng khả năng gửi email của trợ lý, tắt riêng việc trả lời về giá, chuyển riêng một kênh về chế độ người trả lời. Tắt được từng phần thì người trực dám tắt sớm.
Kế hoạch xử lý sự cố nên viết sẵn bằng ngôn ngữ đơn giản: dấu hiệu nào thì tắt gì, ai được gọi, khách đã bị ảnh hưởng thì thông báo thế nào, ghi lại những gì. Một quán ăn ở Quy Nhơn khi lò nướng hỏng vẫn biết chuyển sang món chiên để phục vụ tiếp; hệ thống AI cũng cần cái "thực đơn dự phòng" như vậy.
Sau mỗi lần phải lùi về, viết một bản rà soát ngắn không đổ lỗi: chuyện gì đã xảy ra, phát hiện sau bao lâu, vì sao bài thử trước không bắt được, lần sau đo thêm gì. Mỗi lần lùi về như vậy làm cho bộ bài thử tốt lên, và lần phát hành sau an toàn hơn.
Sai lầm hay gặp khi đưa AI vào dùng thật
Ra mắt một lần cho tất cả. Vì muốn có sự kiện ra mắt hoành tráng, bỏ qua mọi nấc thử nghiệm.
Cập nhật mô hình mà không coi là phát hành. Nhà cung cấp ra phiên bản mới, đội kỹ thuật đổi sang luôn vì nghĩ chỉ là nâng cấp, trong khi hành vi có thể khác hẳn.
Sửa lời nhắc trực tiếp trên bản thật. Một câu sửa vội lúc tối muộn không qua nấc nào, ảnh hưởng toàn bộ người dùng ngay lập tức.
Không có nhóm đối chứng. Chuyển hết sang bản mới rồi so với tháng trước, không tách được ảnh hưởng của bản mới với ảnh hưởng của mùa vụ.
Đo quá ngắn. Mở rộng sau một buổi sáng thử nghiệm, chưa gặp giờ cao điểm hay cuối tuần.
Chỉ nhìn trung bình. Chỉ số chung đẹp nhưng một nhóm khách nhỏ bị trả lời sai hàng loạt.
Bỏ bản cũ quá sớm. Tắt hạ tầng của bản cũ để tiết kiệm, rồi khi cần quay về thì phải dựng lại từ đầu.
Không thông báo cho nhân viên tuyến đầu. Nhân viên tổng đài không biết chatbot vừa đổi, nên khi khách phàn nàn họ không nhận ra đó là lỗi mới.
Áp lực tiến độ thắng tiêu chí. Tiêu chí chưa đạt nhưng vẫn mở rộng vì đã hứa ngày ra mắt với cấp trên.
Không ai được quyền lùi. Người phát hiện lỗi phải chờ họp mới được quyết định quay về bản cũ.
Rà soát để tìm người chịu lỗi. Lần sau người ta giấu sự cố thay vì báo sớm.
Câu hỏi thường gặp
Chạy bóng mô hình AI là gì?
Là cho mô hình mới xử lý cùng đầu vào với mô hình đang dùng nhưng không gửi kết quả cho người dùng. Nhóm kỹ thuật so sánh hai bên để thấy khác biệt trước khi để mô hình mới phục vụ thật.
Nên mở cho bao nhiêu phần trăm người dùng ở bước đầu?
Không có con số chung. Nguyên tắc là đủ nhỏ để lỗi không gây hại lớn, nhưng đủ lớn để có số liệu đáng tin trong vài ngày. Hệ thống ít người dùng thì có thể cần dùng nội bộ lâu hơn thay vì chia tỷ lệ.
Nhà cung cấp cập nhật mô hình thì doanh nghiệp làm gì?
Coi đó như một lần phát hành mới: chạy lại bộ câu hỏi thử cố định, chạy bóng nếu được, rồi chuyển dần. Nếu nhà cung cấp cho phép, nên cố định phiên bản đang dùng để không bị đổi bất ngờ.
Công tắc tắt tính năng giúp gì cho an toàn AI?
Nó cho phép tắt ngay một phần hành vi của hệ thống mà không cần phát hành lại. Có công tắc chia nhỏ, người trực có thể phản ứng trong vài phút thay vì chờ cả nhóm kỹ thuật.
Phát hành từng bước có làm chậm việc đưa AI vào dùng không?
Có chậm hơn một chút ở đầu, nhưng thường nhanh hơn tính trên cả quá trình, vì tránh được những lần phải gỡ toàn bộ, xin lỗi khách và làm lại từ đầu.
