System Design untuk Sistem AI
Dari prototipe ke sistem produksi, arsitektur referensi enam layer, lima keputusan desain paling berdampak, dan checklist kesiapan produksi.
System design adalah kemampuan merancang sistem yang bisa bertahan di skala nyata, bukan hanya berjalan di laptop atau untuk satu pengguna. Bab ini membahas cara berpikir tentang arsitektur sistem AI secara holistik: bagaimana komponen-komponen yang sudah dipelajari di bab-bab sebelumnya dirakit menjadi sistem yang skalabel, andal, dan bisa di-maintain oleh tim.
22.1 Dari Prototipe ke Sistem Produksi
Ada jurang besar antara sistem yang berjalan untuk demo dan sistem yang bisa melayani ribuan pengguna sekaligus secara andal. Memahami jurang ini lebih awal mencegah keputusan arsitektur yang mahal untuk diubah di kemudian hari.
Prototipe / Demo
- Semua logika dalam satu file
- Tidak ada error handling
- Model di-load setiap request
- Tidak ada caching
- Tidak ada logging / monitoring
- Credentials di-hardcode
- Satu instance, tidak bisa scale
Sistem Produksi
- Separation of concerns yang jelas
- Error handling di setiap layer
- Model di-load sekali saat startup
- Caching berlapis (Bab 19)
- Observability via LangSmith
- Secrets via env / Secret Manager
- Horizontal scaling siap
22.2 Arsitektur Referensi Sistem AI Lengkap
Berikut arsitektur referensi yang menggabungkan semua komponen yang sudah dibahas di handbook ini menjadi satu sistem yang kohesif. Ini bukan satu-satunya cara yang benar, tapi merupakan titik awal yang solid untuk sebagian besar use case produksi.
22.3 Keputusan Desain yang Paling Berdampak
Dari semua keputusan arsitektur yang perlu dibuat, lima ini memiliki dampak terbesar pada kemampuan sistem untuk bertahan di produksi jangka panjang.
1. Synchronous vs Asynchronous Processing
Apakah pengguna harus menunggu LLM selesai menjawab (sync), atau request diterima segera dan jawaban dikirim nanti (async)?
Chatbot real-time, FAQ sederhana, sistem yang waktu respons <10 detik. Pengguna menunggu di UI, lebih sederhana diimplementasikan.
Pemrosesan dokumen panjang, analisis batch, tugas yang bisa memakan waktu menit. Request diterima, dikerjakan di background, hasilnya dikirim via webhook atau polling.
2. Stateless vs Stateful: Cara Menyimpan Riwayat Percakapan
LLM tidak punya memori antar request. Riwayat percakapan harus dikirim ulang setiap request. Di mana riwayat ini disimpan dan siapa yang mengirimkannya kembali?
Frontend menyimpan riwayat dan mengirimnya setiap request.
Pro: server stateless, mudah di-scale.
Kontra: riwayat hilang saat pengguna refresh browser.
Server menyimpan riwayat di Redis dengan session_id.
Pro: riwayat persisten, bisa diakses dari device berbeda.
Kontra: kompleksitas tambahan, biaya Redis.
3. Single Index vs Multi-Index di Vector Database
Apakah semua dokumen dari semua sumber masuk ke satu Pinecone index, atau setiap kategori dokumen punya index sendiri?
Lebih sederhana: satu index untuk semua dokumen, pisahkan menggunakan filter metadata. Cocok untuk mayoritas kasus. Lebih murah dan lebih mudah di-maintain.
Lebih terisolasi: dokumen HR di index berbeda dari dokumen teknis. Berguna ketika korpus sangat besar (>10M vektor) atau ketika tim yang berbeda mengelola dokumen yang berbeda.
4. Kapan Re-indexing Diperlukan
Dokumen baru ditambahkan, dokumen lama diperbarui atau dihapus, model embedding diganti (wajib full re-index), atau kualitas retrieval turun signifikan.
Gunakan upsert untuk menambah atau memperbarui dokumen individual. Lebih efisien dari full re-index, cocok untuk perubahan dokumen yang kecil dan sering.
Hanya ketika model embedding berubah, karena vektor dari model berbeda tidak bisa dibandingkan. Rencanakan ini sebagai operasi yang memerlukan downtime singkat atau blue-green deployment.
5. Graceful Degradation: Apa yang Terjadi Ketika Komponen Gagal
Pinecone down → tidak bisa retrieve. LLM API rate limit → tidak bisa generate. Redis down → caching tidak berfungsi. Setiap komponen bisa gagal secara independen.
Sistem sebaiknya tetap memberikan sesuatu yang berguna meski tidak sempurna, bukan crash total. Jika Pinecone down, kembalikan pesan "layanan sedang gangguan" yang jelas. Jika Redis down, bypass cache dan langsung ke LLM.
Setiap pemanggilan komponen eksternal harus dibungkus try-except dengan fallback yang sudah didefinisikan. Tambahkan circuit breaker untuk mencegah cascade failure ketika satu komponen lambat mempengaruhi seluruh sistem.
22.4 Checklist Kesiapan Produksi
Sebelum sistem AI dinyatakan siap untuk pengguna nyata, gunakan checklist berikut sebagai verifikasi akhir, bukan sebagai formalitas, tapi sebagai alat untuk menemukan celah yang terlewat.
- Semua API key dan secrets disimpan di Secret Manager atau env var, tidak ada yang hardcode di kode
- Input dari pengguna divalidasi oleh Pydantic sebelum diproses
- System Prompt memiliki instruksi eksplisit untuk menangani prompt injection
- Access control berbasis metadata diimplementasikan jika ada dokumen dengan level sensitivitas berbeda
- Test set minimal 15-20 pertanyaan sudah dibuat dan dijalankan, skor retrieval dan generation di atas 80%
- Halucination test sudah dijalankan, sistem menjawab dengan pesan fallback untuk pertanyaan di luar domain
- Sumber dokumen ditampilkan bersama setiap jawaban
- Temperature disetel rendah (0.0-0.1) untuk sistem RAG
- LangSmith sudah diaktifkan dan latency P95 sudah diukur baseline-nya
- Caching minimal sudah diimplementasikan (exact cache atau semantic cache)
- Estimasi biaya per hari sudah dihitung berdasarkan traffic yang diperkirakan
- Alert biaya sudah dikonfigurasi di dashboard LLM provider
- Aplikasi sudah berjalan di Docker container dan diuji dengan docker run sebelum deployment
- Endpoint /health sudah ada dan merespons dengan benar
- Error handling sudah diimplementasikan, detail teknis tidak pernah terekspos ke pengguna
- Graceful degradation sudah direncanakan untuk setiap komponen eksternal yang bisa gagal
Kesalahan Umum
Over-engineering adalah salah satu pemborosan waktu yang paling umum di tahap awal. Sistem yang bisa melayani 100 pengguna dengan arsitektur sederhana jauh lebih baik dari sistem yang dirancang untuk 1 juta pengguna tapi tidak pernah selesai dibangun. Mulai sederhana, ukur, dan scale ketika benar-benar dibutuhkan.
Percakapan yang panjang berarti semakin banyak token yang harus dikirim ke LLM setiap request, dan biaya naik secara linear. Selalu implementasikan strategi pemotongan riwayat: batasi ke N pesan terakhir, atau summarize riwayat lama menjadi ringkasan singkat yang disertakan di awal konteks.
Pertanyaan "bagaimana cara memperbarui dokumen yang sudah diindeks?" harus dijawab sebelum bukan sesudah sistem live. Tentukan: siapa yang bertanggung jawab menambahkan dokumen baru, bagaimana proses review sebelum diindeks, dan kapan full re-index diperlukan vs inkremental upsert.
Matikan Pinecone, matikan Redis, matikan LLM API, dan lihat apa yang terjadi pada sistemmu. Jika hasilnya adalah crash yang tidak terkontrol, perbaiki sekarang. Graceful degradation yang baik berarti pengguna mendapat pesan yang jelas dan sistem pulih sendiri ketika komponen yang gagal kembali normal.
Ringkasan Bab 22
- Saya bisa menjelaskan perbedaan antara prototipe dan sistem produksi dari segi error handling, caching, observability, secrets management, dan kemampuan scaling.
- Saya memahami arsitektur referensi enam layer: Client, API Gateway, Cache, AI Logic, Data Services, Infrastruktur, dan peran setiap layer.
- Saya bisa memutuskan antara synchronous vs asynchronous processing berdasarkan karakteristik tugas dan ekspektasi pengguna.
- Saya memahami trade-off antara menyimpan riwayat percakapan di client-side vs server-side (Redis), dan tahu kapan masing-masing lebih tepat.
- Saya bisa memutuskan antara single index dengan metadata filter vs multi-index di Pinecone, dan tahu kapan full re-index diperlukan vs inkremental upsert.
- Saya sudah merencanakan graceful degradation untuk setiap komponen eksternal yang bisa gagal, dan mengujinya sebelum sistem live.
- Saya menggunakan checklist kesiapan produksi sebagai verifikasi akhir sebelum sistem dinyatakan siap untuk pengguna nyata.