Xe tự hành, robot công nghiệp và các đội máy bay không người lái không tuân theo các bộ quy tắc cứng nhắc, được viết tay vốn là nền tảng của các hệ thống lái tự động cũ. Chúng học hỏi từ lượng dữ liệu khổng lồ, điều này có nghĩa là hành vi của chúng mang tính xác suất chứ không phải tất định. Một hệ thống lái tự động truyền thống của máy bay phản ứng với các đầu vào cảm biến thông qua logic được lập trình rõ ràng. Một mô hình học máy phản ứng thông qua các khuôn mẫu mà nó suy luận được trong quá trình huấn luyện. Sự khác biệt đó khiến việc xác minh trở nên khó khăn hơn nhiều, và đó chính là lý do tại sao cộng đồng học máy đã chuyển hướng sang các khung đảm bảo có cấu trúc thay vì các thử nghiệm mang tính tùy hứng (ad-hoc).
Tại sao Đảm bảo Học máy là Yếu tố Tiên quyết
Khi một hệ thống tự hành mắc lỗi, hậu quả vượt xa một lỗi máy chủ hay một ứng dụng bị treo. Một robot kho bãi nhận diện sai chướng ngại vật có thể phá hủy hàng hóa hoặc làm bị thương công nhân. Một máy bay không người lái giao hàng phân loại đường dây điện là bầu trời trống trải có thể đâm vào cơ sở hạ tầng. Vì các hệ thống này dựa trên các mạng thần kinh phức tạp và các mô hình thống kê, nên các phương thức lỗi (failure modes) của chúng rất tinh vi. Chúng hiếm khi hỏng hóc theo những cách hiển nhiên. Thay vào đó, chúng âm thầm suy giảm chất lượng khi đối mặt với các đầu vào nằm ngoài phân phối mà chúng đã thấy trong quá trình huấn luyện.
Các lỗi trong học máy tự hành không phải lúc nào cũng bắt nguồn từ mã nguồn lỗi rõ ràng. Chúng có thể nảy sinh từ những lỗ hổng trong dữ liệu huấn luyện, những thay đổi môi trường không lường trước, hoặc các dự đoán quá tự tin vào các trường hợp biên (edge cases). Các tổ chức coi các thành phần ML như các mô-đun phần mềm tiêu chuẩn, giả định rằng một bộ thử nghiệm đơn vị (unit test) là đủ, sẽ nhận ra quá muộn rằng độ chính xác trong phòng thí nghiệm không đồng nghĩa với sự an toàn trong thế giới thực. Bạn cần một tiêu chuẩn có hệ thống nhằm giải quyết các rủi ro đặc thù của hành vi học được. Đó chính là khoảng trống mà khung AMLAS được thiết kế để lấp đầy.
AMLAS thực sự bao gồm những gì
AMLAS, viết tắt của Assurance of Machine Learning for use in Autonomous Systems (Đảm bảo Học máy cho việc sử dụng trong các Hệ thống Tự hành), cung cấp một cách tiếp cận toàn diện (end-to-end) để xác minh rằng các thành phần được học đã sẵn sàng cho việc triển khai trong các tình huống rủi ro cao. Nó không coi an toàn là một yếu tố bổ sung hay một bước kiểm tra cuối cùng trước khi phát hành. Thay vào đó, nó lồng ghép các hoạt động đảm bảo vào vòng đời của hệ thống.
Khung làm việc này tập trung vào ba trụ cột thực tế:
Các phương pháp xác minh cho mô hình ML. Điều này vượt xa các chỉ số chia tách huấn luyện-kiểm tra tiêu chuẩn như độ chính xác (accuracy) hoặc điểm F1. Việc đảm bảo theo AMLAS đặt câu hỏi liệu mô hình có hành xử một cách có thể dự đoán được tại các ranh giới quyết định hay không, cách nó phản ứng với các đầu vào nằm ngoài phân phối (out-of-distribution), và liệu điểm tin cậy (confidence scores) của nó có phải là những chỉ số đáng tin cậy cho sự không chắc chắn thực tế hay không. Các kỹ sư được kỳ vọng sẽ kiểm tra mô hình bằng các ví dụ đối kháng (adversarial examples) và kiểm tra áp lực (stress-test) nó với các đầu vào từ các lĩnh vực nằm ngoài tập huấn luyện một chút. Mục tiêu không phải là sự hoàn hảo. Mục tiêu là thu thập đủ bằng chứng để biết khi nào có thể tin tưởng mô hình và khi nào thì không.
Các giao thức an toàn cho các hành động tự hành. Một mô hình nhận thức được học sẽ cung cấp dữ liệu cho phần mềm lập kế hoạch và điều khiển để di chuyển phần cứng vật lý. AMLAS yêu cầu các hành động hạ nguồn (downstream) này phải bao gồm các rào chắn bảo vệ (guardrails). Ngay cả khi một mạng thần kinh phân loại sai một đối tượng, phương tiện hoặc robot đó không được phép thực hiện một quỹ đạo vi phạm các ràng buộc cứng về mặt vật lý. Điều này có thể có nghĩa là giới hạn mô-men xoắn trên cánh tay robot, hàng rào địa lý (geofencing) cho máy bay không người lái, hoặc các hành lang phanh bắt buộc cho các phương tiện mặt đất. Hệ thống tự hành cần các lớp kiến trúc để ngăn chặn một lỗi mô hình đơn lẻ trở thành một sự cố vật lý không thể kiểm soát.
Các phương pháp để giảm thiểu sự không chắc chắn. Sự không chắc chắn trong học máy tồn tại dưới nhiều dạng. Có sự không chắc chắn aleatoric (aleatoric uncertainty) — nhiễu vốn có trong các phép đo cảm biến hoặc môi trường — và sự không chắc chắn epistemic (epistemic uncertainty) — phản ánh những gì mô hình chưa biết. AMLAS khuyến khích các thực hành giúp định lượng và quản lý cả hai loại này. Các kỹ thuật có thể bao gồm các phương pháp ensemble (tập hợp), nơi nhiều mô hình cùng đánh dấu sự bất đồng như một dấu hiệu cảnh báo, hoặc các lớp xác thực đầu vào để từ chối các dữ liệu được biết là sẽ gây ra hành vi bất thường. Bạn có thể không thể loại bỏ hoàn toàn sự không chắc chắn, nhưng bạn có thể ngăn hệ thống hành động mù quáng dựa trên nó.
Một lộ trình thực tế để xây dựng niềm tin
Các khung làm việc chỉ có ý nghĩa nếu các đội ngũ đưa chúng vào thực tế. AMLAS được chuyển hóa thành hành động hiệu quả nhất khi các tổ chức tuân theo một trình tự có kỷ luật.
Hãy xác định các mục tiêu an toàn của bạn trước khi thu thập bất kỳ tập dữ liệu nào. Trong kỹ thuật phần mềm truyền thống, các yêu cầu luôn đi trước. Các dự án học máy thường làm ngược lại, coi an toàn là một vấn đề cần giải quyết sau khi mô hình đã được huấn luyện. Hãy đảo ngược thói quen đó. Hãy bắt đầu với một miền thiết kế vận hành (operational design domain) rõ ràng. Hệ thống sẽ chạy trong những điều kiện nào? Tỷ lệ lỗi có thể chấp nhận được đối với mỗi mối nguy hiểm là bao nhiêu? Những lỗi nào yêu cầu sự can thiệp ngay lập tức của con người? Việc trả lời những câu hỏi này sớm sẽ định hình mọi thứ, từ việc thu thập dữ liệu đến kiến trúc mô hình.
Kiểm thử mô hình của bạn với dữ liệu phản ánh sự hỗn loạn thực tế trong vận hành. Các điểm chuẩn (benchmarks) trong phòng thí nghiệm mang lại cảm giác an tâm, nhưng chúng thường không phản ánh đúng thực tế. Một robot kho bãi chỉ được huấn luyện trên các hình ảnh mã vạch hoàn hảo sẽ thất bại khi nhãn bị nhăn, thiếu ánh sáng hoặc bị bẩn che khuất. Một máy bay không người lái tự hành chỉ được thử nghiệm trong thời tiết đẹp sẽ gặp khó khăn với ánh sáng chói và gió giật. Bạn cần các nhật ký (logs) từ môi trường triển khai thực tế, bao gồm cả những trường hợp biên (edge cases) gây khó chịu vốn không bao giờ xuất hiện trong các tập dữ liệu được tuyển chọn kỹ lưỡng. Hãy chạy các thử nghiệm chế độ bóng (shadow mode trials), nơi hệ thống tự hành đưa ra quyết định song song với người vận hành nhưng chưa trực tiếp điều khiển phần cứng. Hãy so sánh các nhật ký này một cách nghiêm ngặt.
Giám sát hiệu suất liên tục sau khi triển khai. Thế giới không đứng yên một chỗ. Sự thay đổi ánh sáng theo mùa, bề mặt đường mòn, thiết kế bao bì mới và các mô hình lưu lượng mạng thay đổi đều có thể làm suy giảm hiệu suất của một mô hình từng hoạt động rất tốt. Hãy thiết lập hệ thống telemetry để theo dõi độ tin cậy của dự đoán, sự trôi dạt phân phối đầu vào (input distribution drift) và tỷ lệ sự cố. Thiết lập các ngưỡng để kích hoạt việc xem xét bởi con người hoặc các hạn chế vận hành tạm thời khi hành vi của mô hình thay đổi. Một mô hình không phải là một sản phẩm tĩnh mà bạn giao hàng rồi quên đi. Nó là một thành phần sẽ "lão hóa" ngay khoảnh khắc nó tiếp xúc với thế giới thực.
Sự thật phũ phàng về việc kiểm định trong thế giới thực
Nhiều đội ngũ tự thuyết phục mình rằng điểm kiểm định (validation score) cao là dấu hiệu của sự sẵn sàng. Thực tế không phải vậy. Kiểm định trong thế giới thực đòi hỏi phải chấp nhận sự không thoải mái. Điều đó có nghĩa là cho máy bay không người lái bay qua những điều kiện gió giật, chạy robot kho bãi trong ca đêm khi đèn nhấp nháy, và để các mô hình nhận thức tiếp xúc với các nhãn dán đối kháng trên biển báo giao thông. Nếu môi trường thử nghiệm của bạn có cảm giác gọn gàng và dễ đoán, thì bạn không phải đang thử nghiệm. Bạn đang diễn tập.
Quy trình này tốn kém và chậm chạp. Nó đòi hỏi sự phối hợp giữa các kỹ sư học máy, các chuyên gia an toàn và những người vận hành thực địa, những người hiểu rõ môi trường vật lý. Thành quả nhận được là một tập hợp các bằng chứng. Khi bạn triển khai, bạn sẽ có thể chỉ ra các điều kiện thử nghiệm cụ thể, các chế độ lỗi đã biết và các biện pháp giảm thiểu gắn liền với từng rủi ro. Tài liệu đó chính là thứ phân biệt một nguyên mẫu (prototype) với một hệ thống mà bạn sẵn sàng vận hành không cần giám sát gần con người.
Giữ cho hệ thống luôn trung thực theo thời gian
Giám sát sau triển khai là nơi mà nhiều chương trình đảm bảo (assurance programs) âm thầm thất bại. Các đội ngũ ăn mừng việc ra mắt và chuyển nguồn lực sang tính năng tiếp theo. Trong khi đó, mô hình đã triển khai phải đối mặt với một dòng dữ liệu đầu vào dần khác biệt so với kinh nghiệm huấn luyện của nó. Nếu không có sự giám sát tích cực, sự trôi dạt này sẽ tích tụ cho đến khi một sự cố nghiêm trọng buộc phải tiến hành điều tra phản ứng.
Hãy thiết lập các vòng lặp phản hồi có cấu trúc. Ghi lại mọi trường hợp mô hình thể hiện độ tin cậy thấp hoặc nơi người vận hành phải can thiệp. Sử dụng các nhật ký này để huấn luyện lại hoặc tinh chỉnh (fine-tune) mô hình định kỳ, nhưng phải kiểm định mỗi bản cập nhật thông qua cùng các cổng đảm bảo (assurance gates) đã áp dụng cho bản phát hành ban đầu. Hãy đối xử với các bản cập nhật mô hình với sự thận trọng tương tự như khi bạn thay thế một hệ thống phanh cơ học bằng một thiết kế mới.
Bài học thực sự
Học máy trong các hệ thống tự hành không phải là một sân chơi nghiên cứu. Đó là cơ sở hạ tầng mang theo rủi ro vật lý, và nó xứng đáng được áp dụng sự nghiêm ngặt tương tự như cách các kỹ sư hàng không vũ trụ và thiết bị y tế áp dụng cho phần cứng. AMLAS cung cấp một hệ thống thuật ngữ và quy trình làm việc cho sự nghiêm ngặt đó. Nó sẽ không tự động hóa sự tin tưởng cho bạn, nhưng nó cung cấp cho bạn một cách có thể lặp lại để giành được sự tin tưởng đó. Hãy bắt đầu với các mục tiêu an toàn trung thực. Kiểm định với dữ liệu thực tế và "bẩn". Hãy quan sát hệ thống như một người hoài nghi một khi nó đã đi vào hoạt động. Các khung làm việc đã tồn tại. Phần còn lại là kỷ luật.
For the full technical breakdown of the AMLAS guidance, read the original details here: https://dev.to/paperium/guidance-on-the-assurance-of-machine-learning-in-autonomous-systems-amlas-f9
If you want to discuss assurance strategies and exchange practical notes with a community working on similar problems, join the conversation here: https://t.me/GyaanSetuAi