90% of US working hours are spent on tasks not covered well by AI benchmarks

Ilusi Leaderboard: Mengapa 90% Jam Kerja Nyata Belum Tersentuh Benchmark AI Modern

Industri kecerdasan buatan saat ini sedang terjangkit bias konfirmasi yang akut. Setiap rilis model fondasi baru selalu dibarengi klaim saturasi benchmark: MMLU mendekati 90 persen, HumanEval nyaris tuntas, dan skor SWE-bench terus merangkak naik. Namun, jika metrik-metrik ini merefleksikan utilitas dunia nyata, mengapa adopsi AI di lini produksi perusahaan masih tertahan di fase eksperimen, otomatisasi parsial, atau sekadar wrapper chatbot?

Data riset terbaru dari Mercor Labor Index menjawab anomali tersebut: sekitar 90 persen jam kerja riil di Amerika Serikat dihabiskan untuk tugas-tugas yang sama sekali tidak dipetakan oleh benchmark AI populer saat ini.

Kesenjangan ini bukan sekadar masalah metodologi statistik. Bagi para software engineer, arsitek sistem, dan pimpinan teknis, temuan ini mengungkap realitas fundamental: metrik evaluasi yang dipakai industri saat ini mengukur variabel yang salah untuk implementasi produksi.

---

Anatomi Kegagalan: Karakteristik Beban Kerja Produksi vs. Benchmark

Benchmark konvensional dirancang agar mudah dievaluasi secara otomatis (autogradable), deterministik, dan terisolasi. GSM8k menguji aritmatika multi-langkah; HumanEval menguji sintaks fungsi Python tunggal dari docstring; SWE-bench menguji resolusi issue GitHub dalam repositori tertutup.

Sebaliknya, 90 persen jam kerja manusia yang terdata dalam basis data O*NET (Occupational Information Network) memiliki karakteristik yang menolak pendekatan evaluasi statis tersebut:

1. Long-Horizon Planning dan Degradasi State

Sebagian besar pekerjaan profesional bukan tugas diskret 30 detik, melainkan rangkaian aksi interdependen yang berjalan selama jam, hari, atau minggu.

Dalam arsitektur agentic workflow, probabilitas kegagalan majemuk berlaku:

P(success) = p^n

Jika sebuah model memiliki tingkat keandalan sub-task sebesar p = 0.95, dalam rantai kerja dengan n = 50 langkah (sebuah workflow standar untuk audit logistik atau rekonsiliasi data perbankan), reliabilitas akhir sistem anjlok ke:

0.95^{50} ≈ 0.077 (7.7%)

Benchmark tidak pernah mengevaluasi peluruhan state (state degradation) ini secara realistis.

2. Ambiguitas Kontekstual dan Tribal Knowledge

Soal-soal benchmark memiliki prompt dengan variabel yang jelas. Di production, data masukan 80 persen bersifat tidak terstruktur, ambigu, dan sarat dengan tribal knowledge yang tidak terdokumentasi dalam basis data formal. Pekerjaan manusia melibatkan klarifikasi konstan, navigasi hierarki birokrasi, dan negosiasi trade-off teknis yang tidak memiliki ground truth biner (benar/salah).

3. Integrasi Sistem vs. Generasi Teks Murni

SWE-bench mendekati realitas teknis lebih baik dibanding pendahulunya, tetapi masih membatasi diri pada eksekusi runtime Docker lokal. Jam kerja riil seorang insinyur melibatkan debugging intermiten pada distributed system, pembacaan telemetry traces di Datadog, mitigasi skema database legacy yang rapuh, dan interaksi dengan API pihak ketiga yang tidak konsisten serta minim dokumentasi. Benchmark menguji kemampuan model menulis kode; enterprise membutuhkan kemampuan model menavigasi friksi operasional sistem.

---

Trade-Off Arsitektural: Cost, Konteks, dan Reliability

Mencoba memaksakan model frontier saat ini untuk menangani 90 persen tugas tak terpetakan tersebut memicu trade-off teknis yang brutal di tataran arsitektur:

[User Ambiguous Input]
        │
        ▼
[ReAct / Planning Loop] ──(Dynamic Context Retrieval)──► [Vector DB / Graph]
        │                                                       │
        ├─ Token Bloat & Latency Spike                          │
        ▼                                                       │
[Multi-Agent Coordination] ◄────────────────────────────────────┘
        │
        ├─ High Stochastic Drift (Non-Deterministic)
        ▼
[Execution / Tool Call] ──► [Legacy Enterprise API / SQL DB]
        │
        └── Failure Mode: Silent Data Corruption (Rollback Required)

Cost vs. Complex Verifier

Untuk menambal kelemahan model pada tugas long-horizon, pendekatan yang lazim digunakan adalah membangun loop refleksi (ReAct, Tree-of-Thoughts) atau multi-agent orchestration. Konsekuensinya adalah ledakan biaya inferensi. Memproses 100k token konteks yang berulang untuk setiap langkah penalaran menghabiskan alokasi komputasi dengan cepat.

