Verifikasi Migrasi Model AI di Produksi tanpa Menambah Flaky Test

Verifikasi migrasi model AI di produksi tanpa menambah flaky test berarti mengubah cara tim menguji: jangan bergantung pada kecocokan teks persis, tetapi ukur perilaku yang benar-benar penting untuk sistem. Saat model lama diganti dengan model baru, misalnya dalam konteks migrasi agen AI ke model yang lebih mutakhir seperti GPT-5.6, risiko utamanya bukan hanya akurasi turun, tetapi juga format output berubah, latency naik, biaya membengkak, atau error rate meningkat.

Pendekatan yang lebih aman adalah memecah verifikasi ke beberapa lapisan: golden dataset untuk membandingkan kualitas, contract test untuk output terstruktur, metrik operasional untuk latency/biaya/error rate, dan rollout bertahap lewat shadow traffic serta canary. Dengan begitu, tim backend bisa mengambil keputusan go/no-go berdasarkan data, bukan impresi dari beberapa prompt manual.

Mengapa test migrasi model AI sering flaky

Penyebab utama flaky test pada sistem berbasis model generatif adalah asumsi bahwa output harus selalu identik. Dalam praktiknya, model baru bisa menghasilkan jawaban yang setara secara makna tetapi berbeda susunan kalimatnya. Jika test membandingkan string mentah secara penuh, hasilnya mudah berubah walau kualitas sebenarnya tidak menurun.

Beberapa sumber flakiness yang umum:

• Nondeterminism inferensi: sampling, temperature, atau perubahan internal model membuat variasi output tetap mungkin terjadi.
• Prompt rendering dinamis: urutan konteks, timestamp, atau metadata request membuat input tidak identik.
• Tool calling atau retrieval yang berubah: sumber data eksternal dapat memberikan isi berbeda antar-run.
• Assertion terlalu ketat: memaksa jawaban sama persis alih-alih memverifikasi struktur, fakta penting, atau keputusan bisnis.
• Dataset evaluasi buruk: contoh terlalu sedikit, tidak representatif, atau tidak dipisah berdasarkan jenis tugas.

Karena itu, target verifikasi migrasi bukan “apakah semua output sama dengan model lama”, melainkan “apakah model baru memenuhi kontrak sistem dan tidak menurunkan metrik yang disepakati”.

Workflow verifikasi migrasi model AI di produksi

1. Bekukan baseline sebelum migrasi

Sebelum membandingkan model lama dengan model baru, bekukan dulu baseline. Simpan artefak berikut:

• Template prompt dan variabel input yang dipakai produksi.
• Golden dataset yang mewakili trafik nyata.
• Metrik baseline: success rate, schema validity, latency p50/p95, biaya per request, dan error rate.
• Versi evaluator atau rule yang dipakai untuk menilai output.

Tanpa baseline yang dibekukan, hasil evaluasi mudah bias karena perubahan prompt, parser, atau evaluator terjadi bersamaan dengan perubahan model.

2. Bangun golden dataset dari kasus produksi nyata

Golden dataset adalah kumpulan request yang mewakili beban kerja penting di produksi. Sumber terbaik biasanya berasal dari log request yang sudah dianonimkan, lalu dikelompokkan berdasarkan use case.

Contoh kategori untuk agen AI backend:

• Pertanyaan sederhana dengan jawaban langsung.
• Permintaan yang memerlukan output JSON terstruktur.
• Kasus multi-step dengan tool calling.
• Input ambigu atau noisy.
• Kasus edge seperti konteks panjang, field kosong, atau instruksi konflik.

Jangan hanya mengambil contoh yang “bagus”. Sertakan juga kasus yang sering gagal, karena justru di situlah regresi sering muncul.

Praktik yang berguna: beri label prioritas pada setiap contoh, misalnya critical, important, dan nice-to-have. Acceptance threshold untuk kasus critical sebaiknya lebih ketat.

3. Pisahkan evaluasi kualitas dari evaluasi reliabilitas

Banyak tim mencampur semua sinyal dalam satu angka agregat. Ini berbahaya. Kualitas jawaban dan reliabilitas sistem perlu dievaluasi terpisah:

• Kualitas: relevansi, ketepatan keputusan, kelengkapan field penting, dan tingkat keberhasilan task.
• Reliabilitas: schema validity, timeout, retry rate, parse failure, latency, biaya, dan rate limit impact.

