Tentukan apakah akan menggunakan Claude untuk perutean tiket
Berikut adalah beberapa indikator utama bahwa Anda harus menggunakan LLM seperti Claude alih-alih pendekatan ML tradisional untuk tugas klasifikasi Anda:Anda memiliki data pelatihan berlabel yang terbatas
Anda memiliki data pelatihan berlabel yang terbatas
Kategori klasifikasi Anda kemungkinan akan berubah atau berkembang seiring waktu
Kategori klasifikasi Anda kemungkinan akan berubah atau berkembang seiring waktu
Anda perlu menangani input teks yang kompleks dan tidak terstruktur
Anda perlu menangani input teks yang kompleks dan tidak terstruktur
Aturan klasifikasi Anda didasarkan pada pemahaman semantik
Aturan klasifikasi Anda didasarkan pada pemahaman semantik
Anda memerlukan penalaran yang dapat diinterpretasi untuk keputusan klasifikasi
Anda memerlukan penalaran yang dapat diinterpretasi untuk keputusan klasifikasi
Anda ingin menangani kasus tepi dan tiket ambigu dengan lebih efektif
Anda ingin menangani kasus tepi dan tiket ambigu dengan lebih efektif
Anda memerlukan dukungan multibahasa tanpa memelihara model terpisah
Anda memerlukan dukungan multibahasa tanpa memelihara model terpisah
Bangun dan deploy alur kerja dukungan LLM Anda
Pahami pendekatan dukungan Anda saat ini
Sebelum terjun ke otomasi, penting untuk memahami sistem tiket yang ada. Mulai dengan menyelidiki bagaimana tim dukungan Anda saat ini menangani perutean tiket. Pertimbangkan pertanyaan seperti:- Kriteria apa yang digunakan untuk menentukan SLA/penawaran layanan apa yang diterapkan?
- Apakah perutean tiket digunakan untuk menentukan tingkat dukungan atau spesialis produk mana yang menerima tiket?
- Apakah ada aturan atau alur kerja otomatis yang sudah ada? Dalam kasus apa mereka gagal?
- Bagaimana kasus tepi atau tiket ambigu ditangani?
- Bagaimana tim memprioritaskan tiket?
Tentukan kategori niat pengguna
Daftar kategori niat pengguna yang terdefinisi dengan baik sangat penting untuk klasifikasi tiket dukungan yang akurat dengan Claude. Kemampuan Claude untuk merutekan tiket secara efektif dalam sistem Anda berbanding lurus dengan seberapa terdefinisi dengan baik kategori sistem Anda. Berikut adalah beberapa contoh kategori niat pengguna dan subkategori.Masalah teknis
Masalah teknis
- Masalah perangkat keras
- Bug perangkat lunak
- Masalah kompatibilitas
- Masalah kinerja
Manajemen akun
Manajemen akun
- Reset kata sandi
- Masalah akses akun
- Pertanyaan penagihan
- Perubahan langganan
Informasi produk
Informasi produk
- Pertanyaan fitur
- Pertanyaan kompatibilitas produk
- Informasi harga
- Pertanyaan ketersediaan
Panduan pengguna
Panduan pengguna
- Pertanyaan cara melakukan
- Bantuan penggunaan fitur
- Saran praktik terbaik
- Panduan pemecahan masalah
Umpan balik
Umpan balik
- Laporan bug
- Permintaan fitur
- Umpan balik atau saran umum
- Keluhan
Terkait pesanan
Terkait pesanan
- Pertanyaan status pesanan
- Informasi pengiriman
- Pengembalian dan penukaran
- Modifikasi pesanan
Permintaan layanan
Permintaan layanan
- Bantuan instalasi
- Permintaan upgrade
- Penjadwalan pemeliharaan
- Pembatalan layanan
Masalah keamanan
Masalah keamanan
- Pertanyaan privasi data
- Laporan aktivitas mencurigakan
- Bantuan fitur keamanan
Kepatuhan dan hukum
Kepatuhan dan hukum
- Pertanyaan kepatuhan regulasi
- Pertanyaan syarat layanan
- Permintaan dokumentasi hukum
Dukungan darurat
Dukungan darurat
- Kegagalan sistem kritis
- Masalah keamanan mendesak
- Masalah sensitif waktu
Pelatihan dan pendidikan
Pelatihan dan pendidikan
- Permintaan pelatihan produk
- Pertanyaan dokumentasi
- Informasi webinar atau workshop
Integrasi dan API
Integrasi dan API
- Bantuan integrasi
- Pertanyaan penggunaan API
- Pertanyaan kompatibilitas pihak ketiga
Tetapkan kriteria keberhasilan
Bekerja dengan tim dukungan Anda untuk mendefinisikan kriteria keberhasilan yang jelas dengan tolok ukur, ambang batas, dan tujuan yang dapat diukur. Berikut adalah beberapa kriteria dan tolok ukur standar saat menggunakan LLM untuk perutean tiket dukungan:Konsistensi klasifikasi
Konsistensi klasifikasi
Kecepatan adaptasi
Kecepatan adaptasi
Penanganan multibahasa
Penanganan multibahasa
Penanganan kasus tepi
Penanganan kasus tepi
Mitigasi bias
Mitigasi bias
Efisiensi prompt
Efisiensi prompt
Skor penjelasan
Skor penjelasan
Akurasi perutean
Akurasi perutean
Waktu-ke-penugasan
Waktu-ke-penugasan
Tingkat perutean ulang
Tingkat perutean ulang
Tingkat resolusi kontak pertama
Tingkat resolusi kontak pertama
Waktu penanganan rata-rata
Waktu penanganan rata-rata
Skor kepuasan pelanggan
Skor kepuasan pelanggan
Tingkat eskalasi
Tingkat eskalasi
Produktivitas agen
Produktivitas agen
Tingkat defleksi layanan mandiri
Tingkat defleksi layanan mandiri
Biaya per tiket
Biaya per tiket
Pilih model Claude yang tepat
Pilihan model tergantung pada trade-off antara biaya, akurasi, dan waktu respons. Banyak pelanggan telah menemukanclaude-3-5-haiku-20241022 sebagai model ideal untuk perutean tiket, karena ini adalah model tercepat dan paling hemat biaya dalam keluarga Claude 3 sambil tetap memberikan hasil yang sangat baik. Jika masalah klasifikasi Anda memerlukan keahlian subjek yang mendalam atau volume besar kategori niat penalaran kompleks, Anda mungkin memilih model Sonnet yang lebih besar.
Bangun prompt yang kuat
Perutean tiket adalah jenis tugas klasifikasi. Claude menganalisis konten tiket dukungan dan mengklasifikasikannya ke dalam kategori yang telah ditentukan berdasarkan jenis masalah, urgensi, keahlian yang diperlukan, atau faktor relevan lainnya. Mari kita tulis prompt klasifikasi tiket. Prompt awal kita harus berisi konten permintaan pengguna dan mengembalikan penalaran dan niat.- Kami menggunakan f-string Python untuk membuat template prompt, memungkinkan
ticket_contentsdimasukkan ke dalam tag<request>. - Kami memberikan Claude peran yang jelas sebagai sistem klasifikasi yang dengan hati-hati menganalisis konten tiket untuk menentukan niat inti dan kebutuhan pelanggan.
- Kami menginstruksikan Claude tentang format output yang tepat, dalam hal ini untuk memberikan penalaran dan analisisnya di dalam tag
<reasoning>, diikuti oleh label klasifikasi yang sesuai di dalam tag<intent>. - Kami menentukan kategori niat yang valid: “Support, Feedback, Complaint”, “Order Tracking”, dan “Refund/Exchange”.
- Kami menyertakan beberapa contoh (a.k.a. few-shot prompting) untuk mengilustrasikan bagaimana output harus diformat, yang meningkatkan akurasi dan konsistensi.
Deploy prompt Anda
Sulit untuk mengetahui seberapa baik prompt Anda bekerja tanpa men-deploy-nya dalam pengaturan produksi tes dan menjalankan evaluasi. Mari kita bangun struktur deployment. Mulai dengan mendefinisikan tanda tangan metode untuk membungkus panggilan kami ke Claude. Kami akan mengambil metode yang sudah mulai kami tulis, yang memilikiticket_contents sebagai input, dan sekarang mengembalikan tuple reasoning dan intent sebagai output. Jika Anda memiliki otomasi yang ada menggunakan ML tradisional, Anda akan ingin mengikuti tanda tangan metode tersebut sebagai gantinya.
- Mengimpor library Anthropic dan membuat instance klien menggunakan kunci API Anda.
- Mendefinisikan fungsi
classify_support_requestyang mengambil stringticket_contents. - Mengirim
ticket_contentske Claude untuk klasifikasi menggunakanclassification_prompt - Mengembalikan
reasoningdanintentmodel yang diekstrak dari respons.
stream=False (default).
Evaluasi prompt Anda
Prompting sering memerlukan pengujian dan optimisasi agar siap produksi. Untuk menentukan kesiapan solusi Anda, evaluasi kinerja berdasarkan kriteria keberhasilan dan ambang batas yang Anda tetapkan sebelumnya. Untuk menjalankan evaluasi Anda, Anda akan memerlukan kasus uji untuk menjalankannya. Sisa panduan ini mengasumsikan Anda telah mengembangkan kasus uji Anda.Bangun fungsi evaluasi
Evaluasi contoh kami untuk panduan ini mengukur kinerja Claude sepanjang tiga metrik kunci:- Akurasi
- Biaya per klasifikasi
- Kami menambahkan
actual_intentdari kasus uji kami ke dalam metodeclassify_support_requestdan menyiapkan perbandingan untuk menilai apakah klasifikasi niat Claude cocok dengan klasifikasi niat emas kami. - Kami mengekstrak statistik penggunaan untuk panggilan API untuk menghitung biaya berdasarkan token input dan output yang digunakan
Jalankan evaluasi Anda
Evaluasi yang tepat memerlukan ambang batas dan tolok ukur yang jelas untuk menentukan apa yang merupakan hasil yang baik. Skrip di atas akan memberi kami nilai runtime untuk akurasi, waktu respons, dan biaya per klasifikasi, tetapi kami masih memerlukan ambang batas yang jelas. Misalnya:- Akurasi: 95% (dari 100 tes)
- Biaya per klasifikasi: Pengurangan 50% rata-rata (di 100 tes) dari metode perutean saat ini
Tingkatkan kinerja
Dalam skenario kompleks, mungkin membantu untuk mempertimbangkan strategi tambahan untuk meningkatkan kinerja di luar teknik rekayasa prompt standar & strategi implementasi guardrail. Berikut adalah beberapa skenario umum:Gunakan hierarki taksonomi untuk kasus dengan 20+ kategori niat
Seiring jumlah kelas bertambah, jumlah contoh yang diperlukan juga berkembang, berpotensi membuat prompt menjadi tidak praktis. Sebagai alternatif, Anda dapat mempertimbangkan untuk mengimplementasikan sistem klasifikasi hierarkis menggunakan campuran classifier.- Organisasikan niat Anda dalam struktur pohon taksonomi.
- Buat serangkaian classifier di setiap level pohon, memungkinkan pendekatan perutean bertingkat.

