Дослідники рідко скаржаться на дефіцит програмного забезпечення. Навпаки, вони стикаються з протилежною проблемою: занадто великою кількістю розрізнених інструментів, з’єднаних за допомогою shell-скриптів та надії. Новий проєкт із відкритим кодом під назвою OpenScience прагне замінити цей «латкинний» підхід єдиним AI-верстаком, розробленим спеціально для наукових відкриттів. Побудований на TypeScript і вже такий, що зібрав понад 2167 зірок на GitHub, він має на меті надати лабораторіям спільне середовище, де штучний інтелект допомагатиме автоматизувати робочі процеси, керувати експериментальними даними та забезпечувати координацію між співавторами. Амбіції зрозумілі. А от чи зможе проєкт вижити в реаліях підтримки open-source та в умовах жорсткої конкуренції — це вже інше питання.
Чому дослідженням потрібне власне робоче середовище
Науковий прогрес залежить від відтворюваності. Результат нічого не вартий, якщо інша команда не може провести той самий аналіз і дійти таких самих висновків. Проте сучасні конвеєри машинного навчання (machine learning pipelines) відомі своєю хаотичністю. Етапи попередньої обробки приховані всередині розрізнених клітинок Jupyter. Гіперпараметри жорстко прописані в недокументованих скриптах. Набори даних копіюються, перейменовуються та губляться на спільних дисках. Коли аспірант іде, його робочий процес часто йде разом із ним.
OpenScience прагне безпосередньо побороти цей хаос. Пропонуючи єдину платформу замість розрізненої колекції бібліотек, проєкт сподівається забезпечити послідовність у тому, як експерименти налаштовуються, відстежуються та поширюються. Співпраця є центральною ідеєю проєкту. Замість того, щоб пересилати код електронною поштою або боротися з системами контролю версій, дослідники зможуть працювати у спільному середовищі, яке фіксує, хто, що і коли змінив. Для галузей, де один експеримент може тривати тижнями обчислень, така прозорість не є розкішшю. Це необхідність.
Ставка на TypeScript для наукового коду
Вибір TypeScript для розробки є несподіваним. Машинне навчання працює на Python. І крапка. TensorFlow, PyTorch і переважна більшість наукових баз коду написані саме на ньому. Вчені зазвичай пишуть скрипти на Python або R, а знання JavaScript у багатьох вистачає лише для того, щоб підправити візуалізацію у веб-інтерфейсі. Тож чому TypeScript?
Команда розробників стверджує, що статична типізація допомагає тримати код організованим і надійним. У науковій роботі одна непомітна помилка типізації може звести нанівець місяці лабораторних досліджень. TypeScript виявляє цілі класи помилок під час компіляції, а не дозволяє їм «вибухнути» всередині тривалого процесу навчання моделі. Для платформи, яка хоче гарантувати відтворюваність, така суворість є привабливою.
Тут є реальні компроміси. TypeScript приваблює розробників, які цінують професійні інструменти, але він може відштовхнути саме тих дослідників, яким OpenScience прагне служити. Біологу, який вивчив основи JavaScript лише для форматування даних опитування, тепер доведеться розбиратися з інтерфейсами, дженериками та конвеєром збірки. Крива навчання тут крута. Якщо платформа змусить кожного користувача ставати інженером програмного забезпечення, перш ніж він зможе навчити модель, впровадження проєкту сповільниться. Ставка полягає в тому, що довгострокова вигода у стабільності переважить короткострокові труднощі під час освоєння.
Що обіцяє OpenScience
Проєкт хоче спростити два завдання, які наразі створюють величезне когнітивне навантаження: навчання моделей та відстеження експериментів. Замість того, щоб просити дослідників з’єднувати між собою пів десятка утиліт командного рядка, OpenScience планує запропонувати цілісний інтерфейс. Він також має намір інтегруватися з лідерами галузі, зокрема з TensorFlow та PyTorch, щоб науковцям не доводилося відмовлятися від знайомих бібліотек.
Сам ШІ має взяти на себе частину найважчої роботи. Робоче середовище має автоматизувати повторювані робочі процеси. Уявіть собі автоматично згенеровані конвеєри очищення даних, інтелектуальні пропозиції щодо гіперпараметрів на основі попередніх запусків або автоматичне логування, яке точно фіксує, яка саме версія набору даних дала певний результат. Якщо це бачення здійсниться, це звільнить дослідників для зосередження на гіпотезах, а не на інфраструктурі.
Ризик розростання інтеграцій
Кожна запланована інтеграція — це обіцянка, яка потребує підтримки. TensorFlow та PyTorch випускають часті оновлення. Одна зміна, що порушує сумісність, у основній залежності може відгукнутися по всіх рівнях абстракції OpenScience і змусити користувачів дивитися на загадкові стек-трейси замість проведення експериментів. Більше бібліотек означає більше патчів безпеки, більше конфліктів версій і більше можливостей для того, щоб платформа втратила синхронність із інструментами, які вона має обслуговувати.
Складність налаштування — це тихий вбивця наукового програмного забезпечення. Якщо встановлення OpenScience вимагає боротьби з драйверами CUDA, конкретними версіями Node.js та конфліктуючими середовищами Python, зайняті аспіранти просто відкриють вкладку Google Colab, де середовище виконання вже попередньо налаштоване. Дослідження проводяться у стислі терміни. Ніхто не отримує публікацію, витрачаючи три тижні на налагодження інструментарію.
Розробники, схоже, усвідомлюють це протиріччя. Їхнє завдання — запропонувати достатньо потужностей, щоб бути корисними, але не стати настільки громіздкими, щоб інструмент завалився під власною вагою.
Сталість у відкритому середовищі
Програмне забезпечення з відкритим вихідним кодом демократизувало все: від веброзробки до аналізу даних. Будь-хто може переглянути код, запропонувати виправлення або зробити форк проєкту для спеціалізованого використання. Така відкритість добре працює, коли велика спільнота оплачуваних професіоналів покладається на кодову базу у своїй щоденній роботі.
Наукові open-source інструменти стикаються з іншою реальністю. Ці 2167 зірок на GitHub виглядають багатообіцяюче, але зірки не фінансують мейнтейнерів. Цикли грантів закінчуються. Аспіранти йдуть далі. Без стабільної інституційної підтримки або відданої основної команди навіть блискучі проєкти закостенівають. Репозиторій залишається бездіяльним протягом року, залежності застарівають, а перші користувачі залишаються з покинутим кодом, який більше не компілюється на сучасному обладнанні. Для платформи, яка прагне забезпечувати відтворюваність науки, занедбаність є гіршою, ніж повна відсутність. OpenScience потребує довгострокової підтримки від університетів, лабораторій або фінансових організацій, якщо вона хоче вижити після того, як зникнуть заголовки новин.
Конкуренція з Jupyter, Colab та MATLAB
OpenScience виходить на переповнену арену. Jupyter Notebooks є стандартним робочим простором для пошукових досліджень на Python. Google Colab усунув апаратний бар'єр, пропонуючи безкоштовні GPU прямо у вкладці браузера. MATLAB усе ще домінує в інженерних кафедрах, які цінують його інструментарії з гарантією та десятиліття інституційної експертизи.
Щоб переманити користувачів від цих усталених інструментів, OpenScience має запропонувати те, чого вони не мають. Можливо, це справжня багатокористувацька співпраця без затримок, характерних для спільних блокнотів. Можливо, це структура управління, де науковці, а не лише розробники ПЗ, визначають дорожню карту. Або, можливо, це рівень версіонування експериментів, який робить відтворюваність автоматичною, а не другорядною справою.
Якою б не була відмінна риса, інструмент має залишатися доступним. Якщо він вимагатиме потужних локальних робочих станцій або передбачатиме, що кожен користувач вміє запускати сервер розробки, він ніколи не вийде за межі сторінки трендів GitHub. Дослідники оптимізують роботу для отримання відповідей, а не для налаштування програмного забезпечення.
Справжнє випробування: управління важливіше за код
Чистий TypeScript та амбітний список функцій допоможуть проєкту лише на певному етапі. Історія наукового ПЗ переповнена прекрасними кодовими базами, які зазнали невдачі, бо були створені розробниками для розробників. Лабораторному досліднику не потрібен яскравий інтерфейс, якщо імпортер CSV вилітає на реальних даних. Їм потрібні інструменти, що враховують справжню рутину досліджень: переривчастий інтернет на польових станціях, заплутані формати файлів зі старого обладнання та абсолютну потребу довести скептичному рецензенту