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 research.

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êu cứu và phải hoàn thành bằng 1, 2 submission 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 machine learning 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 waterfall 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 research, 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 deadline, 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à finetune.

Đôi khi đời không như mơ (Nguồn: http://amid.fish/reproducing-deep-rl)

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 brainstorm. Trong trường hợp phải làm remote, 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 channel khác nhau với từng task, model, conference khác nhau. Điểm mạnh của Paper Dropbox ở chỗ hỗ trợ comment, minh họa trên hình, và render 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 để finetune. Bởi theo quan điểm của mình, finetuning model là một việc siêu chán, rất mệtdễ 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 để finetune giúp ta ko quá sa đà vào việc cắm mắt lên màn hình finetune, 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 finetune 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à textbooks, arxiv-sanity, Google Scholar [với chế độ recommendation], reddit (/r/MachineLearning, /r/compsci, /r/compvision), twitter [Follow các giáo sư đầu ngành, các conference hay mấy con bot trên reddit]).

Công đoạn cuối: viết paper có thể đổi tên thành “ghi chú, nhật ký”. Bằng cách sử dụng overleaf, 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ả paper. Trong khi Paper Dropbox phục vụ cho việc ghi chú tào lao [làm thế nào finetune model, những idea lạ hay những thứ mình không muốn đưa vào paper] thì overleaf là nơi ghi chú theo chính quy với các viết formal và được coi như mình đang viết 1 paper 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 submit 1 conference nào thì hầu như toàn bộ nội dung đã có sẵn, chỉ cần việc apply style của conference đó, đồng thời revise, proofread lại nội dung paper.

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à workstation của lab.

Về software:

  • NeoVim: mình không thích dùng IDE. Và vim rất tiện khi phải edit file remote, 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 config 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 input của hệ thống, mình có thể điều khiển 2 workstations và 1 laptop chỉ với 1 bộ keyboard và mouse.
  • Mobaxterm: ssh trên Windows.
  • LogMeIn: remote máy tính.
  • Google Chrome Remote: remote máy tính có giao diện.
  • Git: version control. Github để share code, tuy nhiên nếu muốn private 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]

comments powered by Disqus