Model baru bisa terlihat lebih “cerdas”, tetapi kalau output JSON lebih sering invalid, migrasi tetap berisiko untuk sistem produksi.

Golden dataset: bandingkan model lama vs baru dengan cara yang stabil

Apa yang sebaiknya diukur

Alih-alih membandingkan string mentah, definisikan evaluator yang lebih tahan variasi:

• Exact match hanya untuk field deterministik seperti enum, boolean, atau ID tool.
• Semantic match untuk jawaban natural language, dinilai oleh rule-based evaluator atau model evaluator dengan rubric yang jelas.
• Task success untuk agen, misalnya apakah intent terdeteksi benar dan aksi yang dipilih sesuai.
• Schema validity untuk output JSON atau format terstruktur.
• Safety/guardrail compliance bila sistem memiliki kebijakan tertentu.

Jika memungkinkan, gunakan evaluator sederhana dan dapat diaudit. Model-as-judge bisa membantu, tetapi jangan menjadi satu-satunya sumber kebenaran untuk kasus bisnis kritis.

Contoh struktur data evaluasi

{
  "case_id": "ticket-routing-042",
  "priority": "critical",
  "input": {
    "user_message": "Tolong refund pesanan saya yang dobel",
    "context": {
      "channel": "chat",
      "locale": "id-ID"
    }
  },
  "expected": {
    "intent": "refund_request",
    "requires_human": false,
    "response_schema": "support_action_v1"
  },
  "checks": [
    "intent_match",
    "json_schema_valid",
    "required_fields_present"
  ]
}

Struktur seperti ini lebih tahan perubahan wording dibanding menyimpan satu string jawaban ideal.

Contoh tabel metrik perbandingan

Angka di atas hanya contoh format. Nilai threshold harus ditentukan dari kebutuhan bisnis dan SLA sistem Anda.

Contract test untuk output terstruktur

Fokus pada kontrak, bukan wording

Jika model menghasilkan JSON, argumen tool, atau payload internal, maka lapisan terpenting adalah contract test. Uji bahwa output:

• Valid terhadap schema.
• Memiliki field wajib.
• Menggunakan tipe data yang benar.
• Memenuhi batasan domain, misalnya enum valid atau skor berada dalam rentang tertentu.
• Tidak mengandung field tambahan yang membingungkan parser downstream, jika sistem mengharuskan schema ketat.

Pendekatan ini mengurangi flakiness karena variasi natural language tidak lagi menjadi sumber kegagalan utama.

Contoh schema dan validator sederhana

from jsonschema import validate, ValidationError

SUPPORT_ACTION_SCHEMA = {
    "type": "object",
    "required": ["intent", "priority", "reply_to_user"],
    "properties": {
        "intent": {"type": "string", "enum": ["refund_request", "order_status", "other"]},
        "priority": {"type": "string", "enum": ["low", "normal", "high"]},
        "reply_to_user": {"type": "string"},
        "requires_human": {"type": "boolean"}
    },
    "additionalProperties": False
}

def assert_contract(payload: dict) -> None:
    validate(instance=payload, schema=SUPPORT_ACTION_SCHEMA)
    if len(payload["reply_to_user"].strip()) == 0:
        raise AssertionError("reply_to_user tidak boleh kosong")

# di test
try:
    assert_contract(model_output)
except ValidationError as e:
    raise AssertionError(f"Schema invalid: {e.message}")

Schema validation seperti ini sangat efektif untuk mencegah regresi saat model baru menjadi lebih “kreatif” dari yang diinginkan sistem.

Kesalahan umum pada contract test

• Terlalu longgar: schema valid, tetapi field penting kosong atau tidak usable.
• Terlalu ketat di tempat yang salah: memaksa seluruh string sama persis padahal yang penting hanya intent dan action.
• Tidak menguji parser downstream: output lolos schema, tetapi gagal diproses service berikutnya.

Karena itu, tambahkan satu lapisan lagi: contract-to-consumer test. Artinya, ambil output model, lalu jalankan parser atau service konsumen yang sama dengan di produksi.

Menangani nondeterminism agar test tidak flaky

Kurangi variasi input dan konfigurasi

Tidak semua nondeterminism bisa dihilangkan, tetapi bisa dikendalikan. Praktik yang biasanya membantu:

• Gunakan prompt template yang dibekukan selama periode evaluasi.
• Hindari field dinamis yang tidak relevan seperti timestamp atau request ID di prompt.
• Bekukan urutan dokumen retrieval bila memungkinkan.
• Gunakan konfigurasi inferensi yang konsisten selama eksperimen.
• Untuk test CI, prioritaskan task dengan output terstruktur atau assertion berbasis properti.

Jika sistem menggunakan retrieval atau tool eksternal, pertimbangkan mode replay untuk test: input, dokumen retrieval, dan respons tool direkam lalu diputar ulang. Ini membuat perbandingan model lebih adil karena variabel eksternal tetap sama.

Gunakan assertion berbasis properti

Daripada memeriksa seluruh kalimat, gunakan assertion seperti:

• Harus mengandung intent yang benar.
• Harus mengisi semua field wajib.
• Tidak boleh menyebut kebijakan yang bertentangan.
• Harus memilih tool A untuk kondisi tertentu.
• Panjang output maksimal sekian karakter.

Model generatif lebih cocok diuji dengan property-based expectations dibanding snapshot tekstual penuh.

Jalankan beberapa sampel hanya jika memang perlu

Untuk kasus yang sangat sensitif terhadap variasi output, Anda bisa menjalankan beberapa kali per test case lalu menilai distribusinya, bukan satu output tunggal. Namun ini ada trade-off:

• Lebih mahal dan lebih lambat.
• Bisa memberi sinyal stabilitas yang lebih realistis.
• Tidak cocok untuk semua test CI; lebih tepat untuk evaluasi pre-release atau nightly build.

Untuk pipeline harian, gunakan subset golden dataset yang kecil tetapi kritis, dan simpan evaluasi penuh untuk job terjadwal.

Evaluasi latency, biaya, dan error rate

Metrik operasional yang wajib dipantau

Migrasi model yang lolos evaluasi kualitas belum tentu layak dirilis. Untuk produksi, minimal ukur:

• Latency p50/p95/p99: penting untuk UX dan timeout service downstream.
• Biaya per request atau per task sukses: lebih berguna daripada biaya mentah jika panjang output berubah.
• Error rate: timeout, provider error, rate limit, parse failure, retry exhaustion.
• Token atau ukuran payload: berguna untuk menjelaskan perubahan biaya dan latency.

Idealnya, metrik ini dikumpulkan per use case, bukan hanya agregat total. Satu model bisa bagus untuk klasifikasi singkat, tetapi buruk untuk alur yang memerlukan konteks panjang.

Definisikan acceptance threshold sebelum pengujian

Threshold harus disepakati sebelum hasil dilihat agar keputusan tidak bias. Contohnya:

• Task success untuk kasus critical tidak boleh turun.
• Schema validity minimal sama, atau penurunan maksimal sangat kecil.
• Latency p95 tidak boleh naik lebih dari batas tertentu.
• Biaya per task sukses harus tetap di bawah batas anggaran.
• Error rate total tidak boleh melebihi SLA internal.

Jangan membuat threshold terlalu umum seperti “harus terasa lebih baik”. Tim operasi memerlukan angka yang bisa dipakai untuk keputusan go/no-go.

Shadow traffic dan canary rollout

Shadow traffic untuk membandingkan tanpa risiko user-facing

Pada mode shadow, request produksi tetap dilayani model lama, tetapi salinan request dikirim ke model baru untuk dievaluasi diam-diam. Ini berguna untuk:

• Mengukur perbedaan kualitas pada trafik nyata.
• Menilai latency dan error rate model baru di kondisi produksi.
• Mengumpulkan contoh regresi yang tidak muncul di golden dataset.

Karena hasil model baru tidak dikirim ke user, risiko bisnis lebih rendah. Tantangannya adalah biaya ganda dan kebutuhan sanitasi data yang baik.

Canary rollout untuk validasi bertahap

Setelah shadow traffic terlihat aman, lakukan canary: arahkan sebagian kecil trafik nyata ke model baru. Mulai dari persentase kecil, pantau metrik, lalu naikkan bertahap jika stabil.

Prinsip canary yang baik:

• Gunakan segmen trafik yang representatif, bukan hanya kasus mudah.
• Pastikan rollback cepat bisa dilakukan lewat feature flag atau config routing.
• Pantau metrik per model secara terpisah.
• Simpan sampel request gagal untuk investigasi.

