Dhivya Nagasubramanian, VP of AI Transformation and Innovation – Haastattelusarja

Dhivya Nagasubramanian on VP of AI Transformation and Innovation suuressa Yhdysvaltain rahoituslaitoksessa, jossa hän johtaa tuotannon agentic AI -järjestelmien suunnittelua, käyttöönottoa ja hallintoa. Hän on kirjoittanut kirjan Agentic AI for Engineers (Apress/Springer Nature), joka on käytännön opas autonomisten AI-järjestelmien rakentamiseen, joita voidaan luottaa tuotantoon. Kirjan julkaisun jälkeen siitä on tehty yli 6 000 institutionaalista käyttöä SpringerLinkissä, se on ollut yli 260 kirjastossa maailmanlaajuisesti ja se on otettu käyttöön yliopistoissa. Hän on Yhdysvaltain patentti- ja tavaramerkkiviraston myöntämä patentinomistaja sovelletussa koneoppimisessa. Hänen tutkimusintresseihinsä kuuluvat sovellusten kehittäminen, jotka kestävät vihamielisiä vankilamurtohyökkäyksiä, ja osallistuminen laajempiin teollisuuden pyrkimyksiin kehittää parempia malleja monikulttuurisen turvallisuuden ja turvallisuuden kehittämiseksi. Hän on haluttu asiantuntija ja paneelin puheenjohtaja useissa teollisuus- ja akateemisissa konferensseissa.

Ura on edennyt yritysasiakirjojen konsultoinnista ja datasta johtamaan AI-muutosta rahoituspalveluissa. Miten nämä kokemukset muokkasivat Agentic AI for Engineers -kirjaa, ja mikä toistuva aukko AI-tutkimuksen ja yritysasiakirjojen käyttöönoton välillä vakuutti sinut siitä, että tämä kirja tarvitaan?

Aloin vuonna 2008 rakentamalla salkun laskenta- ja suorituskykymittausjärjestelmiä pankkipohjaisiin alustoihin. Yksi näistä projekteista oli GIPS-yhdenmukainen moottori aikajaksoittaisen tuoton laskemiseksi, jota myöhemmin käyttivät rahoituslaitokset yli 80 maassa. Se työ opetti minulle opetuksen, joka on muokannut koko urani. Säänneltyjen rahoituslaitosten tapauksessa vaarallisimman epäonnistumisen on väärä luku, joka näyttää oikealta. Hienoisesti virheellinen laskelma luotetaan, raportoidaan ja toimintaan otetaan, koska mitään ei näytä rikkoontuneen.

Näin saman mallin myöhemmin uudelleen. Löysin rakenteellisen aukon laajasti käytetyn markkinointiattribuuttimallin Markov-mallissa. Kehyksen käyttivät satoja tuhansia käyttäjiä, ja virhe oli selvinnyt vuosia yhdestä syystä: tulosteen näytti kohtuulliselta. Kun siirryin AI-muutokseen rahoituspalveluissa, seurasin agentic-järjestelmien toistavan tämän mallin paljon korkeampien panosten kanssa. Agentti ei tuota vain väärää tulosta. Se tekee toiminnan sen perusteella.

Aukko, joka vakuutti minun kirjoittamaan kirjan, on se, että tutkimus ja yritysasiakirjojen käyttöönotto huolehtivat eri asioista. Tutkimus mitataan kyvykkyyttä vertailukohteilla. Yritykset riippuvat siitä, miten järjestelmä toimii epävarmuuden, muuttuvan datan ja vihamielisen paineen alla. Useimmat agenttien kirjoittaminen loppuu demo-vaiheeseen. Kirjoitin Agentic AI for Engineers -kirjan insinööriksi, joka on laittanut nimensä järjestelmään, joka toimii rajoitetun valvonnan alaisena säännellyssä laitoksessa.

Kirjasi kuvaa siirtymistä automaatiosta autonomiaan uutena insinöörinteenä. Mitä erottaa todella autonomisen AI-agentin sofistikoituneesta automaatioprosessista, ja missä organisaatiot ovat todennäköisesti sekoittavat nämä kaksi?

