Daftar Periksa Implementasi AI Observability: 20 Langkah Produksi
Sebuah daftar periksa implementasi AI observability seharusnya menjawab pertanyaan yang lebih sulit daripada “apakah API-nya aktif?” Sebuah fitur AI produksi dapat mengembalikan HTTP 200 sambil memberikan jawaban yang salah, menggunakan konteks retrieval yang kedaluwarsa, memanggil tool yang salah, melakukan retry melalui fallback yang mahal, membocorkan data prompt sensitif ke log, atau membutuhkan waktu terlalu lama untuk berguna.
Tujuan praktisnya adalah menghubungkan setiap hasil yang terlihat oleh pengguna dengan percobaan model, langkah retrieval, panggilan tool, keputusan kebijakan, latensi, penggunaan token, dan biaya yang menghasilkan hasil tersebut. Itu membutuhkan telemetry aplikasi konvensional ditambah konteks dan sinyal evaluasi khusus AI.
Panduan ini menyediakan rencana implementasi bertahap untuk aplikasi LLM, agen, sistem retrieval-augmented generation, dan gateway multi-model. Panduan ini netral terhadap vendor dan menggunakan konsep OpenTelemetry bila memungkinkan. Panduan ini juga mencakup peta sinyal-ke-keputusan, matriks uji penerimaan, rencana peluncuran tujuh hari, kontrak telemetry, pola instrumentasi, runbook alert, dan kartu skor vendor sehingga tim dapat bergerak dari persyaratan ke peluncuran operasional.
AI Observability dalam Satu Kalimat
AI observability adalah kemampuan untuk menjelaskan perilaku, kualitas, keandalan, keamanan, dan biaya dari sebuah alur kerja AI berdasarkan kumpulan trace, metrik, log, evaluasi, dan hasil pengguna yang saling berkorelasi.
Monitoring memberi tahu Anda bahwa sebuah ambang batas berubah. Observability membantu Anda menentukan mengapa perubahan itu terjadi dan request, model, prompt, hasil retrieval, tool, tenant, atau rilis mana yang terlibat.
Gunakan daftar periksa implementasi AI observability dalam panduan ini sebagai gate rilis, bukan sebagai latihan dokumentasi satu kali. Jalankan ulang setiap kali Anda mengubah model, prompt, indeks retrieval, skema tool, kebijakan routing, atau evaluator.
Untuk sebuah aplikasi AI, satu request dapat berisi beberapa percobaan yang berbeda:
aksi pengguna
└─ alur kerja aplikasi
├─ kueri retrieval
├─ percobaan model 1
├─ panggilan tool
├─ percobaan model 2
└─ validasi dan hasil yang terlihat oleh pengguna
Jika langkah-langkah ini tidak dapat digabungkan di bawah satu trace atau identitas request, debugging akan menjadi tebakan.
Model Data Minimum AI Observability
Model data adalah fondasi dari daftar periksa implementasi AI observability karena setiap dashboard, alert, evaluasi, dan kueri insiden bergantung pada bidang korelasi yang konsisten.
Mulailah dengan satu trace tingkat alur kerja dan child span untuk setiap operasi yang material. OpenTelemetry mendefinisikan trace, metrik, log, dan baggage sebagai sinyal inti. Konvensi semantik generative AI-nya menyediakan kosakata yang terus berkembang untuk operasi model dan agen dan, per 4 Agustus 2026, dipelihara di repositori konvensi semantik OpenTelemetry khusus. Karena konvensi tersebut dapat berevolusi, tetapkan versi yang Anda implementasikan dan pertahankan lapisan kompatibilitas internal yang kecil daripada menyebarkan nama field spesifik vendor di seluruh kode Anda.
Sekurangnya, tangkap kelompok field berikut.
| Kelompok bidang | Apa yang harus dicatat | Mengapa ini penting |
|---|---|---|
| Correlation | trace_id, request_id, ID sesi, workflow, environment, release |
Menggabungkan jalur permintaan secara lengkap |
| Route | provider, model yang diminta, model yang ter-resolve, region, endpoint atau alias route | Menjelaskan di mana permintaan sebenarnya dijalankan |
| Attempt | nomor percobaan, alasan retry, sumber dan tujuan fallback | Memisahkan satu permintaan pengguna dari beberapa panggilan yang ditagihkan |
| Performance | waktu antre, waktu hingga token pertama, latensi total, latensi tool dan retrieval | Menemukan tahap yang lambat |
| Usage | input, input yang di-cache, output, reasoning, atau field penggunaan khusus provider | Menjelaskan kapasitas dan biaya |
| Result | status, kelas error yang dinormalisasi, alasan selesai, hasil validasi | Membedakan keberhasilan transport dari keberhasilan tugas |
| Quality | versi evaluator, skor, lulus/gagal, umpan balik pengguna, outcome yang diterima | Melacak apakah respons bermanfaat |
| Governance | tenant, keputusan kebijakan, status redaksi, kelas retensi | Mendukung kontrol privasi dan audit |
Hindari memperlakukan prompt mentah dan respons sebagai field wajib. Dalam banyak sistem, keduanya sebaiknya dinonaktifkan secara default atau disimpan hanya dalam dataset evaluasi yang dikontrol secara terpisah.
Petakan Setiap Sinyal ke Keputusan Operasional
Lebih banyak telemetri tidak selalu lebih baik. Sebelum menambahkan atribut, metrik, atau dashboard, sebutkan keputusan yang didukungnya dan orang yang memiliki keputusan tersebut.
| Sinyal | Pertanyaan yang dijawab | Keputusan tipikal | Pemilik utama |
|---|---|---|---|
| Tingkat completion yang diterima | Apakah workflow menyelesaikan tugas pelanggan? | Rollback, ubah prompt/model, atau selidiki kegagalan downstream | Product dan AI engineering |
| Latensi end-to-end p95 | Apakah pengalaman lengkap cukup cepat? | Ubah route, kurangi latensi retrieval/tool, atau sesuaikan streaming | Platform engineering |
| Waktu hingga token pertama | Apakah streaming terasa responsif? | Sesuaikan antrean, route provider, atau ukuran prompt | Platform engineering |
| Tingkat fallback | Apakah route utama sehat dan ekonomis? | Selidiki kesehatan provider, kapasitas, atau kebijakan route | Reliability engineering |
| Biaya per outcome yang diterima | Apakah retry dan hasil berkualitas rendah menghapus penghematan? | Ubah kombinasi model, caching, ukuran prompt, atau validasi | Engineering dan FinOps |
| Tingkat kelulusan grounding retrieval | Apakah jawaban menggunakan konteks yang relevan dan diotorisasi? | Bangun ulang index, filter, reranker, atau validasi sitasi | Pemilik Search/RAG |
| Kegagalan rekonsiliasi tool | Apakah efek samping eksternal selesai dengan aman? | Jeda tool, rekonsiliasi status, atau perbaiki idempotency | Pemilik aplikasi |
| Jumlah kegagalan redaksi | Apakah data sensitif mencapai exporter? | Hentikan ekspor, karantina telemetri, atau perbarui kebijakan | Keamanan/privasi |
Tabel ini mencegah mode kegagalan umum di mana sebuah dasbor berisi puluhan bagan tetapi tidak ada yang tahu tindakan apa yang harus dipicu oleh perubahan.
Bentuk Trace yang Praktis
Gunakan satu trace untuk alur kerja yang terlihat oleh pengguna, bukan satu trace terpisah yang tidak berkaitan untuk setiap panggilan provider. Root harus menjelaskan tugas pelanggan, sementara span anak menjelaskan operasi yang berkontribusi pada hasil.
workflow: answer_support_question
attributes: tenant_class, release, accepted_outcome, final_status
├─ retrieval.search
│ attributes: index_version, top_k, authorization_result
├─ gen_ai.attempt
│ attributes: provider, requested_model, resolved_model, attempt=1
├─ tool.lookup_order
│ attributes: tool_schema_version, idempotency_key, result
├─ gen_ai.attempt
│ attributes: provider, resolved_model, attempt=2, fallback_reason
└─ evaluation.validate_answer
attributes: evaluator_version, pass, score_band
Konvensi semantik generative AI OpenTelemetry masih terus berkembang. Perlakukan itu sebagai kosakata bersama, tetapi kunci versi konvensinya, catat setiap ekstensi lokal, dan uji peningkatan di staging. Simpan hasil bisnis seperti accepted_outcome di namespace aplikasi stabil milik Anda sendiri agar perubahan pada konvensi semantik tidak merusak pelaporan produk.
Fase 1: Tentukan Hasil Sebelum Menambahkan Dasbor
1. Beri nama alur kerja dan hasil yang diterima
Jangan mulai dengan bagan token seluruh provider. Mulailah dengan tugas pelanggan seperti:
- jawaban dukungan diterima tanpa eskalasi;
- patch kode lolos pengujian;
- ekstraksi cocok dengan skema yang diperlukan;
- agen menyelesaikan tindakan yang diminta tanpa pemulihan manual;
- media yang dihasilkan lolos gerbang tinjauan produk.
Buat nama workflow yang dapat dibaca mesin dan accepted_outcome atau hasil setara. Ini menjadi penyebut untuk metrik kualitas, biaya, dan keandalan.
2. Tentukan taksonomi kegagalan
Pisahkan setidaknya kelas-kelas berikut:
- kegagalan transport: timeout, error koneksi, atau upstream 5xx;
- kegagalan kapasitas: rate limit, kuota, saturasi antrean, atau batas konteks;
- kegagalan kontrak: JSON tidak valid, field hilang, skema tool tidak didukung, atau stream rusak;
- kegagalan kualitas: jawaban tidak relevan, salah, tidak lengkap, atau tidak berbasis bukti;
- kegagalan keamanan: pelanggaran kebijakan, prompt injection berhasil, atau eksekusi tool yang tidak aman;
- kegagalan bisnis: output secara teknis valid tetapi ditolak atau ditinggalkan oleh pengguna.
Dimensi tunggal error=true tidaklah cukup. Itu menyembunyikan apakah Anda memerlukan pekerjaan infrastruktur, perubahan prompt, perubahan model, atau perubahan produk.
3. Pilih indikator level layanan awal
Mulailah dengan seperangkat kecil yang mencerminkan pengalaman pengguna:
workflow availability = accepted workflow completions / eligible workflow starts
quality pass rate = evaluator-passing completions / evaluated completions
p95 end-to-end latency = p95(workflow completed - workflow started)
cost per accepted outcome = total workflow cost / accepted outcomes
Pertahankan ketersediaan provider sebagai metrik diagnostik, bukan SLI produk. Sebuah provider bisa sehat sementara alur kerja Anda gagal karena retrieval, tools, validasi, atau routing bermasalah.
Fase 2: Instrumentasikan Jalur Permintaan Lengkap
4. Buat satu root span untuk setiap alur kerja yang terlihat oleh pengguna
Generate root trace di batas aplikasi, sebelum retrieval atau routing model dimulai. Propagasikan konteks itu melalui antrean, worker, gateway, layanan tool, dan callback.
Gunakan child span untuk:
- retrieval dan reranking;
- setiap percobaan model;
- setiap panggilan tool;
- pemeriksaan guardrail atau kebijakan;
- parsing dan validasi output;
- pemilihan fallback;
- persistensi dan pengiriman downstream.
5. Catat route yang diminta dan yang diselesaikan
Model yang dinamai oleh klien tidak selalu model yang melayani request. Catat keduanya:
{
"ai.requested_model": "support-balanced",
"ai.resolved_provider": "provider-b",
"ai.resolved_model": "model-version-2026-07",
"ai.route_reason": "primary_rate_limited",
"ai.attempt": 2
}
Ini penting untuk sistem multi-provider. Ini juga membuat strategi fallback model dapat diaudit, bukan tak terlihat.
6. Ukur streaming secara terpisah
Latensi total saja tidak menggambarkan pengalaman streaming. Tangkap:
- durasi antrean;
- latensi koneksi dan provider;
- waktu hingga token pertama atau event pertama yang berguna;
- durasi generasi;
- waktu penyelesaian end-to-end;
- waktu pembatalan oleh klien.
Sebuah request dapat memiliki latensi total yang dapat diterima tetapi waktu hingga token pertama buruk. Request juga bisa menghasilkan token pertama dengan cepat lalu macet.
7. Jadikan retry dan fallback sebagai percobaan kelas satu
Jangan pernah menimpa percobaan pertama yang gagal dengan keberhasilan akhir. Satu span workflow harus berisi atau menautkan setiap percobaan yang dapat ditagih, termasuk:
- nomor retry;
- pemicu;
- durasi backoff;
- provider dan model;
- token dan biaya;
- status output parsial;
- disposisi akhir.
Ini mencegah badai retry terlihat sebagai “100% sukses.”
Fase 3: Tambahkan Konteks Kualitas Khusus AI
8. Versikan prompt, alat, kebijakan, dan evaluator
Simpan pengenal stabil, bukan hanya konten mentah:
prompt_version
tool_schema_version
retrieval_index_version
policy_version
evaluator_version
route_policy_version
Dimensi ini memungkinkan Anda membandingkan rilis sebelum dan sesudah perubahan. Tanpa versioning, penurunan kualitas akan sulit diatribusikan.
9. Lacak kualitas retrieval
Untuk retrieval-augmented generation, catat:
- versi kueri dan filter;
- latensi retrieval;
- ID dokumen atau chunk;
- kesegaran sumber;
- top-k dan versi reranker;
- tingkat hasil kosong;
- keputusan kontrol akses;
- hasil validasi sitasi atau grounding.
Jangan letakkan dokumen pribadi lengkap di penyimpanan trace serbaguna. Simpan referensi terkontrol atau hash kecuali kebijakan debugging secara eksplisit mengizinkan pengambilan konten.
10. Lacak panggilan alat dan efek samping
Setiap span tool harus mencakup nama tool, versi skema, keputusan otorisasi, latensi, hasil yang dinormalisasi, dan apakah tool tersebut menghasilkan efek samping eksternal.
Untuk tool yang menimbulkan efek samping, catat juga idempotency key dan state rekonsiliasi. Ini penting ketika panggilan model time out setelah tool selesai dijalankan.
11. Gabungkan evaluasi online dan offline
Sinyal online cepat tetapi berisik: thumbs-up, abandonment, regeneration, correction, escalation, atau penyelesaian tugas. Evaluasi offline lebih lambat tetapi terkontrol: curated test set, rubric grader, executable test, dan review manusia.
Hubungkan keduanya ke workflow dan pengenal versi yang sama. Jangan mencampur skor dari versi evaluator yang berbeda ke dalam satu garis tren tanpa memberi label pada perubahan tersebut.
Fase 4: Kontrol Privasi, Keamanan, dan Retensi
12. Klasifikasikan telemetry sebelum pengumpulan
Tentukan tiga tingkat:
- Metadata: route, timing, token, status, versi, dan ID.
- Sinyal konten turunan: panjang, bahasa, kategori keamanan, skor evaluator, atau hash.
- Konten mentah: prompt, respons, teks yang diambil, argumen tool, dan hasil tool.
Kumpulkan metadata secara luas. Kumpulkan konten mentah hanya ketika use case, pemberitahuan kepada pengguna, kontrol akses, dan kebijakan retensi mendukungnya.
13. Redaksi di batas pengumpulan
Redaksi sebaiknya dilakukan sebelum ekspor jika memungkinkan. Lindungi:
- API key, bearer token, cookie, dan authorization header;
- alamat email, nomor telepon, nomor akun, dan pengenal pemerintah;
- rahasia di dalam argumen tool atau dokumen yang diambil;
- signed URL dan database connection string;
- konten khusus tenant yang dilarang berada di shared observability store.
Gunakan allowlist untuk atribut yang diekspor. Denylist pada akhirnya akan melewatkan field baru yang mengandung rahasia. Terapkan disiplin yang sama seperti yang dijelaskan dalam panduan manajemen AI API key ini.
14. Atur retensi dan akses berdasarkan kelas data
Konten mentah tidak boleh mewarisi retensi yang sama seperti metrik berisiko rendah. Tentukan storage terpisah, enkripsi, peran akses, audit log, dan proses penghapusan. Uji penghapusan alih-alih berasumsi bahwa dokumen kebijakan sudah cukup.
NIST AI Risk Management Framework dan Generative AI Profile-nya menekankan pengukuran berkelanjutan, dokumentasi, dan manajemen risiko di seluruh siklus hidup sistem. Observability membantu menyediakan bukti, tetapi logging yang sembarangan dapat menciptakan risiko privasi dan keamanan baru.
15. Kontrol dimensi ber-cardinality tinggi
Jangan menjadikan user ID, trace ID, teks prompt, document ID, atau pesan error mentah sebagai label metrik. Simpan data ber-cardinality tinggi dalam trace atau log, lalu turunkan metrik yang dibatasi seperti workflow, model family, class error, environment, dan region.
Fase 5: Bangun Alert yang Mengarah ke Tindakan
16. Beri alert pada gejala yang berdampak pada pengguna
Page pada gejala seperti:
- tingkat completion yang diterima berada di bawah objective;
- quality pass rate turun melewati release guardrail;
- latensi p95 atau time to first token menghabiskan error budget;
- biaya per hasil yang diterima melebihi batasnya;
- efek samping yang tidak aman atau kegagalan kebijakan;
- fallback rate naik di atas rentang normalnya.
Gunakan error dari provider, lonjakan token, dan miss retrieval sebagai alert diagnostik atau sinyal dashboard kecuali jika hal-hal tersebut secara langsung mengancam tujuan yang terlihat oleh pengguna.
17. Gunakan jendela burn-rate untuk alert SLO
Threshold statis bisa menghasilkan banyak noise. Alerting burn-rate error budget menanyakan seberapa cepat layanan mengonsumsi budget kegagalan yang diizinkan. Panduan SRE Google merekomendasikan menggabungkan jendela yang lebih cepat dengan jendela konfirmasi yang lebih lambat agar insiden berat segera memicu pager tanpa membuat setiap lonjakan singkat menjadi tindakan yang harus ditindaklanjuti.
18. Tambahkan anotasi rilis dan route
Setiap dashboard harus menampilkan rilis prompt, aplikasi, routing, model, dan evaluator. Tambahkan anotasi deployment dan bandingkan kohort canary versus kontrol. Jika tidak, tim akan melihat sebuah garis bergerak tanpa melihat apa yang berubah.
Fase 6: Validasi Sebelum Rollout Penuh
19. Jalankan drill kegagalan
Uji setidaknya:
- timeout upstream;
- rate limit dan kehabisan kuota;
- output terstruktur yang salah format;
- gangguan streaming parsial;
- retrieval tidak mengembalikan konteks yang berwenang;
- tool berhasil tetapi respons hilang;
- fallback mengubah perilaku model;
- telemetry exporter tidak tersedia;
- aturan redaksi menerima field yang tidak dikenal.
Pastikan workflow gagal dengan aman, trace tetap koheren, dan alert mengidentifikasi pemilik yang tepat.
20. Lakukan rollout dalam empat tahap
- Shadow: emit telemetry tanpa mengubah routing atau perilaku pengguna.
- Canary: aktifkan untuk sebagian kecil traffic dan bandingkan overhead, cardinality, dan kualitas data.
- Guarded production: tambahkan threshold rilis dan aturan rollback.
- Full production: perluas setelah pemeriksaan privasi, keandalan, dan biaya lolos.
OpenTelemetry mendukung pola sampling head dan tail. Pertahankan semua error dan kelas kegagalan yang jarang jika memungkinkan, lalu sampel traffic sukses rutin untuk mengendalikan biaya. Aturan sampling tidak boleh menghapus trace tepat yang dibutuhkan untuk menjelaskan suatu insiden.
Matriks Acceptance-Test Produksi
Acceptance test membuktikan bahwa daftar periksa implementasi AI observability berfungsi dalam skenario kegagalan, privasi, dan kehilangan telemetry, bukan hanya pada request yang berhasil.
Jangan nyatakan observability selesai hanya karena span muncul di trace viewer. Jalankan pengujian terkontrol dan simpan bukti untuk setiap gate rilis.
| Pengujian | Kondisi yang diinjeksi | Bukti telemetri yang diperlukan | Kondisi lulus |
|---|---|---|---|
| Timeout upstream | Paksa rute model utama melampaui batas waktunya | Span percobaan pertama, kelas timeout, keputusan retry atau fallback, hasil akhir | Tidak ada span yatim; disposisi akhir dan total biaya terlihat |
| Batas laju | Kembalikan 429 dari penyedia atau habiskan kuota pengujian | Kode mentah penyedia, kelas kapasitas yang dinormalisasi, durasi backoff, perubahan rute | Anggaran retry dibatasi dan alert mengarah ke pemilik rute |
| Output terstruktur tidak valid | Kembalikan JSON yang rusak atau field wajib yang hilang | Span validasi kontrak, versi validator, upaya perbaikan, hasil akhir lulus/gagal | Keberhasilan HTTP tidak dihitung sebagai keberhasilan yang diterima |
| Stream rusak | Hentikan output setelah token pertama | Waktu ke token pertama, flag output parsial, penggunaan yang dapat ditagihkan, keputusan retry | Konten duplikat dan eksekusi tool ganda dicegah |
| Retrieval kosong | Kembalikan tidak ada dokumen yang diizinkan | Filter retrieval, hasil otorisasi, alasan hasil kosong, kebijakan jawaban | Sistem mengikuti perilaku tanpa konteks yang disetujui |
| Ambiguitas tool | Biarkan sebuah tool selesai sementara permintaan model habis waktunya | Idempotency key, status side effect, hasil rekonsiliasi | Tool tidak dieksekusi dua kali dan status dapat dipulihkan |
| Canary redaksi | Sisipkan secret sintetis ke field pengujian | Peristiwa deteksi lokal tanpa nilai secret yang diekspor | Ekspor diblokir atau direduksi sebelum melewati batas |
| Gangguan exporter | Hentikan destinasi telemetri | Metrik antrean/drop exporter dan kesehatan aplikasi | Lalu lintas pengguna tetap berada dalam anggaran keandalannya |
| Pemeriksaan sampling | Hasilkan error langka di tengah lalu lintas keberhasilan tinggi | Trace error dipertahankan; keberhasilan rutin di-sample sesuai konfigurasi | Contoh insiden tetap dapat dicari setelah sampling |
| Regresi rilis | Deploy canary dengan latensi atau degradasi kualitas yang sudah diketahui | Anotasi rilis, cohort canary, cohort kontrol, perbandingan SLI | Ambang rollback terpenuhi dengan pemilik perubahan yang dapat diidentifikasi |
Untuk setiap pengujian, catat pemilik, tanggal pengujian, trace ID, alert yang diharapkan, alert yang diamati, dan tiket remediasi. Ini mengubah observability menjadi kontrol rilis yang dapat diulang, bukan proyek instrumentasi sekali pakai.
Rencana Implementasi Tujuh Hari
Untuk tim yang fokus, daftar periksa implementasi AI observability dapat diimplementasikan sebagai urutan tujuh hari yang meninggalkan bukti yang dapat ditinjau setiap harinya.
Urutan ini sengaja dibuat sempit. Ini menghasilkan vertical slice yang tepercaya sebelum tim memperluas cakupan.
- Hari 1 — Kontrak hasil: pilih satu alur kerja bernilai tinggi, tentukan awal yang memenuhi syarat, hasil yang diterima, kelas kegagalan, dan rumus SLI.
- Hari 2 — Kerangka trace: buat span root alur kerja dan propagasikan konteks melalui aplikasi, antrean, gateway, lapisan retrieval, dan tools.
- Hari 3 — Percobaan model: tangkap rute yang diminta dan yang terselesaikan, jumlah percobaan, latensi, alasan selesai, penggunaan provider, retry, dan fallback.
- Hari 4 — Kualitas dan biaya: gabungkan hasil validator, versi evaluator, hasil pengguna, dan biaya alur kerja yang dinormalisasi.
- Hari 5 — Kontrol privasi: klasifikasikan field, terapkan ekspor allowlist, uji redaksi, tetapkan retensi, dan verifikasi batas akses.
- Hari 6 — SLO dan dashboard: bangun dashboard minimum, tambahkan anotasi rilis, definisikan alert burn-rate, dan tetapkan penanggung jawab.
- Hari 7 — Latihan kegagalan: jalankan matriks penerimaan, perbaiki celah, mulai canary, dan dokumentasikan kondisi rollback.
Pada akhir hari ketujuh, tujuannya bukan instrumentasi universal. Tujuannya adalah satu alur kerja produksi yang perilakunya, kualitasnya, keandalannya, keamanannya, dan biayanya dapat dijelaskan dari awal hingga akhir.
Dashboard Minimum untuk Peluncuran
Dashboard adalah tampilan operasional dari daftar periksa implementasi AI observability. Dashboard harus menampilkan hasil pelanggan terlebih dahulu dan detail infrastruktur kemudian.
Jaga agar tampilan operasional pertama cukup kecil untuk digunakan selama insiden:
- Baris hasil: awal yang memenuhi syarat, penyelesaian yang diterima, tingkat lulus kualitas, serta pengabaian atau eskalasi.
- Baris keandalan: error yang dinormalisasi, tingkat fallback, amplifikasi retry, dan burn error budget.
- Baris latensi: end-to-end p50/p95/p99, waktu antre, waktu ke token pertama, latensi retrieval, dan latensi tool.
- Baris ekonomi: token input/output/cache, total biaya alur kerja, dan biaya per hasil yang diterima.
- Baris perubahan: aplikasi, prompt, kebijakan rute, model, indeks retrieval, skema tool, dan rilis evaluator.
- Tautan investigasi: trace representatif untuk setiap kelas kegagalan, rilis, rute, dan alur kerja yang terdampak.
Dashboard harus mendukung jalur dari gejala ke trace. Jika sebuah alert menunjukkan penurunan kualitas tetapi tim tidak bisa mencapai trace alur kerja yang terdampak hanya dalam beberapa klik, loop investigasinya belum lengkap.
Kartu Skor Evaluasi Platform AI Observability
Evaluasi komersial harus menguji apakah sebuah platform mendukung model operasi Anda, bukan apakah platform tersebut memiliki daftar fitur terpanjang. Nilai kandidat terhadap workload pilot yang sama yang telah diinstrumentasi.
| Kriteria | Bobot | Yang perlu diverifikasi dalam pilot |
|---|---|---|
| Korelasi alur kerja | 20% | Satu trace menggabungkan percobaan model, retrieval, tool, validasi, dan hasil pengguna |
| Interoperabilitas OpenTelemetry | 15% | Ekspor/impor standar berfungsi; ekstensi lokal tetap dapat di-query; data portabel |
| Gabungan kualitas dan evaluasi | 15% | Umpan balik online dan evaluasi offline ter-versioning terhubung ke trace produksi |
| Privasi dan tata kelola | 15% | Allowlist field, redaksi, kontrol regional, peran akses, log audit, dan pengujian penghapusan |
| Operasi keandalan | 15% | SLO, peringatan burn-rate, kontrol sampling, anotasi rilis, dan dukungan drill insiden |
| Atribusi biaya | 10% | Penggunaan provider, retry, fallback, token cache, dan biaya per hasil yang diterima dapat direkonsiliasi |
| Cakupan Agent/RAG/tool | 5% | Operasi retrieval dan tool yang menimbulkan side effect memiliki span dan filter kelas utama |
| Biaya operasional | 5% | Ingesti, penyimpanan, kueri, retensi, dan overhead engineering sesuai dengan volume yang diharapkan |
Gunakan skor 1–5 untuk setiap kriteria, kalikan dengan bobot, dan minta bukti tertulis dari pilot. Platform yang tidak dapat mempertahankan kontrak telemetry Anda atau mengekspor data Anda menciptakan lock-in operasional meskipun dashboard-nya tampak rapi.
Kontrak Telemetry yang Dapat Disalin
Cara tercepat untuk menjadikan daftar periksa implementasi AI observability operasional adalah mengubahnya menjadi kontrak telemetry ter-versioning. Kontrak ini mendefinisikan apa yang harus diemit oleh setiap alur kerja dan percobaan model, field mana yang opsional, nilai mana yang diizinkan, dan field mana yang dilarang dari indeks volume tinggi.
Contoh di bawah menggunakan namespace internal. Petakan ke konvensi OpenTelemetry GenAI yang dipin terlebih dahulu dalam satu adapter, alih-alih mengekspos kode aplikasi pada perubahan konvensi.
telemetry_contract:
version: "2026-08-04"
workflow_span:
required:
- ai.workflow.name
- ai.workflow.version
- ai.request.id
- deployment.environment
- service.version
- ai.outcome.status
- ai.outcome.accepted
- ai.latency.total_ms
optional:
- ai.tenant.tier
- ai.experiment.id
- ai.user.feedback
prohibited:
- end_user.email
- end_user.name
- raw.authorization_header
model_attempt_span:
required:
- ai.attempt.number
- ai.route.requested_model
- ai.route.resolved_provider
- ai.route.resolved_model
- ai.result.status
- ai.usage.input_tokens
- ai.usage.output_tokens
- ai.latency.first_token_ms
- ai.latency.total_ms
conditional:
- ai.fallback.reason
- ai.error.class
- ai.error.provider_code
- ai.usage.cached_input_tokens
content_capture:
default: "off"
allowed_when:
- approved_evaluation_dataset
- explicit_debug_session
controls:
- redact_before_export
- access_logged
- retention_approved
Tinjau kontrak ini dalam code review seperti halnya sebuah skema API. Penyedia model baru, alat agen, kebijakan fallback, atau evaluator tidak boleh dirilis sampai field telemetry-nya dipetakan ke kontrak dan lulus pengujian penerimaan yang sama.
Pola Instrumentasi untuk Satu Alur Kerja AI
Jangan biarkan setiap tim menciptakan nama span dan atribut secara independen. Sediakan wrapper kecil yang membuat root span alur kerja, mencatat percobaan anak, menangkap hasil yang dinormalisasi, dan menerapkan redaksi sebelum diekspor.
Contoh Python ini sengaja dibuat netral terhadap penyedia. Nama atribut internal harus diterjemahkan ke versi konvensi semantik OpenTelemetry yang Anda pin di lapisan wrapper atau collector.
from opentelemetry import trace
tracer = trace.get_tracer("checkout-assistant")
def run_ai_workflow(request, router, evaluator):
with tracer.start_as_current_span("ai.workflow.checkout_help") as workflow_span:
workflow_span.set_attribute("ai.workflow.name", "checkout_help")
workflow_span.set_attribute("ai.workflow.version", "2026-08-04")
workflow_span.set_attribute("ai.request.id", request.request_id)
result = None
for attempt_number in range(1, 3):
with tracer.start_as_current_span("ai.model.attempt") as attempt_span:
route = router.resolve(request, attempt_number)
attempt_span.set_attribute("ai.attempt.number", attempt_number)
attempt_span.set_attribute("ai.route.requested_model", request.model)
attempt_span.set_attribute("ai.route.resolved_provider", route.provider)
attempt_span.set_attribute("ai.route.resolved_model", route.model)
result = route.generate(request)
attempt_span.set_attribute("ai.result.status", result.status)
attempt_span.set_attribute("ai.usage.input_tokens", result.input_tokens)
attempt_span.set_attribute("ai.usage.output_tokens", result.output_tokens)
if result.status == "ok":
break
attempt_span.set_attribute("ai.error.class", result.error_class)
evaluation = evaluator.score(request, result)
workflow_span.set_attribute("ai.outcome.status", result.status)
workflow_span.set_attribute("ai.outcome.accepted", evaluation.accepted)
workflow_span.set_attribute("ai.evaluator.version", evaluation.version)
workflow_span.set_attribute("ai.quality.score", evaluation.score)
return result
Kode produksi juga harus mencatat durasi, waktu hingga token pertama, alasan fallback, pembatalan, kesalahan streaming, dan pengecualian. Pilihan desain yang penting adalah hierarki: satu alur kerja pelanggan berisi satu atau beberapa percobaan yang dapat ditagihkan, dan alur kerja mencatat hasil akhir yang diterima.
Kebijakan Alert dan Runbook Respons Pertama
Sebuah daftar periksa implementasi AI observability tidak lengkap jika dasbor tidak memiliki aturan respons. Setiap metrik peluncuran memerlukan pemicu, pemilik, dan kueri diagnostik pertama.
| Alert | Contoh pemicu | Pertanyaan pertama | Tindakan segera |
|---|---|---|---|
| Konsumsi budget outcome yang diterima | Burn anggaran error cepat dan lambat | Workflow, rilis, rute, atau tenant mana yang berubah? | Jeda rollout atau kembalikan rilis yang terlibat |
| Regresi latensi | Latensi workflow p95 melampaui SLO | Apakah latensi antrian, retrieval, model, atau tool berubah? | Alihkan lalu lintas melewati tahap yang lambat atau kurangi beban |
| Lonjakan fallback | Tingkat fallback melampaui rentang normalnya | Apakah penyedia utama gagal, melakukan throttling, atau timeout? | Periksa error penyedia yang dinormalisasi dan mentah |
| Lonjakan biaya per outcome | Biaya naik sementara acceptance tetap datar atau turun | Apakah retry, panjang output, atau rute mahal meningkat? | Batasi retry dan pulihkan kebijakan rute sebelumnya |
| Penurunan skor kualitas | Tingkat lolos evaluator online atau sampel turun | Apakah prompt, retrieval, model, atau versi evaluator berubah? | Bandingkan cohort rilis dengan cohort sehat terakhir |
| Ketidakpastian tool | Hasil side-effect tidak dapat direkonsiliasi | Apakah tool selesai sebelum timeout atau pembatalan? | Hentikan retry otomatis dan masuk ke rekonsiliasi |
| Kehilangan telemetri | Kelengkapan span atau usage yang diharapkan menurun | Apakah instrumentasi rusak atau backpressure ekspor meningkat? | Perlakukan telemetri yang hilang sebagai insiden operasional |
Tampilan on-call harus terhubung langsung dari sebuah alert ke traces yang difilter berdasarkan workflow, rilis, model yang diminta, rute yang terselesaikan, dan kelas error. Jika responder harus merekonstruksi filter tersebut secara manual selama insiden, sistem belum siap diluncurkan.
Ownership dan Serah Terima Produksi
Tetapkan checklist ke peran yang disebutkan sebelum rollout. Kepemilikan bersama tanpa pengambil keputusan yang jelas biasanya menghasilkan dashboard yang dapat dilihat semua orang tetapi tidak dipelihara siapa pun.
| Tanggung jawab | Peran yang bertanggung jawab | Bukti serah terima yang diperlukan |
|---|---|---|
| Definisi outcome workflow | Pemilik produk atau fitur AI | Aturan accepted-outcome dan contoh penolakan |
| Skema span dan metrik | Pemilik platform atau observability | Kontrak telemetri berversi dan pengujian skema |
| Field rute dan fallback | Pemilik gateway atau reliability | Validasi rute yang diminta/diselesaikan dan percobaan |
| Evaluator kualitas | Pemilik engineering AI | Versi evaluator, dataset, threshold, batasan yang diketahui |
| Privasi dan retensi | Pemilik keamanan atau privasi | Klasifikasi data, pengujian redaksi, persetujuan retensi |
| SLO dan alert | Pemilik layanan | Dokumen SLO, aturan paging, dashboard, runbook |
| Alokasi biaya | Pemilik engineering finance | Kelengkapan penggunaan dan rekonsiliasi biaya per outcome |
| Kesiapan rilis | Lead engineering | Matriks penerimaan yang selesai dan pemicu rollback |
Jadwalkan tinjauan 30 hari setelah peluncuran. Hapus field yang tidak digunakan, promosikan kueri debug yang berulang kali berguna menjadi tampilan dasbor, tinjau cardinality dan biaya penyimpanan, serta perbarui kontrak ketika perilaku alur kerja berubah.
Daftar Periksa Implementasi AI Observability yang Dapat Disalin
Gunakan daftar ini sebagai gerbang peluncuran:
- [ ] Definisikan setiap alur kerja dan hasil pelanggan yang diterima.
- [ ] Definisikan kegagalan transport, kapasitas, kontrak, kualitas, keamanan, dan bisnis.
- [ ] Pilih SLI untuk ketersediaan, kualitas, latensi, dan biaya per hasil.
- [ ] Setujui kontrak telemetry berversi dengan field wajib, opsional, dan terlarang.
- [ ] Buat satu root trace untuk setiap alur kerja yang terlihat oleh pengguna.
- [ ] Propagasikan konteks melalui antrean, alat, retrieval, dan gateway.
- [ ] Catat rute provider/model yang diminta dan yang diselesaikan.
- [ ] Buat span terpisah untuk setiap percobaan retry dan fallback.
- [ ] Tangkap waktu antre, waktu hingga token pertama, dan latensi total.
- [ ] Tangkap penggunaan token yang dilaporkan provider dan biaya yang dinormalisasi.
- [ ] Versioning prompt, alat, retrieval index, kebijakan, rute, dan evaluator.
- [ ] Catat referensi retrieval, kesegaran, otorisasi, dan hasil grounding.
- [ ] Catat otorisasi alat, idempotensi, hasil, dan status side effect.
- [ ] Gabungkan umpan balik pengguna dan hasil evaluasi offline ke traces.
- [ ] Klasifikasikan telemetry sebagai metadata, sinyal turunan, atau konten mentah.
- [ ] Redaksikan rahasia dan field sensitif sebelum ekspor.
- [ ] Terapkan kebijakan retensi dan akses terpisah berdasarkan kelas data.
- [ ] Jauhkan nilai dengan cardinality tinggi dari label metrik.
- [ ] Pasang alert pada SLO yang berdampak ke pengguna dan burn error budget.
- [ ] Anotasikan rilis dan bandingkan canary versus control.
- [ ] Jalankan drill kegagalan, privasi, sampling, dan gangguan exporter.
- [ ] Simpan bukti pengujian penerimaan dan trace ID untuk gerbang rilis.
- [ ] Bandingkan platform observability dengan satu scorecard pilot berbobot.
- [ ] Tetapkan owner yang bertanggung jawab untuk hasil, skema, privasi, SLO, kualitas, dan biaya.
- [ ] Tautkan setiap alert yang layak dipaging ke runbook respons awal dan kueri trace.
Kesalahan Umum AI Observability
Mencatat prompt tanpa kebijakan data
Prompt mentah terasa berguna saat debugging, tetapi dapat berisi data pelanggan, rahasia, materi berhak cipta, atau informasi yang diatur. Mulailah dengan metadata dan aktifkan penangkapan konten yang terkontrol hanya jika memang dibenarkan.
Mengukur biaya per permintaan alih-alih biaya per hasil
Permintaan murah yang gagal validasi bukanlah murah. Retry, fallback, dan koreksi manusia termasuk dalam biaya alur kerja. Prinsip yang sama berlaku untuk ROI prompt caching: optimalkan tugas yang diterima, bukan tingkat token yang terisolasi.
Menganggap setiap panggilan model sebagai independen
Agent dan sistem RAG adalah alur kerja. Jika span model, retrieval, dan alat tidak saling dikorelasikan, tim tidak dapat merekonstruksi kausalitas.
Mengandalkan satu dasbor provider
Dasbor provider berguna untuk penggunaan dan error di hulu, tetapi tidak melihat hasil aplikasi lengkap Anda, sistem retrieval, eksekusi alat, umpan balik pengguna, atau jalur fallback lintas provider.
Menerapkan instrumentasi semuanya sebelum mendefinisikan keputusan
Telemetry memiliki biaya operasional. Setiap field harus mendukung keputusan debugging, alerting, evaluasi, tata kelola, atau optimasi. Hapus field yang tidak digunakan siapa pun.
Di Mana AI Gateway Berperan
Sebuah LLM gateway dapat menjadi batas korelasi dan kebijakan yang berguna karena banyak aplikasi dan provider melewati satu titik kontrol. Ini dapat menormalkan metadata route, attempt, usage, latency, dan error sebelum mengekspor telemetry ke observability stack Anda.
Gateway bukanlah seluruh solusi. Kode aplikasi tetap bertanggung jawab atas hasil workflow, konteks retrieval, semantik tool, umpan balik pengguna, dan konversi bisnis. Desain yang paling kuat menggabungkan telemetry gateway dengan sinyal di level aplikasi tersebut.
Flatkey menyediakan satu lapisan akses yang kompatibel dengan OpenAI untuk beberapa model AI. Jika tim Anda sedang mengonsolidasikan integrasi provider, jelajahi Flatkey dan gunakan daftar periksa ini untuk mendefinisikan kontrak telemetry di sekitar aplikasi dan lapisan routing Anda.
Pertanyaan yang Sering Diajukan
Apa yang harus saya implementasikan terlebih dahulu untuk AI observability?
Mulailah daftar periksa implementasi AI observability dengan satu root trace per workflow pelanggan, child span untuk model-attempt, field model yang diminta dan yang ter-resolve, latency, usage, error yang dinormalisasi, dan sinyal outcome yang diterima. Tambahkan penangkapan prompt mentah nanti, jika kebijakan privasi Anda mengizinkannya.
Apakah OpenTelemetry cukup untuk observability LLM?
OpenTelemetry menyediakan fondasi yang netral terhadap transport untuk traces, metrics, dan logs, plus konvensi semantik generative AI yang terus berkembang. Anda masih perlu definisi workflow, evaluasi, kontrol privasi, SLO, dashboard, dan proses insiden.
Apakah prompt dan respons harus disimpan dalam traces?
Tidak secara default. Gunakan metadata, versi, hash, dan sinyal kualitas turunan terlebih dahulu. Simpan konten mentah hanya di sistem yang terkontrol dengan tujuan yang eksplisit, kebijakan akses, periode retensi, dan proses penghapusan.
Metric observability AI mana yang paling penting?
Mulailah dengan accepted completion rate, quality pass rate, p95 end-to-end latency, time to first token untuk streaming, fallback rate, dan cost per accepted outcome. Tambahkan metric spesifik workflow setelah metrik-metrik ini dapat dipercaya.
Bagaimana cara memantau beberapa provider AI?
Gunakan satu skema telemetry yang stabil di seluruh provider. Catat baik route yang diminta maupun provider/model yang ter-resolve pada setiap attempt, normalisasikan error tanpa membuang kode provider mentah, dan gabungkan semua attempt di bawah trace workflow yang sama.
