Shahar Azulay, CEO dan Pendiri Bersama groundcover

Shahar Azulay, CEO dan salah satu pendiri groundcover adalah seorang pemimpin R&D berpengalaman. Shahar membawa pengalaman di dunia keamanan siber dan pembelajaran mesin, setelah bekerja sebagai pemimpin di perusahaan-perusahaan seperti Apple, DayTwo, dan Cymotive Technologies. Shahar menghabiskan bertahun-tahun di divisi Siber di Kantor Perdana Menteri Israel dan memegang tiga gelar di bidang Fisika, Teknik Elektro, dan Ilmu Komputer dari Technion Israel Institute of Technology serta Universitas Tel Aviv. Shahar berupaya menggunakan pembelajaran teknologi dari latar belakang yang kaya ini dan membawanya ke medan pertempuran cloud native saat ini dalam bentuk yang paling tajam dan inovatif untuk menjadikan dunia pengembangan perangkat lunak menjadi tempat yang lebih baik.

penutup tanah adalah platform observabilitas berbasis cloud yang dirancang untuk memberikan tim teknik visibilitas penuh dan real-time ke dalam sistem mereka tanpa kerumitan atau biaya alat pemantauan tradisional. Dibangun di atas teknologi eBPF, platform ini mengumpulkan dan mengkorelasikan log, metrik, jejak, dan peristiwa di seluruh lingkungan cloud-native dan Kubernetes tanpa perubahan kode, memungkinkan analisis akar penyebab yang lebih cepat dan wawasan sistem yang lebih jelas. Platform ini menekankan harga yang dapat diprediksi, penerapan yang fleksibel yang menjaga data tetap berada di cloud pelanggan, dan observabilitas ujung-ke-ujung yang mencakup infrastruktur, aplikasi, dan beban kerja modern yang digerakkan oleh AI.

Melihat kembali perjalanan Anda—dari memimpin tim R&D siber di Kantor Perdana Menteri Israel hingga mengelola inisiatif ML di Apple—pengalaman apa yang akhirnya mendorong Anda untuk mendirikan groundcover, dan kapan Anda pertama kali menyadari kesenjangan dalam kemampuan pengamatan untuk sistem AI modern?

Dorongan untuk mendirikan Groundcover berasal dari pengalaman saya di Apple dan DayTwo. Bahkan dengan anggaran besar, kami terjebak dalam pilihan antara membayar mahal untuk mencatat semuanya atau melakukan sampling dan beroperasi tanpa arah. Saat itu, kami mencari teknologi yang dapat menyelesaikan masalah tersebut. Setelah kami menemukan Extended Berkeley Packet Filter (eBPF), jelas bahwa teknologi ini akan mengubah segalanya. eBPF memungkinkan kami melihat semua yang terjadi di kernel tanpa bergantung pada perubahan aplikasi. Saya tidak mengerti mengapa alat observabilitas tidak memanfaatkan hal itu. Kesenjangan AI menjadi jelas kemudian. Setelah platform Kubernetes kami matang, kami melihat pelanggan bergegas melakukan penerapan GenAI sambil memperlakukan LLM seperti kotak hitam. Mereka tahu model tersebut merespons, tetapi tidak tahu mengapa perilakunya tidak terduga atau mengapa biayanya melonjak. Kami menyadari bahwa alur kerja agenik hanyalah layanan mikro yang kompleks dan non-deterministik yang membutuhkan visibilitas tanpa sentuhan yang sama seperti yang telah kami bangun.

Bagaimana latar belakang Anda di bidang keamanan siber, sistem tertanam, dan penelitian dan pengembangan pembelajaran mesin memengaruhi visi di balik groundcover, dan tantangan awal apa yang Anda hadapi dalam membangun perusahaan yang berpusat pada observabilitas untuk aplikasi berbasis LLM dan agenik?

Latar belakang saya di bidang siber membentuk DNA perusahaan. Di dunia intelijen, Anda berasumsi bahwa Anda tidak mengendalikan aplikasi. Pendekatan itulah mengapa Groundcover tidak memerlukan instrumentasi. Saya tahu dari pengalaman bahwa meminta pengembang untuk memodifikasi kode adalah cara tercepat untuk menghambat adopsi. Tantangan awal terberat dengan pemantauan LLM adalah privasi. Observabilitas untuk AI menangkap perintah yang mungkin berisi PII atau IP sensitif. Latar belakang saya menunjukkan bahwa perusahaan tidak ingin data tersebut keluar dari lingkungan mereka. Itulah mengapa kami membangun arsitektur berbasis cloud kami, yang memungkinkan kami untuk memberikan visibilitas mendalam ke dalam perilaku agen sambil menjaga semua data tetap berada di dalam lingkungan pelanggan sendiri.

