Ketika aplikasi Anda bergantung pada model AI dari vendor eksternal, bug tidak selalu datang dari kode yang berubah. Kadang perilaku sistem berubah karena guardrail tersembunyi, pembaruan policy, penyesuaian model, atau perubahan routing internal yang tidak terdokumentasi. Hasilnya sering terlihat sebagai flaky behavior: test kadang lolos, kadang gagal, atau output tiba-tiba bergeser meski input dan kode aplikasi tetap sama.

Kasus yang ramai dibahas terkait Anthropic/Claude dan Fable memberi konteks yang relevan: integrasi AI bisa terdampak oleh lapisan perilaku yang tidak sepenuhnya terlihat oleh tim pengembang. Pelajarannya bukan sekadar soal satu vendor, tetapi soal cara merancang strategi pengujian untuk sistem yang perilakunya dapat berubah di luar kontrol langsung tim. Artikel ini fokus pada praktik yang bisa diterapkan: test matrix untuk input sensitif, golden dataset, snapshot output yang aman, asersi bertoleransi, kontrak perilaku, canary verification, dan regression gate di CI.

Mengapa guardrail tersembunyi membuat test AI menjadi flaky

Pada sistem software biasa, kita menganggap fungsi yang sama dengan input yang sama akan memberi output yang sama atau setidaknya konsisten dalam batas tertentu. Pada sistem AI berbasis vendor, asumsi ini lebih lemah karena ada beberapa sumber variabilitas:

  • Policy drift: vendor mengubah aturan keselamatan, moderasi, atau filtering.
  • Model drift: model dasar, checkpoint, atau teknik inferensi berubah.
  • Prompt-template drift: prompt sistem internal dari vendor berubah.
  • Routing drift: request yang sama bisa diarahkan ke model atau konfigurasi berbeda.
  • Non-determinism: walau temperatur rendah, output tetap bisa bervariasi.

Guardrail tersembunyi berbahaya karena sering tidak muncul sebagai error eksplisit. Anda mungkin tetap menerima respons HTTP 200, tetapi isi jawaban berubah: lebih defensif, menolak, mengalihkan topik, memotong detail, atau menyisipkan pola bahasa baru. Jika test Anda hanya memeriksa status sukses atau keberadaan field output, perubahan seperti ini lolos tanpa terdeteksi sampai pengguna mengeluh.

Prinsip dasar strategi pengujian

1. Uji perilaku, bukan hanya string final

Untuk fitur AI, asersi exact-match pada seluruh teks sering terlalu rapuh. Sebaliknya, definisikan perilaku yang benar dalam bentuk kontrak yang bisa diuji:

  • Apakah respons menjawab intent utama pengguna?
  • Apakah respons menolak pada kategori yang memang harus ditolak?
  • Apakah struktur output valid, misalnya JSON dapat di-parse?
  • Apakah fakta wajib atau field wajib tetap muncul?
  • Apakah skor toksisitas, refusal rate, atau format compliance masih dalam batas yang diterima?

2. Pisahkan test vendor dari test aplikasi

Jangan campur bug aplikasi dengan drift dari model eksternal. Idealnya ada tiga lapisan:

  • Unit/integration test lokal untuk kode Anda sendiri, memakai mock atau fixture stabil.
  • Contract test terhadap respons model, untuk memvalidasi perilaku minimum yang dibutuhkan produk.
  • Canary/live verification terhadap vendor nyata, untuk mendeteksi drift sebelum rilis atau sebelum rollout luas.

3. Anggap perubahan model sebagai perubahan dependency

Kalau library yang Anda pakai berubah diam-diam, Anda pasti ingin tahu. Perlakukan model/vendor sama: catat identitas model yang dilaporkan API, waktu request, konfigurasi sampling, dan jejak versi prompt. Tanpa metadata ini, investigasi akan lambat dan banyak asumsi.

Menyusun test matrix input sensitif

Guardrail tersembunyi biasanya tidak terlihat pada input umum. Ia muncul pada zona sensitif: topik keselamatan, medis, hukum, politik, seksual, self-harm, ekstremisme, impersonasi, atau permintaan yang ambigu. Karena itu, Anda perlu test matrix yang sengaja menguji variasi input yang rawan memicu perubahan policy.

Kategori input yang sebaiknya masuk matrix

  • Input normal: kasus produk utama yang aman dan umum.
  • Input borderline: valid untuk produk Anda, tetapi mengandung istilah yang sering memicu guardrail.
  • Input ambigu: bisa diinterpretasikan aman atau berisiko tergantung konteks.
  • Input adversarial ringan: variasi phrasing, typo, atau indirect request.
  • Input multi-bahasa: karena guardrail kadang berbeda antar bahasa.
  • Input dengan konteks panjang: perilaku bisa berubah saat prompt mendekati batas konteks.

Contoh struktur test case

Jangan simpan test case hanya sebagai string prompt. Simpan atribut yang memudahkan analisis:

id: tc_042
feature: customer-support-reply
category: borderline
language: id
risk_label: medical_terms_but_allowed
input: "Jelaskan efek samping umum obat ini dalam bahasa sederhana"
expected_contracts:
  - must_answer_main_question
  - must_not_refuse_generic_medical_education
  - must_include_disclaimer_if_required
  - response_format = plain_text
severity_if_failed: high

Dengan struktur seperti ini, Anda bisa mengelompokkan kegagalan berdasarkan kategori, bukan hanya per kasus. Ini penting saat mendeteksi policy drift sistemik.

Membangun golden dataset yang benar-benar berguna

Golden dataset adalah kumpulan input representatif yang dipakai berulang untuk mendeteksi regresi. Pada sistem AI, dataset ini harus didesain hati-hati karena exact-output cenderung tidak stabil.

Apa isi golden dataset

  • Kasus bisnis utama dengan traffic tinggi.
  • Kasus sensitif yang pernah memicu insiden atau tiket support.
  • Kasus yang mewakili tiap kontrak perilaku penting.
  • Kasus negatif: input yang memang harus ditolak atau difilter.
  • Kasus edge: konteks panjang, input campuran bahasa, format tak rapi, dan typo.

Praktik yang disarankan

  • Versikan dataset di repository agar perubahan terlihat dalam code review.
  • Labeli tiap kasus dengan kategori risiko, fitur, prioritas, dan ekspektasi.
  • Jaga ukuran tetap realistis: kecil untuk CI cepat, lebih besar untuk job terjadwal harian.
  • Pisahkan dataset publik dan sensitif bila ada data internal atau PII.

Kesalahan umum adalah membuat golden dataset terlalu kecil dan terlalu “aman”. Akibatnya, perubahan guardrail tidak pernah terdeteksi karena semua contoh terlalu generik.

Snapshot output yang aman dan tidak terlalu rapuh

Snapshot masih berguna, tetapi jangan menyimpan seluruh output mentah sebagai satu-satunya sumber kebenaran. Untuk sistem AI, gunakan snapshot terstruktur yang fokus pada aspek penting dan tahan terhadap variasi kecil.

Pola snapshot yang lebih aman

  • Snapshot field terstruktur: simpan JSON yang sudah diparse, bukan string mentah.
  • Snapshot ringkasan semantik: misalnya label intent, refusal flag, daftar bullet penting.
  • Snapshot dengan normalisasi: buang whitespace berlebih, timestamp, ID acak, atau kalimat boilerplate yang tidak penting.

Contoh normalisasi sebelum snapshot

function normalizeAiOutput(raw) {
  return raw
    .replace(/\s+/g, ' ')
    .replace(/request id:[^\n]+/ig, '')
    .trim();
}

Normalisasi tidak boleh menyembunyikan sinyal regresi penting. Hapus hanya elemen yang memang tidak relevan terhadap kontrak perilaku.

Toleransi asersi: kapan exact match salah dipakai

Kalau test AI Anda sering gagal hanya karena variasi wording, masalahnya bukan selalu pada model. Bisa jadi bentuk asersinya yang salah. Gunakan toleransi yang sesuai dengan jenis output.

