Mengapa Benchmark AI Melewatkan 90% Pekerjaan Nyata

Seorang teman saya memimpin operasi di perusahaan logistik menengah, dan musim semi lalu timnya menghabiskan tiga minggu untuk mengevaluasi apakah LLM bisa mengambil alih alur kerja penanganan pengecualian mereka, yaitu pekerjaan membosankan untuk mencocokkan faktur yang tidak sesuai dengan purchase order di tiga sistem yang saling membenci. Deck vendor penuh angka mengesankan: MMLU, GSM8K, HumanEval, dan beberapa benchmark agentic. Model itu lolos setiap tes yang mereka berikan. Lalu mereka menyerahkannya pada seminggu penuh pengecualian nyata, dan model itu dengan percaya diri mencocokkan faktur $14.000 ke PO yang salah, karena seorang vendor menyingkat namanya secara berbeda. Tidak ada leaderboard yang mengukur hal semacam itu.

Kesenjangan itu sekarang bisa diukur. Sebuah pemetaan terbaru antara benchmark AI publik dan taksonomi O*NET dari US Department of Labor, mencakup 923 jabatan dan 18.797 tugas yang membentuk pekerjaan di Amerika, menemukan bahwa 90% jam kerja di AS dihabiskan untuk tugas dengan cakupan benchmark yang sedikit atau tidak ada. Hanya 208 dari 923 jabatan yang memiliki setidaknya satu tugas yang didukung lima prompt benchmark atau lebih. Enam dari 22 keluarga pekerjaan sama sekali tidak punya. Kesimpulan yang tidak nyaman bukan bahwa AI lemah. Melainkan instrumen kita untuk mengukur kemampuan AI hampir seluruhnya diarahkan ke bagian ekonomi yang keliru.

Apa yang Sebenarnya Dicakup Benchmark AI

Metodologi di balik pemetaan ini layak dipahami karena lebih cermat daripada yang tersirat dari judulnya. Peneliti mengambil 29 benchmark agentic berkualitas tinggi yang belum jenuh, yaitu tes di mana model benar-benar harus mengerjakan pekerjaan dan bukan sekadar menjawab pertanyaan, lalu memakai LLM judge (divalidasi terhadap pakar manusia) untuk memberi tag setiap prompt benchmark dengan tugas O*NET yang dilatihnya. Sebuah tugas dianggap "tercakup" jika setidaknya lima prompt memetakan ke tugas tersebut. Digabungkan dengan estimasi berapa banyak waktu kerja yang dikonsumsi setiap tugas, kita mendapatkan gambaran seluruh ekonomi tentang apa yang bisa dilihat rangkaian evaluasi kita.

Apa yang bisa dilihat itu sempit dan tinggi, bukan lebar. Rekayasa perangkat lunak dan analisis keuangan sudah jenuh dengan benchmark. Pengemudi truk, operasi pabrik gas, layanan makanan, dan sebagian besar pekerjaan harian di bidang kesehatan nyaris tidak terlihat. Dan kecondongan ini bukan hanya soal tugas mana yang secara teknis bisa diotomatisasi. Tugas yang ditandai "terpapar AI" sekitar enam kali lebih mungkin di-benchmark dibanding yang tidak terpapar, dan itu wajar, tetapi bahkan setelah dikontrol, tugas dari jabatan dengan total gaji besar tetap terlalu banyak terwakili. Tugas pengacara sangat tercakup. Sekretaris hukum dan panitera pengadilan, yang menghadapi paparan AI serupa, hampir tidak muncul.

Baca lagi: kita membenchmark AI terhadap versi bergengsi dari sebuah pekerjaan sambil mengabaikan versi yang sebenarnya dijalani kebanyakan orang. Ekor panjang pekerjaan pengetahuan berpenghasilan menengah, yaitu koordinator, staf administrasi, spesialis, dan penjadwal yang jamnya menjumlahkan porsi besar ekonomi, hampir tak punya infrastruktur pengukuran sama sekali. Ketika seseorang mengklaim AI bisa mengerjakan sekian persen "pekerjaan pengetahuan", tanyakan pekerjaan pengetahuan yang mana, diukur bagaimana, dan terhadap daftar tugas apa. Jawaban jujurnya biasanya: irisan tipis yang tidak representatif, diukur dengan tes yang dirancang untuk makalah riset.

Saturasi Benchmark Adalah Kegagalan Desain Evaluasi

