Inginerie pe teren: construim sistemul împreună cu oamenii care îl vor folosi

Începeți acolo unde se face munca

Imaginați-vă un atelier în care primul exercițiu este doar să priviți. Un coleg deschide un document de la furnizor, copiază o cifră, verifică o a doua sursă și întreabă pe cineva dacă o excepție se mai aplică. Nu se întâmplă nimic spectaculos. Și totuși, secvența aceasta scurtă conține mare parte din sistemul pe care trebuie să-l construim: dovezi, judecată, relații și o decizie care trebuie să reziste odată consemnată. Scena e ilustrativă, dar e un loc bun de început.

Ingineria pe teren înseamnă ca inginerii să stea destul de aproape de activitate cât să-i înțeleagă constrângerile și să schimbe implementarea împreună cu oamenii care o folosesc. Unitatea de lucru utilă este un caz real, dus de la început până la sfârșit. O prezentare despre ce ar putea face AI scoate rareori la iveală transferul greoi al unei sarcini între colegi, permisiunea care lipsește sau înregistrarea care există în trei versiuni contradictorii.

Luați, ca ilustrare, o echipă de operațiuni care pregătește rezumate despre furnizori. Primul atelier ar trebui să urmeze un exemplu real, deja aprobat: de unde au venit documentele, ce cifre contează, cine verifică rezultatul și unde ajunge rezumatul. Inginerul urmărește metoda existentă a echipei înainte să propună un model sau un agent. Unii pași pot avea nevoie de căutare, alții de o interogare în baza de date, iar unul poate cere judecata unui om.

Exersați verificarea rezultatelor

Propunem ca instruirea să fie construită în jurul a trei tipuri de caz: munca obișnuită, o greșeală plauzibilă și o excepție care ar trebui să oprească procesul. Un participant ar trebui să poată explica de ce e util rezultatul, să arate ce îl susține și să recunoască momentul în care dovezile nu ajung. Faptul că termină repede un exercițiu spune mai puțin decât capacitatea lui de a-i contesta rezultatul.

The Art of Programming a contribuit la formarea acestei metode: Python și AI predate prin proiecte pe care cursanții le construiesc singuri. Într-o companie, același obicei devine un ghid scurt, exemple din fluxul de lucru aprobat și exerciții care folosesc uneltele pe care angajații le vor avea de fapt. Un coleg de la financiar, unul de la asistență și un operator tehnic au nevoie de materiale diferite.

Studiul lui Brynjolfsson, Li și Raymond despre asistența pentru clienți analizează sprijinul AI în munca de asistență și constată că efectele diferă de la un angajat la altul. Sunt dovezi dintr-un context anume, nu un randament promis pentru altă afacere. Sunt un motiv să vedem cine câștigă, cine are nevoie de mai mult sprijin și ce se schimbă în muncă, în loc să raportăm o singură cifră de adoptare pentru toată lumea.

Riscul tăcut al unui răspuns convingător

Un program de instruire poate ajunge, fără să vrea, să răsplătească fluența. Cineva învață un prompt, primește un paragraf șlefuit și pleacă mai încrezător, deși capacitatea lui de a verifica rezultatul nu s-a schimbat. Exercițiul următor ar trebui să întrerupă acest confort: prezentați un răspuns cu o afirmație plauzibilă, dar nesusținută, și cereți-i participantului să arate de unde vine.

Lee și colegii săi au chestionat profesioniști care lucrează cu informația despre folosirea AI și gândirea critică. Concluziile lor privesc efortul și încrederea declarate de participanți; un sondaj nu poate stabili că AI a provocat o pierdere de capacitate. Ridică însă o întrebare utilă pentru instruire: ce judecăți mai fac oamenii și ce acceptă fără să verifice?

Construiți exerciții care cer verificarea rezultatului modelului. Cereți-i celui care verifică să aleagă între două surse cu date diferite de intrare în vigoare. Cereți-i unui coleg de la asistență să-i explice unui client un răspuns nesigur. Cereți-i unui operator să reia un proces oprit fără să repete o acțiune deja încheiată.

Un atelier util se încheie cu întrebări mai bune din partea oamenilor care fac munca.

Îmbunătățiți sistemul pe baza experienței echipei

O sesiune de instruire este și o revizuire de design. Dacă mai mulți oameni citesc greșit aceeași stare, îmbunătățiți interfața. Dacă verificarea unui răspuns durează mai mult decât sarcina însăși, revedeți regăsirea sau formatul rezultatului. Dacă o excepție utilă e invizibilă pentru model, dați fluxului de lucru o cale sigură de a o capta. Instruirea nu ar trebui să devină un mod de a-i învăța pe oameni să compenseze la nesfârșit defecte de produs care puteau fi evitate.

Ghidurile pentru interacțiunea om–AI ale lui Amershi și ale colegilor săi dau acestei revizuiri o structură utilă: stabiliți așteptările, sprijiniți oamenii cât lucrează, ajutați-i să-și revină când sistemul greșește și permiteți adaptarea în timp. Le folosim ca punct de plecare pentru design. Unde poate cineva să conteste rezultatul și ce se întâmplă după ce o face?

Păstrați o evidență mică a cazurilor care au schimbat designul. Notați intrarea, acțiunea așteptată, ce s-a întâmplat de fapt și decizia luată împreună. Eliminați detaliile private care nu sunt necesare pentru învățare. Unele cazuri își au locul în setul de evaluare; altele cer o clarificare de politică sau o altă împărțire a responsabilității.

Verificați că echipa se descurcă singură

O predare practică îi cere unei echipe să ruleze un caz obișnuit, să corecteze un rezultat greșit și să repornească un flux oprit fără ca cel care l-a construit să preia controlul. Exercițiile scot la iveală documentația lipsă mai sigur decât întrebarea dacă toată lumea a înțeles atelierul. Desemnați pe cineva să țină materialele la zi și stabiliți când poate echipa să apeleze la ingineri.

Pentru un pilot, comparați munca acceptată, munca refăcută și timpul de verificare cu procesul anterior. Întrebați-i pe angajați unde îi ajută unealta și unde îi întrerupe. Extindeți accesul când dovezile o susțin și actualizați instruirea de fiecare dată când se schimbă fluxul de lucru. Un număr tot mai mare de autentificări nu arată, singur, că afacerea a câștigat capacitate.

• Alegeți un flux de lucru real și pe cel care răspunde de el.
• Exersați reușita, eroarea și recuperarea în uneltele aprobate.
• Transformați confuzia recurentă într-o îmbunătățire de produs.
• Verificați că echipa poate opera fără cel care a construit sistemul.

Pregătiți materiale la care echipa să poată reveni ușor

La predare, documentați limitele sistemului, câteva exemple reprezentative și pe cine pot contacta utilizatorii când au nevoie de ajutor. Răspundeți întrebărilor apărute în timpul muncii.

Programați o discuție după ce echipa folosește sistemul pe cont propriu. Revedeți cazurile în care s-a blocat și stabiliți ce trebuie schimbat în sistem sau explicat mai clar.