Shahar Azulay, CEO dan Co-Founder dari groundcover

Shahar Azulay, CEO dan co-founder dari groundcover adalah seorang pemimpin R&D serial. Shahar membawa pengalaman di dunia keamanan siber dan pembelajaran mesin setelah bekerja sebagai pemimpin di perusahaan seperti Apple, DayTwo, dan Cymotive Technologies. Shahar menghabiskan banyak tahun di divisi Cyber di kantor Perdana Menteri Israel dan memegang tiga gelar di Fisika, Teknik Elektro, dan Ilmu Komputer dari Technion Israel Institute of Technology serta Universitas Tel Aviv. Shahar berusaha untuk menggunakan pembelajaran teknologi dari latar belakang yang kaya ini dan membawanya ke medan perang cloud native hari ini dalam bentuk yang paling inovatif untuk membuat dunia pengembangan menjadi lebih baik.

groundcover adalah platform observabilitas cloud-native yang dirancang untuk memberikan tim rekayasa visibilitas penuh dan waktu nyata ke dalam sistem mereka tanpa kompleksitas atau biaya alat pemantauan tradisional. Dibangun di atas teknologi eBPF, itu mengumpulkan dan mengorelasikan log, metrik, jejak, dan peristiwa di seluruh lingkungan cloud-native dan Kubernetes tanpa perubahan kode, memungkinkan analisis penyebab akar yang lebih cepat dan wawasan sistem yang lebih jelas. Platform ini menekankan harga yang dapat diprediksi, penerapan yang fleksibel yang menjaga data di cloud pelanggan, dan observabilitas ujung ke ujung yang meliputi infrastruktur, aplikasi, dan beban kerja AI modern yang didorong.

Mengingat kembali perjalanan Anda – dari memimpin tim R&D keamanan siber di kantor Perdana Menteri Israel hingga mengelola inisiatif ML di Apple – apa pengalaman yang akhirnya mendorong Anda untuk mendirikan groundcover, dan kapan Anda pertama kali mengenali kesenjangan dalam observabilitas untuk sistem AI modern?

Dorongan untuk mendirikan groundcover datang dari waktu saya di Apple dan DayTwo. Bahkan dengan anggaran yang besar, kami terjebak dalam memilih antara membayar sejumlah besar untuk memantau semua atau sampling dan terbang buta. Saat itu, kami mencari teknologi yang akan menyelesaikan masalah itu. Begitu kami menemukan Extended Berkeley Packet Filter (eBPF), jelas bahwa itu akan mengubah semuanya. eBPF memungkinkan kami untuk melihat semua yang terjadi di kernel tanpa bergantung pada perubahan aplikasi. Saya tidak bisa memahami mengapa alat observabilitas tidak memanfaatkan itu. Kesenjangan AI menjadi jelas kemudian. Begitu platform Kubernetes kami matang, kami melihat pelanggan bergegas ke dalam penerapan GenAI sementara memperlakukan LLM seperti kotak hitam. Mereka tahu model merespons, tetapi tidak mengapa perilakunya tidak dapat diprediksi atau mengapa biaya melonjak. Kami menyadari bahwa alur kerja agen adalah mikroservis kompleks dan non-deterministik yang memerlukan visibilitas tanpa sentuhan yang sama seperti yang telah kami bangun sebelumnya.

Bagaimana latar belakang Anda di keamanan siber, sistem tertanam, dan R&D pembelajaran mesin mempengaruhi visi di balik groundcover, dan apa tantangan awal yang Anda hadapi dalam membangun perusahaan yang berfokus pada observabilitas untuk aplikasi LLM dan agen?

Latar belakang keamanan siber saya membentuk DNA perusahaan. Di dunia intelijen, Anda menganggap Anda tidak mengontrol aplikasi. Pendekatan itu adalah alasan groundcover tidak memerlukan instrumentasi. Saya tahu dari pengalaman bahwa meminta pengembang untuk memodifikasi kode adalah cara tercepat untuk memblokir adopsi. Tantangan terberat awal dengan pemantauan LLM adalah privasi. Observabilitas untuk AI menangkap prompt yang mungkin berisi data PII atau IP yang sensitif. Latar belakang saya membuatnya jelas bahwa perusahaan tidak akan ingin data itu meninggalkan lingkungan mereka. Itulah mengapa kami membangun arsitektur in-cloud, yang memungkinkan kami untuk memberikan visibilitas yang mendalam ke dalam perilaku agen sambil menjaga semua data di dalam lingkungan pelanggan.

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

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

Apa tantangan yang diperkenalkan aplikasi LLM yang membuat alat observabilitas tradisional tidak memadai?

