Build vs Buy di Era GenAI: Studi Kasus RAG, Observability, dan Keputusan Strategis CTO

Bayangkan sebuah tim developer di perusahaan mid-size yang semangat membangun asisten berbasis dokumen internal. Tujuannya sederhana: membantu karyawan menemukan kebijakan perusahaan, SOP, dan informasi onboarding cukup dengan bertanya ke bot. Ide ini terasa masuk akal, apalagi sejak GenAI menjadi arus utama. Tim merasa: “Kami cukup jago, ini bisa kami bangun sendiri.”

Mereka mulai dengan pendekatan Retrieval-Augmented Generation (RAG). Langkah awal terlihat cepat: parsing dokumen PDF, memecahnya ke dalam paragraf kecil, dan menyimpan embedding-nya ke vector database. Dalam waktu seminggu, MVP sudah bisa menjawab pertanyaan seperti “berapa hari cuti melahirkan?”, meski belum selalu akurat. Tapi di minggu kedua, mereka mulai masuk ke wilayah yang tak lagi indah: pertanyaan yang makin kompleks tidak bisa dijawab. Kadang jawaban keluar dari dokumen yang tidak relevan. Kadang latency tinggi. Kadang sistem crash karena beban memori dari vector DB yang tidak mereka pahami sepenuhnya.

Lalu muncul pertanyaan di ruang meeting: “Apa kita terlalu cepat membangun dari nol?”

Anatomi Sistem RAG: Apa yang Terjadi di Balik Layar

Membangun sistem RAG lebih dari sekadar menyimpan teks ke vector database dan memanggil LLM. Di balik satu pertanyaan sederhana seperti “Apa yang harus saya siapkan untuk klaim BPJS?”, terjadi rangkaian proses teknikal yang kompleks:

Pertama, dokumen yang diunggah harus diproses. Ini bukan sekadar OCR — banyak PDF dari instansi pemerintahan atau HR korporasi memiliki struktur tabel, heading, dan nested list yang jika hilang, akan membuat isi dokumen susah dimengerti oleh model. Proses chunking juga krusial. Banyak tim hanya memotong setiap 500 karakter, tapi gagal mempertahankan konteks. Beberapa tim lanjutan mencoba overlap window, atau bahkan classifier untuk membedakan “bagian penting” dan “tambahan legal”.

Lalu embedding: mau pakai text-embedding-3-small dari OpenAI? Atau mau coba model lokal seperti bge-small atau Cohere Embed? Pilihan ini memengaruhi latency, biaya, dan akurasi. Embedding disimpan ke dalam vector DB. Di sinilah tim mulai kesulitan: Pinecone memang mudah digunakan, tapi apa cukup cepat dan murah? Bagaimana dengan Qdrant, Weaviate, Milvus?

Yang sering luput dari perhatian adalah observability. Di minggu keempat, tim tak lagi bisa menebak kenapa jawaban model makin tidak relevan. Tanpa tracing flow dari pertanyaan → retrieval → LLM prompt → output, developer buta. Akhirnya mereka mulai menambahkan log: berapa vector yang diambil? Dari dokumen mana? Waktu respons LLM? Model mana yang dipakai? Versi chunking mana yang dipakai minggu ini? Tanpa observability yang jelas, sistem terasa seperti black box — dan engineer frustrasi.

Untuk memahami kompleksitas sistem RAG secara teknikal, berikut adalah alur proses yang umum digunakan di proyek-proyek real-world yang melibatkan LLM dan dokumen internal:

 

[User Question]

      ↓

[Preprocessing Layer] ← Optional (e.g., rephrasing, detection)

      ↓

[Retrieval Engine]

   (Vector DB + Filtering)

      ↓

[Retrieved Chunks/Docs]

      ↓

[Prompt Builder]

   (Context + Question → Final Prompt)

      ↓

[LLM Inference API]

   (OpenAI / Anthropic / Claude / Bedrock)

      ↓

[LLM Response]

      ↓

[Postprocessing & Streaming]

      ↓

[Frontend UI (Chat)]

Untuk observability dan debugging, berikut flow tambahan yang bisa ditempel di tiap tahap:

 

OBSERVABILITY / LOGGING POINTS
	User question text & timestamp
Retrieval result: top-k docs + metadata (score)
Time taken by vector DB (latency, count)
Embedding model version used
Prompt sent to LLM (raw)
Model version + latency
Response content
Feedback loop (if user rates answer)

 

Keputusan Strategis CTO: Bangun Sendiri atau Integrasi Platform?

Di titik ini, Tech Lead mulai merapat ke CTO: “Kita sudah habiskan 1,5 bulan, hasilnya belum stabil. Harusnya kita pakai platform yang udah jadi dulu ya?”

Ini bukan percakapan baru. CTO modern tidak hanya harus paham teknologi, tapi juga tahu bagaimana mengelola risiko teknikal sebagai risiko bisnis. Mereka sadar bahwa membangun sendiri memberi fleksibilitas, tapi menyita waktu dan tenaga tim yang terbatas. Di sisi lain, menggunakan platform pihak ketiga mempercepat validasi use case dan memungkinkan tim fokus pada keunggulan kompetitif.

Kapan sebaiknya membangun sendiri?

• Jika datanya sangat spesifik atau sensitif, misalnya dokumen finansial internal atau aset intelektual. 
• Jika model atau pipeline yang dibutuhkan sangat berbeda dari produk umum di pasaran. 
• Jika ingin punya kontrol penuh atas cost, security, dan behavior sistem. 

Kapan integrasi lebih cerdas?

• Jika use case masih dalam fase eksperimentasi dan butuh pembuktian cepat. 
• Jika tim belum punya kapasitas observability dan evaluasi model secara andal. 
• Jika CTO ingin time-to-market dalam hitungan minggu, bukan kuartal. 

Pada akhirnya, ini bukan soal gengsi teknikal. CTO yang matang tahu kapan harus membangun, dan kapan harus mengintegrasikan — bahkan keduanya bisa berjalan bersamaan. Bangun di bagian yang kritikal. Integrasikan untuk fungsi-fungsi umum. Fokuskan energi tim pada hal-hal yang benar-benar memberi nilai tambah untuk bisnis.