Một nhà máy không biết mình đang có bao nhiêu cỗ máy
Giả sử một công ty có một nhà máy rất lớn.
Trong nhà máy có hàng nghìn cỗ máy.
Máy cắt thép.
Máy đóng gói.
Máy kiểm tra chất lượng.
Máy điều khiển nhiệt độ.
Máy tự động phân loại hàng hóa.
Mỗi phòng ban tự mua máy riêng.
Có máy được nhập từ Đức.
Có máy do kỹ sư trong công ty tự chế.
Có một chiếc máy cũ đến mức không ai nhớ ai đã mua nó.
Có một chiếc vẫn chạy mỗi tối, nhưng người viết phần mềm điều khiển đã nghỉ việc từ ba năm trước.
Một ngày, giám đốc nhà máy hỏi:
Công ty hiện có bao nhiêu máy đang hoạt động?
Mọi người nhìn nhau.
Không ai biết.
Ông hỏi tiếp:
Máy nào đang trực tiếp quyết định sản phẩm đạt hay không đạt?
Vẫn không ai biết.
Nếu một chiếc máy phân loại sai hàng, ai chịu trách nhiệm?
Không khí bắt đầu hơi lạnh.
Nếu cần tắt toàn bộ máy của một nhà cung cấp thì phải tắt ở đâu?
Lúc này, một kỹ sư mở laptop.
Một người khác đi tìm file Excel.
Có người lục lại email từ năm ngoái.
Một người nhớ mang máng rằng danh sách máy từng nằm trong một thư mục Google Drive tên là:
1final_machine_inventory_v2_latest_revised.xlsx
Nhưng không ai chắc đó có phải bản mới nhất hay không.
Nghe khá buồn cười.
Không một nhà máy nghiêm túc nào lại vận hành như vậy.
Thế nhưng nhiều doanh nghiệp đang quản lý AI gần giống như thế.
Một đội dùng mô hình dự báo.
Đội khác dùng mô hình chống gian lận.
Một nhóm tự xây recommendation.
Một phòng ban gọi API của mô hình bên ngoài.
Một lập trình viên nhúng LLM vào chatbot nội bộ.
Một agent được cấp quyền đọc email.
Một agent khác được phép gọi ERP.
Các mô hình xuất hiện từng chút một, giống những chiếc máy được đưa qua cửa sau của nhà máy.
Đến một ngày, công ty nhận ra AI đã có mặt ở khắp nơi.
Nhưng không ai có thể trả lời đầy đủ:
- Có bao nhiêu hệ thống AI đang chạy?
- Chúng nằm ở đâu?
- Ai đang sở hữu?
- Chúng dùng dữ liệu nào?
- Chúng ảnh hưởng tới ai?
- Phiên bản nào đang phục vụ production?
- Chúng được phép làm gì?
- Khi có vấn đề thì phải gọi cho ai?
- Và quan trọng nhất: làm thế nào để tắt chúng?
Đó cũng là lý do mình thấy bài viết “Under the Hood: Scaling Responsible AI at Uber” khá đáng đọc.
Điều Uber chia sẻ không phải một mô hình mới.
Không có Transformer khổng lồ.
Không có benchmark sáng chói.
Không có biểu đồ khoe rằng AI thông minh hơn con người 17,3%.
Họ nói về một việc ít hào nhoáng hơn rất nhiều:
Làm thế nào để biết những hệ thống AI nào đang tồn tại, hiểu chúng hoạt động ra sao và đưa trách nhiệm vào ngay trong quy trình xây dựng phần mềm?
Nghe giống công việc hành chính.
Nhưng ở quy mô lớn, những thứ trông giống hành chính thường chính là phần giữ cho cả tòa nhà không sập.
Responsible AI là gì, nói theo cách lúa nhất có thể?
Responsible AI thường được dịch là AI có trách nhiệm.
Cụm từ này nghe khá trang trọng.
Đọc vào dễ tưởng tượng một hội đồng gồm nhiều người mặc vest, ngồi quanh chiếc bàn dài, thảo luận xem robot có nên yêu con người hay không.
Thực tế đời thường hơn nhiều.
Responsible AI là khả năng trả lời được các câu hỏi rất cơ bản:
AI này dùng để làm gì?
Ai đã xây nó?
Ai phê duyệt?
Dữ liệu nào được dùng?
Nó tốt trong trường hợp nào?
Nó yếu trong trường hợp nào?
Kết quả của nó ảnh hưởng tới ai?
Khi nó sai, chúng ta có phát hiện được không?
Ai có quyền sửa?
Ai có quyền tắt?
Một chiếc xe được phép chạy ngoài đường không chỉ vì động cơ mạnh.
Nó còn cần:
- biển số,
- hồ sơ đăng kiểm,
- thông tin chủ sở hữu,
- giới hạn tải trọng,
- lịch bảo trì,
- và một người chịu trách nhiệm khi có tai nạn.
AI cũng vậy.
Một model đạt accuracy 95% chưa có nghĩa là nó đã sẵn sàng để đi vào đời sống.
Ta còn phải biết 5% sai còn lại rơi vào đâu.
Sai ngẫu nhiên hay sai tập trung ở một nhóm người?
Sai trong môi trường thử nghiệm hay sai lúc dữ liệu thực tế thay đổi?
Sai một gợi ý bài hát có thể chỉ làm người dùng khó chịu.
Sai một quyết định liên quan tới tiền, an toàn hoặc quyền truy cập có thể để lại hậu quả rất khác.
Responsible AI không phải lời hứa rằng AI sẽ không bao giờ sai.
Không hệ thống nào đưa ra được lời hứa đó.
Nó là việc xây đủ ánh sáng, hàng rào, biển báo và công tắc khẩn cấp xung quanh một thứ vốn có thể sai.
Vấn đề bắt đầu khi AI có mặt ở khắp nơi
Khi một công ty chỉ có ba mô hình machine learning, việc quản lý khá đơn giản.
Mọi người biết nhau.
Người xây model ngồi cách người vận hành vài chiếc bàn.
Có vấn đề thì nhắn Slack:
Anh ơi, model dự báo hôm nay hơi lạ.
Nhưng khi AI phát triển trên nhiều nền tảng, nhiều đội và nhiều loại công nghệ khác nhau, cách quản lý bằng trí nhớ bắt đầu vỡ.
Uber cho biết AI được phát triển trên nhiều nền tảng và bởi nhiều nhóm trong công ty, bao gồm các mô hình được xây trên Michelangelo — nền tảng AI nội bộ của Uber — cũng như các ứng dụng Generative AI mới. Vì vậy, governance không thể tồn tại như một lớp quy định nằm bên ngoài quy trình kỹ thuật; nó phải được đưa thẳng vào nơi kỹ sư đang thiết kế, huấn luyện và triển khai hệ thống. (Uber)
Đây là một khác biệt rất lớn.
Cách làm dễ nhất là viết một bộ quy định dài 80 trang.
Gửi email toàn công ty.
Yêu cầu mọi người tự đọc.
Sáu tháng sau kiểm tra lại.
Một nửa chưa mở file.
Một phần tư tưởng quy định chỉ áp dụng cho model deep learning.
Số còn lại vẫn dùng template cũ vì link mới nằm trong một email đã bị chôn dưới 3.000 thông báo.
Quy định tồn tại.
Nhưng hành vi không thay đổi.
Uber chọn cách đưa Responsible AI vào chính vòng đời phát triển AI, dựa trên năm trụ cột:
- Visibility: nhìn thấy các hệ thống AI.
- Explainability: hiểu đầu vào ảnh hưởng tới đầu ra như thế nào.
- Governance: đưa kiểm soát vào quy trình.
- Education: giúp nhân viên hiểu họ cần làm gì.
- Adoption: kéo cả hệ thống mới lẫn hệ thống cũ vào cùng một chuẩn. (Uber)
Nói theo cách đơn giản hơn:
Biết máy nào đang chạy.
Biết vì sao nó chạy như vậy.
Đặt hàng rào trước khi mở máy.
Dạy người vận hành cách dùng.
Và đừng bỏ quên những chiếc máy cũ đang nằm dưới tầng hầm.
Trụ cột thứ nhất: Muốn quản lý AI, trước hết phải tìm thấy nó
Điều đầu tiên Uber xây không phải một mô hình phát hiện bias cực kỳ huyền bí.
Họ xây một Model Catalog.
Một cuốn sổ chung để biết các mô hình đang tồn tại trong công ty.
Ở trung tâm của Model Catalog là Model Card — một tài liệu chuẩn hóa mô tả những thông tin quan trọng của từng model, chẳng hạn mục đích, đặc điểm, metric hiệu năng, thông tin triển khai và các tài liệu liên quan. Catalog có thể tìm kiếm, lọc theo trường dữ liệu và tự động điền một số thông tin từ tín hiệu hệ thống nhằm giảm công việc thủ công cho kỹ sư. (Uber)
Model Card giống giấy đăng ký xe
Một Model Card tốt có thể trả lời:
- Tên model là gì?
- Model thuộc hệ thống nào?
- Ai là owner?
- Dùng cho mục đích nào?
- Không nên dùng cho mục đích nào?
- Loại model là gì?
- Được huấn luyện từ dữ liệu nào?
- Metric chính là gì?
- Phiên bản nào đang production?
- Được deploy ở đâu?
- Đầu vào và đầu ra là gì?
- Có rủi ro đặc biệt nào?
- Muốn báo lỗi thì liên hệ ai?
Khái niệm Model Card được đề xuất nhằm đi kèm model với thông tin về mục đích sử dụng, điều kiện đánh giá, hiệu năng, giới hạn và bối cảnh phù hợp, để người dùng không mang một model ra sử dụng ở nơi nó chưa từng được thiết kế cho. (arXiv)
Nó giống giấy đăng ký xe.
Một chiếc xe không chỉ được gọi là:
1xe màu đen
Nó có biển số.
Số khung.
Số máy.
Chủ sở hữu.
Loại phương tiện.
Ngày đăng kiểm.
Một chiếc model cũng không thể được quản lý bằng tên:
1model_final_v3_new
Bởi vì sáu tháng sau, không ai còn nhớ v3 khác v3_new_final2 ở điểm nào.
Một danh sách Excel chưa phải Model Catalog
Nhiều công ty nghe tới model inventory sẽ tạo một file Excel.
Ban đầu khá ổn.
Có 20 dòng.
Mọi người chăm chỉ cập nhật.
Ba tháng sau có 70 dòng.
Một model đổi owner nhưng chưa sửa.
Một model đã tắt vẫn ghi là production.
Một model mới được deploy tối thứ Sáu nhưng chưa ai thêm vào.
Một cột ghi accuracy 93%, nhưng không nói đo trên tập dữ liệu nào.
Một link trỏ tới tài liệu đã bị xóa.
Đến cuối năm, file Excel trở thành một nghĩa trang thông tin.
Mọi thứ từng đúng.
Nhưng không biết còn đúng hay không.
Đây là lý do Uber tự động điền một phần metadata từ tín hiệu hệ thống và tích hợp Model Catalog vào quy trình phát triển ML. (Uber)
Những thông tin máy có thể biết thì đừng bắt con người gõ lại:
- Model ID
- Training job ID
- Git commit
- Owner của project
- Framework
- Ngày deploy
- Endpoint
- Model version
- Dataset version
- Metric từ pipeline
- Trạng thái production
Con người nên bổ sung những thứ máy khó hiểu:
- Mục đích kinh doanh
- Giới hạn sử dụng
- Nhóm người bị ảnh hưởng
- Rủi ro
- Giả định
- Cách xử lý khi có sự cố
Model Catalog sống được hay không phụ thuộc vào một nguyên tắc:
Thông tin phải được sinh ra từ quy trình, không phải trông chờ vào trí nhớ.
Đừng quản lý từng file, hãy quản lý cả hệ thống
Một model hiếm khi sống một mình.
Nó còn có:
- Pipeline dữ liệu
- Feature Store
- Code preprocessing
- Model artifact
- API serving
- Business rule
- Threshold
- Dashboard
- Human approval
- Downstream system
Giả sử một model chống gian lận trả về điểm:
10.87
Con số đó không tự khóa giao dịch.
Một rule phía sau có thể quy định:
1Nếu score > 0.8 thì chặn.
Thay threshold từ 0.8 xuống 0.6 có thể ảnh hưởng lớn hơn việc thay model.
Vì vậy, chỉ quản lý file model là chưa đủ.
Uber nhấn mạnh governance phải hoạt động ở cấp hệ thống, bởi AI được xây dựng xuyên qua nhiều nền tảng, repository, nhóm và workflow khác nhau. (Uber)
Đây là bài học rất quan trọng.
Trách nhiệm không nằm trong một file .pt.
Nó nằm trong toàn bộ dây chuyền biến dữ liệu thành hành động.
Trụ cột thứ hai: Máy đưa ra kết quả, nhưng vì sao?
Giả sử model dự đoán thời gian giao hàng là 42 phút.
Người dùng hỏi:
Vì sao lâu vậy?
Câu trả lời tệ nhất là:
Máy tính tính ra như vậy.
Đó không phải giải thích.
Đó chỉ là một cách lịch sự để nói:
Chúng tôi cũng không biết.
Explainability cố gắng giúp con người hiểu những yếu tố nào đã ảnh hưởng tới kết quả của model.
Uber tích hợp các công cụ feature attribution trực tiếp vào workflow của Michelangelo, ban đầu tập trung vào model dùng dữ liệu dạng bảng hoặc dữ liệu có cấu trúc. Họ triển khai ba cấp độ giải thích: Permutation Feature Importance cho góc nhìn toàn cục, SHAP cho từng dự đoán cụ thể và Integrated Gradients cho các mô hình khả vi như neural network. Kết quả phân tích feature importance được tính sau training và liên kết tự động vào Model Card. (Uber)
Global explanation: Cả model thường nhìn vào điều gì?
Giả sử có một model dự đoán thời gian giao hàng dựa trên:
- Khoảng cách
- Thời tiết
- Giờ trong ngày
- Tình trạng giao thông
- Thời gian chuẩn bị món
- Khu vực
- Loại phương tiện
Ta muốn biết, nhìn chung, model phụ thuộc nhiều nhất vào feature nào.
Permutation Feature Importance, viết tắt là PFI, có một trực giác khá thú vị.
Ta lấy một feature rồi xáo trộn giá trị của nó.
Nếu model đột nhiên dự đoán tệ hơn nhiều, feature đó có vẻ quan trọng.
Nếu xáo trộn mà kết quả gần như không thay đổi, model có thể không dựa nhiều vào nó.
Giống như tháo từng chân khỏi một chiếc bàn.
Tháo chân nào mà bàn ngã mạnh nhất, chân đó có vai trò lớn.
PFI cho cái nhìn toàn cục:
Nhìn chung, model đang dựa vào yếu tố nào?
Nó hữu ích để phát hiện những chuyện lạ.
Ví dụ, một feature tưởng rất quan trọng nhưng model gần như không dùng.
Hoặc một feature không nên có ảnh hưởng lớn lại đang đứng đầu bảng.
Local explanation: Vì sao trường hợp này ra kết quả như vậy?
Global explanation nói về toàn bộ model.
Nhưng người dùng thường hỏi về một trường hợp cụ thể.
Vì sao đơn hàng này bị đánh giá rủi ro cao?
Vì sao chuyến đi này được dự đoán lâu hơn?
Vì sao sản phẩm này được xếp trước sản phẩm kia?
SHAP gán cho từng feature một giá trị thể hiện mức đóng góp của nó vào một dự đoán cụ thể. Framework SHAP được xây dựng để hợp nhất một nhóm phương pháp giải thích dựa trên feature attribution và đưa ra các giá trị quan trọng cho từng đặc trưng trong mỗi prediction. (arXiv)
Ví dụ:
1Dự đoán ban đầu: 25 phút
2
3Khoảng cách xa: +8 phút
4Nhà hàng chuẩn bị chậm: +6 phút
5Giao thông thuận lợi: -3 phút
6Ít tài xế trong khu vực: +6 phút
7
8Kết quả: 42 phút
Con số thực tế phức tạp hơn nhiều.
Nhưng trực giác là vậy.
SHAP giống một nhóm người cùng đẩy một chiếc xe.
Ta muốn biết mỗi người đã góp bao nhiêu lực vào hướng di chuyển cuối cùng.
Integrated Gradients: Lần theo con đường từ im lặng tới quyết định
Với neural network, Uber sử dụng Integrated Gradients.
Phương pháp này xem xét sự thay đổi của đầu ra khi đầu vào đi dần từ một giá trị nền đến giá trị thật, rồi tích lũy gradient trên con đường đó để ước lượng mức đóng góp của từng đầu vào. Integrated Gradients được đề xuất với hai tính chất nền tảng là Sensitivity và Implementation Invariance, đồng thời không yêu cầu chỉnh sửa kiến trúc model. (Proceedings of Machine Learning Research)
Hãy tưởng tượng một căn phòng tối.
Ta bật từng chút ánh sáng lên.
Mỗi lần sáng thêm một chút, ta quan sát đồ vật nào bắt đầu hiện rõ và ảnh hưởng tới điều mình đang nhìn.
Cuối cùng, ta có một hình dung về yếu tố nào đã đưa model từ trạng thái nền tới kết quả hiện tại.
Explainability không phải máy phát hiện sự thật
Đây là chỗ cần hết sức cẩn thận.
Một biểu đồ SHAP đẹp không có nghĩa model công bằng.
Feature importance cao không có nghĩa feature đó là nguyên nhân thật trong đời sống.
Hai feature tương quan với nhau có thể khiến attribution khó diễn giải.
Một feature không xuất hiện trực tiếp vẫn có thể được đại diện bởi những feature khác.
Ví dụ, xóa cột giới tính không đảm bảo model không còn học được tín hiệu tương quan từ hành vi, địa điểm hoặc những dữ liệu thay thế khác.
Explainability giúp ta nhìn vào model.
Nhưng nhìn thấy không đồng nghĩa đã hiểu hết.
Một bác sĩ có thể nhìn ảnh X-quang.
Điều đó không khiến mọi chẩn đoán tự động đúng.
Explainability là chiếc đèn pin.
Không phải giấy chứng nhận vô tội.
Đây cũng là lý do Responsible AI không thể chỉ có một biểu đồ feature importance.
Nó cần governance, kiểm thử, con người và khả năng đặt kết quả vào đúng bối cảnh.
Trụ cột thứ ba: Đừng đợi xây xong nhà mới kiểm tra bản vẽ
Một trong những ý tưởng mình tâm đắc nhất trong bài của Uber là shift-left governance.
Thay vì chờ đến sát ngày release mới bắt đầu kiểm tra trách nhiệm, compliance và rủi ro, Uber đưa các bước này vào từ giai đoạn lập kế hoạch.
Quy trình review tài liệu PRD và ERD được sử dụng như điểm vào sớm cho ML governance. Các yêu cầu chính sách được kết hợp với lời nhắc và cơ chế thực thi trong sản phẩm; kỹ sư được yêu cầu hoàn thành Model Card trước khi deploy, tạo thành một cổng kiểm soát có thể audit trong workflow giao phần mềm. (Uber)
Kiểm tra trước khi đổ bê tông
Giả sử bản vẽ một tòa nhà đặt cửa thoát hiểm ở sai vị trí.
Có hai thời điểm để phát hiện.
Thời điểm thứ nhất: khi bản vẽ còn nằm trên màn hình.
Kỹ sư kéo cửa sang chỗ khác.
Mất mười phút.
Thời điểm thứ hai: sau khi tòa nhà đã hoàn thành.
Tường đã xây.
Điện đã đi.
Nội thất đã lắp.
Muốn sửa phải đập cả một khu vực.
AI governance cũng vậy.
Nếu đến ngày deploy mới hỏi:
- Model đang ảnh hưởng tới ai?
- Dữ liệu này có được phép dùng không?
- Ai là owner?
- Có cơ chế giám sát chưa?
- Nếu model sai thì rollback thế nào?
- Model có giải thích được không?
thì có thể đã quá muộn.
Hàng tháng engineering đã trôi qua.
API đã tích hợp.
Dashboard đã xây.
Business đang chờ release.
Trong hoàn cảnh đó, governance team bị đẩy vào vai người đứng trước chuyến tàu đang chạy và giơ tấm bảng:
Xin dừng lại để điền biểu mẫu.
Không ai vui.
Kỹ sư thấy governance cản trở.
Governance thấy kỹ sư thiếu trách nhiệm.
Shift-left giải quyết mâu thuẫn bằng cách hỏi sớm hơn.
Khi ý tưởng còn mềm.
Khi kiến trúc còn thay đổi được.
Khi một rủi ro chưa biến thành 50 microservice.
Governance tốt phải nằm trong công cụ
Một quy định chỉ nằm trên wiki rất dễ bị quên.
Một quy định nằm trong workflow khó bị bỏ qua hơn.
Ví dụ:
1Train model
2 ↓
3Đánh giá metric
4 ↓
5Sinh feature attribution
6 ↓
7Cập nhật Model Card
8 ↓
9Chạy compliance checks
10 ↓
11Approval nếu cần
12 ↓
13Deploy
Nếu Model Card chưa đủ thông tin, pipeline không cho qua.
Nếu model thuộc nhóm rủi ro cao, hệ thống yêu cầu thêm approval.
Nếu owner trống, không deploy.
Nếu model version và tài liệu không khớp, dừng lại.
Nghe hơi khó chịu.
Giống việc sân bay bắt kiểm tra an ninh.
Không ai thích xếp hàng.
Nhưng không ai muốn một sân bay bỏ kiểm tra chỉ để hành khách lên máy bay nhanh hơn ba phút.
Responsible AI chỉ mở rộng được khi trách nhiệm trở thành tính năng của platform, không phải lòng tốt tự nguyện của từng kỹ sư.
Không phải model nào cũng cần cùng một hàng rào
Một model sắp xếp thứ tự bài viết nội bộ không có cùng mức rủi ro với model ảnh hưởng tới tiền, quyền truy cập hoặc an toàn.
Nếu dùng cùng một quy trình kiểm soát cho mọi hệ thống, ta sẽ gặp hai vấn đề.
Hoặc quy trình quá nhẹ với hệ thống quan trọng.
Hoặc quá nặng với những thử nghiệm nhỏ.
Cả hai đều tệ.
Một cách thực tế là phân loại theo rủi ro.
Ví dụ:
Rủi ro thấp
- Tóm tắt tài liệu nội bộ
- Gợi ý nội dung không mang tính quyết định
- Sandbox thử nghiệm
- Prototype chưa có người dùng thật
Có thể chỉ cần Model Card cơ bản, kiểm tra dữ liệu và owner.
Rủi ro trung bình
- Recommendation cho khách hàng
- Dự báo vận hành
- Phân loại ticket
- Agent tạo nội dung nhưng cần con người duyệt
Cần đánh giá metric, monitoring, giới hạn sử dụng và human oversight.
Rủi ro cao
- Quyết định liên quan tới tiền
- Quyền truy cập
- An toàn
- Nhóm người dễ bị ảnh hưởng
- Agent được phép thực hiện hành động quan trọng
Cần review chuyên sâu, kiểm thử fairness, security, privacy, approval rõ ràng và cơ chế dừng khẩn cấp.
Uber cho biết họ chuyển từ các rule tĩnh sang hệ thống phân loại động, không phụ thuộc vào công nghệ cụ thể, đồng thời sử dụng ngữ cảnh và expert oversight để phân biệt hệ thống có ảnh hưởng thực sự với những cách dùng AI không đáng kể. (Uber)
Điểm này rất đáng học.
Governance không nên hỏi:
Có dùng neural network không?
Nó nên hỏi:
Hệ thống này có thể gây ra hậu quả gì?
Công nghệ thay đổi rất nhanh.
Hậu quả đối với con người mới là thứ cần được quản lý.
Trụ cột thứ tư: Không thể giao hết trách nhiệm cho một phòng ban
Giả sử công ty có một đội Responsible AI gồm mười người.
Công ty có năm nghìn kỹ sư.
Nếu mọi quyết định đều phải đi qua mười người đó, hàng đợi sẽ dài đến năm sau.
Nếu chỉ mười người hiểu Responsible AI, phần còn lại của công ty sẽ coi nó như chuyện của phòng pháp lý.
Đó là cách một chương trình chết rất nhanh.
Uber xem Responsible AI là cam kết chung trong toàn công ty. Họ xây các khóa đào tạo để nhân viên hiểu nguyên tắc trước khi sử dụng hoặc triển khai model, đồng thời tạo một AI Resource Hub tập trung chứa tài liệu kỹ thuật, hướng dẫn và nguồn học tập. (Uber)
Responsible AI giống an toàn cháy nổ
Một tòa nhà không thể nói:
Việc chữa cháy là trách nhiệm của đội cứu hỏa, nhân viên bình thường không cần biết.
Nhân viên vẫn phải biết:
- Lối thoát hiểm ở đâu
- Chuông báo cháy trông như thế nào
- Không được chặn cửa thoát hiểm
- Bình chữa cháy dùng ra sao
- Khi có khói thì gọi ai
Họ không cần trở thành lính cứu hỏa.
Nhưng họ cần đủ hiểu biết để không vô tình biến một tia lửa thành thảm họa.
Kỹ sư cũng vậy.
Không phải ai cũng cần trở thành chuyên gia fairness hay luật AI.
Nhưng người xây hệ thống cần biết:
- Dữ liệu nào nhạy cảm
- Khi nào cần Model Card
- Khi nào phải review
- Explainability nào phù hợp
- Cách báo cáo sự cố
- Rủi ro nào không được tự quyết
- Model nào cần con người phê duyệt đầu ra
AI literacy không chỉ là biết viết prompt.
Nó còn là biết lúc nào không nên tin output.
Trụ cột thứ năm: Đừng chỉ quản lý những model sinh ra từ hôm nay
Giả sử công ty ban hành quy định:
Từ thứ Hai, mọi model mới phải có Model Card.
Nghe rất tốt.
Nhưng còn hàng trăm model đang chạy từ ba năm trước thì sao?
Chúng không biến mất chỉ vì quy định mới ra đời.
Đây là phần khó nhất của governance.
Xây quy trình đẹp cho hệ thống mới khá dễ.
Đưa di sản cũ vào cùng tiêu chuẩn mới mới là việc tốn sức.
Uber bắt đầu bằng giai đoạn onboarding thủ công và beta testing với các đội sở hữu model. Phản hồi từ người dùng nội bộ được dùng để sửa yêu cầu Model Card, phát hành phiên bản thứ hai và thực hiện một đợt tập trung nhằm đưa các model hiện hữu vào chuẩn chung. (Uber)
Model cũ giống nhà xây trước khi có luật phòng cháy mới
Không thể yêu cầu phá toàn bộ thành phố rồi xây lại.
Nhưng cũng không thể nói:
Nhà này cũ nên không cần an toàn.
Ta phải kiểm kê.
Phân loại.
Ưu tiên nhà rủi ro cao.
Bổ sung lối thoát.
Lắp báo cháy.
Đưa dần vào chuẩn mới.
Một chương trình adoption thực tế có thể đi theo thứ tự:
- Tìm tất cả model đang production.
- Xác định owner.
- Loại những model đã chết nhưng chưa được khai tử.
- Phân loại rủi ro.
- Ưu tiên model ảnh hưởng lớn.
- Bổ sung Model Card.
- Thêm monitoring và explainability.
- Đưa vào deployment gate.
- Thiết lập lịch review lại.
Không thể hoàn thành trong một đêm.
Nhưng ít nhất mỗi ngày tòa nhà sáng thêm một tầng.
Vòng đời model không bắt đầu ở production
Một model có thể tồn tại ở nhiều trạng thái:
1Ý tưởng
2 ↓
3Thử nghiệm
4 ↓
5Huấn luyện
6 ↓
7Đánh giá
8 ↓
9Shadow
10 ↓
11Canary
12 ↓
13Production
14 ↓
15Bảo trì
16 ↓
17Ngừng sử dụng
Governance phải hiểu các trạng thái này.
Một notebook thử nghiệm không cần quy trình giống model production.
Nhưng nếu notebook bắt đầu xuất kết quả để nhân viên ra quyết định thật, nó không còn chỉ là thử nghiệm.
Một model đã ngừng nhận traffic nhưng vẫn còn endpoint và credential cũng chưa thật sự chết.
Uber gọi đây là life-cycle-aware governance: xác định thế nào là một model nằm trong phạm vi quản lý trên toàn bộ vòng đời, từ thử nghiệm sớm tới triển khai production. (Uber)
Điều này nghe đơn giản.
Nhưng rất nhiều hệ thống AI sống trong vùng xám.
Người xây nói:
Đây chỉ là POC.
Business nói:
POC này đang gửi báo cáo cho giám đốc mỗi sáng.
Nếu một POC có người dùng thật, dữ liệu thật và quyết định thật, nó đã rời khỏi phòng thí nghiệm từ lâu.
Chỉ có nhãn dán trên cửa là chưa kịp đổi.
“Glass box” không có nghĩa model phải đơn giản
Người ta thường gọi machine learning là hộp đen.
Dữ liệu đi vào.
Kết quả đi ra.
Bên trong có nhiều ma trận, gradient và những con số mà phần lớn con người không nhìn nổi quá năm phút.
Uber dùng hình ảnh glass box — hộp kính — như một hướng tiếp cận: tạo visibility, explainability và governance xung quanh hệ thống AI để tổ chức có thể đổi mới mà vẫn giữ accountability và niềm tin. (Uber)
Hộp kính không có nghĩa mọi người đều nhìn vào neural network và hiểu từng neuron.
Nó có nghĩa ta nhìn thấy những thứ cần thiết để quản lý:
- Model nào đang chạy
- Phiên bản nào
- Owner là ai
- Được thiết kế cho việc gì
- Dữ liệu nào đi vào
- Metric nào được theo dõi
- Feature nào ảnh hưởng lớn
- Ai đã phê duyệt
- Khi nào deploy
- Rủi ro nào đã được ghi nhận
- Cách rollback
- Khi nào cần đánh giá lại
Ta không cần hiểu từng vòng quay trong động cơ để lái xe an toàn.
Nhưng ta cần đồng hồ tốc độ, đèn báo dầu, phanh, lịch bảo trì và một cuốn hướng dẫn.
Responsible AI là bảng điều khiển của cỗ máy.
Một kiến trúc Responsible AI đơn giản cho doanh nghiệp
Không phải công ty nào cũng cần xây Michelangelo.
Nhưng có thể học cách ghép các thành phần.
1PRD / ERD
2 │
3 ▼
4AI Risk Classification
5 │
6 ├── Low Risk
7 ├── Medium Risk
8 └── High Risk
9 │
10 ▼
11Training Pipeline
12 │
13 ├── Dataset metadata
14 ├── Model metrics
15 ├── Feature attribution
16 ├── Security checks
17 └── Privacy checks
18 │
19 ▼
20Model Registry
21 │
22 ▼
23Model Catalog + Model Card
24 │
25 ▼
26Approval / Deployment Gate
27 │
28 ▼
29Production Serving
30 │
31 ├── Quality monitoring
32 ├── Drift monitoring
33 ├── Fairness monitoring
34 ├── Cost monitoring
35 ├── Incident management
36 └── Human feedback
37 │
38 ▼
39Review / Retrain / Retire
1. Model Registry lưu vật thể
Model Registry lưu:
- Model artifact
- Phiên bản
- Metric
- Dataset version
- Training run
- Deployment status
2. Model Catalog lưu ý nghĩa
Model Catalog trả lời:
- Model dùng để làm gì
- Ai sở hữu
- Ảnh hưởng tới ai
- Rủi ro gì
- Giới hạn ở đâu
- Tài liệu liên quan
- Quy trình xử lý sự cố
Hai hệ thống có thể là một sản phẩm.
Nhưng hai khái niệm không hoàn toàn giống nhau.
Registry giống kho giữ máy.
Catalog giống hồ sơ quản lý máy.
3. Policy Engine quyết định cần kiểm tra gì
Không phải mọi model đều chạy cùng checklist.
Policy có thể dựa trên:
- Loại use case
- Dữ liệu nhạy cảm
- Mức tự động hóa
- Khả năng gây thiệt hại
- Phạm vi người dùng
- Có human approval hay không
- Model nội bộ hay bên thứ ba
- Có GenAI hay không
4. CI/CD biến trách nhiệm thành hàng rào thật
Ví dụ:
1Không có owner → Không deploy
2Thiếu Model Card → Không deploy
3Model rủi ro cao → Cần approval
4Metric dưới ngưỡng → Không deploy
5Dataset chưa được duyệt → Không train
6Không có rollback plan → Không production
5. Monitoring phải kéo dài sau deployment
Model không ngừng thay đổi chỉ vì file trọng số đứng yên.
Thế giới xung quanh nó thay đổi.
Người dùng thay đổi.
Sản phẩm thay đổi.
Dữ liệu thay đổi.
Một model tốt hôm nay có thể trở nên tệ sau sáu tháng.
Responsible AI không phải con dấu đóng một lần.
Nó là việc theo dõi suốt vòng đời.
Đo Responsible AI bằng gì?
Một chương trình governance không nên chỉ báo cáo:
Đã tổ chức 12 buổi đào tạo.
Đã tạo 500 Model Card.
Những con số này có ích.
Nhưng chưa nói hệ thống có an toàn hơn hay không.
Có thể theo dõi thêm:
- Tỷ lệ model production đã có owner
- Tỷ lệ model có Model Card đầy đủ
- Tỷ lệ metadata được tự động cập nhật
- Số model không còn traffic nhưng chưa retire
- Thời gian tìm owner khi xảy ra incident
- Tỷ lệ model rủi ro cao đã được review
- Tỷ lệ model có rollback plan
- Tỷ lệ explanation được sinh thành công
- Số vấn đề được phát hiện trước deployment
- Thời gian từ lúc phát hiện lỗi tới khi tắt model
- Số ngoại lệ governance tồn tại quá hạn
- Tỷ lệ model cũ đã được đưa vào chuẩn mới
Mục tiêu không phải tạo nhiều giấy tờ hơn.
Mục tiêu là giảm thời gian tổ chức phải đứng trong bóng tối khi có chuyện.
Những cái bẫy rất dễ gặp
Model Card biến thành bài văn mẫu
Nếu Model Card có 50 câu hỏi nhưng người viết chỉ copy:
1No known risks.
thì catalog vẫn đẹp.
Thông tin vẫn vô dụng.
Model Card phải ngắn đủ để được cập nhật, nhưng cụ thể đủ để sử dụng khi có vấn đề.
Mọi model đều được đánh giá giống nhau
Một chatbot nội bộ và model tự động từ chối giao dịch không nên đi qua cùng một checklist.
Không có risk classification, governance sẽ trở thành một cục bê tông đổ lên mọi đội kỹ thuật.
Explainability được dùng để trang trí
Sinh một biểu đồ SHAP rồi gắn vào dashboard không có nghĩa ai đã đọc nó.
Cần định nghĩa:
- Dấu hiệu nào là bất thường?
- Feature nào không được phép chi phối quá lớn?
- Ai xem?
- Xem khi nào?
- Có hành động gì sau khi xem?
Governance chỉ diễn ra trước deployment
Model có thể drift.
Dataset có thể thay đổi.
Owner có thể nghỉ việc.
Policy có thể đổi.
Một Model Card đúng hôm nay có thể sai sau một năm.
Chỉ quản lý model tự xây
Doanh nghiệp ngày càng sử dụng API model bên ngoài.
Dù không sở hữu trọng số, công ty vẫn sở hữu cách model được đưa vào sản phẩm.
Một hệ thống gọi model bên thứ ba vẫn cần:
- Owner
- Use case
- Dữ liệu gửi ra ngoài
- Version
- Prompt
- Tool permissions
- Evaluation
- Monitoring
- Fallback
- Incident process
Thuê động cơ không có nghĩa được phép lái xe không cần phanh.
Điều mình tâm đắc nhất: Responsible AI thực ra là System Engineering
Khi nghe Responsible AI, người ta thường nghĩ tới triết học.
Công bằng.
Đạo đức.
Niềm tin.
Những khái niệm đó quan trọng.
Nhưng để chúng tồn tại trong production, chúng phải được biến thành những thứ cực kỳ cụ thể:
- Một model ID
- Một owner
- Một Model Card
- Một policy
- Một pipeline
- Một approval
- Một dashboard
- Một alert
- Một nút rollback
- Một ngày hết hạn
- Một log audit
Niềm tin nghe rất trừu tượng.
Nhưng nó được xây bằng metadata.
Trách nhiệm nghe rất lớn lao.
Nhưng nó bắt đầu bằng việc điền đúng tên người sở hữu.
Minh bạch nghe giống triết học.
Nhưng đôi khi nó chỉ là khả năng tìm được model đang chạy trong vòng ba mươi giây.
Đó là điều mình thích nhất trong cách Uber tiếp cận bài toán.
Họ không cố giải Responsible AI chỉ bằng những tuyên bố đẹp.
Họ xây catalog.
Tự động sinh metadata.
Đưa explainability vào training workflow.
Gắn governance vào PRD và ERD.
Đặt Model Card trước cửa deployment.
Đào tạo người dùng.
Sau đó quay lại lục từng model cũ để kéo chúng vào cùng một hệ thống. (Uber)
Không có phép màu.
Chỉ có rất nhiều công việc nhỏ được nối đúng chỗ.
Giống một cây cầu.
Người đứng trên cầu nhìn thấy con đường phẳng.
Không nhìn thấy hàng nghìn con ốc đang giữ từng thanh thép.
Responsible AI cũng vậy.
Người dùng chỉ nhìn thấy một kết quả AI xuất hiện trên màn hình.
Phía sau kết quả đó cần có cả một cấu trúc đủ chắc để trả lời:
Nó đến từ đâu?
Vì sao nó xuất hiện?
Ai đang chịu trách nhiệm?
Và chuyện gì xảy ra nếu nó sai?
Tổng kết
AI càng phát triển, số lượng model sẽ càng tăng.
Model không chỉ nằm trong đội machine learning.
Nó sẽ xuất hiện trong search.
Recommendation.
Forecasting.
Chăm sóc khách hàng.
Tài chính.
Nhân sự.
Bảo mật.
Marketing.
Email.
Tài liệu.
Code.
Và những AI Agent có khả năng tự gọi công cụ rồi tác động thẳng vào hệ thống doanh nghiệp.
Khi đó, câu hỏi quan trọng không còn chỉ là:
Model có chính xác không?
Mà còn là:
Công ty có biết model này đang tồn tại không?
Một AI có thể rất thông minh.
Nhưng nếu không ai biết nó nằm ở đâu, dùng dữ liệu gì, ai sở hữu và cách tắt nó, sự thông minh đó không còn là tài sản hoàn toàn.
Nó bắt đầu trở thành một khoản nợ.
Có lẽ Responsible AI không bắt đầu bằng việc dạy máy trở thành người tốt.
Nó bắt đầu bằng việc con người chịu khó quản lý những gì mình đã tạo ra.
Đặt tên cho nó.
Làm giấy khai sinh.
Ghi rõ chủ sở hữu.
Giới hạn quyền hạn.
Theo dõi hành vi.
Kiểm tra sức khỏe.
Và chuẩn bị sẵn một công tắc để dừng lại.
Bởi vì trong một nhà máy có hàng nghìn cỗ máy tự động, thứ đáng sợ nhất không phải cỗ máy mạnh nhất.
Mà là cỗ máy vẫn đang chạy, đang đưa ra quyết định, đang tác động lên con người — nhưng không ai trong nhà máy còn nhớ nó thuộc về ai.
Bình luận