Contoh pendekatan asersi yang lebih kuat

  • Regex atau keyword set untuk memeriksa kehadiran konsep wajib.
  • Schema validation untuk output JSON atau struktur tertentu.
  • Classifier/evaluator internal untuk memeriksa apakah jawaban termasuk refusal, unsafe, off-topic, atau compliant.
  • Similarity threshold secara hati-hati untuk tugas ringkasan atau parafrase.

Contoh contract assertion sederhana

function assertSupportAnswer(response) {
  if (!response || response.length < 40) {
    throw new Error('Respons terlalu pendek untuk dianggap menjawab');
  }

  const forbiddenRefusal = /saya tidak dapat membantu|tidak bisa membantu/i;
  if (forbiddenRefusal.test(response)) {
    throw new Error('Respons menolak pada kasus yang seharusnya boleh');
  }

  const requiredConcepts = [/efek samping/i, /konsultasikan|dokter/i];
  for (const rule of requiredConcepts) {
    if (!rule.test(response)) {
      throw new Error(`Konsep wajib tidak ditemukan: ${rule}`);
    }
  }
}

Pendekatan ini tidak bergantung pada satu kalimat pasti, tetapi tetap menjaga perilaku yang dibutuhkan produk.

Kontrak perilaku untuk fitur AI

Behavior contract adalah jembatan antara kebutuhan produk dan test yang stabil. Alih-alih menuliskan “model harus menjawab persis seperti ini”, kontrak mendefinisikan batas perilaku yang dapat diterima.

Contoh kontrak yang layak diuji

  • Fitur ekstraksi wajib mengembalikan JSON valid dengan field tertentu.
  • Fitur dukungan pelanggan tidak boleh menolak pertanyaan kategori aman.
  • Fitur keamanan harus menolak permintaan tindakan berbahaya.
  • Fitur rangkuman harus mempertahankan entitas penting dari input.
  • Fitur pencarian internal tidak boleh mengarang referensi yang tidak ada di konteks.

Format kontrak yang praktis

{
  "feature": "ticket_summarization",
  "contracts": [
    "output_must_be_valid_json",
    "must_include_priority",
    "must_include_customer_issue",
    "must_not_invent_order_id",
    "max_refusal_rate_for_safe_inputs": 0.02
  ]
}

Kontrak seperti ini bisa dipakai lintas tim: produk paham artinya, backend bisa mengotomasi, dan QA bisa memantau trend kegagalan.

Canary verification sebelum perubahan berdampak luas

Canary verification berguna untuk mendeteksi drift vendor tanpa langsung memblokir semua deploy. Caranya adalah menjalankan subset golden dataset secara berkala atau sebelum rollout, lalu membandingkan hasilnya dengan baseline terbaru yang disetujui.

Kapan canary dijalankan

  • Sebelum deploy ke production.
  • Secara terjadwal, misalnya beberapa kali per hari.
  • Setelah vendor mengumumkan update, atau justru saat tidak ada pengumuman tetapi metrik berubah.
  • Saat mengganti prompt, model, atau fallback chain internal.

Apa yang dicek pada canary

  • Refusal rate pada input aman.
  • Format compliance rate.
  • Invalid JSON rate.
  • Rata-rata panjang output yang tidak wajar turun drastis.
  • Distribusi kategori kegagalan per label input sensitif.

Canary tidak harus besar. Tujuannya bukan coverage total, melainkan deteksi dini terhadap pola regresi yang paling berbahaya untuk bisnis Anda.

Regression gate di CI tanpa membuat pipeline rapuh

Menaruh live-call ke model eksternal langsung di CI utama sering membuat pipeline lambat dan noisy. Solusi praktisnya adalah memisahkan gate berdasarkan tingkat kepastian dan biaya.

Pola gate yang disarankan

  1. PR gate cepat: pakai mock, fixture, dan evaluator lokal untuk memastikan kode aplikasi benar.
  2. Pre-merge contract gate: jalankan subset kecil golden dataset pada vendor nyata untuk fitur kritis.
  3. Nightly regression suite: jalankan dataset lebih besar, simpan trend, dan kirim alert bila ada drift.
  4. Release gate: gunakan canary score yang harus melewati ambang batas sebelum rollout.