Saya bertahun-tahun membangun pipeline evaluasi, dan pelajaran tersulitnya adalah ini: benchmark adalah model dari dunia, dan kebanyakan benchmark adalah model yang buruk. Mereka memampatkan tugas manusia yang berantakan, kontekstual, dan multi-langkah menjadi prompt bersih dengan jawaban yang bisa diperiksa, karena itu yang murah untuk dinilai. Lalu hukum Goodhart melakukan sisanya. Begitu sebuah benchmark menjadi target pengembangan model, ia berhenti mengukur kapabilitas yang seharusnya diwakilinya. Data pelatihan menyerap distribusi tes, tim menyetel terhadap leaderboard, dan skor naik sementara performa di dunia nyata malah melenceng.

Saturasi adalah gejala yang terlihat. Ketika setiap model frontier mencetak di atas 90% pada sebuah tes, tes itu sudah tidak lagi membedakan. Tetapi masalah yang lebih dalam adalah kita meresponsnya dengan membangun benchmark lain dengan gaya yang sama, mencakup jenis tugas yang sama, karena itulah tugas yang kita tahu cara menilai secara otomatis. QA pilihan ganda melahirkan QA pilihan ganda yang lebih sulit. Tantangan coding melahirkan tantangan coding yang lebih sulit. Sementara itu, tidak ada yang membangun benchmark untuk "perhatikan bahwa klausul ganti rugi kontrak ini diam-diam bertentangan dengan term sheet bulan Maret", karena menilainya membutuhkan pengacara, waktu, dan keputusan penilaian yang menolak otomatisasi.

Inilah mengapa saya tidak setuju dengan pembingkaian bahwa saturasi benchmark berarti AI sudah "menuntaskan" suatu domain. Saturasi berarti instrumennya sudah mentok, titik. Termometer yang menunjuk 40°C tidak membuktikan ruangannya 40 derajat; ia hanya membuktikan Anda butuh termometer lain. Jika Anda mengevaluasi model untuk penggunaan produksi, terutama jika Anda membangun sistem keputusan berbasis LLM di mana kesalahan punya biaya nyata, selisih leaderboard pada benchmark jenuh seharusnya hampir tidak punya bobot dalam keputusan Anda.

Kita tahu persis seberapa bagus model dalam pekerjaan yang sudah kita putuskan untuk diukur. Kita hampir tidak tahu apa-apa tentang sembilan puluh persen lainnya.

Efek Lampu Jalan dalam Evaluasi AI

Ada lelucon lama tentang orang mabuk yang mencari kuncinya di bawah lampu jalan, bukan karena ia menjatuhkannya di sana, tetapi karena di situlah cahayanya. Konstruksi benchmark mengikuti logika yang sama, dan datanya membuktikan ini bukan kebetulan. Studi pemetaan menemukan bahwa kepentingan tugas dalam sebuah jabatan memprediksi cakupan: tugas O*NET yang dinilai paling penting bagi jabatannya memiliki peluang enam sampai sepuluh kali lebih besar untuk di-benchmark dibanding yang paling tidak penting. Sekilas, ini tampak seperti prioritas yang masuk akal. Dalam praktiknya, artinya kita mengukur tugas pajangan dan melewatkan jaringan penghubungnya.

Setiap pekerjaan sebagian besar adalah jaringan penghubung. Tugas yang di-benchmark dari seorang insinyur perangkat lunak adalah "implementasikan fungsi yang lolos tes ini". Hari kerjanya yang sebenarnya mencakup membaca migrasi setengah jadi milik rekan, mencari tahu stakeholder mana yang sebenarnya memiliki keputusan, dan menyadari bahwa tiket itu menjelaskan masalah yang salah. Saya pernah menulis tentang bagaimana alat coding agentic berhasil atau gagal justru karena hal ini: loop, konteks, dan batas izin lebih penting daripada kualitas generasi mentah. Tidak ada yang seperti itu muncul dalam skor gaya HumanEval.

Ada juga masalah definisi yang halus dalam angka cakupan itu sendiri. "Tercakup" berarti lima prompt atau lebih memetakan ke sebuah tugas, bukan berarti lima prompt itu menangkap tugas tersebut. Tiga belas prompt tentang membimbing orang tua soal masalah pengasuhan anak tidak mewakili apa yang sebenarnya dilakukan pekerja sosial di seluruh kasus, ruang sidang, dan kunjungan ke rumah. Jika Anda menerapkan definisi "tercakup dengan baik" versi orang awam, porsi ekonomi yang terukur tidak akan 10%. Angkanya akan dibulatkan menjadi nol. Lampu jalannya bukan hanya sempit; cahaya yang dipancarkannya juga tipis.

Model Menghasilkan, tetapi Tidak Ada yang Mengukur Penilaian

