Các Khoản Nợ Kỹ Thuật Tiềm Ẩn Mà Mọi Người Thực Hành AI Nên Biết

Giới thiệu

Việc xây dựng mô hình máy học đầu tiên của bạn hiện đã trở nên khá nhanh chóng với sự ra đời của các gói và thư viện mới. Thoạt nhìn nó có vẻ màu hồng, nó đang tích lũy khoản nợ kỹ thuật tiềm ẩn về việc duy trì các hệ thống máy học như vậy. 

Nhưng trước tiên hãy hiểu nợ kỹ thuật là gì:

“Trong phát triển phần mềm, nợ kỹ thuật (còn được gọi là nợ thiết kế hoặc nợ mã) là chi phí ngụ ý cho việc làm lại bổ sung do chọn một giải pháp dễ dàng (có giới hạn) ngay bây giờ thay vì sử dụng một cách tiếp cận tốt hơn sẽ mất nhiều thời gian hơn.” – Wikipedia

Theo Ward Cunningham, nợ kỹ thuật là chi phí dài hạn phát sinh do sự phát chuyển nhanh chóng trong công nghệ phần mềm. Nó có thể giống như điều đúng đắn để làm tại một thời điểm trong khi chuyển mã sang sản xuất nhưng nó cần được thực hiện ở giai đoạn sau, về mặt viết bài kiểm tra đơn vị toàn diện, loại bỏ mã dư thừa và không sử dụng, tài liệu, tái cấu trúc mã, v.v. Các nhóm làm việc trên các nhiệm vụ như vậy không cung cấp chức năng mới, mà tham gia tích lũy nợ một cách kịp thời để giảm phạm vi lỗi và thúc đẩy việc bảo trì mã dễ dàng.

Nợ kỹ thuật từ mục đích học máy

Việc nghĩ đến nợ kỹ thuật trong các hệ thống ML dẫn đến phát sinh chi phí cho các vấn đề liên quan đến ML ngoài các vấn đề kỹ thuật phần mềm điển hình.

Phần lớn nợ kỹ thuật ML là do các tương tác và giao diện ở cấp hệ thống. 

Xác định được người tiêu dùng của bạn

Việc xác định người tiêu dùng dự đoán học máy là rất quan trọng để đánh giá tác động của phiên bản mô hình mới của bạn. Phản hồi về các dự đoán của mô hình tạo cơ sở cho việc sửa đổi mô hình và kết hợp tác động tiềm ẩn đối với người dùng. 

Để loại bỏ các rủi ro phát sinh từ các yêu cầu kém hoặc hiểu kém từ những người dùng ngoài ý muốn, quan trọng là phải lập tài liệu và đăng xuất nhóm người dùng đã khai báo, đồng thời tách rời các vòng phản hồi ẩn và kỳ vọng từ nhiều nhóm người dùng.

 Không có thay đổi nào là nhỏ 

Một hệ thống máy học được xây dựng tốt nhất khi tất cả các thuộc tính tác động đến các biến mục tiêu đều có mặt trong thời gian đào tạo mô hình. Về cơ bản, một mô hình có thể xem những gì mà một chuyên gia về con người sẽ thấy để đánh giá kết quả. Cuộc sống của một nhà khoa học dữ liệu sẽ đơn giản hơn nhiều nếu tất cả các biến đều độc lập, nhưng đó không phải là cách quản lý một sự kiện trong đời thực. Bất kỳ thay đổi đơn lẻ nào trong một biến không chỉ thay đổi phân phối của nó mà còn tác động đến tầm quan trọng của tính năng và trọng số của tất cả các biến đầu vào (hoặc độc lập) cùng nhau. Điều này là do thuộc tính tương tác tức là sự thay đổi trong biến ảnh hưởng đến phân phối chung của tất cả các biến. 

Các hiệu ứng tương tự có thể được quan sát thấy khi thêm hoặc xóa một biến. Sự trộn lẫn và vướng víu của các tín hiệu làm thay đổi phức tạp toàn bộ quá trình học mô hình. 

Lưu ý rằng điều này không giới hạn đối với bất kỳ việc thêm hoặc loại bỏ biến nào, chủ yếu là bất kỳ thay đổi nào về siêu tham số, quản lý dữ liệu, quy trình ghi nhãn, lựa chọn ngưỡng hoặc quy trình lấy mẫu có thể dẫn đến hiệu ứng được gọi là Thay đổi mọi thứ sẽ thay đổi mọi thứ.

Dữ liệu liên quan và dữ liệu thay đổi

Việc phân phối dữ liệu đầu vào có thể thay đổi theo thời gian và sẽ cần đánh giá tác động của nó đối với kết quả của mô hình. Đó là nơi mà việc lập phiên bản dữ liệu là quan trọng để những thay đổi định tính và định lượng trong dữ liệu được nắm bắt và ghi lại đầy đủ. Tuy nhiên, điều này dẫn đến chi phí bổ sung cho việc cảnh giác với việc làm mới dữ liệu và duy trì nhiều phiên bản.