Bagaimana Anda mendefinisikan observabilitas LLM, dan apa yang membedakannya dari pemantauan tradisional atau pemantauan ML?

Observabilitas LLM adalah praktik menginstrumentasi dan memantau sistem produksi yang menggunakan model bahasa besar sehingga Anda dapat menangkap konteks lengkap dari setiap inferensi: prompt, konteks, penyelesaian, penggunaan token, latensi, kesalahan, metadata model, dan idealnya umpan balik hilir atau sinyal kualitas. Alih-alih hanya bertanya "Apakah layanan berjalan cepat dan lancar?" atau "Apakah permintaan ini mengalami kesalahan?", observabilitas LLM membantu Anda menjawab pertanyaan seperti "Mengapa permintaan tertentu ini berhasil atau gagal?", "Apa yang sebenarnya terjadi di dalam alur kerja multi-langkah ini?", dan "Bagaimana perubahan pada prompt, konteks, atau versi model memengaruhi biaya, latensi, dan kualitas output?" Hal ini sangat berbeda dari pemantauan tradisional atau bahkan pemantauan ML klasik. Pendekatan lama disesuaikan untuk sistem deterministik, metrik infrastruktur, dan ambang batas statis. Aplikasi LLM bersifat non-deterministik, terbuka, dan sangat bergantung pada konteks. Keberhasilan seringkali bersifat semantik dan subjektif, bukan hanya kode status 200 vs 500. Artinya, Anda harus melacak input dan output, memahami panggilan alat dan langkah-langkah pengambilan, mengevaluasi respons untuk hal-hal seperti halusinasi atau pelanggaran kebijakan, dan menghubungkan biaya dan penundaan tingkat token kembali ke aplikasi dan infrastruktur di sekitarnya.

Tantangan apa yang ditimbulkan oleh aplikasi berbasis LLM sehingga membuat alat observabilitas tradisional tidak memadai?

Sistem yang didukung LLM menghadirkan beberapa tantangan yang mengungkap keterbatasan alat tradisional:

• Alur kerja yang kompleks dan multi-langkah – Kita telah beralih dari alur sederhana “memanggil model, mendapatkan respons” ke agen multi-putaran, alur kerja multi-langkah, generasi yang diperkaya dengan pengambilan data, dan penggunaan alat. Kegagalan yang tidak terdeteksi di salah satu langkah tersebut, seperti pengambilan data, pengayaan, penyematan, pemanggilan alat, atau pemanggilan model, dapat merusak seluruh pengalaman. Pemantauan tradisional biasanya tidak memberikan pandangan lengkap hingga tingkat pelacakan dari rangkaian tersebut, termasuk petunjuk dan responsnya.
• Tumpukan AI yang berkembang pesat – Tim menambahkan model, alat, dan vendor baru dengan kecepatan yang belum pernah terjadi sebelumnya. Di banyak perusahaan, tidak ada yang dapat dengan yakin menyebutkan model mana yang sedang digunakan pada saat tertentu. Observabilitas klasik biasanya mengasumsikan Anda memiliki waktu untuk menginstrumentasi SDK, melakukan penyebaran ulang, dan dengan cermat memilih apa yang Anda ukur. Hal itu jelas tidak mampu mengimbangi kecepatan adopsi AI.
• Ekonomi berbasis token dan kuota – Penetapan harga dan batasan laju terkait dengan token dan durasi konteks, yang sering kali dikendalikan oleh pengembang, perintah, atau perilaku pengguna, bukan oleh operasi pusat. Alat tradisional tidak dirancang untuk menunjukkan kepada Anda "siapa yang membakar berapa banyak token pada model mana, untuk alur kerja mana, pada latensi berapa".
• Ketepatan semantik, bukan kesuksesan biner. – Sebuah LLM dapat mengembalikan kode 200 dan tetap mengalami halusinasi, menyimpang dari perintah Anda, atau melanggar kebijakan. Alat tradisional menganggap itu sebagai keberhasilan. Anda membutuhkan kemampuan observasi yang dapat menampilkan perintah dan respons serta memberi Anda konteks yang cukup untuk memeriksa perilaku dan, seiring waktu, menerapkan pemeriksaan kualitas otomatis.
• Data masukan sensitif mengalir ke pihak ketiga – LLM (Local Learning Modules) mengajak pengguna untuk berbagi informasi yang sangat sensitif melalui antarmuka bergaya obrolan. Sekarang Anda bertanggung jawab atas data tersebut, di mana data tersebut disimpan, dan vendor mana yang dapat melihatnya. Observabilitas berbasis SaaS konvensional yang mengirimkan semua telemetri ke pihak ketiga seringkali tidak dapat diterima untuk beban kerja ini.

