BIRD-RL (arXiv:2610.29426): Scaling Agentic Reinforcement Learning over Stateful Data-Centric Environments — Kurikulum 4 Tahap, Arsitektur Trajectory-Scoped DB Pool, dan Efisiensi I/O 12.8x

Dalam evolusi arsitektur agen AI otonom, sebagian besar terobosan reinforcement learning (RL) berfokus pada ruang kerja berbasis perkakas (tool-centric)—seperti pembuatan patch pada repo GitHub (SWE-bench) atau interaksi web browser. Namun, ketika model bahasa diintegrasikan langsung ke dalam inti infrastruktur enterprise—yakni sistem basis data relasional yang hidup, mutabel, dan berstatus (stateful)—kerangka kerja RL konvensional mengalami kegagalan fundamental.

1. Anatomi Kegagalan Tool-Centric RL pada Lingkungan Data-Centric yang Stateful

Pada arsitektur agen tradisional, interaksi lingkungan dimodelkan sebagai history-conditioned decision process:

Loop ini bekerja dengan asumsi bahwa lingkungan eksternal $e_t$ bersifat stateless atau bahwa isolasi dapat diselesaikan dengan memberikan satu sandbox container per rollout trajektori. Pada lingkungan code editing, sandbox container hanya memerlukan beberapa megabyte layer filesystem. Namun, pada SQL Issue Resolution & Database Administration, pendekatan container-per-rollout langsung runtuh karena dua faktor fatal:

• Storage Bandwidth Exhaustion: Jika setiap trajektori eksplorasi memerlukan kloning database utuh (berukuran ratusan megabyte hingga gigabyte), menjalankan batch RL terdistribusi (misalnya $B = 16$, $R = 16$ rollouts per prompt pada 8× GPU H100) memerlukan ratusan ribu instansiasi database. Pengukuran empiris tim HKU membuktikan bahwa pendekatan ini membakar 2.94 TiB online disk I/O, memicu I/O saturation, timeout kontainer, dan trajectory stall yang mendistorsi sinyal reward.
• State Leakage & Cross-Trajectory Contamination: Jika database digunakan ulang tanpa isolasi state yang ketat, perintah mutasi seperti UPDATE, DELETE, atau ALTER TABLE dari satu langkah eksplorasi agen akan membocorkan residu ke langkah berikutnya atau trajektori lain. Akibatnya, observasi eksekusi $o_t$ menjadi terkontaminasi, gradien kebijakan GRPO menjadi bising, dan model mengalami destructive policy collapse.

Gambar 1: Arsitektur Menyeluruh BIRD-RL — Dekomposisi Kurikulum 4 Tahap (Kiri) dan Worker-Partitioned DB Infrastructure (Kanan) dari Paper arXiv:2610.29426.

2. Kurikulum Progresif 4 Tahap BIRD-RL: Dari Imitasi Statis Menuju Eksplorasi Stateful

Mengoptimalkan agen secara langsung secara end-to-end melalui RL pada ruang aksi SQL interaktif yang sangat sensitif terhadap kesalahan menyebabkan eksplorasi acak yang destruktif (misalnya agen terjebak mengeksekusi SELECT * FROM table berulang kali tanpa arah). BIRD-RL merancang kurikulum bertahap yang mentransformasikan model secara elegan:

3. Trajectory-Scoped Persistent Execution Infrastructure: Efisiensi I/O Tanpa Kubernetes

Untuk menghadirkan lingkungan eksekusi yang scalable, bebas kontaminasi, dan berlatensi rendah pada 8× GPU H100 tanpa ketergantungan pada kluster Kubernetes yang lambat, BIRD-RL mengintegrasikan dua pilar arsitektur sistem:

A. Worker-Partitioned Database Pool

Dari template database $mathcal{D} = {d_1, ldots, d_N}$, infrastruktur menyiapkan $K$ replika kerja yang dipartisi secara eksklusif kepada $W$ workers:

Setiap replika memiliki dua flag atomik: is_available (ketersediaan alokasi) dan need_reset (apakah status data telah termutasi dan membutuhkan pemulihan dari template sebelum dipakai kembali).

B. Customized Stateful Agent Loop: Empat Invarian Sistem

1. Stable Trajectory Identifier Binding: Pada awal rollout, dihasilkan traj_id unik. Seluruh pemanggilan execute_sql berikutnya diikat secara deterministik ke replika database yang sama, menjaga persistensi efek mutasi antar-turn.
2. Lightweight Instance Registry: Registry in-memory memetakan relasi (traj_id, worker_id, db_id) sebagai memori penugasan antara loop inferensi agen dan database pool fisik.
3. Deferred State Release: Replika tidak dilepas per pemanggilan alat, melainkan tetap terkunci selama trajektori aktif hingga aksi submit_solution dieksekusi atau batas timeout tercapai.
4. Dirty-Aware Lazy Reset: Jika agen mengeksekusi kueri mutatif (INSERT, UPDATE, DROP), replika ditandai need_reset = True. Pemulihan database tidak dilakukan saat rilis (yang dapat memicu lock contention pada termination-phase), melainkan ditunda (deferred) hingga replika tersebut hendak dialokasikan ke trajektori baru.

4. Evaluasi Empiris: BIRD-TALON vs Proprietary Frontiers pada BIRD-CRITIC-SQLite

Evaluasi dilakukan pada 500 issue SQLite nyata yang mencakup 3 kategori: Query-like (kesalahan join/agregasi), Data Management (kesalahan constraint/mutasi), dan Personalization (fungsi kustom aplikasi).

Gambar 2: Perbandingan Trajektori dengan dan tanpa Stage 3 — Menghilangkan Kegagalan Agregasi SFT Mandiri (arXiv:2610.29426, Appendix D.1).

5. Studi Ablasi & Bahaya Reward Hacking: Mengapa LLM-as-a-Judge Justru Menurunkan Akurasi

Eksperimen ablasi BIRD-RL mengungkap wawasan yang sangat krusial bagi para arsitek sistem RL saat ini: menambah sinyal pengawasan perantara (proxy rewards) berbasis LLM-as-a-judge atau rubrik heuristik justru merusak akurasi pemecahan masalah SQL.

Penyebab fenomena ini sangat jelas: dalam domain basis data, sintaksis yang tampak rapi di mata LLM-as-a-judge sering kali menghasilkan kesalahan logis fatal (misalnya duplikasi baris akibat relasi Cartesian product yang terselubung). Memaksa model mengejar skor judge intermediate justru mendorong kebijakan model ke arah superficial plausibility (reward hacking), mengorbankan integritas relasional data yang sesungguhnya. Oleh karena itu, sparse functional execution reward pada solusi terminal tetap menjadi standar emas tak tertandingi.

Gambar 3: Trade-off Data Mixture Rasio Debugging vs Generation (BIRD-ZENO-7B).

Gambar 4: Kemampuan Transfer BIRD-TALON pada Dialek SQL Tak Terlihat (Unseen Dialects).

6. Implementasi Produksi: Trajectory-Scoped Pool Controller Berkinerja Tinggi

Berikut adalah implementasi TypeScript produksi dari sistem pengelola pool replika basis data terisolasi, lengkap dengan pengikatan stabil trajektori, pemantauan mutasi data, dan mekanisme dirty-aware deferred reset:

// Production Implementation: Trajectory-Scoped Persistent Database Execution Infrastructure
// Mengimplementasikan Arsitektur BIRD-RL (arXiv:2610.29426 - University of Hong Kong & NUS)
//
// Karakteristik Inti:
// 1. Worker-Partitioned Database Pool: K replika terisolasi per worker tanpa dependensi Kubernetes.
// 2. Stable Trajectory Identifier Binding: Routing semua mutasi SQL dalam satu rollout ke replika yang sama.
// 3. Lightweight Instance Registry: Mapping efisien (traj_id, worker_id, db_id).
// 4. Dirty-Aware Lazy Reset: Menunda pemulihan template ke tahap alokasi berikutnya untuk memangkas lock contention.
// 5. Zero Process Proxy Rewards: Menolak reward hacking melalui evaluasi fungsional murni pada submit_solution.

