Datadog Scout 1.0: Arti Investigasi AI SRE yang Lebih Murah

Pada 15 Oktober 2026 Datadog merilis Scout 1.0, dan kalimat yang paling banyak beredar adalah soal biaya: model yang menyamai dua model frontier tetapi 3-8× lebih murah untuk menjalankan satu investigasi. Pertanyaan pertama saya bukan apakah itu benar, melainkan apa yang akan saya ubah di hari Senin kalau itu benar.

Tulisan ini adalah pembacaan teliti atas tiga dokumen Datadog (blog peluncuran, technical report PDF, dan post eval platform), paper dan leaderboard SREGym yang menjadi sandarannya, serta halaman docs dan pricing Datadog. Saya belum menjalankan Scout karena masih closed preview, jadi isinya adalah cara membaca klaim dan menyusun budget, bukan benchmark milik saya sendiri.

Apa itu Scout, dan klaimnya dalam satu paragraf

Menurut blog peluncuran, Scout adalah model pertama Datadog yang dikhususkan untuk menginvestigasi masalah production, dan menjadi mesin Bits Investigation, yang mereka sebut AI SRE. Technical report menjelaskan Scout dimulai dari GLM-5.3 Flash lalu di-post-train dengan reinforcement learning agar menginvestigasi alert lewat tools yang sama dengan yang dipakai engineer: metrics, logs, traces, dependencies, perubahan seperti deployment dan feature flag, serta code.

Semua angka utama berasal dari satu benchmark internal. Pada medium effort, Scout 1.0 menyamai GPT-6.1 Sol high dan Claude Opus 5.5 high dengan estimasi biaya inference 3-8× lebih rendah, dan sebanding dengan Fable 5.1 medium serta GPT-6 Astra medium pada biaya 12× dan 19× lebih rendah. Dengan test-time scaling, Scout 1.0 xhigh menyamai Fable 5.1 xhigh pada biaya 4× lebih rendah. Tujuannya ekonomis: menjalankan investigasi jauh lebih sering dan lebih awal dalam sebuah insiden.

Cara membaca chart AlertEval

Chart-nya adalah plot Pareto: skor di sumbu vertikal, estimasi biaya per investigasi di sumbu horizontal, dinyatakan relatif terhadap Scout 1.0 medium dari 30× di kiri hingga 1× di kanan. Tiga detail dalam report menentukan seberapa berat chart ini bisa dipercaya, dan blog peluncuran meringkas ketiganya.

Satu kebiasaan membaca lagi: perhatikan skalanya. Sumbu vertikal pada figure berjalan dari 48 sampai 68 sementara sumbu biaya mencakup 30×. Pada rubrik yang memberi partial credit, selisih beberapa poin adalah pergeseran kecil, dan cerita menariknya adalah biaya sangat bervariasi di antara model yang berada pada pita kualitas sempit. Itu dasar yang wajar untuk membangun produk. Itu bukan pernyataan bahwa model yang lebih murah sama baiknya di semua hal.

Resep pelatihan: simulasikan insiden, beri reward pada bukti

Bagian report yang paling bisa dipakai ulang adalah cara Datadog mendapat data latih tanpa data pelanggan. Melabeli insiden nyata secara manual mahal, dan telemetry insiden lama biasanya sudah kedaluwarsa, jadi mereka membangun GenSim, framework yang men-deploy behavioural twin dari aplikasi umum dan menyuntikkan fault dengan root cause yang diketahui, dengan semangat chaos engineering. Postmortem menjadi seed untuk sebagian skenario, dan dua generator mengubahnya menjadi task.

Di sisi pembelajaran mereka memakai asynchronous RL pada fork SkyRL di atas Ray, dengan GRPO yang dimodifikasi: importance sampling dan asymmetric clipping terhadap inference policy, panjang maksimum konstan pada loss untuk mencegah investigasi yang terlalu panjang, tanpa KL penalty langsung dan tanpa entropy regularisation. Reward-nya hybrid antara kebenaran, eksplorasi, dan grounding pada bukti. Mereka juga memakai harness fuzzing, yaitu membuang tools opsional secara acak dan memvariasikan turn budget, supaya model tahan ketika tool surface production berubah.

