Strategi Uji Causal Trace untuk Mencegah Regresi Workflow LLM

Strategi uji causal trace untuk mencegah regresi workflow LLM berguna ketika tes end-to-end biasa tidak cukup menjelaskan kenapa perilaku aplikasi berubah. Masalah utama pada sistem berbasis LLM bukan hanya output yang kadang berbeda, tetapi juga sulitnya menentukan tahap mana yang menyebabkan perbedaan itu: retrieval bergeser, prompt dirakit tidak lengkap, tool call salah argumen, verifier terlalu longgar, atau model memang menghasilkan jawaban yang berbeda namun masih benar.

Pendekatan yang dibahas di sini mengambil inspirasi dari gagasan causal tracing dalam mechanistic interpretability, tetapi diterapkan secara praktis untuk rekayasa perangkat lunak. Intinya bukan membedah neuron model, melainkan memetakan workflow LLM menjadi rantai sebab-akibat yang bisa diamati dan diuji. Dengan begitu, saat terjadi regresi, tim bisa menjawab dua pertanyaan penting: apa yang berubah dan perubahan itu berdampak di titik mana.

Referensi konteks: pembahasan tentang upaya memahami proses penalaran model besar menunjukkan pentingnya observabilitas internal. Dalam praktik engineering, ide itu dapat diterjemahkan menjadi observasi terstruktur pada setiap tahap workflow, bukan sekadar mengecek string output akhir.

Apa yang dimaksud causal trace dalam konteks testing workflow LLM

Dalam konteks aplikasi, causal trace adalah jejak eksekusi yang mencatat transformasi data dari awal sampai akhir. Setiap tahap workflow diperlakukan sebagai titik observasi:

Input normalization: query asli, metadata user, locale, feature flag.
Retrieval: dokumen yang diambil, skor, filter, versi indeks.
Prompt assembly: template, slot yang terisi, instruksi sistem, konteks yang disuntikkan.
Tool call: nama tool, argumen, hasil, error, retry.
Verifier / guardrail: hasil validasi format, grounding, policy, atau rule bisnis.
Output: jawaban akhir, sitasi, status, confidence internal jika ada.

Tanpa pemetaan ini, tes cenderung rapuh. Misalnya, output akhir berubah sedikit dan tes langsung gagal, padahal perbedaannya masih dapat diterima. Atau sebaliknya, output terlihat mirip tetapi retrieval diam-diam salah dokumen sehingga aplikasi menjadi tidak andal pada kasus lain.

Dengan causal trace, Anda tidak hanya menilai hasil akhir, tetapi juga konsistensi sebab-akibat di dalam workflow.

Contoh workflow LLM yang layak diuji dengan causal trace

Anggap kita punya aplikasi asisten internal untuk menjawab pertanyaan kebijakan perusahaan. Workflow sederhananya:

User mengirim pertanyaan.
Sistem melakukan normalisasi input dan klasifikasi intent ringan.
Retriever mengambil 5 dokumen kebijakan teratas.
Prompt builder menyusun instruksi sistem, pertanyaan user, dan potongan dokumen.
Model dapat memanggil tool pencarian lanjutan bila konteks kurang.
Verifier memeriksa apakah jawaban menyertakan rujukan dan tidak melanggar format.
Output dikirim ke user.

Jika aplikasi ini hanya diuji dengan snapshot output, regresi sulit didiagnosis. Misalnya jawaban salah karena:

dokumen yang relevan tidak masuk top-k retrieval,
prompt baru memotong konteks penting,
tool dipanggil dengan argumen tanggal yang salah,
verifier menerima jawaban tanpa sitasi,
output berubah karena model berbeda tetapi masih semantik sama.

Karena itu, struktur tes harus mengikuti workflow, bukan hanya output akhirnya.

Memetakan titik observasi yang bisa diuji

1. Input sebagai sumber sebab awal

Pada tahap ini, simpan representasi input yang sudah dinormalisasi. Hal yang biasanya relevan untuk diuji:

query hasil trimming dan canonicalization,
bahasa dan locale yang terdeteksi,
role atau hak akses user,
feature flag yang aktif,
session state atau konteks percakapan yang ikut mempengaruhi.

Invariant di tahap ini biasanya deterministik. Contohnya: query kosong harus ditolak, locale harus terisi default, dan role terbatas tidak boleh memicu retrieval dokumen privat.

2. Retrieval sebagai sumber regresi paling umum

Retrieval sering menjadi penyebab utama jawaban menurun walaupun model dan prompt tidak berubah. Titik observasinya bisa berupa:

daftar document ID yang diambil,
urutan top-k,
filter yang diterapkan,
versi indeks atau timestamp sinkronisasi,
cuplikan isi dokumen yang dikirim ke prompt.

Di sini, jangan memaksakan kesamaan urutan penuh jika sistem memang punya unsur ranking yang sedikit bervariasi. Lebih aman mendefinisikan aturan seperti:

dokumen kunci tertentu harus muncul di top-k,
tidak boleh ada dokumen dari domain terlarang,
skor relevansi minimum untuk dokumen pertama melewati ambang internal,
cakupan kategori dokumen tertentu tetap terjaga.

3. Prompt assembly harus bisa diaudit

Banyak bug terjadi bukan karena model “berpikir salah”, tetapi karena prompt akhir tidak sesuai harapan. Observasi yang perlu direkam:

nama template atau hash template,
slot variabel yang terisi,
jumlah dokumen konteks yang benar-benar masuk,
panjang prompt atau token perkiraan,
instruksi penting yang wajib ada.

Untuk tahap ini, assertion berbasis struktur lebih tahan lama daripada snapshot string penuh. Misalnya, cek bahwa prompt mengandung blok kebijakan, instruksi sitasi, dan pertanyaan user, tanpa memaksa seluruh whitespace identik.

4. Tool call perlu diuji seperti API biasa

Jika model boleh memanggil tool, anggap ini sebagai kontrak I/O yang wajib tervalidasi. Simpan:

tool yang dipilih,
argumen terstruktur,
respons tool,
status error dan retry,
durasi.

Regresi umum di sini adalah nama field argumen berubah, model mengirim nilai ambigu, atau hasil tool tidak lagi cukup untuk verifier.

5. Verifier sebagai lapisan pembeda valid dan tidak valid

Verifier dapat berupa rule-based checker, evaluator model lain, atau kombinasi keduanya. Titik observasi yang penting:

status pass/fail tiap rule,
alasan penolakan,
apakah fallback dijalankan,
skor evaluasi jika ada rubric.

Tes yang baik memastikan verifier tidak terlalu longgar dan tidak terlalu ketat. Jika terlalu longgar, regresi lolos. Jika terlalu ketat, tes menjadi flaky dan menghambat deploy.

6. Output akhir tetap diuji, tetapi bukan satu-satunya sumber kebenaran

Untuk output, fokus pada atribut yang memang penting bagi pengguna dan bisnis:

jawaban menjawab pertanyaan,
menyertakan sitasi bila diwajibkan,
format JSON valid bila kontraknya terstruktur,
tidak mengandung klaim yang bertentangan dengan dokumen sumber.

Jika memungkinkan, pisahkan penilaian format, grounding, dan task success agar diagnosis lebih jelas.

Membedakan variasi yang boleh dari regresi nyata

Ini tantangan terbesar dalam testing workflow LLM. Tidak semua perbedaan adalah bug. Strategi yang efektif adalah membagi pemeriksaan menjadi tiga kelas:

1. Deterministic invariants

Aturan yang harus selalu benar, misalnya:

output JSON harus lolos schema validation,
tool tertentu hanya boleh dipanggil setelah intent tertentu,
dokumen privat tidak boleh bocor ke prompt untuk user biasa,
jawaban harus menyertakan minimal satu sitasi jika sumber tersedia.

Jenis tes ini paling stabil dan harus menjadi fondasi CI.

2. Bounded variation checks

Aturan yang mengizinkan variasi terbatas. Contohnya:

top-3 retrieval boleh berubah urutan, asalkan document ID wajib tetap muncul di top-5,
jawaban boleh memakai sinonim, asalkan intent dan fakta kunci tetap sama,
tool call boleh tidak terjadi jika konteks retrieval sudah cukup, asalkan verifier tetap lulus.

Pendekatan ini lebih realistis daripada snapshot ketat.

3. Semantic or rubric-based evaluation

Untuk bagian yang memang sulit diukur secara eksak, gunakan evaluator berlapis: rule-based terlebih dahulu, baru penilaian semantik. Namun evaluator semantik jangan dijadikan satu-satunya gerbang, karena ia juga bisa bervariasi.

Prinsip praktisnya: semakin dekat ke infrastruktur dan kontrak data, semakin deterministik tesnya. Semakin dekat ke bahasa alami, semakin gunakan aturan berbatas dan rubric.

Desain test suite: invariant, golden test, replay test, dan evaluasi berlapis

Invariant test

Invariant test memeriksa properti yang harus selalu benar di setiap tahap.

case_id: hr-policy-001
input:
  query: "Berapa cuti tahunan untuk pegawai kontrak?"
expected_invariants:
  retrieval:
    must_include_doc_ids: ["policy-leave-contract"]
    forbidden_sources: ["private/hr-draft"]
  prompt:
    required_sections: ["system_instruction", "user_question", "retrieved_context"]
  tool:
    allowed_tools: ["search_policy", "none"]
  output:
    requires_citation: true
    format: "markdown_or_text"

Kelebihannya: stabil, cepat, dan mudah dijelaskan saat gagal. Kekurangannya: tidak selalu cukup untuk menjamin kualitas jawaban akhir.

Golden test

Golden test menyimpan artefak yang dianggap benar untuk satu workflow atau satu tahap tertentu. Pada sistem LLM, sebaiknya golden tidak hanya berisi output final, tetapi juga trace terpilih.

{
  "case_id": "hr-policy-001",
  "golden": {
    "retrieval_doc_ids": ["policy-leave-contract", "leave-faq"],
    "required_prompt_markers": ["Sertakan sitasi", "Jawab berdasarkan dokumen"],
    "expected_output_facts": [
      "menjawab cuti tahunan pegawai kontrak",
      "menyertakan rujukan kebijakan"
    ]
  }
}

Jangan menjadikan string output penuh sebagai satu-satunya golden, kecuali kasusnya benar-benar terstruktur dan deterministik. Untuk teks bebas, gunakan golden berbasis fakta, marker, schema, atau sitasi wajib.

Replay test

Replay test menjalankan ulang trace produksi atau staging yang pernah sukses. Ini sangat berguna untuk mendeteksi regresi setelah perubahan:

template prompt,
strategi retrieval,
model routing,
tool schema,
verifier.

Agar replay berguna, rekam artefak minimum:

input yang sudah dinormalisasi,
snapshot kandidat retrieval atau ID dokumen dan versi indeks,
prompt terakit atau hash plus komponen pembentuk,
tool I/O,
hasil verifier,
output akhir.

Trade-off-nya, replay dapat menjadi kurang stabil bila bergantung pada data eksternal yang berubah. Solusinya adalah membedakan antara replay penuh dengan stub dan replay parsial terhadap layanan nyata.

Evaluasi berlapis di CI

Jangan menaruh semua tes di satu tahap. Bagi menjadi lapisan:

Pre-merge cepat: schema validation, invariant, unit test prompt builder, kontrak tool.
Integration test: retrieval terhadap indeks uji, prompt assembly, verifier, dan beberapa replay penting.
Nightly evaluation: set kasus lebih besar, semantic scoring, analisis drift, dan pelacakan flaky test.
Canary / post-deploy: sampling trace nyata untuk membandingkan metrik sebelum dan sesudah rilis.

Tujuannya sederhana: tes yang murah dan deterministik memblok perubahan paling awal; tes yang lebih mahal dan variatif dijalankan berkala untuk mendeteksi penurunan kualitas yang tidak terlihat di unit test.

Contoh struktur trace dan test case

Berikut contoh struktur trace yang cukup praktis untuk disimpan sebagai JSON:

{
  "case_id": "billing-007",
  "input": {
    "query": "Bagaimana cara mengunduh invoice bulan lalu?",
    "locale": "id-ID",
    "role": "customer"
  },
  "retrieval": {
    "doc_ids": ["help-invoice-download", "billing-faq"],
    "filters": {"product": "billing"}
  },
  "prompt": {
    "template": "support_answer_v3",
    "markers": ["ground_only_on_context", "cite_sources"],
    "context_doc_count": 2
  },
  "tool_calls": [
    {
      "tool": "lookup_invoice_portal",
      "arguments": {"period": "last_month"},
      "status": "ok"
    }
  ],
  "verifier": {
    "schema_pass": true,
    "citation_pass": true,
    "policy_pass": true
  },
  "output": {
    "contains_citation": true,
    "format": "text"
  }
}

Lalu test case-nya dapat didefinisikan seperti ini:

{
  "case_id": "billing-007",
  "checks": {
    "retrieval": {
      "must_include_any": ["help-invoice-download"],
      "forbid": ["internal-billing-runbook"]
    },
    "prompt": {
      "require_markers": ["ground_only_on_context", "cite_sources"],
      "min_context_doc_count": 1
    },
    "tool_calls": {
      "allowed_tools": ["lookup_invoice_portal"],
      "argument_contract": {
        "period": ["last_month", "explicit_month"]
      }
    },
    "verifier": {
      "must_pass": ["schema_pass", "citation_pass"]
    },
    "output": {
      "must_contain_citation": true
    }
  }
}

Pola ini memudahkan Anda memisahkan perubahan yang sah dari regresi. Misalnya, model boleh menulis kalimat berbeda, tetapi tetap harus memakai sumber yang benar dan memanggil tool yang diizinkan.

Mendeteksi flaky test pada workflow LLM

Flaky test adalah tes yang kadang lolos dan kadang gagal tanpa perubahan kode yang relevan. Pada sistem LLM, penyebabnya bisa lebih banyak daripada aplikasi biasa:

sampling model atau nondeterminisme inference,
retrieval tergantung indeks yang sedang berubah,
layanan tool eksternal lambat atau hasilnya berubah,
evaluator semantik tidak stabil,
tes terlalu ketat pada string output.

Tanda-tanda flaky test

kasus yang sama gagal di rerun lalu lolos tanpa perubahan,
failure terkonsentrasi pada assertion output bebas, bukan pada invariant,
hasil berubah terutama pada urutan retrieval atau pilihan kata,
gagal hanya pada jam tertentu karena dependensi eksternal.

Cara menguranginya

Bekukan dependensi sebanyak mungkin: gunakan fixture retrieval, stub tool, atau snapshot indeks uji.
Turunkan ketergantungan pada exact match: gunakan schema, marker, fakta wajib, dan sitasi.
Pisahkan tes deterministik dari tes evaluatif: jangan campur unit invariant dengan semantic scoring di gerbang yang sama.
Lakukan rerun terukur: jika sebuah kelas tes memang probabilistik, simpan tingkat lolos per kasus, bukan hanya pass/fail tunggal.
Tandai sumber nondeterminisme: model, retrieval live, tool live, atau evaluator LLM.

Poin pentingnya: jangan menormalisasi flakiness sebagai hal wajar. Jika tes terlalu tidak stabil untuk dipercaya, ia bukan pelindung regresi yang baik.

Metrik reliabilitas yang layak dipantau

Selain pass rate mentah, beberapa metrik berikut lebih membantu untuk workflow LLM:

1. Stage pass rate

Persentase kelulusan per tahap: retrieval, prompt, tool, verifier, output. Ini memudahkan identifikasi lokasi regresi.

2. Flake rate per case

Berapa sering satu test case berubah hasil saat dijalankan ulang dalam kondisi sama. Jika tinggi, perbaiki desain test sebelum memakainya sebagai gerbang CI.

3. Regression detection precision

Seberapa sering alarm tes benar-benar terkait penurunan kualitas nyata, bukan variasi wajar. Metrik ini penting agar tim tidak lelah menghadapi false alarm.