Inilah asimetri yang menurut saya paling memberatkan. Hampir setiap benchmark yang ada menguji produksi: tulis kodenya, susun memonya, selesaikan masalahnya. Tetapi separuh yang paling kritis secara ekonomi dari kebanyakan tugas nyata adalah deteksi, yaitu menangkap kesalahan, menandai inkonsistensi, dan mengetahui kapan jawaban yang percaya diri itu salah. Nilai seorang akuntan junior bukan pada menghasilkan rekonsiliasi, melainkan pada menyadari bahwa sebuah angka terasa janggal. Benchmark hampir tidak pernah menguji itu, karena membangun tugas deteksi kesalahan yang bisa dinilai jauh lebih sulit daripada membangun tugas generasi yang bisa dinilai. Anda membutuhkan artefak cacat yang realistis, kekeliruan yang masuk akal namun halus, dan kesepakatan manusia tentang apa yang dihitung sebagai tertangkap.

Ini adalah doorman fallacy yang diterapkan pada desain evaluasi. Ganti penjaga pintu dengan pintu otomatis dan Anda akan menemukan, terlambat, bahwa penjaga itu juga menyapa penghuni, menerima paket, dan mengawasi jalan. Otomatisasi bagian pekerjaan yang di-benchmark dan Anda menemukan bahwa bagian yang tidak di-benchmark ternyata menopang beban. Model teman logistik saya bisa menyusun catatan rekonsiliasi yang bagus, yaitu tugas yang terlihat, sambil diam-diam mengacaukan pencocokan, penilaian yang membuat catatan itu layak ditulis. Rangkaian eval menilai hiasannya dan mengabaikan hidangannya.

Sampai deteksi kesalahan mendapat perlakuan benchmark kelas satu, bersiaplah menghadapi kesenjangan terus-menerus antara performa demo dan performa di produksi. Ini kesenjangan yang sama dengan yang ada antara apa yang dikatakan spesifikasi dan apa yang dilakukan implementasi, dan seperti dalam perangkat lunak, di kesenjangan itulah kegagalan berkembang biak. Model yang menghasilkan di persentil ke-90 tetapi memverifikasi di persentil ke-30 adalah, dalam produksi, karyawan persentil ke-30 dengan keunggulan kecepatan mengetik.

Menimbang Eval Berdasarkan Distribusi Tugas Nyata

Ide paling praktis dalam pekerjaan pemetaan benchmark ini juga yang paling sederhana: jika benchmark terlalu banyak mewakili beberapa tugas, berhentilah merata-ratakan prompt dan mulailah merata-ratakan tugas, dibobot berdasarkan berapa banyak waktu kerja yang benar-benar dikonsumsi setiap tugas. Rata-rata biasa dari setiap prompt yang diberi tag "analis keuangan" didominasi oleh tugas yang kebetulan punya prompt benchmark paling banyak, biasanya yang paling mudah dibuatkan dataset-nya. Rata-rata berbobot O*NET memberi setiap tugas nyata pijakan yang setara. Selisihnya bisa sangat dramatis.

import pandas as pd
# The tasks an occupation actually performs, with time shares
# (from O*NET, your own ticket logs, or time-tracking data)
tasks = pd.DataFrame({
"task": ["draft contract", "advise client", "review filing", "coordinate closing"],
"time_share": [0.30, 0.25, 0.35, 0.10],
})
# Model results: one row per eval prompt, mapped to the task it exercises
results = pd.DataFrame({
"prompt_id": ["p1", "p2", "p3", "p4", "p5"],
"task": ["draft contract", "draft contract", "draft contract",
"review filing", "coordinate closing"],
"score": [0.92, 0.88, 0.95, 0.61, 0.40],
})
# Naive: flat average over prompts. Drafting has 3 of 5 prompts,
# so the score is dominated by the model's best task.
naive = results["score"].mean()  # 0.752
# Task-weighted: average within each task first, then weight by
# the share of working hours that task consumes.
per_task = results.groupby("task")["score"].mean()
weights = tasks.set_index("task")["time_share"]
weighted = (per_task * weights).sum() / weights[per_task.index].sum()
# 0.30*0.917 + 0.35*0.61 + 0.10*0.40, over covered time (0.75) = 0.705
# vs naive 0.752 — and 'advise client' (25% of the job) has no data at all

