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

Anda telah bekerja di penelitian pembelajaran mesin, produksi AI di Facebook (META ), 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 teratasi 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 mengirim tumpukan paralel, yang berarti mereka memiliki tumpukan terpisah untuk perangkat lunak, pembelajaran mesin, dan GenAI. Saat Anda memiliki tumpukan paralel, penskalaan menjadi lebih kompleks karena pertukaran 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 dapat membawa tumpukan vertikal serupa ke perusahaan dan menyesuaikannya 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 membutuhkan tumpukan terintegrasi vertikal untuk mengirim dan menskalakan sistem ini secara efektif. Ini yang akhirnya membuat kami mendirikan TrueFoundry, dan hipotesis kami benar. Adopsi AI dipercepat setelah peluncuran ChatGPT pada akhir 2022.

Saat 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. Saat 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 menambah ketidakpastian lebih lanjut.

Selain itu, kegagalan tidak lagi biner. Sebagai gantinya, sistem gagal atau tidak gagal, banyak masalah muncul sebagai kegagalan sebagian atau degradasi diam. Sistem mungkin merespons dengan latensi yang lebih tinggi, kualitas yang menurun, atau perilaku yang tidak tepat seiring waktu. Dalam banyak kasus, degradasi ini dapat lebih sulit dideteksi dan kadang-kadang lebih merusak daripada gangguan yang parah.

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 tinggi. Apa peristiwa baru-baru ini membuat jelas bahwa keandalan AI telah bergeser dari “nice to have” menjadi persyaratan arsitektur inti?

Salah satu pelanggan kesehatan kami yang memproses permintaan pasien waktu nyata yang sensitif terkait 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 terkendali.

Insiden seperti ini menimbulkan pertanyaan penting. Saat 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 pengalihan terpusat, pengawasan, pengaman, 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. Saat 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 alasan kita melihat peningkatan permintaan untuk perhatian dan pengawasan eksekutif.

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

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

Dalam lingkungan 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.

Dalam sektor seperti kesehatan, dampaknya meluas ke pengalaman pelanggan dan hasil layanan. Jika pasien tidak dapat memenuhi resep mereka tepat waktu, ada konsekuensi nyata. Ini tidak hanya menjadi masalah bagi pasien, tetapi juga dapat merusak reputasi apotek atau penyedia kesehatan. Dalam lingkungan kritis di mana kepercayaan menjadi faktor, sangat penting bahwa sistem tetap online. Ini adalah alasan 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 ketangguhan 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 dapat segera dilihat oleh kepemimpinan.

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 berinvestasi secara tidak proporsional dalam pengembangan kemampuan daripada dalam rekayasa ketangguhan.

Saat perusahaan semakin mengandalkan model dan API eksternal, apa fragilitas baru yang diperkenalkan ke tumpukan AI yang mungkin belum sepenuhnya dipahami oleh para pemimpin?

LLM pada dasarnya adalah sumber daya bersama, dan perusahaan tidak memiliki kontrol penuh atasnya seperti halnya infrastruktur tradisional. Selain itu, sistem bisnis kritis dengan perusahaan berjalan pada sistem eksternal yang tidak sepenuhnya teruji waktu. LLM itu sendiri berkembang dengan cepat, yang berarti penyedia model tidak dapat dianggap bertanggung jawab atas hal-hal seperti latensi atau kinerja model yang sedikit menurun, karena mereka beriterasi pada penelitian mereka dengan sangat cepat.

Karena LLM adalah sumber daya bersama, latensi dapat melonjak karena konsumen LLM lain mengambil tindakan tertentu. Ada banyak titik kegagalan yang diperkenalkan karena sifat fundamental 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 sebuah wilayah secara keseluruhan 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 berharap ketangguhan AI menjadi faktor penentu dalam pemilihan platform dan vendor, mirip dengan cara waktu aktif dan redundansi membentuk keputusan infrastruktur cloud?

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

Melihat ke depan, apa yang dimaksud dengan AI “siap produksi” dalam dunia di mana AI diharapkan tersedia terus-menerus, bukan hanya kadang-kadang membantu?

Sistem AI siap produksi harus dapat diamati, dikendalikan, dan dipulihkan. Ketiga kotak ini harus diceklist.

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

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

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

Ini adalah arah yang kami tuju di TrueFoundry. Vendor yang mendefinisikan kesiapan produksi dengan cara ini, menggabungkan pengawasan, kontrol terpusat, dan pemulihan otomatis, akan mendapatkan kepercayaan pelanggan jangka panjang dan akan dapat terus memecahkan masalah baru yang muncul.

Terima kasih atas wawancara yang luar biasa, pembaca yang ingin mempelajari lebih lanjut dapat mengunjungi TrueFoundry.