Nikunj Bajaj, Co-Founder dan CEO TrueFoundry – Seri Wawancara

Anda telah bekerja di penelitian pembelajaran mesin, produksi AI di Facebook, dan sistem rekomendasi skala besar sebelum mendirikan TrueFoundry — pengalaman apa yang paling langsung mendorong Anda untuk membangun perusahaan infrastruktur AI perusahaan, dan apa kesulitan yang tidak diatasi pada saat itu?

Di Meta, kami memandang pembelajaran mesin sebagai kasus khusus perangkat lunak, dan GenAI sebagai kasus khusus pembelajaran mesin, yang menghasilkan tumpukan vertikal dengan perangkat lunak di bagian bawah, pembelajaran mesin di tengah, dan GenAI di atas. Dalam pengaturan ini, jika saya adalah pengembang pembelajaran mesin, model yang saya bangun mengikuti pola pengiriman yang sama dengan perangkat lunak lainnya, yang membuat penskalaan sistem sangat sederhana.

Namun, sebagian besar perusahaan, bagaimanapun, mengirim tumpukan paralel, yang berarti mereka memiliki tumpukan terpisah untuk perangkat lunak, pembelajaran mesin, dan GenAI. Saat Anda memiliki tumpukan paralel ini, penskalaan menjadi lebih kompleks karena handoff yang diperlukan antara pembelajaran mesin dan dunia perangkat lunak.

Tim kami selalu bekerja di persimpangan membangun model pembelajaran mesin dan infrastruktur pembelajaran mesin, sehingga kami memiliki pandangan unik yang bisa kami bawa ke perusahaan dan disesuaikan dengan kebutuhan spesifik mereka. Kami juga memiliki hipotesis pada akhir 2021 bahwa pembelajaran mesin mendekati titik infleksi, dan ketika itu terjadi, lebih banyak perusahaan akan memerlukan tumpukan terintegrasi vertikal untuk mengirim dan menskala sistem ini secara efektif. Ini yang akhirnya membawa kami untuk mendirikan TrueFoundry, dan hipotesis kami benar. Adopsi AI dipercepat setelah peluncuran ChatGPT pada akhir 2022.

Seiring sistem AI berpindah dari eksperimen ke operasi sehari-hari, apa yang berubah tentang cara organisasi harus memikirkan keandalan dan kegagalan?

Taruhannya dengan Gen AI jauh lebih tinggi dibandingkan dengan sistem pembelajaran mesin tradisional. Ketika sistem ini berpindah ke produksi, organisasi menghadapi tingkat ketidakpastian dan non-determinisme yang jauh lebih tinggi karena LLM bersifat stokastik. Sistem agenik yang dibangun di atasnya menambahkan ketidakpastian lebih lanjut.

Selain itu, kegagalan tidak lagi biner. Alih-alih sistem hanya gagal atau tidak gagal, banyak masalah muncul sebagai kegagalan sebagian atau degradasi sunyi. Sistem mungkin merespons dengan latensi yang lebih tinggi, kualitas yang terdegradasi, atau perilaku yang tidak tepat seiring waktu. Dalam banyak kasus, degradasi ini dapat lebih sulit dideteksi dan kadang-kadang bahkan lebih merusak daripada gangguan yang keras.

Organisasi perlu memikirkan keandalan tidak hanya dalam hal waktu aktif tetapi juga degradasi kinerja seiring waktu.

TrueFailover diluncurkan di tengah gelombang gangguan layanan cloud dan AI yang sangat terlihat. Apa peristiwa terbaru yang membuat jelas bahwa keandalan AI telah bergeser dari “nice to have” menjadi persyaratan arsitektur inti?

Salah satu pelanggan kami di bidang kesehatan yang memproses permintaan pasien waktu-nyata yang terkait dengan resep obat terkena dampak gangguan yang disebabkan oleh kegagalan model. Alur kerja mereka menghasilkan ribuan dolar pendapatan per detik, dan gangguan tersebut mengganggu beberapa alur kerja kritis ini. Sebagai pelanggan TrueFailover awal, kami dapat membantu dengan pemulihan cepat, dan dampaknya terkandung.

