Insights — August 24, 2026

Sebelum AI Menggerakkan Uang: Gerbang Evaluasi yang Saya Bangun untuk AutoKon

Evaluasi LLMVLMAI di ProduksiFintech

Kebanyakan fitur AI gagal dengan diam-diam. Ringkasannya meleset sedikit, labelnya salah, sarannya diabaikan. Tidak ada yang membuat tiket dan produk tetap jalan.

AutoKon bukan produk seperti itu. Ia pipeline verifikasi finansial untuk pengembang properti di Indonesia: pekerja lapangan memotret satu unit rumah, model visi-bahasa membaca foto itu, dan hasil bacaan itu ikut menentukan cairnya pembayaran kontraktor. Deskripsi yang salah bukan menurunkan pengalaman pengguna. Ia memindahkan uang ke tempat yang keliru.

Satu sifat itu mengubah cara saya membangun sisanya.

Pipeline-nya tidak berhenti di model

Arsitektur yang paling gampang dibayangkan: foto masuk, VLM keluar, keputusan diambil. Claude Opus Vision memang sangat bagus mendeskripsikan lokasi konstruksi. Ia akan bilang dindingnya sudah diplester, kuda-kuda atapnya sudah naik, lantainya sudah discreed. Sesekali ia akan mengatakan semua itu, dengan keyakinan yang sama persis, untuk foto yang isinya lain. Jarang, tapi cukup sering untuk jadi masalah.

Karena itu setiap deskripsi hasil AI melewati tahap evaluasi LLM-as-judge sebelum mendekati keputusan pencairan. Model kedua menilai model pertama terhadap gambar dan klaimnya, dan item hanya lanjut kalau lolos ambang.

Judge ini bukan dasbor kualitas yang ditempel setelah rilis. Ia duduk di jalur pembayaran. Kalau tahap evaluasi mati, pencairan menunggu. Itu mode kegagalan yang benar untuk domain ini, dan memutuskannya sejak awal yang membuat sisa desainnya bisa dikerjakan.

Yang sebenarnya diukur judge

Kebanyakan pekerjaan evaluasi yang saya lihat mengoptimalkan apakah jawabannya bagus. Untuk gerbang pembayaran, itu pertanyaan yang salah.

Pertanyaannya adalah apakah deskripsi itu grounded: apakah setiap klaim di dalamnya didukung oleh apa yang ada di foto. Sebuah deskripsi bisa rapi, masuk akal, berguna, dan tetap mengklaim tahap pekerjaan yang tidak terlihat di frame. Persis kegagalan itu yang tidak boleh sampai ke mesin pencairan.

Maka judge-nya diberi prompt yang sempit. Apakah tiap klaim di sini didukung gambar ini? Ia tidak pernah ditanya apakah deskripsinya enak dibaca. Klaim tak berdasar menggugurkan item meski tulisannya bagus, dan hampir seluruh nilainya ada di penyempitan itu. Rubrik kualitas yang terlalu luas menghasilkan judge yang terlalu sering sepakat dengan generator, karena keduanya berbagi bias optimis yang sama.

Angka yang membuat judge layak dipakai

Judge otomatis baru layak dipakai kalau ia sepakat dengan reviewer manusia, dan Anda harus bisa menyebut seberapa besar kesepakatannya.

Pipeline-nya menargetkan Cohen’s κ ≥ 0,80 terhadap label manusia, yang tergolong kesepakatan substansial di skala mana pun. Itu ambang operasional, bukan angka untuk slide. Di bawahnya, judge jadi sumber rasa aman palsu alih-alih kontrol, dan respons yang jujur adalah memperluas review manusia sampai rubrik atau labelnya membaik.

Tiga hal yang saya pelajari sampai ke sana. Waktu pelabelan manusia itu langka, jadi habiskan di titik ketika generator dan judge berselisih, bukan di kasus yang sejak awal sudah jelas. Rubrik ambigu muncul sebagai κ rendah jauh sebelum muncul sebagai kerugian; ketika kesepakatan turun, penyebabnya hampir selalu rubrik yang membuat dua reviewer yang sama-sama masuk akal menilai foto yang sama secara berbeda, bukan model yang memburuk. Dan distribusi input terus bergeser. Tipe proyek baru, kamera ponsel baru, dan musim hujan sama-sama mengubah apa yang dilihat kamera, jadi suite evaluasi yang dibekukan sejak rilis akan lapuk.

Di mana manusianya duduk

Gerbang evaluasi tidak menggantikan persetujuan. AutoKon menjalankan alur persetujuan bukti foto dengan lima peran, dan submission lapangan masuk lewat WhatsApp melalui alur n8n dan Botpress, bukan lewat portal yang mengharuskan tiap pekerja lapangan punya akun dan ikut pelatihan.

AI tidak menyetujui apa pun. Ia mengeluarkan bukti yang jelas lengkap dan jelas berdasar dari antrean reviewer, lalu menandai apa yang butuh manusia. Reviewer menerima kasus ambigu lengkap dengan konteksnya, dan di situlah penilaian manusia sepadan dengan biayanya. Itu yang membuat satu engineer bisa menjalankan platform untuk ribuan unit rumah di tiga zona waktu tanpa beban review yang tumbuh seiring jumlah unit.

Yang bisa dibawa ke tempat lain

Tidak semua produk menggerakkan uang, tapi pertanyaannya tetap berlaku. Apa hal terburuk yang bisa dilakukan jawaban salah yang percaya diri di sini, dan desain Anda berangkat dari situ atau dari kemampuan modelnya? Metrik Anda mengukur kebenaran terhadap sumber, atau sekadar kemasukakalan? Bisakah Anda menyebut angka kesepakatan dengan manusia? Orang yang masih ada di lingkaran itu kebagian kasus sulit atau kasus gampang?

Modelnya tidak pernah jadi bagian tersulit di proyek ini. Yang sulit adalah struktur di sekelilingnya, dan kesediaan membiarkan struktur itu menghentikan jalur mulus ketika memang harus.