Rancang Bangun Sistem RAG (Retrieval-Augmented Generation) Skala Enterprise Menggunakan LLM Lokal

1. Konteks Industri & Analisis Akar Masalah

Dalam lanskap enterprise modern, kebutuhan akan sistem pemrosesan informasi berbasis kecerdasan buatan yang menjaga kedaulatan data (data sovereignty) menjadi hal yang mutlak. Banyak perusahaan terjebak dalam dilema antara memanfaatkan Large Language Model (LLM) komersial pihak ketiga yang menawarkan kemampuan kognitif tinggi namun rentan terhadap kebocoran data sensitif (seperti data finansial, kekayaan intelektual, dan PII), atau membangun sistem internal yang aman namun sering kali mengalami halusinasi (hallucination) dan ketinggalan konteks informasi spesifik perusahaan.

Retrieval-Augmented Generation (RAG) hadir sebagai solusi arsitektural yang menjembatani kesenjangan tersebut. RAG memungkinkan LLM lokal (seperti Llama 3 atau Mistral yang berjalan di infrastruktur on-premise) untuk mengakses basis pengetahuan eksternal secara dinamis melalui pencarian vektor (vector search). Namun, merancang RAG skala enterprise bukanlah perkara menyambungkan skrip Python sederhana ke database vektor. Tantangan nyata di dunia produksi melibatkan latensi tinggi, manajemen memori GPU/CPU yang ketat, konsumsi token yang membengkak, sinkronisasi data real-time, hingga proteksi keamanan infrastruktur web.

Kondisi Sebelum vs Sesudah Penerapan Sistem RAG Enterprise

• Sebelum RAG:
  • Ketergantungan API Eksternal: Mengirim data perusahaan ke LLM komersial, melanggar regulasi kepatuhan seperti GDPR, HIPAA, atau UU PDP.
  • Halusinasi Tinggi: Model memberikan jawaban yang tampak meyakinkan namun salah secara faktual karena tidak memiliki akses ke dokumen internal terbaru.
  • Statis: Pengetahuan model terbatas pada waktu pelatihan terakhir (cutoff date) dan tidak dapat memperbarui diri secara instan ketika ada kebijakan baru perusahaan.
• Sesudah RAG (Lokal & Terdistribusi):
  • Kedaulatan Data Penuh: Seluruh pemrosesan, mulai dari embedding, penyimpanan vektor, hingga inferensi LLM, berjalan di dalam infrastruktur privat yang dikendalikan penuh oleh tim infrastruktur.
  • Akurasi Berbasis Konteks: Jawaban didasarkan pada dokumen referensi nyata yang diambil secara presisi (ground-truth), meminimalkan halusinasi secara drastis.
  • Skalabilitas Tinggi: Integrasi dengan arsitektur web modern (Nginx, Go/Node backend, Redis caching, dan Qdrant/Milvus cluster) menjamin ketersediaan tinggi (high availability) di bawah beban traffic enterprise.

2. Konsep Inti & Deep Dive Arsitektur

Sistem RAG Enterprise bekerja melalui dua fase utama: Fase Ingesti Dokumen (Offline Pipeline) dan Fase Query/Inferensi (Online Pipeline).

Alur Eksekusi Data (Data Flow Architecture)

[Dokumen Sumber: PDF/Docx/DB] 
          │
          ▼
[Web/Backend Service (Go/PHP)] ──> [Text Chunking & Normalization]
                                              │
                                              ▼
                                   [Embedding Model (Local CPU/GPU)]
                                              │
                                              ▼
                                   [Vector DB Cluster (Qdrant/Milvus)]

----------------- [Online / Inference Pipeline] -----------------

[Client Request (Web/Mobile)] 
          │
          ▼
[Nginx Reverse Proxy / WAF]
          │
          ▼
[Backend API Gateway] ──> [Redis Cache Layer (Query Hash Check)]
          │                                 │ (Cache Miss)
          ▼                                 ▼
[Embedding Query] ──────> [Vector Search (Top-K Similarity)]
          │
          ▼
[Prompt Assembler (Context + User Query)]
          │
          ▼
[Local LLM Inference Engine (Ollama / vLLM / llama.cpp)]
          │
          ▼
[Stream Response via WebSocket/SSE to Client]

Penjelasan Komponen Utama

1. Ingestion Pipeline: Dokumen perusahaan diambil dari penyimpanan objek (S3/MinIO), diurai, dipecah menjadi potongan-potongan kecil (chunks), diubah menjadi representasi numerik (embeddings), lalu disimpan ke Vector Database.
2. Inference Pipeline: Pengguna mengirimkan pertanyaan melalui antarmuka web. Permintaan diverifikasi oleh WAF dan API Gateway. Sistem membuat embedding dari pertanyaan tersebut, mencari dokumen yang paling relevan di Vector DB menggunakan metrik jarak kosinus (cosine similarity), menggabungkan hasil pencarian dengan prompt asli, lalu mengirimkannya ke LLM lokal untuk menghasilkan jawaban.

