Xây dựng mô hình AI theo Agile: Khi “Done” không còn là xong việc, và “User” không chỉ là người dùng
Nếu quy trình tạo ra dữ liệu còn chưa ổn định (ví dụ: quy trình mới, trường dữ liệu mới, hệ phân loại còn chưa thống nhất), hãy ổn định quy trình trước bằng tự động hóa hoặc các quy tắc rõ ràng. Sau đó, mới đưa vào một mô hình AI vào làm thử nghiệm. Nếu không, bạn chỉ đang dạy mô hình AI học lại sự hỗn loạn của ngày hôm qua - và gọi đó là “học”.
Khi bắt đầu áp dụng Agile vào các dự án xây dựng mô hình AI, tôi từng nghĩ rằng bộ “công thức” quen thuộc của mình như chia nhỏ công việc, chu kỳ ngắn, demo thường xuyên - có thể tiếp tục sử dụng hiệu quả. Nhưng thực tế không phải vậy.
Chúng tôi vẫn bàn giao được các phần việc theo từng bước, nhưng nhiều khi nhìn thì có vẻ tiến triển tốt, trong khi thực chất lại đang hiểu sai vấn đề.
Trong lĩnh vực của tôi (các hệ sinh thái Salesforce trong ngành y tế và ngân hàng) - sự chênh lệch này thể hiện rất rõ: các mô hình vẫn“chạy tốt” trong buổi sprint review, lại gây ra rắc rối ở những bước sau, phát sinh vấn đề tuân thủ, hoặc âm thầm tối ưu theo những hành vi không mong muốn.
Sau nhiều dự án, tôi dần nhận ra rằng Agile vẫn phù hợp với AI - nhưng chỉ khi bạn định nghĩa lại hai khái niệm nền tảng sau ngay từ đầu:
- “Done” không đơn thuần là hoàn thành một mô hình hoạt động được. Nó phải là một mô hình đi kèm bằng chứng cho thấy chúng ta đang làm điều đúng đắn.
- “User” không chỉ là người dùng cuối. Nó còn bao gồm dữ liệu, người người kiểm duyệt và các cơ chế kiểm soát - những yếu tố sẽ tiếp tục “sống cùng” mô hình sau khi nó được triển khai.
Tiếp theo, tôi sẽ trình bày những cách làm để tạo nên sự khác biệt, những thời điểm khiến tôi phải thay đổi quan điểm, và một khung thực hành thực tế mà bạn có thể áp dụng cho lần triển khai AI tiếp theo.
1. Tái định nghĩa “Done”: Từ đầu ra sang bằng chứng về kết quả
Bước ngoặt trong suy nghĩ của tôi đến từ một buổi demo sprint, khi tính năng AI của chúng tôi giúp giảm đáng kể thời gian tạo Opportunity trên Salesforce trong lĩnh vực ngân hàng. Trên lý thuyết, đây rõ ràng là một kết quả tích cực. Tuy nhiên, chỉ một tuần sau, bộ phận tuân thủ phát hiện ra những trường hợp ngoại lệ tinh vi mà mô hình đã “học” được từ các lối tắt trước đây trong hệ thống CRM. Chúng tôi đã tối ưu tốc độ, nhưng phải đánh đổi bằng khả năng kiểm soát và quản trị. Nói cách khác, “done” trong sprint không đồng nghĩa với “done” trong kinh doanh.
Điều thực sự tạo ra khác biệt là khi chúng tôi bổ sung “bằng chứng về kết quả đạt được” vào Definition of Done (DoD):
- Mỗi user story cần đi kèm với một cặp chỉ số là tính hiệu quả và tính kiểm soát (ví dụ, thời gian tiết kiệm luôn đi kèm với tỷ lệ tuân thủ chính sách).
- Áp dụng việc kiểm tra Champion-Challenger trong tiêu chí nghiệm thu: mô hình mới phải vượt qua mức chuẩn so sánh, đồng thời vẫn đảm bảo các chỉ số kiểm soát trên tập dữ liệu kiểm chứng độc lập.
- Rà soát các tình huống phản thực tế: trước khi đóng một story, chúng tôi tự hỏi nhau, “Mô hình có thể đưa ra khuyến nghị sai nhưng rất tự tin ở đâu? Và mình sẽ phát hiện điều đó bằng cách nào?”
Những thay đổi này không làm chậm tiến độ - mà giúp tránh việc phải sửa sai tốn kém về sau. Đồng thời, nó cũng thay đổi hoàn toàn cách chúng tôi tổ chức demo sprint: thay vì trình bày theo cách “mô hình làm được gì”, chúng tôi tập trung vào việc “chúng tôi đã học được gì, và bằng cách nào để biết rằng mình không học sai”.
2. Mở rộng khái niệm “user”: Bao gồm dữ liệu, người kiểm duyệt và cơ chế kiểm soát
Trong các dự án tích hợp y tế (Epic/Genesys ↔ Salesforce Health Cloud), chúng tôi sớm nhận ra rằng những người kiểm tra đầu ra của mô hình, như điều phối viên chăm sóc, quản lý vận hành, bộ phận bảo mật và tuân thủ - quan trọng không kém người dùng cuối.
Nếu họ không có đủ khả năng quan sát, hoặc không có một cơ chế can thiệp nhanh gọn, đội ngũ sẽ âm thầm xây dựng các quy trình thủ công bên ngoài hệ thống. Đó chính là cách các “quy trình ngầm” xuất hiện.
Từ đó, chúng tôi đúc kết một số nguyên tắc làm việc sau:
- Xem người quản lý dữ liệu như những người dùng chính. Cung cấp cho họ các công cụ kiểm tra linh hoạt, thông tin về nguồn gốc dữ liệu và các tín hiệu cảnh báo độ lệch trong môi trường họ làm việc (thường là CRM hoặc các bảng SPM).
- Xem người kiểm duyệt là thành phần cốt lõi. Nếu những người tham gia vào quy trình không thể đưa ra phản hồi trực tiếp ngay trong quy trình làm việc, chất lượng mô hình sẽ giảm dần mà không ai kịp nhận ra.
- Xem các cơ chế kiểm soát (bảo mật/tuân thủ) như những tính năng của sản phẩm, không phải các buổi kiểm duyệt mang tính chốt chặn theo giai đoạn. Chúng tôi triển khai sớm các yếu tố tuân thủ ở quy mô nhỏ - như gợi ý chính sách, sự kiện kiểm toán và chế độ xem lấy mẫu - để người kiểm duyệt có thể theo dõi và định hình ranh giới của mô hình.
Khi áp dụng cách tiếp cận này, mức độ sử dụng mô hình tăng lên rõ rệt, và mô hình cũng học nhanh hơn vì phản hồi được ghi nhận ngay trong luồng công việc, thay vì nằm rải rác ở các bảng tính riêng lẻ.
3. Chia nhỏ công việc theo quyết định, không phải theo giao diện
Trong một dự án Salesforce, phần công việc đầu tiên của chúng tôi tập trung vào giao diện: các trường tự động điền, những giá trị mặc định thông minh, rồi sau đó mới đến bảng đề xuất. Dù tốc độ triển khai có vẻ rất tốt nhưng việc học hỏi thì không. Mô hình không được đặt vào đúng áp lực ra quyết định mà chúng tôi thực sự quan tâm (ví dụ: lead nào cần được ưu tiên ngay; case nào cần được chuyển cấp xử lý).
Sau đó, chúng tôi đã thay đổi cách chia nhỏ phạm vi bằng “một quyết định, từ đầu đến cuối”:
- Xác định rõ quyết định (ví dụ: “Opportunity nào cần được liên hệ ngay trong ngày?”).
- Triển khai một mô hình rất nhỏ (hoặc thậm chí chỉ là một mô hình thử nghiệm dựa trên các quy tắc), kèm theo giải thích rõ ràng, nút override một chạm, và cơ chế thu thập phản hồi.
- Đánh giá chất lượng quyết định so với đường cơ sở (baseline), thay vì chỉ dựa trên tốc độ thao tác.
Cách chia này cho thấy sự đánh đổi thật sự (độ chính xác so với độ bao phủ, thông lượng so với tính công bằng) ngay từ rất sớm, và mang lại những cuộc thảo luận đúng trọng tâm trong các buổi sprint review.
4. Quản lý backlog: Tách riêng mô hình, dữ liệu và kiểm soát, nhưng demo như một câu chuyện thống nhất
Trong Agile truyền thống, các user story (yêu cầu) được trình bày theo dạng “với tư cách là người dùng, tôi muốn…” thường tích hợp việc huấn luyện mô hình, xử lý dữ liệu và tăng cường kiểm soát vào chung một hạng mục công việc khổng lồ. Chúng tôi tách các công việc này thành ba luồng riêng biệt, mỗi luồng có nhịp triển khai riêng, nhưng luôn được demo cùng nhau:
- Luồng mô hình: các tính năng mới, đường cong chi phí, kết quả so sánh với mô hình đối chứng, các tín hiệu sai lệch.
- Luồng dữ liệu: tình trạng pipeline (quy trình xử lý dữ liệu), ghi chú về nguồn gốc dữ liệu, các trường hợp ngoại lệ đã được gán nhãn trong sprint.
- Luồng kiểm soát: các sự kiện kiểm toán đã triển khai, chính sách lấy mẫu, phạm vi quyền truy cập.
Mỗi buổi sprint review sẽ trình bày một câu chuyện thống nhất: chúng tôi đã thay đổi gì ở mô hình, dữ liệu đã dịch chuyển ra sao vì điều đó và các cơ chế kiểm soát đã được cập nhật như thế nào. Nhờ vậy, ban lãnh đạo theo dõi được giá trị tạo ra; bộ phận kiểm toán thấy rõ khả năng truy vết; còn đội ngũ thực thi hiểu được mối quan hệ nhân – quả giữa các thay đổi/quyết định.
5. Biến việc phản hồi trở nên dễ dàng (và hiển thị rõ ràng) ngay trong công cụ làm việc
Trong một dự án triển khai tại bệnh viện, chúng tôi có rất nhiều phản hồi giá trị - nhưng lại bị ẩn trong SharePoint và các chuỗi email. Sau đó, chúng tôi chuyển toàn bộ về đúng nơi công việc diễn ra, dưới dạng bình luận trên Salesforce, trên các hồ sơ xử lý công việc, và qua những biểu mẫu rà soát đơn giản. Đồng thời, chúng tôi tổng hợp “Top 5 nhóm phản hồi nổi bật nhất” và hiển thị trên bảng điều khiển SPM mà ban lãnh đạo vốn xem định kỳ hằng tuần.
Nhờ vậy, vòng phản hồi được khép kín. Thay vì yêu cầu bác sĩ và đội hỗ trợ phải đi sang một nơi khác để lên tiếng, chúng tôi đưa việc phản hồi vào ngay trong luồng công việc của họ.
Chất lượng mô hình được cải thiện - bởi cuối cùng, phản hồi cũng được đặt đúng chỗ để phát huy tác dụng.
6. Khi nào nên nói “không” với việc xây dựng mô hình
Một bài học nghe có phần nghịch lý: đôi khi, hành động Agile nhất không phải là xây dựng mô hình. Nếu quy trình tạo ra dữ liệu còn chưa ổn định (ví dụ: quy trình mới, trường dữ liệu mới, hệ phân loại còn chưa thống nhất), hãy ổn định quy trình trước bằng tự động hóa hoặc các quy tắc rõ ràng. Sau đó, mới đưa vào một mô hình AI vào làm thử nghiệm. Nếu không, bạn chỉ đang dạy mô hình học lại sự hỗn loạn của ngày hôm qua - và gọi đó là “học”.
Hiện tại, chúng tôi áp dụng một nguyên tắc kiểm soát đơn giản: Nếu không thể xác định một phần quy trình đủ ổn định trong 4 đến 6 tuần, thì không đào tạo cho mô hình mà chỉ đo lường/ghi nhận. Phần đo lường này về sau sẽ trở thành tài sản quý giá cho việc huấn luyện.
Một khung thực hành gọn nhẹ bạn có thể áp dụng ngay:
- Nâng cấp DoD (Definition of Done): có chỉ số kết quả + kiểm soát + kiểm tra bằng mô hình đối chứng + ví dụ phản thực tế.
- Bản đồ người dùng: người dùng cuối, người quản trị dữ liệu, người kiểm duyệt, người chịu trách nhiệm kiểm soát - mỗi vai trò đều có kênh phản hồi ngay trong luồng công cụ.
- Chia nhỏ công việc theo quyết định: một quyết định thực tế, xuyên suốt đầu-cuối, kèm lập luận và cơ chế ghi đè.
- Backlog ba luồng: mô hình / dữ liệu / kiểm soát - nhưng được demo như một câu chuyện thống nhất.
- Phản hồi trong luồng công việc: thu thập và tổng hợp phản hồi ngay tại nơi mọi người đang làm việc.
- Đo lường trước khi làm mô hình AI: chỉ học từ những quy trình đủ ổn định để có thể “dạy” cho mô hình.
7. Những gì tôi rút ra từ hành trình này
Làm AI trong những môi trường thay đổi nhanh và chịu ràng buộc chặt chẽ về tuân thủ không khiến tôi chắc chắn hơn về “cách làm đúng”. Ngược lại, nó khiến tôi khiêm tốn hơn. Tôi đã trải qua những buổi họp stand-up vào tận đêm khuya khi mô hình bị trượt mà không hề được báo trước, những buổi sprint review mà một phát hiện nhỏ cũng làm thay đổi toàn bộ lộ trình, và cả những khoảnh khắc tự hỏi: “Liệu chúng ta có đang giải quyết đúng vấn đề không?”
Điều tôi học được - thường phải trả giá bằng những kinh nghiệm cay đắng, là những đội nhóm thành công xem việc học hỏi mới là sản phẩm thực sự. Các cơ chế kiểm soát trở thành tính năng và mỗi quyết định được chia nhỏ thành những phần có thể kiểm chứng được. Khi chúng ta tái định nghĩa “done” và “user” theo lăng kính đó, mô hình sẽ tốt lên qua từng sprint, và tổ chức dần đủ tin tưởng để mở rộng quy mô.
Vì thế, nếu đã có lúc bạn dừng lại giữa dự án và tự hỏi: “Liệu cách mình đang làm còn hiệu quả không?” khi xây dựng AI trong một thế giới đa hệ thống, chịu nhiều ràng buộc, thì bạn không hề đơn độc. Chính câu hỏi đó thường là điểm khởi đầu cho những cuộc trao đổi thực sự có giá trị. Và tôi cũng rất muốn nghe cách bạn vượt qua hành trình ấy như thế nào.
Tác giả: Pulkit Singhal | Nguồn: PMI
Xem thêm:
Sự kiện “Project Manager Trong Kỷ Nguyên AI”
AI, Tự động hóa và những câu hỏi hóc búa về sự hợp tác của con người