CI untuk evaluasi model AI open weights yang reproducible diperlukan ketika tim engineering ingin mengganti atau memperbarui model tanpa merusak kualitas, menaikkan latensi secara diam-diam, atau membuat biaya inferensi sulit dikendalikan. Dalam praktiknya, masalah terbesar bukan sekadar menjalankan benchmark, tetapi memastikan hasilnya sebanding, dapat diulang, dan cukup otomatis untuk menjadi gerbang sebelum deploy.

Tren model open weights yang makin kompetitif—misalnya konteks naiknya perhatian terhadap keluarga model seperti GLM-5.2 di berbagai leaderboard—mendorong tim untuk lebih sering mengevaluasi kandidat model baru. Namun leaderboard publik tidak cukup untuk keputusan produksi. Tim tetap perlu pipeline internal yang menguji dataset, prompt, parameter inferensi, biaya, dan latensi pada beban kerja yang relevan dengan produk sendiri.

Mengapa evaluasi model harus masuk ke CI, bukan dijalankan manual

Evaluasi manual biasanya gagal pada tiga hal:

  • Tidak reproducible: model, prompt, parameter decoding, dan dataset berubah tanpa jejak yang jelas.
  • Tidak konsisten: benchmark dijalankan di mesin berbeda, dengan cache berbeda, atau subset data yang berbeda.
  • Tidak operasional: hasil evaluasi tidak terhubung ke proses merge, release, atau approval deploy.

Dengan memasukkan evaluasi ke CI, tim bisa menetapkan kontrak teknis yang jelas: setiap perubahan model adapter, quantization, prompt template, atau kode inferensi harus menghasilkan metrik yang tercatat dan dibandingkan dengan baseline. Jika gagal melewati ambang batas kualitas, biaya, atau latensi, pipeline berhenti sebelum perubahan masuk produksi.

Prinsip reproducibility yang wajib dijaga

1. Versioning untuk model, prompt, dataset, dan evaluator

Reproducibility hanya tercapai jika semua komponen evaluasi diberi identitas yang eksplisit. Minimal, catat:

  • Model identifier: nama model, revisi commit atau digest artifact, jenis quantization, tokenizer, dan format weights.
  • Prompt version: template prompt, system instruction, few-shot examples, dan format output yang diharapkan.
  • Dataset version: sumber data, hash file, metode sampling, dan split evaluasi.
  • Evaluator version: skrip scoring, normalizer output, rubric, dan aturan pass/fail.
  • Inference config: temperature, top_p, max tokens, seed bila relevan, batch size, timeout, dan hardware profile.

Kesalahan umum adalah hanya mem-version-kan model, tetapi membiarkan prompt atau dataset berubah di branch berbeda. Akibatnya, tim mengira model baru lebih baik, padahal benchmark-nya berubah.

2. Pisahkan benchmark deterministik dan benchmark statistik

Tidak semua evaluasi dapat dibuat benar-benar deterministik. Karena itu, pisahkan dua kategori:

  • Deterministik: exact match, schema validity, tool-call format, regression test prompt, safety checks berbasis aturan.
  • Statistik: kualitas generatif, preference scoring, rubric LLM-as-judge, atau task yang sensitif terhadap sampling.

Untuk benchmark statistik, jangan gunakan satu kali run sebagai satu-satunya dasar keputusan. Jalankan beberapa sampel, kunci subset data, dan gunakan ambang toleransi agar CI tidak fluktuatif.

3. Samakan kondisi perbandingan

Model open weights sering dibandingkan secara tidak adil karena konfigurasi inferensinya berbeda. Jika satu model diuji dengan context window besar, prompt lebih ringkas, atau hardware lebih cepat, hasil biaya dan latensinya menjadi tidak sebanding. Praktiknya:

  • Gunakan prompt set yang sama untuk task yang sama.
  • Gunakan dataset split yang sama untuk perbandingan baseline vs candidate.
  • Catat runtime backend yang digunakan, karena implementasi inferensi dapat memengaruhi throughput dan latency.
  • Jangan mencampur hasil warm cache dan cold cache tanpa penanda.

