Dhivya Nagasubramanian, VP de Transformare și Inovare AI – Seria de Interviuri

Dhivya Nagasubramanian este VP de Transformare și Inovare AI la o instituție financiară majoră din SUA, unde conduce designul, implementarea și guvernanța sistemelor agenților AI de producție. Ea este autoarea cărții Agentic AI pentru Ingineri (Apress/Springer Nature), o ghid practic pentru construirea sistemelor autonome AI care pot fi încredințate în producție. De la lansarea sa, cartea a înregistrat peste 6.000 de accesări instituționale pe SpringerLink, deținute în peste 260 de biblioteci din întreaga lume și adoptate în universități. Ea este deținătoare a unui brevet acordat de USPTO în domeniul învățării automate aplicate. Interesele sale de cercetare includ construirea de aplicații care sunt rezistente la atacurile de jailbreak adversative și contribuția la eforturile industriale mai largi de a dezvolta modele mai bune pentru siguranța și securitatea multiculturală. Ea este un expert și vorbitor solicitat în multiple conferințe industriale și academice.

Cariera dvs. a evoluat de la consultanță pentru întreprinderi și știința datelor la conducerea transformării AI în serviciile financiare. Cum v-au influențat aceste experiențe cartea Agentic AI pentru Ingineri, și ce lacune recurente între cercetarea AI și implementarea întreprinderilor v-au convins că această carte trebuia scrisă?

Am început în 2008 construirea sistemelor de contabilitate a portofoliului și măsurarea performanței pentru platformele bancare. Unul dintre proiecte a fost un motor GIPS-compliant pentru calculul randamentelor ponderate în timp, care a fost ulterior utilizat de instituții financiare din peste 80 de țări. Acela mi-a învățat o lecție care mi-a modelat întreaga carieră. În finanțele reglementate, eșecul cel mai periculos este un număr greșit care pare corect. Un calcul subtil incorect este încredințat, raportat și acționat timp de ani, pentru că nimic nu pare defect.

Am văzut același model din nou mai târziu. Am găsit o lacună structurală în modelul Markov al unui model de atribuire a marketingului utilizat pe scară largă. Cadru a fost utilizat de sute de mii de utilizatori, iar eroarea a supraviețuit ani de zile dintr-un singur motiv: ieșirile păreau rezonabile. Când m-am mutat în transformarea AI în serviciile financiare, am văzut sisteme agenților care au repetat acest model cu riscuri mult mai mari. Un agent nu produce doar un rezultat greșit. Acesta ia acțiune pe baza lui.

Lacuna care m-a convins să scriu cartea este că cercetarea și implementarea întreprinderilor se preocupă de lucruri diferite. Cercetarea măsoară capacitatea pe bănci de testare. Întreprinderile depind de modul în care un sistem se comportă sub ambiguitate, date în schimbare și presiune adversă. Cele mai multe scrieri despre agenți se opresc la stadiul de demonstrație. Am scris Agentic AI pentru Ingineri pentru inginerul care trebuie să-și pună numele pe un sistem care va rula cu supraveghere limitată într-o instituție reglementată.

Cartea dvs. descrie trecerea de la automatizare la autonomie ca o nouă mentalitate de inginerie. Ce separă cu adevărat un agent AI autonom de un flux de lucru automatizat sofisticat, și unde sunt organizațiile mai susceptibile să confunde cele două?

Le dau echipelor un test simplu. Puteți enumera fiecare cale pe care sistemul o poate urma înainte de a-l rula? Dacă da, aveți automatizare. Poate fi o automatizare foarte sofisticată cu un model de limbaj în interiorul său, dar este încă automatizare. Dacă sistemul descompune obiective, alege instrumente și decide ordinea acțiunilor la runtime pe baza contextului pe care nu l-ați scriptat, aveți autonomie. Diferența nu are nimic de-a face cu modelul pe care îl utilizați. Se reduce la locul unde se iau deciziile.

