Jeff Champagne, Field CTO di Cribl – Seri Wawancara

Jeff Champagne, Field CTO di Cribl, membawa pengalaman mendalam di bidang observabilitas, data perusahaan, strategi produk, dan arsitektur teknis. Sebelum bergabung dengan Cribl, ia menjabat sebagai Direktur Manajemen Produk di Databricks dan menghabiskan lebih dari tujuh tahun di Splunk dalam peran produk lapangan senior, arsitektur, dan teknik sistem global. Latar belakangnya juga mencakup kepemimpinan arsitektur sistem di BNY ConvergEx, pekerjaan teknik senior di Premier Technology Solutions, dan kepemimpinan teknik awal di Assist-2-Sell, memberinya perspektif yang luas tentang bagaimana perusahaan mengumpulkan, mengelola, menganalisis, dan bertindak berdasarkan data operasional skala besar.

Cribl adalah perusahaan telemetri perusahaan yang fokus membantu tim IT, keamanan, SRE, dan DevOps mengumpulkan, memproses, mengarahkan, menyimpan, dan menganalisis data observabilitas dan keamanan tanpa terkunci pada vendor tunggal. Perusahaan ini memposisikan diri sebagai “Platform AI untuk Telemetri,” dengan produk seperti Cribl Stream untuk pengumpulan telemetri waktu nyata, pengurangan, pengayaan, dan pengarahan; Cribl Edge untuk pengumpulan telemetri endpoint vendor-netral; Cribl Search untuk mencari data di tempat; dan Cribl Lake untuk penyimpanan. Misi yang lebih luas adalah memberikan perusahaan lebih banyak kontrol, fleksibilitas, dan efisiensi saat volume telemetri tumbuh dan operasi yang didorong AI memerlukan data yang lebih bersih dan lebih mudah diakses.

Anda telah bekerja di Splunk, Databricks, dan sekarang Cribl, memberi Anda pandangan langka tentang data perusahaan, observabilitas, dan infrastruktur selama beberapa siklus teknologi. Dari perspektif itu, apa yang terasa benar-benar berbeda tentang tantangan observabilitas yang dibuat oleh AI agen?

Dalam observabilitas aplikasi, kami selalu menangani jalur eksekusi yang kompleks dan bercabang, melacak permintaan melalui layanan mikro dan mengorelasikan log di seluruh sistem terdistribusi. Dalam operasi keamanan, kami menangani sumber data yang berbeda-beda dan ber volume tinggi untuk mendeteksi ancaman di seluruh sistem yang, meskipun kompleks, masih berperilaku dalam cara yang dapat diprediksi. AI agen tidak mengubah kembali masalah-masalah tersebut; itu meledakkan mereka secara bersamaan.

Agen menghubungkan keputusan, memanggil alat eksternal, dan memunculkan sub-agen secara dinamis dengan cara yang tidak ditentukan sebelumnya pada saat penulisan. Grafik eksekusi tidak hanya kompleks, tetapi juga dapat sangat berbeda setiap kali, dan volume telemetri yang diperlukan untuk merekonstruksi apa yang sebenarnya terjadi tumbuh secara eksponensial dengan setiap lompatan.. Mengumpulkan semua telemetri yang diperlukan untuk membuat sistem agen observable harus mudah diinstrumentasikan dan efektif biaya untuk dioperasikan pada skala besar. Jika tidak, perusahaan akan membuat trade-off yang sama seperti yang mereka lakukan sebelumnya dan mengurangi visibilitas untuk mengontrol biaya — tepat pada saat yang salah untuk menjadi buta.

Sebagai perusahaan memasukkan agen otonom ke dalam alur kerja, di mana letak kesenjangan visibilitas terbesar antara apa yang diminta agen untuk dilakukan dan apa yang sebenarnya terjadi di seluruh sistem yang mendasarinya?

Agen menyelesaikan alur kerja yang tampak sukses di permukaan sementara diam-diam membuat panggilan alat yang buruk, menghalusikan parameter, atau menyimpang dari tujuan asli. Konsekuensinya sering muncul beberapa jam kemudian di sistem lain.

Putusnya biasanya dimulai pada interpretasi: sedikit ketidakjelasan dalam instruksi asli diselesaikan secara berbeda tergantung pada apa yang diambil agen dari memori, alat apa yang tersedia pada saat itu, atau bagaimana langkah sebelumnya dalam rantai membentuk konteksnya. Anda juga harus menginstrumentasikan sistem hilir yang agen bergantung, karena agen dapat membuat panggilan database yang sempurna dan masih mengembalikan jawaban yang salah jika tabel yang mendasarinya tidak pernah diperbarui karena pekerjaan ETL gagal secara diam-diam di hulu.