Insiden seperti ini memunculkan pertanyaan penting. Ketika taruhan sistem Gen AI terus meningkat, mengapa proses pemulihan masih sebagian besar manual? Ini memperkuat gagasan bahwa sistem harus dibangun dengan asumsi bahwa kegagalan akan terjadi, dan mereka harus dirancang untuk memperbaiki diri secara otomatis. Keandalan juga harus dibangun ke dalam tumpukan AI itu sendiri melalui penggunaan AI Gateway, yang dapat menyediakan pengaturan terpusat, observabilitas, pengawasan, dan pengalihan model cerdas di seluruh penyedia.

Banyak gangguan AI masih dilihat sebagai gangguan teknis. Di mana Anda melihat biaya ekonomi dan manusia yang sebenarnya mulai muncul ketika sistem AI mengalami gangguan?

AI perusahaan telah berkembang ke titik di mana gangguan-gangguan ini tidak lagi hanya memengaruhi alur kerja internal. Hari ini, gangguan dan degradasi memengaruhi persepsi publik dan keuntungan secara langsung dan segera, karena kasus penggunaan produksi sekarang menghadap pelanggan. Perubahan ini dari pengujian internal ke aplikasi yang menghadap pelanggan dengan taruhan tinggi adalah mengapa kami melihat peningkatan permintaan untuk perhatian dan pengawasan eksekutif.

Ketika sistem AI semakin tertanam dalam alur kerja operasional, gangguan tidak lagi hanya menjadi masalah teknis. Mereka semakin memiliki konsekuensi bisnis, pelanggan, dan reputasi langsung.

Di lingkungan yang sangat kritis seperti apotek, operasi kesehatan, atau dukungan pelanggan, seberapa cepat gangguan AI dapat meluas menjadi risiko operasional atau reputasi?

Di lingkungan yang sangat kritis, eskalasi terjadi hampir seketika karena sistem ini mendukung alur kerja waktu-nyata yang sensitif. Bahkan gangguan singkat dapat menghentikan proses kritis, menunda pengiriman layanan, atau mengganggu sistem huluan yang bergantung pada output tersebut, menciptakan efek operasional yang meluas di seluruh organisasi.

Di sektor seperti kesehatan, dampaknya meluas beyond gangguan operasional ke pengalaman pelanggan dan hasil layanan. Jika pasien tidak dapat memenuhi resep mereka tepat waktu, ada konsekuensi nyata. Ini bukan hanya masalah bagi pasien, tetapi juga dapat merusak reputasi apotek atau penyedia layanan kesehatan. Di lingkungan yang sangat kritis di mana kepercayaan menjadi faktor, sangat penting bahwa sistem tetap online. Ini adalah mengapa organisasi semakin mengakui bahwa sistem AI harus dirancang dengan asumsi bahwa kegagalan akan terjadi dan bahwa mekanisme pemulihan perlu diaktifkan secara otomatis untuk meminimalkan risiko.

Anda telah mengatakan bahwa banyak tim merancang untuk kemampuan daripada kontinuitas. Mengapa Anda pikir ketahanan telah diabaikan secara historis dalam desain sistem AI?

Ini sebagian besar disebabkan oleh insentif dalam organisasi. Kemampuan baru terlihat dan menarik. Mereka membuka demo, fitur, dan kemungkinan produk yang kepemimpinan dapat segera lihat.

Kontinuitas, oleh definisi, tidak terlihat ketika semuanya berjalan dengan baik. Karena itu, sistem penghargaan cenderung miring ke arah pengiriman fitur baru daripada memastikan tidak ada yang rusak. Akibatnya, organisasi sering menginvestasikan secara tidak proporsional dalam pengembangan kemampuan daripada dalam rekayasa ketahanan.

Ketika perusahaan semakin mengandalkan model dan API eksternal, apa fragilitas baru yang diperkenalkan ke tumpukan AI yang mungkin pemimpin belum sepenuhnya menghargai?

LLM pada dasarnya adalah sumber daya bersama, dan perusahaan tidak memiliki mereka seperti infrastruktur tradisional. Selain itu, sistem bisnis kritis dengan perusahaan berjalan di sistem eksternal yang belum sepenuhnya diuji waktu. LLM itu sendiri berkembang dengan cepat, yang berarti penyedia model tidak dapat diminta pertanggungjawaban untuk hal-hal seperti latensi atau kinerja model sedikit menurun, karena mereka beriterasi pada penelitian mereka dengan sangat cepat.

