Những điều cần và không nên trong nghiên cứu về máy học — đọc đi, những người đam mê

Bạn đã biết Neural đang chiếm sân khấu vào mùa thu này? Cùng với đội ngũ chuyên gia tuyệt vời, chúng tôi sẽ khám phá tương lai của trí tuệ nhân tạo trong TNW Conference 2021. Đảm bảo đặt vé của bạn ngay bây giờ!

Máy học đang trở thành một công cụ quan trọng trong nhiều ngành công nghiệp và lĩnh vực khoa học. Nhưng nghiên cứu và phát triển sản phẩm về ML đặt ra nhiều thách thức, nếu không giải quyết được, có thể đưa dự án của bạn vào hướng sai.

Trong bài báo được xuất bản gần đây trên máy chủ tiền in arXiv, Michael Lones, Giáo sư Bổ nhiệm tại Trường Toán học và Khoa học Máy tính, Đại học Heriot-Watt, Edinburgh, cung cấp một danh sách các điều cần và không nên trong nghiên cứu về máy học.

Bài báo, mà Lones mô tả là “những bài học được rút ra trong quá trình nghiên cứu ML ở môi trường học thuật, và trong quá trình hướng dẫn sinh viên thực hiện nghiên cứu ML,” bao gồm những thách thức ở các giai đoạn khác nhau của chu kỳ nghiên cứu về máy học. Mặc dù được hướng đến các nhà nghiên cứu học thuật, nhưng hướng dẫn của bài báo cũng hữu ích cho những nhà phát triển đang tạo ra mô hình máy học cho các ứng dụng thực tế.

Dưới đây là những điểm mà tôi rút ra từ bài báo, mặc dù tôi khuyến nghị mọi người liên quan đến nghiên cứu và phát triển máy học đọc toàn bộ nó.

Chú ý đặc biệt đến dữ liệu

Mô hình máy học tồn tại và phát triển dựa trên dữ liệu. Do đó, suốt bài báo, Lones nhấn mạnh tầm quan trọng của việc chú ý đặc biệt đến dữ liệu ở mọi giai đoạn của chu kỳ nghiên cứu về máy học. Bạn phải cẩn thận về cách bạn thu thập và chuẩn bị dữ liệu của mình và cách bạn sử dụng nó để huấn luyện và kiểm thử mô hình máy học của bạn.

Không có lượng công suất tính toán và công nghệ tiên tiến nào có thể giúp bạn nếu dữ liệu của bạn không đến từ một nguồn đáng tin cậy và không được thu thập một cách đáng tin cậy. Bạn cũng nên sử dụng sự thận trọng của riêng mình để kiểm tra nguồn gốc và chất lượng của dữ liệu của bạn. “Đừng giả định rằng, vì một bộ dữ liệu đã được sử dụng bởi một số bài báo, nó là chất lượng tốt,” Lones viết.

Bộ dữ liệu của bạn có thể gặp nhiều vấn đề có thể dẫn đến mô hình của bạn học sai điều gì đó.

Ví dụ, nếu bạn đang làm việc trên một vấn đề phân loại và bộ dữ liệu của bạn chứa quá nhiều ví dụ của một lớp và quá ít của lớp khác, thì mô hình máy học đã được huấn luyện có thể học cách dự đoán mọi đầu vào thuộc về lớp mạnh mẽ. Trong trường hợp này, bộ dữ liệu của bạn gặp vấn đề “mất cân bằng lớp.”

Trong khi mất cân bằng lớp có thể được phát hiện nhanh chóng thông qua thực hành khám phá dữ liệu, việc phát hiện các vấn đề khác đòi hỏi sự cẩn trọng và kinh nghiệm bổ sung. Ví dụ, nếu tất cả các hình ảnh trong bộ dữ liệu của bạn được chụp vào ban ngày, thì mô hình máy học của bạn sẽ hoạt động kém trên những bức ảnh tối. Một ví dụ tinh tế hơn là thiết bị được sử dụng để thu thập dữ liệu. Ví dụ, nếu bạn đã chụp tất cả các bức ảnh đào tạo của mình bằng cùng một máy ảnh, mô hình của bạn có thể học cách phát hiện dấu vết thị giác đặc biệt của máy ảnh của bạn và sẽ hoạt động kém trên những hình ảnh được chụp bằng các thiết bị khác. Bộ dữ liệu máy học có thể có tất cả các loại độ chệch như vậy.