Agen melakukan tepat apa yang diperintahkan; data yang dipercayainya hanya sudah ketinggalan zaman.

Mengapa alat observabilitas tradisional sering tidak memadai untuk memantau sistem AI agen?

Pertama, mereka dibangun di sekitar skema kaku dan propietary serta bentuk data yang dapat diprediksi. Jejak agen tidak sesuai dengan harapan tersebut — mereka ber volume besar, sangat bervariasi dalam struktur, dan mencakup jenis data seperti teks prompt lengkap, rantai alasan model, dan muatan panggilan alat yang alat warisan tidak dirancang untuk mengkonsumsi tanpa pekerjaan transformasi yang signifikan. Standar terbuka seperti konvensi semantik GenAI OpenTelemetry muncul untuk menangani ini, tetapi banyak platform warisan tidak dibangun untuk mengambil keuntungan dari mereka.

Kedua, persamaan skala dan biaya rusak dengan cepat. Satu agen yang menangani beban kerja produksi dapat menghasilkan lebih banyak telemetri dalam satu jam daripada seluruh tumpukan aplikasi yang dihasilkan dalam satu hari, dan sebagian besar platform tradisional mengenakan biaya berdasarkan volume yang dikonsumsi dan disimpan. Itu menciptakan trade-off yang tidak mungkin — baik Anda menginstrumentasikan semuanya dan menghadapi biaya yang tidak terkendali, atau mengurangi visibilitas ke sistem di mana Anda membutuhkannya paling banyak.

Ketika agen AI gagal, bagaimana organisasi dapat menentukan apakah penyebab akar adalah model, lapisan pengambilan, ketergantungan API, masalah izin, atau masalah infrastruktur hilir?

Mengisolasi penyebab akar dalam kegagalan agen adalah proses eliminasi melintasi lapisan. Ini hanya berhasil jika telemetri Anda mencakup semua lapisan secara konsisten. Sinyal latensi dan kesalahan pada span model menunjukkan LLM itu sendiri. Span pengambilan memberitahu Anda apakah konteks yang dikembalikan relevan atau sudah ketinggalan zaman. Span panggilan alat memaparkan ketergantungan API yang gagal atau kesalahan izin.

Seperti yang disebutkan, Anda juga memerlukan telemetri dari sistem hilir yang agen bergantung, karena agen dapat membuat panggilan yang sempurna dan masih menghasilkan jawaban yang salah jika data yang dipercayainya tidak pernah diperbarui. Tidak ada satu sinyal yang menceritakan seluruh cerita, yang mengapa mengorelasikan di seluruh lapisan tersebut dalam satu tempat adalah apa yang membedakan tim yang dapat memecahkan kegagalan agen dengan cepat dari mereka yang masih menebak.

Jenis telemetri data apa yang menjadi paling penting ketika perusahaan berusaha memahami perilaku agen pada skala besar?

Dasarannya masih MELT — metrik, acara, log, dan jejak — tetapi bobotnya bergeser secara signifikan ketika Anda memasuki sistem agen. Metrik memberitahu Anda sesuatu salah dan log memberikan catatan mentah tentang apa yang terjadi, tetapi keduanya tidak dapat merekonstruksi rantai alasan yang diikuti agen untuk mencapai jawaban yang salah. Itulah di mana jejak menjadi sinyal paling kritis.

Dalam sistem terdistribusi tradisional, jejak menunjukkan bagaimana permintaan bergerak melalui layanan. Dalam sistem agen, itu menunjukkan bagaimana model beralasan melalui masalah, alat apa yang dipanggil, konteks apa yang diambil, di mana ia bercabang, dan apa yang diputuskan pada setiap langkah. Tanpa jejak itu, Anda hanya melihat output dengan tidak ada cara untuk menjelaskan bagaimana Anda sampai di sana.

Sinyal MELT lainnya tidak menghilang; metrik pada penggunaan token dan latensi penting untuk biaya dan kinerja, dan log dari sistem hilir tetap penting. Tetapi jejak adalah apa yang membuat perilaku agen dapat dibaca pada skala besar.

