Awalnya tampak brilian. Dalam satu akhir pekan, seorang pengembang berhasil menulis framework evaluasi large language model (LLM) hanya dengan sekitar 200 baris kode Python. Demonstrasinya berjalan mulus dan memicu rasa percaya diri yang tinggi. Namun, enam bulan berselang, kode tersebut berubah menjadi tumpukan kekacauan yang sulit dirawat.
Tiga model penilai berbeda terpaksa dipadukan dengan tiga cara parsing manual yang rapuh. Kumpulan data uji tak lagi disentuh sejak November. Gerbang integrasi berkelanjutan (CI) kerap gagal bukan karena ada kesalahan pada prompt, melainkan karena vendor mengubah sedikit perilaku modelnya. Insinyur kedua yang masuk ke proyek pun bertanya sederhana namun menusuk: "Bagaimana sistem ini sebenarnya bekerja?"
Kegagalan ini bukan pada kerangka dasarnya, melainkan pada 80 persen pekerjaan yang dilewati saat tutorial akhir pekan tersebut. Celah inilah yang menjadi pelajaran berharga bagi banyak tim teknologi. Sang pengembang akhirnya merumuskan satu kalimat sakti: bangunlah rubrik penilaian, namun belilah mesin eksekusinya.
Pemisahan peran ini butuh waktu enam bulan untuk dipahami. Beberapa bagian dari sistem evaluasi memang eksklusif milik perusahaan. Rubrik yang menentukan standar "baik" bagi produk, kumpulan data dari kegagalan nyata, serta aturan kapan sebuah perubahan layak memblokir rilis, tidak bisa dikerjakan pihak lain. Sementara itu, komponen seperti pemanggilan model penilai, penguraian jawaban, percobaan ulang, dan penyingkatan memori bersifat generik di semua perusahaan.
Sebelum menulis kode, ia kini selalu menanyakan dua hal. Apakah komponen ini spesifik atau generik? Rubrik domain sangat spesifik dan layak dimiliki. Sebaliknya, logika percobaan ulang dan penyingkatan bersifat generik. Pertanyaan kedua: apakah komponen ini akan mengalami akumulasi nilai atau justru membusuk? Kumpulan data yang tumbuh dari kegagalan produksi akan menguat seiring waktu, sementara lapisan pelacakan buatan tangan akan usang begitu vendor mengubah sistemnya.
Bagi ekosistem teknologi di Indonesia, pengalaman ini sangat relevan. Geliat startup AI di Jakarta, Bandung, dan Yogyakarta semakin masif seiring meluasnya adopsi LLM untuk layanan bahasa lokal. Sayangnya, budaya "membangun segalanya dari nol" demi efisiensi jangka pendek atau kebanggaan teknis masih kerap terjadi. Akibatnya, banyak insinyur lokal terjebak merawat infrastruktur generik yang sebenarnya bisa diakuisisi dengan biaya lebih murah.
Ketergantungan pada alat bernama dolar juga memperburuk situasi. Membangun mesin penilai sendiri berarti menanggung risiko fluktuasi biaya komputasi dan API model kelas atas. Padahal, sumber daya manusia teknologi di Tanah Air masih terbatas. Menghabiskan satu hingga satu setengal insinyur penuh waktu hanya untuk merawat parser yang rapuh adalah pemborosan yang tak terlihat di awal.
Lebih dari itu, kualitas produk AI lokal berisiko stagnan jika tim terlalu sibuk dengan pipa teknis. Fokus seharusnya dialihkan pada rubrik yang merekam kegagalan spesifik bahasa Indonesia, seperti nuansa sopan santun atau konteks budaya yang kerap luput dari model global. Itu adalah keunggulan kompetitif yang tak bisa dibeli dari vendor luar negeri.
Ada empat elemen yang layak dibangun sendiri menurut sang pengembang. Rubrik harus disimpan di repositori Git agar perubahan terekam jelas, bukan di database. Kumpulan data sebaiknya diambil dari seratus kasus nyata produksi ketimbang dua ratus kasus rekayasa. Aturan penghalang rilis serta label humanisasi juga murni milik tim terkait. "Bangunlah bagian yang spesifik dan menguat, gunakan kembali sisanya," tegasnya mengenai filosofi pengembangan ini.
Salah satu kesalahan mahal yang ia temui adalah menyandarkan gerbang evaluasi pada skor rata-rata. Dengan hanya 30 kasus uji, rata-rata mudah bergetar secara acak sehingga gerbang gagal menangkap regresi nyata. Solusinya adalah memadukan batas bawah keras dengan perbandingan terhadap garis dasar produksi terbaru. Tak kalah penting, pemeriksaan yang sama wajib dijalankan di CI dan produksi langsung agar kecocokan data tetap terjaga.
Ke depan, tren evaluasi LLM diprediksi bergeser dari pembangunan mandiri menuju layanan khusus (eval-as-a-service). Tim teknologi di Indonesia perlu menyadari bahwa versi akhir pekan hanyalah ilusi; menjaga sistem evaluasi tetap hidup mendekati beban satu hingga satu setengah tenaga kerja penuh. Mengadopsi runner generik akan membebaskan kapasitas insinyur untuk berinovasi pada produk inti.
Langkah berikutnya bagi perusahaan yang sudah terlanjur membangun sendiri adalah melakukan audit komponen. Pisahkan mesin generik dari logika domain secepatnya. Dengan demikian, ketika vendor model memperbarui format keluaran, tim tidak perlu panik merombak kode dari nol, melainkan cukup memperbarui konfigurasi pada layanan yang sudah dibeli.