RAG: Arsitektur untuk Chatbot yang Akurat

Large Language Model (LLM) seperti GPT atau Claude memiliki dua kelemahan fundamental: mereka bisa berhalusinasi (menjawab dengan percaya diri meski salah) dan pengetahuan mereka berhenti di tanggal cutoff training data. Untuk aplikasi bisnis, dua kelemahan ini tidak bisa ditoleransi. Di sinilah RAG hadir sebagai solusi.

Apa itu RAG?

RAG (Retrieval-Augmented Generation) adalah arsitektur yang menggabungkan pencarian dokumen dengan generasi teks AI. Alih-alih mengandalkan memori internal LLM, RAG mengambil dokumen relevan dari knowledge base Anda, lalu menyertakannya sebagai konteks saat LLM menyusun jawaban.

Alur kerjanya sederhana:

Query pengguna
    |
    v
[1. RETRIEVAL] --> Cari dokumen relevan dari knowledge base
    |
    v
[2. AUGMENT]   --> Gabungkan dokumen + query sebagai prompt
    |
    v
[3. GENERATE]  --> LLM menghasilkan jawaban berdasarkan konteks
    |
    v
Jawaban akurat dengan sumber yang jelas

Dengan pola ini, LLM tidak perlu “mengingat” semua informasi. Ia cukup membaca dokumen yang diberikan dan menyusun jawaban berdasarkan fakta yang ada.

Hybrid Search: Vector + Keyword

Kualitas RAG ditentukan oleh kualitas retrieval. Pencarian yang buruk menghasilkan konteks yang tidak relevan, dan LLM akan memberikan jawaban yang salah meskipun secara teknis “benar” berdasarkan konteks yang diberikan.

TUTUR menggunakan hybrid search yang menggabungkan dua pendekatan:

Vector search menggunakan embedding untuk menangkap makna semantik. Query “cara mengatasi error koneksi” akan menemukan dokumen tentang “troubleshooting database connection timeout” meskipun kata-katanya berbeda.
Keyword search menggunakan BM25 untuk mencocokkan kata kunci secara eksak. Ini penting untuk istilah teknis, kode error, atau nama produk yang harus cocok persis.

Kedua skor digabungkan dengan pembobotan yang bisa dikonfigurasi per tenant, memastikan hasil pencarian baik secara semantik maupun leksikal.

Pipeline Search dengan Reranking

Pencarian sederhana sering menghasilkan terlalu banyak hasil yang kurang relevan. TUTUR menerapkan pipeline multi-tahap:

Initial retrieval mengambil kandidat dokumen (biasanya 20-50 dokumen) menggunakan hybrid search dengan threshold yang lebih longgar.
Reranking mengurutkan ulang kandidat menggunakan model cross-encoder yang lebih akurat. Model ini membandingkan query dengan setiap dokumen secara langsung, bukan hanya membandingkan embedding.
Score threshold memfilter hasil akhir. Hanya dokumen dengan skor di atas ambang batas yang dimasukkan sebagai konteks LLM.

Pipeline ini memastikan LLM hanya menerima dokumen yang benar-benar relevan.

Strategi Chunking

Dokumen panjang tidak bisa di-embed secara utuh. Mereka harus dipecah menjadi potongan (chunk) yang lebih kecil. Strategi chunking sangat mempengaruhi kualitas retrieval:

Fixed-size chunking memotong dokumen setiap N karakter. Sederhana tapi bisa memotong di tengah kalimat atau paragraf, menghilangkan konteks.
Semantic chunking memotong berdasarkan batas paragraf atau topik. Lebih akurat tapi ukuran chunk bervariasi.
Overlapping chunks menambahkan tumpang tindih antar potongan (misalnya 20%) untuk memastikan informasi di perbatasan tidak hilang.

TUTUR menggunakan kombinasi semantic chunking dengan overlap. Setiap chunk menyimpan metadata tentang dokumen asalnya, posisi dalam dokumen, dan hierarki heading, sehingga konteks tidak hilang saat retrieval.

Implementasi RAG di TUTUR

TUTUR mengimplementasikan RAG dengan stack berikut:

Qdrant sebagai vector database untuk menyimpan dan mencari embedding dokumen. Setiap tenant memiliki namespace terpisah di Qdrant, memastikan isolasi data.
Embedding model mengonversi teks menjadi vektor numerik. TUTUR mendukung beberapa provider embedding yang bisa dikonfigurasi per tenant.
Score threshold yang bisa diatur per tenant. Jika tidak ada dokumen yang memenuhi threshold, TUTUR akan memberitahu pengguna bahwa informasi tidak ditemukan di knowledge base, alih-alih memaksa LLM untuk menjawab tanpa konteks.

Pendekatan ini menghasilkan chatbot yang jujur: ia menjawab berdasarkan data Anda jika tersedia, dan mengakui keterbatasannya jika tidak.

Kapan RAG Tidak Cukup?

RAG bukan solusi untuk semua masalah AI:

Reasoning kompleks yang membutuhkan multi-step logic masih bergantung pada kemampuan LLM itu sendiri.
Data real-time yang berubah setiap detik lebih cocok menggunakan function calling atau API integration langsung.
Knowledge base yang sangat kecil (kurang dari 10 dokumen) mungkin lebih efisien dimasukkan langsung ke system prompt.

Namun untuk mayoritas use case enterprise, chatbot customer support, internal knowledge assistant, dan dokumentasi interaktif, RAG adalah arsitektur yang tepat dan terbukti mengurangi halusinasi secara signifikan.