Arsitektur pipeline CI/CD yang praktis

Untuk kebanyakan tim, pipeline evaluasi yang sehat terdiri dari beberapa tahap berikut:

  1. Prepare: resolve versi model, dataset, prompt, dan evaluator; unduh metadata; validasi manifest.
  2. Fetch/Build Artifact: ambil weights, tokenizer, adapter, atau image runtime; manfaatkan cache agar tidak mengunduh ulang setiap job.
  3. Benchmark Matrix: jalankan evaluasi per task, per model variant, atau per quantization dalam matriks paralel.
  4. Aggregate Metrics: gabungkan hasil benchmark menjadi satu laporan terstruktur.
  5. Policy Gate: bandingkan hasil dengan baseline dan threshold bisnis/teknis.
  6. Approval: jika lolos, minta persetujuan reviewer tertentu sebelum deploy.
  7. Deploy: rollout ke environment berikutnya hanya jika gate terpenuhi.

Contoh struktur repository

repo/
  models/
    manifest.yaml
  prompts/
    support_v3.yaml
    extraction_v2.yaml
  datasets/
    eval_manifest.yaml
  eval/
    run_benchmark.py
    score.py
    aggregate.py
    policy.py
  baselines/
    production.json
  .github/workflows/
    model-eval.yml

Intinya, manifest menjadi sumber kebenaran. Hindari mengambil parameter secara implisit dari environment yang tidak tercatat di hasil evaluasi.

Versioning yang bisa diaudit

Gunakan manifest evaluasi

Daripada menyebar konfigurasi di banyak file yang sulit ditelusuri, gunakan satu manifest yang mendeskripsikan kandidat evaluasi. Contoh tingkat konsep:

experiment_id: glm52-q4-support-v3
model:
  name: glm-5.2
  revision: "<commit-atau-digest>"
  quantization: q4
  tokenizer_revision: "<digest>"
prompt:
  file: prompts/support_v3.yaml
  revision: "<git-sha>"
dataset:
  name: support_eval_id
  version: 2026-06-15
  split: holdout
  sample_seed: 42
inference:
  temperature: 0.0
  top_p: 1.0
  max_output_tokens: 512
  timeout_seconds: 30
runtime:
  backend: vllm
  device_profile: gpu-standard
metrics:
  quality: [accuracy, format_valid, judge_score]
  latency: [p50_ms, p95_ms]
  cost: [input_tokens, output_tokens, gpu_seconds]

Format tidak harus sama, tetapi prinsipnya penting: satu eksperimen harus bisa dijalankan ulang dari metadata yang lengkap.

Simpan baseline sebagai artifact yang bisa dibandingkan

Baseline sebaiknya bukan angka yang ditulis manual di dokumentasi. Simpan baseline sebagai file JSON hasil evaluasi kandidat yang sudah disetujui untuk produksi. Saat ada model baru, pipeline membandingkan hasil terbaru dengan baseline tersebut.

Dengan cara ini, approval bukan berdasarkan intuisi, tetapi pada diff metrik yang jelas.

Job matrix benchmark di CI

Job matrix benchmark berguna saat tim ingin menguji beberapa kombinasi model dan task tanpa menulis job terpisah satu per satu. Biasanya matriks dibagi berdasarkan:

  • task: klasifikasi, ekstraksi, RAG answer, summarization, tool-calling
  • model variant: full precision, quantized, fine-tuned adapter
  • runtime: CPU test ringan vs GPU evaluasi utama
  • dataset split: smoke set untuk PR, holdout set untuk release candidate

Strategi yang umum dipakai:

  • PR pipeline: jalankan smoke benchmark kecil, cepat, dan murah.
  • Scheduled atau release pipeline: jalankan benchmark penuh pada holdout set yang lebih representatif.

Pemisahan ini penting agar CI harian tidak memakan biaya berlebihan, tetapi tetap memberi sinyal dini jika ada regresi jelas.