Semua ini berarti sistem LLM membutuhkan kemampuan observasi yang sadar akan AI, kaya konteks, dan jauh lebih sedikit bergantung pada instrumentasi manual dibandingkan alat yang digunakan sebagian besar tim saat ini.

Sinyal atau metrik mana yang paling penting untuk memahami kinerja dan kualitas sistem LLM, termasuk latensi, penggunaan token, dan perilaku prompt/respons?

Ada beberapa kategori sinyal yang sangat penting dalam praktiknya:

Latensi dan throughput

• Latensi ujung ke ujung per permintaan, termasuk waktu model dan waktu aplikasi di sekitarnya.
• Latensi ekor (P90, P95, P99) per model dan per alur kerja.
• Data throughput berdasarkan model, rute, dan layanan, sehingga Anda tahu ke mana beban sebenarnya mengarah.

Penggunaan token dan faktor pendorong biaya

• Token input dan output per permintaan, dirinci berdasarkan model.
• Penggunaan token yang diagregasi dari waktu ke waktu per model, tim, pengguna, dan alur kerja.
• Ukuran konteks untuk alur kerja yang banyak melakukan pengambilan data sehingga Anda dapat melihat kapan permintaan mulai menumpuk.
• Inilah yang memungkinkan Anda menjawab pertanyaan “Siapa sebenarnya yang membelanjakan anggaran AI kita dan untuk apa?”

Perilaku cepat dan responsif

• Muatan perintah dan respons aktual pada jejak representatif, termasuk panggilan alat dan jalur penalaran.
• Alat apa saja yang dipilih LLM untuk digunakan dan dalam urutan apa.
• Variasi respons untuk perintah serupa sehingga Anda dapat mengetahui seberapa stabil perilakunya.

Keandalan dan kesalahan

• Tingkat dan jenis kesalahan spesifik model (kesalahan penyedia, waktu habis, masalah otentikasi, kesalahan kuota).
• Kegagalan dalam alur kerja di sekitarnya, seperti waktu habis alat atau kesalahan pengambilan, berkorelasi dengan panggilan LLM.

Konteks infrastruktur klasik

• Metrik CPU, memori, dan jaringan kontainer untuk layanan yang mengatur panggilan LLM Anda.
• Log yang saling terkait yang menjelaskan apa yang coba dilakukan oleh aplikasi tersebut.

Ketika Anda dapat melihat semua itu di satu tempat, kemampuan observasi LLM bergeser dari "Saya tahu sesuatu itu lambat atau mahal" menjadi "Saya tahu persis model, pola prompt, dan layanan mana yang bertanggung jawab dan mengapa".

Bagaimana kemampuan observasi dapat membantu tim mendeteksi kegagalan tersembunyi seperti penyimpangan yang cepat, halusinasi, atau penurunan kualitas output secara bertahap?

Kegagalan senyap dalam sistem LLM biasanya terjadi ketika semuanya tampak "hijau" di tingkat infrastruktur, tetapi perilaku sebenarnya menyimpang. Observabilitas membantu dalam beberapa hal:

• Melacak alur kerja secara keseluruhan, bukan hanya panggilan model. – Dengan menangkap seluruh alur permintaan dari klien ke layanan ke pengambilan ke model ke alat, Anda dapat melihat di mana perilaku berubah. Misalnya, mungkin pengambilan mulai mengembalikan lebih sedikit dokumen, atau panggilan alat gagal secara berkala, dan model berimprovisasi.
• Dengan tetap memperhatikan petunjuk, konteks, dan respons. – Ketika Anda dapat memeriksa perintah dan respons bersamaan dengan jejak (trace), akan jauh lebih mudah untuk menemukan kasus di mana versi perintah baru, instruksi sistem baru, atau sumber konteks baru mengubah perilaku, meskipun latensi dan tingkat kesalahan tetap sama.
• Penyaringan dan pemotongan berdasarkan kondisi semantik – Setelah Anda memiliki data telemetri LLM yang lengkap, Anda dapat memfilter data seperti "panggilan dasar selama lebih dari satu detik", "permintaan yang menggunakan keluarga model ini", atau "jejak yang melibatkan rute tertentu ini", lalu membaca petunjuk dan respons untuk melihat apakah model tersebut mengalami penyimpangan atau halusinasi dalam skenario tertentu.
• Memberikan peringatan pada SLO tingkat bisnis. – Anda dapat menetapkan SLO seperti “setiap panggilan LLM yang melebihi satu detik melanggar SLA yang berlaku untuk pengguna” dan memicu peringatan ketika kondisi tersebut terpenuhi. Seiring waktu, SLO serupa dapat dikaitkan dengan skor kualitas atau pemeriksaan kebijakan sehingga Anda akan diberi peringatan ketika kualitas menurun, bukan hanya ketika infrastruktur gagal.

