Tentang Sesi Ini
Ringkasan & metadata
Catatan: ini adalah sesi sponsor oleh Datadog — sebuah platform observability. Materi memaparkan sudut pandang Datadog tentang pemantauan aplikasi GenAI. Buku ini adalah rangkuman edukatif independen, bukan materi pemasaran resmi.
Selama bertahun-tahun, para praktisi SRE (Site Reliability Engineering) bersandar pada apa yang disebut "golden signals" — empat sinyal emas untuk memantau kesehatan sistem: latency (seberapa cepat respons), traffic (seberapa banyak permintaan), errors (seberapa sering gagal), dan saturation (seberapa penuh sumber daya). Untuk aplikasi web dan API klasik, keempatnya sudah cukup untuk tahu kapan sistem sehat atau sakit.
Tapi begitu aplikasi Anda ditenagai model bahasa besar (LLM), gambaran itu jadi menyesatkan. Sebuah API bisa merespons cepat (latency bagus), tanpa error (kode 200), sumber daya lega (saturation rendah) — dan tetap memberi jawaban yang salah, mengarang fakta, atau membakar biaya token secara diam-diam. Semua lampu hijau, tetapi pengguna dirugikan. Di sinilah sesi ini masuk: mengapa kita harus melampaui golden signals dan sinyal baru apa yang perlu dipantau di era GenAI.
Kenapa penting untuk Anda? Jika tim Anda sudah menaruh aplikasi LLM di produksi tetapi masih memantaunya seperti API biasa, Anda kemungkinan besar buta terhadap masalah yang paling merugikan: kualitas jawaban yang menurun, halusinasi, dan biaya yang membengkak.
Kenapa Metrik Klasik Tak Cukup
Kenapa golden signals tak cukup
Golden signals mengukur apakah sistem berjalan, bukan apakah sistem berguna. Untuk layanan tradisional, keduanya nyaris sama: kalau API mengembalikan data dengan cepat dan tanpa error, ia sudah memenuhi tugasnya. Untuk aplikasi LLM, keduanya bisa berpisah jauh.
Perbedaan mendasarnya: keluaran LLM bersifat probabilistik dan berbentuk teks bebas, bukan nilai pasti. Sebuah endpoint yang mengembalikan HTTP 200 dengan isi kalimat yang meyakinkan namun keliru tetap dianggap "sukses" oleh metrik klasik. Padahal justru kalimat itulah yang bisa menyesatkan pengguna, melanggar kebijakan, atau merusak reputasi. Karena itu, memantau LLM menuntut sinyal yang menilai isi jawaban, bukan hanya status pengirimannya.
Prinsipnya bukan membuang golden signals, melainkan memperluasnya. Latency, traffic, errors, dan saturation tetap dibutuhkan — kita hanya menambahkan lapisan sinyal baru yang khusus memahami perilaku model.
Sinyal baru di era GenAI
Berikut sinyal-sinyal tambahan yang dibahas, sebagai fondasi LLM Observability. Ikon di bawah menandai kategori yang perlu dipantau:
Kunci menyatukan semuanya adalah evaluasi otomatis: menilai jawaban model secara berkelanjutan (mis. dengan model penilai atau aturan) sehingga penurunan kualitas terdeteksi lebih dini — sama seperti error rate memberi tahu sistem sedang bermasalah, "quality score" memberi tahu jawaban sedang memburuk.
Analogi yang Mudah Dicerna
Dasbor mobil lama vs mobil pintar
Ibaratnya, golden signals adalah dasbor mobil bensin biasa: ada jarum bensin dan spidometer kecepatan. Selama Anda mengendarai mobil bensin lama, dua meter itu sudah cukup untuk tahu apakah perjalanan aman — masih ada bensin, kecepatan wajar.
Tapi begitu Anda beralih ke "mobil listrik pintar" (aplikasi LLM), dua meter itu tidak lagi menceritakan kondisi sebenarnya. Mobil listrik tak punya tangki bensin; yang penting adalah daya baterai, efisiensi, suhu, dan kesehatan perangkat lunak. Kalau Anda hanya melihat spidometer, mobil bisa melaju mulus sambil baterainya diam-diam habis atau perangkat lunaknya salah membaca rambu. Anda butuh meter baru agar tahu keadaan yang sesungguhnya.
- Jarum bensin lama = golden signals (latency, traffic, errors, saturation) — masih berguna, tapi tak menceritakan segalanya.
- Meter daya baterai = biaya token — sumber daya yang benar-benar terkuras tiap kali model bekerja.
- Meter efisiensi = kualitas & relevansi jawaban — apakah "energi" dipakai untuk hasil yang berguna.
- Peringatan perangkat lunak = deteksi halusinasi, drift, & keamanan prompt — mobil melaju, tapi apakah ia "berpikir" benar?
High-Level Architecture & Alur
High-Level Architecture (HLA)
Secara garis besar, observability GenAI menyisipkan lapisan pemantauan di sekeliling aplikasi LLM. Aplikasi Anda memanggil model (mis. lewat Amazon Bedrock), lalu setiap langkah — prompt, panggilan alat, respons — dikirim sebagai traces, metrics, dan logs ke platform observability. Di sana, sinyal baru dihitung (biaya token, skor kualitas, deteksi halusinasi) lalu diteruskan ke dasbor dan alerting.
Alur observability satu permintaan
Ketika seorang pengguna mengirim pertanyaan ke aplikasi LLM, inilah yang dipantau di balik layar:
- Terima prompt. Permintaan pengguna dan konteksnya direkam sebagai awal sebuah trace.
- Panggil model. Model (mis. di Bedrock) memproses; latensi model dan jumlah token masuk/keluar dicatat.
- Rantai alat. Bila agen memanggil alat atau basis pengetahuan, tiap langkah menjadi span dalam trace yang sama.
- Evaluasi jawaban. Output dinilai otomatis: relevan? faktual? aman? Skornya jadi metrik.
- Hitung biaya. Token dikalikan tarif menjadi biaya per permintaan, diagregasi jadi tren harian.
- Alert bila melenceng. Jika kualitas turun, biaya melonjak, atau halusinasi terdeteksi, peringatan dikirim.
Dari Konsep ke Bisnis Nyata
Contoh nyata (konteks Indonesia)
Agar tidak berhenti di teori, berikut tiga skenario penerapan yang khas ditemui tim yang mengoperasikan GenAI di Indonesia.
Menjaga kualitas chatbot yang sudah dipakai jutaan pengguna
Sebuah marketplace menjalankan chatbot LLM di produksi. Golden signals menunjukkan semua sehat, tapi keluhan pengguna naik. Dengan LLM Observability, tim menelusuri trace per percakapan dan menemukan model mulai menjawab di luar topik setelah pembaruan prompt. Evaluasi kualitas otomatis menandai penurunan skor relevansi lebih dini, sebelum viral di media sosial.
Mencegah "tagihan token" membengkak diam-diam
Sebuah startup fintech menemukan biaya inferensi melonjak tanpa penjelasan. Lewat pemantauan token cost per fitur, mereka melihat satu alur retrieval mengirim konteks jauh lebih panjang dari perlu. Dengan alerting berbasis anggaran, lonjakan biaya kini terdeteksi dalam hitungan menit, bukan saat tagihan bulanan datang — sambil tetap menjaga skor kualitas jawaban.
Menyatukan pemantauan AI ke dalam praktik keandalan
Tim platform sebuah perusahaan telko menyediakan "AI sebagai layanan" bagi tim internal. Mereka memperluas dasbor SRE yang sudah ada dengan sinyal GenAI: latensi model, drift perilaku, dan deteksi keamanan prompt. Ketika sebuah model versi baru mulai menyimpang, alert menyala dan tim dapat melakukan rollback — memperlakukan kualitas AI setegas mereka memperlakukan uptime.
Ringkasan Visual (Geser)
Ringkasan visual
Enam kartu berikut merangkum inti sesi. Gunakan tombol atau tombol panah keyboard (← →) untuk berpindah.
Poin yang Bisa Dibawa Pulang
Poin yang bisa dibawa pulang
- Golden signals tetap perlu, tapi tak cukup. Untuk LLM, "sistem berjalan" tidak sama dengan "jawaban berguna".
- Pantau sinyal baru: kualitas & relevansi, halusinasi, biaya token, latensi model, keamanan prompt, dan drift.
- LLM Observability = tracing + evaluasi otomatis. Telusuri rantai prompt→tool→respons dan nilai output secara berkelanjutan.
- Integrasikan, jangan menyilo. Sambungkan pemantauan aplikasi LLM di AWS/Bedrock ke praktik keandalan (SRE) yang sudah Anda jalankan.