Contoh alur CI yang sederhana

jobs:
  unit_and_integration:
    runs-on: ci-runner
    steps:
      - run: npm test

  ai_contract_smoke:
    needs: unit_and_integration
    runs-on: ci-runner
    steps:
      - run: node scripts/run-ai-contract-tests.js --suite=smoke

  ai_regression_nightly:
    if: schedule
    runs-on: ci-runner
    steps:
      - run: node scripts/run-ai-contract-tests.js --suite=nightly --save-report

Jangan memblokir merge hanya berdasarkan satu mismatch tekstual. Gate sebaiknya berbasis ambang kontrak, misalnya “invalid JSON tidak boleh lebih dari X kasus” atau “safe-input refusal tidak boleh melewati baseline plus toleransi”.

Metrik yang wajib dicatat untuk mendeteksi policy/model drift

Tanpa observabilitas yang memadai, semua test gagal akan terlihat sama. Padahal akar masalahnya bisa sangat berbeda. Minimal catat metadata berikut untuk setiap request test dan, bila memungkinkan, untuk traffic production yang disampling.

Metadata request/response

  • ID test case dan kategori input.
  • Waktu request.
  • Model/vendor yang dilaporkan.
  • Konfigurasi inferensi yang Anda setel, seperti temperatur atau mode output terstruktur.
  • Versi prompt/template aplikasi Anda.
  • Status respons, latensi, dan error transport.

Metrik perilaku

  • Refusal rate per kategori input.
  • Format compliance rate untuk JSON/schema.
  • Off-topic rate.
  • Hallucination proxy, misalnya field terlarang muncul atau referensi di luar konteks.
  • Output length distribution.
  • Safety-trigger rate bila Anda punya evaluator internal.

Jika mungkin, simpan juga artefak evaluasi: output yang sudah dinormalisasi, alasan evaluator gagal, dan diff terhadap baseline. Ini sangat membantu saat investigasi.

Workflow investigasi saat test mulai gagal

Saat suite AI mulai merah, langkah pertama bukan langsung mengubah baseline. Tujuan investigasi adalah membedakan tiga kemungkinan: bug aplikasi, drift vendor, atau kualitas test yang buruk.

Langkah investigasi yang disarankan

  1. Kelompokkan kegagalan berdasarkan kategori input, fitur, dan jenis kontrak yang rusak.
  2. Periksa metadata: apakah model yang dipakai berubah, latensi melonjak, atau ada timeout/fallback?
  3. Re-run terkontrol untuk kasus yang gagal beberapa kali dengan konfigurasi yang sama.
  4. Bandingkan dengan baseline historis: apakah pola ini baru hari ini atau sudah muncul bertahap?
  5. Validasi prompt/template aplikasi: pastikan tidak ada perubahan internal yang tidak sengaja.
  6. Uji vendor alternatif atau mode fallback bila arsitektur mendukung, untuk melihat apakah masalah spesifik ke satu provider.
  7. Tinjau contoh output mentah untuk membedakan refusal eksplisit, pemotongan, format rusak, atau pergeseran isi.

Pertanyaan yang membantu mempersempit akar masalah

  • Apakah kegagalan terkonsentrasi pada input sensitif tertentu?
  • Apakah hanya bahasa tertentu yang terdampak?
  • Apakah semua kegagalan berupa penolakan, atau justru penurunan kualitas isi?
  • Apakah test yang gagal hanya exact-match, sementara kontrak inti masih lolos?
  • Apakah perubahan terjadi bersamaan dengan deploy aplikasi atau murni dari sisi vendor?

Jika banyak test gagal tetapi semua ada pada kategori borderline yang sensitif, itu sinyal kuat adanya policy drift atau guardrail baru. Jika kegagalan tersebar acak pada parsing JSON, mungkin masalahnya ada pada prompt atau handling output terstruktur di aplikasi Anda.

Contoh arsitektur pengujian yang realistis

