Dasar-dasar AI
Cara Membuat Chatbot: Arsitektur, Data, Keamanan, dan Evaluasi
Tambahkan Unite.AI ke sumber pilihan Anda di Google
Chatbot adalah aplikasi yang menerima pesan, menentukan apa yang dibutuhkan pengguna, dan mengembalikan respons melalui teks atau suara. Sistem modern dapat menggabungkan aturan, pencarian, pengklasifikasi, transformer, alat, dan model bahasa besar alih-alih bergantung pada satu model.
Membangun chatbot yang berguna oleh karena itu merupakan masalah produk dan sistem. Lapisan dialog harus terhubung ke pengetahuan yang dapat dipercaya dan tindakan bisnis, sementara identitas, izin, pencatatan, evaluasi, fallback, dan eskalasi manusia membatasi apa yang boleh dilakukan bot.
Key takeaways
- Mulailah dengan tugas pengguna yang sempit dan kriteria keberhasilan yang dapat diukur.
- Pisahkan generasi bahasa dari pencarian, alat, izin, dan aturan bisnis.
- Uji percakapan lengkap, termasuk ambiguitas, interupsi, penolakan, dan pemulihan.
- Anggap prompt dan output model sebagai data yang tidak dapat dipercaya; pantau produksi dan pertahankan jalur eskalasi.
Define the job before choosing a model
Tuliskan siapa pengguna, apa yang ingin mereka capai, data apa yang dapat diakses sistem, dan tindakan mana yang memerlukan konfirmasi. Bot FAQ, asisten status pesanan, dan agen manajemen akun memiliki profil risiko yang sangat berbeda.
Buat baseline non-AI dan satu set percakapan representatif untuk penerimaan. Ukur penyelesaian tugas, dukungan jawaban, latensi, abandon, eskalasi, dan biaya kesalahan berbahaya. Demo yang lancar bukan bukti bahwa alur kerja berfungsi secara andal.
Use a layered architecture
Pipeline tipikal mencakup adaptor saluran, status sesi, validasi input, logika intent atau routing, pencarian, model respons atau kebijakan, adaptor alat, dan observabilitas. Pencarian dapat menancapkan jawaban pada dokumen yang disetujui; alat melakukan tindakan terkontrol melalui skema eksplisit.
Jaga pemeriksaan deterministik di luar model bahasa. Otentikasi, otorisasi, batas inventaris, pengembalian dana, dan tindakan tidak dapat dibatalkan harus ditegakkan oleh kode aplikasi. Prompt engineering dapat membentuk perilaku, tetapi bukan sistem kontrol akses.
Design dialogue, knowledge, and recovery together
Percakapan yang baik menangani permintaan tidak lengkap, koreksi, banyak intent, dan referensi ke putaran sebelumnya. Simpan hanya konteks yang diperlukan untuk tugas, buat retensi terlihat, dan bedakan pernyataan pengguna dari fakta tepercaya yang dikembalikan oleh sistem yang disetujui.
Ketika kepercayaan atau bukti tidak cukup, bot harus mengajukan pertanyaan terfokus, menawarkan alternatif aman, atau mentransfer ke manusia dengan ringkasan singkat. Pemulihan adalah bagian inti pengalaman—bukan kasus tepi yang ditambahkan setelah peluncuran.
Evaluate and operate the complete system
Uji kualitas pencarian, pemilihan alat, akurasi argumen, kepatuhan kebijakan, ketahanan terhadap prompt injection, kebocoran privasi, dan hasil end-to-end. Lakukan red‑team pada input adversarial dan verifikasi bahwa dokumen berbahaya tidak dapat diam-diam menggantikan instruksi sistem.
Versi prompt, indeks, model, kebijakan, dan alat. Tinjau percakapan sampel dengan kontrol privasi, amati drift dan klaster kegagalan, serta pertahankan rollback. Disiplin operasional ini menghubungkan pengembangan chatbot dengan AIOps dan respons insiden.
Core chatbot components in more detail
Lapisan saluran menormalkan input dari obrolan web, aplikasi seluler, platform pesan, atau suara. Lapisan sesi mengaitkan pesan dengan percakapan yang terautentikasi atau anonim, menegakkan kedaluwarsa, dan menyimpan hanya status yang diperlukan untuk tugas. Kontrol input membatasi ukuran dan tipe berkas, mendeteksi muatan tidak aman, serta menghapus markup yang tidak boleh dijalankan oleh sistem hilir.
Router kemudian memutuskan apakah permintaan termasuk dalam alur deterministik, pencarian, generasi, atau antrean manusia. Klasik pengklasifikasi intent tetap berguna ketika set label stabil; model bahasa lebih fleksibel namun lebih sulit dikalibrasi. Router hibrida dapat menyisihkan tugas teratur atau bervolume tinggi untuk alur kerja teruji dan menggunakan model umum untuk penjelasan terbuka.
Lapisan respons harus membawa bukti dan status secara terpisah. Kalimat yang dihasilkan dapat mengutip bagian yang diambil, tetapi aplikasi harus mempertahankan sumber dan versi yang mendukungnya. Memori percakapan harus membedakan preferensi pengguna dari data akun terverifikasi, dan tidak boleh mengizinkan pesan pengguna sebelumnya memberikan izin baru.
Retrieval, tools, and transactions
Kualitas pencarian dimulai sebelum pencarian vektor. Dokumen memerlukan kepemilikan, label akses, versi kanonik, potongan yang berguna, dan tanggal penghapusan. Penulisan ulang kueri, pencarian kata kunci, embedding, filter, dan reranking dapat digabungkan. Evaluasi harus mengukur apakah bukti yang diperlukan berhasil diambil, apakah bagian yang tidak relevan dikecualikan, dan apakah jawaban benar‑benar mengikuti bukti.
Alat mengubah saran model menjadi permintaan bertipe ke kode aplikasi. Setiap alat memerlukan tujuan sempit, skema eksplisit, validasi sisi server, kredensial hak paling sedikit, batas waktu, idempotensi bila memungkinkan, dan hasil yang jelas. Model tidak boleh menyusun kueri basis data mentah atau URL acak ketika operasi bisnis terbatas dapat diekspos sebagai gantinya.
Transaksi memerlukan konfirmasi pada titik komitmen. Tampilkan kepada pengguna bidang material—penerima, jumlah, alamat, tanggal, atau perubahan akses—dan jangan perlakukan “ya” lama sebagai persetujuan untuk tindakan baru. Untuk pekerjaan ber‑langkah, pertahankan mesin status di luar model sehingga percobaan ulang atau pesan yang diurutkan ulang tidak dapat melewati gerbang yang diperlukan.
A practical build and evaluation plan
Mulailah dengan dua puluh hingga lima puluh tugas representatif dan sertakan permintaan yang gagal, ambigu, dan di luar ruang lingkup. Tandai tindakan yang diharapkan, bukti, eskalasi, dan perilaku yang dilarang. Implementasikan alur kerja paling sederhana yang dapat berfungsi, lalu tambahkan pencarian atau generasi hanya bila meningkatkan hasil terukur. Ini menghasilkan rangka regresi yang dapat dipakai kembali sebelum antarmuka menjadi rumit.
Evaluasi komponen dan percakapan secara terpisah. Metrik pencarian, akurasi pemanggilan alat, pemeriksaan kebijakan, dan dukungan respons mendiagnosa kegagalan spesifik; penyelesaian tugas dan usaha pengguna mengungkap kualitas tingkat sistem. Gunakan tes multi‑turn yang memperbaiki detail sebelumnya, menginterupsi alur, mengganti topik, menahan informasi yang diperlukan, dan memicu kegagalan ketergantungan.
Peluncuran produksi harus bertahap berdasarkan grup pengguna, tugas, dan izin. Pantau klaim yang tidak didukung, klarifikasi berulang, penolakan alat, eskalasi, latensi, dan abandon. Tinjau sampel yang aman secara privasi, pertahankan jalur penonaktifan darurat untuk setiap alat, dan gunakan temuan insiden untuk memperbarui prompt, data, kode, serta set tes secara bersamaan.
Worked example: a support chatbot from prototype to production
Misalkan sebuah retailer menginginkan chatbot yang menjawab pertanyaan tentang pesanan dan pengembalian. Tentukan intent yang didukung, kondisi eskalasi, pengetahuan yang disetujui, aturan otentikasi, dan tindakan yang dilarang terlebih dahulu. Bangun set tes dari pertanyaan historis yang di‑de‑identifikasi, termasuk permintaan samar, ejaan salah, input multibahasa, pengguna marah, prompt injection, dan pertanyaan tanpa jawaban. Baseline pencarian harus mengembalikan bukti sebelum respons generatif diizinkan mengklaim kebijakan atau status pesanan.
Runtime dapat mengklasifikasi intent, mengambil bagian kebijakan, meminta verifikasi identitas hanya ketika data akun diperlukan, memanggil API pesanan yang sangat terbatas, menyusun jawaban, dan melampirkan sitasi. Setiap pemanggilan alat memerlukan skema eksplisit, pemeriksaan otorisasi, batas waktu, kebijakan retry, dan kunci idempotensi. Model tidak boleh menyusun kueri basis data mentah atau menentukan izin sendiri. Tindakan berdampak tinggi seperti pembatalan atau pengembalian dana memerlukan konfirmasi dan, di atas batas yang ditetapkan, persetujuan manusia.
Evaluasi akurasi intent, kebenaran jawaban, dukungan bukti, kualitas penolakan, keberhasilan penahanan, presisi eskalasi, latensi, dan biaya per percakapan yang diselesaikan. Tinjau hasil per intent dan grup pengguna, bukan rata‑rata tunggal. Di produksi, catat jejak yang sadar persetujuan, hasil alat, versi dokumen yang diambil, dan koreksi pengguna. Luncurkan secara bertahap, bandingkan dengan saluran yang ada, dan nonaktifkan kemampuan ketika ambang kesalahan, penyalahgunaan, atau ketergantungan terlampaui.
Practical implementation checklist
Ubah konsep menjadi alur kerja yang terbatas dan dapat diuji: definisikan tugas → rute → ambil → hasilkan → gunakan alat → evaluasi. Tunjuk pemilik yang bertanggung jawab, dokumentasikan data dan ketergantungan, buat baseline sederhana, tetapkan kriteria penerimaan dan penghentian, uji kegagalan representatif, serta definisikan pemantauan, rollback, dan tinjauan sebelum memperluas ruang lingkup. Catat versi dan asumsi sehingga tim lain dapat mereproduksi hasil dan memahami apa yang berubah.
Sebelum peluncuran, jalankan tinjauan kesiapan terdokumentasi dengan orang‑orang yang membangun, mengoperasikan, mengamankan, dan terpengaruh oleh sistem. Uji kasus normal, kondisi batas, kegagalan ketergantungan, dan penyalahgunaan; pertahankan bukti serta risiko yang belum terselesaikan. Tentukan siapa yang dapat menyetujui rilis, mengubah ambang, menimpa output, atau menghentikan operasi. Tinjau kembali keputusan setelah data dunia nyata muncul, karena pilot yang secara teknis berhasil tidak menjamin kinerja andal pada skala yang lebih luas.
- KNOWLEDGE: sumber dan sitasi yang disetujui.
- ACTIONS: alat bertipe dengan hak paling sedikit.
- RECOVERY: klarifikasi, tolak, atau eskalasi.
Frequently asked questions
Does a chatbot need a large language model?
Tidak. Aturan, pencarian, formulir, dan pengklasifikasi kecil dapat lebih aman dan lebih murah untuk tugas yang sempit. LLM berguna ketika pemahaman atau generasi bahasa yang fleksibel menghasilkan nilai terukur.
What should be tested before launch?
Tugas representatif, permintaan yang tidak didukung, bahasa ambigu, kegagalan alat, batas privasi, prompt adversarial, penyerahan ke manusia, latensi, dan akurasi setiap tindakan konsekuensial.
Primary references