Số lượng dữ liệu cũng là một vấn đề quan trọng. Hãy đảm bảo dữ liệu của bạn có đủ. “Nếu tín hiệu mạnh, bạn có thể làm mọi việc chỉ với ít dữ liệu; nếu yếu, bạn cần nhiều dữ liệu hơn,” Lones viết.

Trong một số lĩnh vực, sự thiếu hụt dữ liệu có thể được bù đắp bằng các kỹ thuật như chéo kiểm tra và mở rộng dữ liệu. Nhưng nói chung, bạn nên biết rằng mô hình máy học của bạn càng phức tạp, bạn sẽ cần nhiều dữ liệu đào tạo hơn. Ví dụ, vài trăm ví dụ đào tạo có thể đủ để huấn luyện một mô hình hồi quy đơn giản với vài tham số. Nhưng nếu bạn muốn phát triển một mạng nơ-ron sâu với hàng triệu tham số, bạn sẽ cần nhiều dữ liệu đào tạo hơn.

Một điểm quan trọng khác mà Lones đề cập trong bài báo là cần có sự phân chia mạnh mẽ giữa dữ liệu đào tạo và kiểm thử. Các kỹ sư máy học thường để dành một phần dữ liệu của họ để kiểm thử mô hình đã được đào tạo. Nhưng đôi khi, dữ liệu kiểm thử tràn vào quá trình đào tạo, điều này có thể dẫn đến mô hình máy học không tổng quát hóa được cho dữ liệu được thu thập từ thế giới thực.

“Đừng để dữ liệu kiểm thử tràn vào quá trình đào tạo,” ông cảnh báo. “Điều tốt nhất bạn có thể làm để ngăn chặn những vấn đề này là phân loại một phần của dữ liệu của bạn ngay từ đầu dự án và chỉ sử dụng tập kiểm thử độc lập này một lần để đánh giá sự tổng quát của một mô hình duy nhất ở cuối dự án.”

Trong các tình huống phức tạp hơn, bạn sẽ cần một “tập kiểm thử chứng nhận,” một tập thứ hai để đưa mô hình máy học vào quá trình đánh giá cuối cùng. Ví dụ, nếu bạn đang thực hiện kiểm tra chéo hoặc học bổ sung, tập kiểm thử gốc có thể không cung cấp một đánh giá chính xác về mô hình của bạn. Trong trường hợp này, một tập kiểm thử chứng nhận có thể hữu ích.

“Nếu bạn có đủ dữ liệu, tốt hơn là để một phần sang một bên và chỉ sử dụng nó một lần để đưa ra một ước lượng không thiên vị về phiên bản mô hình cuối cùng được chọn,” Lones viết.

Hiểu rõ mô hình của bạn (cũng như của người khác)

Nhưng khi đối mặt với các vấn đề cụ thể của các mô hình máy học, bạn nên luôn có một danh sách các thuật toán ứng cử để đánh giá. “Nói chung, không có khái niệm về một mô hình ML tốt nhất,” Lones viết. “Trên thực tế, có một bằng chứng cho điều này, dưới dạng định lý No Free Lunch, cho thấy rằng không có phương pháp ML nào tốt hơn bất kỳ phương pháp nào khác khi xem xét trên mọi vấn đề có thể có.”

Điều đầu tiên bạn nên kiểm tra là xem mô hình của bạn có phù hợp với loại vấn đề của bạn không. Ví dụ, dựa trên việc đầu ra dự định của bạn là hạng mục hay liên tục, bạn sẽ cần chọn thuật toán máy học phù hợp cùng với cấu trúc phù hợp. Các loại dữ liệu (ví dụ, dữ liệu bảng, hình ảnh, văn bản không cấu trúc, v.v.) cũng có thể là một yếu tố quyết định trong lớp mô hình bạn sử dụng.

Một điểm quan trọng Lones đề cập trong bài báo của mình là cần tránh sự phức tạp quá mức. Ví dụ, nếu vấn đề của bạn có thể được giải quyết bằng một cây quyết định đơn giản hoặc mô hình hồi quy, không có lý do gì bạn phải sử dụng học sâu.

Lones cũng cảnh báo tránh cố gắng tái tạo lại điều đã được tạo ra. Với máy học là một trong những lĩnh vực nóng nhất của nghiên cứu, luôn có khả năng mạnh mẽ rằng người khác đã giải quyết một vấn đề tương tự như của bạn. Trong trường hợp như vậy, điều khôn ngoan là kiểm tra công việc của họ. Điều này có thể tiết kiệm rất nhiều thời gian vì các nhà nghiên cứu khác đã đối mặt và giải quyết những thách thức mà bạn có thể gặp sau này.

