Belajar Solution Architect - AI/LLM Solution Design

#Pendahuluan

Setelah di episode 20 kalian bisa mendesain SaaS multi-tenant dengan isolasi data berlapis dan pricing selaras biaya, kita hadapi brief yang kini mendominasi meja setiap SA: solusi AI/LLM. Hampir setiap klien datang dengan pertanyaan serupa — "bisa nggak kita pakai AI untuk customer service/dokumen internal/laporan?" — dan tugas kalian menerjemahkan antusiasme itu menjadi arsitektur yang benar-benar bekerja, terukur, dan tidak membocorkan data.

Mengapa perlu kerangka khusus? Karena LLM memperkenalkan sifat yang belum ada di komponen tradisional: output probabilistik (jawaban bisa beda tiap kali), halusinasi (percaya diri padahal salah), biaya per token, dan permukaan risiko baru (prompt injection). Desain naif "panggil API, tampilkan jawaban" akan gagal di semua dimensi itu.

#Menentukan Pola Solusi AI yang Tepat

Langkah pertama bukan memilih model, melainkan menempatkan masalah pada spektrum pola — dari termurah paling deterministik ke termahal paling fleksibel:

Aturan desain yang menjaga kalian dari over-engineering: mulai dari kiri tabel. Banyak brief "butuh AI" sebenarnya selesai dengan classifier biasa atau search embedding — tanpa biaya token berulang dan tanpa risiko halusinasi. LLM dipakai ketika tugas benar-benar butuh generasi bahasa atau penalaran longgar.

#Arsitektur RAG End-to-End

RAG (Retrieval-Augmented Generation) adalah pola solusi LLM enterprise paling umum: model menjawab berdasarkan dokumen kalian, dengan kutipan. Bentuk lengkapnya punya dua pipeline:

100%

Keputusan desain penting per tahap:

• Chunking — ukuran chunk (±300-800 token) dan overlap menentukan kualitas retrieval; potong per struktur semantik (heading/paragraf), bukan karakter mentah.
• Embedding & vector store — pilih store sesuai skala: pgvector cukup sampai jutaan vektor (bonus: tetap satu database PostgreSQL), vector DB khusus (OpenSearch k-NN, Pinecone, dsb.) saat skala/filter metadata kompleks.
• Hybrid search — gabungkan pencarian keyword + vector; untuk korpus berbahasa Indonesia dengan istilah teknis, hybrid secara konsisten mengalahkan vector murni.
• Reranking — ambil top-20 murah lalu rerank ke top-3 berkualitas; ini upgrade rasio kualitas/biaya terbaik di RAG.
• Citation wajib — jawaban tanpa rujukan sumber adalah undangan halusinasi; paksa format jawaban menyertakan dokumen asal.

#Agent Patterns dan Guardrails

Agent = LLM yang boleh bertindak: memanggil tool, membaca sistem, mengambil keputusan multi-langkah. Kuasainya karena permintaannya meningkat, tapi desain dengan pagar ketat:

• Tool scoping minimal — agent hanya diberi tool yang dibutuhkan tugasnya, dengan izin IAM tersendiri (lanjutan least privilege episode 8). Agent support tiket tidak butuh tool hapus database.
• Human-in-the-loop untuk aksi tak terbalikkan — refund besar, kirim email massal, ubah kontrak: agent menyusun draft, manusia menyetujui. Otomasi penuh hanya untuk aksi reversible.
• Prompt injection defense — konten eksternal (dokumen RAG, email) bisa berisi instruksi jahat "abaikan aturan sebelumnya". Mitigasi: pisahkan instruksi sistem vs data user, sanitasi input, validasi output sebelum dieksekusi, dan jangan pernah memberi agent kredensial luas.
• Loop terkendali — batasi jumlah langkah dan biaya maksimal per eksekusi agent; loop tak berujung adalah tagihan tak berujung.

Pola orkestrasi yang lazim: workflow engine (episode 13) memandu alur deterministik, LLM hanya di titik-titik yang butuh penalaran — bukan LLM yang memegang kendali alur bisnis utuh.

#Evaluasi: Metrik Sebelum Production