3. Perbandingan Komparatif / Analisis Pendekatan

Dalam membangun infrastruktur RAG, pemilihan Vector Database dan Inference Engine sangat menentukan performa jangka panjang. Berikut adalah perbandingan mendalam antara dua database vektor terkemuka untuk enterprise: Qdrant vs Milvus.

[!TIP] Gunakan Qdrant jika tim Anda membutuhkan kecepatan deployment, efisiensi resource di lingkungan on-premise, dan pengelolaan metadata yang kompleks. Pilih Milvus jika skala data perusahaan Anda telah mencapai puluhan juta hingga miliaran vektor dengan arsitektur multi-node Kubernetes.

4. Prasyarat Sistem & Persiapan Lingkungan

Sebelum melangkah ke implementasi teknis, pastikan spesifikasi infrastruktur server Anda memenuhi standar produksi minimal berikut:

• OS: Ubuntu Server 22.04 LTS / Debian 12 (Kernel Linux >= 5.15)
• Hardware:
  • CPU: Min. 16 vCPU (Intel Xeon / AMD EPYC dengan dukungan AVX-512)
  • RAM: Min. 64 GB ECC RAM
  • GPU: NVIDIA RTX 4090 / A10G / L4 (VRAM min. 24GB untuk menjalankan model LLM 8B/13B terquantisasi)
• Software Stack:
  • Docker & Docker Compose (v2.20+)
  • Nginx (Reverse Proxy & SSL Termination)
  • Go 1.22+ atau Node.js 20 LTS (untuk backend API)
  • Redis 7+ (untuk caching dan rate limiting)

Verifikasi Driver GPU & NVIDIA Container Toolkit

Pastikan driver NVIDIA dan container toolkit telah terpasang agar kontainer Docker dapat mengakses GPU secara langsung:

# Verifikasi instalasi NVIDIA driver di host
nvidia-smi

# Verifikasi NVIDIA Container Toolkit
docker run --rm --gpus all nvidia/cuda:12.1.0-base-ubuntu22.04 nvidia-smi

5. Panduan Implementasi Langkah demi Langkah

Langkah 1: Konfigurasi Docker Compose untuk Seluruh Ekosistem RAG

Buat file docker-compose.yml untuk mengelola Qdrant, Ollama (LLM Engine), Redis, dan Backend API dalam satu jaringan privat.

version: '3.8'

networks:
  rag_internal:
    driver: bridge

services:
  qdrant:
    image: qdrant/qdrant:v1.9.0
    container_name: qdrant_enterprise
    restart: always
    ports:
      - "6333:6333"
      - "6334:6334"
    volumes:
      - qdrant_storage:/qdrant/storage
    networks:
      - rag_internal
    environment:
      - QDRANT__SERVICE__HTTP_PORT=6333
      - QDRANT__SERVICE__GRPC_PORT=6334

  ollama:
    image: ollama/ollama:latest
    container_name: ollama_engine
    restart: always
    ports:
      - "11434:11434"
    volumes:
      - ollama_data:/root/.ollama
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: all
              capabilities: [gpu]
    networks:
      - rag_internal

  redis:
    image: redis:7.2-alpine
    container_name: redis_cache
    restart: always
    ports:
      - "6379:6379"
    command: redis-server --requirepass "SecureRedisPassword2024!"
    networks:
      - rag_internal

volumes:
  qdrant_storage:
  ollama_data:

Jalankan stack infrastruktur:

docker compose up -d

Langkah 2: Mengunduh Model LLM & Embedding Lokal

Masuk ke dalam kontainer Ollama untuk mengunduh model bahasa besar (misal: Llama 3) dan model embedding (misal: BGE-Large).

docker exec -it ollama_engine ollama run llama3:8b-instruct-q4_K_M
docker exec -it ollama_engine ollama pull bge-large

Langkah 3: Implementasi Backend Go untuk Pemrosesan RAG

Buat direktori proyek Go baru, inisialisasi modul, dan tulis kode utama untuk menangani ingestion dan query. Buat file main.go:

package main

import (
	"bytes"
	"context"
	"encoding/json"
	"fmt"
	"logfledged"
	"net/http"
	"os"

	"github.com/qdrant/go-client/qdrant"
	"google.golang.org/grpc"
	"google.golang.org/grpc/credentials/insecure"
)

type QueryRequest struct {
	Query string `json:"query"`
}

