Myslitelé
Kritická cesta k automatizaci vývoje modelů

Dalším důležitým milníkem pro výzkum umělé inteligence je automatizace vývoje modelů. Každý pokrok v oblasti rozumění, jazyka a vnímání je v jistém smyslu krokem směrem k tomuto cíli. Nicméně, cesta k automatizaci modelů vyžaduje řešení souboru základních výzev, které musí být nejprve vyřešeny.
Most k tomuto cíli vede přímo přes inženýrství strojového učení (ML). Společný omyl spočívá v tom, že ML je předcházející technologie moderní umělé inteligence a že základové modely ji jednoduše nahradily. To však nepochopitelně popisuje vztah. Jako akademická disciplína zahrnuje ML všechny aspekty školení modelů, včetně školení základových modelů, které jsou v centru současné umělé inteligence. Existuje však významný rozdíl v měřítku a složitosti dat.
Tradiční modely ML jsou obvykle školeny na pečlivě kurátorovaných, doménově specifických datech obsahujících tisíce nebo miliony příkladů. Základové modely, na druhé straně, jsou školeny na tisících datech současně, pocházejících z různých zdrojů s nekonzistentními formáty, původem a kvalitou. Tento rozdíl v měřítku a heterogenitě dat je zásadním důvodem, proč se správa dat stává mnohem složitější a důležitější, jakmile modely rostou v síle.
To činí pochopení dat centrální překážkou při automatizaci vývoje modelů. Systém umělé inteligence, který může interpretovat heterogenní data a zlepšit procesy postavené kolem něj, by mohl v zásadě zlepšit svůj vlastní proces školení a pomoci budovat lepší modely. Jakmile umělé inteligence může zlepšit proces, kterým je školen, zlepšení se rozšíří dolů do každého domény, kde je umělé inteligence aplikována.
Tři překážky stojící v cestě
První překážka je fragmentace kontextu. V téměř každé organizaci jsou signály, experimenty, definice funkcí a institucionální znalosti relevantní pro daný problém modelování rozptýleny po datových skladech, poznámkách a procesech, které nebyly navrženy pro komunikaci navzájem. Zvažte zdravotnický systém, který buduje model pro detekci sepse. Klinické kritérium relevantní pro tento problém, jako jsou prahové hodnoty, laboratorní hodnoty a dokumentační standardy, může žít v úplně samostatných modulech elektronického systému zdravotních záznamů.
Druhá překážka je sémantická nejednoznačnost. Význam není inherentní v datech, ale je kontextuální a organizační. Stejné názvy polí ve dvou různých databázích mohou odkazovat na jemně odlišné věci. Koncepty, jako je výnos, aktivní uživatel a odchod, rutinně mají několik platných definic v rámci jedné společnosti. I koncept, jako je “výnos”, může způsobit problémy. Tým prodeje může definovat výnos jako celkovou hodnotu smluv podepsaných v tomto čtvrtletí, zatímco finanční tým definuje jej jako skutečně obdržené peníze. Produktový tým má další pochopení, protože definuje termín jako uznávaný výnos rozložený po období předplatného. Všichni tři čerpají z polí doslova nazvaných “výnos” ve svých systémech, ale mezioborová zpráva, která je kombinuje, by potichu smísila tři neslučitelná čísla.
Třetí a nejvíce systémová překážka je absence zdokumentované institucionální paměti. Sledování původu, řešení nesrovnalostí a udržování kvalitních signálů napříč tolik zdroji je nevyřešeným problémem, dokonce i pro lidské týmy. Bez institucionální paměti toho, co bylo zkuseno a jak dobře tyto přístupy fungovaly, bude jakýkoli mechanismus automatizace modelů neustále znovuobjevovat stejné slepé uličky, plýtvaje časem a zdroji.
Zvažte tým datových vědců v maloobchodní společnosti, který buduje model pro předpověď poptávky. Během tří let nezávisle objevilo dvanáct analytiků, že surová meteorologická data zhoršují výkon modelu během týdne svátků, že feed zásob certain dodavatele obsahuje systematické zpoždění a že standardní přístup k manipulaci s reklamními akcemi způsobuje únik cíle. Když původní analytici přešli do jiných týmů nebo opustili společnost, znalosti odešly s nimi. Bez institucionální evidence o tom, co bylo zkuseno, co selhalo a proč, mechanismus automatizace modelů nemůže stavět na nahromaděných zkušenostech. Prostě začíná od nuly, znovu a znovu, zbytečně plýtvaje časem.
Co vyžaduje skutečné řešení
Historie automatizace ML je historií částečných řešení. AutoML řešila úzký problém ladění hyperparametrů, ale nemohla zvládnout nesoulad cílů nebo uvažovat o organizačním záměru. MLOps učinila produkční procesy více robustními a snazšími na monitorování, ale nástroje MLOps provádějí strategii, místo aby ji definovaly. Nedávnější agenti kódování představují skutečný krok vpřed, ale zdědili stejnou slepou skvrnu. Generují kód dobře, zatímco fungují bez organizačního kontextu nebo institucionální paměti.
Systém, který by byl schopen skutečné autonomní inženýrství ML, by potřeboval schopnosti, které žádný existující nástroj neposkytuje v kombinaci. Musel by být schopen mapovat obchodní cíle na cíle modelů, což je překlad, který nelze odvodit pouze z dat. Musel by být schopen objevit relevantní data napříč fragmentovanými systémy s nekonzistentními schématy, zatímco automaticky dodržoval požadavky na shodu, správu a zabezpečení, místo aby vyžadoval, aby je lidé spravovali jako samostatný proces. Musel by mít institucionální paměť, aby mohl zpřístupnit existující práci, pochopit, proč byly minulé experimenty opuštěny, a stavět na tom, co již kolegové znají.
Přísné auditní stopy, které sledují původ napříč verzemi dat, definicemi funkcí a commity kódu, by musely být jádrem mechanismu pro zakotvení systému v tom, co se skutečně stalo. A jakýkoli takový systém by vyžadoval pečlivě navržený lidský faktor. Ne binární volbu mezi plnou automatizací a plnou manuální kontrolou, ale podporu pro různé úrovně interakce v závislosti na úkolu, sázkách a důvěře systému v každém rozhodování. Automatizace, která obchází lidský úsudek v kritických okamžicích, není funkcí dobře navržené umělé inteligence; spíše je to selhání.
Co dosud žádná laboratoř nevyřešila, je, jak vytvořit sémantické pochopení organizačních dat, které chápe, co data znamenají v konkrétním institucionálním kontextu. MCP řeší problém připojení. Nyní ještě nevyřešila problém významu. To zůstává otevřenou výzkumnou frontou.
Co se stane možným
Ekonomické důsledky řešení těchto problémů jsou významné. Vlastní vývoj ML dnes vyžaduje specializované praktiky a týdny iterací, i pro dobře definované problémy. Systém, který by mohl navigovat celý pracovní postup autonomně od definice problému přes objevování dat, vývoj modelů a hodnocení modelů, by dramaticky změnil tuto rovnici, zkracující časové osy a otevírající vysoké hodnotové použití, které jsou v současnosti příliš náročné na zdroje. Projekty, které dříve vyžadovaly týmy s hlubokými znalostmi ML pracující týdny, mohou být nyní dokončeny za dny bez nutnosti využívat tolik vzácných odborníků na ML.
Výzvy kontextové fragmentace, sémantické nejednoznačnosti a chybějící institucionální paměti nejsou jedinečné pro podnikové ML. Manifestují se pod různými omezeními při konstrukci základových modelů pro školení, kde musí být tisíce heterogenních dat agregována, filtrována a iterativně rafinována. Ačkoli se obě situace liší strukturou a cílem, obě jsou omezeny stejnou základní překážkou: absencí systémů, které mohou spolehlivě obnovit kontext, sledovat původ a stavět na předchozích pracích napříč iteracemi. Automatizace vývoje modelů v podniku je proto kritickým krokem na cestě k systémům umělé inteligence, které jsou schopné zlepšovat se samy.













