“Model AI mana yang paling bagus?”
Pertanyaan ini sering muncul ketika perusahaan mulai mengeksplorasi generative AI. Wajar, karena sekarang pilihannya semakin banyak dan hampir setiap model datang dengan klaim kemampuan yang berbeda.
Masalahnya, pertanyaan tentang model terbaik sering muncul terlalu cepat.
Sebelum membandingkan benchmark, ukuran context window, parameter, atau kemampuan reasoning, ada satu hal yang lebih penting untuk dipahami: AI tersebut sebenarnya akan digunakan untuk mengerjakan apa?
Bagi architect, pemilihan model biasanya dimulai dari workload. Sebuah model bisa terlihat sangat kuat secara umum, tetapi belum tentu menjadi pilihan yang tepat untuk kebutuhan bisnis tertentu.
Customer service assistant, document processing, coding assistant, hingga AI agent yang berinteraksi dengan berbagai sistem perusahaan sama-sama menggunakan AI, tetapi kebutuhan teknis di belakangnya bisa sangat berbeda.
Itulah sebabnya rekomendasi model seharusnya tidak dimulai dari leaderboard.
Workload membantu menentukan kemampuan apa yang benar-benar dibutuhkan dari sebuah model.
Jika AI digunakan untuk mengekstrak informasi dari dokumen, kebutuhan modelnya berbeda dari AI yang harus melakukan reasoning kompleks atau menjalankan tools melalui sebuah agent.
Begitu juga dengan ekspektasi terhadap output. Ada use case yang membutuhkan jawaban sangat akurat dan konsisten, sementara use case lain lebih mengutamakan kecepatan respons atau kemampuan menangani volume request yang besar.
Dalam tahap ini, yang perlu dipahami bukan hanya apa yang akan dilakukan AI, tetapi juga seperti apa hasil yang dianggap berhasil.
Apakah output-nya perlu mengikuti format tertentu? Seberapa besar toleransi terhadap kesalahan? Apakah respons harus diberikan secara real time? Apakah AI akan berhadapan langsung dengan pengguna atau hanya menjadi bagian dari workflow di belakang layar?
Jawaban terhadap pertanyaan-pertanyaan tersebut biasanya lebih membantu dalam mempersempit pilihan model dibanding sekadar melihat spesifikasi teknis.
Cukup besar, karena model AI di lingkungan enterprise hampir selalu bekerja dengan konteks yang berasal dari data perusahaan.
Data tersebut bisa berupa dokumen internal, knowledge base, database, ticket support, data transaksi, hingga informasi dari aplikasi lain.
Karakteristik datanya kemudian ikut menentukan kebutuhan model.
Misalnya, workload yang banyak memproses dokumen panjang akan memiliki kebutuhan yang berbeda dari workload yang hanya menerima input singkat dan terstruktur. Lingkungan multilingual juga dapat membutuhkan evaluasi tersendiri terhadap kemampuan bahasa model.
Ada pula pertanyaan tentang bagaimana model mendapatkan konteks. Apakah seluruh informasi diberikan langsung melalui prompt, atau AI perlu mengambil informasi dari sumber lain melalui retrieval?
Jika workload melibatkan data sensitif, aspek security, access control, data residency, dan governance juga ikut masuk ke dalam keputusan.
Karena itu, memilih model AI tidak bisa dipisahkan dari pertanyaan tentang data yang akan digunakan oleh aplikasi tersebut.
Tidak.
Model yang lebih besar biasanya menawarkan kemampuan yang lebih luas, tetapi kemampuan tambahan tersebut tidak selalu dibutuhkan untuk setiap workload.
Untuk task seperti extraction, classification, summarization sederhana, atau pekerjaan yang sangat terstruktur, model yang lebih kecil bisa saja sudah memberikan kualitas output yang cukup baik.
Pilihan seperti ini juga dapat memberikan keuntungan dari sisi latency dan biaya.
Sebaliknya, workload yang membutuhkan reasoning kompleks, pemahaman konteks yang panjang, atau kemampuan menjalankan instruksi yang lebih rumit mungkin membutuhkan model dengan capability yang lebih tinggi.
Pertanyaannya bukan seberapa besar model yang bisa digunakan, melainkan seberapa besar capability yang memang dibutuhkan oleh workload tersebut.
Kualitas jawaban tentu penting, tetapi di production environment ada lebih banyak hal yang ikut menentukan apakah sebuah model layak digunakan.
Latency adalah salah satunya. Untuk aplikasi yang berinteraksi langsung dengan pengguna, perbedaan waktu respons beberapa detik dapat terasa cukup signifikan. Namun untuk workload yang berjalan secara asynchronous, latency yang lebih tinggi mungkin masih bisa diterima.
Cost juga baru terasa penting ketika aplikasi mulai digunakan dalam skala yang lebih besar. Model yang terlihat ekonomis ketika diuji dengan beberapa ratus request dapat menghasilkan profil biaya yang sangat berbeda ketika jumlah request meningkat menjadi ratusan ribu atau jutaan.
Kemudian ada aspek operasional: bagaimana model diintegrasikan, dimonitor, diamankan, dan dikelola setelah masuk production.
Karena itu, evaluasi model biasanya tidak berhenti pada pertanyaan “apakah jawabannya bagus?”, tetapi juga mencakup apakah model tersebut bisa dijalankan secara efisien dan konsisten di lingkungan yang sebenarnya.
Benchmark tetap berguna, tetapi sebaiknya digunakan sebagai referensi awal, bukan sebagai keputusan akhir.
Public benchmark dapat membantu melihat kemampuan relatif sebuah model dalam area tertentu, misalnya reasoning, coding, mathematics, atau language understanding.
Namun benchmark selalu memiliki kondisi pengujiannya sendiri.
Workload perusahaan bisa memiliki data, terminologi, konteks, dan ekspektasi output yang sangat berbeda.
Model dengan skor benchmark tinggi belum tentu menjadi model dengan performa terbaik ketika digunakan untuk membaca dokumen perusahaan, memahami istilah industri tertentu, atau mengikuti workflow yang spesifik.
Sebaliknya, model yang peringkatnya lebih rendah secara umum bisa saja memberikan hasil lebih konsisten pada use case yang ruang lingkupnya lebih sempit.
Itulah mengapa benchmark lebih berguna untuk membantu membuat shortlist kandidat. Setelah itu, evaluasi perlu dilakukan menggunakan workload yang sedekat mungkin dengan kondisi nyata.
Cara yang paling relevan adalah menguji kandidat model menggunakan data dan skenario yang mewakili penggunaan sebenarnya.
Dari pengujian tersebut, tim dapat melihat bukan hanya kualitas output, tetapi juga kecepatan respons, reliability, biaya, penggunaan context, dan perilaku model pada berbagai kondisi.
Hasilnya sering kali tidak sesederhana menentukan satu model sebagai pemenang.
Sebuah model mungkin memberikan kualitas output terbaik, tetapi memiliki latency atau cost yang terlalu tinggi. Model lain mungkin sedikit lebih rendah pada satu aspek, tetapi jauh lebih efisien untuk workload dengan volume besar.
Trade-off seperti inilah yang akhirnya menentukan keputusan arsitektur.
Tidak harus.
Dalam banyak kasus, workload yang berbeda justru lebih masuk akal jika menggunakan model yang berbeda.
Task sederhana dengan volume tinggi bisa diarahkan ke model yang lebih ringan, sementara workload yang membutuhkan reasoning lebih kompleks dapat menggunakan model yang lebih capable.
Pendekatan seperti ini juga membuka kemungkinan untuk mengelola cost dan performance secara lebih fleksibel.
Karena itu, pertanyaan tentang “model AI apa yang akan digunakan perusahaan?” perlahan mulai bergeser menjadi “model apa yang paling sesuai untuk setiap workload?”
Perbedaannya terlihat kecil, tetapi dampaknya terhadap arsitektur cukup besar.
Jumlah model AI akan terus bertambah, dan posisi masing-masing model di benchmark juga akan terus berubah.
Itu membuat mengejar satu model yang dianggap “terbaik” menjadi pendekatan yang cepat kedaluwarsa.
Yang lebih berguna adalah memiliki cara evaluasi yang konsisten: mulai dari memahami workload, melihat karakteristik data, menentukan kebutuhan kualitas dan performance, kemudian mempertimbangkan cost, security, serta operasionalnya.
Setelah konteks tersebut jelas, perbandingan antar-model menjadi jauh lebih relevan.
Pada akhirnya, perusahaan tidak sedang mencari model dengan skor tertinggi.
Mereka sedang mencari model yang bisa menjalankan pekerjaan yang dibutuhkan, dengan trade-off yang bisa diterima ketika AI tersebut benar-benar masuk ke production.