Belajar MLOps - LLMOps & GenAI Platforms

#Pendahuluan

Setelah supply chain di episode 20 diperkuat, kita masuk ke area yang paling cepat bergerak di MLOps: LLMOps — pengoperasian Large Language Model dan aplikasi GenAI. Semua yang kalian pelajari di episode 0-20 (tracking, pipeline, serving, monitoring, security) tetap berlaku, tetapi dengan beberapa pergeseran penting.

Mengapa LLMOps penting? Karena GenAI mengubah ekonomi pembuatan software: sekarang "fitur" bisa berupa model bahasa yang duduk di balik API. Tapi itu juga berarti pertanyaan operasional baru — bagaimana men-version prompt? Bagaimana mengevaluasi jawaban yang tidak ada ground truth tunggalnya? Bagaimana mencegah hallucination? Episode ini membedah fine-tuning (LoRA), RAG, vector DB, dan evaluasi LLM.

#LLMOps vs MLOps

Aspek	MLOps tradisional	LLMOps
Model	Dilatih dari nol	Pretrained, di-fine-tune / dipanggil via API
Artefak utama	Bobot model	Prompt, vector index, konfigurasi model
Biaya dominan	Training GPU	Inference & token
Evaluasi	Metrik otomatis	Perlu human/LLM judgment
Failure mode	Drift (episode 12)	Hallucination, injection (episode 18)

Perubahan terbesar: prompt adalah "kode" — ia artefak yang harus di-version, ditest, dan dipromosikan seperti kode.

#Fine-Tuning dengan LoRA

Fine-tuning penuh mengubah seluruh bobot model — mahal dan lambat. LoRA (Low-Rank Adaptation) hanya melatih dua matriks kecil yang menyatu ke bobot asli, sehingga biaya GPU turun drastis dengan hasil yang hampir setara pada banyak kasus.

text

Full fine-tuning:  W + ΔW       (semua bobot berubah)
LoRA:              W + A·B      (dua matriks rank-rendah yang dilatih)

Dalam praktiknya, LoRA adalah langkah yang dipilih ketika model base tidak cukup untuk domain spesifik — misalnya model hukum yang harus memahami istilah teknis. Dan karena hanya sebagian kecil parameter yang berubah, artifact LoRA mudah di-version dan di-deploy di atas model base yang sama.

#RAG Infrastructure

RAG (Retrieval-Augmented Generation) menjawab masalah data privat: alih-alih melatih ulang model, kita ambil konteks dari dokumen dan berikan ke model saat dipanggil. Ini arsitektur paling umum untuk GenAI produksi 2026.

100%

Tiga komponen yang harus dikelola dengan serius:

Chunking — ukuran dan cara pemecahan dokumen menentukan kualitas retrieval; terlalu besar = konteks kacau, terlalu kecil = konteks hilang.
Embedding model — versi embedding harus di-pin; mengganti embedding berarti vector index lama tidak kompatibel.
Vector database — pilihan populer: pgvector (jika sudah pakai Postgres), Milvus, Qdrant, atau Chroma untuk eksperimen.

#Prompt Management

Prompt yang bagus adalah aset yang harus dikelola seperti kode: di-version, di-test, dan dipromosikan. Simpan di registry, jangan hardcode.

Prompt versioned di registry

{
  "rag_prompt_v3": {
    "system": "Jawab berdasarkan konteks. Jika konteks tidak memuat jawaban, katakan tidak tahu.",
    "model": "gpt-4o-mini",
    "temperature": 0.2,
    "max_tokens": 512
  }
}

Kunci dari RAG yang aman: instruksi sistem yang tegas ("hanya pakai konteks") menjadi garis pertahanan pertama terhadap prompt injection (episode 18).

#Evaluasi LLM

Tanpa ground truth tunggal, evaluasi LLM membutuhkan pendekatan baru. RAGAS menyediakan metrik standar: faithfulness (apakah jawaban didukung konteks), answer relevancy, dan context precision/recall.

Evaluasi RAG dengan RAGAS

from ragas import evaluate
from ragas.metrics import faithfulness, answer_relevancy
 
result = evaluate(
    dataset=eval_ds,
    metrics=[faithfulness, answer_relevancy],
)
print(result)

Important

Kesalahan paling umum tim GenAI: lupa bahwa RAG juga butuh monitoring dan versioning. Vector index harus di-version seperti dataset (episode 6), prompt di-registry seperti model (episode 11), dan kualitas jawaban dievaluasi terus-menerus — bukan sekali saat demo. Tracking token dan biaya per prompt (episode 22) juga wajib.

#Guardrails

LLM tidak bisa dipercaya buta; ia butuh pagar di sekelilingnya:

Output filtering — validasi format (JSON), deteksi PII, cek isi berbahaya.
Input validation — deteksi pola prompt injection sebelum masuk ke model.
Fallback & refusal — jika input di luar cakupan, tolak dengan sopan alih-alih berhalusinasi.

#Praktik: Platform RAG Produksi

Arsitektur produksi yang disarankan:

text

Ingestion (batch):  Dokumen → chunking → embedding → vector index (versioned)
Serving (online):   Query → retrieve → prompt → LLM → guardrail → jawaban
Ops (terus-menerus): monitor cost/token, latency, faithfulness, retrain index saat dokumen berubah

Pipeline ingestion dan serving dipisahkan: ingestion bisa berjalan batch harian, serving melayani real-time. Keduanya tetap lewat CI/CD (episode 8) dan monitoring (episode 12).

#Common Pitfalls

Chunking asal-asalan — retrieval jelek; uji beberapa strategi chunking secara terukur.
Prompt hardcode di kode — tidak bisa di-version dan di-rollback; pakai registry.
Evaluasi subjektif ("jawabannya enak dibaca") — pakai metrik seperti faithfulness secara konsisten.
Tanpa guardrails — sistem RAG terbuka prompt injection (episode 18).
Vector index tidak di-version — dokumen berubah, index basi, dan tidak bisa ditelusuri versinya.

#Penutup

Pada episode 21 ini, kalian telah membangun fondasi LLMOps dan GenAI.

Inti yang harus dibawa pulang:

LLMOps menggeser artefak utama dari bobot ke prompt, vector index, dan konfigurasi.
LoRA = fine-tuning hemat GPU: hanya matriks rank-rendah yang dilatih.
RAG = arsitektur dominan: chunking + embedding + vector DB + retrieval + LLM.
Prompt di-registry, dievaluasi dengan RAGAS, dan dilindungi guardrails.
Pipeline RAG tetap butuh CI/CD, versioning, dan monitoring seperti model biasa.

Di episode 22 selanjutnya kita akan membahas cost & GPU optimization — mengukur GPU utilization, quantization, batching, dan strategi menekan biaya inference yang sering kali menjadi tagihan terbesar. Sampai jumpa di episode 22!