Calea critică către automatizarea dezvoltării modelului

Următoarea piatră de hotar importantă pentru cercetarea inteligenței artificiale este să automatizeze dezvoltarea modelului. Fiecare progres în raționament, limbaj și percepție este, într-un anumit sens, un pas către acest obiectiv. Cu toate acestea, calea către automatizarea modelului necesită rezolvarea unei serii de provocări fundamentale care trebuie rezolvate mai întâi.

Podul către acest obiectiv trece direct prin ingineria machine learning (ML). O concepție greșită comună susține că ML este o tehnologie predecesoare a inteligenței artificiale moderne și că modelele de bază le-au înlocuit pur și simplu. Acest lucru înțelege greșit relația. Ca disciplină academică, ML cuprinde toate aspectele antrenării modelului, inclusiv antrenarea modelului de bază din centrul momentului actual al inteligenței artificiale. Cu toate acestea, există o diferență semnificativă în ceea ce privește scala și complexitatea datelor.

Modelele ML tradiționale sunt de obicei antrenate pe seturi de date atent curate, specifice domeniului, care conțin mii sau milioane de exemple. Modelele de bază, pe de altă parte, sunt antrenate pe mii de seturi de date simultan, extrase din surse foarte diferite, cu formate, proveniență și calitate inconstante. Această diferență în ceea ce privește scala și eterogenitatea datelor este un motiv fundamental pentru care gestionarea datelor devine mult mai grea și mai importantă pe măsură ce modelele devin mai puternice.

Acest lucru face ca înțelegerea datelor să devină un blocaj central în automatizarea dezvoltării modelului. Un sistem AI care poate interpreta date eterogene și îmbunătăți conductele construite în jurul acestuia ar putea, în principiu, îmbunătăți propriul proces de antrenare și ajuta la construirea unor modele mai bune. Odată ce AI poate îmbunătăți procesul prin care este antrenat, îmbunătățirile se propagă în aval către fiecare domeniu în care se aplică AI.

Trei bariere care stau în cale

Prima barieră este fragmentarea contextului. În aproape fiecare organizație, semnalele, experimentele, definițiile caracteristicilor și cunoștințele instituționale relevante pentru o anumită problemă de modelare sunt dispersate în magazine de date, caiete și conducte care nu au fost proiectate să comunice între ele. Luați în considerare un sistem de sănătate care construiește un model de detectare a sepsisului. Criteriile clinice relevante pentru această problemă, cum ar fi pragurile vitale, valorile de laborator și standardele de documentare, pot trăi în module complet separate ale unui sistem de înregistrare electronică a sănătății.

A doua barieră este ambiguitatea semantică. Sensul nu este inerent în date, ci este contextual și organizațional. Același nume de câmp în două baze de date diferite poate se referă la lucruri subtil diferite. Concepte precum venitul, utilizatorul activ și abandonul au în mod regulat multiple definiții valabile în cadrul unei singure companii. Chiar și un concept aparent atât de simplu ca “venitul” poate cauza probleme. O echipă de vânzări poate defini venitul ca valoarea totală a contractelor semnate în acest trimestru, în timp ce echipa de finanțe îl definește ca numerarul efectiv primit. Echipa de produse are o altă înțelegere, deoarece definește termenul pentru a însemna venitul recunoscut, distribuit pe o perioadă de abonament. Toate trei extrag din câmpuri literal numite “venit” în sistemele lor respective, dar un raport între echipe care le combină ar amesteca silent trei numere incompatibile.

A treia și cea mai sistemică barieră este absența memoriei organizaționale documentate. Urmărirea provenienței, rezolvarea incoerențelor și menținerea semnalelor de calitate pe atâtea surse este o problemă nerezolvată, chiar și pentru echipele umane. Fără o memorie instituțională a ceea ce s-a încercat și cum au funcționat aceste abordări, orice mecanism de automatizare a modelului va continua să redescopere aceleași fundături, irosind timp și resurse.