func main() {
	// Inisialisasi koneksi gRPC ke Qdrant Vector DB
	conn, err := grpc.Dial("localhost:6334", grpc.WithTransportCredentials(insecure.NewCredentials()))
	if err != nil {
		log.Fatalf("Gagal terhubung ke Qdrant: %v", err)
	}
	defer conn.Close()

	client := qdrant.NewCollectionsClient(conn)
	_ = client // Digunakan untuk manajemen koleksi di implementasi nyata

	http.HandleFunc("/api/v1/rag/query", handleRAGQuery)
	
	fmt.Println("RAG Enterprise Backend berjalan pada port 8080...")
	log.Fatal(http.ListenAndServe(":8080", nil))
}

func handleRAGQuery(w http.ResponseWriter, r *http.Request) {
	if r.Method != http.MethodPost {
		http.Error(w, "Method not allowed", http.StatusMethodNotAllowed)
		return
	}

	var req QueryRequest
	if err := json.NewDecoder(r.Body).Decode(&req); err != nil {
		http.Error(w, err.Error(), http.StatusBadRequest)
		return
	}

	// 1. Dapatkan Embedding untuk Query dari Ollama
	embedding := fetchEmbeddingFromOllama(req.Query)

	// 2. Lakukan Vector Search di Qdrant (Simulasi Top-K)
	// 3. Gabungkan Konteks Dokumen dengan Query
	// 4. Kirim ke LLM untuk Inferensi Akhir
	
	response := map[string]string{
		"status": "success",
		"query":  req.Query,
		"answer": "Contoh jawaban hasil sintesis RAG lokal berdasarkan dokumen internal perusahaan.",
	}

	w.Header().Set("Content-Type", "application/json")
	json.NewEncoder(w).Encode(response)
}

func fetchEmbeddingFromOllama(text string) []float32 {
	payload := map[string]string{
		"model":  "bge-large",
		"prompt": text,
	}
	jsonPayload, _ := json.Marshal(payload)

	resp, err := http.Post("http://localhost:11434/api/embeddings", "application/json", bytes.NewBuffer(jsonPayload))
	if err != nil {
		log.Printf("Error embedding: %v", err)
		return nil
	}
	defer resp.Body.Close()

	var result struct {
		Embedding []float32 `json:"embedding"`
	}
	json.NewDecoder(resp.Body).Decode(&result)
	return result.Embedding
}

Langkah 4: Konfigurasi Nginx Reverse Proxy

Konfigurasikan Nginx sebagai pintu gerbang utama yang mengamankan komunikasi eksternal dan melakukan terminasi SSL.

server {
    listen 80;
    server_name rag.enterprise.internal;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl http2;
    server_name rag.enterprise.internal;

    ssl_certificate /etc/letsencrypt/live/rag.enterprise.internal/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/rag.enterprise.internal/privkey.pem;
    
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers HIGH:!aNULL:!MD5;

    client_max_body_size 50M;

    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        
        # Konfigurasi Timeout Panjang untuk Streaming LLM
        proxy_read_timeout 300s;
        proxy_send_timeout 300s;
    }
}

6. Bedah Kode & Penjelasan Detail Baris Kunci

• grpc.Dial("localhost:6334", ...): Komunikasi backend Go dengan Qdrant menggunakan protokol gRPC pada port 6334. gRPC dipilih alih-alih REST HTTP karena performa serialisasi data biner (Protobuf) jauh lebih cepat dan efisien untuk transfer vektor berdimensi tinggi (misal: 1024 atau 1536 dimensi).
• deploy.resources.reservations.devices: Baris konfigurasi penting dalam Docker Compose untuk memastikan kontainer Ollama mendapatkan akses langsung ke perangkat GPU fisik host menggunakan NVIDIA Container Toolkit, mengurangi latensi inferensi LLM dari hitungan detik menjadi milidetik.
• proxy_read_timeout 300s: Konfigurasi krusial pada Nginx. Model bahasa besar sering kali membutuhkan waktu beberapa detik hingga menit untuk menghasilkan respons teks yang panjang (terutama pada dokumen enterprise yang kompleks). Tanpa menaikkan nilai timeout ini, Nginx akan memutus koneksi secara sepihak (Gateway Timeout 504).

7. Skenario Produksi & Studi Kasus Dunia Nyata

Dalam skenario operasional enterprise dengan ribuan karyawan yang mengakses sistem RAG secara bersamaan (high concurrency), arsitektur monolitik akan mengalami bottleneck pada antrean inferensi GPU.

Strategi Skala Produksi:

1. Horizontal Pod Autoscaling (HPA) dengan Kubernetes: Backend Go dan API Gateway dideploy di atas klaster Kubernetes, di mana pod backend dapat diskalakan secara otomatis berdasarkan penggunaan CPU/Memory.
2. Model Inference Queue & Load Balancing: Menggunakan vLLM atau Triton Inference Server sebagai pengganti Ollama murni untuk menangani Continuous Batching, yang menggabungkan beberapa permintaan prompt secara simultan ke dalam satu siklus komputasi GPU, melipatgandakan throughput sistem.
3. Redis Semantic Caching: Sebelum melakukan vector search dan inferensi LLM yang memakan resource GPU besar, sistem mengecek semantic cache di Redis. Jika pertanyaan serupa pernah diajukan sebelumnya dalam ambang batas kemiripan tertentu (>95%), jawaban langsung dikembalikan dari cache Redis dalam waktu < 5ms.

8. Common Pitfalls, Anti-Patterns & Solusi

• Anti-Pattern 1: Ukuran Chunk Dokumen Terlalu Besar atau Terlalu Kecil.
  • Dampak: Jika chunk terlalu besar, model kehilangan detail spesifik dan mencampur konteks. Jika terlalu kecil, informasi kehilangan makna utuh (semantic loss).
  • Solusi: Terapkan strategi Recursive Character Text Splitting dengan ukuran rata-rata 500-1000 token dan overlap sebesar 150 token untuk menjaga kontinuitas informasi antar-chunk.
• Anti-Pattern 2: Mengabaikan Manajemen VRAM GPU.
  • Dampak: Server mengalami Out-Of-Memory (OOM) Crash secara mendadak saat beberapa pengguna melakukan query bersamaan.
  • Solusi: Gunakan kuantisasi model tingkat lanjut (seperti Q4_K_M atau AWQ/GPTQ) dan atur parameter OLLAMA_NUM_PARALLEL serta batas maksimum konteks (num_ctx) secara bijak di file konfigurasi.

9. Benchmark, Metrik Kinerja & Tuning Performa

Untuk mengukur kesiapan sistem sebelum dirilis ke lingkungan produksi, lakukan pengujian beban menggunakan tool seperti k6 atau wrk.

Contoh Skrip Pengujian k6 (load-test.js):

import http from 'k6/http';
import { check, sleep } from 'k6';

export const options = {
  stages: [
    { duration: '1m', target: 50 },  // Ramp-up ke 50 pengguna
    { duration: '3m', target: 50 },  // Pertahankan beban
    { duration: '1m', target: 0 },   // Ramp-down
  ],
};

export default function () {
  const url = 'https://rag.enterprise.internal/api/v1/rag/query';
  const payload = JSON.stringify({ query: 'Apa kebijakan cuti tahunan perusahaan?' });
  const params = { headers: { 'Content-Type': 'application/json' } };

  const res = http.post(url, payload, params);
  check(res, {
    'status adalah 200': (r) => r.status === 200,
    'latensi di bawah 3 detik': (r) => r.timings.duration < 3000,
  });
  sleep(1);
}

[!WARNING] Pastikan parameter indeks HNSW di Qdrant (m dan ef_construct) telah disetel sesuai karakteristik dataset Anda. Nilai ef_search yang terlalu rendah akan mempercepat pencarian tetapi menurunkan akurasi (recall), sedangkan nilai yang terlalu tinggi meningkatkan latensi pencarian.

10. Checklist Penerapan Produksi & Kesimpulan

Sebelum sistem RAG berbasis LLM lokal dinyatakan Production-Ready, pastikan seluruh poin dalam checklist berikut telah terpenuhi:

• Keamanan & Kepatuhan: Seluruh data perusahaan dienkripsi saat transit (TLS 1.3) dan saat disimpan (at-rest menggunakan AES-256).
• Access Control (RBAC): Integrasi metadata dokumen dengan sistem otorisasi pengguna, memastikan pengguna hanya dapat mengambil dokumen yang memiliki hak akses (Document-level permissions).
• Monitoring & Observability: Prometheus dan Grafana dikonfigurasi untuk memantau penggunaan VRAM GPU, latensi gRPC Qdrant, dan metrik HTTP backend.
• Backup & Disaster Recovery: Kebijakan backup otomatis harian untuk volume data Qdrant Vector DB dan file konfigurasi environment.
• Rate Limiting: Perlindungan API terhadap serangan DoS / penyalahgunaan token menggunakan pembatasan berbasis Redis di Nginx/API Gateway.

Dengan mengikuti arsitektur dan panduan komprehensif ini, organisasi Anda dapat menghadirkan sistem pencarian dan generasi berbasis AI yang tidak hanya memiliki performa tinggi dan skalabilitas enterprise, tetapi juga menjaga kerahasiaan dan keamanan data secara mutlak di dalam infrastruktur mandiri.