Karena LLM adalah sumber daya bersama, latensi dapat melonjak karena konsumen lain dari LLM ini mengambil tindakan tertentu. Ada banyak titik kegagalan yang diperkenalkan karena sifat dasar LLM, dan perusahaan dalam dunia baru ini tidak memiliki kontrol penuh. Tanpa kontrol penuh, hal terbaik yang dapat dilakukan perusahaan adalah menciptakan redundansi sistem yang cukup untuk merancang sistem yang tangguh.

Tanpa fokus pada produk tertentu, bagaimana organisasi harus merancang ulang arsitektur AI untuk mengasumsikan kegagalan daripada mengobati gangguan sebagai kasus tepi yang jarang?

Organisasi harus kembali ke prinsip-prinsip dasar desain sistem terdistribusi. Sistem perangkat lunak dibangun dengan asumsi bahwa komponen jaringan dan mesin akan gagal, dan bahwa seluruh wilayah dapat turun.

Sistem AI tidak boleh berbeda. Kami harus mengasumsikan bahwa penyedia model akan mengalami masalah latensi, degradasi, atau gangguan, dan menggabungkan redundansi sehingga aplikasi tetap tangguh di seluruh skenario kegagalan.

Apakah Anda mengharapkan ketahanan AI menjadi faktor penentu dalam pemilihan platform dan vendor, mirip dengan bagaimana waktu aktif dan redundansi membentuk keputusan infrastruktur cloud?

Ketika lebih banyak sistem AI berpindah ke produksi, ketahanan akan menjadi syarat utama. Jika vendor tidak dapat menampilkan grafik dan metrik mereka tentang waktu aktif dan ketahanan secara keseluruhan, mereka tidak akan dipertimbangkan. Setelah ketahanan menjadi harapan dasar di seluruh vendor, faktor penentu akan bergeser ke pengalaman pengguna, optimasi kinerja, observabilitas, dan kemampuan produk tingkat tinggi. Seiring waktu, komponen seperti AI Gateway dan kemampuan failover otomatis akan menjadi elemen dasar infrastruktur AI perusahaan.

Menghadap ke depan, apa yang dimaksud dengan “siap produksi” AI yang sebenarnya dalam dunia di mana AI diharapkan tersedia terus, bukan hanya membantu sesekali?

Sistem AI yang siap produksi harus dapat diamati, dikontrol, dan dipulihkan. Ketiga kotak ini perlu dicentang.

Untuk AI produksi yang dapat diamati, tim memerlukan visibilitas yang dalam ke perilaku model, latensi, tingkat kesalahan, penggunaan token, drift, dan pola kegagalan. Tanpa observabilitas yang kuat, menjadi sangat sulit untuk mendeteksi degradasi sebelum pengguna mulai memperhatikannya.

Untuk sistem yang dapat dikontrol, itu termasuk pembentukan lalu lintas, pembatasan laju, pengawasan, penerapan kebijakan, dan pengalihan cerdas di seluruh model dan penyedia. Ini adalah tempat AI Gateway menjadi dasar, bertindak sebagai pesawat kontrol terpusat yang menerapkan pengawasan, menyediakan tata kelola konsisten, dan memungkinkan pengalihan model dinamis ketika kinerja atau keandalan menurun.

Dan terakhir, ketika datang ke kemampuan pulih, sistem harus dibangun dengan asumsi bahwa komponen dapat rusak sebagian atau sepenuhnya, baik karena gangguan penyedia, kualitas model yang terdegradasi, batas laju, atau input yang tidak terduga dari aktor jahat. Mekanisme failover dan pemulihan otomatis harus menjadi bagian asli dari arsitektur, bukan buku manual yang dipicu setelah sesuatu salah.

Ini adalah arah yang kami kerjakan di TrueFoundry. Vendor yang mendefinisikan kesiapan produksi dengan cara ini, menggabungkan observabilitas, kontrol terpusat, dan pemulihan otomatis, akan memenangkan kepercayaan pelanggan jangka panjang dan akan dapat terus memecahkan masalah baru seiring munculnya.

Terima kasih atas wawancara yang bagus, pembaca yang ingin mempelajari lebih lanjut harus mengunjungi TrueFoundry.