Annat ryhmille yksinkertaisen testin. Voitko luetella jokaisen polun, jonka järjestelmä voi ottaa ennen sen suorittamista? Jos kyllä, sinulla on automaatio. Se voi olla hyvin sofistikoitunut automaatio, jossa on kielen malli sen sisällä, mutta se on silti automaatio. Jos järjestelmä purkaa tavoitteita, valitsee työkaluja ja päättää toimintajärjestyksen suorittamisen aikana kontekstin perusteella, jonka et ohjelmoinut, sinulla on autonomia. Ero ei liity siihen, mikä malli käytetään. Se liittyy siihen, missä päätökset tehdään.

Organisaatiot sekoittavat nämä kaksi kumpaankin suuntaan, mutta vain toinen suunta on kallista. Kutsuminen käsikirjoitettua LLM-työkulkua agenteiksi on pääasiassa markkinointiongelma. Kalliin virhe on vastakkainen. Tiimit käyttöönottoivat todella autonomista päätöksentekoa hallinnon alaisuuteen, joka on suunniteltu deterministiseen automaatioon. Heidän testaamisensa olettaa toistettavuutta. Heidän valvontansa olettaa tunnettuja vikamalleja. Heidän auditointireitinsä olettaa, että jokaisen toiminnan taustalla on jäljitetty sääntö. Yksikin näistä oletuksista ei pidä agentille.

Se on asenne muutos, jota argumentoin kirjassa. Automaation kanssa pääkysymys on, suoritettiinko järjestelmä oikein. Autonomian kanssa kysymys muuttuu: päätti järjestelmä oikein. Vastataksesi siihen vaaditaan erilaista instrumentointia, erilaisia arviointimenetelmiä ja erilaista varovaisuutta.

Monet agentic AI -järjestelmät suoriutuvat vaikuttavasti esittelyissä, mutta kamppailevat, kun ne altistetaan todellisille käyttäjille, muuttuville tiedoille ja arvaamattomille työkaluille. Mitkä komponentit tulisi pitää pakollisina tuotantovalmiissa agenttijärjestelmässä?

Rehellinen vastaus on, että tuotanto tarvitsee kaiken, mitä demo antaa vääräksi. Esittely toimii, koska joku hallitsi ympäristöä.

Kirjassa kuvaan seitsemänkerroksisen viitearkkitehtuurin, mutta nämä ovat komponentteja, joita pidän pakollisina. Työkalusopimukset, joissa on tyypitetyt syötteet ja eksplisiittiset käyttöoikeudet, jotta agentin ulottuvuus on rajoitettu suunnittelun sijaan toivomisen kautta. Tilanhallinta, joka kestää keskeytyksiä ja virheitä. Rakenteellinen vikakäsittely määritetyillä eskaloitumispoluilla. Arviointikehys, joka suoritetaan jatkuvasti, ei kerran ennen käynnistystä. Ja auditointireitti, joka tallentaa päätökset ja niiden taustalla olevan päättelyn, ei vain toimet, jotka suoritetaan.

Komponentti, jonka tiimit useimmin ohittavat, on suoritusaikaisen verifikaatio. Tämä on kerros, joka tarkistaa jokaisen toiminnan agentin ilmoitetun tavoitteen ja sovellettavien käytäntöjen perusteella. Standardi-infrastruktuuri kertoo, onko kutsu onnistunut. Verifikaatio kysyy, olisiiko kutsu pitänyt tehdä lainkaan. Se ei koskaan osoita arvoaan esittelyssä, koska mitään ei tarvitse kiinni. Tuotannossa se on ensimmäinen asia, jota toivot olisit sen saaneen.

Kirjasi käsittelee turvallisuutta, suuntautumista, palautusilmojen, testaamista, vikojen korjaamista, arviointia ja käyttöönottoa. Miten insinöörit voivat yhdistää nämä elementit jatkuvaan varmistusprosessiin sen sijaan, että kohtelevat turvallisuutta lopullisena ennen käynnistystä tarkasteluna?