Contoh GitHub Actions tingkat konsep

name: model-eval

on:
  pull_request:
    paths:
      - 'models/**'
      - 'prompts/**'
      - 'eval/**'
      - 'datasets/**'
  workflow_dispatch:

jobs:
  benchmark:
    runs-on: ubuntu-latest
    strategy:
      fail-fast: false
      matrix:
        task: [support, extraction]
        variant: [candidate]
    steps:
      - uses: actions/checkout@v4

      - name: Restore eval cache
        uses: actions/cache@v4
        with:
          path: |
            .cache/models
            .cache/datasets
          key: eval-${{ hashFiles('models/**', 'datasets/**') }}

      - name: Setup runtime
        run: ./scripts/setup_eval_runtime.sh

      - name: Run benchmark
        run: |
          python eval/run_benchmark.py \
            --task ${{ matrix.task }} \
            --manifest models/manifest.yaml \
            --output results/${{ matrix.task }}.json

      - name: Upload results
        uses: actions/upload-artifact@v4
        with:
          name: results-${{ matrix.task }}
          path: results/${{ matrix.task }}.json

  aggregate:
    needs: benchmark
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Download artifacts
        uses: actions/download-artifact@v4
        with:
          path: artifacts
      - name: Aggregate and compare baseline
        run: |
          python eval/aggregate.py --input artifacts --output summary.json
          python eval/policy.py --summary summary.json --baseline baselines/production.json

Contoh di atas sengaja bersifat konseptual. Implementasi nyata biasanya butuh runner GPU terpisah, akses ke penyimpanan artifact, dan isolasi secret bila ada komponen privat.

Contoh GitLab CI tingkat konsep

stages:
  - benchmark
  - aggregate
  - approve

benchmark_support:
  stage: benchmark
  script:
    - ./scripts/setup_eval_runtime.sh
    - python eval/run_benchmark.py --task support --manifest models/manifest.yaml --output support.json
  artifacts:
    paths:
      - support.json

benchmark_extraction:
  stage: benchmark
  script:
    - ./scripts/setup_eval_runtime.sh
    - python eval/run_benchmark.py --task extraction --manifest models/manifest.yaml --output extraction.json
  artifacts:
    paths:
      - extraction.json

aggregate:
  stage: aggregate
  script:
    - python eval/aggregate.py --input . --output summary.json
    - python eval/policy.py --summary summary.json --baseline baselines/production.json
  artifacts:
    paths:
      - summary.json

approve_deploy:
  stage: approve
  when: manual
  script:
    - echo "Approved for deployment"

Jika memakai GitLab, pola manual approval setelah evaluasi cukup alami. Di GitHub, approval biasanya dihubungkan dengan environment protection, branch protection, atau workflow terpisah untuk deploy.

Caching artifact agar evaluasi tidak mahal dan lambat

Tanpa caching, evaluasi model open weights akan boros waktu karena weights dan dataset sering berukuran besar. Caching yang baik biasanya meliputi:

  • Model weights: cache berdasarkan digest atau revision, bukan hanya nama model.
  • Tokenizer dan preprocessing artifact: termasuk vocabulary atau serialized dataset.
  • Dataset snapshot: terutama jika ada proses normalisasi atau filtering yang mahal.
  • Container image runtime: agar setup environment tidak berulang di setiap job.

Namun ada trade-off:

  • Cache yang terlalu agresif dapat menyembunyikan perubahan penting dan membuat hasil tidak benar-benar bersih.
  • Cache pada runner ephemeral belum tentu tersedia antar job atau antar workflow.
  • Untuk evaluasi performa, cold-start dan warm-start sebaiknya dicatat terpisah.

Catatan: Jika benchmark Anda memasukkan metrik latensi, jangan menyamakan hasil yang didapat setelah model sudah berada di memori dengan hasil startup pertama. Keduanya berguna, tetapi menjawab pertanyaan operasional yang berbeda.

Metrik yang wajib dicatat

