Model Update dan Change Log: Kenapa Eksperimen Harus Punya Versi

Selasa pagi, tim AI menjalankan benchmark.

Accuracy: 84 persen.

Tiga minggu kemudian benchmark yang sama dijalankan lagi.

Accuracy: 91 persen.

Semua senang.

“Prompt baru kita berhasil.”

Lalu seorang engineer membuka deployment config.

Ternyata model yang dipakai sudah berubah di tengah periode.

Prompt memang berubah.

Model juga berubah.

Retrieval configuration berubah.

Knowledge base di-update.

Sekarang angka 84 dan 91 tidak lagi menjawab satu pertanyaan.

Kita punya empat perubahan sekaligus.

Inilah alasan eksperimen AI harus punya versi dan change log.

Dalam software biasa, versioning sudah normal.

Release 1.2.

Build.

Commit.

Dependency.

Changelog.

Di AI, banyak tim justru kembali ke workflow “coba sekarang, screenshot, compare nanti”.

Masalahnya output generative sangat sensitif terhadap configuration.

Model.

Prompt.

System instruction.

Tool.

Retriever.

Dataset.

Temperature atau parameter lain jika tersedia.

Knowledge source.

Policy.

Post-processing.

Evaluation rubric.

Satu perubahan kecil bisa memengaruhi hasil.

Tanpa versioning, experiment kehilangan memory.

Model alias dan model snapshot bukan hal yang sama

OpenAI API mendokumentasikan model snapshots untuk sejumlah model. Snapshot memungkinkan developer mengunci versi tertentu agar performance dan behavior lebih konsisten dibanding menggunakan alias yang dapat menunjuk ke versi yang diperbarui.

Ini penting untuk eksperimen.

Kalau production memakai alias “latest”, bagus untuk mendapat improvement baru.

Tetapi untuk benchmark reproducibility, alias dapat menambah variable.

Jadi pisahkan kebutuhan.

Production objective:
latest capability atau vendor recommendation.

Experiment objective:
control variable.

Tidak selalu harus snapshot.

Tetapi experiment record harus tahu model identifier yang digunakan.

Kalau platform consumer tidak memberi model version detail, catat apa yang tersedia:

Product.

Mode.

Date.

Account state.

Known release.

Jangan mengarang version.

Unknown adalah metadata yang sah.

Version eksperimen bukan cuma model

Buat Experiment ID.

EXP-GEO-2026-081.

Lalu version stack:

Model: X.

Prompt: p3.

Retriever: r2.

Dataset: d5.

Evaluation rubric: e2.

Tool config: t1.

System policy: s4.

Sekarang satu run punya fingerprint.

Kalau result berubah, kita tahu apa yang berbeda.

Tanpa fingerprint, experiment mudah berubah menjadi:

“Kayaknya bulan lalu lebih bagus.”

Itu bukan evaluation.

Prompt juga harus versioned

Prompt sering diedit langsung di dashboard.

Tidak ada history.

Satu kalimat diubah.

Engineer lupa.

Output membaik.

Tidak ada yang tahu kenapa.

Simpan prompt seperti code.

p1:
baseline.

p2:
menambahkan instruction untuk cite source.

p3:
menambahkan refusal rule.

p4:
mengubah output format.

Setiap version punya:

Date.

Author.

Reason.

Expected effect.

Link ke test.

Tidak perlu Git untuk semua team, tetapi source control ideal untuk implementation yang critical.

Yang penting prompt tidak menjadi document cair tanpa history.

Dataset punya version

Ini lebih sering dilupakan daripada prompt.

Benchmark awal punya 100 query.

Kemudian 20 query baru ditambah.

Lima query lama diperbaiki karena typo.

Tiga ground-truth label berubah.

Sekarang dataset berbeda.

Jika tetap disebut “benchmark 100 query”, comparison misleading.

Version:

D1 = 100 query original.

D2 = 117 query after cleanup and expansion.

Kalau ingin trend continuity, pertahankan frozen core set.

Gunakan extended set untuk experiment baru.

Ini sama seperti AI Search query panel.

Data change adalah experiment change.

Evaluation rubric juga dependency

Model menjawab:

“Brand A termasuk salah satu pilihan populer.”

Reviewer lama memberi skor 1 karena brand disebut.

Reviewer baru memberi skor 0 karena tidak ada evidence.

Apakah model memburuk?

Tidak.

Rubric berubah.

Version rubric.

Definisi:

Mention.

Recommendation.

Citation.

Correctness.

Relevance.

Severity.

Tie-breaking.

Examples.

Inter-rater rule.

Kalau rubric e2 lebih ketat dari e1, report harus bilang.