Lopullinen tarkastelu perustuu oletukseen, että tarkasteltava järjestelmä on järjestelmä, joka toimii. Agentic AI -järjestelmille tämä oletus epäonnistuu kolmella tavalla. Alimpien mallien päivitykset. Työkalut ja rajapinnat, joista agentti riippuu, muuttuvat. Ja data ja ympäristö, jossa agentti toimii, muuttuvat jatkuvasti. Yksinkertainen turvallisuustarkastelu kuvailee järjestelmää, joka ei enää ole olemassa muutaman kuukauden kuluttua.

Jatkuva varmistus tarkoittaa silmukan sulkemista. Käyttäytymisen arviointi suoritetaan CI: ssä (jatkuva integrointi) samalla tavalla kuin yksikkötestit, ja ne estävät jokaisen muutoksen syötteisiin, työkaluihin ja malleihin. Suoritusaikaisen valvonnan tuotannon jäljet syötetään takaisin arviointijoukkoihin. Kuvaan kirjassa neljä valvontamallia, koska yksikin malli ei kata koko vikapintaa. Jokainen tapaus tuottaa uuden tarkistuksen, samalla tavalla kuin jokainen bugi tuottaa regressiotestin. Ja vihamielinen testaus suoritetaan säännöllisesti aikataulun mukaan sen sijaan, että kerran ennen käynnistystä.

Organisaatiopuoli on yhtä tärkeä kuin tekninen puoli. Turvallisuus ei voi olla erillinen tiimi, joka tulee lopussa tarkastuslistan kanssa. Insinöörit, jotka rakentavat agenttia, omistavat sen arviointipaketteja, sen invariantteja ja sen eskaloitumissuunnittelua, koska he tietävät paremmin kuin kukaan muu, missä järjestelmän tuomio on heikoimmin.

Olet korostanut agenttityökalukutsujen semanttista valvontaa. Mitä semanttinen valvonta paljastaa, mitä perinteiset lokit ja havainnollistamistyökalut eivät voi, ja miten se voi havaita, kun agentti on teknisesti toimiva, mutta tavoittelee väärää kohdetta?

Perinteinen havainnollistamistyökalu vastaa yhtä kysymystä: onnistuiko kutsu? Se kattaa tilakoodit, skeemat, viiveet ja virherajat. Se ei voi vastata kysymykseen, joka on tärkein agenteille, eli pitäisikö kutsu tapahtua. Työkalukutsu voi olla teknisesti täydellinen ja silti väärä toiminta. Oikea muoto, voimassa olevat tunnistetiedot, onnistunut vastaus, väärä asia tehdä.

Semanttinen valvonta arvioi jokaisen toiminnan agentin ilmoitetun tavoitteen ja sovellettavien käytäntöjen perusteella. Kirjassa kuvaan tämän määrittämisenä semanttisia invariantteja agenttityökalukutsuille. Nämä ovat ominaisuuksia, jotka on oltava voimassa riippumatta siitä, minkä polun agentti ottaa. Agentti, joka tutkii yhden asiakkaan tapausta, ei koskaan saa käyttää asiakirjoja, jotka eivät kuulu kyseiseen tapaukseen. Agentti, joka ilmoittaa epäilyn tietyn kynnyksen ylittämisestä, ei koskaan ratkaise sitä itse. Kun invariantti rikkoontuu, havaitset ongelman toiminnan hetkellä sen sijaan, että neljännesvuosittaisessa tarkastuksessa.

Tämä on myös se, miten havaitset tavoitteen siirtymisen, jonka pidän agentic-järjestelmien määrittävänä epäonnistumisena. Tavoitteen siirtymä näyttää agentilta, joka suorittaa jokaisen vaiheen oikein lokien mukaan, mutta hiljaisesti työskentelee väärän tavoitteen eteen. Se ei koskaan näy lokissa, koska mitään ei epäonnistunut. Semanttinen valvonta kohdeltaa aikomusta suoraan, ja aikomus on se, missä agentit menevät väärään.

Kun agentti kohtaa epäselvät ohjeet, ristiriitaiset käytännöt, ei saatavilla olevat työkalut tai riittämätön luottamus, miltä tulisi näyttää rakenteellinen vikakäsittely? Miten kehittäjät voivat varmistaa, että järjestelmä pysähtyy, eskaloituu tai palautuu sen sijaan, että improvisoi?

Ongelma, jota on suunniteltava, on, että useimmat agentit ovat vain yksi tapa lopettaa tehtävä, joka on tuottaa vastaus. Kun ohjeet ovat epäselvät tai käytännöt ovat ristiriidassa, agentti improvisoi. Ei siksi, että malli on lailla, vaan siksi, että improvisointi on ainoa käyttäytyminen, jonka arkkitehtuuri sallii. Rakenteellinen vikakäsittely tarkoittaa antamista järjestelmälle parempia vaihtoehtoja ja tekemistä niistä helpompia kuin keksitty vastaus.

Käytännössä se tarkoittaa, että kieltäminen ja eskaloituminen on suunniteltu ja testattu samalla tavalla kuin onnistuminen. Suosittelen määrittämistä tyypitetyistä vikatiloista: epäselvä ohje, ristiriitainen käytäntö, ei saatavilla oleva työkalu, riittämätön luottamus. Kukin niistä vastaa tiettyä käyttäytymistä. Kysy selvitys kysymys. Käsi asiakas ihmiselle täydellisen asiayhteyden kanssa. Laske ainoastaan lukuoikeuksilla. Uudelleenyritys tiukemmissa rajoissa. Tai lopeta. Luottamussuureet tulisi vastata toiminnan riskiä. Rajapinta sisäisen yhteenvetokirjan luomiselle ja asiakastilitoiminnan koskettelemiselle ei koskaan ole sama luku.

Kaksi käytäntöä tekee tämän todeksi. Ensinnäkin suunnittele eskaloitumispolku ennen onnistumista. Jos ihminen vastaanottaa käsin, päättää, mitä asiayhteyttä he saavat ja mitä valtuuksia heillä on, ennen kuin kirjoitat ensimmäisen ohjauksen. Toiseksi testaa vikaa samalla tavalla kuin testaat ominaisuuksia. Ruoki agentille epäselvät ohjeet. Poista työkalut esirunnossa. Syötä agentille ristiriitaiset käytännöt. Järjestelmä, joka ei ole koskaan harjoitellut epäonnistumista, toimii ilman ohjausta, kun se tapahtuu tuotannossa.

Rahoituslaitokset on tasapainotettava kokeilun ja tiukkojen vaatimusten välillä yksityisyyden, auditoinnin, malliriskin ja sääntelyn noudattamisessa. Missä inhimillinen hyväksyntä tulisi pysyä pakollisena, ja missä agenteille voidaan antaa turvallisesti suurempaa toimintavalmiutta?

Minun sääntöni on, että inhimillinen hyväksyntä tulisi pysyä pakollisena kaikissa toimissa, jotka ovat peruuttamattomia, jotka liikkuvat rahaa tai vaikuttavat potilaan lopputulokseen, jotka liittyvät asiakasviestintään, jolla on sääntelyn painoarvo, jotka syötetään sääntelystä raportointiin tai jotka muuttavat agentin omia työkaluja, käytäntöjä tai valtuuksia. Agentit voivat ottaa enemmän toimintavalmiutta lukemis- ja päättelytyössä: tutkimus, hakeminen, asiakirjojen analyysi, priorisointi, luonnos, sovittaminen, joka lippaa epäilyn ihmisen tarkastelua varten eikä ratkaise sitä itse.

Yleinen virhe on edellyttää inhimillistä hyväksyntää jokaisessa vaiheessa. Se ei tee järjestelmää turvallisemmaksi. Se luo manuaalisen prosessin ja kouluttaa tarkastajat leimaamaan sen. Hyväksynnät kuuluvat todellisiin päätöspisteisiin. Niitä tulisi olla vain muutamia, ja jokaisen tulisi olla henkilö, jolla on todellinen valta sanoa ei.