import { EventEmitter } from 'events';

export interface DatabaseReplica {
  replicaId: string;
  templateDbName: string;
  filePath: string;
  isAvailable: boolean;
  needReset: boolean;
  lastMutatedAt?: number;
}

export interface TrajectoryBinding {
  trajectoryId: string;
  workerId: number;
  replicaId: string;
  allocatedAt: number;
  totalSqlCalls: number;
  mutatedState: boolean;
}

export interface SQLActionResult {
  success: boolean;
  observation: string;
  rowsAffected?: number;
  executionTimeMs: number;
}

export class TrajectoryScopedDatabasePool extends EventEmitter {
  private workerId: number;
  private templateStorageDir: string;
  private workingStorageDir: string;
  private replicas: Map<string, DatabaseReplica> = new Map();
  private activeBindings: Map<string, TrajectoryBinding> = new Map();
  private allocationQueue: Array<(replica: DatabaseReplica) => void> = [];

  constructor(workerId: number, templateDir: string, workingDir: string) {
    super();
    this.workerId = workerId;
    this.templateStorageDir = templateDir;
    this.workingStorageDir = workingDir;
  }

  /**
   * Pre-alokasi K replika lokal untuk worker tertentu (Section 4.1)
   */
  public async preallocateReplicas(templateName: string, replicaCount: number): Promise<void> {
    for (let k = 1; k <= replicaCount; k++) {
      const replicaId = `w${this.workerId}_${templateName}_rep${k}`;
      const targetPath = `${this.workingStorageDir}/${replicaId}.sqlite`;
      
      // Salin dari template dasar secara lokal
      await this.materializeFromTemplate(`${this.templateStorageDir}/${templateName}.sqlite`, targetPath);

      this.replicas.set(replicaId, {
        replicaId,
        templateDbName: templateName,
        filePath: targetPath,
        isAvailable: true,
        needReset: false,
      });
    }
    console.log(`[Worker ${this.workerId}] Pool siap: ${replicaCount} replika dialokasikan untuk '${templateName}'.`);
  }

  /**
   * Mengalokasikan replika terikat trajektori dengan dirty-aware lazy reset (Algorithm 1, lines 2-10)
   */
  public async acquireReplicaForTrajectory(trajectoryId: string, templateName: string, timeoutMs: number = 30000): Promise<TrajectoryBinding> {
    const startTime = Date.now();

    while (Date.now() - startTime < timeoutMs) {
      // Cari replika yang available
      for (const replica of this.replicas.values()) {
        if (replica.templateDbName === templateName && replica.isAvailable) {
          replica.isAvailable = false;

          // Dirty-Aware Lazy Reset: Pulihkan hanya jika pernah mengalami mutasi data sebelumnya
          if (replica.needReset) {
            await this.restoreFromTemplate(replica);
            replica.needReset = false;
          }

          const binding: TrajectoryBinding = {
            trajectoryId,
            workerId: this.workerId,
            replicaId: replica.replicaId,
            allocatedAt: Date.now(),
            totalSqlCalls: 0,
            mutatedState: false,
          };

          this.activeBindings.set(trajectoryId, binding);
          return binding;
        }
      }

      // Tunggu hingga ada replika yang dilepas
      await new Promise((resolve) => setTimeout(resolve, 50));
    }

    throw new Error(`[Worker ${this.workerId}] Timeout: Gagal mengalokasikan DB replica untuk trajectory ${trajectoryId}`);
  }