Pipeline evaluasi yang baik tidak berhenti di satu angka kualitas. Untuk keputusan deploy, setidaknya catat empat kelompok metrik berikut.

1. Kualitas

  • Task accuracy atau exact match untuk tugas deterministik.
  • Format validity: JSON valid, schema pass, field wajib lengkap.
  • Hallucination/relevance proxy bila task melibatkan retrieval atau knowledge grounding.
  • Judge score atau rubric score untuk task generatif yang sulit dinilai otomatis.
  • Safety/compliance checks jika domain Anda sensitif.

2. Latensi dan performa

  • p50/p95 latency per request.
  • Time to first token bila aplikasi bersifat streaming.
  • Tokens per second atau throughput agregat.
  • Error rate, timeout rate, dan retry count.

3. Biaya

  • Input/output tokens per sampel dan total.
  • GPU seconds atau konsumsi compute setara yang bisa ditagihkan internal.
  • Storage/network overhead bila weights dan dataset sering dipindahkan antar runner.

4. Provenance dan auditability

  • model revision
  • prompt revision
  • dataset hash/version
  • evaluator revision
  • runtime backend
  • hardware profile
  • timestamp run

Tanpa provenance, angka benchmark tidak berguna untuk investigasi regresi beberapa minggu kemudian.

Baseline pass/fail yang realistis

Gerbang CI tidak harus menuntut model baru menang di semua metrik. Dalam produk nyata, keputusan biasanya berupa kompromi antara kualitas, latensi, dan biaya.

Contoh aturan kebijakan

  • Hard fail jika format validity turun di bawah threshold minimum.
  • Hard fail jika p95 latency melewati batas SLA internal.
  • Hard fail jika biaya inferensi naik melewati persentase yang ditentukan tanpa peningkatan kualitas yang setara.
  • Soft fail atau approval required jika quality score naik tipis tetapi biaya juga naik.

Pendekatan ini lebih sehat daripada satu skor gabungan yang terlalu menyederhanakan trade-off. Satu model bisa unggul di kualitas, tetapi tidak layak deploy untuk jalur trafik utama karena latensinya terlalu tinggi.

Contoh logika kebijakan sederhana

if format_validity < min_format_validity:
    fail()

if p95_latency_ms > max_p95_latency_ms:
    fail()

if quality_score < baseline_quality - allowed_regression:
    fail()

if cost_per_1k_requests > baseline_cost * cost_growth_limit:
    require_manual_approval()

Nilai threshold harus ditentukan dari kebutuhan produk, bukan mengikuti angka benchmark publik secara mentah.

Evaluasi biaya-latensi-kualitas sebagai satu paket

Dalam konteks model open weights, banyak tim terlalu fokus pada kualitas benchmark dan lupa bahwa total biaya operasional mencakup lebih dari token. Ada biaya runner GPU, waktu setup, storage cache, dan kompleksitas serving. Karena itu, evaluasi yang relevan untuk CI sebaiknya menjawab tiga pertanyaan sekaligus:

  1. Apakah kualitasnya cukup baik untuk use case produk?
  2. Apakah latensinya sesuai SLA pada backend yang akan dipakai?
  3. Apakah total biayanya masuk akal pada trafik yang diproyeksikan?

Model yang terlihat unggul di leaderboard belum tentu unggul di biaya operasional tim Anda. Misalnya, model dengan kualitas lebih tinggi bisa membutuhkan memori lebih besar, quantization yang lebih agresif, atau tuning serving yang belum stabil. Itulah sebabnya konteks seperti GLM-5.2 berguna sebagai sinyal pasar, tetapi keputusan deploy tetap harus didasarkan pada evaluasi internal yang reproducible.

Approval gate sebelum deploy

Setelah policy gate otomatis dijalankan, masih ada satu tahap penting: approval gate. Ini berguna untuk kasus di mana:

  • hasil benchmark lolos minimum, tetapi ada trade-off biaya yang perlu disetujui pemilik layanan;
  • model baru menyentuh area sensitif seperti legal, safety, atau compliance;
  • perubahan berasal dari fine-tuning atau prompt update yang berdampak ke perilaku produk.

