Menggunakan API OpenAI untuk memverifikasi alamat logistik di Eropa: Kami menghemat 32% dari biaya tenaga kerja dan juga menghindari 2 kesalahan fatal.

Pekan lalu, promosi besar Black Week baru saja berakhir, dan saat kami mengadakan pertemuan evaluasi di tim teknis, kami menemukan bahwa tingkat keberhasilan pemeriksaan alamat otomatis tahun ini meningkat sebesar 41% dibandingkan tahun lalu. Sebelumnya, kami mempekerjakan 3 orang paruh waktu khusus untuk menangani alamat yang tidak valid, tetapi tahun ini hanya perlu menyisakan 1 orang saja.

Tapi tidak ada yang ingin membicarakan masalah kesalahan kode 429 yang baru saja terjadi bulan lalu—pada tiga jam paling sibuk di hari pertama promosi besar-besaran,13% dari permintaan penyelesaian alamat dikembalikan langsung.Kantor layanan pelanggan kami hancur, dan tim operasional hampir saja datang untuk merobek meja kami.

Untuk yang belum pernah mencobanya, mari saya jelaskan secara jujur: Apa sebenarnya API OpenAI itu?

Yang dimaksud adalah Anda tidak perlu melatih model besar sendiri; Anda cukup memanggil API dari model-model yang sudah terlatih sebelumnya oleh OpenAI, seperti GPT-4o atau GPT-3.5-turbo, dan mengirimkan permintaan untuk mendapatkan hasilnya. Biayanya dihitung berdasarkan jumlah token yang Anda gunakan. Versi yang mendukung konteks hingga 128k untuk setiap permintaan kini sudah sepenuhnya tersedia.

Alasan kami memilihnya sangat sederhana: format alamat di berbagai negara Eropa sangat kacau; kode pos di Inggris berbeda sama sekali dengan format di Jerman, dan ada juga berbagai kesalahan ejaan dalam berbagai bahasa. Koleksi aturan yang kami buat sendiri diperbarui sebanyak 8 kali dalam setengah tahun, tetapi masih ada yang terlewat. Dengan menggunakan API untuk analisis semantik, selama prompt yang diberikan benar, tingkat keakuratan langsung meningkat menjadi lebih dari 96%.

Kami benar-benar mendapatkan 3 keuntungan nyata, bukan yang palsu.

• Tidak perlu memelihara tim algoritma khusus untuk mengoptimalkan model; hanya dengan 3 server backend, proses penghubungan antar antarmuka selesai dalam 1 minggu. Pada bulan pertama setelah diluncurkan, penghematan biaya tenaga kerja dari 3 pekerja paruh waktu sebesar 32% berhasil dicapai.
• Kesalahan ejaan dan alamat singkatan yang sebelumnya tidak dapat dikenali oleh basis data aturan, kini dapat diperbaiki secara otomatis dalam lebih dari 90% kasus. Akibatnya, tingkat penolakan pesanan (return rate) akibat kesalahan alamat yang dimasukkan oleh pengguna saat memesan turun sebesar 28%.
• Dukung penginputan campuran berbagai bahasa; alamat yang diisi oleh pengguna Polandia dalam bahasa Polandia atau pengguna Spanyol dalam bahasa Spanyol dapat langsung dianalisis menjadi format logistik standar tanpa perlu penyesuaian lokalisasi tambahan.

Jangan hanya melihat keuntungannya saja; kami hampir saja terjebak dalam dua masalah serius karena hal tersebut.

Pertama-tama, masalah yang muncul adalah mekanisme pembatasan lalu lintas (throttling) yang hanya menggunakan satu model secara default. Sebelumnya, kami hanya menggunakan GPT-4o-mini, dan pembatasan lalu lintas yang berlaku per menit cukup untuk keperluan sehari-hari. Namun, pada hari promosi besar, jumlah permintaan meningkat tiga kali lipat, sehingga langsung memicu mekanisme pembatasan tersebut. Sebanyak 13% dari permintaan mengalami kesalahan kode (429 error). Untuk mengatasi masalah ini, kami menambahkan logika penurunan kualitas layanan (downgrading), yaitu dengan mengalihkan permintaan yang tidak terjadi pada jam puncak ke GPT-3.5-turbo, dan akhirnya situasi dapat dikendalikan kembali.

