Критичний шлях до автоматизації розробки моделей

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

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

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

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

Три бар’єри, що стоять на шляху

Перший бар’єр – фрагментація контексту. У майже кожній організації сигнали, експерименти, визначення ознак та інституційна знання, що стосуються будь-якої задачі моделювання, розкидані по різних складах даних, блокнотах та процесах, які ніколи не були спроектовані для спілкування один з одним. Розгляньте систему охорони здоров’я, яка будує модель виявлення сепсису. Клінічні критерії, що стосуються цієї проблеми, такі як пороги життєво важливих показників, лабораторні значення та стандарти документації, можуть перебувати в цілком окремих модулях електронної системи охорони здоров’я.

Другий бар’єр – семантична двозначність. Значення не є вродженим для даних, а є контекстним та організаційним. Та сама назва поля в двох різних базах даних може означати дещо різні речі. Концепції, такі як доход, активний користувач та відхід, часто мають кілька дійсних визначень в межах однієї компанії. Навіть така концепція, як “доход”, може викликати проблеми. Команда продажів може визначати доход як загальну вартість підписаних контрактів цього кварталу, тоді як фінансова команда визначає його як фактично отримані гроші. Команда продукту має ще одне розуміння, оскільки вона визначає термін як визнаний доход, розподілений по терміну підписки. Всі три команди витягують дані з полів, що буквально називаються “доходом” в своїх системах, але звіт, який поєднує ці дані, буде тихо змішувати три несумісні числа.

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

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

Що вимагає справжнє рішення

Історія автоматизації ML – це історія часткових рішень. AutoML вирішив вузьку проблему налаштування гіперпараметрів, але не міг обробляти несумісності цілей або розглядати організаційні наміри. MLOps зробив виробничі процеси більш стійкими та легшими для моніторингу, але інструменти MLOps виконують стратегію, а не визначають її. Більш недавні агенти кодування представляють справжній крок вперед, але вони успадкували ту саму сліпоту. Вони генерують код добре, працюючи без організаційного контексту чи інституційної пам’яті.

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

Суворі аудиторські сліди, які відстежують походження по версіям даних, визначенням ознак та комітам коду, мали б бути основним механізмом для засновування системи на тому, що фактично відбулося. І така система потребувала б вдумливого дизайну “людина в циклі”. Не бінарний вибір між повною автоматизацією та повним ручним контролем, а підтримка різних рівнів взаємодії залежно від завдання, ставок та впевненості системи на кожному етапі прийняття рішень. Автоматизація, яка обходить людську оцінку в критичні моменти, не є особливістю добре спроектованого штучного інтелекту; скоріше, це режим відмови.

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

Що стає можливим

Економічні наслідки вирішення цих проблем є суттєвими. Custom ML-розробка сьогодні вимагає спеціалістів-практиків та тижнів ітерацій, навіть для добре визначених проблем. Система, яка могла б навігацію повністю робочого процесу автономно від визначення проблеми до відкриття даних, розробки моделей та оцінки моделей, змінила б цю рівнянку драматично, стискаючи терміни та відкриваючи високоцінні випадки використання, які зараз є занадто ресурсоємними для виконання. Проекти, які раніше вимагали команд з глибокими знаннями ML, що працювали тижнями, тепер можуть бути завершені за кілька днів без витрат великої кількості часу рідкісних експертів ML.

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