Biaya unit ekonomi menjadi tidak masuk akal jika model menghabiskan 4.50 dalam biaya token API hanya untuk menyelesaikan tugas administratif yang nilainya setara dengan upah manusia 2.00 per jam untuk tugas yang sama.

Konteks Lebar vs. Needle-in-a-Haystack Degradation

Meskipun penyedia model menawarkan context window hingga 1M atau 2M token, attention drift tetap terjadi. Ketika dokumen compliance perbankan setebal 400 halaman dimasukkan ke dalam context window bersama dengan 50 schema relasional, performa model dalam mengambil instruksi operasional yang spesifik mengalami penurunan akurasi signifikan. Context window besar bukan pengganti memori episodik terstruktur.

Latensi vs. Human-in-the-Loop

Upaya mencapai akurasi tinggi pada tugas yang kompleks sering kali membutuhkan verifikasi manusia. Namun, memasukkan intervensi manual ke dalam pipeline otomatisasi yang lambat menciptakan bottleneck baru. Latensi sistem meningkat dari hitungan milidetik menjadi hitungan jam karena ketergantungan pada tinjauan manual, menegasikan nilai efisiensi otomatisasi itu sendiri.

---

Rekomendasi Teknis untuk Engineering Teams

Mengacu pada diskoneksi antara metrik publik dan realitas operasional, tim teknis perlu mengubah paradigma perancangan sistem berbasis LLM:

1. Buang Benchmark Publik sebagai Acuan Arsitektur

Skor MMLU atau LMSYS Chatbot Arena tidak memiliki korelasi langsung dengan kemampuan model mengekstrak entitas dari invoice semi-rusak atau memvalidasi payload JSON terhadap sistem ERP SAP yang kaku. Bangun harness evaluasi internal (Evals) berbasis produksi:

  • Ambil sampel 500 transaksi riil yang mewakili edge cases operasional.
  • Tentukan metrik evaluasi berbasis unit test deterministik, bukan evaluasi LLM-as-a-judge yang longgar.
  • Jadikan Evals ini sebagai gating pipeline dalam continuous integration (CI) sebelum memperbarui model fondasi atau prompt logic.

2. Prioritaskan Deterministic State Machines daripada Autonomous Agents

Hindari arsitektur multi-agent otonom tanpa batasan (fully autonomous) untuk proses bisnis krusial. Gunakan state machine deterministik (seperti Temporal atau AWS Step Functions) untuk alur kerja utama, dan posisikan LLM secara ketat sebagai micro-parser atau edge worker:

  • Batasi peran LLM hanya pada: transformasi data tidak terstruktur menjadi struktur yang divalidasi oleh JSON Schema/Pydantic.
  • Gunakan kode deterministik (Python/Go/Rust) untuk mengeksekusi transisi logika bisnis dan panggilan database.
  • Terapkan idempotency keys pada setiap eksekusi tool call untuk mencegah mutasi state ganda akibat retry otomatis saat model mengalami timeout.

3. Reduksi Konteks Secara Agresif

Jangan membebani context window dengan seluruh state aplikasi. Terapkan strategi RAG berbasis Graph atau Knowledge Graph yang dikurasi secara deterministik, bukan sekadar naive dense retrieval:

  • Ambil hanya sub-graph dan state lokal yang relevan untuk transisi langkah tertentu.
  • Pertahankan skema input/output sekecil mungkin guna menekan latensi inferensi dan meminimalkan token cost.

4. Fokus pada Observabilitas Payload dan Rollback

Sebagian besar failure mode pada LLM bukan berupa exception runtime eksplisit (seperti HTTP 500), melainkan silent semantic corruption (data yang salah secara konteks bisnis tetapi valid secara sintaksis).

  • Pasang logging struktural pada setiap input/output node model.
  • Bangun mekanisme circuit breaker otomatis: jika model menghasilkan format yang menyimpang dua kali berturut-turut, fallback ke alur reguler atau arahkan langsung ke antrean review teknis manusia tanpa melanjutkan eksekusi ke sistem hilir.

---

Kesimpulan

Kesenjangan 90 persen yang diidentifikasi oleh riset Mercor menunjukkan bahwa revolusi AI generatif saat ini masih tertahan di batas luar utilitas ekonomi enterprise yang sesungguhnya. Model fondasi telah menyelesaikan domain pencarian pola sintaksis dan sintesis teks statis. Namun, pekerjaan rekayasa perangkat lunak yang krusial bukanlah merayakan skor benchmark sintetis, melainkan mendesain arsitektur tangguh di sekitar ketidaksempurnaan model tersebut: mengelola state yang rapuh, meredam halusinasi secara deterministik, dan menjembatani model dengan sistem produksi dunia nyata.

Arsitektur & Alur Visual Sistem

Arsitektur dan Alur Sistem: 90% of US working hours are spent on tasks not covered well by AI benchmarks