Organizațiile confundă cele două în ambele direcții, dar doar o direcție este costisitoare. A numi un flux de lucru LLM scriptat agentic este mai mult o problemă de marketing. Greșeala costisitoare este inversă. Echipele implementează luarea deciziilor autonome sub guvernanță care a fost proiectată pentru automatizarea deterministă. Testarea lor presupune reproductibilitate. Monitorizarea lor presupune tipare de eșec cunoscute. Urmele lor de audit presupun că există o regulă trasabilă în spatele fiecărei acțiuni. Niciuna dintre aceste presupuneri nu se aplică pentru un agent.

Aceea este schimbarea de mentalitate pe care o argumentez în cartea mea. Cu automatizarea, principala întrebare este dacă sistemul a executat corect. Cu autonomia, întrebarea devine dacă sistemul a decis corect. Răspunsul la această întrebare necesită instrumentație diferită, metode de evaluare diferite și un nivel diferit de precauție.

Multe sisteme AI agențice se desfășoară impresionant în demonstrații, dar se luptă atunci când sunt expuse la utilizatori reali, date în schimbare și unelte imprevizibile. Care componente ar trebui să fie luate în considerare obligatorii într-o arhitectură de agent de producție?

Răspunsul onest este că producția necesită tot ceea ce o demonstrație vă permite să săriți peste. O demonstrație funcționează pentru că cineva a controlat mediul. Producția ia această control.

În cartea mea, descriu o arhitectură de referință cu șapte straturi, dar acestea sunt componentele pe care le consider obligatorii. Contracte de instrumente cu intrări tipizate și permisiuni explicite, astfel încât ajungerea agentului să fie limitată prin design și nu prin speranță. Managementul stării care supraviețuiește întreruperilor și eșecurilor. Gestionarea eșecului structurat cu căi de escaladare definite. O husă de evaluare care rulează continuu, nu doar o dată înainte de lansare. Și o urmă de audit care înregistrează deciziile și raționamentul din spatele lor, nu doar acțiunile întreprinse.

Componenta pe care echipele o sar peste cel mai des este verificarea la runtime. Acesta este un strat care verifică fiecare acțiune împotriva obiectivului declarat al agentului și a politicilor care se aplică. Infrastructura standard vă spune dacă un apel a reușit. Verificarea întreabă dacă apelul ar fi trebuit să fie făcut deloc. Nu-și demonstrează valoarea într-o demonstrație, pentru că nimic nu are nevoie să fie prins. În producție, este primul lucru pe care îl veți dori să-l aveți.

Cartea dvs. acoperă siguranța, alinierea, buclele de feedback, testarea, depanarea, evaluarea și implementarea. Cum ar trebui echipele de ingineri să combine aceste elemente într-un proces de asigurare continuă, mai degrabă decât să trateze siguranța ca o revizuire finală pre-lansare?

O revizuire finală se bazează pe presupunerea că sistemul pe care l-ați revizuit este sistemul care va rula. Pentru AI agențică, acea presupunere eșuează în trei moduri. Modelele subiacente sunt actualizate. Uneltele și API-urile pe care agentul le depinde se schimbă. Și datele și mediul în care agentul operează continuă să se schimbe. O revizuire de siguranță unică descrie un sistem care nu mai există câteva luni mai târziu.

Asigurarea continuă înseamnă închiderea buclei. Evaluările comportamentale rulează în CI (integrare continuă) în același mod în care rulează testele unitare, și ele blochează fiecare schimbare la prompte, unelte și modele. Monitorizarea la runtime alimentează urmele de producție înapoi în seturile de evaluare. Descriu patru modele de monitorizare în cartea mea, pentru că niciun model nu acoperă întreaga suprafață a eșecului. Fiecare incident produce o nouă verificare, în același mod în care fiecare bug ar trebui să producă un test de regresie. Și testarea adversă rulează pe un calendar regulat, în loc de a rulează o singură dată înainte de lansare.

