Các nhà nghiên cứu hiếm khi phàn nàn về việc thiếu hụt phần mềm. Nếu có, họ lại đang đối mặt với vấn đề ngược lại: quá nhiều thứ rời rạc

Các nhà nghiên cứu hiếm khi phàn nàn về việc thiếu hụt phần mềm. Nếu có, họ thường đối mặt với vấn đề ngược lại: quá nhiều công cụ rời rạc được chắp vá bằng các script shell và sự hy vọng. Một dự án mã nguồn mở mới có tên OpenScience muốn thay thế sự chắp vá đó bằng một môi trường làm việc AI (AI workbench) duy nhất được thiết kế dành riêng cho khám phá khoa học. Được xây dựng bằng TypeScript và đã thu hút hơn 2.167 sao trên GitHub, dự án hướng tới việc cung cấp cho các phòng thí nghiệm một môi trường chung, nơi trí tuệ nhân tạo giúp tự động hóa quy trình làm việc, quản lý dữ liệu thực nghiệm và giữ cho các cộng tác viên luôn thống nhất. Tham vọng này rất rõ ràng. Liệu nó có thể tồn tại trước thực tế của việc bảo trì mã nguồn mở và sự cạnh tranh khốc liệt hay không lại là một câu hỏi khác.

Tại sao nghiên cứu cần một môi trường làm việc riêng

Tiến bộ khoa học phụ thuộc vào khả năng tái lập (reproducibility). Một kết quả sẽ trở nên vô nghĩa nếu một nhóm khác không thể chạy cùng một phân tích và đưa ra cùng một kết luận. Tuy nhiên, các quy trình (pipeline) học máy hiện đại nổi tiếng là lộn xộn. Các bước tiền xử lý bị ẩn giấu bên trong các ô (cell) Jupyter nằm rải rác. Các siêu tham số (hyperparameters) được viết cứng vào các script không có tài liệu hướng dẫn. Các tập dữ liệu bị sao chép, đổi tên và thất lạc trên các ổ đĩa dùng chung. Khi một nghiên cứu sinh tốt nghiệp và rời đi, quy trình làm việc của họ thường "đi theo" họ luôn.

OpenScience nhằm mục đích tấn công trực tiếp vào sự hỗn loạn đó. Bằng cách cung cấp một nền tảng thống nhất thay vì một tập hợp các thư viện rời rạc, dự án hy vọng sẽ thực thi tính nhất quán trong cách thiết lập, theo dõi và chia sẻ các thí nghiệm. Sự cộng tác là trọng tâm của dự án này. Thay vì gửi mã nguồn qua lại bằng email hoặc vật lộn với việc kiểm soát phiên bản (version control), các nhà nghiên cứu sẽ làm việc trong một môi trường chung, nơi ghi lại ai đã thay đổi cái gì và khi nào. Đối với các lĩnh vực mà một thí nghiệm duy nhất có thể tiêu tốn nhiều tuần tính toán, sự minh bạch đó không phải là một thứ xa xỉ. Đó là một sự tất yếu.

Đặt cược vào TypeScript cho mã nguồn khoa học

Việc lựa chọn xây dựng dự án này bằng TypeScript là một điều bất ngờ. Học máy chạy trên Python. Chấm hết. TensorFlow, PyTorch và đại đa số các kho mã nguồn nghiên cứu đều được viết bằng Python. Các nhà khoa học thường viết script bằng Python hoặc R, và nhiều người chỉ biết đủ JavaScript để tinh chỉnh một bản trực quan hóa web. Vậy tại sao lại là TypeScript?

Đội ngũ phát triển lập luận rằng kiểu tĩnh (static typing) giúp mã nguồn được tổ chức ngăn nắp và đáng tin cậy. Trong công việc khoa học, một lỗi kiểu dữ liệu âm thầm có thể làm mất hiệu lực nhiều tháng làm việc trong phòng thí nghiệm. TypeScript phát hiện toàn bộ các lớp lỗi ngay tại thời điểm biên dịch (compile time) thay vì để chúng bùng phát bên trong một tác vụ huấn luyện đang chạy dài. Đối với một nền tảng muốn đảm bảo khả năng tái lập, sự nghiêm ngặt đó rất hấp dẫn.

Tuy nhiên, luôn có những sự đánh đổi thực tế. TypeScript thu hút các nhà phát triển coi trọng các công cụ chuyên nghiệp, nhưng nó có thể gây xa lánh chính những nhà nghiên cứu mà OpenScience hy vọng sẽ phục vụ. Một nhà sinh học vốn chỉ học JavaScript cơ bản để định dạng dữ liệu khảo sát giờ đây phải vật lộn với interfaces, generics và một quy trình build. Lộ trình học tập là rất dốc. Nếu nền tảng buộc mọi người dùng phải trở thành một kỹ sư phần mềm trước khi họ có thể huấn luyện một mô hình, việc áp dụng sẽ bị đình trệ. Sự đặt cược ở đây là lợi ích lâu dài về tính ổn định sẽ lớn hơn những khó khăn ngắn hạn trong việc tiếp cận ban đầu.

Những gì OpenScience hứa hẹn

Dự án muốn đơn giản hóa hai tác vụ hiện đang tiêu tốn rất nhiều năng lượng trí tuệ: huấn luyện mô hình và theo dõi thí nghiệm. Thay vì yêu cầu các nhà nghiên cứu phải kết nối nửa tá tiện ích dòng lệnh lại với nhau, OpenScience dự định cung cấp một giao diện gắn kết. Nó cũng có ý định tích hợp với các "ông lớn" trong lĩnh vực này, cụ thể là TensorFlow và PyTorch, để các nhà khoa học không phải từ bỏ các thư viện quen thuộc.

Bản thân AI được kỳ vọng sẽ đảm nhận một số phần việc nặng nhọc. Môi trường làm việc này hướng tới việc tự động hóa các quy trình làm việc lặp đi lặp lại. Hãy tưởng tượng về các quy trình làm sạch dữ liệu được tạo tự động, các gợi ý thông minh cho siêu tham số dựa trên các lần chạy trước đó, hoặc việc ghi nhật ký tự động để ghi lại chính xác phiên bản nào của tập dữ liệu đã tạo ra một kết quả nhất định. Nếu tầm nhìn đó trở thành hiện thực, nó có thể giải phóng các nhà nghiên cứu để họ tập trung vào các giả thuyết thay vì cơ sở hạ tầng.

Rủi ro từ sự phình to của việc tích hợp

Mỗi sự tích hợp được lên kế hoạch đều là một lời hứa đòi hỏi phải được bảo trì. TensorFlow và PyTorch thường xuyên cập nhật. Một thay đổi gây lỗi (breaking change) duy nhất trong một phụ thuộc cốt lõi có thể gây ra hiệu ứng dây chuyền qua các lớp trừu tượng của OpenScience và khiến người dùng phải đối mặt với các stack trace khó hiểu thay vì chạy các thí nghiệm. Càng nhiều thư viện đồng nghĩa với việc càng nhiều bản vá bảo mật, nhiều xung đột phiên bản và nhiều cơ hội để nền tảng bị mất đồng bộ với các công cụ mà nó có nhiệm vụ phục vụ.

Độ phức tạp khi cài đặt là kẻ sát nhân thầm lặng của các phần mềm nghiên cứu. Nếu việc cài đặt OpenScience đòi hỏi phải vật lộn với các trình điều khiển CUDA, các phiên bản Node.js cụ thể và các môi trường Python xung đột lẫn nhau, các nghiên cứu sinh bận rộn sẽ chỉ đơn giản là mở một tab Google Colab nơi môi trường thực thi đã được cấu hình sẵn. Nghiên cứu diễn ra trong những mốc thời gian eo hẹp. Không ai có thể có được một bài báo khoa học bằng cách dành ba tuần để gỡ lỗi một bộ công cụ.

Các nhà phát triển dường như nhận thức được sự mâu thuẫn này. Thách thức của họ là cung cấp đủ sức mạnh để hữu ích mà không trở nên quá nặng nề khiến công cụ tự sụp đổ dưới sức nặng của chính nó.

Tính bền vững trong thế giới mã nguồn mở

Phần mềm mã nguồn mở đã phổ cập hóa mọi thứ, từ phát triển web đến phân tích dữ liệu. Bất kỳ ai cũng có thể kiểm tra mã nguồn, đóng góp bản sửa lỗi hoặc fork dự án cho một trường hợp sử dụng chuyên biệt. Sự cởi mở đó hoạt động tốt khi một cộng đồng lớn các chuyên gia được trả lương dựa vào mã nguồn cho công việc hàng ngày của họ.