Nhiều nhà khoa học dữ liệu thêm nhiều gói hoặc thực hiện các thay đổi tạm thời đối với mã để nhanh chóng điều chỉnh phiên bản mới nhất của mã đang chạy để thực hiện thử nghiệm hoặc phân tích. Vấn đề phát sinh khi họ quên giữ cho mã có liên quan và loại bỏ các khối mã không sử dụng hoặc không cần thiết đóng vai trò là trở ngại cho những thay đổi mã sau này khi cần. Đây thường là trường hợp khi nhiều nhà phát triển đang cộng tác trên một tập lệnh duy nhất và tiếp tục thêm các thay đổi mà không loại bỏ sự dư thừa hoặc không liên quan do lo ngại rằng cuối cùng họ có thể vi phạm mã của người khác hoặc sẽ mất thêm thời gian để kiểm tra mã ngược - thay đổi tương thích.

Khi nào nên thêm và không đánh đổi

Mọi nhà khoa học dữ liệu cần chấp nhận thực tế rằng “Nhiều hơn không phải là tốt hơn” khi bổ sung các tính năng. Theo giả định rằng mọi tính năng đơn lẻ đều quan trọng đối với việc học mô hình trừ khi nó dẫn đến kích thước dữ liệu quá lớn, các nhà khoa học dữ liệu không xem xét chi phí duy trì các tính năng có giá trị còn lại. Ngoài ra, nếu một tính năng sau đó được tuyên bố là không quan trọng, thì họ không muốn thay đổi quy trình mô hình và do đó, tiếp tục mang các tính năng kế thừa được thiết kế trong giai đoạn phát triển mô hình ban đầu.

Điều này vẫn có vẻ khá đơn giản để xử lý cho đến khi tất cả các tính năng được cắm trực tiếp vào mô hình từ một bảng duy nhất. Độ phức tạp tăng lên nhiều lần khi các thuộc tính được lấy từ nhiều luồng dữ liệu và trải qua vô số phép nối và phép biến đổi dẫn đến các bước trung gian bổ sung. Việc quản lý các quy trình như vậy, đồng thời phát hiện và gỡ lỗi các hệ thống như vậy trở thành yếu tố ngăn cản nhóm tiếp tục phát triển các giải pháp đổi mới.  

Hạn chế của hiệu ứng xếp tầng

Bản thân việc quản lý một mô hình đã là một trận chiến khó khăn, do đó rất nhiều tổ chức có xu hướng xây dựng một mô hình tổng quát. Nó có vẻ là một trò chơi chiến thắng, nhưng nó là một con dao hai lưỡi.

Là một mô hình tổng quát hoạt động tốt cho tất cả các trường hợp sử dụng? Nếu không thì việc xây dựng một lớp mô hình hiệu chỉnh trên mô hình cơ sở thường là lựa chọn được nhiều người tìm kiếm để phục vụ tốt hơn cho phát biểu vấn đề tương tự nhưng hơi khác một chút. Trong những trường hợp như vậy, mô hình sửa đổi lấy mô hình cơ sở làm đầu vào bổ sung thêm một lớp phụ thuộc và một bộ phân tích và giám sát bổ sung cho mô hình sửa đổi.

Tóm tắt

Trong bài viết, chúng tôi đã thảo luận về chi phí và lợi ích của việc xử lý nợ kỹ thuật ẩn trong các hệ thống máy học. Quan điểm thiển cận về việc ưu tiên phát hành các phiên bản mô hình mới hoặc chạy thử nghiệm quy trình từ đầu đến cuối sẽ chuyển mọi thứ sang sản xuất một cách nhanh chóng. Nhưng nó tiếp tục thêm vào các chi phí ẩn làm chậm tốc độ đổi mới của các nhóm trong thời gian dài.  

Các tác giả của bài báo nghiên cứu chia sẻ một số câu hỏi đáng suy nghĩ để những người thực hành AI suy ngẫm trong khi xem xét các tác động của các khoản nợ tiềm ẩn:

• Thật dễ dàng để kiểm tra một cách tiếp cận thuật toán mới ở quy mô đầy đủ
• Làm thế nào chúng ta có thể đo lường tác động của từng thay đổi? Chúng ta đã thiết lập các điểm kiểm tra trong quy trình để nắm bắt và phân bổ các yếu tố chẩn đoán chưa?
• Cải tiến bằng cách mang lại một thay đổi trong hệ thống có dẫn đến tác động tiêu cực đến phần còn lại của hệ thống không?
• Làm thế nào nhanh chóng và dễ dàng để các thành viên mới hiểu được các sắc thái và sự phức tạp của toàn bộ quy trình?

Copyright Disclaimer:

This site does not store any files on its server. We only index and link to content provided by other sites. Please contact the content providers to delete copyright contents if any and email us, we'll remove relevant links or contents immediately.

Tuyên bố miễn trừ bản quyền:

Trang web này không lưu trữ bất kỳ tệp nào trên máy chủ của nó. Chúng tôi chỉ lập chỉ mục và liên kết đến nội dung được cung cấp bởi các trang web khác. Vui lòng liên hệ với các nhà cung cấp nội dung để xóa nội dung bản quyền nếu có và gửi email cho chúng tôi, chúng tôi sẽ xóa các liên kết hoặc nội dung có liên quan ngay lập tức.

Tham khảo các bài viết cùng chủ đề: