Dhivya Nagasubramanian, Wakil Presiden Transformasi dan Inovasi AI – Seri Wawancara

Dhivya Nagasubramanian adalah Wakil Presiden Transformasi dan Inovasi AI di sebuah lembaga keuangan besar di Amerika Serikat, di mana dia memimpin desain, penerapan, dan tata kelola sistem AI agenik produksi. Dia adalah penulis Agentic AI for Engineers (Apress/Springer Nature), sebuah panduan praktis untuk membangun sistem AI otonom yang dapat dipercaya dalam produksi. Sejak dirilis, buku ini telah mencatat lebih dari 6.000 akses lembaga di SpringerLink, penyimpanan di lebih dari 260 perpustakaan di seluruh dunia, dan adopsi di seluruh universitas. Dia adalah pemegang paten yang diberikan oleh USPTO di bidang pembelajaran mesin terapan. Minat risetnya termasuk membangun aplikasi yang resisten terhadap serangan jailbreak lawan dan menyumbang upaya industri yang lebih luas untuk mengembangkan model yang lebih baik untuk keamanan dan keselamatan multibudaya. Dia adalah seorang ahli yang dicari dan panelis di berbagai konferensi industri dan akademik.

Karir Anda telah berkembang dari konsultasi perusahaan dan ilmu data menjadi memimpin transformasi AI dalam jasa keuangan. Bagaimana pengalaman tersebut membentuk Agentic AI for Engineers, dan apa kesenjangan berulang antara penelitian AI dan penerapan perusahaan yang meyakinkan Anda bahwa buku ini perlu ditulis?

Saya memulai pada tahun 2008 dengan membangun sistem akuntansi portofolio dan pengukuran kinerja untuk platform perbankan. Salah satu proyek tersebut adalah mesin yang sesuai dengan GIPS untuk menghitung pengembalian waktu, yang kemudian digunakan oleh lembaga keuangan di lebih dari 80 negara. Pekerjaan itu mengajari saya sebuah pelajaran yang telah membentuk seluruh karir saya. Dalam keuangan teratur, kegagalan paling berbahaya adalah angka yang salah yang terlihat benar. Perhitungan yang salah terselubung dipercaya, dilaporkan, dan diambil tindakan selama bertahun-tahun, karena tidak ada yang tampak rusak.

Saya melihat pola yang sama lagi kemudian. Saya menemukan kesenjangan struktural dalam model Markov dari model atribusi pemasaran yang banyak digunakan. Kerangka tersebut digunakan oleh ratusan ribu pengguna, dan kesalahan itu telah bertahan selama bertahun-tahun karena satu alasan: outputnya terlihat masuk akal. Ketika saya pindah ke transformasi AI di jasa keuangan, saya menyaksikan sistem agenik mengulangi pola ini dengan taruhan yang jauh lebih tinggi. Sebuah agen tidak hanya menghasilkan hasil yang salah. Ia mengambil tindakan berdasarkan itu.

Kesenjangan yang meyakinkan saya untuk menulis buku ini adalah bahwa penelitian dan penerapan perusahaan peduli tentang hal-hal yang berbeda. Penelitian mengukur kemampuan pada benchmark. Perusahaan bergantung pada bagaimana sistem berperilaku di bawah ketidakjelasan, data yang berubah, dan tekanan lawan. Kebanyakan tulisan tentang agen berhenti pada tahap demo. Saya menulis Agentic AI for Engineers untuk insinyur yang harus menandatangani namanya pada sistem yang akan berjalan dengan pengawasan terbatas di dalam lembaga yang diatur.

Buku Anda menjelaskan pergeseran dari otomatisasi ke otonomi sebagai pola pikir rekayasa baru. Apa yang benar-benar memisahkan agen AI otonom dari alur kerja otomatis yang canggih, dan di mana organisasi paling mungkin membingungkan keduanya?

Saya memberikan tim sebuah tes sederhana. Apakah Anda dapat mendaftarkan setiap jalur yang sistem dapat ambil sebelum Anda menjalankannya? Jika ya, Anda memiliki otomatisasi. Mungkin itu otomatisasi yang sangat canggih dengan model bahasa di dalamnya, tetapi itu masih otomatisasi. Jika sistem memecah tujuan, memilih alat, dan memutuskan urutan tindakan pada runtime berdasarkan konteks yang Anda tidak skrip, Anda memiliki otonomi. Perbedaan ini tidak ada hubungannya dengan model yang Anda gunakan. Ini berkaitan dengan di mana keputusan dibuat.

Organisasi membingungkan keduanya dalam kedua arah, tetapi hanya satu arah yang mahal. Menyebut alur kerja LLM yang diskenario sebagai agenik hampir merupakan masalah pemasaran. Kesalahan yang mahal adalah sebaliknya. Tim menerapkan pengambilan keputusan otonom di bawah tata kelola yang dirancang untuk otomatisasi deterministik. Pengujian mereka menganggap keterulangan. Pemantauan mereka menganggap pola kegagalan yang diketahui. Jejak audit mereka menganggap ada aturan yang dapat dilacak di balik setiap tindakan. Tidak satu pun dari asumsi tersebut berlaku untuk agen.

Itulah pergeseran pola pikir yang saya ajukan dalam buku. Dengan otomatisasi, pertanyaan utama adalah apakah sistem dieksekusi dengan benar. Dengan otonomi, pertanyaan menjadi apakah sistem memutuskan dengan benar. Menjawab itu memerlukan instrumentasi yang berbeda, metode evaluasi yang berbeda, dan tingkat kehati-hatian yang berbeda.

Banyak sistem AI agenik berperforma impresif dalam demonstrasi tetapi bergelut ketika terkena pengguna nyata, data yang berubah, dan alat yang tidak terduga. Apa komponen yang harus dipertimbangkan wajib dalam arsitektur agen produksi?

Jawaban yang jujur adalah produksi membutuhkan semua yang demo biarkan Anda lewati. Sebuah demonstrasi bekerja karena seseorang mengontrol lingkungan. Produksi mengambil kontrol itu.

Dalam buku, saya menjelaskan arsitektur referensi tujuh lapis, tetapi ini adalah komponen yang saya anggap wajib. Kontrak alat dengan input yang ditentukan dan izin yang eksplisit, sehingga jangkauan agen dibatasi oleh desain daripada oleh harapan. Pengelolaan keadaan yang bertahan dari gangguan dan kegagalan. Penanganan kegagalan terstruktur dengan jalur eskalasi yang ditentukan. Kerangka evaluasi yang berjalan terus, bukan hanya sekali sebelum peluncuran. Dan jejak audit yang mencatat keputusan dan alasan di baliknya, bukan hanya tindakan yang diambil.

Komponen yang paling sering dilewati tim adalah verifikasi runtime. Ini adalah lapisan yang memeriksa setiap tindakan terhadap tujuan agen yang dinyatakan dan kebijakan yang berlaku untuknya. Infrastruktur standar memberitahu Anda apakah panggilan berhasil. Verifikasi bertanya apakah panggilan seharusnya dilakukan sama sekali. Ini tidak pernah membuktikan nilainya dalam demo, karena tidak ada yang perlu ditangkap. Dalam produksi, ini adalah hal pertama yang akan Anda inginkan.

Buku Anda mencakup keselamatan, pemeliharaan, umpan balik, pengujian, debugging, evaluasi, dan penerapan. Bagaimana tim rekayasa harus menggabungkan elemen-elemen ini menjadi proses asuransi berkelanjutan daripada memperlakukan keselamatan sebagai tinjauan pra-peluncuran terakhir?

Tinjauan akhir bergantung pada asumsi bahwa sistem yang Anda tinjau adalah sistem yang akan berjalan. Untuk AI agenik, asumsi itu gagal dalam tiga cara. Model dasar diperbarui. Alat dan API yang agen bergantung padanya berubah. Dan data serta lingkungan yang agen operasikan terus berubah. Tinjauan keselamatan sekali membahas sistem yang tidak ada lagi beberapa bulan kemudian.

Asuransi berkelanjutan berarti menutup loop. Evaluasi perilaku berjalan di CI (integrasi berkelanjutan) sama seperti unit tes, dan mereka menggate setiap perubahan pada prompt, alat, dan model. Pemantauan runtime memberi makan jejak produksi kembali ke dalam set evaluasi. Saya menjelaskan empat pola pemantauan dalam buku, karena tidak satu pola pun mencakup seluruh permukaan kegagalan. Setiap insiden menghasilkan pemeriksaan baru, sama seperti setiap bug harus menghasilkan tes regresi. Dan pengujian lawan berjalan pada jadwal teratur bukan hanya sekali sebelum peluncuran.

Aspek organisasional sama pentingnya dengan aspek teknis. Keselamatan tidak dapat menjadi tim terpisah yang muncul di akhir dengan daftar periksa. Insinyur yang membangun agen harus memiliki suite evaluasi, invarian, dan desain eskalasi, karena mereka tahu lebih baik daripada siapa pun di mana penilaian sistem paling lemah.

Anda telah menekankan pemantauan semantik panggilan alat agen. Apa yang diungkapkan pemantauan semantik yang tidak dapat dilakukan oleh log konvensional dan alat observabilitas, dan bagaimana dapat mendeteksi ketika agen secara teknis berfungsi tetapi mengejar tujuan yang salah?

Observabilitas konvensional menjawab satu pertanyaan: apakah panggilan berhasil? Ini mencakup kode status, skema, latensi, dan tingkat kesalahan. Ini tidak dapat menjawab pertanyaan yang paling penting untuk agen, yaitu apakah panggilan seharusnya terjadi. Sebuah panggilan alat dapat secara teknis sempurna dan masih menjadi tindakan yang salah. Format yang benar, kredensial yang valid, respon yang berhasil, hal yang salah untuk dilakukan.

Pemantauan semantik mengevaluasi setiap tindakan terhadap tujuan agen yang dinyatakan dan kebijakan yang berlaku untuknya. Dalam buku, saya menjelaskan ini sebagai mendefinisikan invariant semantik atas panggilan alat agen. Ini adalah properti yang harus berlaku tidak peduli apa jalur yang diambil agen. Sebuah agen yang melakukan riset kasus pelanggan tertentu tidak pernah boleh mengakses catatan di luar kasus itu. Sebuah agen harus menandai ketidaksesuaian di atas ambang tertentu, tidak pernah menyelesaikannya sendiri. Ketika invariant dilanggar, Anda menangkap masalah pada saat tindakan daripada dalam audit triwulanan.

Ini juga bagaimana Anda mendeteksi drift tujuan, yang saya anggap sebagai kegagalan yang mendefinisikan sistem agenik. Drift tujuan terlihat seperti agen yang menyelesaikan setiap langkah dengan benar menurut log sementara secara diam-diam bekerja menuju tujuan yang salah. Ini tidak pernah muncul dalam log, karena tidak ada yang gagal. Pemantauan semantik memperlakukan niat sebagai sesuatu yang Anda ukur langsung, dan niat adalah tempat agen salah.

Ketika agen menghadapi instruksi yang ambigu, kebijakan yang bertentangan, alat yang tidak tersedia, atau kepercayaan yang tidak mencukupi, apa yang seharusnya terlihat seperti penanganan kegagalan terstruktur? Bagaimana pengembang dapat memastikan sistem berhenti, eskalasi, atau pulih daripada berimprovisasi?

Masalah yang perlu Anda desain melawan adalah bahwa sebagian besar agen hanya memiliki satu cara untuk mengakhiri tugas, yaitu menghasilkan jawaban. Ketika instruksi ambigu atau kebijakan bertentangan, agen berimprovisasi. Bukan karena modelnya ceroboh, tetapi karena berimprovisasi adalah satu-satunya perilaku yang diizinkan oleh arsitektur. Penanganan kegagalan terstruktur berarti memberi sistem pilihan yang lebih baik dan membuatnya lebih mudah dijangkau daripada jawaban yang dibuat-buat.

Dalam prakteknya, itu berarti penolakan dan eskalasi dirancang dan diuji dengan perawatan yang sama seperti keberhasilan. Saya sarankan mendefinisikan keadaan kegagalan yang ditentukan: instruksi yang ambigu, kebijakan yang bertentangan, alat yang tidak tersedia, kepercayaan yang tidak mencukupi. Masing-masing memetakan ke perilaku tertentu. Tanyakan pertanyaan klarifikasi. Serahkan ke manusia dengan konteks yang lengkap. Turun ke operasi hanya baca. Ulangi dalam batas yang lebih ketat. Atau berhenti. Ambang kepercayaan harus sesuai dengan risiko tindakan tertentu. Batang untuk menyusun ringkasan internal dan batang untuk menyentuh akun pelanggan tidak pernah boleh menjadi nomor yang sama.

Dua praktik membuat ini nyata. Pertama, desain jalur eskalasi sebelum jalur yang bahagia. Jika manusia akan menerima serahan, putuskan apa konteks yang mereka dapatkan dan apa wewenang yang mereka miliki sebelum Anda menulis prompt pertama. Kedua, uji kegagalan dengan cara Anda menguji fitur. Suntikkan instruksi yang ambigu. Nonaktifkan alat di pengaturan. Beri agen kebijakan yang bertentangan. Sebuah sistem yang tidak pernah berlatih gagal akan bertindak tanpa bimbingan pertama kali itu terjadi di produksi.

Lembaga keuangan harus menyeimbangkan eksperimen dengan persyaratan ketat sekitar privasi, auditabilitas, risiko model, dan kepatuhan regulasi. Di mana persetujuan manusia harus tetap wajib, dan di mana agen dapat diberi otonomi operasional yang lebih besar?

Aturanku adalah bahwa persetujuan manusia harus tetap wajib untuk setiap tindakan yang tidak dapat dibalik, yang memindahkan uang atau memengaruhi hasil pasien, yang melibatkan komunikasi pelanggan yang membawa bobot regulasi, yang memberi makan pelaporan regulasi, atau yang mengubah alat, kebijakan, atau izin agen sendiri. Agen dapat diberi otonomi yang lebih besar dalam pekerjaan baca dan alasan: penelitian, pengambilan, analisis dokumen, triase, penyusunan, dan rekonsiliasi yang menandai ketidaksesuaian untuk tinjauan manusia daripada menyelesaikannya.

Kesalahan umum adalah memerlukan persetujuan manusia pada setiap langkah. Ini tidak membuat sistem lebih aman. Ini merekayasa kembali proses manual dengan langkah tambahan dan melatih peninjau untuk menyetujui. Persetujuan milik pada titik keputusan nyata. Harus ada sedikit dari mereka, dan masing-masing harus ditempati oleh seseorang dengan wewenang nyata untuk mengatakan tidak.

Prinsip lainnya adalah bahwa otonomi harus diperoleh daripada diberikan. Mulai sempit. Perluas ketika sistem membuktikan diri di bawah pemantauan. Simpan bukti. Dalam istilah risiko model, lingkungan kontrol Anda harus membiarkan Anda menunjukkan regulator tidak hanya apa yang dilakukan agen, tetapi mengapa Anda dibenarkan memberinya tingkat kemandirian itu. Catatan itu adalah lisensi nyata untuk beroperasi.

Melalui pekerjaan Anda pada penjaga AI dan standar, Anda membantu mendefinisikan aturan untuk sistem yang kemampuannya terus berubah. Apa penjaga yang dapat distandarisasi hari ini, dan apa yang masih tergantung pada konteks, industri, atau kasus penggunaan?

Penjaga yang dapat kita standarisasi hari ini adalah struktural. Mereka memerlukan bahwa kontrol tertentu ada, didokumentasikan, dan dapat diinspeksi. Batasan kemampuan dan izin yang didokumentasikan untuk sistem otonom. Mekanisme pengawasan manusia dan eskalasi yang ditentukan. Kewajiban deteksi dan pelaporan insiden. Metode evaluasi dan persyaratan bukti. Akuntabilitas yang jelas di seluruh siklus hidup sistem, sehingga ketika sesuatu salah, jawaban atas siapa yang bertanggung jawab tidak pernah hanya AI. Ini dapat distandarisasi karena mereka berkaitan dengan apakah kontrol ada dan seberapa baik mereka, bukan nilai spesifik yang mereka ambil.

Apa yang tidak dapat kita standarisasi saat ini adalah pengaturan itu sendiri. Ambang kepercayaan spesifik, taksonomi kerusakan, dan tingkat otonomi yang sesuai bergantung pada konteks. Toleransi kegagalan yang dapat diterima untuk agen konten pemasaran dan untuk sistem yang menyentuh keputusan klinis atau keuangan tidak dua titik pada skala yang sama. Mereka milik rezim yang berbeda, yang dibentuk oleh domain, yurisdiksi, dan siapa yang menanggung kerusakan ketika sesuatu gagal.

Kontrol keuangan adalah model yang berguna di sini. Persyaratan audit distandarisasi secara global, tetapi materialitas selalu dihakimi dalam konteks. Standar yang menghormati pemisahan ini cenderung diadopsi. Standar yang mencoba menentukan nilai yang bergantung pada konteks cenderung diabaikan, dan standar keselamatan yang tidak diikuti oleh siapa pun tidak melindungi siapa pun.

Penelitian Anda baru-baru ini telah mengeksplorasi kekuatan multibudaya dan lawan dalam evaluasi keselamatan AI. Apa jenis kegagalan model yang mungkin terlewatkan oleh benchmark Barat atau rata-rata global, dan bagaimana perusahaan harus mengevaluasi sistem yang dimaksudkan untuk penerapan multibudaya?

Memandang hanya benchmark rata-rata dapat melewatkan kegagalan yang paling penting. Sebuah model dapat memposting skor keselamatan keseluruhan yang kuat sementara gagal dengan buruk untuk bahasa, dialek, atau konteks budaya tertentu, karena kegagalan tersebut menghilang ke dalam rata-rata. Evaluasi yang berpusat pada Barat menambahkan titik buta lain. Ini melewatkan kerusakan yang spesifik budaya, seperti idiom, gerakan, dan konteks agama atau regional di mana output yang sama tidak berbahaya dalam satu budaya dan merusak dalam budaya lain. Ini juga menguji kode-switching, transliterasi, dan nama serta entitas non-Barat dengan buruk. Ada sudut lawan juga. Penyerang tidak menargetkan kinerja rata-rata Anda. Mereka menemukan irisan terlemah Anda, dan untuk sebagian besar model itu adalah bahasa dengan sumber daya yang lebih rendah atau konteks budaya yang dievaluasi dengan buruk.

Ini adalah apa yang menarik saya untuk menyumbang penelitian benchmark keselamatan AI multibudaya. Temuan intinya sederhana. Menilai keselamatan di seluruh budaya memerlukan data evaluasi dan penilaian manusia yang diambil dari budaya tersebut. Anda tidak dapat menilai kerusakan dari luar konteks di mana terjadi.

Untuk perusahaan, saya sarankan tiga aturan. Evaluasi setiap segmen yang Anda layani, dan jangan pernah menerima rata-rata sebagai bukti. Bangun set evaluasi dari populasi pelanggan aktual Anda. Jalankan pengujian lawan dalam bahasa yang digunakan pelanggan Anda. Jika Anda melayani pelanggan di empat puluh negara dan mengevaluasi hanya dalam bahasa Inggris, Anda telah mengukur sistem untuk penerapan orang lain.

Anda juga memegang paten yang diberikan oleh Kantor Paten dan Merek Amerika Serikat di AI terapan. Apa masalah yang Anda coba selesaikan, apa yang proses itu ajarkan Anda tentang mengubah penelitian AI menjadi inovasi praktis, dan apa tantangan AI agenik yang belum terpecahkan yang paling Anda minati untuk ditangani selanjutnya?

Paten yang baru saja disetujui membahas masalah skala dan konsistensi dalam tinjauan kualitas layanan keuangan — tinjauan panggilan konvensional adalah manual, sehingga peninjau manusia hanya dapat mengambil sampel sebagian panggilan, dan penilaian mereka bervariasi dari orang ke orang. Pendekatanku mengarahkan setiap pertanyaan kualitas dan kepatuhan ke metode yang paling sesuai untuk menjawabnya, dengan setiap keputusan yang dilog dan dapat diaudit.

Anda dapat melihat tema yang sama yang saya deskripsikan sepanjang wawancara ini. Arahkan setiap tugas ke alat yang paling lemah yang dapat melakukannya dengan baik. Jaga manusia dalam loop di mana penilaian penting. Dan buat setiap keputusan otomatis dapat dilacak, karena dalam lembaga yang diatur, jawaban tanpa bukti bukanlah jawaban.

Apa yang proses paten ajarkan saya adalah bahwa disiplinnya ada di detail. Anda tidak bisa mematenkan ide yang samar. Anda harus menunjukkan dengan tepat apa yang metode Anda lakukan dengan berbeda, dan apa yang berlaku. Ketepatan itu membuat pekerjaan dasar lebih baik.

Tantangan yang belum terpecahkan yang paling saya pedulikan sekarang adalah verifikasi runtime untuk sistem multi-agents. Mendefinisikan invariant semantik untuk satu agen adalah dapat dikelola. Saya tahu, karena kami melakukannya dalam produksi. Ketika agen mendelegasikan pekerjaan ke agen lain, perilaku menjadi emergen, dan kegagalan bergerak ke dalam handoff. Sebuah instruksi sedikit diinterpretasikan ulang pada setiap langkah. Sebuah kebijakan berlaku untuk satu agen tetapi tidak untuk agen yang direkrutnya. Memverifikasi interaksi antar agen, bukan hanya tindakan masing-masing, adalah di mana saya mengharapkan generasi kegagalan sunyi berikutnya muncul. Itulah masalah yang ingin saya kerjakan selanjutnya.

Terima kasih atas wawancara yang luar biasa, pembaca juga dapat memesan buku Agentic AI for Engineers Anda.