Skema routing sederhana

llm_router:
  default_model: legacy-model
  routes:
    - condition: feature_flag == "ai-model-canary"
      model: new-model
      traffic_percent: 5
  shadow:
    enabled: true
    model: new-model

Nama key di atas hanya ilustrasi. Intinya, tim backend sebaiknya memiliki mekanisme routing yang dapat diubah cepat tanpa deploy besar.

Checklist regresi untuk tim backend

Checklist teknis sebelum release

• Prompt template untuk baseline dan kandidat dibekukan.
• Golden dataset mencakup kasus critical, edge case, dan failure case historis.
• Contract test untuk semua output terstruktur sudah lulus.
• Parser downstream diuji dengan output model baru.
• Latency, biaya, dan error rate dibandingkan terhadap baseline.
• Threshold acceptance sudah terdokumentasi sebelum evaluasi.
• Shadow traffic sudah berjalan dan hasilnya direview.
• Rollback via feature flag atau router sudah diuji.
• Logging cukup untuk membedakan error model, parser, retrieval, dan tool.
• Dashboard observability menampilkan metrik per model.

Checklist CI/CD yang bisa diterapkan

Contoh alur pipeline

# PR pipeline
run_prompt_lint
run_schema_tests
run_golden_subset_eval --dataset critical_cases.json

# nightly pipeline
run_full_golden_eval --dataset all_cases.json
run_cost_latency_report

# pre-release gate
run_shadow_comparison_report
check_acceptance_thresholds
approve_or_block_release

Perintah di atas bersifat generik. Yang penting adalah struktur gatting-nya: ada check cepat untuk PR, evaluasi penuh terjadwal, lalu gate sebelum rollout.

Debugging saat model baru gagal

Kelompokkan kegagalan berdasarkan jenisnya

Jangan langsung menyimpulkan “model baru jelek”. Kelompokkan dulu:

• Format failure: JSON invalid, field hilang, enum salah.
• Reasoning failure: intent salah, tool salah, keputusan salah.
• Retrieval/context failure: model gagal memakai konteks atau prompt tidak cukup jelas.
• Operational failure: timeout, rate limit, retry berlebihan.

Klasifikasi ini mempercepat remediasi. Format failure biasanya bisa dibenahi dengan kontrak yang lebih jelas atau parser yang lebih defensif. Reasoning failure mungkin memerlukan perubahan prompt, dataset, atau bahkan keputusan untuk tidak migrasi.

Bandingkan input render final, bukan prompt template saja

Kesalahan umum lain adalah hanya melihat template prompt. Yang perlu dibandingkan adalah prompt final yang sudah dirender, termasuk dokumen retrieval, tool result, dan metadata yang ikut terkirim. Banyak regresi ternyata berasal dari perubahan konteks, bukan perubahan model inti.

Keputusan go/no-go yang masuk akal

Keputusan release sebaiknya sederhana dan dapat diaudit. Contohnya, model baru boleh masuk produksi jika:

1. Semua contract test lulus.
2. Task success pada kasus critical minimal sama dengan baseline.
3. Latency, biaya, dan error rate berada dalam threshold yang disetujui.
4. Shadow traffic tidak menunjukkan regresi signifikan yang belum dijelaskan.
5. Canary pada porsi trafik kecil stabil selama periode observasi yang ditentukan.
6. Rollback mechanism sudah diuji.

Jika salah satu syarat gagal, hasilnya no-go sampai ada mitigasi yang jelas. Dalam migrasi model AI, keputusan terbaik sering kali bukan “pakai model terbaru sekarang”, tetapi “tunda rollout sampai kontrak, evaluasi, dan observability cukup kuat”.

Penutup

Verifikasi migrasi model AI di produksi tanpa menambah flaky test membutuhkan perubahan pola pikir: jangan uji model generatif seperti fungsi deterministik biasa. Gunakan golden dataset untuk membandingkan perilaku penting, contract test untuk menjaga output terstruktur, metrik operasional untuk menilai dampak produksi, serta shadow traffic dan canary untuk rollout aman.

Jika tim backend mendefinisikan acceptance threshold sejak awal dan menyiapkan checklist CI/CD yang disiplin, migrasi model—termasuk migrasi agen AI ke model baru seperti GPT-5.6—bisa dijalankan dengan risiko yang jauh lebih terukur.