Banyak diskusi AI masih fokus berat pada halusinasi. Apakah perusahaan meremehkan kegagalan operasional seperti pengambilan yang buruk, integrasi yang rusak, lonjakan latensi, atau konteks yang hilang?

Sebagian besar halusinasi dalam produksi bukanlah kegagalan model; mereka adalah kegagalan operasional yang disamaratakan. Pengambilan yang buruk mengembalikan konteks yang sudah ketinggalan zaman atau tidak lengkap, dan model mengisi celah dengan sesuatu yang terdengar masuk akal. Integrasi yang rusak berarti agen tidak pernah mendapatkan data yang diperlukan untuk beralasan dengan benar dari awal. Konteks yang hilang dari pekerjaan ETL yang gagal terlihat seperti halusinasi tetapi sebenarnya adalah masalah infrastruktur.

Ketika tim tidak dapat melihat perbedaan, mereka beralih ke apa yang dapat mereka kontrol, yang biasanya adalah model itu sendiri. Mereka mengulangi sistem prompt, menambahkan penghalang, dan memperbarui kerangka evaluasi, dan meskipun teknik-teknik tersebut memiliki nilai nyata, mereka mengobati gejala daripada penyebabnya. Dalam pengalaman saya, investasi dengan pengaruh tertinggi hampir selalu kualitas data dan kesegaran di lapisan pengambilan. Agen yang terletak dengan baik dengan data yang bersih dan mutakhir akan mengungguli agen yang dirancang dengan baik tetapi bekerja dari konteks yang sudah ketinggalan zaman atau tidak lengkap setiap saat.

Seiring agen menjadi lebih otonom, apa yang harus dilakukan tim perusahaan untuk mempertahankan akuntabilitas tanpa terjebak dalam kebisingan?

Dasarannya masih MELT, tetapi akuntabilitas untuk sistem agen memerlukan lapisan kerangka evaluasi di atas telemetri tradisional. Metrik, acara, dan log memunculkan kegagalan infrastruktur dan integrasi yang rusak yang dapat merusak perilaku agen sebelum model merespons; jejak memberikan Anda rantai alasan untuk memahami mengapa mencapai jawaban tertentu. Tetapi keduanya tidak memberitahu Anda apakah jawaban itu sebenarnya benar, dan itulah di mana evaluasi LLM-as-judge mengisi celah. Kemampuan AI yang sama yang memungkinkan agen dapat digunakan untuk menilai mereka, memberi skor output untuk akurasi, kelengkapan, dan penyelesaian tugas pada skala yang tidak dapat dicapai oleh proses tinjauan manusia.

Sebelum produksi, itu bertindak sebagai gerbang kualitas, menangkap regressi sebelum mencapai pengguna. Dalam produksi, itu menjadi pemantau terus-menerus, mengambil sampel lalu lintas langsung dan memflag respons yang jatuh di luar ambang batas yang dapat diterima. Kunci untuk menghindari kebisingan adalah mengakui bahwa tidak semua alur kerja agen membawa risiko yang sama, yang berarti beralih dari pemantauan seragam ke sesuatu yang industri mulai sebut sebagai tata kelola human-on-the-loop. Anda mendefinisikan baseline perilaku dan ambang batas kepercayaan sebelumnya, biarkan agen beroperasi, dan simpan intervensi manusia untuk pengecualian.

Apa peran yang dapat dimainkan oleh pipa telemetri dalam membantu tim keamanan, SRE, data, dan AI bekerja dari pandangan bersama tentang perilaku agen?

Tim keamanan, SRE, insinyur data, dan tim AI semua melihat irisan yang berbeda dari masalah yang sama melalui alat yang berbeda, dan tidak ada satu pun dari mereka yang memiliki gambaran lengkap sendiri. Alasan pipa telemetri telah menjadi bagian standar dari arsitektur data perusahaan modern adalah bahwa mereka menyelesaikan masalah tepat ini: satu pipa yang tergovernan dengan baik di hulu dari semua alat Anda memastikan setiap tim bekerja dari data yang sama yang dinormalisasi dan diperkaya tanpa agen dan pengumpul khusus yang dikerahkan untuk setiap tim.

Kelenturan itu penting pada dua tingkat. Yang pertama adalah tiering data. Pipa telemetri yang dirancang dengan baik memungkinkan Anda untuk mencocokkan data dengan strategi penyimpanan dan analisis yang tepat sehingga Anda tidak membayar harga analitik untuk data yang hanya Anda butuhkan untuk retensi kepatuhan jangka panjang. Yang kedua adalah pilihan sebagai lanskap alat AI terus berkembang dengan cepat. Perusahaan yang membangun strategi observabilitas mereka di sekitar ekosistem vendor tunggal akan menghadapi proyek migrasi yang mahal setiap kali alat yang lebih baik muncul.