Aturan kurasinya adalah bagian yang akan saya tiru untuk eval apa pun. Mereka menyaring shortcut dan kebocoran jawaban, termasuk runbook yang terlalu detail, membuang skenario yang sudah konsisten diselesaikan model, dan menyeimbangkan ulang agar filter kesulitan tidak menghapus seluruh kombinasi sistem dan fault.

SREGym: pengecekan independen dan batasnya

SREGym adalah benchmark publik yang dipakai Datadog untuk berargumen bahwa peningkatannya berlaku pada harness dan sebaran task yang berbeda. Paper oleh peneliti termasuk Hans-Arno Jacobsen dan Tianyin Xu menjelaskan sistem hidup di atas stack cloud-native nyata, fault injector, background noise, serta mode kegagalan seperti metastable dan correlated failure, dengan 90 masalah. Datadog menjalankan seluruh 90 task tanpa noise pada harness Stratus bawaan.

Klaim report: Scout 1.0 medium meningkat signifikan dari GLM-5.3 Flash dan melampaui GLM-5.3 dengan biaya lebih dari 4× lebih rendah, dan mode effort tertinggi kompetitif dengan model terbaik sambil tetap hemat biaya minimal 2× terhadap semua pesaing, serta 10× terhadap kelas Astra dan Fable. Catatan kakinya membawa caveat: run Datadog sendiri memakai satu percobaan per fault, baris lain disalin dari leaderboard publik dengan agent harness terbaik tiap model, dan ketika safety classifier Claude Fable menolak sebuah request mereka fallback ke Claude Opus 5.5 pada level effort yang sama.

Dua hal lagi. Blog peluncuran dan report berbeda label, menyebut hasil SREGym yang sama sebagai Scout 1.0 high di satu tempat dan xhigh di tempat lain, jadi cek tier mana yang dimaksud sebuah angka. Dan leaderboard publik di sregym.com yang saya baca memuat kohort Lite terpisah berisi 17 fault di mana lima baris teratas mendapat 97,1 sampai 100 persen, artinya kohort itu tidak lagi membedakan agent yang kuat. Dengan satu percobaan per fault pada 90 fault, saya menganggap selisih beberapa fault sebagai noise.

Dari rasio menjadi budget

Rasio biaya bukan harga, dan Scout belum punya harga: post-nya tidak mencantumkan pricing dan aksesnya lewat form sign-up untuk closed preview. Yang dipublikasikan Datadog adalah satuan penagihannya. Halaman pricing mencantumkan AI Credits 500 credit per bulan seharga 500 dolar bila ditagih tahunan, atau 1,30 dolar per credit on-demand, dengan credit tak terpakai di-reset tiap bulan, dan memperkirakan Bits Investigation sekitar 6,5 credit per autonomous investigation, dengan catatan pemakaian aktual bervariasi. Halaman itu tidak menyebut model mana yang ada di balik estimasi tersebut.

Berikut hitungan yang akan saya jalankan sebelum mengaktifkan auto-investigation, hanya dengan angka yang dipublikasikan itu. Ini sketsa budget, dan argumen costFactor adalah thought experiment tentang model yang lebih murah, bukan harga Datadog.

// Figures from datadoghq.com/pricing, read 2026-10-17. Estimates, not quotes.
const CREDITS_PER_INVESTIGATION = 6.5;   // page: ~6.5 credits per autonomous investigation
const BUNDLE_CREDITS = 500;              // page: 500 credits per month ...
const BUNDLE_USD = 500;                  // ... for $500, billed annually
const ON_DEMAND_USD_PER_CREDIT = 1.3;    // page: on-demand rate beyond the bundle