Karena lapisan observabilitas memiliki akses ke sinyal khusus AI dan juga log, metrik, serta jejak klasik, maka lapisan ini menjadi tempat yang tepat untuk mendeteksi masalah yang jika tidak ditangani akan secara diam-diam menurunkan pengalaman pengguna.

Bagaimana pendekatan Groundcover mendukung diagnosis latensi yang tidak terduga atau perilaku yang tidak diharapkan dalam alur kerja agen multi-langkah dan panggilan alat?

Groundcover menggunakan pendekatan yang dirancang untuk sistem AI modern. Kami menggunakan sensor berbasis eBPF di tingkat kernel untuk mengamati lalu lintas di seluruh layanan mikro tanpa perubahan kode atau penyebaran ulang. Segera setelah Anda memperkenalkan alur kerja LLM, kami dapat secara otomatis menemukan panggilan tersebut. Jika Anda mulai menggunakan model baru seperti Anthropic, OpenAI, atau Bedrock besok, Groundcover akan menangkap lalu lintas tersebut secara otomatis. Itu memberi Anda:

• Penelusuran ujung-ke-ujung dari alur kerja multi-hop – Anda dapat melihat alur lengkap permintaan di berbagai layanan, termasuk di mana LLM atau alat digunakan.
• Konteks mendalam pada setiap panggilan LLM – Setiap panggilan mencakup model yang digunakan, latensi, penggunaan token, perintah, respons, serta log dan metrik infrastruktur yang berkorelasi.
• Penyaringan yang ampuh berdasarkan latensi dan kondisi. – Misalnya, Anda dapat memfilter semua panggilan Claude 3.5 yang melebihi satu detik dan langsung memeriksa jejak yang melanggar SLA Anda.
• Peringatan dan dasbor yang terkait dengan perilaku LLM. – Setelah data tersedia, Anda dapat membuat peringatan untuk pelanggaran SLA atau membangun dasbor yang melacak latensi, throughput, penggunaan token, dan kesalahan.

Karena semuanya dikumpulkan di edge oleh eBPF dan disimpan di cloud Anda sendiri, Anda mendapatkan tampilan dengan granularitas tinggi ini tanpa perlu menambahkan instrumentasi di dalam setiap panggilan agen atau alat.

Risiko keamanan data dan kepatuhan apa yang Anda lihat muncul dalam penerapan LLM, dan bagaimana observabilitas dapat membantu mengurangi risiko tersebut?

Penerapan LLM menghadirkan beberapa risiko data yang unik:

• Masukan pengguna tanpa batas – Pengguna dapat memasukkan informasi yang sangat sensitif ke dalam chatbot dan antarmuka berbasis AI. Hal itu mungkin termasuk data pribadi, data pelanggan, atau informasi yang diatur yang tidak pernah Anda maksudkan untuk dikumpulkan.
• Penyedia model pihak ketiga – Setelah Anda mengirim data tersebut ke penyedia LLM eksternal, Anda bertanggung jawab atas ke mana data tersebut pergi, bagaimana data tersebut disimpan, dan subprosesor mana yang terlibat. Hal ini memiliki implikasi besar terhadap GDPR, residensi data, dan kepercayaan pelanggan.
• Telemetri sebagai salinan kedua dari data sensitif. – Jika tumpukan observabilitas Anda mengirimkan muatan data lengkap ke vendor SaaS, Anda sekarang memiliki salinan lain dari informasi sensitif tersebut yang berada di luar lingkungan Anda.

Arsitektur tanaman penutup tanah dirancang untuk mengatasi masalah-masalah tersebut:

• Kami menggunakan model "bawa cloud Anda sendiri" di mana backend observabilitas penuh berjalan di dalam akun cloud Anda, di sub-akun, sebagai bidang data yang sepenuhnya terkelola. Bidang kontrol yang menskalakan dan mengelolanya dijalankan oleh kami, tetapi kami tidak mengakses, menyimpan, atau memproses data telemetri Anda.
• Karena kami dapat menangkap muatan data dengan aman di lingkungan Anda sendiri, Anda dapat mengamati perintah, respons, dan alur kerja tanpa data tersebut pernah meninggalkan cloud Anda. Tidak ada penyimpanan pihak ketiga untuk jejak LLM Anda dan tidak ada pengeluaran data tambahan yang perlu dikhawatirkan.
• Dengan visibilitas tersebut, Anda dapat melihat siapa yang mengunggah apa dan ke mana alirannya, mendeteksi penggunaan data sensitif yang tidak terduga, dan menegakkan kebijakan tentang model dan wilayah mana yang diizinkan.