Toinen periaate on, että autonomia tulisi ansaita, ei myöntää. Aloita kapealla. Laajenna, kun järjestelmä osoittaa itsensä valvontaan. Säilytä näyttö. Malliriskin kannalta ohjausympäristösi tulisi antaa sinun näyttää sääntelijälle, että mitä agentti teki, ja miksi olit oikeutettu antamaan sille sen tason itsenäisyyttä. Tuo on todellinen toimilupa.

Tehtävänne teollisuuden turvallisuuden ja standardien parissa on määritellä sääntöjä järjestelmille, joiden kyvyt jatkuvasti muuttuvat. Mitkä turvallisuuden varmistuskeinot voidaan standardisoida tänään, ja mitkä alueet ovat edelleen riippuvaisia kontekstista, alasta tai käyttötarkoituksesta?

Turvallisuuden varmistuskeinot, joita voidaan standardisoida tänään, ovat rakenteellisia. Ne edellyttävät, että tiettyjä valvontatoimia on olemassa, ne on dokumentoitu ja niitä voidaan tarkastella. Dokumentoitu kyky- ja valtuutusrajat autonomisille järjestelmille. Määritellyt inhimillisen valvonnan ja eskaloitumismekanismit. Ilmoitusvelvollisuudet ja arviointimenetelmät. Selkeä vastuu järjestelmän elinkaaren aikana, jotta kun jotain menee pieleen, vastaus siihen, kuka on vastuussa, ei koskaan ole vain AI. Nämä voidaan standardisoida, koska ne koskevat valvontatoimien olemassaoloa ja niiden laatua, ei niiden arvoja.

Mitä me emme voi vielä standardisoida, ovat itse asetukset. Tiettyjen luottamussuureiden, vahinkojen luokittelujen ja sopivan autonomiatason määritys riippuu voimakkaasti kontekstista. Sallittu epäonnistumisen sietäminen markkinointiin tarkoitettujen sisältöagenttien ja järjestelmien, jotka koskettelevat kliinisiä tai taloudellisia päätöksiä, eivät ole kaksi pistettä samalla asteikolla. Ne kuuluvat eri järjestelmiin, jotka muotoilee ala, hallintoalue ja kuka kärsii vahinkoa, kun jotain menee pieleen.

Rahoitussäännöt ovat hyödyllinen malli tässä. Auditvaatimukset ovat standardisoituja maailmanlaajuisesti, mutta materiaalinen arvo arvioidaan aina kontekstissa. Standardit, jotka kunnioittavat tätä jakoa, ovat yleensä hyväksyttyjä. Standardit, jotka yrittävät määrätä kontekstiriippuvaisia arvoja, usein jäävät huomiotta, ja turvallisuussääntö, jota kukaan ei noudata, ei suojaa ketään.

Viimeaikaiset tutkimuksesi ovat käsittelleet monikulttuurista ja vihamielistä kestävyyttä AI-turvallisuuden arvioinnissa. Mitkä mallin epäonnistumiset ovat todennäköisesti väärin Länsimaisen tai globaalisti keskitetyjen vertailukohteiden vuoksi, ja miten yritykset voivat arvioida järjestelmiä, jotka on tarkoitettu monikulttuuriseen käyttöön?

Katse vain keskitetyille vertailukohteille voi jättää väärät virheet. Malli voi julkaista vahvan yleisen turvallisuuspisteen, kun taas se epäonnistuu pahasti tietyssä kielessä, murteessa tai kulttuurisessa kontekstissa, koska nämä virheet katoavat keskiarvoon. Länsimaisen arvioinnin lisää toisen sokean tilan. Se jättää väärät kulttuurisesti spesifiset vahingot, kuten idiomeja, elekieltä ja uskonnollisia tai alueellisia konteksteja, joissa sama tuloste on vaaraton yhdessä kulttuurissa ja vahingollinen toisessa. Se myös alitestailee koodinvaihtoa, translitterointia ja ei-länsimaisia nimiä ja entiteettejä. On myös vihamielinen kulma. Hyökkääjät eivät kohdistaa keskimääräistä suorituskykyä. He löytävät heikoimman viipaleen, ja useimmissa malleissa se viipale on matalaresurssinen kieli tai alitehokas kulttuurinen konteksti.

