Connect with us

Liderzy opinii

Krytyczna Ścieżka do Automatyzacji Rozwoju Modelu

mm mm
A stylized digital landscape showing illuminated lines connecting data structures. A cluster representing

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

Most 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 dotyczy relacji. Jako dyscyplina akademicka, ML obejmuje wszystkie aspekty szkolenia modelu, 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 zestawach danych zawierających tysiące lub miliony przykładów. Modele podstawowe, z drugiej strony, są szkolone na tysiącach zestawów danych jednocześnie, pobranych z bardzo różnych źródeł o niejednorodnych 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 jest centralną wąskim gardłem w automatyzacji rozwoju modelu. System sztucznej inteligencji, który może interpretować heterogeniczne dane i ulepszać potoki zbudowane wokół nich, mógłby w zasadzie ulepszyć swój własny proces szkolenia i pomóc zbudować lepsze modele. Gdy sztuczna inteligencja może ulepszyć proces, przez który jest szkolona, ulepszenia 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 medycznej.

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 rutynowo mają wiele ważnych definicji w ramach jednej firmy. Nawet pojęcie takie jak “przychód” może powodować problemy. Zespół sprzedaży może definiować przychód jako całkowitą wartość podpisanych umów w tym kwartale, podczas gdy zespół finansowy definiuje go jako otrzymane pieniądze. Zespół produktowy ma jeszcze inne zrozumienie, ponieważ definiuje ten termin jako rozpoznanie przychodu rozłożonego w czasie subskrypcji. Wszystkie trzy są pobierane z pól dosłownie nazwanych “przychód” w ich odpowiednich 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 niekonsekwencji 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 o tym, co zostało spróbowane i jak dobrze te podejścia działały, żadne mechanizmy automatyzacji modelu nie będą mogły budować na zgromadzonym doświadczeniu. Po prostu zaczynają od zera, raz za razem, marnując czas i zasoby.

Rozważmy zespół analityków danych w firmie detalicznej budującej model prognozowania popytu. Przez trzy lata, tuzin analityków niezależnie odkrył, że surowe dane pogodowe pogarszają wydajność modelu podczas tygodni świątecznych, że karmienie zapasów od konkretnego dostawcy 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 odeszł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, raz za razem, marnując czas.

Co 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 powodu o zamiarach 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 do przodu, ale odziedziczyli ten sam punkt ślepy. Generują kod dobrze, ale działają bez kontekstu organizacyjnego lub instytucjonalnej pamięci.

System zdolny do prawdziwie autonomicznej inżynierii ML wymagałby zdolności, których nie zapewnia żadne istniejące narzędzie w połączeniu. Wymagałby mapowania celów biznesowych na cele modelu, co jest tłumaczeniem, które nie może być wnioskowane wyłącznie z danych. Wymagałby odkrycia istotnych danych w rozproszonych systemach o niejednorodnych schematach, przy jednoczesnym automatycznym przestrzeganiu ograniczeń zgodności, zarządzania i bezpieczeństwa, zamiast wymagania od ludzi zarządzania nimi jako odrębnego procesu. Wymagałby instytucjonalnej pamięci, aby wyeksponować istniejącą pracę, zrozumieć, dlaczego poprzednie eksperymenty zostały porzucone, i budować na tym, co koledzy już wiedzą.

Surowe ślady audytu, które śledzą pochodzenie wersji danych, definicji cech i zatwierdzeń 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, stawki i pewności systemu na każdym punkcie decyzyjnym. Automatyzacja, która omija ludzkie osądy 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. Nie rozwiązuje jeszcze problemu znaczenia. To pozostaje otwarta granica badań.

Co Staje Się Możliwe

Ekonomiczne implikacje rozwiązania tych problemów są znaczące. Niestandardowa rozwój ML wymaga obecnie specjalistycznych praktyków i tygodni iteracji, nawet dla dobrze określonych problemów. System, który mógłby nawigować przez cały potok pracy w sposób autonomiczny, 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ą ML pracujących przez tygodnie, mogą teraz być realizowane w ciągu dni bez konieczności wykorzystywania tak wielu rzadkich ekspertów ML.

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

Doris Xin jest CEO i współzałożycielką Disarray. Jako doktorantka UC Berkeley RISELab i stypendystka NSF Graduate Research Fellow, Doris doskonaliła swoją ekspertyzę w dziedzinie ML i była jednym z pierwszych inżynierów ML w LinkedIn.

Moustafa AbdelBaky jest CTO i współzałożycielem Disarray. Jest trzykrotnym stypendystą IBM PhD z prawie dwoma dekadami badań nad autonomiczną orkiestracją w rozproszonych systemach, edge ML i czasie rzeczywistym AI dla autonomicznych misji lotniczych i kosmicznych NASA.