Jangan membuat trend seolah comparable.

Change log harus mencatat “why”, bukan hanya “what”

Buruk:

“Updated prompt.”

Baik:

“p4, 8 Agustus 2026. Menambahkan instruction agar output membedakan product availability dan historical availability setelah ditemukan 7 stale-stock errors pada evaluation d3.”

Sekarang change punya reasoning.

Enam bulan kemudian tim mengerti.

Kalau p4 ternyata memperburuk latency atau conversion, mereka tahu trade-off.

Changelog menjadi institutional memory.

OpenAI sendiri menyediakan API changelog dan deprecation documentation untuk perubahan platform. Itu menunjukkan dependency eksternal juga berubah dan developer perlu memperhatikan lifecycle.

Organisasi internal sebaiknya punya discipline yang sama.

Satu eksperimen, satu variable idealnya

Praktik ideal:

Ubah prompt.

Model sama.

Data sama.

Retriever sama.

Rubric sama.

Compare.

Lalu uji model baru dengan prompt sama.

Ini memudahkan attribution.

Dalam real world kadang tidak mungkin.

Security fix harus masuk.

Model lama deprecated.

Source berubah.

Deadline dekat.

Kalau banyak variable berubah, jangan pura-pura A/B test bersih.

Label:

multi-variable release comparison.

Observation:
overall performance naik.

Causality:
tidak dapat diisolasi ke prompt.

Bahasa seperti ini lebih jujur.

Change log mengurangi overclaim.

Model update bisa memperbaiki satu hal dan merusak hal lain

Average score naik.

High-severity error juga naik.

Contoh.

Model baru lebih baik menjawab FAQ.

Tetapi lebih confident pada legal question.

Kalau hanya lihat aggregate, update terlihat sukses.

Regression suite diperlukan.

Kelompokkan eval:

Core factual.

Refusal.

High-risk.

Tool use.

Retrieval.

Commerce.

Language Indonesia.

Entity resolution.

Long context.

Critical business flow.

Setiap model update menjalankan subset yang relevan.

OpenAI secara publik mendorong penggunaan evals untuk mengukur apakah AI system memenuhi expectation bisnis.

Prinsip regression evaluation sejalan dengan itu.

Bukan karena ada satu template wajib.

Karena sistem berubah.

Change log tanpa eval hanya sejarah.

Eval tanpa change log sulit menjelaskan perubahan.

Version production deployment

Setiap production answer idealnya dapat dikaitkan ke configuration version.

Tidak perlu expose ke user.

Internal trace:

request ID.

model.

prompt version.

retriever.

knowledge snapshot.

tool version.

policy.

timestamp.

Kalau incident terjadi, kita bisa reproduce.

Tanpa version:

“Waktu customer komplain, system-nya pakai config yang mana?”

“Kayaknya yang baru.”

Kata “kayaknya” mahal di production.

Knowledge base juga perlu snapshot

RAG system memakai documentation.

Documentation berubah.

Answer berubah.

Team mengira model update yang menyebabkan.

Padahal source berubah.

Simpan knowledge version.

Tidak harus copy semua web setiap jam.

Untuk high-impact corpus, version document set.

Document ID.

Revision.

Effective date.

Index build.

Embedding model if relevant.

Chunking rule.

Sekarang retrieval change bisa dilacak.

AI Search external lebih sulit, tetapi principle observation tetap berlaku

Kita tidak mengontrol model ChatGPT consumer atau Google AI feature.

Tetapi program GEO masih bisa version-kan sisi kita.

Query panel v3.

Website evidence version.

Correction log.

Product feed revision.

Measurement methodology.

Test date.

Platform condition.

Kalau answer berubah setelah model update eksternal, report:

“Observed after platform change.”

Bukan:

“Page optimization menyebabkan perubahan.”

Causality harus earned.

Deprecation harus dianggap event eksperimen

Vendor menghentikan model.

OpenAI punya deprecation page untuk API model tertentu.

Ketika model deprecated, tim harus:

Identify experiments affected.

Freeze final baseline.

Migrate.

Run regression.

Update production version.

Document differences.

Archive old result.

Jangan overwrite historical score seolah model lama tidak pernah ada.

Experiment history penting untuk belajar.

Model change approval perlu risk-tier

Prototype:
developer boleh switch cepat.

Internal low-risk:
owner approval.

Customer-facing:
regression required.

High-stakes:
specialist review, legal/compliance/security sesuai use case.

Critical transaction:
controlled rollout, rollback plan.

Tidak semua model update butuh CAB meeting.