“Bỏ qua các nghiên cứu trước đó là có thể bỏ lỡ thông tin quý báu,” Lones viết.

Nghiên cứu các bài báo và công việc của các nhà nghiên cứu khác cũng có thể cung cấp cho bạn các mô hình máy học mà bạn có thể sử dụng lại cho vấn đề của mình. Trên thực tế, các nhà nghiên cứu máy học thường sử dụng mô hình của nhau để tiết kiệm thời gian và tài nguyên tính toán và bắt đầu với một cơ sở được tin tưởng bởi cộng đồng ML.

“Quan trọng là tránh ‘hội chứng chưa được phát minh ở đây’, tức là chỉ sử dụng các mô hình đã được phát minh tại tổ chức của bạn, vì điều này có thể khiến bạn bỏ qua mô hình tốt nhất cho một vấn đề cụ thể,” Lones cảnh báo.

Hiểu rõ mục tiêu cuối cùng và các yêu cầu của nó

“[Đối với] nhiều nghiên cứu học thuật, mục tiêu cuối cùng là tạo ra một mô hình ML có thể triển khai trong tình huống thực tế. Nếu đúng vậy, thì đáng đầu tư thời gian suy nghĩ sớm về cách triển khai nó,” Lones viết.

Ví dụ, nếu mô hình của bạn sẽ được sử dụng trong một ứng dụng chạy trên thiết bị người dùng và không phải trên các cụm máy chủ lớn, thì bạn không thể sử dụng các mạng neural lớn yêu cầu lượng bộ nhớ và không gian lưu trữ lớn. Bạn phải thiết kế các mô hình máy học có thể hoạt động trong môi trường có tài nguyên hạn chế.

Một vấn đề khác mà bạn có thể đối mặt là nhu cầu về khả năng giải thích. Ở một số lĩnh vực như tài chính và chăm sóc sức khỏe, nhà phát triển ứng dụng bị yêu cầu theo luật pháp cung cấp giải thích về quyết định thuật toán nếu người dùng yêu cầu. Trong những trường hợp như vậy, việc sử dụng một mô hình hộp đen có thể là không thể. Ví dụ, ngay cả khi mạng neural sâu có thể mang lại lợi thế về hiệu suất, sự thiếu khả năng giải thích của nó có thể làm cho nó trở nên vô dụng. Thay vào đó, một mô hình minh bạch hơn như một cây quyết định có thể là lựa chọn tốt hơn ngay cả khi nó dẫn đến sự suy giảm hiệu suất. Hoặc nếu học sâu là một yêu cầu tuyệt đối cho ứng dụng của bạn, thì bạn cần nghiên cứu các kỹ thuật có thể cung cấp diễn giải đáng tin cậy về các kích hoạt trong mạng neural.

Là một kỹ sư máy học, bạn có thể không có kiến thức chính xác về yêu cầu của mô hình của mình. Do đó, việc trò chuyện với các chuyên gia ngành là quan trọng vì họ có thể giúp bạn hướng dẫn bạn đúng hướng và xác định liệu bạn đang giải quyết một vấn đề liên quan hay không.

“Bỏ qua ý kiến ​​của các chuyên gia ngành có thể dẫn đến các dự án không giải quyết được vấn đề hữu ích hoặc giải quyết vấn đề hữu ích một cách không thích hợp,” Lones viết.

Ví dụ, nếu bạn tạo ra một mạng neural nhận diện giao dịch ngân hàng gian lận với độ chính xác rất cao nhưng không cung cấp giải thích cho quyết định của nó, thì các tổ chức tài chính sẽ không thể sử dụng nó.

Biết cần đo lường và báo cáo điều gì

Ví dụ, nhiều kỹ sư ML sử dụng “kiểm tra độ chính xác” để đánh giá mô hình của họ. Kiểm tra độ chính xác đo lường phần trăm dự đoán đúng mà mô hình thực hiện. Con số này có thể là mơ hồ trong một số trường hợp.

Ví dụ, hãy xem xét một bộ dữ liệu về các ảnh X-quang được sử dụng để huấn luyện một mô hình máy học để phát hiện ung thư. Dữ liệu của bạn không cân bằng, với 90 phần trăm các ví dụ huấn luyện được đánh dấu là lành tính và một số rất nhỏ được phân loại là ác tính. Nếu mô hình đã được đào tạo của bạn đạt điểm 90 trên bài kiểm tra độ chính xác, có thể nó chỉ học cách đặt nhãn cho mọi thứ là lành tính. Nếu được sử dụng trong một ứng dụng thực tế, mô hình này có thể dẫn đến những trường hợp bị bỏ lỡ với hậu quả thảm khốc. Trong trường hợp như vậy, đội ngũ ML phải sử dụng các kiểm tra không nhạy cảm đối với sự mất cân bằng lớp hoặc sử dụng ma trận nhầm lẫn để kiểm tra các chỉ số khác. Các kỹ thuật gần đây hơn có thể cung cấp một đo lường chi tiết về hiệu suất của mô hình trong nhiều lĩnh vực.