Apa kesalahan yang Anda lihat perusahaan lakukan ketika mereka mencoba memasang praktik pemantauan yang ada ke penggunaan AI agen?

Kesalahan paling umum yang saya lihat adalah mencapai platform observabilitas premium yang ada untuk mengumpulkan jejak agen tanpa memikirkan implikasi biaya terlebih dahulu. Jejak agen besar, bervariasi, dan ber volume besar dengan cara yang telemetri aplikasi tradisional tidak. Sebagian besar platform premium mengenakan biaya berdasarkan penggunaan dan penyimpanan. Tagihan dapat menjadi masalah serius sebelum tim menyadari apa yang terjadi, dan respons tipikal adalah mengurangi apa yang mereka kumpulkan. Hasilnya adalah yang terburuk dari kedua dunia: biaya tinggi dan visibilitas yang tidak lengkap.

Kesalahan kedua adalah menerapkan model mental yang salah untuk apa yang seharusnya dipantau. Pemantauan infrastruktur tradisional bertanya “apakah sistem menyala?” dan mengangkat alert ketika tidak. Pertanyaan itu perlu dan cukup dekat dengan apa yang dibutuhkan untuk sistem agen, di mana infrastruktur dapat sehat tetapi agen diam-diam membuat keputusan yang buruk, mengambil data yang sudah ketinggalan zaman, atau menyimpang dari tujuan aslinya. Tim yang memasang dasbor dan ambang batas yang ada ke alur kerja agen sering kali membujuk diri mereka sendiri bahwa mereka memiliki cakupan ketika mereka sebenarnya hanya memantau pipa.

Kesalahan ketiga adalah mengobati instrumentasi sebagai sesuatu yang dapat ditunda. Perusahaan yang mempilot agen dengan cepat dan memindahkan ke produksi tanpa memikirkan observabilitas berakhir dalam siklus perbaikan yang mahal, membangun kembali arsitektur pengumpulan data setelah kegagalan produksi yang signifikan pertama. Tim yang menskalakan penggunaan agen paling sukses menginstrumentasikan awal, membangun baseline saat lalu lintas rendah dan perilaku dapat diprediksi, dan membangun kerangka evaluasi mereka sebelum mereka membutuhkannya daripada setelah sesuatu salah.

Menghadap ke depan, apakah visibilitas infrastruktur akan menjadi prasyarat untuk adopsi AI perusahaan dengan cara yang sama seperti observabilitas awan menjadi penting untuk migrasi awan skala besar?

Paralel dengan awan sangat mirip. Hal paling penting yang saya katakan kepada pelanggan ketika mereka memindahkan infrastruktur ke awan adalah bahwa mereka tidak melakukan lift dan shift. Mereka mengirim arsitektur baru dengan kemampuan baru. Semua itu perlu diinstrumentasikan dan dipantau dengan cara yang alat sebelumnya tidak disiapkan. Perusahaan yang melewatkan langkah itu menghadapi kegagalan yang berantai yang tidak dapat didiagnosis, biaya yang tidak dapat dijelaskan, dan gangguan yang tidak dapat dicegah. Observabilitas menjadi dasar kepercayaan yang membuat skala awan memungkinkan, dan pola yang sama sedang terjadi sekarang dengan AI agen, bergerak lebih cepat dan dengan taruhan yang lebih tinggi.

Alasan utama agen akan memerlukan pengawasan jenis ini secara permanen adalah bahwa mereka dirancang untuk non-deterministik, perilakunya muncul pada runtime, dan kemampuan efektifnya tumbuh setiap kali Anda menghubungkan alat baru. Sertifikasi pra-deployment statis tidak dapat menutupi sistem yang permukaan aksi berubah dengan setiap integrasi. Agen akan beroperasi dalam batasan kepercayaan yang ditentukan, dan batasan tersebut akan berkembang seiring waktu ketika infrastruktur observabilitas, kebijakan, dan evaluasi matang. Batasan itu sendiri tidak akan pernah menghilang, dan itu bukanlah kegagalan. Itulah cara setiap sistem otonom yang signifikan di dunia sudah bekerja.

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