- Pro - nuansa dan akurasi yang lebih besar: Anda dapat membuat prompt yang berbeda untuk setiap jalur induk, memungkinkan klasifikasi yang lebih bertarget dan spesifik konteks. Ini dapat mengarah pada peningkatan akurasi dan penanganan permintaan pelanggan yang lebih bernuansa.
- Kontra - peningkatan latensi: Perlu diketahui bahwa beberapa classifier dapat menyebabkan peningkatan latensi, dan kami merekomendasikan mengimplementasikan pendekatan ini dengan model tercepat kami, Haiku.
Gunakan database vektor dan pencarian kesamaan retrieval untuk menangani tiket yang sangat bervariasi
Meskipun memberikan contoh adalah cara paling efektif untuk meningkatkan kinerja, jika permintaan dukungan sangat bervariasi, bisa sulit untuk menyertakan cukup contoh dalam satu prompt. Dalam skenario ini, Anda dapat menggunakan database vektor untuk melakukan pencarian kesamaan dari dataset contoh dan mengambil contoh yang paling relevan untuk kueri tertentu. Pendekatan ini, yang diuraikan secara detail dalam resep klasifikasi kami, telah terbukti meningkatkan kinerja dari akurasi 71% menjadi 93%.Pertanggungjawabkan secara khusus untuk kasus tepi yang diharapkan
Berikut adalah beberapa skenario di mana Claude mungkin salah mengklasifikasikan tiket (mungkin ada yang lain yang unik untuk situasi Anda). Dalam skenario ini, pertimbangkan untuk memberikan instruksi eksplisit atau contoh dalam prompt tentang bagaimana Claude harus menangani kasus tepi:Pelanggan membuat permintaan implisit
Pelanggan membuat permintaan implisit
- Solusi: Berikan Claude beberapa contoh pelanggan nyata dari jenis permintaan ini, bersama dengan apa niat yang mendasarinya. Anda bisa mendapatkan hasil yang lebih baik jika Anda menyertakan alasan klasifikasi untuk niat tiket yang sangat bernuansa, sehingga Claude dapat lebih baik menggeneralisasi logika ke tiket lain.
Claude memprioritaskan emosi daripada niat
Claude memprioritaskan emosi daripada niat
- Solusi: Berikan Claude arahan tentang kapan harus memprioritaskan sentimen pelanggan atau tidak. Bisa sesederhana “Abaikan semua emosi pelanggan. Fokus hanya pada menganalisis niat permintaan pelanggan dan informasi apa yang mungkin diminta pelanggan.”
Beberapa masalah menyebabkan kebingungan prioritas masalah
Beberapa masalah menyebabkan kebingungan prioritas masalah
- Solusi: Klarifikasi prioritas niat sehingga Claude dapat lebih baik mengurutkan niat yang diekstrak dan mengidentifikasi kekhawatiran utama.
Integrasikan Claude ke dalam alur kerja dukungan yang lebih besar
Integrasi yang tepat memerlukan Anda membuat beberapa keputusan mengenai bagaimana skrip perutean tiket berbasis Claude Anda cocok dengan arsitektur sistem perutean tiket yang lebih besar. Ada dua cara Anda dapat melakukan ini:- Berbasis push: Sistem tiket dukungan yang Anda gunakan (misalnya Zendesk) memicu kode Anda dengan mengirim event webhook ke layanan perutean Anda, yang kemudian mengklasifikasikan niat dan merutekannya.
- Pendekatan ini lebih dapat diskalakan web, tetapi perlu Anda mengekspos endpoint publik.
- Berbasis pull: Kode Anda menarik tiket terbaru berdasarkan jadwal tertentu dan merutekannya pada waktu pull.
- Pendekatan ini lebih mudah diimplementasikan tetapi mungkin membuat panggilan yang tidak perlu ke sistem tiket dukungan ketika frekuensi pull terlalu tinggi atau mungkin terlalu lambat ketika frekuensi pull terlalu rendah.