Làm nghiên cứu theo phong cách Agile

Bài viết xoay quanh một số mẹo vặt về làm nghiên cứu trong Khoa Học Máy Tính (KHMT), đặc biệt là hướng Machine Learning của một thanh niên mới tập tành làm re­search.

Lên kế hoạch

Không giống như PhD khi học có kha khá nhiều thời gian để tìm hiểu bài toán nghiên cứu, thông thường nhóm mình chỉ có 2 – 3 tháng để tập trung cho 1 nghiên cứu và phải hoàn thành bằng 1, 2 sub­mis­sion và các hội nghị. Dĩ nhiên, sau đó các công trình này có thể được mở rộng và nộp cho các tạp chí, công đoạn này nếu làm liền mạch thì có thể mất thêm 1, 2 tháng nữa. Bởi vậy, điều quan trọng là phân phối thời gian giữa các công việc, theo mình việc làm nghiên cứu theo hướng ma­chine learn­ing gồm 3 công đoạn chính:

• Lên ý tưởng, đề xuất model và phương pháp giải.
• Cài đặt và chạy thí nghiệm.
• Viết bài báo, dọn dẹp code và đăng tải.

Nếu như theo phương pháp wa­ter­fall trong công nghệ phần mềm, thì mỗi công đoạn được thực hiện riêng lẽ và tách biệt nhau. Tuy nhiên điều đó chỉ xuất hiện khi ta đề xuất được một model “lý tưởng”: chạy tốt trên các tập dữ liệu và hầu như không có trở ngại gì khi cài đặt. Điều này không phải lúc nào cũng có thể đạt được. Ví dụ, đôi khi dữ liệu chạy rất tốt trên MNIST hay Cifar10, nhưng lại chạy rất tệ trên SUN397. Điều đó khiến ta phải quay lại bước đầu tiên để xem xét lại model, bởi có lẽ nguyên nhân là do model không chạy tốt cho tập dữ liệu lớn và ta cần xây dựng một model mới tốt hơn.

Vì vậy, đề xuất của mình đó là tận dụng Agile trong re­search, 3 công đoạn có thể thực hiện trong 5 ngày rồi sau đó lặp lại liên tục cho đến khi “hội tụ” (đến dead­line, hết idea để làm model, …):

• 1 – 2 ngày lên model.
• 1 – 2 ngày cài đặt.
• 1 ngày chạy thí nghiệm và fine­tune.

Việc lên model là team-work. Công cụ tốt nhất đó là bảng, 1 phòng họp và liên tục brain­storm. Trong trường hợp phải làm re­mote, thì Slack và Paper Dropbox là 2 phương tiện rất tốt để ghi chú và trao đổi. Trên Slack ta có thể chia thành các chan­nel khác nhau với từng task, model, con­fer­ence khác nhau. Điểm mạnh của Paper Dropbox ở chỗ hỗ trợ com­ment, minh họa trên hình, và ren­der công thức bằng Latex rất tốt.

Điều mình nhấn mạnh đó là chỉ nên dành 1 ngày để fine­tune. Bởi theo quan điểm của mình, fine­tun­ing model là một việc siêu chán, rất mệt và dễ làm tụt cảm xúc của người làm nghiên cứu. Giới hạn bản thân 1 ngày để fine­tune giúp ta ko quá sa đà vào việc cắm mắt lên màn hình fine­tune, hoặc phải đặt nải chuối cúng ông địa để mong có kết quả tốt. Việc giới hạn về thời gian còn giúp ta đề xuất ra được nhiều phương pháp đánh giá model nhanh hơn, có bộ tham số chuẩn và không fine­tune nhưng tham số quá tào lao.

Trong khoảng thời gian xen lẫn các công đoạn, ta có thể cập nhật các bài báo mới, học các kỹ thuật mới hoặc tìm hiểu kỹ hơn về bài toán mình đang làm. Công cụ tốt nhất cho giai đoạn này chính là text­books, arxiv-san­ity, Google Scholar (với chế độ rec­om­men­da­tion), red­dit (/r/MachineLearning, /r/compsci, /r/compvision), twit­ter (Follow các giáo sư đầu ngành, các con­fer­ence hay mấy con bot trên red­dit).

Công đoạn cuối: viết pa­per có thể đổi tên thành “ghi chú, nhật ký”. Bằng cách sử dụng over­leaf, và liên tục cập nhật tiến độ, công thức, model thông qua Latex, ta hầu như có được nội dung cho cả pa­per. Trong khi Paper Dropbox phục vụ cho việc ghi chú tào lao (làm thế nào fine­tune model, những idea lạ hay những thứ mình không muốn đưa vào pa­per) thì over­leaf là nơi ghi chú theo chính quy với các viết for­mal và được coi như mình đang viết 1 pa­per thực sự. Dĩ nhiên, một bước tiến hóa của phương pháp này Literate Programming, mà hiện nay Jupyter là một ví dụ tiêu biểu. Đến khi cần phải sub­mit 1 con­fer­ence nào thì hầu như toàn bộ nội dung đã có sẵn, chỉ cần việc ap­ply style của con­fer­ence đó, đồng thời re­vise, proof­read lại nội dung pa­per.

Cài đặt môi trường

Mỗi người có một môi trường cài đặt khác nhau, trong khi đó setup của mình bao gồm:

• Keyboard: Code Keyboard, thiết kế bởi Jeff Atwood, founder của StackOverflow.
• Mouse: MX Master.
• Màn hình và work­sta­tion của lab.

Về soft­ware:

• NeoVim: mình không thích dùng IDE. Và vim rất tiện khi phải edit file re­mote, dường như mình không gặp trở ngại khi ssh và edit file, trừ mỗi chuyện đường truyền chậm. Ngoài ra việc lưu các con­fig hệ thống trên git/​github giúp thống nhất cài đặt giữa các máy với nhau.
• Synergy: thống nhất in­put của hệ thống, mình có thể điều khiển 2 work­sta­tions và 1 lap­top chỉ với 1 bộ key­board và mouse.
• Mobaxterm: ssh trên Windows.
• LogMeIn: re­mote máy tính.
• Google Chrome Remote: re­mote máy tính có giao diện.
• Git: ver­sion con­trol. Github để share code, tuy nhiên nếu muốn pri­vate thì GitLab có vẻ tiện hơn, tuy nhiên GitLab lại có nhiều tính năng hơi thừa.

(Một bài tạp nham sau khi nộp xong NIPS, tự hứa với lòng không viết thêm bài tạp nham như thế này nữa)