Luați în considerare o echipă de știință a datelor la o companie de retail care construiește un model de previziune a cererii. Pe parcursul a trei ani, o duzină de analiști au descoperit independent că datele brute despre vreme deteriorează performanța modelului în timpul săptămânilor de sărbători, că alimentarea stocului unui anumit furnizor conține o întârziere sistematică și că abordarea standard pentru gestionarea evenimentelor promoționale provoacă scurgeri de țintă. Când analiștii originali s-au mutat în alte echipe sau au părăsit compania, cunoștințele au dispărut odată cu ei. Fără o înregistrare instituțională a ceea ce s-a încercat, a ceea ce a eșuat și de ce, un mecanism de automatizare a modelului nu poate construi pe experiența acumulată. Pur și simplu pornește de la zero, din nou și din nou, irosind inutil timp.

Ce necesită o soluție reală

Istoria automatizării ML este o istorie a soluțiilor parțiale. AutoML a abordat problema îngustă a reglării hiperparametrilor, dar nu a putut gestiona necorespondențele obiectivelor sau nu a putut raționa despre intenția organizațională. MLOps a făcut conductele de producție mai robuste și mai ușor de monitorizat, dar uneltele MLOps execută o strategie, mai degrabă decât să o definească. Agendenții de codare mai recenti reprezintă un pas real înainte, dar au moștenit același punct orb. Ei generează cod bine, dar operează fără context organizațional sau memorie instituțională.

Un sistem capabil de inginerie ML autonomă adevărată ar necesita capacități pe care niciun instrument existent nu le oferă în combinație. Ar trebui să poată mapa obiectivele de afaceri la obiectivele modelului, ceea ce este o traducere care nu poate fi dedusă doar din date. Ar trebui să poată descoperi date relevante în sisteme fragmentate cu scheme inconstante, respectând în același timp automat constrângerile de conformitate, guvernanță și securitate, mai degrabă decât să solicite oamenilor să le gestioneze ca un proces separat. Ar trebui să aibă o memorie instituțională pentru a aduce la suprafață lucrările existente, a înțelege de ce experimentele trecute au fost abandonate și a construi pe ceea ce colegii deja știu.

Urmele de audit riguroase care urmăresc proveniența pe versiuni de date, definiții de caracteristici și angajamente de cod ar trebui să fie un mecanism de bază pentru a ancora sistemul în ceea ce s-a întâmplat realmente. Și un astfel de sistem ar necesita o proiectare atentă a omului în buclă. Nu o alegere binară între automatizarea completă și controlul manual complet, ci suport pentru niveluri variate de interacțiune, în funcție de sarcină, de mize și de încrederea sistemului la fiecare punct de decizie. Automatizarea care ocolește judecata umană în momente critice nu este o caracteristică a unei AI bine proiectate; mai degrabă, este un mod de eșec.

Ce niciun laborator nu a rezolvat încă este cum să creeze o înțelegere semantică a datelor organizaționale care să înțeleagă ce înseamnă datele într-un context instituțional specific. MCP rezolvă problema conectivității. Nu rezolvă încă problema sensului. Acesta rămâne frontiera deschisă a cercetării.

Ce devine posibil

Implicațiile economice ale rezolvării acestor probleme sunt semnificative. Dezvoltarea ML personalizată necesită astăzi practicieni specialiști și săptămâni de iterație, chiar și pentru probleme bine definite. Un sistem care ar putea naviga fluxul de lucru complet în mod autonom, de la definirea problemei la descoperirea datelor, dezvoltarea modelului și evaluarea modelului, ar schimba dramatic această ecuație, comprimând timpul de dezvoltare și deschizând cazuri de utilizare de înaltă valoare care sunt în prezent prea intense din punct de vedere al resurselor pentru a fi urmărite. Proiectele care au necesitat echipe cu expertiză profundă în ML, care au lucrat timp de săptămâni, pot fi acum finalizate în câteva zile, fără a fi nevoie să se utilizeze atât de mult timpul expertului ML.

Provocările fragmentării contextului, ambiguității semantice și lipsei memoriei instituționale nu sunt unice pentru ML enterprise. Ele se manifestă sub constrângeri diferite în construirea conductelor de antrenare a modelului de bază, unde mii de seturi de date eterogene trebuie agregate, filtrate și rafinate iterativ. Deși cele două setări diferă în structură și obiectiv, ambele sunt limitate de același blocaj subiacent: absența sistemelor care pot recupera în mod fiabil contextul, urmări proveniența și construi pe munca anterioară, de-a lungul iterațiilor. Automatizarea dezvoltării modelului în cadrul companiei este, prin urmare, un pas critic pe calea către sistemele AI capabile să se îmbunătățească singure.