Kesalahan kedua adalah penilaian yang salah terhadap alamat yang sensitif. Pernah ada pengguna yang memasukkan alamat yang mengandung kata-kata terkait “basis militer”, dan alamat tersebut langsung ditangkap oleh sistem pengawasan konten API. Karena kami tidak memiliki mekanisme cadangan untuk mengatasi kegagalan, pesanan tersebut tertunda selama 2 hari sebelum dikirim, sehingga pengguna memberikan ulasan negatif.

Siapa yang seharusnya menggunakannya? Jangan buang-buang uang sia-sia.

Jika Anda, seperti kami, bergerak di bidang pemrosesan semantik berbahasa ganda dan menghadapi situasi di mana aturan yang perlu ditulis sangat banyak, seperti validasi alamat, respons otomatis untuk pertanyaan pengguna, atau generasi konten berbahasa ganda, dan tim Anda tidak memiliki tim khusus untuk pengembangan algoritma, maka menggunakan API OpenAI jauh lebih menguntungkan daripada melatih model sendiri.

Namun, jika Anda bergerak di bidang bisnis yang memerlukan pengolahan data inti yang tidak boleh keluar dari lingkup tertentu, seperti pemrosesan data keuangan kritis, analisis data privasi medis, atau skenario sederhana dengan jumlah permintaan yang stabil dan aturan yang jelas, maka tidak perlu ikut-ikutan dengan tren ini. Menulis aturan sendiri atau mengimplementasikan model kecil secara lokal akan lebih menghemat biaya dan lebih aman.

3 saran untuk pemula, semuanya berdasarkan pengalaman kami saat mengalami kesulitan.

• Jangan hanya menggunakan satu model saja; siapkan setidaknya dua model dengan tingkat kualitas yang berbeda untuk keperluan downgrade. Gunakan model dengan tingkat akurasi tinggi untuk permintaan yang penting, dan model yang lebih murah untuk permintaan yang kurang penting atau saat masa puncak penggunaan. Dengan cara ini, Anda dapat menghemat setidaknya 40% biaya, sekaligus menghindari masalah terkait pembatasan jumlah permintaan (traffic throttling) yang disebabkan oleh satu model saja.
• Semua permintaan harus dilengkapi dengan mekanisme percobaan ulang (retry) dan logika cadangan (fallback). Untuk situasi seperti penahanan konten, pembatasan lalu lintas (throttling), dan waktu tunggu yang melebihi batas (timeout), rencana penanganan harus sudah disiapkan terlebih dahulu. Jangan menunggu hingga antarmuka (interface) tidak berfungsi lagi baru memikirkan cara untuk menanganinya secara manual.
• Jangan langsung menggunakan model dengan tingkat kecanggihan tertinggi dari awal; coba model GPT-3.5-turbo yang paling murah untuk melihat hasilnya terlebih dahulu. Jika hasilnya tidak memuaskan, barulah beralih ke model yang lebih canggih. Untuk sebagian besar skenario sederhana, model yang lebih kecil sudah cukup memadai.

Pada akhirnya, mari kita bahas dua pertanyaan yang sering diajukan oleh banyak orang.

Pertanyaan: Apakah akan ada keterlambatan yang signifikan saat melakukan panggilan di wilayah Eropa?
Jawaban: Kami menggunakan node Frankfurt, dan sebagian besar permintaan diselesaikan dalam waktu 15 detik. Hanya sekitar beberapa persen dari permintaan yang tiba-tiba membutuhkan waktu lebih dari 200 detik untuk diselesaikan. Dengan menambahkan mekanisme caching, masalah tersebut dapat diatasi tanpa mempengaruhi kinerja bisnis sama sekali.

Pertanyaan: Apakah ada kemungkinan hasil analisis atau pemrosesan menjadi tidak akurat?
Ya, sekarang kami mengalihkan hasil dengan tingkat kepercayaan di bawah 80% ke peninjauan manual. Setelah menambahkan aturan ini, tingkat kesalahan hampir dapat diabaikan.