Partea organizațională contează la fel de mult ca și partea tehnică. Siguranța nu poate fi o echipă separată care apare la sfârșit cu o listă de verificare. Inginerii care construiesc agentul ar trebui să dețină seturile de evaluare ale acestuia, invariantele și proiectarea de escaladare, pentru că știu mai bine decât oricine unde judecata sistemului este cea mai slabă.

Ați subliniat monitorizarea semantică a apelurilor de instrumente ale agentului. Ce revelează monitorizarea semantică pe care instrumentele și dispozitivele de observabilitate convenționale nu le pot, și cum poate detecta atunci când un agent este funcțional din punct de vedere tehnic, dar urmărește obiectivul greșit?

Observabilitatea convențională răspunde la o întrebare: a reușit apelul? Acoperă codurile de stare, schemele, latența și ratele de eroare. Nu poate răspunde la întrebarea care contează cel mai mult pentru agenți, care este dacă apelul ar fi trebuit să se întâmple. Un apel de instrument poate fi tehnic perfect și totuși poate fi acțiunea greșită. Format corect, credențiale valabile, răspuns reușit, lucru greșit de făcut.

Monitorizarea semantică evaluează fiecare acțiune împotriva obiectivului declarat al agentului și a politicilor care se aplică. În cartea mea, descriu acest lucru ca definirea invariantei semantice peste apelurile de instrumente ale agentului. Acestea sunt proprietăți care trebuie să se mențină indiferent de calea pe care o ia agentul. Un agent care cercetează un caz al unui client nu ar trebui să acceseze niciodată înregistrări din afara acelui caz. Un agent ar trebui să semnaleze o discrepanță peste un anumit prag, nu să o rezolve singur. Când o invariantă este încălcată, prindeți problema în momentul acțiunii, în loc de a o face într-un audit trimestrial.

Aceasta este și modul în care detectați deriva obiectivului, pe care o consider deficiența definitorie a sistemelor agențice. Deriva obiectivului pare a fi un agent care finalizează fiecare pas corect conform jurnalelor, dar lucrează în secret pentru obiectivul greșit. Nu apare niciodată într-un jurnal, pentru că nimic nu a eșuat. Monitorizarea semantică tratează intenția ca pe ceva ce se măsoară direct, iar intenția este unde agenții greșesc.

Când un agent întâmpină instrucțiuni ambigue, politici contradictorii, unelte indisponibile sau lipsă de încredere, cum ar trebui să arate gestionarea eșecului structurat? Cum pot dezvoltatorii să se asigure că sistemul se oprește, escaladează sau se recuperează, în loc să improvizeze?

Problema pe care trebuie să o proiectați împotriva este că majoritatea agenților au doar un mod de a încheia o sarcină, care este de a produce un răspuns. Când instrucțiunile sunt ambigue sau politicile sunt contradictorii, agentul improvizează. Nu pentru că modelul este nechibzuit, ci pentru că improvizația este singurul comportament pe care arhitectura îl permite. Gestionarea eșecului structurat înseamnă a oferi sistemului opțiuni mai bune și a le face mai ușor de accesat decât un răspuns inventat.

În practică, înseamnă că refuzul și escaladarea sunt proiectate și testate cu aceeași grijă ca și succesul. Recomand definirea stărilor de eșec tipizate: instrucțiune ambiguă, politică contradictorie, instrument indisponibil, lipsă de încredere. Fiecare dintre acestea se asociază cu un comportament specific. Puteți pune o întrebare de clarificare. Puteți preda unui om cu contextul complet atașat. Puteți trece la operarea în citire numai. Puteți reîncerca în limite mai strânse. Sau puteți opri. Pragurile de încredere ar trebui să corespundă riscului acțiunii specifice. Barul pentru redactarea unui rezumat intern și barul pentru atingerea unui cont de client nu ar trebui să fie niciodată același număr.

Doi practici fac acest lucru real. Primul, proiectați calea de escaladare înainte de a proiecta calea fericită. Dacă un om va primi predarea, decideți ce context va primi și ce autoritate va avea înainte de a scrie primul prompt. Al doilea, testați eșecul în același mod în care testați funcțiile. Injectați instrucțiuni ambigue. Dezactivați unelte în mediu de testare. Alimentați agentul cu politici contradictorii. Un sistem care nu a practicat niciodată eșecul va acționa fără îndrumare prima dată când se întâmplă în producție.

