Fase 6 · Use Case: Chatbot

Guardrails & UX chatbot production

Studi kasus penutup fase ini: menyatukan seluruh guardrails dari fase-fase sebelumnya jadi checklist konkret untuk chatbot yang benar-benar siap dihadapkan ke pengguna nyata.

Sumber asli docs.claude.com Resmi Rangkuman ~7 menit baca

Intisari

Chatbot production butuh batas topik eksplisit di system prompt — tanpa itu, model bisa 'membantu' menjawab hal di luar cakupan yang justru berisiko (nasihat hukum, medis, keputusan finansial).
Fallback yang jelas untuk tiga situasi: pertanyaan di luar topik, model tidak yakin jawabannya, dan permintaan yang butuh otorisasi/tindakan sensitif — semuanya harus punya respons yang aman, bukan model 'mencoba membantu' apa pun caranya.
Eskalasi ke manusia: deteksi sinyal (kata kunci frustrasi, pertanyaan berulang tanpa terselesaikan, permintaan eksplisit 'bicara dengan orang') dan sediakan jalur keluar yang jelas — bukan memaksa pengguna terus berhadapan dengan bot.
Rate limiting per pengguna (bukan cuma rate limit provider dari Fase 2) mencegah satu pengguna menghabiskan anggaran biaya seluruh sistem, sengaja maupun tidak.
Checklist sebelum go-live menyatukan semua fase sebelumnya: guardrails (Fase 2), batas agent (Fase 3), evaluasi (Fase 5), observability (Fase 7) — chatbot bukan proyek yang 'selesai' setelah demo pertama berhasil.

Batas topik yang eksplisit

Tanpa batasan yang jelas, model yang dilatih untuk "membantu" cenderung mencoba menjawab apa pun yang ditanyakan — termasuk topik yang seharusnya di luar cakupan chatbot-mu, dan berpotensi menimbulkan risiko hukum/reputasi.

system_prompt = """Kamu adalah asisten customer service toko online kami.
Kamu HANYA menjawab pertanyaan seputar: status pesanan, kebijakan pengembalian, dan katalog produk.

Untuk pertanyaan di luar topik ini (nasihat hukum, medis, finansial, atau topik tidak
berhubungan), jawab: "Maaf, saya hanya bisa membantu seputar pesanan dan produk toko kami.
Untuk pertanyaan lain, silakan hubungi [kontak yang sesuai]."

Jangan pernah membuat janji yang tidak ada di kebijakan resmi (refund di luar 30 hari, diskon
khusus, dsb.) meskipun pengguna memaksa atau membuat alasan yang meyakinkan."""

Tiga situasi yang butuh fallback jelas

Situasi	Fallback yang aman
Pertanyaan di luar topik	Tolak sopan + arahkan ke kanal yang tepat (lihat system prompt di atas)
Model tidak yakin / RAG tidak menemukan konteks relevan (Fase 5)	"Saya tidak menemukan informasi pasti soal ini" — bukan menebak dengan percaya diri
Permintaan butuh otorisasi/tindakan sensitif (refund, ubah data akun)	Verifikasi eksplisit di luar model, atau eskalasi ke manusia — jangan biarkan model "memutuskan" sendiri

Deteksi kapan harus eskalasi ke manusia

def perlu_eskalasi(riwayat: list, pesan_baru: str) -> bool:
    sinyal_eksplisit = any(kata in pesan_baru.lower() for kata in
                           ["bicara dengan orang", "customer service manusia", "komplain"])

    # deteksi percakapan berputar tanpa progres: 3+ pesan user berturut tanpa penyelesaian jelas
    pesan_user_terakhir = [m for m in riwayat[-6:] if m["role"] == "user"]
    berulang_tanpa_progres = len(pesan_user_terakhir) >= 3

    return sinyal_eksplisit or berulang_tanpa_progres

Eskalasi bukan tanda kegagalan — ia bagian dari desain yang baik. Chatbot yang memaksa pengguna frustrasi terus berhadapan dengan bot yang tidak membantu jauh lebih buruk untuk pengalaman pengguna daripada chatbot yang mengaku "ini di luar kemampuan saya" dan memberi jalan keluar cepat ke manusia.

Rate limit per pengguna, bukan cuma per API key

Rate limit dari provider (Fase 2) melindungi seluruh aplikasimu, tapi tidak mencegah satu pengguna individual mengirim ratusan pesan dalam semenit dan menghabiskan jatah/biaya yang seharusnya dibagi semua pengguna.

def cek_rate_limit_pengguna(pengguna_id: int, maks_per_menit: int = 10) -> bool:
    jumlah = redis_client.incr(f"chat_rate:{pengguna_id}")
    if jumlah == 1:
        redis_client.expire(f"chat_rate:{pengguna_id}", 60)
    return jumlah <= maks_per_menit

Checklist sebelum go-live

Area	Sudah dari fase	Pertanyaan verifikasi
Guardrails prompt injection & PII	Fase 2	Sudah diuji dengan input yang mencoba "menyerang" prompt?
Batas langkah/biaya kalau pakai agent	Fase 3	Ada batas maksimum langkah & token per percakapan?
Kualitas retrieval & faithfulness	Fase 5	Ada dataset evaluasi tetap yang dijalankan sebelum tiap perubahan besar?
Fallback & eskalasi	Materi ini	Tiga situasi fallback di atas sudah ditangani eksplisit?
Observability & biaya	Fase 7	Bisa melihat berapa biaya per percakapan, dan melacak percakapan yang gagal?

Latihan: ambil chatbot RAG dari materi sebelumnya, tambahkan system prompt dengan batas topik eksplisit, fungsi perlu_eskalasi, dan rate limit sederhana (boleh pakai dictionary in-memory untuk latihan). Uji dengan mengirim pertanyaan di luar topik, lalu 4 pesan berturut yang berulang tanpa progres — pastikan keduanya memicu jalur fallback/eskalasi yang tepat.

Rangkuman ini sengaja dipangkas ke bagian yang dipakai di roadmap. Buka sumber aslinya saat kamu butuh detail lengkap atau referensi parameter.