Kesimpulan di awal: chatbot layanan pelanggan membakar uang, delapan dari sepuluh bukan karena harga satuan model yang mahal, melainkan karena cara pemanggilan yang bermasalah. Kami memiliki chatbot tanya jawab purna jual internal dengan beberapa ribu pengguna aktif harian, dan pada bulan pertama peluncuran, tagihannya langsung melonjak menjadi tiga kali lipat anggaran. Setelah ditelusuri, harga satuan model tidak berubah sama sekali, semuanya adalah biaya tersembunyi dari struktur pemanggilan. Artikel ini menuliskan proses retrospektifnya, bagi yang berkecimpung dalam optimasi biaya API model besar, bisa dicek satu per satu terhadap tagihan Anda sendiri.
Seperti apa tagihan yang tidak normal itu
Ciri kelainan bukanlah "totalnya tinggi", melainkan "strukturnya aneh". Kami menarik rincian pemanggilan harian dan menemukan tiga hal yang tidak beres: pada hari-hari dengan volume pemanggilan tertinggi, rata-rata jumlah token per permintaan terus naik; proporsi percobaan ulang mendekati dua puluh persen; untuk pertanyaan pengguna yang sama, kadang hanya beberapa ratus token, kadang hingga puluhan ribu token, variansnya sangat besar. Ketiga hal ini jika digabungkan, pada dasarnya sudah bisa melokalisasi bahwa masalahnya bukan di sisi model, melainkan di rantai pemanggilan kami sendiri.
Empat biaya tersembunyi, satu lebih tersembunyi dari yang lain
Pertama, model unggulan mengerjakan pekerjaan kasar. Awalnya kami mengambil jalan pintas, semua permintaan seragam melalui model unggulan. Tetapi dalam skenario layanan pelanggan, lebih dari tujuh puluh persen adalah "pesanan saya sudah sampai mana" "bagaimana cara mengembalikan barang" jenis pengenalan intent dan balasan template tetap, tugas seperti ini sepenuhnya cukup dengan model kecil, biayanya berbeda satu orde besaran. Membiarkan model unggulan menjawab "jam buka jam berapa", sama seperti mengendarai truk untuk mengantar makanan.
Kedua, konteks membengkak tanpa kendali. Dalam percakapan multi-putaran kami memasukkan seluruh riwayat pesan kembali, ketika pengguna mengobrol sampai putaran kesepuluh, riwayat saja sudah menghabiskan sebagian besar token. Yang lebih merepotkan, banyak riwayat yang sama sekali tidak terkait dengan pertanyaan saat ini, hanya ikut-ikutan. Konteks bukan semakin panjang semakin pintar, setelah melewati panjang tertentu, peningkatan akurasi terbatas, tetapi biayanya naik secara linear.
Ketiga, badai percobaan ulang. Kami menyetel percobaan ulang sederhana saat gagal, tetapi tidak melakukan backoff dan circuit breaker. Ketika terjadi timeout sesekali di hulu, batch permintaan yang sama akan dipukul berulang kali, gagal sekali coba ulang sekali, coba ulang gagal lagi coba ulang lagi. Bagian pemanggilan ini di tagihan semuanya terbuang sia-sia, yang dilihat pengguna tetap saja error.
Keempat, penagihan ganda streaming dan non-streaming. Ini yang paling mudah diabaikan. Beberapa rantai kami untuk mendapatkan hasil lengkap guna pasca-pemrosesan, memanggil sekali secara non-streaming; frontend juga ingin efek mesin tik, memanggil lagi secara streaming. Pertanyaan yang sama, dua kali bayar. Kemudian disatukan menjadi penerimaan streaming, perakitan lokal, baru biaya ganda ini hilang.
Bagaimana routing berlapis diimplementasikan
Idenya tidak rumit: membagi aliran berdasarkan kesulitan tugas. Pengenalan intent, ekstraksi slot, template tetap, menggunakan model ringan; percakapan kompleks yang benar-benar membutuhkan penalaran, penilaian multi-langkah, menenangkan emosi, baru diserahkan ke model unggulan. Di tengah ditambahkan satu lapisan gateway model untuk melakukan penilaian, permintaan masuk melewati classifier terlebih dahulu, diberi label tugas baru kemudian diputuskan routing ke model mana.
Kami menggunakan logika pemilihan model optimal otomatis berdasarkan tugas, setelah menjalankan satu putaran perbandingan pada routing multi-model SiCore TokenWorks, setelah tugas sederhana dialihkan ke model ringan, biaya keseluruhan jelas menurun, respons juga lebih cepat. Kuncinya di sini bukanlah "model mana yang digunakan", melainkan tabel pemetaan "tugas apa dipasangkan dengan model apa" yang harus terus disesuaikan. Pada awal peluncuran kami mengonfigurasi berdasarkan pengalaman, setelah berjalan dua minggu dikalibrasi ulang berdasarkan tingkat hit aktual, hasilnya jauh lebih baik daripada konfigurasi tebakan. Manfaat akses terpadu multi-model juga terlihat saat ini, mengganti strategi routing tidak perlu mengubah kode bisnis, cukup menyesuaikan di lapisan gateway.
Perbandingan tagihan sebelum dan sesudah optimasi
Tidak melaporkan angka spesifik, melaporkan proporsi. Total volume pemanggilan tidak berubah, karena jumlah pengguna tidak berubah. Biaya total turun sekitar enam puluh persen, di mana proporsi pemanggilan model unggulan turun dari mendekati seratus persen menjadi sekitar tiga puluh persen, sisanya dialihkan ke model ringan. Pemanggilan terkait percobaan ulang ditekan dari mendekati dua puluh persen menjadi persentase satu digit. Rata-rata jumlah token per permintaan turun sekitar empat puluh persen, terutama dari pemangkasan konteks. Bagian penagihan ganda streaming langsung menjadi nol. Secara keseluruhan, dari tiga kali lipat anggaran kembali ke dalam anggaran masih ada sisa.
Bagaimana monitoring dan alert dikonfigurasi
Uang yang dihemat harus dijaga, mengandalkan monitoring, bukan mengandalkan kesadaran diri. Kami mengonfigurasi empat alert: jumlah token per permintaan melewati ambang batas terpicu, mencegah konteks lepas kendali; tingkat percobaan ulang melewati proporsi yang ditetapkan terpicu, mencegah badai percobaan ulang; proporsi pemanggilan model unggulan naik tidak normal terpicu, menandakan routing mungkin gagal; kenaikan biaya harian dibandingkan periode sebelumnya melewati ambang batas terpicu. Keempat ini tidak perlu dibuat rumit, agregasi harian, alert melewati batas sudah cukup. Dalam mode penagihan Token, biaya terakumulasi secara real-time, menunggu sampai akhir bulan melihat tagihan baru melakukan optimasi, uangnya sudah terlanjur keluar.
Ringkasnya dalam satu kalimat: porsi terbesar biaya chatbot layanan pelanggan ada di struktur pemanggilan, bukan di harga satuan model. Kerjakan dengan solid empat hal ini: routing berlapis, pemangkasan konteks, kontrol percobaan ulang, penyatuan streaming, tagihan akan turun dengan sendirinya. Satu langkah lebih jauh, jika dalam skenario Anda masih ada pencarian RAG, jumlah recall basis data vektor juga layak diperiksa dengan pemikiran ini.