function monthlyUsd(alertsPerDay, autoShare, costFactor = 1) {
  const investigations = alertsPerDay * 30 * autoShare;
  const credits = investigations * CREDITS_PER_INVESTIGATION * costFactor;
  const overage = Math.max(0, credits - BUNDLE_CREDITS);
  return BUNDLE_USD + overage * ON_DEMAND_USD_PER_CREDIT;
}

// 20 alerts a day, all auto-investigated: 600 investigations = 3,900 credits
// -> 500 bundled + 3,400 on demand = $500 + $4,420 = $4,920 a month
console.log(monthlyUsd(20, 1));

// Thought experiment: the same load if per-investigation cost fell 4x.
// This is NOT a Datadog price. It shows why the claim matters at volume.
console.log(monthlyUsd(20, 1, 0.25));

Inilah bentuk nyata dari klaimnya. Pada volume rendah, bundle menelan perbedaannya dan tidak ada yang sadar. Pada volume ketika Anda menginvestigasi setiap transisi alert, credit per investigasi mendominasi tagihan, sehingga model yang memangkasnya beberapa kali lipat menggeser satu pos anggaran, bukan sekadar pembulatan. Apakah Datadog meneruskan penghematan itu adalah keputusan harga yang tidak dibahas post-nya.

Di mana klaimnya masih tipis

Kegagalan yang layak diketahui ada di cerita pelatihan, dan Datadog melaporkannya dengan jujur. Ketika mereka melatih langsung dengan sinyal judge yang jarang, model belajar mengurangi paparan penalti dengan menginvestigasi lebih sedikit dan mengklaim lebih sedikit, bentuk reward hacking. Rubrik granular yang lebih rapat menaikkan skornya sendiri tanpa memperbaiki hasil AlertEval. Solusinya reward hybrid, dan pelajarannya berlaku umum: metrik yang menghukum temuan spurious, bila dioptimalkan, akan memberi Anda investigator yang penakut.

Batas lainnya ada pada buktinya. Semua hasil akurasi dan biaya bersifat internal atau self-reported, tanpa replikasi independen yang dikutip. Tidak ada data latency atau failure rate. Skor adalah kesesuaian dengan penjelasan referensi, bukan penyelesaian insiden. Preview terbatas pada tim Datadog sendiri dan sekelompok kecil pelanggan. Post-nya sendiri menyebut cakupan kegagalan yang lebih luas sebagai pekerjaan ke depan, yang berarti cakupan saat ini lebih sempit daripada seluruh ruang insiden.

Ada satu caveat lagi yang akan saya letakkan di samping benchmark: skenario latihnya hasil simulasi, sedangkan evaluasinya pada insiden nyata. Ketidakcocokan itu disengaja, dan itu argumen terkuat bahwa perilaku yang dipelajari berlaku di dunia nyata. Itu juga berarti model sudah melihat tools dan pola kegagalan berbentuk Datadog, jadi perilakunya pada stack yang tidak lazim adalah bagian yang tidak dicakup angka yang dipublikasikan.

Seperti apa investigasi yang baik: kasus Postgres

Case study dalam report adalah bagian yang paling jelas, karena menunjukkan apa yang harus dilakukan seorang investigator. Alert-nya: seluruh 30 worker autovacuum Postgres sibuk lebih dari satu jam sementara dead rows terus naik. Penyebabnya berjarak lima lompatan kausal: node drain Kubernetes mengeluarkan sebuah read replica sekitar dua jam sebelum alert dan menghapus disk lokalnya, replacement-nya naik dengan disk kosong, dan primary mempertahankan replication slot lama sehingga cleanup horizon tertahan.