Tämä on se, mikä veti minut osallistumaan monikulttuuriseen AI-turvallisuuden vertailuun. Ydinlöytö on suora. Kulttuurien turvallisuuden arvioiminen vaatii arviointidataa ja inhimillistä arviointia, joka on peräisin näistä kulttuureista. Et voi arvioida vahinkoa kontekstista, jossa se tapahtuu.

Yrityksille suosittelen kolmea sääntöä. Arvioi jokainen segmentti, jonka palvelet, ja älä koskaan hyväksy keskiarvoa todisteena. Rakenna arviointijoukkoja todellisista asiakasväestöistäsi. Suorita vihamielinen testaus kielillä, joita asiakkaasi käyttävät. Jos palvelet asiakkaita 40 maassa ja arvioit vain englanniksi, olet mitannut järjestelmääsi jonkun toisen käyttöön.

Sinulla on myös myönnetty Yhdysvaltain patentti- ja tavaramerkkiviraston myöntämä patentti sovelletussa koneoppimisessa. Mikä ongelma yritit ratkaista, mitä prosessi opetti sinulle AI-tutkimuksen käytännön innovaatioksi muuttamisesta, ja mikä ratkaistava agentic AI -haaste kiinnostaa sinua eniten seuraavaksi?

Hyväksytty patentti koskee mittakaava- ja johdonmukaisuusongelmaa rahoituspalvelujen laadun tarkastelussa – perinteinen puhelun tarkastelu on manuaalista, joten ihmiset voivat vain näytteitä puheluista, ja heidän arviointinsa vaihtelevat henkilökohtaisesti. Lähestymistapani ohjaa jokaisen laadun ja noudattamisen kysymyksen menetelmään, joka on parhaiten sovellettavissa vastaamaan siihen, ja jokainen päätös on kirjattu ja jäljitettävissä tarkastelua varten.

Voit nähdä samat teemat, joita olen kuvannut koko haastattelun ajan. Ohjaa jokainen tehtävä työkaluun, joka on sopivin tehtävän suorittamiseen. Pitä inhimillinen osallistuminen silmukassa, missä tuomio on tärkeää. Ja tee jokainen automaattinen päätös jäljitettäväksi, koska säännellyssä laitoksessa vastaus ilman näyttöä ei ole vastaus.

Patenttiprosessi opetti minulle, että tarkkuus on yksityiskohtaisissa tiedoissa. Et voi patentoida epämääräistä ideaa. Sinun on osoitettava tarkasti, mitä menetelmäsi tekee eri tavalla, ja missä se soveltuu. Tämä tarkkuus paransi perustavaa työtä.

Ratkaistamaton haaste, josta välittäisin eniten nyt, on suoritusaikainen verifikaatio moniagenttijärjestelmissä. Määrittäminen semanttisia invariantteja yhdelle agentille on hallittavissa. Tiedän, koska teemme sen tuotannossa. Kun agentit siirtävät työtä muille agenteille, käyttäytyminen muuttuu emergoivaksi, ja virheet siirtyvät käsiin. Ohje tulkitaan hieman uudelleen jokaisessa vaiheessa. Käytäntö soveltuu yhteen agenttiin, mutta ei agenttiin, jonka se palkkaa. Verifioimalla vuorovaikutusta agenteiden välillä, ei vain yksittäisten agenttien toimintaa, odotan, että seuraava sukupolvi hiljaisia epäonnistumisia ilmestyy. Se on ongelma, jota haluan seuraavaksi ratkaista.

Kiitos hienosta haastattelusta, lukijat voivat myös tilata hänen kirjansa Agentic AI for Engineers.