Krytyczna ścieżka do automatyzacji tworzenia modeli

Następnym ważnym kamieniem milowym w badaniach nad sztuczną inteligencją jest automatyzacja tworzenia modeli. Każdy postęp w rozumowaniu, języku i percepcji jest w pewnym sensie krokiem w stronę tego celu. Jednakże, droga do automatyzacji modeli wymaga rozwiązania zestawu podstawowych wyzwań, które muszą być rozwiązane najpierw.

Mostek do tego celu prowadzi bezpośrednio przez inżynierię maszynowego uczenia się (ML). Powszechne nieporozumienie głosi, że ML jest technologią poprzedzającą nowoczesną sztuczną inteligencję i że modele podstawowe po prostu ją zastąpiły. To nieporozumienie nie rozumie relacji. Jako dyscyplina akademicka, ML obejmuje wszystkie aspekty szkolenia modeli, w tym szkolenie modeli podstawowych w centrum obecnego momentu sztucznej inteligencji. Istnieje jednak znacząca różnica w skali i złożoności danych.

Tradycyjne modele ML są zwykle szkolone na starannie wyselekcjonowanych, domenowo-specyficznych zbiorach danych zawierających tysiące lub miliony przykładów. Modele podstawowe, z drugiej strony, są szkolone na tysiącach zbiorów danych jednocześnie, pobranych z bardzo różnych źródeł o niejednolitych formatach, pochodzeniu i jakości. Ta różnica w skali i heterogeniczności danych jest podstawowym powodem, dla którego zarządzanie danymi staje się znacznie trudniejsze i ważniejsze, gdy modele stają się coraz potężniejsze.

To sprawia, że zrozumienie danych staje się centralną przeszkodą w automatyzacji tworzenia modeli. System sztucznej inteligencji, który może interpretować heterogeniczne dane i poprawiać potoki zbudowane wokół nich, mógłby w zasadzie poprawić swój własny proces szkolenia i pomóc zbudować lepsze modele. Gdy sztuczna inteligencja może poprawić proces, przez który jest szkolona, poprawki są przenoszone w dół do każdej dziedziny, w której sztuczna inteligencja jest stosowana.

Trzy bariery stojące na przeszkodzie

Pierwszą barierą jest fragmentacja kontekstu. W niemal każdej organizacji, sygnały, eksperymenty, definicje cech i wiedza instytucjonalna istotne dla danego problemu modelowania są rozproszone po magazynach danych, notesach i potokach, które nigdy nie były zaprojektowane do komunikacji ze sobą. Rozważmy system opieki zdrowotnej budujący model wykrywania sepsy. Kryteria kliniczne istotne dla tego problemu, takie jak progi życiowe, wartości laboratoryjne i standardy dokumentacji, mogą znajdować się w całkowicie oddzielnych modułach systemu elektronicznej dokumentacji zdrowia.

Druga bariera to niejednoznaczność semantyczna. Znaczenie nie jest wrodzone w danych, ale jest kontekstowe i organizacyjne. Ta sama nazwa pola w dwóch różnych bazach danych może odnosić się do subtelnie różnych rzeczy. Pojęcia takie jak przychód, aktywny użytkownik i churn mają zwykle wiele ważnych definicji w ramach jednej firmy. Nawet pojęcie tak pozornie proste jak “przychód” może powodować problemy. Zespół sprzedaży może definiować przychód jako łączną wartość podpisanych umów w tym kwartale, podczas gdy zespół finansowy definiuje go jako rzeczywiście otrzymane środki. Zespół produktowy ma jeszcze inne zrozumienie, definiując ten termin jako rozpoznaný przychód rozłożony na okres subskrypcyjny. Wszystkie trzy korzystają z pól dosłownie nazwanych “przychód” w swoich systemach, ale raport międzyzespołowy łączący je będzie cicho mieszał trzy niezgodne liczby.

Trzecią i najbardziej systemową barierą jest brak udokumentowanej pamięci instytucjonalnej. Śledzenie pochodzenia, rozwiązywanie niezgodności i utrzymanie sygnałów jakościowych w tak wielu źródłach jest nierozwiązanym problemem, nawet dla zespołów ludzkich. Bez instytucjonalnej pamięci tego, co zostało spróbowane i jak dobrze te podejścia działały, każdy mechanizm automatyzacji modelu będzie odkrywał te same martwe końce, marnując czas i zasoby.

