Penggunaan LLM (Large Language Model) untuk gateway penalaran pada skala perusahaan: Kami berhasil mengurangi tingkat kesalahan (error rate) dari 13% menjadi 0, sekaligus menghemat biaya sebesar 28%.

Pada promosi Black Friday bulan lalu, tim teknologi e-commerce lintas negara kami di Singapura, yang terdiri dari 3 orang pengembang backend, bertahan di ruang pemantauan selama 36 jam penuh. Mereka sangat fokus pada kurva tingkat keberhasilan permintaan (request success rate). Hampir saja mereka “melompat” kegirangan melihat hasilnya! Tahun lalu, pada momen promosi yang sama, kami mengalami masalah karena pembatasan kapasitas (traffic throttling) dari satu penyedia layanan LLM (Large Language Model).13% dari permintaan pembuatan deskripsi produk mengalami kesalahan (error code 429).Pengelolaan backend toko tersebut mengalami masalah selama hampir 4 jam, dan hanya dalam waktu itu saja, sudah menerima lebih dari 2000 keluhan dari pelanggan.

Pahami dulu: Apa sebenarnya itu gateway penalaran untuk penggunaan tingkat perusahaan (enterprise-level deployment reasoning gateway)?

Bukanlah sebuah framework baru yang canggih; pada dasarnya, ini hanyalah lapisan penjadwalan lalu lintas (traffic scheduling layer) yang berada di antara layanan bisnis Anda dan berbagai antarmuka LLM (Large Language Models). Parameter utamanya sangat sederhana:Dalam kondisi beban normal, keterlambatan penjadwalan tidak boleh melebihi 10 ms.Jika melebihi batas tersebut, itu sama saja dengan menghambat kemajuan bisnis.

3 manfaat nyata yang kami peroleh setelah mengatasi berbagai masalah:

• Pertama-tama, risiko terkait pembatasan lalu lintas data (traffic throttling) telah dihilangkan: saat ini kami terhubung dengan tiga penyedia LLM (Large Language Model) utama secara bersamaan, dan gateway akan secara otomatis mengalokasikan permintaan ke node yang memiliki kuota yang cukup dan memberikan respons tercepat. Pada puncak periode Black Friday tahun ini, jumlah permintaan (QPS) meningkat sebesar 2,3 kali dibandingkan tahun lalu, dan tidak pernah terjadi kasus di mana sistem mengalami kesulitan dalam menangani permintaan secara massal (429 error).
• Selanjutnya, biaya secara nyata berkurang: Kami mengarahkan permintaan pembuatan tag produk dengan prioritas rendah secara otomatis ke model yang lebih efisien dari segi biaya, tanpa perlu mengubah kode bisnis. Dalam waktu 7 hari, pengeluaran untuk token langsung berkurang sebesar 28%.
• Yang terakhir adalah pengurangan beban kerja duplikat di sisi backend: sebelumnya, setiap kali model diganti atau penyedia layanan baru ditambahkan, kita harus mengubah antarmuka dari 3 modul bisnis secara manual. Sekarang, semua pengaturan dilakukan di lapisan gateway, dan prosesnya bisa selesai dalam waktu setengah hari.

Jangan hanya melihat keuntungannya saja; kami sudah benar-benar terjebak dalam 3 masalah besar ini.

Pada minggu pertama peluncuran, kami mengalami sebuah kecelakaan: setelah mengaktifkan fitur fallback otomatis, gateway mengalihkan sejumlah permintaan kustomisasi berprioritas tinggi yang seharusnya menggunakan GPT-4 ke model yang memiliki kualitas hasil yang jauh lebih rendah, sehingga lebih dari 200 konten iklan bisnis tidak memenuhi standar yang ditetapkan. Akibatnya, kami harus mengganti konten tersebut dengan voucher promosi senilai sekitar sepuluh ribu rupiah. Baru kemudian kami menyadari bahwa tidak semua permintaan cocok untuk di downgrade secara otomatis, dan dalam skenario yang sangat sensitif, diperlukan aturan verifikasi tambahan sebagai cadangan.

Masih ada banyak masalah terkait biaya yang belum dibahas: Jika tingkat QPS (Queries Per Second) Anda selama ini di bawah 10, biaya server dan pemeliharaan gateway itu sendiri bisa lebih mahal daripada biaya paket kualitas tinggi yang ditawarkan oleh penyedia LLM (Large Language Model). Jadi, tidak ada alasan untuk memaksakkan penggunaan gateway tersebut.

Jangan percaya pada klaim bahwa produk tersebut “siap digunakan sepenuhnya begitu dibuka kemasannya”. Kami telah mencoba 3 jenis gateway berbasis sumber terbuka, dan aturan distribusi lalu lintas bawaannya sama sekali tidak cocok untuk skenario e-commerce. Hanya dengan menyesuaikan aturan bobot saja, kami menghabiskan waktu sekitar 2 hari penuh.

Siapa yang seharusnya maju? Siapa yang sama sekali tidak perlu membuang-buang waktu?

Berikan saja kriteria penilaian tersebut, jangan ragu-ragu:

• Kriteria yang dapat dipertimbangkan adalah: jumlah permintaan LLM (Large Language Model) lebih dari 10.000 kali per hari, penggunaan lebih dari 2 model sekaligus, dan persyaratan ketersediaan layanan di atas 99,9%;
• Jika tim Anda adalah sebuah perusahaan rintisan kecil dengan kurang dari 5 orang, bisnis inti Anda tidak terlalu terikat pada penggunaan model besar (big models), dan biaya operasional LLM (Large Language Model) dalam sebulan bahkan tidak sebanding dengan gaji seorang engineer backend, maka sebaiknya jangan mencoba pendekatan penggunaan LLM untuk skala enterprise. Lebih menguntungkan jika Anda langsung menggunakan antarmuka asli dari penyedia layanan tersebut.

2 saran praktis untuk pemula yang pertama kali mencoba

Jangan langsung melakukan perubahan secara menyeluruh. Mulailah dengan mengalokasikan 10% dari lalu lintas dengan prioritas rendah selama satu minggu dalam mode “grayscale” (pengujian bertahap). Fokuslah pada dua indikator utama: apakah terjadi pengajuan permintaan yang berulang, dan apakah keterlambatan yang disebabkan oleh proses penjadwalan masih dalam batas yang dapat diterima. Kami sendiri memulai dengan menguji lalu lintas untuk sistem balasan otomatis setelah penjualan selama 3 hari, dan hanya setelah yakin tidak ada masalah, kami baru beralih ke layanan inti perusahaan.

Pertanyaan: Apakah perlu membuat gateway sendiri dari nol? Jawaban: Kecuali jika tim Anda memiliki seseorang yang benar-benar tidak punya pekerjaan dan memiliki waktu luang, lebih baik menggunakan versi open source yang sudah matang dan mengadaptasikannya saja. Ini akan menghemat setidaknya 2 bulan waktu dibandingkan dengan membuatnya sendiri, dan juga akan memberikan stabilitas yang lebih tinggi.