Dhivya Nagasubramanian, AI Dönüşümü ve Yeniliklerden Sorumlu Başkan – Röportaj Serisi

Dhivya Nagasubramanian, büyük bir ABD finans kuruluşunda AI Dönüşümü ve Yeniliklerden Sorumlu Başkan olarak, üretim agentic AI sistemlerinin tasarımı, dağıtımı ve yönetiminden sorumludur. Agentic AI for Engineers (Apress/Springer Nature) kitabının yazarıdır. Kitap, üretimde güvenle kullanılabilen otonom AI sistemleri oluşturmak için pratik bir rehberdir. Kitabın yayınlanmasından bu yana, SpringerLink’te 6.000’den fazla kurumsal erişim, dünya çapında 260’den fazla kütüphanede tutulma ve üniversitelerde benimsenme kaydedilmiştir. Uygulamalı makine öğrenimi alanında USPTO tarafından verilen bir patent sahibidir. Araştırma ilgi alanları, adversarial jailbreak saldırılarına karşı dayanıklı uygulamalar oluşturmayı ve daha iyi güvenlik ve güvenlik modelleri geliştirmeye yönelik endüstri çapında çabaları içerir. Çok sayıda endüstri ve akademik konferansta aranan bir uzman konuşmacı ve panelisttir.

Kariyeriniz, empresa danışmanlığı ve veri biliminden finansal hizmetlerde AI dönüşümüne liderlik etmeye doğru ilerledi. Bu deneyimler Agentic AI for Engineers’ı nasıl şekillendirdi ve AI araştırması ile empresa dağıtımı arasındaki tekrarlanan boşluğu size bu kitabın yazılması gerektiğini nasıl ikna etti?

2008’de bankacılık platformları için portföy muhasebe ve performans ölçüm sistemleri oluşturmaya başladım. Bu projelerden biri, 80’den fazla ülkedeki finansal kurumların tarafından kullanılan bir GIPS uyumlu zaman ağırlıklı getiriler hesaplayıcısıydı. Bu iş, kariyerimi şekillendiren bir ders öğretti. Düzenlenmiş finansmanda, en tehlikeli başarısızlık, doğru görünmesine rağmen yanlış bir numaradır. Bir hesaplamada küçük bir hata, yıllarca sürebilir, çünkü hiçbir şey bozulmamış gibi görünür.

Daha sonra aynı kalıbı tekrar gördüm. Geniş olarak kullanılan bir pazarlama atıf modelinin Markov modelindeki bir yapısal boşluğu buldum. Çerçeve, yüz binlerce kullanıcı tarafından kullanılmış ve hatası yıllarca boyunca bir nedenle hayatta kalmıştı: çıktılar makul görünüyordu. AI dönüşümüne finansal hizmetlerde geçiş yaptığımda, agentic sistemlerin bu kalıbı çok daha yüksek bahislerle tekrarladığını izledim. Bir ajan sadece yanlış bir sonuç üretmez. Ona dayanarak eylem alır.

Bana kitabın yazılması gerektiğini ikna eden boşluk, araştırma ve empresa dağıtımı farklı şeylere önem verir. Araştırma, yeteneklerini benchmark’larda ölçer. Şirketler, bir sistemin belirsizlik, değişen veriler ve adversarial baskı altında nasıl davranacağına bağlıdır. Çoğu ajan yazısı demo aşamasında durur. Agentic AI for Engineers’ı, bir sistemi sınırlı denetimle çalıştıracak mühendis için yazdım.

Kitabınız, otomasyondan otonomiye geçişi yeni bir mühendislik zihniyeti olarak tanımlar. Gerçekten bir otonom AI ajanını, gelişmiş bir otomatik iş akışından ayıran nedir ve şirketler bu ikisini karıştırmaya en çok nerede eğilimlidir?

Ekibe basit bir test yaparım. Sistemin alabileceği her yolu çalıştırmadan önce listeleyebilir misiniz? Evet ise, otomasyona sahipsiniz demektir. Bu, içinde dil modeli olan çok gelişmiş bir otomasyon olabilir, ancak yine de otomasyondur. Sistem, çalışma zamanında bağlamınıza göre hedefleri parçalar, araçları seçer ve eylemlerin sırasını belirlerse, otonomiye sahipsiniz demektir. Fark, kullanılan modelle ilgili değildir. Kararlar nerede alındığına bağlıdır.

Şirketler her iki yönde de bu ikisini karıştırır, ancak sadece bir yön pahalıdır. Bir betiği agentic olarak adlandırmak, çoğunlukla bir pazarlama sorunudur. Pahalı hata, tersi yöndür. Gerçekten otonom karar alma, deterministik otomasyon için tasarlanan yönetim altında dağıtılır. Testleri, tekrarlanabilirliği varsayar. İzleme, bilinen hata modellerini varsayar. Denetim izi, her eylemin arkasında izlenebilir bir kural olduğunu varsayar. Hiçbiri, bir ajan için geçerli değildir.

Bu, kitabında savunduğum zihniyet değişimidir. Otomasyonla, ana soru, sistemin doğru bir şekilde çalışıp çalışmadığıdır. Otonomiyle, soru, sistemin doğru bir şekilde karar alıp almadığı haline gelir. Buna cevap verebilmek için farklı araçlara, farklı değerlendirme yöntemlerine ve daha yüksek bir dikkat seviyesine ihtiyaç vardır.

Çok sayıda agentic AI sistemi, gösterilerde etkileyici bir performans sergiler, ancak gerçek kullanıcılar, değişen veriler ve öngörülemez araçlarla karşılaştıklarında mücadele eder. Üretim için hazır bir ajan mimarisinde hangi bileşenlerin zorunlu olarak dikkate alınması gerekir?

Samimi cevap, üretim için atlanan her şeyin gerekli olduğudur. Bir gösteri, çevre kontrolü nedeniyle çalışır. Üretim, bu kontrolü ortadan kaldırır.

Kitapta, yedi katmanlı bir referans mimari tanımlarım, ancak zorunlu olarak dikkate aldığım bileşenler şunlardır: Araç sözleşmeleri, tipik girişler ve açık izinlerle, ajanın erişimi tasarım tarafından sınırlıdır, umut tarafından değil. State yönetimi, kesintiler ve arızalar sonrasında hayatta kalır. Yapılandırılmış hata işleme, tanımlı escalation yollarıyla. Sürekli çalışan bir değerlendirme kılıfı, yalnızca başlatmadan önce değil. Ve ajanın stated hedefine ve uygulanan politikalarına karşı eylemlerini ve nedenlerini kaydeden bir denetim izi, yalnızca alınan eylemleri değil.

Ekibin en çok atladığı bileşen, çalışma zamanı doğrulamasıdır. Bu, her eylemi ajanın belirtilen hedefine ve uygulanan politikalarına karşı kontrol eden bir katmandır. Standart altyapı, çağrının başarılı olup olmadığını söyler. Doğrulama, çağrının yapılmak zorunda olup olmadığını sorar. Bir demo için kanıtını asla gösteremez, çünkü hiçbir şey yakalanmaz. Üretimde, ilk isteyeceğiniz şey budur.

Kitabınız, güvenlik, hizalama, geri bildirim döngüleri, test, hata ayıklama, değerlendirme ve dağıtım konularını kapsar. Mühendislik ekipleri, bu öğeleri bir sürekli güvence süreci olarak birleştirmek yerine, güvenliği son bir ön lansman incelemesi olarak mı tedavi etmelidir?

Bir son inceleme, gözden geçirdiğiniz sistemin çalışacak sistem olduğu varsayımına dayanır. Agentic AI için, bu varsayım üç şekilde başarısız olur. Altta yatan modeller güncellenir. Ajanın bağımlı olduğu araçlar ve API’ler değişir. Ve ajanın çalıştığı veri ve ortam sürekli değişir. Bir defaya mahsus güvenlik incelemesi, birkaç ay sonra artık mevcut olmayan bir sistemi tanımlar.

Sürekli güvence, döngüyü kapatmak demektir. Davranışsal değerlendirmeler, birimin testleri gibi CI’de çalışır ve her model, araç ve.prompt değişikliğine karşı kapalıdır. Çalışma zamanı izleme, üretim izlerini değerlendirme kümelerine geri besler. Kitapta dört izleme modeli tanımlarım, çünkü hiçbir model tüm hata yüzeyini kapsamaz. Her olay, bir regresyon testi ürettiği gibi yeni bir kontrol üretir. Ve adversarial test, lansmandan önce değil, düzenli bir zamanlamayla çalışır.

