← Blog · Engineering · 9 min read
Aplikasi AI gagal dengan cara yang sunyi. Tanpa observability, Anda buta terhadap penurunan kualitas. Artikel ini menunjukkan apa yang harus dilacak dan bagaimana.
A 30-minute scoping call. We listen, ask three questions, tell you if we can help.
Book a callAplikasi perangkat lunak tradisional gagal dengan suara keras. Server mati, error muncul di log, alarm berbunyi, dan tim tahu ada masalah. Aplikasi AI gagal dengan cara yang jauh lebih berbahaya: secara sunyi. Model tetap mengembalikan respons dengan kode status 200, antarmuka tampak normal, tidak ada exception yang terlempar. Tetapi diam-diam, kualitas jawaban menurun, model mulai berhalusinasi pada kategori pertanyaan tertentu, atau distribusi input bergeser sehingga model bekerja jauh di bawah performa awalnya. Tidak ada yang menyadarinya sampai pengguna mengeluh, atau lebih buruk, sampai mereka diam-diam pergi.
Inilah mengapa observability untuk aplikasi AI bukan kemewahan, melainkan kebutuhan dasar. Tanpa kemampuan melihat apa yang terjadi di dalam sistem AI di produksi, Anda menerbangkan pesawat tanpa instrumen. Artikel ini membahas apa yang harus dilacak dalam aplikasi AI, mengapa observability AI berbeda dari monitoring tradisional, dan bagaimana membangunnya secara praktis dengan perangkat yang tersedia.
Monitoring perangkat lunak konvensional berfokus pada metrik yang jelas benar atau salah: latensi, tingkat error, penggunaan CPU, throughput. Metrik ini tetap relevan untuk aplikasi AI, tetapi sama sekali tidak cukup.
Tantangan unik aplikasi AI ada pada sifat keluarannya. Sebuah respons LLM bisa selesai cepat, tanpa error, dan tetap salah total. Kualitas tidak biner, melainkan spektrum yang menuntut penilaian. Selain itu, sistem AI bersifat non-deterministik: input yang sama bisa menghasilkan output berbeda, sehingga reproduksi masalah jauh lebih sulit.
Aplikasi AI modern juga sering merupakan rantai panjang: retrieval mengambil dokumen, prompt dirakit, model membangkitkan jawaban, output diurai dan divalidasi, mungkin agent memanggil beberapa tool secara berurutan. Kegagalan bisa terjadi di mana saja dalam rantai ini, dan tanpa visibilitas ke setiap langkah, mendiagnosis akar masalah menjadi tebak-tebakan yang melelahkan.
Fondasi observability AI adalah tracing, yaitu merekam jejak lengkap setiap permintaan dari awal hingga akhir, mencakup setiap langkah perantara. Untuk aplikasi LLM, satu trace idealnya menangkap seluruh rantai.
Hal yang layak direkam dalam sebuah trace:
Input pengguna apa adanya, sebagai titik awal.
Langkah retrieval: kueri yang dijalankan, dokumen yang diambil, dan skor relevansinya. Banyak kegagalan berakar di sini, dan tanpa melihatnya, Anda akan menyalahkan model padahal masalahnya retrieval.
Prompt final yang benar-benar dikirim ke model, termasuk konteks yang disisipkan. Prompt yang dirakit sering berbeda dari yang dibayangkan tim.
Respons model mentah, sebelum pasca-pemrosesan.
Pemanggilan tool pada sistem agent: tool apa dipanggil, dengan argumen apa, dan hasilnya.
Metadata: model yang dipakai, jumlah token, latensi tiap langkah, dan biaya.
Ketika sebuah jawaban buruk dilaporkan, trace lengkap memungkinkan Anda menelusuri persis di mana rantai itu tergelincir. Apakah retrieval mengambil dokumen yang salah? Apakah prompt kehilangan konteks penting? Apakah model menyimpang dari sumber? Tanpa tracing, ketiga pertanyaan ini hanya bisa dijawab dengan dugaan.
Logging adalah fondasi, tetapi mencatat semuanya tanpa struktur sama tidak bergunanya dengan tidak mencatat apa pun. Logging yang berguna terstruktur dan dapat dicari.
Catat pasangan input-output secara terstruktur sehingga dapat dianalisis belakangan: untuk menemukan pola kegagalan, membangun dataset evaluasi dari kasus nyata, dan menyelidiki keluhan spesifik. Sertakan pengidentifikasi yang memungkinkan korelasi, seperti ID sesi dan ID pengguna, agar Anda dapat merekonstruksi perjalanan lengkap saat menyelidiki insiden.
Namun, logging aplikasi AI membawa tanggung jawab privasi yang serius. Input dan output sering memuat data pribadi, dan di Indonesia ini tunduk pada UU PDP No. 27/2022. Terapkan minimisasi, redaksi data sensitif sebelum disimpan, kontrol akses ketat, dan kebijakan retensi yang jelas. Observability tidak boleh menjadi pintu belakang kebocoran data.
Yang tidak dapat Anda lihat tidak dapat Anda perbaiki. Yang Anda simpan sembarangan dapat menjadi pertanggungjawaban hukum.
Evaluasi offline terhadap golden dataset penting, tetapi tidak menangkap apa yang terjadi pada lalu lintas produksi yang sesungguhnya. Evaluasi online mengisi celah ini dengan menilai kualitas keluaran secara berkelanjutan di lingkungan nyata.
Beberapa pendekatan yang dapat dikombinasikan:
LLM-as-judge: gunakan model untuk menilai sampel keluaran produksi pada dimensi seperti faithfulness terhadap sumber, relevansi, dan kelengkapan. Ini memungkinkan penilaian berskala tanpa meninjau setiap respons secara manual.
Sinyal implisit pengguna: lacak perilaku yang mengindikasikan kualitas, seperti apakah pengguna mengulang pertanyaan, meninggalkan sesi, atau mengeskalasi ke manusia. Sinyal ini gratis dan jujur.
Umpan balik eksplisit: sediakan mekanisme sederhana bagi pengguna menandai jawaban baik atau buruk, dan jadikan setiap umpan balik negatif kasus yang ditinjau.
Tinjauan manusia tersampel: tinjau sampel acak secara berkala untuk kalibrasi, sebab penilai otomatis pun bisa keliru dan perlu diperiksa.
Kuncinya adalah mengubah kualitas dari sesuatu yang abstrak menjadi metrik yang dipantau seperti metrik operasional lainnya.
Dua ancaman sunyi yang paling sering luput tanpa observability adalah drift dan regresi.
Drift terjadi ketika dunia berubah sementara sistem tidak. Distribusi pertanyaan pengguna bergeser, terminologi baru muncul, atau pola perilaku berubah seiring musim. Model yang dilatih atau dievaluasi pada pola lama mulai bekerja lebih buruk pada pola baru tanpa ada yang berubah dalam kode Anda. Pantau distribusi input dari waktu ke waktu untuk mendeteksi pergeseran ini sebelum ia menggerus kualitas secara signifikan.
Regresi terjadi ketika perubahan yang Anda buat sendiri memperburuk keadaan. Mengganti versi model, menyetel prompt, atau memperbarui basis pengetahuan dapat memperbaiki sebagian kasus sambil diam-diam merusak yang lain. Tanpa pemantauan, regresi ini lolos ke produksi. Tetapkan ambang kualitas sebagai gerbang sebelum perubahan dirilis luas, dan bandingkan metrik sebelum dan sesudah setiap perubahan. Banyak tim terkejut menemukan bahwa "peningkatan" yang mereka rilis sebenarnya menurunkan kualitas pada segmen pengguna tertentu.
Data yang terkumpul tidak bernilai jika tidak diubah menjadi visibilitas yang dapat ditindaklanjuti. Bangun dashboard yang menyatukan metrik operasional dan metrik kualitas dalam satu pandangan.
Dashboard kualitas yang baik menampilkan tren skor kualitas dari waktu ke waktu, sebaran biaya dan latensi, tingkat eskalasi ke manusia, dan kategori pertanyaan yang paling sering gagal. Visibilitas ini membantu tim memprioritaskan perbaikan berdasarkan dampak nyata, bukan tebakan.
Alerting menutup lingkaran. Tetapkan peringatan untuk anomali yang menuntut perhatian: lonjakan tingkat eskalasi, penurunan skor faithfulness, kenaikan biaya per permintaan yang tidak wajar, atau lonjakan latensi. Rancang alert agar bermakna, bukan bising. Alert yang terlalu sering memicu kelelahan dan akhirnya diabaikan, sehingga insiden nyata terlewat di tengah kebisingan.
Ekosistem observability LLM telah matang. Tersedia banyak perangkat khusus, termasuk opsi open-source yang dapat dijalankan sendiri untuk tim yang ingin menjaga data tetap di infrastruktur mereka, hal yang relevan bagi institusi keuangan atau pemerintah di Indonesia dengan tuntutan kedaulatan data. Standar tracing terbuka memungkinkan integrasi dengan perangkat pemantauan yang mungkin sudah Anda miliki. Pilihan teknologi spesifik kurang penting dibanding komitmen untuk benar-benar merekam, mengukur, dan menindaklanjuti.
Satu dimensi observability yang sering terlupakan adalah biaya. Aplikasi LLM memiliki struktur biaya yang berbeda dari perangkat lunak tradisional: setiap permintaan menanggung biaya token yang berbanding lurus dengan panjang konteks dan keluaran. Tanpa visibilitas, biaya ini dapat meledak diam-diam, persis seperti kualitas dapat menurun tanpa terdeteksi.
Lacak biaya pada granularitas yang berguna: per permintaan, per fitur, per pengguna, dan per kategori pertanyaan. Visibilitas ini sering mengungkap temuan mengejutkan, misalnya satu fitur kecil yang ternyata menyedot porsi besar tagihan karena prompt yang terlalu panjang, atau segelintir pengguna yang menghasilkan biaya tidak proporsional. Dengan data ini, tim dapat mengambil keputusan terinformasi: memangkas konteks yang tidak perlu, mengarahkan pertanyaan sederhana ke model yang lebih murah, atau menerapkan caching pada pola berulang.
Pasangkan pemantauan biaya dengan batas anggaran yang tegas. Tetapkan alert ketika biaya harian melampaui ambang yang diharapkan, dan pertimbangkan batas keras untuk mencegah lonjakan akibat bug atau penyalahgunaan. Bagi tim keuangan yang menyetujui anggaran AI, kemampuan menunjukkan ke mana setiap Rupiah mengalir adalah pembeda antara investasi yang dipercaya dan eksperimen yang dicurigai.
Observability mencapai nilai penuhnya hanya ketika terhubung ke siklus perbaikan yang nyata. Data yang dikumpulkan harus mengalir kembali menjadi tindakan, bukan sekadar arsip.
Pola yang efektif membentuk lingkaran tertutup. Kasus kegagalan yang tertangkap di produksi dikurasi menjadi dataset uji. Dataset ini memperkaya evaluasi offline, sehingga perbaikan dapat diuji terhadap kegagalan nyata sebelum dirilis. Perubahan yang lolos gerbang kualitas dirilis, lalu dipantau kembali di produksi melalui observability yang sama. Lingkaran ini, dari produksi ke evaluasi ke perbaikan dan kembali ke produksi, adalah mesin yang membuat kualitas sistem AI meningkat seiring waktu alih-alih merosot.
Tanpa lingkaran ini, observability menjadi latihan pasif: tim melihat masalah tetapi tidak punya jalur sistematis untuk memperbaikinya, dan kegagalan yang sama berulang. Dengan lingkaran ini, setiap insiden menjadi pelajaran yang permanen tertanam dalam dataset uji, sehingga sistem menjadi lebih tangguh dari waktu ke waktu.
Ketika aplikasi AI berevolusi dari sekadar tanya-jawab menjadi agent yang merencanakan, memanggil tool, dan mengambil tindakan secara otonom, kebutuhan observability melonjak drastis. Agent dapat menjalankan banyak langkah berurutan, dan kegagalan di langkah ketiga dapat berakar dari keputusan keliru di langkah pertama yang tampak wajar saat itu.
Untuk sistem agent, tracing harus menangkap keseluruhan pohon keputusan: rencana yang disusun agent, tool apa yang dipanggil pada setiap titik, argumen yang dikirim, hasil yang dikembalikan, dan bagaimana agent menafsirkan hasil itu untuk langkah berikutnya. Tanpa visibilitas ke seluruh rantai ini, mendiagnosis mengapa agent mengambil tindakan yang salah menjadi nyaris mustahil.
Beberapa hal yang khusus penting dipantau pada agent:
Loop dan kemacetan: agent dapat terjebak mengulang langkah yang sama atau gagal mencapai tujuan. Pantau jumlah langkah per tugas dan tetapkan batas agar tidak ada agent yang berputar tanpa henti, membakar biaya dan waktu.
Penyalahgunaan tool: agent yang memanggil tool dengan argumen tidak valid atau dalam urutan yang keliru adalah sinyal masalah penalaran yang perlu ditangkap.
Tindakan berisiko: untuk agent yang dapat mengubah keadaan, seperti mengirim pesan atau memperbarui data, catat dan, jika perlu, gerbangi tindakan paling sensitif dengan persetujuan sebelum dieksekusi.
Sistem agent memberi otonomi yang lebih besar, dan otonomi tanpa observability adalah resep untuk kegagalan yang sulit ditelusuri dan mahal.
Observability bukan proyek sekali pasang lalu dilupakan, melainkan praktik berkelanjutan. Tim yang berhasil membangun kebiasaan: meninjau dashboard kualitas secara rutin, menyelidiki setiap penurunan, mengubah kasus kegagalan nyata menjadi dataset uji, dan memperlakukan kualitas AI sebagai metrik operasional sekelas uptime.
Tanpa budaya ini, perangkat observability tercanggih pun akan menjadi dashboard yang tidak pernah dilihat siapa pun. Observability memberi mata; disiplin tim yang memutuskan apakah mata itu digunakan untuk melihat dan bertindak.
Aplikasi AI gagal dengan sunyi, dan tanpa observability, penurunan kualitas baru disadari setelah pengguna kehilangan kepercayaan dan pergi. Membangun visibilitas penuh, melalui tracing end-to-end, logging yang patuh privasi, evaluasi online, deteksi drift dan regresi, serta dashboard dan alerting yang bermakna, adalah yang membedakan sistem AI yang dapat dioperasikan dengan percaya diri dari yang berjalan dalam kegelapan.
Sainskerta Solusi Nusantara membantu perusahaan Indonesia membangun aplikasi AI yang dapat diamati dan dipercaya sepanjang fase strategi hingga operasi. Kami merancang lapisan observability yang sesuai dengan tuntutan kepatuhan UU PDP dan kedaulatan data sektor Anda, sehingga tim Anda dapat mendeteksi masalah sebelum pengguna melakukannya. Jika produk AI Anda sudah berjalan di produksi tetapi Anda merasa buta terhadap kualitas nyatanya, hubungi tim kami melalui halaman Kontak untuk menjadwalkan sesi konsultasi dan menyusun strategi observability yang konkret.
