Di episode #43 saya sudah catat soal observability dan biaya saat AI masuk produksi. Kali ini saya mau naik satu tingkat: bagaimana menjalankan seluruh siklus pengembangan AI itu seperti layaknya proyek software biasa — ada eksperimen yang tercatat, ada versi yang bisa dibalik, ada pengganti yang menggagalkan perubahan jelek sebelum tayang. Ini catatan saya tentang LLMOps, dan jujur, bagi saya ini bagian yang paling terasa “kerjaan insinyur” dibandingkan bagian lain di Season 3.
Kenapa MLOps lama tidak cukup
Di Season 1 saya belajar bahwa model klasik dilatih sekali, dievaluasi, lalu di-deploy. “Model” -nya berupa file bobot, dan begitu file itu terkunci, perilakunya tetap. LLM membalik logika ini. Yang saya kirim ke produksi bukan cuma model, tapi kombinasi model + system prompt + contoh few-shot + parameter suhu + strategi retrieval. Semuanya bisa berubah tanpa saya sentuh kode sama sekali — provider bisa mengganti versi model di belakang layar, atau rekan tim mengedit prompt karena terlihat “lebih rapi”.
Ini berarti bagi saya: objek yang harus dikelola versinya bukan cuma bobot model, tapi seluruh konfigurasi itu. Kalau tidak ada catatan, saya tidak akan pernah tahu kenapa jawaban aplikasi berubah di hari Selasa.
Experiment tracking: satu baris untuk tidak lupa
Prinsipnya sama seperti ketika saya menulis unit test: kalau hasilnya tidak direkam, dia tidak ada. Untuk LLM, yang dicatat adalah trace — input, output, latensi, jumlah token, biaya — lalu dihubungkan dengan versi prompt dan konfigurasi yang menghasilkannya. MLflow 3 (rilis 11 Juni 2025, Databricks Data + AI Summit) memperkenalkan entitas LoggedModel sebagai objek primer, jadi trace, metrik, dan prompt bisa dikelompokkan per versi aplikasi, bukan per “run” seperti MLOps konvensional. Tracing-nya dibangun di atas OpenTelemetry, jadi bisa dibawa ke infrastruktur mana pun. Ini yang membuat saya tertarik: satu platform untuk eksperimen klasik maupun GenAI.
Alternatif open source yang sering muncul di komunitas: Langfuse (observability + eval agent, bisa self-host). Pilihannya bukan soal mana yang paling canggih, tapi mana yang paling mudah saya pasang di server sendiri.
Model registry dan prompt registry
Di git, saya terbiasa dengan tag rilis. Konsepnya di sini sama: kandidat yang sudah lolos evaluasi didaftarkan ke registry dengan status staging → production, dan rollback berarti kembali ke versi sebelumnya — bukan menggali-ngali riwayat chat. MLflow 3 juga membawa prompt registry dengan penelusuran versi bergaya Git, termasuk diff visual antar versi. Bagi saya ini penting karena prompt memang kode: satu kata yang berubah bisa mengubah perilaku model secara drastis. Kalau prompt tidak punya versi, evaluasi di episode #30 jadi percuma karena saya tidak tahu prompt mana yang sedang diukur.
CI/CD untuk prompt dan model
Ini bagian favorit saya, karena rasanya persis seperti menulis test di proyek biasa. Promptfoo, misalnya, menjalankan eval sebagai langkah CI: setiap perubahan pada file prompt memicu pengujian, dan hasilnya bisa dibuat jadi quality gate yang menggagalkan build. Contoh perintahnya kira-kira begini:
# eval + hentikan build kalau ada assertion yang gagal npx promptfoo@latest eval -c promptfooconfig.yaml --fail-on-error # quality gate: pass rate minimal 95% jq '.results.stats' results.json
Promptfoo menyediakan integrasi GitHub Actions, GitLab CI, CircleCI, sampai Jenkins (dokumentasinya masih diperbarui hingga November 2026). Syaratnya Node.js minimal 22.22.0 dan kunci API provider disimpan sebagai environment variable. Bagi saya, pelajaran utamanya bukan tool-nya: pelajarannya adalah bahwa perubahan prompt harus diperlakukan seperti perubahan kode — direview, diuji, baru digabung.
Monitoring drift dan kualitas setelah tayang
Setelah produksi, ada tiga jenis “perubahan diam” yang saya waspadai:
- Drift input — pertanyaan pengguna bergeser (misalnya musim liburan tiba, topik mendadak berbeda) sehingga distribusi data keluar dari yang pernah diuji.
- Drift kualitas — model atau prompt diganti pihak lain, skor groundedness turun pelan-pelan tanpa error teknis apa pun.
- Drift biaya & latensi — rata-rata token per permintaan naik karena konteks makin panjang (hubungannya erat dengan episode #56 soal context engineering).
Caranya: kumpulkan trace produksi secara berkala, jalankan ulang eval terhadapnya, dan bandingkan dengan baseline. MLflow 3 menyebutnya evaluation suite dengan LLM judge; intinya sama — dataset evaluasi dibangun dari percakapan nyata, bukan dari tebakan saya sendiri di meja kerja. Saya terapkan dengan begini: minggu pertama setelah rilis, saya audit 20–30 trace acak tiap minggu, lalu promosikan kasus-kasus gagalnya menjadi test case permanen.
Peta singkat tooling
| Kebutuhan | Contoh tool | Catatan |
|---|---|---|
| Experiment tracking & tracing | MLflow 3, Langfuse, Arize Phoenix | OpenTelemetry jadi acuan bersama |
| Registry prompt/model | MLflow Prompt Registry, model registry konvensional | Wajib ada rollback |
| Eval di CI | Promptfoo, LangSmith, Braintrust | Butuh quality gate eksplisit |
| Monitoring produksi | Langfuse, MLflow monitoring, provider observability | Audit trace berkala |
Kesimpulan yang saya bawa: LLMOps bukan lapisan tambahan yang berat, melainkan kebiasaan lama — catatan eksperimen, tag versi, test otomatis — yang saya pindahkan ke dunia prompt dan model. Bedanya, di sini “kodenya” bisa berubah perilaku lewat satu kalimat, jadi ketelitianannya justru lebih tinggi.
Sumber
- MLflow 3 release notes — https://mlflow.org/releases/3/
- Databricks blog: MLflow 3.0 — https://www.databricks.com/blog/mlflow-30-unified-ai-experimentation-observability-and-governance
- Langfuse (open source observability & eval) — https://github.com/langfuse/langfuse
- Promptfoo CI/CD integration — https://www.promptfoo.dev/docs/integrations/ci-cd
- OpenTelemetry — https://opentelemetry.io/
Komentar Terbaru