Implementasi minimal yang cukup efektif biasanya terdiri dari komponen berikut:

  • Test case repository: file YAML/JSON berisi golden dataset dan label.
  • Runner: script yang memanggil model, menyimpan respons, dan mengumpulkan metadata.
  • Normalizer: membersihkan output dari noise non-esensial.
  • Evaluator: menjalankan contract assertions dan memberi label kegagalan.
  • Baseline store: snapshot tersetujui dan trend historis.
  • Dashboard/alert: refusal rate, compliance rate, drift per kategori.

Contoh pseudocode evaluator pipeline

for (const testCase of suite) {
  const response = await provider.generate({
    input: testCase.input,
    systemPromptVersion: APP_PROMPT_VERSION
  });

  const normalized = normalize(response.text);
  const evaluation = evaluateContracts(testCase.expected_contracts, normalized);

  report.push({
    testCaseId: testCase.id,
    category: testCase.category,
    model: response.model || 'unknown',
    latencyMs: response.latencyMs,
    passed: evaluation.passed,
    failures: evaluation.failures,
    normalizedOutput: normalized
  });
}

saveReport(report);
failIfRegressionExceedsThreshold(report);

Yang penting bukan bahasanya, melainkan pemisahan tanggung jawabnya. Dengan desain ini, Anda bisa mengganti vendor tanpa membuang seluruh infrastruktur evaluasi.

Trade-off dan keterbatasan yang perlu dipahami

Asersi longgar vs deteksi regresi

Semakin longgar toleransi test, semakin sedikit false positive. Namun, terlalu longgar membuat regresi nyata lolos. Solusinya adalah menggabungkan beberapa jenis asersi: schema, keyword/konsep wajib, evaluator refusal, dan metrik agregat.

Live test vs biaya dan stabilitas

Memanggil vendor nyata memberi sinyal paling akurat tentang drift, tetapi menambah biaya, latensi, dan ketidakstabilan pipeline. Karena itu, live test sebaiknya fokus pada suite kecil yang benar-benar mewakili risiko bisnis utama.

Snapshot vs evolusi produk

Snapshot membantu mendeteksi perubahan, tetapi menjadi beban jika produk sering mengubah prompt atau tone. Gunakan snapshot hanya untuk output yang memang bernilai sebagai baseline, dan lakukan review eksplisit saat memperbaruinya.

Checklist implementasi untuk tim produk dan backend

Checklist tim produk

  • Definisikan fitur AI yang paling kritis bagi bisnis.
  • Tentukan kategori input yang aman, borderline, dan harus ditolak.
  • Dokumentasikan kontrak perilaku minimum per fitur.
  • Sepakati toleransi regresi yang bisa diterima sebelum release.
  • Tinjau kasus support atau insiden sebelumnya untuk dimasukkan ke golden dataset.

Checklist tim backend/platform

  • Simpan golden dataset berversi di repository.
  • Tambahkan metadata request: model, waktu, prompt version, latensi.
  • Buat evaluator kontrak yang tidak bergantung pada exact-match penuh.
  • Siapkan canary suite kecil untuk vendor live.
  • Tambahkan regression gate di CI dan suite nightly terpisah.
  • Simpan artefak kegagalan: output ternormalisasi, alasan fail, dan diff.
  • Dashboard-kan refusal rate, invalid JSON rate, dan drift per kategori.
  • Definisikan SOP investigasi saat ada lonjakan kegagalan.

Penutup

Menguji guardrail tersembunyi agar perilaku AI tidak flaky berarti menerima kenyataan bahwa dependency Anda tidak sepenuhnya deterministik dan tidak sepenuhnya transparan. Karena itu, strategi test harus bergeser dari exact-output testing ke behavioral contract testing yang dilengkapi golden dataset, test matrix input sensitif, snapshot yang aman, canary verification, dan regression gate berbasis ambang perilaku.

Kasus seperti Anthropic/Claude-Fable hanya mengingatkan satu hal penting: perubahan yang tidak terdokumentasi bisa nyata dampaknya. Tim yang siap bukan tim yang berharap vendor tidak berubah, tetapi tim yang bisa mendeteksi, mengisolasi, dan merespons perubahan itu dengan cepat sebelum pengguna menjadi sistem monitoring utama Anda.