Các công cụ mã nguồn mở khoa học đối mặt với một thực tế khác. 2.167 ngôi sao trên GitHub trông có vẻ đầy hứa hẹn, nhưng các ngôi sao không nuôi sống những người duy trì dự án. Các chu kỳ cấp vốn kết thúc. Các nghiên cứu sinh tốt nghiệp và chuyển đi. Nếu không có sự hỗ trợ định chế ổn định hoặc một đội ngũ nòng cốt tận tâm, ngay cả những dự án xuất sắc cũng sẽ trở nên xơ cứng. Kho lưu trữ nằm im trong một năm, các thư viện phụ thuộc bị lỗi thời, và những người dùng sớm phải đối mặt với những đoạn mã bị bỏ rơi không còn khả năng biên dịch trên các phần cứng hiện đại. Đối với một nền tảng muốn lưu trữ khoa học có khả năng tái lập, sự bỏ rơi còn tồi tệ hơn cả việc chưa từng tồn tại. OpenScience cần sự hỗ trợ lâu dài từ các trường đại học, phòng thí nghiệm hoặc các tổ chức tài trợ nếu muốn tồn tại lâu hơn những dòng tiêu đề báo chí.

Cạnh tranh với Jupyter, Colab và MATLAB

OpenScience đang bước vào một môi trường đầy cạnh tranh. Jupyter Notebooks là công cụ thử nghiệm mặc định cho nghiên cứu khám phá bằng Python. Google Colab đã loại bỏ rào cản phần cứng bằng cách cung cấp GPU miễn phí ngay trong một tab trình duyệt. MATLAB vẫn thống trị các khoa kỹ thuật, nơi coi trọng các bộ công cụ được bảo hành và kiến thức chuyên môn tích lũy qua nhiều thập kỷ.

Để thu hút người dùng rời khỏi các công cụ đã định hình này, OpenScience phải cung cấp thứ mà họ không có. Có thể đó là sự cộng tác đa người dùng thực thụ mà không gặp phải độ trễ của các notebook dùng chung. Có thể đó là một cấu trúc quản trị nơi các nhà khoa học, chứ không chỉ các nhà phát triển phần mềm, dẫn dắt lộ trình phát triển. Hoặc có lẽ đó là mức độ phiên bản hóa thí nghiệm giúp việc tái lập trở nên tự động thay vì là một bước bổ sung sau cùng.

Dù điểm khác biệt là gì, công cụ phải luôn dễ tiếp cận. Nếu nó đòi hỏi các máy trạm cục bộ cấu hình cao hoặc mặc định rằng mọi người dùng đều thành thạo việc chạy một máy chủ phát triển, nó sẽ không bao giờ thoát khỏi trang xu hướng của GitHub. Các nhà nghiên cứu tối ưu hóa để tìm ra câu trả lời, chứ không phải để cấu hình phần mềm.

Thử thách thực sự: Quản trị quan trọng hơn Mã nguồn

TypeScript sạch và một danh sách tính năng đầy tham vọng cũng chỉ giúp dự án tiến xa được một chặng đường nhất định. Lịch sử của phần mềm khoa học đầy rẫy những mã nguồn đẹp đẽ nhưng thất bại vì chúng được xây dựng bởi các nhà phát triển dành cho các nhà phát triển. Một nhà khoa học thực nghiệm không cần một giao diện người dùng hào nhoáng nếu trình nhập CSV bị lỗi khi xử lý dữ liệu thực tế. Họ cần những công cụ tôn trọng quá trình nghiên cứu thực tế: kết nối internet chập chờn tại các trạm thực địa, các định dạng tệp lộn xộn từ các thiết bị cũ, và yêu cầu tuyệt đối phải chứng minh chính xác đoạn mã nào đã tạo ra hình ảnh nào cho một người phản biện khắt khe.

Thành công phụ thuộc vào quản trị cộng đồng. Các nghiên cứu viên chính, quản lý phòng thí nghiệm và nghiên cứu sinh cần có tiếng nói thực sự trong việc quyết định những gì sẽ được xây dựng. OpenScience phải tiếp cận các nhà khoa học tại nơi họ đang làm việc, chứ không phải tại nơi mà các nhà phát triển mặc định họ nên ở đó.

Điểm mấu chốt

OpenScience là một thử nghiệm thực sự thú vị. Nó áp dụng tính nghiêm ngặt của kỹ thuật phần mềm có kiểu dữ liệu vào thế giới khám phá khoa học đầy lộn xộn và lặp đi lặp lại. Sự kết hợp đó rất hiếm thấy trong một lĩnh vực bị thống trị bởi các tập lệnh Python nhanh chóng. Nhưng các lựa chọn kỹ thuật luôn đi kèm rủi ro, sự cạnh tranh rất khốc liệt, và con đường từ những ngôi sao GitHub đến một cơ sở hạ tầng bền vững là rất gian nan. Mã nguồn đã mở. Các ngôi sao đang tích lũy. Thách thức thực sự hiện nay là xây dựng