Economics of Reasoning Effort pada LLM Agents (arXiv:2610.34491): Dilema Credence Good, Inflasi Biaya 42x, Regresi Akurasi Instance-Level, dan Arsitektur Adaptive Escalation

Dalam lanskap model frontier modern (OpenAI o1/o3, DeepSeek-R1, Gemini Thinking, hingga Qwen3-Thinking), penyedia API menyediakan tombol pengatur tunggal yang tampak linear: Reasoning Effort (None, Low, Medium, High, Extra High). Asumsi umum di kalangan tim rekayasa perangkat lunak adalah semakin tinggi dial penalaran diputar, semakin cerdas model bekerja dan semakin tinggi probabilitas keberhasilan tugas. Namun, riset empiris komprehensif terbaru dari gabungan peneliti Stanford dan Harvard dalam paper "What Effort Level Should I Choose? On the Economics of Reasoning Effort in LLM Agents" (arXiv:2610.34491) mengungkap kenyataan yang bertolak belakang secara mengejutkan: effort tinggi sering kali menggagalkan tugas yang sebelumnya berhasil diselesaikan pada effort rendah, memicu inflasi biaya komputasi hingga 42x lipat pada tugas mudah, dan memicu perilaku hyper-verification kontraproduktif.

1. Teori Ekonomi Credence Good dalam Komputasi Inferensi Test-Time

Dalam ilmu ekonomi mikro klasik (Darby & Karni, 1973; Dulleck & Kerschbamer, 2006), credence good adalah kategori barang atau jasa yang utilitas marjinalnya tidak dapat dinilai oleh konsumen bahkan setelah produk tersebut dikonsumsi. Contoh tipikal di dunia nyata adalah perbaikan mesin mobil atau konsultasi medis: montir dapat menyatakan bahwa penggantian transmisi seharga puluhan juta rupiah mutlak diperlukan untuk memperbaiki mobil Anda; setelah Anda membayar dan mobil kembali berjalan, Anda tetap tidak pernah tahu apakah mobil tersebut sebenarnya hanya memerlukan pengencangan satu baut longgar.

Paper arXiv:2610.34491 menunjukkan bahwa reasoning effort pada LLM agent adalah manifestasi sempurna dari credence good digital:

2. Paradoks 1: Ilusi Akurasi Agregat vs Regresi Solusi (Non-Nested Sets)

Secara konseptual, jika effort $e_1 < e_2$, para rekayasawan berasumsi bahwa himpunan task yang terselesaikan pada level rendah ($s_{e_1}$) akan menjadi subset dari himpunan task pada level tinggi ($s_{e_2}$), yaitu $s_{e_1} subseteq s_{e_2}$. Jika ini benar, menaikkan effort selalu merupakan keputusan aman selama anggaran mencukupi.

Namun, temuan Section 3.1 paper ini membuktikan bahwa himpunan solusi sama sekali tidak bersarang (non-nested). Pada seluruh 8 model frontier yang diuji di Terminal-Bench 2.1:

Terdapat sekumpulan tugas nyata yang diselesaikan dengan mulus pada effort rendah, tetapi gagal total ketika effort dinaikkan. Angka agregat menipu pengembang karena kenaikan metrik makro menutupi korban regresi di tingkat instans:

Sebagai contoh spesifik pada task dna-insert di Terminal-Bench: pada effort tertinggi, GPT-5.6-sol terjebak dalam simulasi internal panjang yang melaporkan bahwa outputnya telah memenuhi batasan numerik, padahal script verifier eksternal menolaknya karena parameter output tergeser. Sebaliknya, run pada effort low mengeksekusi perintah Unix secara langsung tanpa overthinking dan langsung lulus verifikasi.

3. Paradoks 2: Inflasi Biaya Hingga 42x pada Himpunan Tugas Mudah ($s_{ ext{all}}$)

Para perancang sistem sering berharap bahwa model cerdas yang diberi instruksi penalaran tinggi akan segera menyadari jika masalah yang dihadapi sepele, lalu menghentikan inferensi secara efisien. Riset Section 3.2 membantah hipotesis ini secara kategoris dengan mengevaluasi subset $s_{ ext{all}}$—yaitu tugas-tugas yang berhasil diselesaikan pada semua tingkat effort:

• Kegagalan Pemulihan Rute Efisien: Model yang dikonfigurasi pada effort tinggi tidak pernah mereplikasi rute ringkas yang diambilnya saat disetel pada low effort. Pengeluaran token selalu bertambah secara monoton mengikuti level effort yang ditentukan di muka.
• Rasio Biaya Ekstrem (Hingga 42x Lipat): Pada soal matematika dan sains yang terpecahkan di seluruh level, biaya inferensi per task pada level tertinggi melonjak hingga 42x lebih mahal daripada level terendah tanpa menghasilkan diferensiasi output yang berarti.
• Effort "None" Bukan Solusi Hemat Otomatis: Mematikan reasoning secara penuh (effort: 'none') tidak menjamin penghematan pada skenario agentik. Tanpa penalaran internal, agent sering kali tersesat dalam siklus pemanggilan tool eksternal yang repetitif, mentransfer biaya dari token penalaran ke biaya token konteks input/output yang bahkan lebih mahal.

4. Perubahan Perilaku Trajektori: Hyper-Verification & Shortcut Retrieval

Menggunakan taksonomi Act·ONOMY (arXiv:2605.13625), para peneliti membedah apa yang sebenarnya dilakukan oleh agent saat reasoning effort dinaikkan. Ditemukan bahwa penambahan komputasi bukan sekadar membuat agen berpikir lebih lama mengenai algoritma yang sama, melainkan menggeser strategi penyelesaian masalah secara fundamental:

5. Arsitektur Produksi: Adaptive Escalation Laddering Engine

Jika memilih effort tetap di muka (fixed effort) terbukti tidak efisien, dan membiarkan LLM merutekan tingkat effort-nya sendiri (self-routing) tidak lebih baik dari pemilihan acak, apa solusi terbaik bagi rekayasa sistem agentik?

Jawabannya adalah Adaptive Escalation Protocol (Naïve Laddering with Deterministic Outcome Feedback):

1. Eksekusi Awal pada Effort Terendah: Selalu jalankan attempt pertama pada level low (atau level minimum yang mendukung pemanggilan tool). Mayoritas tugas bisnis dan coding standar terselesaikan pada tahap ini dengan biaya fraksional ($0.05–$0.20).
2. Verifikasi Deterministik Eksternal: Alihkan beban verifikasi dari self-reflection LLM ke verifier eksternal yang murah dan deterministik (misalnya: linting, TypeScript compiler, unit tests, regex schema validator).
3. Eskalasi Bertingkat Berdasarkan Kegagalan Terverifikasi: Hanya jika verifier eksternal menolak artefak, sistem mengeskalasikan task ke effort berikutnya (low → medium → high → xhigh), menyertakan pesan error verifikasi ke dalam context retry.

// Production Implementation: Adaptive Reasoning Effort Laddering Engine
// Berdasarkan Prinsip Rekayasa arXiv:2610.34491 (Economics of Reasoning Effort)
// Mengeliminasi pemborosan biaya hingga 42x lipat dan mencegah regresi akurasi
// dengan memulai inferensi pada tingkat effort terendah, lalu melakukan eskalasi
// terkontrol hanya jika verifikasi eksternal (deterministik) mendeteksi kegagalan.

export type ReasoningEffortLevel = 'none' | 'low' | 'medium' | 'high' | 'xhigh';

export interface TaskVerificationResult {
  passed: boolean;
  score?: number;
  stdout?: string;
  errorMessage?: string;
}

export interface ExecutionAttemptLog {
  effort: ReasoningEffortLevel;
  durationMs: number;
  tokensConsumed: {
    prompt: number;
    completion: number;
    reasoning: number;
  };
  apiCostUsd: number;
  verified: boolean;
}

export interface AdaptiveEscalationConfig {
  ladderSequence: ReasoningEffortLevel[]; // Default: ['low', 'medium', 'high']
  costCeilingUsdPerTask: number;
  wallClockTimeoutMs: number;
  enableFastFailCircuitBreaker: boolean;
}

export class AdaptiveEffortLadderingEngine {
  private readonly config: AdaptiveEscalationConfig;

  constructor(
    private readonly agentInvoker: (input: TInput, effort: ReasoningEffortLevel) => Promise<{
      output: TOutput;
      tokens: { prompt: number; completion: number; reasoning: number };
      costUsd: number;
    }>,
    private readonly deterministicVerifier: (output: TOutput, input: TInput) => Promise,
    customConfig?: Partial
  ) {
    this.config = {
      ladderSequence: customConfig?.ladderSequence || ['low', 'medium', 'high'],
      costCeilingUsdPerTask: customConfig?.costCeilingUsdPerTask || 2.50,
      wallClockTimeoutMs: customConfig?.wallClockTimeoutMs || 300_000, // 5 menit
      enableFastFailCircuitBreaker: customConfig?.enableFastFailCircuitBreaker ?? true,
    };
  }