Rozważmy zespół naukowców danych w firmie detalicznej budujący model prognozowania popytu. Przez trzy lata, tuzin analityków niezależnie odkrył, że surowe dane pogodowe pogarszają wydajność modelu podczas tygodni świątecznych, że określony dostawca danych o zapasach zawiera systematyczne opóźnienie, a standardowe podejście do obsługi wydarzeń promocyjnych powoduje wyciek celu. Gdy pierwotni analitycy przenieśli się do innych zespołów lub opuścili firmę, wiedza poszła z nimi. Bez instytucjonalnego zapisu tego, co zostało spróbowane, co nie powiodło się i dlaczego, mechanizm automatyzacji modelu nie może budować na zgromadzonym doświadczeniu. Po prostu zaczyna od zera, znowu i znowu, marnując czas.

Czego wymaga prawdziwe rozwiązanie

Historia automatyzacji ML jest historią częściowych rozwiązań. AutoML rozwiązał wąski problem dostrajania hiperparametrów, ale nie mógł obsłużyć niezgodności celów ani rozumu o intencjach organizacyjnych. MLOps uczynił potoki produkcyjne bardziej solidnymi i łatwiejszymi do monitorowania, ale narzędzia MLOps wykonują strategię, zamiast ją definiować. Bardziej niedawne agenci kodowania reprezentują prawdziwy krok naprzód, ale odziedziczyli ten sam punkt ślepy. Generują kod dobrze, ale działają bez kontekstu organizacyjnego i pamięci instytucjonalnej.

System, który byłby naprawdę samodzielnie inżynierią ML, wymagałby funkcji, których nie zapewnia żadne istniejące narzędzie. Musiałby mapować cele biznesowe na cele modelu, co jest tłumaczeniem, które nie może być wnioskowane z samych danych. Musiałby odkrywać istotne dane w rozproszonych systemach o niejednolitych schematach, automatycznie przestrzegając ograniczeń zgodności, zarządzania i bezpieczeństwa, zamiast wymagać od ludzi zarządzania nimi jako oddzielnego procesu. Musiałby mieć pamięć instytucjonalną, aby ujawnić istniejącą pracę, zrozumieć, dlaczego poprzednie eksperymenty zostały porzucone, i budować na tym, co koledzy już wiedzą.

Ścisłe ślady audytowe, które śledzą pochodzenie w wersjach danych, definicjach cech i zobowiązaniach kodu, musiałyby być podstawowym mechanizmem dla ugruntowania systemu w tym, co naprawdę się wydarzyło. I taki system wymagałby przemyślanego projektu z ludzkim uczestnictwem. Nie binarny wybór między pełną automatyzacją a pełną kontrolą ręczną, ale wsparcie dla różnych poziomów interakcji, w zależności od zadania, stawek i zaufania systemu na każdym punkcie decyzyjnym. Automatyzacja, która omija ludzki osąd w krytycznych momentach, nie jest cechą dobrze zaprojektowanej sztucznej inteligencji; raczej jest to tryb awaryjny.

To, czego jeszcze nie rozwiązał żaden laboratorium, to jak stworzyć semantyczne zrozumienie danych organizacyjnych, które rozumie, co dane znaczą w określonym kontekście instytucjonalnym. MCP rozwiązuje problem połączenia. Jeszcze nie rozwiązuje problemu znaczenia. To pozostaje otwarta granica badań.

Czego można osiągnąć

Ekonomiczne implikacje rozwiązania tych problemów są znaczące. Dzisiaj niestandardowa rozwój ML wymaga specjalistycznych praktyków i tygodni iteracji, nawet dla dobrze określonych problemów. System, który mógłby nawigować przez cały potok autonomicznie od definicji problemu przez odkrycie danych, rozwój modelu i ocenę modelu, przesunąłby tę równanie dramatycznie, kompresując terminy i otwierając przypadki użycia o wysokiej wartości, które obecnie są zbyt zasobowo-intensywne, aby je realizować. Projekty, które wymagały zespołów z głęboką wiedzą na temat ML pracujących przez tygodnie, mogą teraz być ukończone w ciągu dni bez konieczności wykorzystania tak wielu rzadkich ekspertów ML.

Wyzwania fragmentacji kontekstu, niejednoznaczności semantycznej i braku pamięci instytucjonalnej nie są unikalne dla przedsiębiorstw ML. Pojawiają się one pod różnymi ograniczeniami w budowie potoków szkolenia modeli podstawowych, gdzie tysiące heterogenicznych zbiorów danych muszą być agregowane, filtrowane i iteracyjnie rafinowane. Chociaż te dwa ustawienia różnią się strukturą i celem, oba są ograniczone przez ten sam podstawowy wąski gardło: brak systemów, które mogą niezawodnie odzyskać kontekst, śledzić pochodzenie i budować na poprzedniej pracy w iteracjach. Automatyzacja rozwoju modeli w przedsiębiorstwie jest więc krytycznym krokiem na drodze do systemów sztucznej inteligencji, które mogą się same poprawiać.