Коли модель ШІ справді є open source: вимоги OSAID 1.0

Відкриті ваги ще не роблять модель відкритим кодом. Open Source AI Definition 1.0, яку Open Source Initiative опублікувала 28 жовтня 2024 року, переносить чотири базові свободи open source на системи штучного інтелекту. Користувач повинен мати право використовувати, вивчати, змінювати й поширювати систему, а також отримати форму, придатну для реального внесення змін.

Модель ШІ не зводиться до одного репозиторію

У звичайній програмі центральним об’єктом часто є вихідний код. Машинне навчання додає інші компоненти: архітектуру, параметри, код навчання та інференсу, конфігурацію, токенізатор, процедури обробки даних і самі відомості про навчальний набір. Відкрити лише клієнтську бібліотеку або демонстраційний застосунок недостатньо, якщо ключові рішення приховані в недоступному конвеєрі.

Саме тому OSI описує систему широко — як робочу цілісність та її окремі елементи. Перевіряти потрібно не рекламну назву, а конкретний реліз: які файли доступні, які права надані, що потрібно для відтворення роботи і які обмеження містять ліцензія та правила використання.

Чотири свободи залишаються основою

OSAID 1.0 вимагає свободи використовувати систему для будь-якої мети без окремого дозволу, вивчати її роботу, змінювати для будь-якої мети та поширювати оригінальну або змінену версію. Обмеження, яке забороняє конкурентне використання, певну галузь або комерційне розгортання, конфліктує з цими свободами, навіть якщо ваги можна безплатно завантажити.

У цьому сенсі слово «відкрита» не є синонімом «доступна після реєстрації». Ліцензія може вимагати зберігати повідомлення про авторство або поширювати зміни на тих самих умовах, але не повинна перетворювати загальне право використання на дозвіл для обраних сценаріїв. Різницю між open source і моделлю source-available TechPulse вже розглядав у матеріалі про ліцензійні обмеження.

Потрібна форма, у якій систему реально змінюють

Для машинного навчання «preferred form for making modifications» включає три групи елементів: інформацію про дані, повний код і параметри. Їх має бути достатньо, щоб кваліфікований фахівець міг зрозуміти походження системи та створити суттєво еквівалентну модель на тих самих або подібних даних.

Ця вимога не означає, що навчання завжди буде дешевим або що автор зобов’язаний надати обчислювальний кластер. Вона відділяє практичну модифікованість від ситуації, коли користувач отримує фінальний файл, але не знає, як підготували дані, які параметри застосували й чому повторний запуск дає інший результат.

Відомості про дані важливі навіть без повної публікації набору

OSAID вимагає детально описати походження, склад, спосіб отримання та добору даних, розмітку, фільтрацію й обробку. Потрібно перелічити публічно доступні набори та пояснити, де їх отримати. Для даних третіх сторін також має бути інформація про джерело та умови доступу, навіть якщо сам набір не можна вільно перевидати.

Це компроміс між прозорістю і реальними обмеженнями авторського права, приватності чи договорів. Він не гарантує, що будь-хто відтворить модель біт у біт, але дає змогу оцінити прогалини, упередження й законність походження. Загальна фраза «навчено на публічних даних» не відповідає такому рівню опису.

Код має охоплювати навчання, обробку та запуск

Відкритий репозиторій повинен містити не лише архітектуру моделі. Важливі код завантаження і очищення даних, навчальні аргументи, гіперпараметри, процедури оцінювання, токенізатори, залежності та інференс. Якщо суттєва фільтрація виконувалася закритим сервісом, відтворити систему за відкритою частиною буде неможливо.

Команді варто перевірити, чи збирається середовище з зафіксованих версій, чи задокументовані апаратні припущення та чи можна запустити базовий тест. Підпис релізу й походження артефактів не є окремою умовою OSAID, але допомагають переконатися, що завантажені ваги відповідають заявленому коду. Практичний процес описано у статті TechPulse про підпис релізів open source.

Параметри та ваги потрібні, але їх недостатньо

Параметри містять результат навчання: ваги, конфігурацію, а іноді проміжні контрольні точки й стан оптимізатора. Без них користувачеві довелося б повторити дороге навчання перед будь-яким дослідженням. OSAID передбачає їх доступність на умовах, сумісних із потрібними свободами.

Водночас файл ваг без коду й інформації про дані схожий на виконуваний файл без вихідного коду. Його можна запустити або донавчити, але важко встановити причину поведінки й відтворити ключові рішення. Тому коректніше писати «модель із відкритими вагами», якщо повний набір умов open source не виконаний.

Назву потрібно перевіряти для кожної версії

Проєкт може змінити ліцензію, закрити нову версію або залишити попередній реліз відкритим. Інша модель із тієї самої родини може використовувати новий набір даних і відмінні умови. Тому редакції, закупівельній команді й розробникам потрібно фіксувати точну назву, версію, контрольну суму та дату перевірки документів.

Не варто покладатися лише на картку в каталозі моделей. Посилання на ліцензію, репозиторій, опис даних і ваги мають бути доступні без суперечливих умов. Якщо сайт одночасно називає систему open source і забороняє певне використання, у документації продукту потрібно описати фактичне обмеження, а не повторювати маркетинговий ярлик.

Open source не гарантує безпеки або якості

OSAID відповідає на питання про свободи й доступність форми для модифікації. Вона не сертифікує точність, відсутність шкідливого вмісту, законність кожного навчального прикладу чи придатність до медичного, фінансового або іншого ризикового сценарію. Відкрита система може мати вразливу залежність, слабку документацію або невідомі межі оцінювання.

Перевага відкритості полягає в можливості незалежної перевірки, але можливість не є фактом проведеного аудиту. Перед використанням команда має оцінити модель на власних даних, перевірити ліцензії залежностей, сканувати артефакти, зафіксувати походження й обмежити повноваження застосунку. Назва open source не повинна знижувати вимоги до безпеки ланцюга постачання.

Компанії потрібен реєстр моделей і компонентів

Один продукт може поєднувати відкритий рушій, ваги з окремими умовами, пропрієтарний API та набір даних, який не можна поширювати. Загальна назва системи приховує ці відмінності. У реєстрі варто зберігати версію, джерело, контрольну суму, ліцензію кожного компонента, призначення, власника й дату останньої перевірки.

Після оновлення потрібно знову прочитати умови, а не припускати спадковість. Якщо команда донавчає модель, вона окремо документує власні дані, код і параметри та визначає, що може опублікувати. Такий реєстр допомагає одночасно юридичній перевірці, реагуванню на вразливість і відтворенню виробничої системи.

Відкритий проєкт потребує правил для внесків і релізів

Публікація файлів не створює спільноту автоматично. Учасникам потрібні зрозумілі правила приймання змін, перевірки даних, документування експериментів і реагування на небезпечну поведінку. Якщо навчальний конвеєр змінює десятки параметрів, pull request має містити не лише код, а конфігурацію, контрольний набір, метрики й опис впливу на відомі обмеження.

Окремо визначають, хто має право випускати ваги, як перевіряється їхнє походження і як проєкт повідомляє про вразливість або помилковий набір. Відтворюваний реліз пов’язує коміт, середовище, дані, конфігурацію й контрольну суму артефакту. Це зменшує ризик, що офіційна назва буде прикріплена до невідомого файлу.

Модель керування також впливає на довіру. Якщо одна компанія одноосібно змінює ліцензію та дорожню карту, користувачі повинні розуміти цей ризик. Фонд, технічний комітет або опублікована процедура рішень не є вимогою OSAID, але допомагають оцінити стійкість проєкту й можливість підтримувати незалежне відгалуження.

Документація повинна чесно відокремлювати те, що можна перевірити сьогодні, від майбутніх намірів. Обіцянка згодом опублікувати код навчання не робить поточний реліз відкритим. Так само доступ до файлів за запитом, який власник може відхилити без критеріїв, не дорівнює свободі використання. Статус варто змінювати лише після появи всіх необхідних компонентів і сумісних умов.

Редакціям і каталогам моделей корисно публікувати не бінарну позначку, а коротке обґрунтування: де лежить код, якою ліцензією охоплені ваги, як описані дані та що відсутнє. Це дає читачеві можливість перевірити висновок і не змішує open source із безплатним доступом. Дату такої перевірки потрібно показувати поруч, адже умови й файли змінюються.

Короткий чекліст для команди

• Чи дозволене використання системи для будь-якої мети?
• Чи можна змінювати й поширювати оригінальну та похідну версію?
• Чи доступні код навчання, обробки даних, оцінювання та інференсу?
• Чи описані походження, добір, розмітка й фільтрація даних?
• Чи доступні параметри та конфігурація моделі?
• Чи відповідають ліцензії кожного компонента заявленим свободам?
• Чи можна відтворити базовий запуск за документацією?

Першоджерела: Open Source AI Definition 1.0, офіційні пояснення OSI та повідомлення про випуск від 28 жовтня 2024 року.