Instituțiile financiare trebuie să echilibreze experimentarea cu cerințe stricte în jurul confidențialității, auditabilității, riscului modelului și conformității reglementare. Unde ar trebui să rămână aprobarea umană obligatorie, și unde pot agenții să primească cu siguranță o autonomie operațională mai mare?

Regula mea este că aprobarea umană ar trebui să rămână obligatorie pentru orice acțiune care este ireversibilă, care mută bani sau afectează rezultatul unui pacient, care implică comunicări ale clienților care poartă greutate reglementară, care alimentează raportarea reglementară, sau care schimbă uneltele, politicile sau permisiunile agentului. Agenții pot primi cu siguranță o autonomie mai mare în munca de citire și înțelegere: cercetare, recuperare, analiză de documente, triaj, redactare și reconcilieri care semnalează discrepanțe pentru revizuirea umană, în loc de a le rezolva.

Greșeala comună este de a cere aprobarea umană la fiecare pas. Acest lucru nu face sistemul mai sigur. Re creează procesul manual cu pași suplimentari și antrenează reviewerii să ștampileze. Aprobările aparțin la punctele de decizie reale. Ar trebui să existe puține dintre ele, și fiecare ar trebui să fie încadrat de cineva cu autoritate reală de a spune nu.

Al doilea principiu este că autonomia ar trebui să fie câștigată, nu acordată. Începeți îngust. Extindeți pe măsură ce sistemul se dovedește sub monitorizare. Păstrați dovezi. În termeni de risc al modelului, mediul de control ar trebui să vă permită să arătați unui regulator nu doar ce a făcut agentul, ci și de ce ați fost justificați în a-i acorda acel nivel de independență. Acesta este licența reală de a opera.

Prin munca dvs. asupra garanțiilor și standardelor de inteligență artificială, sunteți implicată în definirea regulilor pentru sisteme a căror capacitate continuă să se schimbe. Care garanții pot fi standardizate realist astăzi, și care domenii rămân prea dependente de context, industrie sau caz de utilizare?

Garanțiile pe care le putem standardiza astăzi sunt structurale. Acestea necesită ca anumite controale să existe, să fie documentate și să poată fi inspectate. Capabilități și permisiuni documentate pentru sisteme autonome. Mecanisme de supraveghere umană și escaladare definite. Obligații de detectare și raportare a incidentelor. Metode de evaluare și cerințe de dovezi. Răspundere clară pe tot ciclul de viață al sistemului, astfel încât atunci când ceva merge prost, răspunsul la “cine este responsabil” nu este niciodată doar “AI-ul”. Acestea pot fi standardizate pentru că se referă la existența controalelor și la cât de bune sunt, nu la valorile specifice pe care le iau.

Ceea ce nu putem standardiza încă sunt setările însele. Praguri de încredere specifice, taxonomii de daune și niveluri de autonomie adecvate depind foarte mult de context. Toleranța la eșec acceptabilă pentru un agent de conținut de marketing și pentru un sistem care atinge decizii clinice sau financiare nu sunt două puncte pe aceeași scară. Ele aparțin unor regimuri diferite, modelate de domeniu, jurisdicție și de cine suportă daunele atunci când ceva eșuează.

Controalele financiare sunt un model util aici. Cerințele de audit sunt standardizate la nivel global, dar materialitatea este întotdeauna judecată în context. Standardele care respectă această separare tind să fie adoptate. Standardele care încearcă să dicteze valori dependente de context tind să fie ignorate, și un standard de siguranță pe care nimeni nu îl respectă nu protejează pe nimeni.

Cercetarea dvs. recentă a explorat robustețea multiculturală și adversă în evaluarea siguranței AI. Ce tipuri de eșecuri ale modelului sunt susceptibile de a fi ratate de benchmark-urile centrate pe Occident sau medii globale, și cum ar trebui întreprinderile să evalueze sistemele destinate pentru implementarea multiculturală?

