Belajar System Analyst - Analyzing AI/LLM Systems

#Pendahuluan

Setelah di episode 21 kalian punya workflow AI sebagai alat kerja pribadi, kali ini tantangannya naik kelas: menganalisis sistem yang dibangun di atas AI sendiri. Pemilik TokoKita melihat demo chatbot dan bertanya: "kita bisa punya asisten stok yang dijawab pakai bahasa sehari-hari, nggak?" Episode ini membahas apa yang berbeda saat menganalisis fitur berbasis LLM — strategi data, evaluasi mutu, dan desain UX yang jujur terhadap ketidakpastian.

Mengapa butuh episode tersendiri? Karena semua kebiasaan analisis tradisional kita goyangkan oleh satu sifat: non-determinisme. Sistem klasik TokoKita bisa diuji biner — input X harus menghasilkan output Y, pass atau fail. Model bahasa menjawab pertanyaan yang sama dengan kalimat berbeda setiap kali, kadang benar brilian, kadang meyakinkan-yet-salah. Requirement "sistem harus akurat" tidak lagi cukup; kita harus mendefinisikan akurat untuk kasus mana, diukur bagaimana, toleransi berapa. Di sinilah analyst menjadi penerjemah antara ekspektasi bisnis ("seperti ChatGPT dong") dan realitas engineering (eval dataset, threshold, guardrails).

#Apa yang Berubah saat Sistem Berbasis LLM

Empat pergeseran fundamental yang harus masuk ke cara kalian menganalisis:

1. Perilaku probabilistik, bukan deterministik — acceptance criteria bergeser dari "output sama persis" ke "mutu rata-rata pada sampel uji mencapai ambang". Test case lama (TC-nn) masih dipakai untuk bagian deterministik (stok tetap dihitung DB), tapi bagian LLM butuh evaluasi berbasis dataset, bukan assertion per-baris.
2. Data adalah komponen sistem — pada sistem klasik, kualitas jawaban ditentukan kode. Pada LLM+retrieval, kualitas jawaban ditentukan mutu data yang dirujuk: master produk yang kotor (nama duplikat, satuan tak konsisten) menghasilkan jawaban kotor tanpa satu baris kode pun salah.
3. Kegagalan halus, bukan crash — sistem gagal bukan dengan error merah, melainkan dengan jawaban percaya-diri yang keliru (hallucination). Analisis risiko harus menanyakan: seberapa mahal jawaban salah ini bagi bisnis?
4. UX adalah kontrol keselamatan — karena output tak bisa dijamin 100%, desain antarmuka ikut menahan risiko: sitasi sumber, batasan cakupan, konfirmasi sebelum aksi.

#Analogi Dunia Nyata

Bayangkan karyawan magang yang sangat fasih berbicara: dia menjawab semua pertanyaan pelanggan dengan percaya diri, tapi kadang mengarang harga karena belum hafal buku stok. Kalian tidak menghentikan dia bicara — kalian (1) berikan dia buku stok yang rapi untuk dibaca (grounding), (2) uji pengetahuannya sebelum diterjukan ke pelanggan (evaluasi), dan (3) pasang aturan "cek buku dulu sebelum menyebut angka" (UX + guardrails). Tiga langkah itu persis struktur requirement fitur AI.

#Studi Kasus: Asisten Stok Cerdas TokoKita

Scope yang kita sepakati dengan pemilik — sengaja sempit untuk versi pertama:

Pembatasan "read-only" adalah keputusan analisis terpenting di tabel itu: nilai bisnis sudah tercapai dengan jawaban cepat, sementara aksi tulis (mengurangi stok otomatis) membuka kelas risiko baru yang layak ditunda ke versi dua.

#Strategi Data: Grounding, Bukan Menghafal

Pertanyaan arsitektur pertama yang analyst harus siap diskusikan: bagaimana model "tahu" stok TokoKita? Dua opsi besar:

• Fine-tuning (melatih ulang model dengan data toko) — cocok untuk gaya bahasa/format khusus, tidak cocok untuk fakta yang berubah tiap jam. Stok berubah setiap transaksi; melatih ulang tiap jam mustahil.
• Retrieval-augmented generation (RAG) — pertanyaan user dicocokkan ke data terkini dari database, potongan hasilnya disisipkan sebagai konteks prompt, model menyusun jawaban dari situ. Fakta selalu segar karena dibaca langsung dari sumber kebenaran.

Untuk TokoKita keputusannya jelas: RAG di atas master produk dan kartu stok. Konsekuensi requirement-nya penting dan sering terlewat: mutu retrieval menjadi requirement tersendiri — pencarian "indom" harus menemukan "Indomie Goreng", artinya master produk butuh pembersihan (sinonim, satuan konsisten). Ini pekerjaan analisis data nyata, bukan pekerjaan model.

#Evaluasi Mutu: Golden Set dan Rubrik

Sejak awal kita sepakati definisi "cukup baik". Kita susun golden set: 60-80 pertanyaan nyata (dari wawancara kepala toko) beserta jawaban referensi dan rubrik penilaian:

Q-12 : "Indomie goreng di cabang Tebos masih ada?"
Sumber kebenaran : kartu stok SKU-00123 @ Tebos = 48 pcs
Rubrik:
  - Angka stok sesuai DB          (wajib benar)
  - Menyebut cabang yang dimaksud (wajib benar)
  - Bahasa ringkas, maks 2 kalimat (preferensi)
Ambang versi 1 : >= 90% item wajib-benar lolos
                 pada seluruh golden set

Penilaian dilakukan dua lapis: LLM-as-judge untuk penyaringan massal murah, lalu manusia (kalian!) menilai sampel acak dan semua kasus gagal — judge juga bisa salah, jadi audit berkala tetap wajib. Pola ini identik dengan filosofi UAT episode 14: mutu didefinisikan sebagai kriteria yang bisa diverifikasi, bukan perasaan saat demo.

#UX yang Mengelola Ketidakpastian

Desain pengalaman adalah setengah dari manajemen risiko fitur AI. Empat keputusan UX yang kita tulis sebagai requirement:

1. Selalu tampilkan sumber — setiap angka stok disertai label kecil "dari kartu stok, diperbarui 14:32". Jawaban tanpa jejak sumber tidak boleh tampil.
2. Bahasa tingkat keyakinan yang jujur — jika retrieval menemukan dua produk mirip, asisten bertanya balik ("maksud Anda Indomie Goreng atau Kuah?") alih-alih menebak. Keraguan yang jujur lebih dipercaya daripada presisi palsu.
3. Konfirmasi sebelum aksi bernilai — saran reorder berakhir di tombol "buat draft PO" yang diklik manusia; asisten tidak pernah mengirim pesanan sendiri.
4. Jalan keluar yang jelas — tombol "lihat kartu stok manual" selalu tersedia; pengguna tidak pernah terjebak dalam percakapan yang membingungkan.

#Guardrails: Batasan yang Ditulis Sejak Desain

Guardrails adalah requirement non-fungsional khas AI, dan semuanya bisa dipetakan ke warisan seri kita:

• Batas topik — asisten menolak pertanyaan di luar stok/reorder ("siapa presiden?" dijawab: "aku hanya bisa bantu soal stok"). Cakupan sempit = permukaan kesalahan kecil.
• Privasi — pertanyaan yang diketik pemilik bisa berisi nama member; konsisten dengan privacy analysis episode 20, prompt tidak boleh diteruskan ke API model pihak ketiga tanpa anonimisasi [PELANGGAN-01], dan retensi log percakapan dibatasi 30 hari.
• Audit — setiap jawaban menyimpan rujukan data yang dipakai; bila pemilik mengambil keputusan beli berdasarkan jawaban asisten, kita bisa merekonstruksi dasar jawabannya. Lanjutan langsung dari audit log SEC-09.
• Fallback — bila layanan model tak tersedia, dashboard stok biasa tetap berfungsi penuh; fitur AI adalah tambahan, bukan titik gagal baru untuk operasional inti (prinsip graceful degradation dari integrasi episode 13).

#Praktik: Dokumen Requirement Fitur AI

Rangkuman keputusan di atas menjadi 02-requirements/ai-assistant-spec.md di repo dokumentasi:

# Spec Fitur AI: Asisten Stok Cerdas v1.0
 
## Scope
Pengguna: pemilik & kepala toko. Kanal: dashboard web.
Fungsi: Q&A stok bahasa natural + usul reorder (draft saja).
 
## Requirement Inti
AI-01  Jawaban stok WAJIB dirujuk dari kartu stok via
       retrieval; dilarang menjawab dari ingatan model.
AI-02  Retrieval WAJIB menemukan produk utk typo/sinonim
       umum (indomie/indom/mie goreng); master produk
       dibersihkan sebagai prasyarat rilis.
AI-03  Ambigu (>= 2 kandidat produk) -> asisten bertanya
       balik, dilarang menebak.
AI-04  Tidak ada operasi tulis; reorder berhenti di draft PO.
AI-05  Setiap jawaban menampilkan sumber + waktu update data.
 
## Evaluasi (gerbang rilis)
Golden set 70 item (wajib-benar >= 90%), rubrik per item,
judge LLM + audit manusia mingguan atas 20% sampel acak.
 
## Guardrails
Batas topik stok; anonimisasi nama member di prompt;
retensi log 30 hari; audit trail per jawaban;
fallback penuh ke dashboard stok manual.
 
## Di luar scope v1
Suara, multi-bahasa daerah, aksi tulis otomatis,
prediksi permintaan statistik.

Perhatikan pola nomornya: AI-nn untuk kebutuhan spesifik-AI, sementara NFR lama (kinerja, keamanan) tetap berlaku tanpa diganti — fitur AI hidup di dalam tata kelola yang sudah kalian bangun sepanjang seri ini.

#Kesalahan Umum

1. Requirement "pakai AI" tanpa masalah bisnis — chatbot karena tren menghasilkan biaya tanpa nilai. Selalu mulai dari pain nyata (pertanyaan stok menghabiskan waktu kepala toko), lalu putuskan apakah AI alat yang tepat.
2. Mengabaikan persiapan data — tim fokus memilih model padahal master produk kotor adalah bottleneck sesungguhnya. Anggaran waktu analisis: mayoritas untuk data, sisanya untuk prompt dan model.
3. Acceptance criteria yang tak terukur — "jawaban harus bagus dan ramah" tidak bisa jadi gerbang rilis. Terjemahkan ke rubrik golden set dengan ambang numerik, sekecil apa pun datanya.
4. Lupa biaya operasional — tiap pertanyaan berbiaya token dan latensi; tanpa batasan, fitur "gratis" ini muncul di tagihan bulanan. Masukkan estimasi biaya ke feasibility seperti episode 12.
5. Menjual presisi yang tidak ada — menyebut asisten "selalu benar" kepada stakeholder akan meledak di kegagalan pertama. Kelola ekspektasi sejak kickoff: "mempercepat 80% pertanyaan umum, sisanya lewat menu manual."

#Penutup

Inti yang harus dibawa pulang:

• Sistem berbasis LLM menuntut pergeseran analisis: mutu probabilistik dengan ambang terukur, data sebagai komponen utama, kegagalan halus yang dimitigasi lewat UX dan guardrails.
• Untuk fakta yang sering berubah, retrieval di atas sumber kebenaran mengalahkan fine-tuning; mutu data master menjadi prasyarat rilis, bukan catatan kaki.
• Evaluasi golden set + rubrik + judge berlapis adalah padanan UAT untuk dunia AI — demo bukan bukti, dataset adalah bukti.
• Spec Asisten Stok Cerdas mengunci scope read-only, empat keputusan UX, dan empat guardrails yang mewarisi tata kelola keamanan, privasi, serta integrasi seri ini.

Fitur kalian kini modern — tetapi ia hidup di dalam organisasi yang lebih besar darinya. Di episode 23 selanjutnya kita naik satu tingkat ke enterprise architecture awareness: bagaimana TOGAF memandang perusahaan sebagai kesatuan arsitektur bisnis-data-aplikasi-teknologi, dan bagaimana proyek-proyek kecil seperti milik kita seharusnya selaras dengan peta besar itu. Pastikan tetap semangat!