นักวิจัยไม่ค่อยบ่นเรื่องการขาดแคลนซอฟต์แวร์ หากจะมีปัญหา พวกเขาก็มักจะเจอในทางตรงกันข้าม นั่นคือการมีเครื่องมือที่กระจัดกระจายมากเกินไป ซึ่งถูกนำมาเชื่อมต่อกันด้วย shell scripts และความหวัง โปรเจกต์ open-source ใหม่ที่ชื่อว่า OpenScience ต้องการจะแทนที่การทำงานแบบปะติดปะต่อนี้ด้วยเวิร์กเบนช์ AI หนึ่งเดียวที่ออกแบบมาเพื่อการค้นพบทางวิทยาศาสตร์โดยเฉพาะ โปรเจกต์นี้สร้างด้วย TypeScript และมียอดดาว GitHub มากกว่า 2,167 stars แล้ว โดยมีความมุ่งหมายที่จะมอบสภาพแวดล้อมการทำงานร่วมกันให้กับห้องปฏิบัติการ ซึ่งปัญญาประดิษฐ์จะเข้ามาช่วยจัดการเวิร์กโฟลว์โดยอัตโนมัติ จัดการข้อมูลการทดลอง และช่วยให้ผู้ร่วมงานทำงานไปในทิศทางเดียวกัน ความทะเยอทะยานนี้ชัดเจน แต่การที่มันจะสามารถอยู่รอดท่ามกลางความเป็นจริงของการดูแลรักษาซอฟต์แวร์แบบ open-source และการแข่งขันที่รุนแรงได้หรือไม่นั้น ยังเป็นอีกคำถามหนึ่ง
ทำไมงานวิจัยจึงต้องการเวิร์กเบนช์เป็นของตัวเอง
ความก้าวหน้าทางวิทยาศาสตร์ขึ้นอยู่กับความสามารถในการทำซ้ำ (reproducibility) ผลลัพธ์จะไม่มีความหมายเลยหากทีมอื่นไม่สามารถรันการวิเคราะห์แบบเดียวกันและได้ข้อสรุปแบบเดียวกันได้ แต่ทว่า pipeline ของ machine learning ในปัจจุบันกลับมีความวุ่นวายอย่างมาก ขั้นตอนการเตรียมข้อมูล (preprocessing) มักซ่อนอยู่ใน Jupyter cells ที่กระจัดกระจาย ค่า hyperparameters ถูกเขียนแบบ hard-coded ลงในสคริปต์ที่ไม่มีเอกสารกำกับ ชุดข้อมูลถูกคัดลอก เปลี่ยนชื่อ และสูญหายไปตามไดรฟ์ที่ใช้ร่วมกัน เมื่อนักศึกษาบัณฑิตศึกษาจบการศึกษาไป เวิร์กโฟลว์ของพวกเขามักจะหายไปพร้อมกับตัวพวกเขาด้วย
OpenScience มุ่งเป้าที่จะจัดการกับความวุ่นวายนั้นโดยตรง ด้วยการนำเสนอแพลตฟอร์มที่เป็นหนึ่งเดียวแทนที่จะเป็นเพียงการรวบรวมไลบรารีที่กระจัดกระจาย มันจึงหวังที่จะสร้างความสม่ำเสมอในวิธีการตั้งค่า ติดตาม และแบ่งปันการทดลอง การทำงานร่วมกันคือหัวใจสำคัญของแนวคิดนี้ แทนที่จะต้องส่งโค้ดไปมาทางอีเมลหรือต้องต่อสู้กับการทำ version control นักวิจัยจะสามารถทำงานภายในสภาพแวดล้อมร่วมกันที่บันทึกไว้ว่าใครเปลี่ยนอะไรและเมื่อใด สำหรับสาขาที่การทดลองเพียงครั้งเดียวอาจต้องใช้เวลาคำนวณนานหลายสัปดาห์ ความโปร่งใสในลักษณะนี้ไม่ใช่ความหรูหรา แต่มันคือความจำเป็น
การเดิมพันด้วย TypeScript สำหรับโค้ดทางวิทยาศาสตร์
การเลือกสร้างสิ่งนี้ด้วย TypeScript เป็นเรื่องที่เหนือความคาดหมาย เพราะ machine learning ทำงานบน Python เท่านั้น ไม่ว่าอย่างไรก็ตาม ทั้ง TensorFlow, PyTorch และฐานโค้ดการวิจัยส่วนใหญ่ล้วนเขียนด้วย Python นักวิทยาศาสตร์มักจะเขียนสคริปต์ด้วย Python หรือ R และหลายคนรู้จัก JavaScript เพียงแค่พอจะปรับแต่งการแสดงผลข้อมูลบนเว็บได้เท่านั้น แล้วทำไมต้องเป็น TypeScript?
ทีมพัฒนาให้เหตุผลว่า static typing ช่วยให้โค้ดเป็นระเบียบและเชื่อถือได้ ในงานทางวิทยาศาสตร์ ข้อผิดพลาดด้าน type ที่ไม่แจ้งเตือน (silent type error) เพียงจุดเดียวอาจทำให้งานในห้องแล็บที่ทำมาหลายเดือนกลายเป็นโมฆะ TypeScript สามารถตรวจจับข้อผิดพลาดได้ทั้งกลุ่มตั้งแต่ขั้นตอน compile time แทนที่จะปล่อยให้มันระเบิดออกมาในระหว่างการรันงาน training ที่ใช้เวลานาน สำหรับแพลตฟอร์มที่ต้องการรับประกันความสามารถในการทำซ้ำ ความเข้มงวดเช่นนี้จึงเป็นสิ่งที่น่าดึงดูด
อย่างไรก็ตาม มันก็มีข้อแลกเปลี่ยนที่แท้จริง TypeScript ดึงดูดนักพัฒนาที่ให้ความสำคัญกับเครื่องมือระดับมืออาชีพ แต่ก็อาจทำให้เหล่านักวิจัยที่ OpenScience ตั้งใจจะให้บริการนั้นรู้สึกแปลกแยก นักชีววิทยาที่เคยเรียนรู้ JavaScript พื้นฐานเพื่อจัดรูปแบบข้อมูลแบบสำรวจ อาจต้องมาเผชิญกับ interfaces, generics และ build pipeline ซึ่งมีเส้นทางการเรียนรู้ (learning curve) ที่สูงชัน หากแพลตฟอร์มบังคับให้ผู้ใช้ทุกคนต้องกลายเป็นวิศวกรซอฟต์แวร์ก่อนที่จะสามารถฝึกโมเดลได้ การนำไปใช้งานก็จะหยุดชะงัก การเดิมพันครั้งนี้คือ ผลตอบแทนในด้านความเสถียรในระยะยาวจะคุ้มค่ากว่าความยุ่งยากในการเริ่มต้นใช้งานในระยะสั้น
สิ่งที่ OpenScience สัญญาไว้
โปรเจกต์นี้ต้องการลดความซับซ้อนของสองงานที่ปัจจุบันต้องใช้พลังสมองอย่างมหาศาล นั่นคือการฝึกโมเดล (model training) และการติดตามการทดลอง (experiment tracking) แทนที่จะให้นักวิจัยต้องนำเครื่องมือ command-line หลายตัวมาเชื่อมต่อกันเอง OpenScience วางแผนที่จะนำเสนออินเทอร์เฟซที่สอดประสานกัน นอกจากนี้ยังตั้งใจที่จะรวมเข้ากับเครื่องมือหลักในสาขานี้ โดยเฉพาะ TensorFlow และ PyTorch เพื่อให้นักวิทยาศาสตร์ไม่ต้องละทิ้งไลบรารีที่คุ้นเคย
ตัว AI เองจะเข้ามาช่วยรับภาระงานหนัก เวิร์กเบนช์นี้มีเป้าหมายเพื่อทำให้เวิร์กโฟลว์ที่ทำซ้ำๆ กลายเป็นอัตโนมัติ ลองนึกถึง pipeline การทำความสะอาดข้อมูลที่สร้างขึ้นโดยอัตโนมัติ, การแนะนำ hyperparameters อย่างชาญฉลาดโดยอิงจากการรันครั้งก่อนๆ หรือการบันทึก log อัตโนมัติที่ระบุได้อย่างแม่นยำว่าชุดข้อมูลเวอร์ชันใดที่ให้ผลลัพธ์นั้นๆ หากวิสัยทัศน์นี้เป็นจริง มันจะช่วยให้นักวิจัยสามารถมุ่งเน้นไปที่การตั้งสมมติฐานแทนที่จะต้องมาจัดการกับโครงสร้างพื้นฐาน
ความเสี่ยงจากการขยายตัวที่มากเกินไปของการรวมระบบ
ทุกการรวมระบบ (integration) ที่วางแผนไว้คือคำสัญญาที่ต้องมีการดูแลรักษา TensorFlow และ PyTorch มีการอัปเดตอยู่บ่อยครั้ง การเปลี่ยนแปลงที่ส่งผลกระทบต่อระบบเดิม (breaking change) เพียงจุดเดียวใน dependency หลัก อาจส่งผลกระทบต่อเนื่องไปยังชั้นการทำงาน (abstraction layers) ของ OpenScience และทำให้ผู้ใช้ต้องเผชิญกับ stack traces ที่อ่านไม่รู้เรื่องแทนที่จะได้รันการทดลอง การมีไลบรารีมากขึ้นหมายถึงการต้องมีแพตช์ความปลอดภัยมากขึ้น ความขัดแย้งของเวอร์ชันที่มากขึ้น และโอกาสที่แพลตฟอร์มจะหลุดออกจากความสอดคล้องกับเครื่องมือที่มันควรจะรองรับ
ความซับซ้อนในการติดตั้งคือเพชฌฆาตเงียบของซอฟต์แวร์เพื่อการวิจัย หากการติดตั้ง OpenScience ต้องมานั่งแก้ปัญหาเรื่อง CUDA drivers, เวอร์ชันของ Node.js ที่เฉพาะเจาะจง และสภาพแวดล้อมของ Python ที่ขัดแย้งกัน นักศึกษาระดับบัณฑิตศึกษาที่งานล้นมือก็จะเลือกเปิด Google Colab แทน ซึ่งมี runtime ที่ตั้งค่าไว้ให้พร้อมใช้งานแล้ว งานวิจัยต้องดำเนินไปภายใต้กรอบเวลาที่จำกัด ไม่มีใครได้ตีพิมพ์ผลงานจากการใช้เวลาสามสัปดาห์เพื่อไล่แก้บั๊กของชุดเครื่องมือ (toolchain) หรอก
ดูเหมือนว่าเหล่านักพัฒนาจะตระหนักถึงความตึงเครียดนี้ ความท้าทายของพวกเขาคือการนำเสนอประสิทธิภาพที่เพียงพอต่อการใช้งาน โดยไม่ทำให้เครื่องมือเทอะทะจนเกินไปจนพังทลายลงด้วยน้ำหนักของตัวเอง
ความยั่งยืนในโลกโอเพนซอร์ส
ซอฟต์แวร์โอเพนซอร์สได้ทำให้ทุกอย่างเข้าถึงได้อย่างเท่าเทียม ตั้งแต่การพัฒนาเว็บไปจนถึงการวิเคราะห์ข้อมูล ใครๆ ก็สามารถตรวจสอบโค้ด มีส่วนร่วมในการแก้ไข หรือ fork โปรเจกต์เพื่อนำไปใช้ในกรณีเฉพาะทางได้ ความเปิดกว้างนี้ทำงานได้ดีเมื่อมีชุมชนขนาดใหญ่ของมืออาชีพที่ได้รับค่าตอบแทนคอยใช้งาน codebase ในการทำงานประจำวันของพวกเขา
แต่เครื่องมือโอเพนซอร์สทางวิทยาศาสตร์ต้องเผชิญกับความจริงที่ต่างออกไป ยอด GitHub stars จำนวน 2,167 ดวงนั้นดูมีความหวัง แต่ยอดดาวไม่ได้เป็นเงินทุนให้ผู้ดูแล รอบการให้ทุนวิจัยมีวันสิ้นสุด นักศึกษาปริญญาโทปริญญาเอกก็ต้องเรียนจบและย้ายไปที่อื่น หากปราศจากการสนับสนุนที่มั่นคงจากสถาบันหรือทีมงานหลักที่ทุ่มเท แม้แต่โปรเจกต์ที่ยอดเยี่ยมก็อาจหยุดชะงักลงได้ Repository อาจถูกทิ้งไว้เฉยๆ เป็นปี Dependencies เริ่มล้าสมัย และผู้ใช้งานกลุ่มแรกๆ ก็ต้องเผชิญกับโค้ดที่ถูกทอดทิ้งซึ่งไม่สามารถคอมไพล์กับฮาร์ดแวร์สมัยใหม่ได้อีกต่อไป สำหรับแพลตฟอร์มที่ต้องการรองรับวิทยาศาสตร์ที่ทำซ้ำได้ (reproducible science) การถูกทอดทิ้งนั้นเลวร้ายยิ่งกว่าการไม่เคยมีตัวตนอยู่เสียอีก OpenScience ต้องการการสนับสนุนระยะยาวจากมหาวิทยาลัย ห้องปฏิบัติการ หรือหน่วยงานให้ทุน หากต้องการที่จะอยู่รอดต่อไปได้มากกว่าแค่การเป็นข่าวพาดหัว
การแข่งขันกับ Jupyter, Colab และ MATLAB
OpenScience กำลังก้าวเข้าสู่สนามที่มีการแข่งขันสูง Jupyter Notebooks คือเครื่องมือมาตรฐานสำหรับการวิจัยเชิงสำรวจใน Python Google Colab ได้ทลายอุปสรรคด้านฮาร์ดแวร์ด้วยการเสนอ GPU ฟรีผ่านเบราว์เซอร์ ส่วน MATLAB ยังคงครองตลาดในภาควิชาวิศวกรรมที่ให้ความสำคัญกับชุดเครื่องมือที่มีการรับประกันและองค์ความรู้ของสถาบันที่สั่งสมมานานหลายทศวรรษ
เพื่อดึงดูดผู้ใช้จากเครื่องมือที่มั่นคงเหล่านี้ OpenScience ต้องนำเสนอสิ่งที่เครื่องมือเหล่านั้นไม่มี บางทีอาจเป็นการทำงานร่วมกันแบบหลายผู้ใช้ (multi-user collaboration) ที่แท้จริงโดยไม่มีความหน่วงเหมือนการใช้ shared notebooks หรืออาจเป็นโครงสร้างการบริหารจัดการที่ให้นักวิทยาศาสตร์เป็นผู้กำหนดทิศทางแผนการดำเนินงาน (roadmap) ไม่ใช่แค่เหล่านักพัฒนาซอฟต์แวร์ หรือบางทีอาจเป็นระบบการทำเวอร์ชันของผลการทดลอง (experiment versioning) ที่ทำให้การทำซ้ำ (reproducibility) เป็นเรื่องอัตโนมัติแทนที่จะเป็นเพียงสิ่งที่ต้องทำภายหลัง
ไม่ว่าจุดต่างจะเป็นอะไร เครื่องมือนี้ต้องยังคงเข้าถึงได้ง่าย หากมันต้องการเวิร์กสเตชันประสิทธิภาพสูงในเครื่อง หรือคาดหวังว่าผู้ใช้ทุกคนต้องเชี่ยวชาญในการรันเซิร์ฟเวอร์สำหรับพัฒนา มันจะไม่มีวันหลุดออกจากหน้า GitHub trending ได้เลย นักวิจัยต้องการเน้นไปที่การหาคำตอบ ไม่ใช่การตั้งค่าซอฟต์แวร์
บททดสอบที่แท้จริง: การบริหารจัดการสำคัญกว่าโค้ด
TypeScript ที่เขียนมาอย่างดีและรายการฟีเจอร์ที่ทะเยอทะยานจะช่วยผลักดันโปรเจกต์ไปได้เพียงระดับหนึ่งเท่านั้น ประวัติศาสตร์ของซอฟต์แวร์ทางวิทยาศาสตร์เต็มไปด้วย codebase ที่สวยงามแต่ล้มเหลว เพราะมันถูกสร้างขึ้นโดยนักพัฒนาเพื่อนักพัฒนา นักวิทยาศาสตร์ในห้องปฏิบัติการไม่ต้องการอินเทอร์เฟซที่หรูหราหากตัวนำเข้าไฟล์ CSV พังเมื่อเจอข้อมูลในโลกความเป็นจริง พวกเขาต้องการเครื่องมือที่เข้าใจถึงความยากลำบากที่แท้จริงของการวิจัย เช่น อินเทอร์เน็ตที่ติดๆ ดับๆ ในสถานีวิจัย, รูปแบบไฟล์ที่ยุ่งเหยิงจากเครื่องมือรุ่นเก่า และความจำเป็นอย่างยิ่งที่จะต้องพิสูจน์ให้ได้ว่าโค้ดชุดไหนสร้างรูปภาพใดขึ้นมา เพื่อตอบคำถามผู้ประเมิน (reviewer) ที่เข้มงวด
ความสำเร็จขึ้นอยู่กับการบริหารจัดการโดยชุมชน (community governance) หัวหน้าโครงการวิจัย ผู้จัดการห้องปฏิบัติการ และนักศึกษาระดับบัณฑิตศึกษา จำเป็นต้องมีสิทธิ์มีเสียงในการตัดสินใจว่าควรสร้างอะไร OpenScience ต้องเข้าถึงนักวิทยาศาสตร์ในจุดที่พวกเขาอยู่ ไม่ใช่ในจุดที่นักพัฒนาคาดหวังว่าพวกเขาควรจะอยู่
บทสรุป
OpenScience เป็นการทดลองที่น่าสนใจอย่างแท้จริง มันนำความเข้มงวดของวิศวกรรมซอฟต์แวร์แบบ typed มาใช้กับโลกแห่งการค้นพบทางวิทยาศาสตร์ที่ยุ่งเหยิงและต้องทำซ้ำไปมา การผสมผสานนี้หาได้ยากในสาขาที่ถูกครอบงำด้วยสคริปต์ Python แบบเร็วๆ แต่ทางเลือกทางเทคนิคก็มาพร้อมกับความเสี่ยง การแข่งขันก็ดุเดือด และเส้นทางจากยอด GitHub stars ไปสู่โครงสร้างพื้นฐานที่ยั่งยืนนั้นก็สูงชัน โค้ดนั้นเปิดกว้าง ยอดดาวก็กำลังเพิ่มขึ้น แต่ความท้าทายที่แท้จริงในตอนนี้คือการสร้าง...