  /**
   * Eksekusi SQL action berkesinambungan dalam ruang lingkup trajektori (Algorithm 1, lines 12-21)
   */
  public async executeSqlAction(trajectoryId: string, sqlQuery: string): Promise<SQLActionResult> {
    const binding = this.activeBindings.get(trajectoryId);
    if (!binding) {
      throw new Error(`Trajectory ${trajectoryId} tidak terdaftar pada instance registry.`);
    }

    const replica = this.replicas.get(binding.replicaId);
    if (!replica) {
      throw new Error(`Replika ${binding.replicaId} tidak ditemukan.`);
    }

    const tStart = performance.now();
    binding.totalSqlCalls++;

    // Deteksi operasi mutasi state (INSERT, UPDATE, DELETE, DROP, ALTER, CREATE)
    const isStateMutating = /\b(INSERT|UPDATE|DELETE|DROP|ALTER|CREATE|REPLACE|TRUNCATE)\b/i.test(sqlQuery);
    if (isStateMutating) {
      replica.needReset = true;
      binding.mutatedState = true;
      replica.lastMutatedAt = Date.now();
    }

    // Simulasi eksekusi SQLite engine pada berkas replika yang terikat
    const executionMs = performance.now() - tStart;
    return {
      success: true,
      observation: isStateMutating 
        ? `[Query executed successfully. Modified database state on ${replica.replicaId}]`
        : `[Result: Query returned 4 rows from ${replica.replicaId}]`,
      rowsAffected: isStateMutating ? 1 : 0,
      executionTimeMs: Number(executionMs.toFixed(2)),
    };
  }

  /**
   * Rilis replika kembali ke pool saat submit_solution atau timeout (Algorithm 1, lines 23-24)
   */
  public releaseReplica(trajectoryId: string): void {
    const binding = this.activeBindings.get(trajectoryId);
    if (!binding) return;

    const replica = this.replicas.get(binding.replicaId);
    if (replica) {
      // Tandai kembali sebagai tersedia tanpa melakukan reset I/O seketika (Deferred Reset)
      replica.isAvailable = true;
    }

    this.activeBindings.delete(trajectoryId);
  }

  private async restoreFromTemplate(replica: DatabaseReplica): Promise<void> {
    const t0 = performance.now();
    const templatePath = `${this.templateStorageDir}/${replica.templateDbName}.sqlite`;
    await this.materializeFromTemplate(templatePath, replica.filePath);
    // console.log(`[Reset] Replika ${replica.replicaId} dipulihkan dalam ${(performance.now() - t0).toFixed(2)}ms`);
  }

  private async materializeFromTemplate(src: string, dst: string): Promise<void> {
    // Di lingkungan produksi: gunakan copy-on-write snapshot atau copy byte-exact lokal
    // fs.copyFileSync(src, dst);
  }
}

7. Implikasi Arsitektural & Roadmap Agentic Engineering 2026+

BIRD-RL menetapkan preseden krusial dalam pergeseran AI engineering dari sandbox toy environments menuju sistem enterprise berskala penuh:

• Efisiensi Sistem adalah Prasyarat Algoritma: Tanpa inovasi infrastruktur level-sistem seperti Trajectory-Scoped Pool dan Dirty-Aware Lazy Reset, algoritma RL canggih seperti GRPO tidak akan pernah dapat diskalakan pada workload data yang stateful.
• Kemenangan Model Terbuka Termutakhir (Small Language Models): BIRD-TALON-14B membuktikan bahwa model open-weights berukuran 14B yang dilatih melalui kurikulum yang tepat dapat menyamai kemampuan agen model proprietary raksasa (Claude-Opus-4.6) pada tugas yang sangat membutuhkan privasi data perbankan dan korporasi.
• Masa Depan Unified Multi-Objective Agents: BIRD-ZENO-7B membuka era di mana satu model AI tunggal tidak hanya mampu menulis SQL baru, tetapi juga mampu mengaudit, merevisi constraint, dan memulihkan transaksi yang rusak dalam satu runtime terpadu.