Praktik yang baik:

  • Wajibkan review dari owner model dan owner service.
  • Lampirkan ringkasan diff baseline vs candidate di PR atau merge request.
  • Simpan artifact hasil evaluasi agar reviewer bisa menginspeksi contoh keluaran, bukan hanya metrik agregat.

Approval manusia bukan pengganti evaluasi otomatis, tetapi lapisan kontrol untuk keputusan yang memang tidak bisa direduksi menjadi satu angka.

Jebakan umum dan cara menghindarinya

Benchmark tidak stabil

Penyebab umum:

  • sampling acak tanpa seed atau tanpa pengulangan run,
  • dataset terlalu kecil,
  • latensi diukur saat lingkungan runner sedang noisy,
  • LLM-as-judge berubah prompt atau model penilainya.

Mitigasi:

  • gunakan subset tetap untuk PR,
  • jalankan beberapa repetisi untuk metrik statistik,
  • pisahkan benchmark kualitas dari benchmark performa murni,
  • version-kan judge prompt dan judge model.

Hasil tidak sebanding

Ini terjadi jika dua kandidat diuji dengan prompt berbeda, context berbeda, atau runtime berbeda. Pastikan satu eksperimen menyimpan semua parameter inferensi dan preprocessing. Jika ada perubahan format prompt, anggap itu kandidat baru yang memang harus dibandingkan secara eksplisit.

Biaya runner membengkak

GPU CI mahal, terutama jika setiap pull request memicu benchmark penuh. Solusi praktis:

  • gunakan smoke test murah di PR, benchmark penuh saat nightly atau release;
  • batasi benchmark pada file-path tertentu yang berubah;
  • cache weights dan dataset;
  • matikan job paralel yang tidak memberi sinyal keputusan tambahan.

Terlalu percaya pada satu benchmark publik

Leaderboard bisa membantu menyaring kandidat, tetapi tidak mewakili prompt, domain, dan SLA produk Anda. Evaluasi internal harus selalu menjadi sumber keputusan akhir.

Fokus hanya pada rata-rata

Rata-rata sering menutupi masalah ekor distribusi. Untuk produksi, p95 latency, error rate, dan kegagalan format pada kasus sulit biasanya lebih penting daripada sekadar mean score.

Strategi implementasi bertahap untuk tim engineering

Jika tim Anda belum punya pipeline evaluasi sama sekali, jangan langsung membangun sistem yang terlalu kompleks. Tahapan yang lebih realistis:

  1. Fase 1: versioning manifest, smoke benchmark, dan penyimpanan artifact hasil.
  2. Fase 2: baseline comparison dan policy gate otomatis untuk kualitas serta format validity.
  3. Fase 3: tambahkan metrik latensi dan biaya pada runner yang representatif.
  4. Fase 4: approval gate, dashboard historis, dan benchmark terjadwal untuk kandidat model baru.

Dengan pendekatan bertahap, tim bisa mendapat manfaat cepat tanpa menunggu infrastruktur evaluasi yang sempurna.

Penutup

CI untuk evaluasi model AI open weights yang reproducible pada dasarnya adalah disiplin software engineering: semua input harus terversi, semua hasil harus dapat diaudit, dan semua keputusan deploy harus ditopang metrik yang sebanding. Konteks model open weights yang terus membaik—termasuk keluarga model yang sedang menonjol seperti GLM-5.2—membuat frekuensi evaluasi naik, tetapi juga meningkatkan risiko keputusan yang terburu-buru jika pipeline internal belum matang.

Mulailah dari manifest eksperimen yang jelas, benchmark matrix yang hemat biaya, cache artifact yang benar, baseline pass/fail yang realistis, lalu tambahkan approval gate sebelum deploy. Jika fondasi ini rapi, tim dapat mengadopsi model baru lebih cepat tanpa mengorbankan reproducibility, biaya, atau stabilitas produk.