4. Grounding or citation compliance

Jika aplikasi menuntut jawaban berbasis sumber, ukur berapa persen jawaban yang lolos aturan sitasi atau grounding.

5. Tool-call contract success rate

Untuk agentic workflow, ukur keberhasilan pemanggilan tool sesuai schema dan intent.

6. Replay stability

Persentase trace historis yang tetap lolos setelah perubahan sistem. Ini berguna sebagai indikator dampak terhadap perilaku lama.

Gunakan metrik ini per kategori kasus, bukan hanya agregat global. Regresi pada kasus biling, HR, atau legal bisa tertutup jika semua domain dicampur.

Implementasi praktis di pipeline CI

Lapisan 1: unit dan contract test

Jalankan cepat pada setiap pull request:

validasi schema output terstruktur,
tes prompt builder dengan marker wajib,
tes parser dan formatter tool arguments,
tes rule verifier.

Lapisan 2: integration test terkontrol

Jalankan terhadap fixture retrieval dan stub tool:

cek invariant lintas tahap,
cek golden trace parsial,
ukur stage pass rate.

Lapisan 3: replay test penting

Pilih trace representatif dari produksi:

kasus bernilai bisnis tinggi,
kasus yang pernah gagal sebelumnya,
kasus edge seperti query ambigu atau multi-turn.

Lapisan 4: nightly evaluation

Tambahkan evaluasi lebih mahal:

semantic review dengan rubric,
analisis drift retrieval,
deteksi flakiness berbasis rerun sampling.

Jika organisasi Anda baru mulai, jangan langsung membangun evaluator kompleks. Mulai dari invariant dan replay paling penting, lalu tambahkan semantic layer hanya untuk area yang memang perlu.

Kesalahan umum saat menerapkan strategi uji causal trace

Terlalu fokus pada output akhir sehingga penyebab regresi tidak terlihat.
Menyimpan golden berupa string penuh untuk jawaban bebas, lalu tes menjadi rapuh.
Tidak merekam versi konteks seperti indeks retrieval, template prompt, atau schema tool.
Mencampur live dependency ke semua tes sehingga CI lambat dan flaky.
Mengandalkan evaluator LLM sebagai hakim tunggal tanpa invariant rule-based.
Tidak mengelompokkan kasus uji berdasarkan domain, risiko, dan jenis failure.

Checklist implementasi

Petakan workflow LLM menjadi tahap input, retrieval, prompt assembly, tool call, verifier, dan output.
Tentukan artefak trace minimum yang direkam pada setiap tahap.
Definisikan invariant yang deterministik terlebih dahulu.
Buat golden test berbasis fakta, marker, schema, dan dokumen wajib; hindari exact output text untuk teks bebas.
Kumpulkan replay trace dari kasus produksi yang representatif.
Pisahkan suite pre-merge, integration, nightly, dan canary.
Tandai sumber nondeterminisme dan minimalkan dependensi live di CI.
Ukur stage pass rate, flake rate, replay stability, dan compliance penting seperti sitasi.
Tinjau failure berdasarkan tahap penyebab, bukan hanya pass/fail akhir.
Perbarui dataset uji saat workflow berubah, tetapi lakukan review agar baseline tidak bergeser tanpa disadari.

Penutup

Strategi uji causal trace untuk workflow LLM bukan upaya membuat semua perilaku model menjadi deterministik. Tujuannya adalah membuat perubahan bisa dijelaskan, diuji, dan diputuskan dengan sadar. Dengan memecah alur menjadi titik observasi yang jelas, Anda dapat membedakan variasi yang masih dapat diterima dari regresi yang benar-benar merusak perilaku aplikasi.

Mulailah dari hal yang paling praktis: rekam trace per tahap, tetapkan invariant, bangun replay test dari kasus penting, lalu lapisi dengan evaluasi yang lebih kaya di CI. Pendekatan ini biasanya memberi hasil lebih baik daripada sekadar menambah lebih banyak snapshot output yang rapuh dan sulit dirawat.

Quick Search

shopping_cart Keranjang