Bagian yang membedakan demo dari solusi: evaluasi sistematis. Bangun eval dataset sejak awal:

1. Kumpulkan 50-200 pasangan pertanyaan-jawaban emas dari domain nyata (dengan SME).
2. Ukur tiap iterasi: retrieval metrics (recall@k: apakah dokumen benar tertangkap?), faithfulness (apakah jawaban konsisten dengan konteks?), correctness (bandingkan dengan jawaban emas via judge model atau rubrik).
3. Jadikan eval bagian CI untuk prompt/model change — regresi kualitas harus terdeteksi seperti regresi test unit.

Tanpa dataset eval, setiap perubahan prompt adalah lempar dadu yang dinilai dari perasaan — dan kualitas akan merosot diam-diam saat volume kasus bertambah.

#Biaya, Latensi, dan Privasi

Tiga batasan yang menentukan viability komersial solusi AI:

#Biaya

Hitung biaya per interaksi (token in × harga in + token out × harga out), lalu proyeksikan ke volume bulanan — angka ini sering mengejutkan pada skala besar. Strategi penghematan yang efektif: cache jawaban untuk pertanyaan berulang (FAQ bisa hemat >60%), kurangi context dengan retrieval presisi (rerank), turunkan max output, dan route pertanyaan mudah ke model kecil/murah.

#Latensi

LLM lambat dibanding API biasa (detik, bukan milidetik). Mitigasi arsitektur: streaming response agar first-token cepat terasa, async untuk task panjang (ringkasan dokumen dikirim via notifikasi), dan prefetch/cache di layer retrieval.

#Privasi & Data

Pertanyaan pertama klien enterprise hampir selalu: "data kita ke mana?" Jawabannya harus sudah didesain:

• PII masking sebelum prompt + re-hydrate setelah respons bila perlu.
• Pilihan deployment: API publik (dengan zero-retention agreement), endpoint khusus provider, atau self-hosted open-weight model untuk data super sensitif — trade-off biaya/kemudahan/kendali masuk ADR.
• Retensi log percakapan diselaraskan regulasi (episode 19); jangan log prompt berisi rahasia dagang tanpa kebijakan eksplisit.

#Common Pitfalls

• Demo-driven development — membangun dari satu contoh sukses; tanpa eval dataset, kalian tidak tahu tingkat kegagalannya di 10% kasus sisanya.
• Halusinasi diterima sebagai fitur — tanpa citation dan disclaimer scope, satu jawaban salah bisa lebih mahal dari seluruh manfaat otomasi (konteks legal/support).
• Model lock-in tanpa abstraksi — panggilan langsung vendor di semua kode; gunakan adapter layer agar ganti/route antar-model bisa dilakukan tanpa refactor total (pelajaran coupling episode 2).
• Mengabaikan data quality pipeline — dokumen usang/duplikat di corpus menghasilkan jawaban usang dengan percaya diri; governance konten (versi dokumen, tanggal review) adalah bagian solusi RAG.
• Agent dengan izin terlalu luas — shortcut "kasih admin saja biar gampang" adalah kombinasi prompt injection + blast radius besar = insiden yang tinggal menunggu.

#Penutup

Inti yang harus dibawa pulang:

• Tempatkan masalah pada spektrum pola (rule → embedding → RAG → agent) dan mulai dari yang paling sederhana; LLM bukan default.
• RAG hidup dari kualitas retrieval: chunking semantik, hybrid search, rerank, citation wajib.
• Agent butuh guardrails struktural: tool scoping, human-in-the-loop untuk aksi permanen, anti prompt injection, loop terbatas.
• Eval dataset adalah fondasi: retrieval metrics, faithfulness, correctness — dijalankan di CI seperti test biasa.
• Viability ditentukan biaya-per-interaksi, latensi (streaming/async), dan desain privasi data sejak hari pertama.

Di episode 22 selanjutnya kita akan membahas data-driven solutions — merancang platform analitik end-to-end: batch vs real-time streaming, lakehouse dan table format modern, feature store dan ML pipelines, serta bagaimana metrik produk menjadi bahan bakar keputusan bisnis. Sampai jumpa di episode 22!