Ada dua hal yang perlu diperhatikan dalam cuplikan itu. Pertama, skor berbobot turun karena tugas terlemah model kurang terwakili dalam kumpulan prompt, persis distorsi yang disembunyikan oleh rata-rata datar. Kedua, dan yang lebih penting: "memberi nasihat kepada klien" lenyap sepenuhnya dari perhitungan karena tidak ada prompt yang memetakan ke sana. Skema pembobotan apa pun diam-diam membuang tugas dengan cakupan nol, dan cakupan nol adalah kondisi normal untuk sebagian besar ekonomi. Pembobotan memperbaiki masalah pembobotan. Ia tidak bisa memperbaiki masalah data yang hilang. Itu butuh membangun eval baru, bukan menghitung ulang rata-rata dari yang lama.

Cara Mengevaluasi AI terhadap Pekerjaan yang Benar-benar Anda Lakukan

Jika Anda memilih atau menerapkan model, kesenjangan cakupan di seluruh ekonomi punya implikasi konkret: benchmark publik adalah prior yang lemah untuk kasus penggunaan Anda, kecuali Anda kebetulan berada di sudut kecil yang terang itu. Jadi bangunlah sudut Anda sendiri. Ini kurang heroik daripada kedengarannya, dan jauh lebih baik daripada mempercayai deck vendor.

• Ambil sampel tugas dari log, bukan imajinasi. Tarik seminggu tiket, email, atau pengecualian nyata dan ambil sampel berdasarkan frekuensi. Set eval Anda harus menyerupai histogram beban kerja Anda, termasuk ekor yang membosankan. Ekor yang membosankan itulah sebagian besar pekerjaannya.
• Bobotkan berdasarkan waktu atau biaya, lalu laporkan kedua angkanya. Rata-rata datar dan rata-rata berbobot mengapit kebenaran. Jika sebuah model menang di rata-rata datar tetapi kalah di rata-rata berbobot, berarti ia bagus di tugas yang mudah diuji, dan itulah justru mode kegagalan yang sedang Anda saring.
• Sertakan tugas verifikasi. Ambil output nyata, termasuk yang sudah diketahui buruk, dan nilai model berdasarkan kemampuannya menangkap kesalahan yang ditanam maupun yang alami. Dalam pengalaman saya, kemampuan deteksi dan kemampuan generasi hampir tidak berkorelasi, dan deteksilah yang sebenarnya Anda beli.
• Simpan set privat dan segarkan secara berkala. Eval apa pun yang dipakai ulang selama berbulan-bulan menjadi target pelatihan, bahkan tanpa disengaja, begitu seseorang mulai menyetel prompt terhadapnya. Rotasi kasus setiap kuartal.
• Nilai hasil end-to-end jika memungkinkan. Jika tugasnya "rekonsiliasi faktur ini", nilai hasil rekonsiliasinya, bukan prosa perantaranya. Metrik antara justru menyanjung model seperti unit test menyanjung kode yang tidak punya cakupan integrasi.

Ada satu efek yang lebih senyap dan layak disebut, yang akan dikenali siapa pun yang setiap hari memakai alat coding AI: penyakit biaya Baumol skala mikro. Ketika generasi menjadi dua puluh kali lebih cepat, Anda tidak menghabiskan hari untuk menghasilkan. Anda menghabiskannya untuk bagian yang tidak ikut cepat, yaitu meninjau, berkoordinasi, memverifikasi, dan memutuskan. Sisa yang tidak di-benchmark tidak menyusut seiring membaiknya AI; ia tumbuh mengisi waktu yang dibebaskan, dan menjadi porsi yang lebih besar dari apa yang menentukan apakah AI itu layak diterapkan. Mengukur irisan yang bisa diotomatisasi dengan presisi yang makin tinggi sambil mengabaikan sisanya bukan sekadar tidak lengkap. Itu membalik apa yang sebenarnya penting.

Tidak satu pun dari ini berarti kemajuan AI itu palsu. Kemajuan kapabilitasnya nyata, dan saya sudah mempertaruhkan proyek pada hal itu. Ini argumen bahwa budaya pengukuran kita diarahkan ke distribusi yang keliru. Benchmark dibangun di tempat prompt murah untuk ditulis dan dinilai: kode, matematika, pengetahuan gaya ujian. Ekonomi sebagian besar bukan seperti itu. Sampai evaluasi mengejar, perlakukan setiap klaim kapabilitas yang heboh sebagai pernyataan tentang sepersepuluh peta yang terang, dan bangunlah eval yang mencakup sembilan puluh persen gelap milik Anda sendiri. Organisasi yang melakukan pekerjaan pengukuran yang membosankan dan tidak glamor ini akan membuat keputusan penerapan yang lebih baik daripada semua orang yang terus menyegarkan leaderboard, dan selisihnya tidak akan tipis.