Privirea doar la benchmark-urile medii poate să rateze eșecurile care contează. Un model poate posta un scor de siguranță general puternic, în timp ce eșuează grav pentru un anumit limbaj, dialect sau context cultural, pentru că aceste eșecuri dispar în medie. Evaluarea centrată pe Occident adaugă o altă punctă orb. Ratează daunele care sunt specifice cultural, cum ar fi idiome, gesturi și contexte religioase sau regionale în care aceeași ieșire este inofensivă într-o cultură și dăunătoare în alta. De asemenea, subtestează codul de schimbare a limbii, transliterarea și numele și entitățile non-occidentale. Există și un unghi advers. Atacatorii nu vizează performanța dvs. medie. Ei găsesc cel mai slab strat al dvs., și pentru majoritatea modelelor, acel strat este un limbaj cu resurse mai mici sau un context cultural mai puțin evaluat.

Acesta este ceea ce m-a atras în contribuția la cercetarea benchmark-ului de siguranță AI multiculturală. Constatarea de bază este simplă. Evaluarea siguranței pe culturi necesită date de evaluare și judecată umană din acele culturi. Nu puteți evalua daunele din afara contextului în care acestea apar.

Pentru întreprinderi, sugerez trei reguli. Evaluați fiecare segment pe care îl deserviți, și nu acceptați niciodată o medie ca dovadă. Construiți seturi de evaluare din populațiile dvs. de clienți actuali. Rulați testarea adversă în limbile pe care le folosesc clienții dvs. Dacă deserviți clienți în 40 de țări și evaluați doar în engleză, ați măsurat sistemul pentru altcineva.

Dețineți, de asemenea, un brevet acordat de Oficiul pentru Brevete și Mărci din SUA în învățarea automată aplicată. Ce problemă încercați să rezolvați, ce v-a învățat procesul despre transformarea cercetării AI în inovație practică, și ce provocare nerezolvată a agenților AI sunteți cel mai interesată să abordați în continuare?

Brevetul care a fost recent aprobat abordează o problemă de scară și coerență în revizuirea calității serviciilor financiare — revizuirea convențională a apelurilor este manuală, astfel încât reviewerii umani pot doar eșantiona o fracțiune din apeluri, iar evaluările lor variază de la o persoană la alta. Abordarea mea direcționează fiecare întrebare de calitate și conformitate către metoda cea mai potrivită pentru a o răspunde, cu fiecare decizie înregistrată și trasabilă pentru audit.

Puteți vedea aceleași teme pe care le-am descris pe tot parcursul acestui interviu. Direcționați fiecare sarcină către cel mai slab instrument care o poate face bine. Țineți oamenii în buclă acolo unde judecata contează. Și faceți fiecare decizie automată trasabilă, pentru că într-o instituție reglementată, un răspuns fără dovezi nu este un răspuns.

Procesul de brevet m-a învățat că disciplina este în detalii. Nu puteți breveta o idee vagă. Trebuie să arătați exact ce face metoda dvs. diferit, și exact unde se aplică. Acea precizie a făcut munca de bază mai bună.

Provocarea nerezolvată care mă interesează cel mai mult acum este verificarea la runtime pentru sistemele multi-agente. Definirea invariantei semantice pentru un singur agent este realizabilă. Știu, pentru că o facem în producție. Când agenții deleagă sarcini altor agenți, comportamentul devine emergent, iar eșecurile se mută în delegări. O instrucțiune este ușor reinterpretată la fiecare pas. O politică se aplică unui agent, dar nu și agentului pe care îl recrutează. Verificarea interacțiunii dintre agenți, nu doar a acțiunilor fiecăruia, este unde mă aștept să apară următoarea generație de eșecuri silențioase. Aceasta este problema pe care vreau să o abordez în continuare.

Mulțumim pentru acest interviu minunat, cititorii pot comanda cartea dvs. Agentic AI pentru Ingineri.