Dengan kata lain, kemampuan observasi tidak hanya menjadi alat keandalan dan biaya, tetapi juga titik kendali utama untuk privasi, residensi data, dan kepatuhan.

Seiring organisasi berkembang dari satu integrasi LLM menjadi banyak layanan berbasis AI, tantangan operasional apa saja yang cenderung muncul terkait visibilitas, keandalan, dan biaya?

Integrasi pertama biasanya berupa satu model dalam satu alur kerja. Pada tahap itu, semuanya terasa terkendali. Namun, begitu tim melihat nilainya, penggunaan akan meningkat pesat dan beberapa tantangan pun muncul:

• Penyebaran model dan vendor – Tim terus-menerus menguji model-model baru. Dengan cepat menjadi tidak jelas model mana yang sedang diproduksi dan bagaimana penggunaannya.
• Biaya tak terduga dari penggunaan token – Konsumsi token meningkat seiring dengan panjang konteks dan kompleksitas alur kerja. Tanpa visibilitas terhadap penggunaan token per model dan alur kerja, pengelolaan biaya menjadi sangat sulit.
• Ketergantungan keandalan pada penyedia eksternal – API yang berinteraksi langsung dengan pengguna menjadi sensitif terhadap latensi atau kesalahan model, yang dapat mengganggu SLA bahkan ketika infrastruktur inti dalam kondisi sehat.
• Meningkatnya utang instrumen – Observabilitas tradisional mengasumsikan Anda dapat menambahkan instrumentasi saat dibutuhkan. Dalam tumpukan AI yang berkembang pesat, pengembang jarang memiliki waktu untuk itu.

Groundcover mengatasi hal ini dengan secara otomatis mendeteksi lalu lintas AI dan kemudian memberi Anda:

• Visibilitas terpusat mengenai model dan vendor mana yang digunakan.
• Dasbor yang menampilkan latensi, throughput, dan penggunaan token dari waktu ke waktu.
• Korelasi antara perilaku LLM dan layanan yang bergantung padanya
• Peringatan untuk pelanggaran SLO yang didorong oleh AI.

Hal itu mempermudah peningkatan skala dari “satu fitur AI yang keren” menjadi “AI yang terintegrasi ke dalam puluhan layanan penting” tanpa kehilangan kendali.

Ke depan, bagaimana Anda memperkirakan kemampuan observasi LLM akan berkembang dalam lima tahun mendatang seiring dengan percepatan AI berbasis agen, orkestrasi multi-model, dan tekanan regulasi?

Kita masih berada di tahap awal. Dalam lima tahun ke depan, saya memperkirakan akan ada beberapa perubahan besar:

• Dari tingkat permintaan hingga pemahaman tingkat agen – Observabilitas akan diperluas untuk menangkap urutan alat, jalur penalaran, dan logika percobaan ulang, bukan hanya panggilan model.
• Sinyal semantik dan kebijakan yang lebih kaya – Pemeriksaan kualitas otomatis untuk halusinasi, masalah keamanan, dan keselarasan merek akan menjadi metrik standar.
• Keterkaitan yang lebih erat dengan tata kelola dan privasi. – Seiring bertambahnya regulasi, kemampuan pengamatan (observability) juga akan berfungsi sebagai lapisan penegakan dan audit untuk residensi data, retensi, dan penggunaan model yang disetujui.
• Optimasi lintas model dan multi-vendor. – Tim akan mengarahkan lalu lintas antar model secara dinamis berdasarkan kinerja dan biaya, dengan panduan data pengamatan waktu nyata.
• Penggunaan instrumen manual yang lebih sedikit – Teknik seperti pengumpulan berbasis eBPF dan penemuan otomatis akan menjadi standar, sehingga tim dapat berinovasi tanpa memperlambat proses.

Singkatnya, observabilitas LLM akan berkembang dari "dasbor yang bagus untuk dimiliki untuk AI" menjadi sistem saraf pusat yang menghubungkan keandalan, pengendalian biaya, tata kelola data, dan kualitas produk di seluruh hal yang dilakukan organisasi dengan AI.

Terima kasih atas wawancaranya yang luar biasa, pembaca yang ingin belajar lebih banyak harus berkunjung penutup tanah.