Tetapi “update otomatis karena latest lebih baru” juga terlalu santai untuk high-impact system.

Risk menentukan ceremony.

Shadow testing sangat berguna

Sebelum model baru aktif:

Run traffic sample secara shadow.

Bandingkan output.

Tidak memengaruhi user.

Cari regression.

Factual error.

Refusal.

Latency.

Cost.

Tool call.

Format.

Safety.

Language.

Kemudian canary.

5 persen traffic.

Monitor.

Naik bertahap.

Rollback jika threshold terlewati.

Ini software reliability mindset.

AI bukan pengecualian.

Versioning membuat rollback possible.

Kalau tidak tahu config sebelumnya, rollback hanya slogan.

Change log seharusnya bisa dibaca non-engineer

CEO tidak perlu commit hash.

Tetapi product owner perlu tahu:

Apa berubah.

Kenapa.

Apa expected impact.

Apa actual result.

Apa risk.

Apakah rollback tersedia.

Buat dua layer.

Technical change log.

Business release note.

Contoh:

Technical:
model snapshot X -> Y, prompt p4 -> p5.

Business:
“Update ditujukan untuk meningkatkan accuracy pada product policy. Evaluation menunjukkan improvement pada 80-query test set, tetapi latency naik 12 persen. Monitoring dua minggu.”

Jangan mengarang angka kalau tidak diuji.

Kalau belum ada result, tulis expected.

Experiment notebook harus punya failure

Jangan hanya log success.

Model update ditolak.

Prompt memburuk.

Retriever baru gagal.

Catat.

Failed experiment adalah evidence.

Kalau dihapus, enam bulan kemudian team mengulang hal yang sama.

Change log yang hanya berisi kemenangan adalah marketing document.

Engineering log harus menyimpan keputusan yang tidak jadi ship.

Versioning adalah perlindungan dari memory organisasi yang pendek

AI team bergerak cepat.

Orang pindah.

Model deprecated.

Dashboard berubah.

Vendor release update.

Prompt terus diedit.

Tanpa versioning, system menjadi hasil tumpukan keputusan yang tidak bisa ditelusuri.

Ketika performance berubah, kita menebak.

Dengan versioning:

Kita tahu baseline.

Kita tahu delta.

Kita tahu variable.

Kita tahu evidence.

Kita tahu rollback.

Eksperimen AI tidak harus lambat.

Justru versioning membuat eksperimen lebih cepat karena kegagalan tidak membuat kita kehilangan arah.

Setiap run meninggalkan jejak.

Setiap perubahan punya nama.

Setiap hasil terikat ke configuration.

Jadi ketika angka naik dari 84 ke 91, pertanyaan pertama bukan:

“Siapa yang mau bikin case study?”

Pertanyaan pertama:

“Version apa yang berubah, dan experiment ini sebenarnya membuktikan apa?”

Kalau tim bisa menjawab itu dalam satu menit, change log bekerja.

Ada satu hal lagi yang sering membuat experiment history kacau: baseline tidak dibekukan.

Tim bilang “compare ke baseline”, tetapi baseline ikut berubah karena source, prompt, atau dataset diperbaiki. Akhirnya semua experiment dibandingkan ke target bergerak.

Buat baseline release.

Misalnya BASE-2026-08-01.

Simpan model, prompt, dataset, rubric, dan configuration. Jangan edit baseline itu. Kalau baseline baru dibutuhkan, buat BASE-2026-09-01.

Dengan cara ini, improvement punya reference yang jelas.

Model registry juga layak dibuat walaupun sederhana.

Kolom:

model identifier,
provider,
status,
first tested,
production approval,
known limitation,
cost tier,
latency observation,
deprecation status,
replacement,
owner.

Tujuannya bukan membuat katalog semua model di dunia. Hanya model yang benar-benar digunakan organisasi.

Kalau vendor mengeluarkan model baru setiap bulan, team tidak harus ikut semuanya. Registry membantu memilih mana yang sudah diuji dan mana yang cuma menarik di announcement.

Change management juga perlu membedakan emergency patch dari planned experiment.

Emergency patch:
security, policy, factual bug, critical failure.

Tidak perlu menunggu experiment sempurna.

Tetapi setelah patch, lakukan retrospective eval dan catat deviation.

Planned experiment:
bisa mengikuti controlled comparison.

Jangan menggunakan alasan “kita agile” untuk menghapus traceability.

Agile berarti feedback cepat.

Bukan memory pendek.

Pada akhirnya, versioning membuat AI system lebih mudah diperlakukan seperti product serius, bukan demo yang terus berubah bentuk tanpa ada orang yang tahu versi mana yang sedang dibahas.