Dựa trên ứng dụng, nhà phát triển ML cũng có thể muốn đo lường một số chỉ số khác nhau. Trong ví dụ phát hiện ung thư, có thể quan trọng là giảm thiểu số âm giả mạo càng nhiều càng tốt, ngay cả nếu đó làm giảm độ chính xác hoặc tăng một chút số dương giả mạo. Tốt hơn là gửi một số người lành tính đến bệnh viện để chẩn đoán hơn là bỏ lỡ bệnh nhân ung thư quan trọng.

Trong bài viết của mình, Lones cảnh báo rằng khi so sánh nhiều mô hình máy học cho một vấn đề, đừng cho rằng những con số lớn không nhất thiết có nghĩa là mô hình tốt hơn. Ví dụ, sự khác biệt về hiệu suất có thể do mô hình của bạn được đào tạo và kiểm tra trên các phân đoạn khác nhau của bộ dữ liệu của bạn hoặc trên các bộ dữ liệu hoàn toàn khác nhau.

“Để thực sự chắc chắn về một so sánh công bằng giữa hai phương pháp, bạn nên triển khai lại tất cả các mô hình bạn đang so sánh, tối ưu hóa từng mô hình với cùng một mức độ, thực hiện nhiều đánh giá… và sau đó sử dụng các kiểm tra thống kê… để xác định liệu sự khác biệt về hiệu suất có ý nghĩa hay không,” Lones viết.

Lones cũng cảnh báo không nên đánh giá quá mức khả năng của mô hình trong báo cáo của bạn. “Một sai lầm phổ biến là đưa ra các tuyên bố tổng quát không được hỗ trợ bằng dữ liệu được sử dụng để đào tạo và đánh giá các mô hình,” ông viết.

Do đó, bất kỳ báo cáo nào về hiệu suất của mô hình của bạn cũng phải bao gồm loại dữ liệu nó được đào tạo và kiểm tra. Việc xác nhận mô hình của bạn trên nhiều bộ dữ liệu có thể cung cấp một cái nhìn hiệu quả hơn về khả năng của nó, nhưng bạn vẫn nên cẩn trọng với loại lỗi dữ liệu mà chúng ta đã thảo luận trước đó.

Cuối cùng, thách thức tích hợp sẽ là một phần quan trọng của mọi dự án máy học ứng dụng. Làm thế nào hệ thống máy học của bạn sẽ tương tác với các ứng dụng khác đang chạy trong tổ chức của bạn? Hệ thống cơ sở dữ liệu của bạn đã sẵn sàng để kết nối vào đường ống máy học chưa? Hệ thống đám mây hoặc cơ sở hạ tầng máy chủ của bạn có hỗ trợ triển khai và mở rộng mô hình của bạn không? Những loại câu hỏi này có thể quyết định sự triển khai của một sản phẩm ML.

Ví dụ, gần đây, lab nghiên cứu AI OpenAI đã tung ra phiên bản thử nghiệm của mô hình Codex API của họ để đánh giá công khai. Nhưng việc họ phát hành thất bại vì máy chủ của họ không thể mở rộng đến nhu cầu người dùng.

Hy vọng, bài viết ngắn này sẽ giúp bạn đánh giá tốt hơn dự án máy học của mình và tránh những sai lầm. Đọc bài báo đầy đủ của Lones, có tiêu đề là “Làm thế nào để tránh những rủi ro của máy học: hướng dẫn cho nhà nghiên cứu học thuật,” để biết thêm chi tiết về những sai lầm phổ biến trong quá trình nghiên cứu và phát triển ML.

Bài viết này được xuất bản ban đầu bởi Ben Dickson trên TechTalks, một tờ báo nghiên cứu xu hướng công nghệ, cách chúng ảnh hưởng đến cuộc sống và kinh doanh của chúng ta, cũng như các vấn đề mà chúng giải quyết. Nhưng chúng tôi cũng thảo luận về mặt tối của công nghệ, những hậu quả tối tăm của công nghệ mới, và những điều chúng ta cần phải chú ý. Bạn có thể đọc bài viết gốc tại đây.