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

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

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

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

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

Три бар’єри, що стоять на заваді

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

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

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

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

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

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

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

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

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

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

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

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