LLM Observability: Memantau Latensi, Biaya, dan Kualitas AI

Ketika fitur kecerdasan buatan sudah masuk ke aplikasi produksi, memeriksa apakah API berhasil mengembalikan respons saja tidak cukup. Pengguna bisa menerima jawaban yang lambat, menghabiskan token terlalu banyak, mengambil konteks yang keliru, atau menghasilkan keluaran yang tidak sesuai kebutuhan. Tanpa catatan yang tepat, tim sulit mengetahui bagian mana yang perlu diperbaiki.

LLM observability adalah praktik mengumpulkan dan menghubungkan sinyal operasional serta kualitas dari aplikasi yang menggunakan large language model (LLM). Tujuannya bukan mengawasi isi percakapan tanpa batas, melainkan memahami bagaimana sebuah permintaan diproses, berapa biayanya, di mana keterlambatan terjadi, dan apakah hasilnya memenuhi kriteria yang ditetapkan.

Mengapa pemantauan biasa belum cukup?

Pemantauan layanan tradisional biasanya berfokus pada ketersediaan, penggunaan CPU dan memori, latensi, serta tingkat error. Sinyal tersebut tetap penting, tetapi tidak selalu menjelaskan perilaku sistem AI. Sebuah permintaan dapat berstatus sukses secara teknis, sementara model menjawab dengan informasi yang tidak relevan atau tidak menggunakan dokumen yang seharusnya menjadi sumber.

Aplikasi berbasis LLM juga sering terdiri dari beberapa tahap: menerima masukan, menyusun prompt, mencari dokumen, memanggil model, menggunakan alat, lalu memvalidasi hasil. Jika semuanya dicatat sebagai satu permintaan besar, tim akan kesulitan menemukan tahap yang menambah latensi atau menghasilkan kesalahan. Observability membantu menghubungkan tahapan itu menjadi satu jejak proses.

Empat kelompok sinyal yang perlu dipantau

1. Latensi dan keandalan

Ukur waktu total dari permintaan masuk hingga jawaban siap digunakan, lalu pisahkan waktu tiap tahap. Pada layanan model, waktu hingga token pertama dan waktu penyelesaian penuh bisa sama-sama berguna, terutama untuk respons streaming. Catat juga timeout, pembatasan laju, kegagalan penyedia, percobaan ulang, dan pembatalan oleh pengguna.

2. Token dan biaya

Catat jumlah token masukan dan keluaran, model yang digunakan, serta biaya perkiraan berdasarkan tarif yang berlaku. Bedakan biaya tiap permintaan dari akumulasi per pengguna, fitur, atau lingkungan. Prompt yang membengkak, riwayat percakapan terlalu panjang, dan pengulangan pemanggilan alat dapat meningkatkan biaya tanpa memberi manfaat sepadan.

3. Alur dan konteks

Untuk sistem retrieval-augmented generation (RAG), rekam metadata proses pencarian: jumlah dokumen yang ditemukan, skor relevansi, sumber yang dipilih, dan versi indeks. Untuk pemanggilan alat, catat nama alat, durasi, hasil sukses atau gagal, dan jumlah percobaan. Data ini membantu membedakan masalah model dari masalah retrieval, basis data, atau layanan eksternal.

4. Kualitas keluaran

Kualitas perlu diukur terpisah dari keberhasilan teknis. Gunakan evaluasi yang sesuai dengan fitur: kesesuaian terhadap sumber, kelengkapan, format, tingkat penolakan yang tepat, atau penilaian pengguna. Pemeriksaan otomatis dapat membantu menyaring kasus, tetapi hasilnya perlu dikalibrasi dengan contoh yang dinilai manusia. Jangan menjadikan satu skor sebagai ukuran universal untuk semua jenis tugas.

Menerapkan tracing pada satu permintaan

