Strategi Uji Provenance Model untuk Cegah Regresi Supply Chain

Strategi uji provenance model diperlukan ketika tim merilis model, adapter, checkpoint, container image, atau paket build yang tampak baru tetapi sebenarnya hanya hasil repackaging, merge, atau fine-tune kecil dari artefak lama. Tujuannya bukan sekadar mencari siapa yang benar, melainkan memastikan setiap klaim rilis bisa dibuktikan secara teknis, diaudit, dan direproduksi.

Dalam konteks isu seperti Nex-N2, pelajaran utamanya sederhana: tanpa workflow verifikasi yang konsisten, tim mudah salah menganggap perubahan distribusi artefak sebagai perubahan substansial pada model. Karena itu, pengujian provenance harus diperlakukan seperti pengujian regresi pada software supply chain: ada threat model, ada bukti minimum, ada baseline, dan ada gate sebelum rilis.

Mengapa provenance model perlu diuji, bukan hanya didokumentasikan

Dokumentasi rilis sering menyebut sumber data, base model, metode fine-tune, dan benchmark. Masalahnya, dokumentasi adalah claim, bukan bukti. Dalam praktik engineering, provenance perlu diuji dengan sinyal yang bisa diverifikasi, misalnya:

Hash artefak untuk mengetahui apakah file benar-benar berubah.
Golden metadata untuk memastikan asal-usul, pipeline, dan parameter build tercatat konsisten.
Diff config, weights, dan adapter untuk membedakan model baru dari hasil repackaging.
Evaluasi regresi untuk melihat apakah perilaku model bergeser secara signifikan.
Gate CI untuk menahan rilis yang tidak memenuhi bukti minimum.

Pendekatan ini berlaku bukan hanya untuk model machine learning, tetapi juga untuk container image, artefak build, dan paket distribusi. Prinsipnya sama: setiap artefak harus punya jejak asal-usul yang dapat diuji ulang.

Threat model: apa yang sebenarnya ingin dicegah

Sebelum membuat checklist, tentukan ancaman yang realistis. Threat model untuk provenance model biasanya bukan hanya serangan eksternal, tetapi juga kesalahan proses internal.

1. Salah klasifikasi perubahan artefak

Model lama dikemas ulang ke format baru lalu diklaim sebagai model baru.
Hasil merge adapter dianggap pretraining baru.
Perubahan hanya pada tokenizer, config, atau quantization, tetapi dideskripsikan sebagai perubahan arsitektur atau kualitas model.

2. Klaim reproducibility yang tidak bisa dibuktikan

Checkpoint tidak bisa ditelusuri ke commit, dataset snapshot, dan pipeline yang spesifik.
File model berbeda, tetapi metadata build tidak menjelaskan penyebabnya.
Rilis tidak menyertakan bukti evaluasi yang dapat diulang.

3. Supply chain drift

Image builder, dependency, atau tool konversi berubah sehingga artefak berbeda walau input sama.
Pipeline CI menghasilkan checksum berbeda karena proses non-deterministik.
Repackaging mengubah susunan file, normalisasi metadata, atau kompresi tanpa perubahan substansi model.

4. Benchmark yang menyesatkan

Perubahan skor berasal dari variasi benchmark yang flaky, bukan dari model.
Seed, decoding parameter, atau subset data berubah tanpa dicatat.
Perbandingan dilakukan pada lingkungan runtime yang tidak setara.

Threat model ini penting karena strategi uji provenance model yang baik harus mampu membedakan perubahan substansial, perubahan distribusi, dan noise pengukuran.

Bukti minimum yang harus ada pada setiap rilis

Jika tim ingin mengaudit provenance dengan disiplin, buat contract of evidence: daftar bukti minimum yang wajib hadir sebelum artefak dianggap layak rilis.

Checklist verifikasi provenance

Identitas artefak: nama, versi, tanggal build, dan identifier unik.
Hash file utama: checksum untuk checkpoint, tokenizer, config, adapter, image manifest, dan file pendukung kritis.
Asal input: base model, commit source, dataset snapshot, dan dependency lock.
Transformasi: fine-tune, merge, quantize, convert, prune, repackaging, atau compression yang dilakukan.
Pipeline build: commit pipeline, environment, runner, dan tool yang digunakan.
Evaluasi regresi: hasil baseline versus kandidat rilis.
Status diff: apakah config, adapter, atau weights berubah secara material.
Tingkat kepercayaan klaim: misalnya repackaged only, fine-tuned derivative, atau new training run.

Checklist ini memaksa tim berhenti mendeskripsikan artefak hanya dengan istilah pemasaran. Sebaliknya, status rilis ditentukan oleh bukti teknis.

Golden metadata: fondasi audit yang konsisten

Golden metadata adalah skema metadata yang dianggap sumber kebenaran minimum untuk provenance. Ia tidak perlu rumit, tetapi harus stabil, mudah diparse, dan cukup kaya untuk audit.

Atribut yang sebaiknya dicatat

artifact_id: identifier unik artefak.
source_commit: commit code/pipeline yang menghasilkan artefak.
base_artifact: model atau image asal.
build_inputs: dataset snapshot, config, adapter, script, dependency lock.
transformations: urutan langkah seperti merge, fine-tune, quantization, conversion.
output_hashes: hash file keluaran per komponen.
eval_manifest: benchmark, seed, subset data, decoding parameter, dan runtime.
claim_type: turunan, repackaged, merged, atau training baru.

Metadata ini idealnya disimpan bersama artefak dan ikut ditandatangani atau setidaknya dichecksum. Tanpa itu, metadata bisa berubah setelah rilis tanpa jejak yang jelas.

Contoh manifest provenance

{
  "artifact_id": "model-2026-06-rc1",
  "claim_type": "fine_tuned_derivative",
  "base_artifact": {
    "name": "base-model-x",
    "digest": "sha256:..."
  },
  "source_commit": "abc123def",
  "build_inputs": {
    "training_config": "sha256:...",
    "tokenizer": "sha256:...",
    "adapter": "sha256:...",
    "dataset_snapshot": "dataset@2026-06-15"
  },
  "transformations": [
    "merge_adapter",
    "export_checkpoint",
    "repackage"
  ],
  "outputs": {
    "weights": "sha256:...",
    "config": "sha256:...",
    "tokenizer": "sha256:..."
  },
  "evaluation": {
    "benchmark_suite": "internal-regression-v1",
    "seed": 42,
    "decoder": {
      "temperature": 0,
      "top_p": 1.0
    }
  }
}

Formatnya bisa JSON, YAML, atau attestations terpisah. Yang penting adalah konsistensi, bukan formatnya.

Hash artefak: cepat, murah, tetapi jangan dipakai sendirian

Hash adalah garis pertahanan pertama. Bila dua file sama persis, checksum akan identik. Jika checksum berbeda, ada perubahan byte-level. Namun, hash tidak cukup untuk menjawab apakah perubahan itu substantif.

Apa yang sebaiknya di-hash

File weights/checkpoint.
Config model dan tokenizer.
Adapter atau LoRA weights.
Manifest image container dan layer digest.
File lock dependency.
Script konversi atau export yang relevan.

Contoh perhitungan hash

sha256sum model.safetensors config.json tokenizer.json adapter.safetensors > SHA256SUMS

Untuk container image, gunakan digest manifest dari registry atau hasil inspect tooling yang memang dirancang untuk konten image. Untuk paket build, simpan checksum artefak final dan file lock input.

Keterbatasan hash

Perubahan metadata file atau urutan serialisasi bisa mengubah hash tanpa mengubah isi semantik.
File yang berbeda tidak selalu berarti model berubah secara fungsional.
Hash yang sama tidak membuktikan provenance jika asal file tidak diketahui.

Karena itu, hash harus dipadukan dengan metadata dan diff semantik.

Diff config, weights, dan adapter: membedakan perubahan substansial dari repackaging

Bagian ini biasanya paling berguna ketika tim ingin membuktikan apakah model benar-benar baru, hanya hasil merge, atau sekadar kemasan ulang.

1. Diff config

Bandingkan file konfigurasi secara terstruktur, bukan hanya teks mentah. Perhatikan perubahan pada:

Nama arsitektur.
Ukuran hidden layer, jumlah layer, vocab size.
Special tokens dan tokenizer mapping.
Parameter quantization atau export.

Jika yang berubah hanya metadata deskriptif atau path, kemungkinan besar ini bukan model baru. Jika parameter arsitektur inti berubah, itu sinyal perubahan substantif, meski tetap perlu dibuktikan dengan artefak weights dan evaluasi.

2. Diff weights

Untuk weights, ada tiga tingkat pemeriksaan yang umum:

Byte-level: checksum file.
Tensor manifest: nama tensor, shape, dtype.
Numeric diff: statistik perbedaan tensor, misalnya norm atau rasio tensor yang berubah.

Pemeriksaan tensor manifest sering cukup untuk mendeteksi repackaging versus perubahan nyata. Jika nama tensor, shape, dan dtype identik tetapi file berbeda, kemungkinan ada perubahan serialisasi, kompresi, atau metadata. Jika nilai tensor juga berubah, baru masuk ke analisis lebih dalam.

3. Diff adapter dan hasil merge

Kasus yang sering membingungkan adalah adapter yang di-merge ke base model. Secara file akhir, weights memang berubah. Namun provenance-nya tetap harus dinyatakan sebagai derived from base + adapter, bukan otomatis model baru hasil training dari nol.

Checklist untuk kasus merge:

Catat digest base model sebelum merge.
Catat digest adapter.
Simpan script atau command merge yang digunakan.
Verifikasi bahwa output merge dapat direproduksi dari input yang sama.
Bedakan label rilis antara merged derivative dan new training run.

Contoh skrip verifikasi sederhana

#!/usr/bin/env python3
import json, hashlib, sys
from pathlib import Path

def sha256(path):
    h = hashlib.sha256()
    with open(path, 'rb') as f:
        for chunk in iter(lambda: f.read(1024 * 1024), b''):
            h.update(chunk)
    return h.hexdigest()

files = [Path("config.json"), Path("tokenizer.json"), Path("model.safetensors")]
manifest = {str(p): sha256(p) for p in files if p.exists()}
print(json.dumps(manifest, indent=2, sort_keys=True))

Skrip ini belum cukup untuk audit penuh, tetapi berguna sebagai langkah awal yang bisa dijalankan di CI.

Evaluasi regresi: jangan hanya cek file, cek perilaku model

Dua artefak bisa berbeda, tetapi performanya identik. Sebaliknya, artefak yang tampak mirip bisa mengalami regresi perilaku. Karena itu, evaluasi regresi harus menjadi bagian dari uji provenance model.

Apa yang perlu dibekukan dalam evaluasi

Versi benchmark atau snapshot dataset evaluasi.
Seed dan parameter decoding.
Prompt template atau formatting input.
Runtime inferensi, precision, dan setting batch.
Kriteria lolos: misalnya toleransi perbedaan skor atau rule berbasis statistik.

Flaky test pada benchmark: sumber salah simpul yang sering diabaikan

Benchmark model sering flaky karena ada sampling, layanan eksternal, timeout, atau variasi runtime. Jika ini tidak dikendalikan, tim bisa salah menyimpulkan bahwa artefak baru lebih baik atau berbeda padahal variasinya hanya noise.

Beberapa mitigasi yang praktis:

Gunakan decoding deterministik bila memungkinkan, misalnya temperature nol untuk tes regresi.
Jalankan evaluasi lebih dari satu kali pada subset kecil yang stabil jika memang ada komponen non-deterministik.
Pisahkan smoke benchmark di CI dari benchmark penuh yang mahal.
Simpan output mentah, bukan hanya skor agregat, agar diff perilaku bisa ditelusuri.
Tentukan confidence band atau toleransi, bukan aturan lulus/gagal yang terlalu kaku pada skor tunggal.

Apa yang dinilai dalam gate evaluasi

Untuk kebutuhan provenance, evaluasi tidak harus langsung membuktikan model lebih baik. Fokus utamanya adalah:

Apakah perilaku model konsisten dengan klaim rilis.
Apakah ada regresi besar yang tidak dijelaskan oleh metadata transformasi.
Apakah perubahan benchmark sejalan dengan diff artefak yang ditemukan.

Contoh: jika metadata menyatakan hanya repackaging, tetapi benchmark bergeser signifikan, itu tanda kuat ada masalah pada proses export, tokenizer, runtime, atau artefak yang salah.

Gate CI sebelum rilis: tempat semua verifikasi disatukan

Workflow manual mudah terlewat. Cara paling efektif adalah menjadikan verifikasi provenance sebagai gate CI sebelum artefak dipublikasikan.

Tahapan gate yang direkomendasikan

Collect evidence: generate manifest, checksum, dan metadata input.
Compare with baseline: bandingkan kandidat rilis dengan artefak sebelumnya atau base artifact.
Run regression checks: smoke benchmark, validasi config, validasi struktur weights.
Classify release: repackaged, merged derivative, fine-tuned derivative, atau training baru.
Block or approve: tahan rilis jika bukti tidak lengkap atau klaim tidak sesuai hasil verifikasi.

Contoh workflow CI generik

stages:
  - build
  - provenance
  - eval
  - release

provenance_check:
  stage: provenance
  script:
    - python scripts/gen_manifest.py > manifest.json
    - sha256sum model.safetensors config.json tokenizer.json > SHA256SUMS
    - python scripts/compare_against_baseline.py --manifest manifest.json --baseline baseline.json
  artifacts:
    paths:
      - manifest.json
      - SHA256SUMS

regression_eval:
  stage: eval
  script:
    - python scripts/run_smoke_eval.py --manifest manifest.json --output eval.json
    - python scripts/check_eval_gate.py --eval eval.json --policy policy.json
  artifacts:
    paths:
      - eval.json

release:
  stage: release
  script:
    - ./publish.sh
  when: on_success

Contoh ini sengaja generik agar mudah diadaptasi ke GitHub Actions, GitLab CI, Jenkins, atau sistem internal lain.

Kebijakan gate yang masuk akal

Gagal jika metadata provenance wajib tidak lengkap.
Gagal jika hash input penting tidak tersedia.
Gagal jika claim_type tidak cocok dengan hasil diff artefak.
Gagal jika benchmark smoke menunjukkan regresi di luar toleransi.
Butuh persetujuan manual jika ada perubahan besar tetapi bukti reproduksi belum lengkap.

Workflow yang bisa diterapkan lintas artefak: model, image, dan paket build

Konsep provenance tidak eksklusif untuk machine learning. Pola yang sama bisa dipakai di berbagai artefak supply chain.

1. Model atau checkpoint

Hash checkpoint, config, tokenizer, adapter.
Simpan lineage: base model, adapter, script merge, config training/export.
Bandingkan tensor manifest dan jalankan smoke eval.

2. Container image

Catat digest image dan layer penting.
Simpan Dockerfile atau definisi build serta dependency lock.
Bandingkan package inventory atau SBOM antar rilis.
Jalankan smoke test runtime untuk memastikan image tidak berubah secara tak terduga.

3. Paket build atau binary release

Hash artefak final dan file lock dependency.
Bandingkan isi paket, metadata build, dan hasil uji fungsional minimum.
Pastikan build dapat diulang dari commit yang sama dengan hasil yang dapat dijelaskan.

Perbedaan utamanya hanya pada jenis artefak dan jenis evaluasinya. Struktur verifikasi tetap sama: metadata + digest + diff + regression check + CI gate.

Kesalahan umum saat menerapkan uji provenance

1. Menganggap hash berbeda berarti model baru

Checksum berbeda hanya membuktikan file berbeda. Itu belum menjawab apakah perubahannya substantif atau hanya repackaging.

2. Menyimpan metadata, tetapi tidak membekukan input

Jika dataset snapshot, dependency lock, atau script export tidak dipatok, provenance akan sulit direproduksi walau manifest terlihat lengkap.

3. Benchmark dipakai sebagai satu-satunya bukti

Skor benchmark bisa fluktuatif dan tidak cukup untuk membuktikan asal-usul artefak. Evaluasi harus melengkapi bukti supply chain, bukan menggantikannya.

4. Tidak membedakan jenis klaim rilis

Tim sering memakai istilah “rilis model baru” untuk semua perubahan. Ini sumber kebingungan. Gunakan klasifikasi yang eksplisit: repackaged, merged derivative, fine-tuned derivative, atau new training run.

5. Verifikasi hanya dilakukan setelah kontroversi muncul

Kalau verifikasi baru dijalankan setelah ada pertanyaan publik, bukti sering sudah tersebar, input hilang, dan audit jadi mahal. Provenance harus dikumpulkan sejak pipeline normal berjalan.

Tips debugging ketika hasil verifikasi tidak konsisten

Hash berubah, benchmark tetap: cek repackaging, metadata file, format serialisasi, atau kompresi.
Hash sama, benchmark berubah: cek runtime, tokenizer, prompt template, decoding parameter, atau benchmark harness.
Config sama, weights berbeda: cek apakah ada merge adapter, quantization, atau export ulang.
Weights tampak sama, perilaku berubah: cek tokenizer, special token, pre/post-processing, atau precision runtime.
CI flaky: pisahkan smoke test deterministik dari benchmark penuh yang lebih mahal dan lebih sensitif terhadap noise.

Penutup

Strategi uji provenance model yang efektif bukan sekadar menambahkan file README atau pernyataan rilis. Yang dibutuhkan adalah workflow verifikasi yang bisa dijalankan berulang: tentukan threat model, tetapkan golden metadata, hash artefak penting, lakukan diff config/weights/adapter, jalankan evaluasi regresi yang sadar flaky benchmark, lalu pasang gate CI sebelum rilis.

Dengan pendekatan itu, tim dapat mengurangi salah klasifikasi hasil merge, fine-tune, atau repackaging sebagai model baru. Lebih penting lagi, klaim rilis menjadi lebih mudah diaudit, dijelaskan, dan direproduksi, baik untuk model machine learning, container image, maupun paket build dalam supply chain yang lebih luas.

Quick Search

shopping_cart Keranjang