Ce mai trebuie construit în jurul unui model AI pentru a-l folosi în producție

Definiți unitatea de lucru

Porniți de la o singură acțiune de afaceri și notați-i începutul și sfârșitul. Pentru un asistent intern de cunoștințe, succesul poate însemna că un utilizator primește un răspuns susținut de documente la care are acces sau o explicație clară că materialele disponibile nu răspund la întrebare. Pentru un agent, succesul poate include o actualizare verificată într-un alt sistem. Acestea sunt contracte diferite și trebuie evaluate separat.

Un asistent de achiziții, luat ca ilustrare, scoate în evidență diferența. Citirea unei comenzi este o permisiune. Recomandarea unei corecturi este un rezultat. Aplicarea corecturii este o acțiune, cu un responsabil și o urmă de audit. O conversație fluentă poate ascunde aceste treceri dacă arhitectura nu le numește.

ReAct explorează alternarea raționamentului cu acțiunile în sarcinile modelelor de limbaj. Asta face granița deosebit de vizibilă: un sistem poate aduna informații și poate acționa în mai mulți pași. Lucrarea este o metodă de cercetare, nu un contract de funcționare pentru afacerea voastră. Aplicația tot trebuie să definească acțiunile permise și rezultatele acceptabile.

Desenați dependențele înainte să alegeți modelul

Enumerați sursele de referință, verificările de identitate, uneltele și destinațiile pentru erori. Stabiliți ce se întâmplă când o dependență este lentă, goală, depășită sau indisponibilă. Modelul poate răspunde și când un serviciu de regăsire cade; aplicația trebuie să decidă dacă acel răspuns ar trebui afișat.

Sculley și colegii săi descriu cum acumulează sistemele de machine learning datorie tehnică prin dependențele de date, buclele de feedback și infrastructura din jur. Lucrarea lor susține ideea de a privi dincolo de modelul izolat. Într-o analiză de arhitectură, transformăm această grijă în responsabili numiți și interfețe vizibile: cine poate schimba intrarea, cine observă o schimbare și ce decizii din aval depind de ea.

Construiți un singur traseu complet

O primă versiune ar trebui să includă utilizatorul, dovezile și traseul pentru eșec. O interfață atrăgătoare, legată de un apel la model pe care nu-l urmărește nimeni, nu e de ajuns ca să aflați dacă întregul proces funcționează. Folosiți un domeniu îngust, ca echipa să-și permită să construiască devreme piesele operaționale.

ML Test Score tratează pregătirea pentru producție ca pe o colecție de verificări pentru date, modele, infrastructură și monitorizare. Lecția utilă pentru o analiză de design este cât de largă e întrebarea. O comparație de modele nu poate ține locul verificării serviciului care îl va conține.

Pentru exemplul cu achizițiile, un pilot util ar putea aduce comanda, ar putea compara un set mic de câmpuri și ar putea prezenta dovezile într-o coadă de verificare. Ar înregistra identificatorul rulării, versiunile relevante, decizia celui care verifică și orice pas eșuat. Ar putea evita complet modificarea sistemului de contabilitate până când procesul de verificare e bine înțeles.

Tot aici ar trebui să stabilească echipa ce va măsura. O recomandare corectă care sosește după ce decizia a fost luată nu e utilă. O recomandare rapidă care cere o investigație lungă poate costa mai mult decât procesul anterior. Calitatea, latența, efortul de verificare și costul de operare își au locul în aceeași discuție despre lansare.

Un scurt exercițiu de simulare a erorilor

Desenați șase căsuțe pe o pagină: cerere, identitate, sursă, model, acțiune, operator. Porniți pe rând de la fiecare căsuță și eliminați ceva la care se așteaptă căsuța următoare. Exercițiul e mic în mod deliberat. O sursă întoarce o revizie veche. Un utilizator pierde accesul cât timp o rulare stă la coadă. Destinația acceptă o schimbare, iar răspunsul se pierde.

Pentru fiecare întrerupere, notați ce vede utilizatorul și ce știe operatorul. Dacă răspunsurile diferă, faceți ca diferența să fie intenționată. Un utilizator poate vedea un mesaj scurt, în timp ce un operator autorizat vede un identificator al rulării și o cale sigură de reconciliere. Niciunuia nu ar trebui să i se spună că o acțiune de afaceri a eșuat doar pentru că o cerere de rețea a expirat.

Proiectați ziua de după lansare

Stabiliți cine poate opri fluxul și cine îl poate modifica. Documentați cum se continuă munca atunci când serviciul AI nu este disponibil. Decideți ce informații păstrați despre fiecare rulare, cine le poate consulta și cum includeți corecțiile în următoarea evaluare.

Raportul de lansare ar trebui să spună ce a fost testat, ce cazuri rămân nesusținute și ce ar determina echipa să revină la versiunea anterioară. O limită de funcționare restrânsă, dar explicită, îi permite echipei să decidă în cunoștință de cauză. Extinderea devine apoi o decizie bazată pe folosire, nu o consecință a faptului că software-ul e disponibil tehnic.

Înainte să adăugați o nouă funcție, rugați pe cineva din afara implementării să urmărească acea evidență. Poate identifica revizia sursei, decizia și responsabilul fără o explicație dată în privat? Dacă nu poate, următoarea îmbunătățire ar putea fi un panou de administrare, nu un model mai capabil.