  /**
   * Menjalankan eksekusi tugas dengan protokol laddering eskalasi bertingkat.
   * Mengembalikan hasil terverifikasi pertama yang lolos atau attempt terbaik.
   */
  public async execute(taskInput: TInput): Promise<{
    finalOutput: TOutput;
    isVerified: boolean;
    totalAttempts: number;
    totalCostUsd: number;
    trajectoryHistory: ExecutionAttemptLog[];
    resolvedAtEffort: ReasoningEffortLevel;
  }> {
    const startTime = Date.now();
    let accumulatedCost = 0;
    const history: ExecutionAttemptLog[] = [];

    let lastOutput: TOutput | null = null;
    let successfulOutput: TOutput | null = null;
    let successfulEffort: ReasoningEffortLevel = this.config.ladderSequence[0];

    for (let i = 0; i < this.config.ladderSequence.length; i++) {
      const currentEffort = this.config.ladderSequence[i];
      const attemptStart = Date.now();

      // Cek limitasi anggaran & timeout sebelum memulai panggilan model
      if (accumulatedCost >= this.config.costCeilingUsdPerTask) {
        console.warn(`[LadderingEngine] Anggaran biaya batas atas (${this.config.costCeilingUsdPerTask}) terlampaui.`);
        break;
      }
      if (Date.now() - startTime >= this.config.wallClockTimeoutMs) {
        console.warn(`[LadderingEngine] Wall-clock timeout terlampaui.`);
        break;
      }

      console.info(`[LadderingEngine] Mencoba eksekusi tahap ${i + 1}/${this.config.ladderSequence.length} dengan effort: "${currentEffort}"`);

      try {
        const runResult = await this.agentInvoker(taskInput, currentEffort);
        lastOutput = runResult.output;
        accumulatedCost += runResult.costUsd;

        // Evaluasi verifikasi deterministik eksternal (compiler, test runner, regex verifier)
        const verifyResult = await this.deterministicVerifier(runResult.output, taskInput);
        const attemptDuration = Date.now() - attemptStart;

        history.push({
          effort: currentEffort,
          durationMs: attemptDuration,
          tokensConsumed: runResult.tokens,
          apiCostUsd: runResult.costUsd,
          verified: verifyResult.passed,
        });

        if (verifyResult.passed) {
          console.info(`✅ [LadderingEngine] Solusi TERVERIFIKASI lolos pada effort "${currentEffort}" dalam ${attemptDuration}ms! Tidak diperlukan eskalasi.`);
          successfulOutput = runResult.output;
          successfulEffort = currentEffort;
          break; // Stop! Jangan buang token/biaya untuk level yang lebih tinggi
        }

        console.warn(`⚠️ [LadderingEngine] Verifikasi gagal pada effort "${currentEffort}". Alasan: ${verifyResult.errorMessage || 'Mismatched test assertion'}. Mengeskalasikan...`);
      } catch (err) {
        console.error(`❌ [LadderingEngine] Error eksekusi pada level ${currentEffort}:`, (err as Error).message);
        if (this.config.enableFastFailCircuitBreaker && (err as Error).message.includes('RATE_LIMIT')) {
          throw err;
        }
      }
    }

    if (!successfulOutput && lastOutput) {
      successfulOutput = lastOutput; // Fallback ke output terakhir jika semua level gagal verifikasi
    }

    if (!successfulOutput) {
      throw new Error('Semua tingkatan reasoning effort gagal menghasilkan artefak.');
    }

    return {
      finalOutput: successfulOutput,
      isVerified: history.some(h => h.verified),
      totalAttempts: history.length,
      totalCostUsd: Number(accumulatedCost.toFixed(4)),
      trajectoryHistory: history,
      resolvedAtEffort: successfulEffort,
    };
  }
}

6. Evaluasi Biaya Total: Memperhitungkan Latensi Waktu Tunggu Pengguna

Penghematan dari arsitektur laddering menjadi jauh lebih spektakuler ketika biaya waktu tunggu pengguna (user waiting cost) dimasukkan ke dalam persamaan biaya total:

Di mana $w$ adalah nilai ekonomi waktu insinyur/pengguna per detik, dan $T$ adalah latensi total inferensi. Pada tugas-tugas agentic SWE-Bench, waktu tunggu menyumbang 58% hingga 98% dari total beban ekonomi interaksi. Karena effort tinggi melipatgandakan latensi hingga beberapa menit per percobaan, laddering yang menyelesaikan sebagian besar tugas dalam hitungan detik pada effort low menghasilkan penghematan biaya total gabungan hingga 19.5% lebih murah daripada konfigurasi fixed high pada GPT-5.6-terra di Terminal-Bench.

7. Panduan Rekayasa Lapangan & Kesimpulan Arsitektural

Bagi pimpinan teknologi, arsitek AI, dan pengembang sistem agentic o1/o3/DeepSeek-R1, temuan dari riset ini merumuskan 4 aturan baku rekayasa perangkat lunak: