Software Engineering cho Machine Learning (phần cuối): Hướng tới một mô hình hoàn chỉnh cho quy trình phát triển Machine Learning
Như chúng ta đã thấy ở phần trước, có một số khác biệt trong mức độ trải nghiệm về AI giữa các nhóm Software Engineer (SE). Sự khác biệt đó ảnh hưởng đến nhận thức của chính cá nhân từng SE về các thách kỹ thuật sẽ được giải quyết trong quá trình thực hành hàng ngày của họ. Khi các nhóm SE trưởng thành và bắt đầu hoạt động tốt, việc cung cấp các sản phẩm và nền tảng dựa trên ML sẽ trở nên hiệu quả với hiệu suất tốt hơn.
Để nắm bắt được sự phát triển của ML chính xác hơn so với sử dụng số năm kinh nghiệm đơn thuần, các tác giả của nghiên cứu này đã tạo một mô hình đo mức độ trưởng thành 6 chiều đánh giá xem mỗi giai đoạn quy trình công việc này:
(1) Đã có các mục tiêu được xác định
(2) Được thực hiện nhất quán
(3) Được ghi lại
(4) Được tự động hóa
(5) Được đo lường và theo dõi
(6) Được cải thiện liên tục
hay không.
Các yếu tố này dựa trên các khái niệm đằng sau Mô Hình Khả Năng Trưởng Thành (Capability Maturity Model — CMM) và Six Sigma, được sử dụng rất rộng rãi trong lĩnh vực phát triển phần mềm để đánh giá và cải thiện sự trưởng thành của các dự án phần mềm.
Trong khảo sát, các tác giả của nghiên cứu này đã yêu cầu các SE tham gia trả lời 2 giai đoạn nào mà họ dành nhiều thời gian nhất (tính bằng số giờ họ dùng cho mỗi hoạt động). Cụ thể, họ xếp hạng ý kiến từ (1) Rất không đồng ý đến (5) Rất đồng ý cho 6 tuyên bố sau:
S1: Nhóm của tôi có mục tiêu xác định rõ ràng cho những gì cần hoàn thành đối với hoạt động này.
S2: Nhóm của tôi thực hiện hoạt động này một cách nhất quán.
S3: Nhóm của tôi đã ghi lại phần lớn các thực hành liên quan đến hoạt động này.
S4: Nhóm của tôi tự động hóa phần lớn hoạt động này.
S5: Nhóm của tôi đo lường và theo dõi hiệu quả khi hoàn thành hoạt động này.
S6: Nhóm của tôi liên tục cải thiện các thực hành liên quan đến hoạt động này.
Các SE sẽ trả lời cho những giai đoạn mà họ cảm thấy quen thuộc nhất do họ thường chuyên về các giai đoạn khác nhau trong một quy trình làm việc. Câu hỏi trên giúp các SE có thể trả lời dễ dàng, đồng thời bao quát các kỹ thuật ML được áp dụng. Ý định của cuộc khảo sát này là mô tả một cách dễ hiểu các vấn đề như mức độ tự động hóa trong một giai đoạn quy trình công việc cụ thể? Các giai đoạn được ghi lại như thế nào?. Sẽ còn cần nhiều nghiên cứu hơn để xác định được mức trưởng thành tương tự CMM. Để phân tích các câu trả lời, các tác giả đã xác định Chỉ số Trưởng Thành Hoạt Động (Activity Maturity Index — AMI) để kết hợp các điểm số riêng lẻ thành một thước đo duy nhất. Chỉ số này là kết quả trung bình thu được với 6 tuyên bố S1 đến S6 nói trên. Tiếp đến, các tác giả cũng yêu cầu các SE tham gia đánh giá Hiệu quả Hoạt động (Activity Effectiveness) qua việc trả lời câu hỏi “Bạn cho rằng thực hành trong nhóm của bạn hiệu quả đến đâu xung quanh hoạt động này trên thang điểm từ 1 (kém) đến 5 (xuất sắc)?” Hệ số tương quan Spearman giữa Chỉ số Trưởng thành và Chỉ số Hiệu quả là từ 0.4982 đến 07.627 (p < 0.001) cho tất cả các hoạt động AI. Điều này cho thấy Chỉ số Trưởng thành là một thước đo tổng hợp đáng tin cậy và hợp lệ để có thể nắm bắt được sự trưởng thành và hiệu quả của các hoạt động AI.
Ngoài Chỉ số Trưởng thành hoạt Động và Chỉ số Hiệu quả Hoạt động, các tác giả của nghiên cứu này còn thu thập điểm Hiệu quả Tổng thể (Overall Effectiveness — OE) bằng câu hỏi: “Hiệu quả làm việc với AI trong nhóm của bạn trên thang điểm từ 1 (kém) đến 5 (xuất sắc)?”. Các biện pháp AMI, AE và OE cho phép chúng ta có thể so sánh sự trưởng thành và hiệu quả của các tổ chức, ngành học và lĩnh vực ứng dụng khác nhau bên trong tập đoàn đa lĩnh vực như Microsoft, từ đó xác định được điểm cần cải thiện.
So sánh này được trực quan hóa qua Hình 3 và hiển thị điểm hiệu quả tổng thể trung bình chia cho chín trong số các lĩnh vực AI tiêu biểu nhất trong khảo sát. Có 2 điều cần chú ý. Đầu tiên, sự lan rộng của các giá trị y chỉ ra rằng số liệu OE có thể phân biệt bằng số giữa các nhóm SE, có nghĩa là một số người được hỏi cảm thấy nhóm của họ ở mức độ trưởng thành khác nhau so với những người khác. Thứ hai, một thử nghiệm ANOVA và Scott Knott cho thấy sự khác biệt đáng kể giữa các giá trị — chứng minh rằng giá trị tiềm năng để xác định các mức trưởng thành của quy trình ML là khác nhau. Tuy vậy, các định lượng này cũng là những nỗ lực đầu tiên trong việc định lượng số liệu quy trình để cho phép các nhóm SE đánh giá mức độ họ thực hành ML.
VII: THẢO LUẬN
Trong phần này, các tác giả của nghiên cứu sẽ tổng hợp các phát hiện của họ thành 3 quan sát về một số khác biệt cơ bản trong cách thức mà Software Engineering được điều chỉnh để hỗ trợ các lĩnh vực ứng dụng phổ biến trước đây và cách mà Software Engineering có thể được điều chỉnh để hỗ trở các ứng dụng và nền tảng AI.
A. Phát hiện và quản lý dữ liệu
Nếu Software Engineering là việc code các phần mềm chuyển giao, thì ML lại thiên về dữ liệu cho model. Các SE thích thiết kế và xây dựng các hệ thống thanh lịch, trừu tượng, module hóa và đơn giản. Ngược lại, dữ liệu được sử dụng trong ML lại đồ sộ, cụ thể theo từng ngữ cảnh, không đồng nhất, phức tạp và khó để mô tả. Những khác biệt dẫn đến nhiều vấn đề khó khăn khi các model ML được tích hợp vào các hệ thống phần mềm với quy mô lớn dần.
Các SE phải tìm, thu thập, quản lý, tinh gọn và xử lý dữ liệu để sử dụng trong quá trình training và điều chỉnh model. Tất cả các dữ liệu phải được lưu trữ, theo dõi và cập nhật phiên bản. Mặc dù các API phần mềm được mô tả bằng thông số kỹ thuật, bộ dữ liệu lại hiếm khi có định nghĩa lược đồ rõ ràng để mô tả các cột cũng như đặc điểm hóa phân phối thống kê. Tuy nhiên, do việc lặp đi lặp lại nhanh chóng liên quan đến ML, lược đồ dữ liệu (và cả dữ liệu) thay đổi thườn xuyên, thậm chí nhiều lần mỗi ngày. Khi dữ liệu được nhập từ các nguồn cấp dữ liệu chẩn đoán quy mô lớn, nếu các kỹ sư ML muốn thay đổi giá trị dữ liệu nào được thu thập, họ phải đợi các hệ thống kỹ thuật được cập nhật, triển khai và thông báo trước khi dữ liệu mới có thể đến. Ngay cả những thay đổi “đơn giản” cũng có thể có những tác động đáng kể đến khối lượng dữ liệu được thu thập, có khả năng ảnh hưởng đến các ứng dụng thông qua các đặc tính hiệu suất bị thay đổi hoặc việc sử dụng băng thông mạng tăng lên.
Mặc dù có nhiều công nghệ được thiết kế hoàn hảo để cập nhật code, nhưng điều tương tự không áp dụng với dữ liệu. Một tập dữ liệu đã cho có thể chứa dữ liệu từ một số chế độ lược đồ khác nhau. Khi một kỹ sư duy nhất tập hợp và xử lý dữ liệu, họ có thể theo dõi các chi tiết vốn không được ghi lại này, nhưng khi quy mô dự án mở rộng, việc duy trì tác vụ này có thể trở thành gánh nặng. Để giúp mã hóa thông tin này trở thành một dạng có thể đọc bằng máy, Gebru et al. đề xuất sử dụng các bảng dữ liệu được lấy cảm hứng từ các thiết bị điện tử để theo dõi một cách minh bạch và đáng tin cậy hơn các đặc điểm siêu dữ liệu của các bộ dữ liệu này [1]. Để so sánh các bộ dữ liệu với nhau, công cụ Datadiff [2] cho phép các nhà phát triển xây dựng các hàm chuyển đổi khả thi trên các mẫu dữ liệu.
B. Tùy biến và Tái sử dụng
Mặc dù hiểu rõ về việc mất bao nhiêu công sức để tùy chỉnh và sử dụng lại các thành phần code, việc tùy chỉnh các model ML vẫn có thể tốn nhiều nguồn lực hơn nữa. Trong phần mềm, các đơn vị tái sử dụng chính yếu là các hàm, thuật toán, thư viện và module. Một SE có thể tìm source code cho thư viện (VD: từ Github), phân tách và dễ dàng thực hiện các thay đổi đối với code, sử dụng chính các kỹ năng mà họ dùng để phát triển phần mềm.
Mặc dù các model ML được train đầy đủ có vẻ là những chức năng mà người ta gọi là input cho sẵn, nhưng thực tế lại phức tạp hơn nhiều. Một phần của model là thuật toán cốt yếu cho kỹ thuật ML cụ thể đang được sử dụng (VD: SVM hoặc mạng lưới thần kinh). Một phần khác của model lại là tập hợp các tham số điều khiển chức năng (ví dụ: vectors hỗ trợ SVM hoặc trọng số mạng thần kinh) và được học trong quá trình training. Nếu kỹ sư muốn áp dụng model vào domain tương tự như dữ liệu ban đầu được train, việc tái sử dụng là điều đơn giản. Tuy nhiên, có nhiều thay đổi quan trọng cần có nếu muốn chạy model trên một domain hoàn toàn khác hoặc trong trường hợp sử dụng dạng input hơi khác. Không thể đơn giản thay đổi các tham số chỉ với trình soạn thảo văn bản. Trên thực tế, model có thể phải training lại, hoặc tệ hơn, có thể cần phải thay thế bằng một model khác. Cả hai trường hợp này đều yêu cầu SE phải có các kỹ năng ML mà họ có thể chưa từng học bao giờ. Ngoài ra, training lại hoặc xây dựng lại model đòi hỏi dữ liệu dành cho việc training bổ sung phải có sẵn, thu thập, tinh gọn — điều này mất nhiều công sức và chuyên môn tương tự như quá trình đã làm với model ban đầu.
C. Machine Learning Modularity
Một thuộc tính quan trọng khác của kỹ thuật hệ thống phần mềm quy mô lớn là tính module (modularity). Các module được tách ra và cách ly để đảm bảo rằng việc phát triển một thành phần sẽ không can thiệp vào hành vi của các thành phần khác trong cùng giai đoạn phát triển. Ngoài ra, tính module của phần mềm được củng cố bởi Luật Conway, các nhóm xây dựng từng thành phần của phần mềm với sự đồng nhất với kiến trúc chung của chính phần mềm đó. Do đó, các module riêng biệt thường được chỉ định cho các nhóm SE riêng biệt. Các tương tác module được kiểm soát bởi các API có nhiệm vụ kép giúp cho phép các module tách rời nhau, nhưng cũng mô tả các giao diện để giảm thiểu khối lượng giao tiếp cần thiết giữa các nhóm SE riêng biệt, giúp cho các module của họ tương thích và hoạt động cùng nhau. [3][4]
Việc duy trì ranh giới module nghiêm ngặt giữa các model ML là điều khó khăn vì 2 lí do. Đầu tiên, các model không dễ để mở rộng. Ví dụ, người ta không thể (hoặc chưa thể) lấy một model NLP tiếng Anh và thêm một model NLP riêng để đặt pizza và kì vọng 2 model có thể hoạt động đúng với nhau. Tương tự, người ta không thể lấy model đặt pizza và ghép nó với một mô hình NLP tiếng Pháp rồi chúng hoạt động với nhau như một phép màu. Các model sẽ phải được phát triển và training cùng nhau.
Thứ hai là, các model tương tác với nhau theo những cách không rõ ràng. Trong các hệ thống quy mô lớn có nhiều hơn một model, mỗi kết quả của model sẽ ảnh hưởng đến một quá trình training và điều chỉnh khác. Trên thực tế, hiệu quả của model này sẽ thay đổi do kết quả của model kia, ngay cả khi code của chúng được giữ tách biệt. Do đó, ngay cả khi các nhóm khác nhau xây dựng từng model, họ cũng vẫn phải phối hợp chặt chẽ để train hoặc duy trì hệ thống đầy đủ. Hiện tượng này (còn có thể gọi là vấn đề thành phần hỗn loạn) có thể dẫn đến lan truyền lỗi đa dạng, cũng có nghĩa là các cải tiến trong một phần của hệ thống không được điều chỉnh theo các cải tiến mới nhất. Vấn đề này thậm chí còn rõ ràng hơn trong các trường hợp khi các model ML không được cập nhật theo cách tương thích và phát sinh ra những lỗi mới chưa từng được thấy trước đây, khiến phá vỡ sự tương tác với các bộ phận khác của hệ thống dựa vào nó.
VIII. GIỚI HẠN
Nghiên cứu này được thực hiện với các nhóm phát triển tại Microsoft — một công ty phần mềm toàn cầu với danh mục sản phẩm đa dạng. Đây cũng là một trong những nhà cung cấp lớn nhất các sản phẩm và nền tảng dựa trên Machine Learning. Một số phát hiện có thể chỉ là đặc trưng của các nhóm Microsoft cũng như những thành viên tham gia khảo sát trong nghiên cứu này. Một số phát hiện phụ thuộc vào quy trình ML cụ thể được sử dụng bởi một số nhóm SE tại Microsoft. Tuy nhiên, với sự đa dạng cao của các dự án, các tác giả nghiên cứu hi vọng rằng nhiều bài học trong series bài viết này sẽ áp dụng được với các công ty khác.
IX. KẾT LUẬN
Nhiều nhóm tại Microsoft đã dành nhiều nỗ lực đáng kể để phát triển một danh mục ứng dụng và nền tảng AI rộng lớn bằng cách tích hợp ML vào các quy trình kỹ thuật phần mềm hiện có cũng như trau dồi và phát triển đội ngũ kế cận gồm các nhân tài học và làm về ML. Trong nghiên cứu này, các tác giả đã mô tả của một số nghiên cứu khác để tìm hiểu thêm về quy trình và thực hành thay đổi được thực hiện bởi một số nhóm của Microsoft trong những năm gần đây. Từ những phát hiện này, các tác giả đã tổng hợp một tập hợp các thực hành tốt nhất để giải quyết các vấn đề cơ bản cho sự phát triển và triển khai quy mô lớn của các ứng dụng dựa trên ML. Một số vấn đề được báo cáo có tương quan với trải nghiệm của người tham gia khảo sát về kinh nghiệm với AI, trong khi những vấn đề khác được áp dụng cho hầu hết những người xây dựng ứng dụng AI. Các tác giả đã trình bày một thước đo trưởng thành của quy trình ML để giúp các nhóm tự đánh giá mức độ họ làm việc với ML và đưa ra hướng dẫn để cải thiện. Cuối cùng, các tác giả đã xác định ba khía cạnh khác biệt cơ bản của domain AI so với các domain ứng dụng trước đó. Tác động của chúng sẽ còn đòi hỏi những nỗ lực nghiên cứu nhiều hơn nữa để có thể giải quyết trong tương lai.
Tham khảo:
[1] T. Gebru, J. Morgenstern, B. Vecchione, J. W. Vaughan, H. M. Wallach, H. D. III, and K. Crawford, “Datasheets for datasets,” CoRR, vol. abs/1803.09010, 2018.
[2] C. Sutton, T. Hobson, J. Geddes, and R. Caruana, “Data diff: Interpretable, executable summaries of changes in distributions for data wrangling,” in Proc. of the 24th ACM SIGKDD. ACM, 2018, pp. 2279–2288.
[3] C. R. B. de Souza, D. Redmiles, and P. Dourish, ““Breaking the Code”, moving between private and public work in collaborative software development,” in Proc. of the 2003 International ACM SIGGROUP Conference on Supporting Group Work, 2003, pp. 105–114.
[4] C. R. B. de Souza, D. Redmiles, L.-T. Cheng, D. Millen, and J. Patterson, “Sometimes you need to see through walls: A field study of application programming interfaces,” in Proc. of the 2004 ACM Conference on Computer Supported Cooperative Work, 2004, pp. 63–71.
___________________________________________________________________
Software Engineering for Machine Learning: A Case Study
Các tác giả nghiên cứu:
Saleema Amershi | Microsoft Research | Redmond, WA USA | samershi@microsoft.com
Andrew Begel | Microsoft Research | Redmond, WA USA | andrew.begel@microsoft.com
Christian Bird | Microsoft Research | Redmond, WA USA | cbird@microsoft.com Robert DeLine | Microsoft Research | Redmond, WA USA | rdeline@microsoft.com
Harald Gall | University of Zurich | Zurich, Switzerland | gall@ifi.uzh.ch
Ece Kamar | Microsoft Research | Redmond, WA USA | eckamar@microsoft.com
Nachiappan Nagappan | Microsoft Research | Redmond, WA USA | nachin@microsoft.com
Besmira Nushi | Microsoft Research | Redmond, WA USA | besmira.nushi@microsoft.com
Thomas Zimmermann | Microsoft Research | Redmond, WA USA | tzimmer@microsoft.com