Organizasyonel taraf, teknik taraf kadar önemlidir. Güvenlik, sonuna kadar gelen ayrı bir ekip olamaz. Ajanı inşa eden mühendisler, değerlendirme suitlerini, değişmezlerini ve escalation tasarımını sahip olmalıdır, çünkü sistemdeki yargının en zayıf olduğu yerleri onlar daha iyi bilir.

Siz, ajan araç çağrılarının semantik izlemesini vurguladınız. Semantik izleme, geleneksel günlükler ve gözlemlenebilirlik araçlarından neler ortaya çıkarır ve bir ajanın teknik olarak işlevsel olmasına rağmen yanlış bir hedefi izlemesi nasıl tespit edilebilir?

Geleneksel gözlemlenebilirlik, bir soru cevaplar: çağrı başarılı mıydı? Durum kodlarını, şemaları, gecikme ve hata oranlarını kapsar. Ancak ajanlar için en önemli olan soruyu cevaplayamaz: çağrı gerçekleşmeli miydi? Bir araç çağrısı teknik olarak mükemmel olabilir ve yine de yanlış eylem olabilir. Doğru format, geçerli kimlik bilgileri, başarılı yanıt, yanlış şey yapmak.

Semantik izleme, her eylemi ajanın belirtilen hedefine ve uygulanan politikalarına karşı değerlendirir. Kitapta, bu, ajan araç çağrıları üzerinde semantik değişmezler tanımlamak olarak tanımlanır. Bunlar, ajanın aldıkları yoldan bağımsız olarak tutulması gereken özelliklerdir. Bir müşteri dosyasını araştıran bir ajan, nunca bu dosyanın dışındaki kayıtlara erişmemelidir. Bir ajan, belirli bir eşiğin üzerinde bir tutarsızlığı bayrak olarak işaretlemelidir, asla kendi başına çözmemelidir. Bir değişmez ihlal edildiğinde, eylemin anında problemi yakalarsınız, değil bir yıllık denetimde.

Bu, goal drift’i, yani agentic sistemlerin tanımlayıcı başarısızlığını tespit etmenin de bir yoludur. Goal drift, günlüklerde hiçbir şeyin başarısız olmadığı halde, her adımda doğru bir şekilde tamamlanan bir ajanı andırır, ancak sessizce yanlış bir hedefi izler. Günlüklerde görünmez, çünkü hiçbir şey başarısız olmaz. Semantik izleme, niyeti doğrudan ölçen bir şey olarak ele alır ve ajanlar yanlış gittiği yer burasıdır.

Bir ajan, belirsiz talimatlar, çelişen politikalar, mevcut olmayan araçlar veya yetersiz güvenle karşılaştığında, yapılandırılmış hata işleme nasıl olmalıdır? Geliştiriciler, sistemin duraklaması, escalation veya kurtarılması yerine nasıl improvisasyon yapmasını önleyebilir?

Tasarlanacak problem, çoğu ajanın sadece bir görevi bitirmek için bir yolu olduğudur: bir cevap üretmektir. Talimatlar belirsiz veya politikalar çeliştiğinde, ajan improvisasyon yapar. Modelin sorumsuz olması nedeniyle değil, mimarinin sadece bu davranışı izin vermesi nedeniyle. Yapılandırılmış hata işleme, sistemlere daha iyi seçenekler sunmayı ve bunları bir cevap uydurmak kadar kolay hale getirmeyi içerir.

Uygulamada, bu, başarısızlık durumlarının tasarlandığı ve test edildiği anlamına gelir. İstenen başarısızlık durumları: belirsiz talimat, çelişen politika, mevcut olmayan araç, yetersiz güven. Her biri belirli bir davranışa karşılık gelir. Bir açıklama sorusu sorun. Tam bağlam ile birlikte bir insana devredin. Salt okunur işlemeye geçin. Daha dar sınırlar içinde yeniden deneyin. Ya da durun. Güven eşikleri, spesifik eylemin riskine karşılık gelmelidir. Bir iç özeti oluşturma eşiği ve bir müşteri hesabına dokunmanın eşiği asla aynı sayı olmamalıdır.

İki uygulama, bunu gerçeğe dönüştürür. İlk olarak, escalation yolunu mutlu yol önce tasarlayın. Bir insan devralacaksa, hangi bağlamı alacağını ve hangi yetkiye sahip olacağını, ilk prompt’u yazmadan önce kararlaştırın. İkincisi, başarısızlığı, özellikler gibi test edin. Belirsiz talimatlar enjekte edin. Araçları devre dışı bırakın. Çelişen politikalar besleyin. Üretimde ilk kez olduğunda, bir rehbersiz eylem gerçekleştirecek bir sistem, hiçbir zaman başarısızlık uygulamış olmaz.

Finansal kurumlar, deneyimi katı gereksinimlerle dengeler: gizlilik, denetlenebilirlik, model riski ve düzenleyici uyum. İnsan onayı nerede zorunlu kalmalıdır ve ajanlara nerede daha büyük operasyonel otonomi güvenli bir şekilde verilebilir?

Kuralım, insan onayı, geri alınamaz bir eylem, para hareketi veya bir hastanın sonucunu etkileyen bir eylem, düzenleyici ağırlığa sahip müşteri iletişimleri, düzenleyici raporlama beslemeleri veya ajanın kendi araçlarını, politikalarını veya izinlerini değiştiren bir eylem için kalmalıdır. Ajanlar, okuma ve akıl yürütme işlerinde daha fazla otonomi alabilir: araştırma, belge analizi, triyaj, taslaklar ve insan inceleme için tutarsızlıkları bayrak olarak işaretleyen uzlaştırmalar.

Ortak hata, her adımda insan onayı gerektirmektir. Bu, sistemi daha güvenli yapmaz. Elle işlenen bir süreci yeniden yaratır ve inceleyicileri rubber stamp’e eğitir. Onaylar, gerçek karar noktalarında olmalıdır. Bunların az olması ve her birinin gerçek otoriteye sahip olması gerekir.

Diğer ilke, otonominin verilmesi yerine kazanıldığıdır. Dar başlayın. İzleme altında kendini kanıtladıkça genişletin. Delili tutun. Model riski terimleriyle, kontrol ortamınız, düzenleyiciye sadece ajanın ne yaptığını değil, neden bu düzeyde bağımsızlığa sahip olmasını haklı çıkardığınızı göstermenize izin vermelidir. Bu kayıt, gerçek olarak işletme ruhsatınızdır.

Yapay zeka güvence ve standartları üzerine çalışmanız, sürekli değişen yeteneklere sahip sistemler için kuralların belirlenmesine yardımcı oluyor. Hangi güvenceler bugün gerçekçi bir şekilde standardize edilebilir ve hangi alanlar masih çok fazla bağımlıdır: bağlam, endüstri veya kullanım durumu?

Şu anda standardize edilebilecek güvenceler yapısal güvencelerdir. Belirli kontrollerin var olduğunu, belgeli olduğunu ve incelenebileceğini gerektirir. Otonom sistemler için belgelendirilmiş yetenek ve izin sınırları. Tanımlı insan denetimi ve escalation mekanizmaları. Olay algılama ve raporlama yükümlülükleri. Değerlendirme yöntemleri ve kanıt gereksinimleri. Sistem yaşam döngüsü boyunca açık hesap verebilirlik, böylece bir şey yanlış gittiğinde, AI’nin sorumlu olduğu cevabı asla değildir. Bunlar standardize edilebilir, çünkü kontrollerin varlığına ve ne kadar iyi olduğuna ilişkinlerdir, değil spesifik değerlerine.

Standardize edilemeyenler, ayarlar kendileridir. Spesifik güven eşikleri, zarar taksonomileri ve uygun otonomi seviyeleri, bağlama, endüstriye ve kullanım durumuna bağlı olarak büyük ölçüde farklılık gösterir. Pazarlama içeriği ajanı için kabul edilebilir başarısızlık toleransı ve klinik veya finansal kararlar alanındaki bir sistem için tolerans aynı ölçekte iki nokta değildir. Farklı rejimlere aittirler, alan, yargı ve zararın kime ait olduğu tarafından şekillenirler.

Finansal kontroller, burada faydalı bir modeldir. Denetim gereksinimleri küresel olarak standardize edilmiştir, ancak malzeme her zaman bağlam içinde değerlendirilir. Bağlamı saygı gösteren standartlar, benimsenme eğilimindedir. Bağlam bağımlı değerleri dikte etmeye çalışan standartlar, genellikle göz ardı edilir ve bir güvenlik standardı, hiç kimsenin uymadığı bir standardı korumaz.

Son araştırmalarınız, AI güvenliği değerlendirmesinde çok kültürlü ve adversarial dayanıklılığa odaklandı. Western-merkezli veya küresel olarak ortalama benchmark’ler tarafından kaçırılacak olan türden model hataları nelerdir ve şirketler, çok kültürlü dağıtıma yönelik sistemleri nasıl değerlendirmelidir?

Yalnızca ortalama benchmark’lere bakmak, önemli olan hataları kaçırmaya neden olabilir. Bir model, genel bir güvenlik puanı post edebilir, ancak belirli bir dil, lehçe veya kültürel bağlam için kötü bir şekilde başarısız olabilir, çünkü bu hatalar ortalama içinde kaybolur. Western-merkezli değerlendirme, başka bir kör nokta ekler. Kültürel olarak spesifik zararları, yani bir kültürde zararsız ancak başka bir kültürde zararlı olan aynı çıktıları kaçırır. Ayrıca, kod değiştirme, transliterasyon ve Batı dışı isimler ve varlıkları yeterli şekilde test etmez. Bir adversarial açı da vardır. Saldırganlar, ortalama performansınıza saldırmazlar. En zayıf dil veya kültürel bağlamı bulurlar ve çoğu model için bu dil, en zayıf noktadır.

Bu, beni çok kültürlü AI güvenliği benchmark araştırmalarına katkıda bulunmaya yöneltti. Temel bulgu basittir. Güvenlik, değerlendirme verisi ve insan yargısı, zararın meydana geldiği bağlamdan alınmalıdır.

Şirketler için üç kural öneririm. Hizmet ettiğiniz her segmenti değerlendirin ve asla bir ortalamayı kanıt olarak kabul etmeyin. Değerlendirme kümelerini gerçek müşteri nüfusunuzdan inşa edin. Adversarial testleri, müşterilerinizin kullandığı dillerde çalıştırın. Müşterilerinizi 40 ülkede hizmet ediyorsanız ve sadece İngilizce değerlendirdiyseniz, sisteminizi başka bir dağıtım için ölçmüş olursunuz.

Ayrıca, uygulamalı AI’de bir Birleşik Devletler Patent ve Ticaret Ofisi tarafından verilen patentin sahibisiniz. Hangi problemi çözmeye çalışıyordunuz, süreç size AI araştırmalarını pratik bir yeniliğe nasıl dönüştürmeyi öğretti ve hangi çözülmemiş agentic AI zorluğunu çözmeye en çok ilgi duyuyorsunuz?

Onaylanan patent, finansal hizmetlerde kalite incelemesi için bir ölçek ve tutarlılık sorununu ele alır – geleneksel çağrı incelemesi manuel olduğundan, insan inceleyiciler sadece çağrıların bir kısmını örnekleyebilir ve değerlendirmeleri kişiden kişiye değişir. Yaklaşımım, her kalite ve uyumluluk sorusunu, onu cevaplayabilecek en uygun yönteme yönlendirir ve her karar günlüğe kaydedilir ve denetim için izlenebilir.

Aynı temaları, bu röportaj boyunca tanımladığım gibi görebilirsiniz. Her görevi, onu iyi yapabilecek en az güçlü aracıya yönlendirin. İnsan yargısında önemli olan yerlerde insanları döngüde tutun. Ve her otomatik kararı, bir cevap olmadan bir cevap olarak kabul edilemeyeceği şekilde izlenebilir kılın.

Patent süreci, disiplinin ayrıntılarda olduğunu öğretti. Belirsiz bir fikir için patent alamazsınız. Yönteminizin farklı olarak ne yaptığını ve nerede uygulandığını tam olarak göstermeniz gerekir. Bu kesinlik, altta yatan işi daha iyi yaptı.

Şu anda en çok önem verdiğim çözülmemiş zorluk, çoklu ajan sistemleri için çalışma zamanı doğrulamasıdır. Tek bir ajan için semantik değişmezler tanımlamak yönetilebilir. Üretimde yapıyoruz, çünkü. Ancak ajanlar diğer ajanlara görevler devrederken, davranışlar ortaya çıkar ve hatalar, el değişimlerine girer. Bir talimat slightly yanlış yorumlanır. Bir politika, bir ajana uygulanır, ancak o ajanın işe aldığı ajana uygulanmaz. Ajanların, yalnızca herbirinin eylemlerinin değil, birbirleriyle etkileşimlerinin de doğrulanması, sessiz başarısızlıkların ortaya çıkacağı yer burasıdır. Bu, çalışmak istediğim próximo problemidir.

Harika röportaj için teşekkür ederiz, okuyucular ayrıca Agentic AI for Engineers kitabını sipariş edebileceklerdir.