Sistem LLM memperkenalkan beberapa tantangan yang mengekspos keterbatasan alat tradisional:

• Alur kerja multi-langkah yang kompleks – Kami berpindah dari alur sederhana “panggil model, dapatkan respons” ke agen multi-turn, pipa multi-langkah, generasi yang diperkaya dengan pengambilan, dan penggunaan alat. Kegagalan sunyi di salah satu langkah tersebut, seperti pengambilan, pengayaan, penyematan, panggilan alat, atau panggilan model, dapat merusak pengalaman secara keseluruhan. Pemantauan tradisional biasanya tidak memberikan Anda gambaran lengkap, tingkat jejak, dari rantai tersebut dengan prompt dan respons yang disertakan.
• Stack AI yang berkembang pesat – Tim menambahkan model, alat, dan vendor baru dengan kecepatan yang belum pernah mereka lihat sebelumnya. Di banyak perusahaan, tidak ada yang dapat dengan percaya diri menyebutkan model mana yang ada di produksi pada saat tertentu. Observabilitas klasik biasanya menganggap Anda memiliki waktu untuk menginstrumentasi SDK, mengatur ulang, dan mengkurasi apa yang diukur. Itu tidak dapat mengikuti kecepatan adopsi AI.
• Ekonomi berbasis token dan kuota – Harga dan batas tarif terkait dengan token dan panjang konteks, yang sering dikendalikan oleh pengembang, prompt, atau perilaku pengguna, bukan oleh operasi pusat. Alat tradisional tidak dirancang untuk menunjukkan “siapa membakar berapa banyak token pada model mana, untuk alur kerja mana, pada latensi berapa”.
• Korektif semantik alih-alih keberhasilan biner – LLM dapat mengembalikan kode 200 dan masih mengalami halusinasi, menyimpang dari prompt Anda, atau melanggar kebijakan. Alat tradisional melihat itu sebagai keberhasilan. Anda memerlukan observabilitas yang dapat menampilkan prompt dan respons dan memberikan konteks yang cukup untuk memeriksa perilaku dan, dari waktu ke waktu, memasang pemeriksaan kualitas otomatis.
• Data input sensitif yang mengalir ke pihak ketiga – LLM mengundang pengguna untuk berbagi informasi sangat sensitif melalui antarmuka seperti obrolan. Sekarang Anda bertanggung jawab atas data tersebut, di mana disimpan, dan vendor mana yang melihatnya. Observabilitas SaaS konvensional yang mengirimkan semua telemetri ke pihak ketiga seringkali tidak dapat diterima untuk beban kerja ini.

Semua ini berarti sistem LLM memerlukan observabilitas yang menyadari AI, kaya konteks, dan jauh lebih sedikit bergantung pada instrumentasi manual daripada alat yang sebagian besar tim gunakan saat ini.

Mana sinyal atau metrik 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 praktek:

Latensi dan throughput

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

Penggunaan token dan penggerak biaya

• Token input dan output per permintaan, dipecah per model.
• Penggunaan token yang diagregasi dari waktu ke waktu per model, tim, pengguna, dan alur kerja.
• Ukuran konteks untuk pipeline pengambilan yang padat sehingga Anda dapat melihat kapan prompt meledak.
• Ini adalah apa yang memungkinkan Anda untuk menjawab “Siapa yang sebenarnya menghabiskan anggaran AI kami dan untuk apa?”

Perilaku prompt dan respons

• Payload prompt dan respons yang sebenarnya pada jejak perwakilan, termasuk panggilan alat dan jalur penalaran.
• Alat mana yang dipilih LLM dan dalam urutan apa.
• Variansi respons untuk prompt serupa sehingga Anda dapat mengetahui seberapa stabil perilakunya.

Kehandalan dan kesalahan

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

Konteks infrastruktur klasik

• Metriks CPU, memori, dan jaringan wadah untuk layanan yang mengatur panggilan LLM Anda.
• Log yang berkorelasi yang menjelaskan apa yang dilakukan aplikasi.

Ketika Anda dapat melihat semua itu dalam satu tempat, observabilitas LLM bergerak dari “Saya tahu sesuatu lambat atau mahal” ke “Saya tahu model mana, pola prompt mana, dan layanan mana yang bertanggung jawab dan mengapa”.

Bagaimana observabilitas dapat membantu tim mendeteksi kegagalan sunyi seperti drift prompt, halusinasi, atau degradasi bertahap dalam kualitas output?

Kegagalan sunyi dalam sistem LLM biasanya terjadi ketika semuanya tampak “hijau” pada tingkat infrastruktur, tetapi perilaku sebenarnya sedang bergeser. Observabilitas membantu dengan beberapa cara:

• Melacak alur kerja penuh, bukan hanya panggilan model – Dengan menangkap jalur penuh dari permintaan klien ke layanan ke pengambilan ke model ke alat, Anda dapat melihat di mana perilaku berubah. Misalnya, mungkin pengambilan mulai mengembalikan dokumen yang lebih sedikit, atau panggilan alat terkadang gagal, dan model sedang melakukan improvisasi.
• Menjaga prompt, konteks, dan respons dalam pandangan – Ketika Anda dapat memeriksa prompt dan respons bersama dengan jejak, itu menjadi jauh lebih mudah untuk mendeteksi kasus di mana versi prompt baru, instruksi sistem baru, atau sumber konteks baru mengubah perilaku, bahkan jika latensi dan tingkat kesalahan tetap sama.
• Mengfilter dan memotong pada kondisi semantik – Begitu Anda memiliki telemetri LLM yang kaya, Anda dapat memfilter ke hal-hal seperti “panggilan dasar selama satu detik”, “permintaan yang menggunakan keluarga model ini”, atau “jejak yang melibatkan rute ini”, lalu membaca prompt dan respons untuk melihat apakah model sedang bergeser atau mengalami halusinasi dalam skenario tertentu.
• Mengaktifkan peringatan pada SLO tingkat bisnis – Anda dapat mendefinisikan SLO seperti “setiap panggilan LLM selama satu detik melanggar SLA pengguna kami” dan memicu peringatan ketika kondisi tersebut dipenuhi. Dari waktu ke waktu, SLO serupa dapat diikat ke skor kualitas atau pemeriksaan kebijakan sehingga Anda dapat diingatkan ketika kualitas memburuk, bukan hanya ketika infrastruktur gagal.

Karena lapisan observabilitas memiliki akses ke sinyal AI-spesifik dan log, metrik, dan jejak klasik, itu menjadi tempat alami untuk menangkap masalah yang akan merusak pengalaman pengguna secara sunyi.

Bagaimana pendekatan groundcover mendukung mendiagnosis latensi yang tidak dapat diprediksi atau perilaku yang tidak terduga dalam alur kerja agen multi-langkah dan panggilan alat?

groundcover mengambil pendekatan yang dirancang untuk sistem AI modern. Kami menggunakan sensor berbasis eBPF di tingkat kernel untuk mengamati lalu lintas di seluruh mikroservis tanpa perubahan kode atau pengaturan ulang. Begitu Anda memperkenalkan alur kerja LLM, kami dapat mendeteksi panggilan tersebut secara otomatis. Jika Anda mulai menggunakan model baru seperti Anthropic, OpenAI, atau Bedrock besok, groundcover menangkap lalu lintas tersebut secara otomatis. Itu memberi Anda:

• Jejak ujung ke ujung dari alur kerja multi-hop – Anda melihat jalur penuh dari permintaan di seluruh layanan, termasuk di mana LLM atau alat digunakan.
• Konteks yang mendalam pada setiap panggilan LLM – Setiap panggilan mencakup model yang digunakan, latensi, penggunaan token, prompt, respons, dan log serta metrik infra yang berkorelasi.
• Pengfilteran yang kuat pada latensi dan kondisi – Misalnya, Anda dapat memfilter semua panggilan Claude 3.5 yang lebih dari satu detik dan segera memeriksa jejak yang melanggar SLA Anda.
• Peringatan dan dasbor yang terkait dengan perilaku LLM – Begitu data tersedia, Anda dapat membuat peringatan untuk pelanggaran SLA atau membangun dasbor yang melacak latensi, throughput, penggunaan token, dan kesalahan.

Karena semuanya dikumpulkan di tepi oleh eBPF dan disimpan di cloud Anda sendiri, Anda mendapatkan pandangan granular tinggi tanpa menambahkan instrumentasi di dalam setiap agen atau panggilan alat.

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

Penerapan LLM membawa beberapa risiko data unik:

• Masukan pengguna tak terbatas – Pengguna dapat mengetikkan informasi sangat sensitif ke dalam antarmuka AI yang didukung. Itu mungkin termasuk data pribadi, data pelanggan, atau informasi yang diatur yang Anda tidak pernah bermaksud untuk mengumpulkan.
• Penyedia model pihak ketiga – Begitu Anda mengirim data tersebut ke penyedia LLM eksternal, Anda bertanggung jawab atas di mana data itu pergi, bagaimana disimpan, dan subprocessor mana yang terlibat. Itu memiliki implikasi besar untuk GDPR, kediaman data, dan kepercayaan pelanggan.
• Telemetri sebagai salinan kedua data sensitif – Jika tumpukan observabilitas Anda mengirimkan payload penuh ke vendor SaaS, Anda sekarang memiliki salinan lain dari informasi sensitif itu yang berada di luar lingkungan Anda.

Arsitektur groundcover dirancang untuk menangani kekhawatiran tersebut secara tepat:

• Kami menggunakan model “bawa cloud Anda sendiri” di mana backend observabilitas penuh berjalan di dalam akun cloud Anda, di sub-akun, sebagai dataplane yang sepenuhnya dikelola. Control plane yang menskalakan dan mengelolanya dijalankan oleh kami, tetapi kami tidak mengakses, menyimpan, atau memproses data telemetri Anda.
• Karena kami dapat dengan aman menangkap payload di lingkungan Anda sendiri, Anda dapat mengamati prompt, respons, dan alur kerja tanpa data itu pernah meninggalkan cloud Anda. Tidak ada penyimpanan pihak ketiga dari jejak LLM Anda dan tidak ada egress data tambahan untuk dikhawatirkan.
• Dengan visibilitas itu, Anda dapat melihat siapa yang mengunggah apa dan ke mana itu mengalir, mendeteksi penggunaan data sensitif yang tidak terduga, dan menerapkan kebijakan sekitar model dan wilayah mana yang diizinkan.

Dengan demikian, observabilitas menjadi tidak hanya alat keandalan dan biaya, tetapi juga titik kontrol kunci untuk privasi, kediaman data, dan kepatuhan.

Ketika organisasi berkembang dari satu integrasi LLM ke banyak layanan yang didukung AI, apa tantangan operasional yang cenderung muncul sekitar visibilitas, keandalan, dan biaya?

Integrasi pertama biasanya adalah model tunggal dalam alur kerja tunggal. Pada tahap itu, semuanya terasa dapat dikelola. Begitu tim melihat nilai, penggunaan meledak dan beberapa tantangan muncul:

• Model dan vendor yang berserakan – Tim menguji model baru secara konstan. Ini segera menjadi tidak jelas model mana yang ada di produksi dan bagaimana mereka digunakan.
• Kejutan biaya dari penggunaan token – Konsumsi token tumbuh dengan panjang konteks dan kompleksitas alur kerja. Tanpa visibilitas ke dalam penggunaan token per model dan alur kerja, mengelola biaya sangat sulit.
• Ketergantungan keandalan pada penyedia eksternal – API pengguna akhir menjadi sensitif terhadap latensi model atau kesalahan, yang dapat mengganggu SLA bahkan ketika infrastruktur inti sehat.
• Utang instrumentasi yang tumbuh – Observabilitas tradisional menganggap Anda memiliki waktu untuk menambahkan instrumentasi saat diperlukan. Dalam tumpukan AI yang berkembang pesat, pengembang jarang memiliki waktu untuk itu.

groundcover mengatasi ini dengan mendeteksi lalu lintas AI secara otomatis dan kemudian memberikan Anda:

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

Itu membuatnya jauh lebih mudah untuk berkembang dari “fitur AI yang keren” ke “AI yang terintegrasi ke dalam puluhan layanan kritis” tanpa kehilangan kontrol.

Menghadap ke depan, bagaimana Anda mengharapkan observabilitas LLM berkembang selama lima tahun ke depan ketika AI agen, orkestrasi multi-model, dan tekanan regulasi dipercepat?

Kami masih berada di hari-hari awal. Dalam lima tahun ke depan, saya mengharapkan beberapa pergeseran besar:

• Dari tingkat permintaan ke pemahaman tingkat agen – Observabilitas akan berkembang untuk menangkap urutan alat, jalur penalaran, dan logika pengulangan, 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.
• Pengikatan yang lebih ketat dengan tata kelola dan privasi – Ketika regulasi tumbuh, observabilitas juga akan berfungsi sebagai lapisan penegakan dan audit untuk kediaman data, retensi, dan penggunaan model yang disetujui.
• Optimasi lintas model, multi-vendor – Tim akan mengarahkan lalu lintas di seluruh model secara dinamis berdasarkan kinerja dan biaya, dipandu oleh data observabilitas waktu nyata.
• Kurangnya instrumentasi manual – Teknik seperti pengumpulan berbasis eBPF dan penemuan otomatis akan menjadi default, sehingga tim dapat berinovasi tanpa melambat.

Singkatnya, observabilitas LLM akan berkembang dari “nice to have dasbor untuk AI” menjadi sistem saraf pusat yang menghubungkan keandalan, kontrol biaya, tata kelola data, dan kualitas produk di seluruh apa yang dilakukan organisasi dengan AI.

Terima kasih atas wawancara yang luar biasa, pembaca yang ingin mempelajari lebih lanjut harus mengunjungi groundcover.