Buat satu trace untuk setiap permintaan pengguna dan tambahkan span untuk tahap-tahap penting, misalnya pengambilan konteks, pemanggilan model, pemanggilan alat, dan validasi. Gunakan ID korelasi agar log dari layanan berbeda dapat disatukan tanpa mengandalkan teks prompt sebagai kunci. Jika aplikasi sudah menggunakan standar observability seperti OpenTelemetry, pertimbangkan untuk meneruskan trace ke sistem yang sama dengan layanan lain.

Metadata yang berguna antara lain nama model, versi prompt, lingkungan, durasi, jumlah token, status akhir, serta versi konfigurasi retrieval. Simpan informasi secukupnya untuk menjawab pertanyaan operasional. Hindari menaruh seluruh percakapan atau data rahasia di atribut trace hanya karena tersedia kolom untuk itu.

Privasi dan keamanan log AI

Prompt dan respons dapat memuat alamat email, informasi pelanggan, kode sumber, kredensial yang tidak sengaja ditempelkan, atau data internal. Terapkan minimisasi data sejak desain: redaksi pola sensitif, pembatasan akses berbasis peran, enkripsi, dan masa retensi yang jelas. Batasi pula siapa yang dapat mengekspor trace, karena akses observability bisa menjadi jalur tidak langsung menuju data produksi.

Jangan mencatat API key, token autentikasi, atau rahasia sistem. Untuk investigasi, gunakan ID permintaan, ringkasan terkontrol, serta contoh yang sudah disamarkan. Jika isi lengkap diperlukan untuk kasus tertentu, pisahkan penyimpanannya dari metrik umum, beri akses terbatas, dan audit setiap penggunaan. Pastikan kebijakan pencatatan sesuai dengan pemberitahuan privasi dan kewajiban organisasi.

Membuat dashboard dan peringatan yang berguna

Mulailah dari beberapa pertanyaan yang bisa ditindaklanjuti: apakah latensi meningkat, apakah tingkat error berubah, fitur mana yang paling banyak memakai token, dan apakah hasil evaluasi turun setelah perubahan prompt atau model? Tampilkan tren serta persentil latensi, bukan hanya rata-rata yang dapat menyembunyikan permintaan sangat lambat.

Peringatan sebaiknya berdasarkan dampak dan pola yang stabil. Contohnya, lonjakan timeout selama beberapa menit atau biaya harian yang melampaui anggaran. Hindari membuat peringatan untuk setiap variasi kecil; terlalu banyak notifikasi akan membuat tim mengabaikan sinyal penting. Hubungkan setiap peringatan dengan langkah pemeriksaan yang jelas.

Evaluasi perubahan sebelum dirilis

Gunakan kumpulan contoh uji yang mewakili penggunaan nyata, termasuk masukan ambigu, dokumen kosong, permintaan berbahaya, dan kegagalan alat. Jalankan evaluasi sebelum serta sesudah mengganti model, prompt, atau konfigurasi retrieval. Bandingkan kualitas, latensi, biaya, dan tingkat kegagalan secara bersamaan agar peningkatan di satu sisi tidak menutupi kemunduran di sisi lain.

Mulai dengan sampel terbatas dan perluas cakupan secara bertahap. Tetapkan pemilik metrik, ambang yang masuk akal, dan proses untuk meninjau hasil yang menyimpang. Untuk konteks tracing dan metrik layanan yang lebih luas, baca juga panduan OpenTelemetry: logs, metrics, dan traces untuk troubleshooting aplikasi.

Kesimpulan

LLM observability menggabungkan pemantauan operasional, penelusuran alur, pengukuran biaya, dan evaluasi kualitas agar aplikasi AI lebih mudah dipahami saat berjalan di produksi. Mulailah dengan sinyal yang benar-benar membantu keputusan, lindungi data sensitif, dan uji perubahan menggunakan contoh yang representatif. Dengan pendekatan ini, tim dapat menemukan sumber masalah lebih cepat tanpa mengorbankan privasi pengguna atau menganggap setiap respons yang berhasil dikirim sebagai jawaban yang benar.