Salah satu keputusan teknis yang paling sering diremehkan saat membangun AI agent: model LLM mana yang dipakai. Banyak yang berhenti di pertanyaan “pakai model paling pintar yang ada” — padahal untuk sebagian besar tugas operasional bisnis, itu justru pilihan yang boros dan kadang lebih lambat tanpa manfaat akurasi yang benar-benar terasa.
Tiga sumbu trade-off yang sebenarnya perlu dipertimbangkan
Bukan cuma “pintar vs murah”. Ada tiga sumbu yang saling tarik-menarik. Pertama, akurasi dan kemampuan reasoning model. Kedua, latency, yaitu seberapa cepat agent bisa merespons. Ketiga, biaya per pemanggilan, yang dihitung dari jumlah token yang diproses tiap kali model dipanggil. Model yang lebih besar cenderung lebih akurat untuk tugas yang butuh reasoning berlapis, tapi juga lebih lambat dan lebih mahal per panggilan. Untuk agent yang dipanggil ratusan hingga ribuan kali sehari, misalnya menjawab chat WA pelanggan, selisih biaya per panggilan yang terlihat kecil bisa menumpuk jadi signifikan dalam sebulan.
Tidak semua langkah dalam satu agent butuh model yang sama
Ini yang sering terlewat: sebuah agent biasanya melakukan beberapa jenis “keputusan” dalam satu alur kerja, dan tidak semuanya sama kompleksnya. Mengklasifikasikan jenis pertanyaan masuk (FAQ vs butuh eskalasi) adalah tugas relatif sederhana yang bisa ditangani model kecil/cepat dengan akurasi cukup baik. Menyusun jawaban naratif yang butuh menggabungkan beberapa sumber data dan konteks percakapan panjang adalah tugas yang lebih pantas memakai model yang lebih mumpuni. Arsitektur yang matang memisahkan ini — pakai model murah/cepat untuk tugas rutin bervolume tinggi, model lebih besar untuk tugas yang benar-benar butuh reasoning dalam, alih-alih memakai satu model untuk semua langkah secara seragam.
Kenapa “model terbaru” tidak otomatis berarti “model yang tepat”
Model baru yang dirilis biasanya lebih baik secara umum, tapi itu tidak berarti otomatis jadi pilihan tepat untuk use case spesifik Anda — kadang model yang lebih lama tapi sudah teruji stabil di alur kerja yang ada punya risiko lebih rendah daripada buru-buru migrasi ke model terbaru yang perilakunya belum dipahami sepenuhnya untuk kasus penggunaan Anda. Pergantian model idealnya diuji dulu di lingkungan terbatas sebelum dipakai penuh di produksi — bukan langsung ganti semua begitu ada rilis baru.
Pertanyaan praktis sebelum memilih
Sebelum menentukan model, tanyakan: seberapa sering tugas ini dipanggil (volume), seberapa fatal kalau jawabannya sedikit meleset (toleransi kesalahan), dan seberapa penting kecepatan respons untuk pengalaman pengguna. Jawaban atas tiga pertanyaan ini biasanya lebih menentukan pilihan model yang tepat dibanding sekadar melihat leaderboard benchmark umum.