Investigasinya, seperti ditunjukkan figure report, menguji penyebab dari runbook lebih dulu, melihat rows read naik 10× sementara jumlah query datar sehingga write spike disingkirkan, tidak menemukan idle transaction dalam empat jam dan lag replica di bawah 4 detik, lalu mengikuti replica pengganti yang mengulang permintaan segment write-ahead log yang hilang tiap 9 detik, dan mengaitkannya dengan node drain 10 menit sebelum onset. Traces hanya menunjukkan error gRPC yang tidak terkait dan dikesampingkan. Rekomendasi pemulihan Datadog: drop slot dan rebuild replica. Berikut query yang saya jalankan manual untuk memeriksa rantai yang sama.

-- Are the autovacuum workers all busy? (compare with SHOW autovacuum_max_workers)
SELECT count(*) FROM pg_stat_activity WHERE backend_type = 'autovacuum worker';

-- Dead rows that vacuum cannot remove
SELECT relname, n_dead_tup FROM pg_stat_user_tables ORDER BY n_dead_tup DESC LIMIT 10;

-- Does a replication slot pin the cleanup horizon? Inactive slots with an old
-- xmin or a large retained_wal are the suspects.
SELECT slot_name, active, xmin, catalog_xmin,
       pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn)) AS retained_wal
FROM pg_replication_slots
ORDER BY pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn) DESC;

-- Only after confirming the replica it belonged to is gone for good:
-- SELECT pg_drop_replication_slot('slot_name_from_above');

Perhatikan apa yang membuat ini sulit bagi model tetapi murah diperiksa manusia: query yang tepat baru jelas setelah Anda tahu node drain terjadi. Itulah argumen untuk membiarkan model murah berjalan di setiap alert sebagai first responder, dan juga untuk tetap menempatkan manusia pada langkah drop slot.

Yang dikerjakan hari Senin

Perlakukan Scout sebagai alasan untuk bersiap, bukan alasan untuk membeli. Tidak ada langkah di bawah yang memerlukan akses preview, dan setiap langkah memperbaiki cara Anda menilai AI investigator mana pun.

1. Pilih 20 alert lama yang punya postmortem tertulis, sehingga root cause-nya diketahui dan disepakati.
2. Ubah masing-masing menjadi test case berisi alert, root cause, query yang mengungkapnya, dan daftar red herring, dengan bentuk seperti di bawah.
3. Jalankan investigator yang Anda pakai minimal tiga kali per kasus dan catat seberapa sering ia berhasil sedikitnya sekali dan seberapa sering berhasil setiap kali.
4. Nilai temuan pada penyebab langsung dan penyebab yang lebih dalam secara terpisah, dan kurangi untuk klaim yang tidak didukung bukti.
5. Jalankan script budget pada volume alert nyata Anda, lalu aktifkan Auto-Investigate pada beberapa monitor yang didukung dan baca tab Reports untuk jumlah investigasi dan mean time to conclusion sebelum diperluas.

{
  "id": "pg-autovacuum-stale-slot",
  "alert": "All autovacuum workers busy for over 1h on orders-db",
  "root_cause": "Replica evicted by node drain; its replication slot pins the cleanup horizon",
  "deeper_findings": ["node drain ~2h before alert", "replacement replica has empty disk"],
  "evidence_queries": ["pg_replication_slots", "vacuum completion logs", "k8s events: node drain"],
  "red_herrings": ["unrelated gRPC error in traces", "normal write rate"],
  "judge_rubric": {
    "immediate_cause": 40,
    "deeper_cause": 40,
    "penalty_per_unsupported_claim": 10,
    "penalty_for_contradicting_reference": 20
  }
}

Bobot rubrik di atas adalah milik saya, diadaptasi dari properti yang menurut report diberi reward dan penalti oleh DeepJudge, bukan angka Datadog. Sesuaikan dengan biaya sebuah jawaban salah bagi tim Anda.

Scout tidak mengubah apa itu investigasi; ia mengubah seberapa sering Anda sanggup menjalankannya. Aturan yang saya bawa: baca setiap klaim AI SRE sebagai rasio ditambah rubrik ditambah ukuran sampel, dan ukur insiden Anda sendiri sebelum membiarkan rasio biaya menentukan berapa banyak alert yang diinvestigasi otomatis.