Large Language Model atau LLM memang pintar menjawab banyak pertanyaan, tetapi ada satu masalah besar: model tidak otomatis mengetahui data internal perusahaan, informasi terbaru, atau perubahan kebijakan setelah masa pelatihannya.
Hasilnya, jawaban bisa terdengar meyakinkan tetapi sebenarnya kurang tepat. Di sinilah Strategi RAG menjadi penting.
Retrieval-Augmented Generation memungkinkan aplikasi mencari informasi dari sumber eksternal sebelum LLM membuat jawaban.
Namun sekadar memasukkan dokumen ke vector database belum cukup. Akurasi sangat bergantung pada kualitas data, strategi pencarian, chunking, dan konteks yang akhirnya diberikan kepada model.
1. Pahami RAG sebagai Sistem Retrieval dan Generation
RAG pada dasarnya menggabungkan dua kemampuan: mencari informasi dan menghasilkan jawaban. Ketika pengguna memasukkan pertanyaan, aplikasi mencari bagian dokumen yang paling relevan, kemudian mengirimkannya bersama pertanyaan tersebut kepada LLM.
Google Cloud menjelaskan bahwa pendekatan ini menggabungkan information retrieval dengan kemampuan generative model sehingga jawaban dapat menggunakan informasi eksternal yang lebih aktual dan relevan.
Contohnya, chatbot internal perusahaan mendapat pertanyaan mengenai aturan cuti terbaru. Daripada mengandalkan pengetahuan bawaan model, sistem mencari dokumen kebijakan HR terbaru lalu menjadikannya konteks sebelum menghasilkan jawaban.
Model tetap bertugas menyusun bahasa, tetapi sumber faktanya berasal dari knowledge base yang dikendalikan perusahaan.
2. Bersihkan Knowledge Base Sebelum Membuat Embedding
Kualitas RAG sangat dipengaruhi kualitas dokumen yang masuk ke sistem. Jika knowledge base penuh informasi kedaluwarsa, duplikat, atau saling bertentangan, retrieval yang canggih sekalipun tetap berpotensi membawa konteks yang salah.
AWS menunjukkan bahwa dokumen mentah sering dibuat untuk dibaca manusia, bukan mesin. Struktur yang buruk, screenshot, hyperlink tanpa konteks, singkatan yang tidak dijelaskan, dan dokumen terlalu besar dapat mengurangi efektivitas semantic retrieval.
Sebelum indexing, lakukan audit terhadap dokumen. Tandai versi resmi, tanggal berlaku, pemilik dokumen, kategori, serta status apakah informasi masih aktif.
Misalnya perusahaan mempunyai lima versi kebijakan reimbursement. Jangan memasukkan semuanya tanpa penanda versi karena retriever mungkin menemukan peraturan lama yang secara semantik terlihat sangat relevan.
Knowledge base yang bersih adalah fondasi akurasi, bukan pekerjaan administratif tambahan.
3. Pilih Strategi Chunking Berdasarkan Struktur Informasi
Dokumen biasanya perlu dipecah menjadi potongan kecil atau chunks sebelum dibuat embedding. Masalahnya, chunk terlalu kecil dapat kehilangan konteks, sedangkan chunk terlalu besar membawa banyak informasi yang tidak relevan.
Tidak ada satu ukuran chunk yang ideal untuk semua data.
Manual produk dapat dipecah berdasarkan heading dan subheading. Kontrak mungkin lebih cocok dipisahkan berdasarkan pasal. FAQ dapat menggunakan satu pertanyaan dan jawaban sebagai satu unit utuh.
OpenAI menyediakan dukungan strategi chunking pada vector store, termasuk konfigurasi ukuran chunk dan overlap.
Hal ini menunjukkan bahwa chunking memang merupakan parameter yang perlu disesuaikan dengan karakter data, bukan sekadar menggunakan satu angka secara universal.
Tujuan akhirnya adalah membuat setiap chunk cukup mandiri untuk menjawab suatu topik, tetapi tidak terlalu panjang sampai informasi penting tenggelam.
Kesalahan pada tahap ini sering membuat sistem terasa “kurang pintar”, padahal masalahnya berada pada proses retrival.
4. Gunakan Metadata untuk Mempersempit Pencarian
Semantic similarity sangat berguna, tetapi tidak selalu cukup.
Bayangkan aplikasi mempunyai ribuan dokumen dari bagian HR, legal, finance, engineering, dan sales. Pertanyaan “berapa batas reimbursement perjalanan?” bisa saja menemukan dokumen lama atau aturan dari negara berbeda.
Metadata dapat mempersempit ruang pencarian berdasarkan atribut seperti departemen, wilayah, tipe dokumen, tanggal, bahasa, atau status dokumen.
Microsoft menjelaskan bahwa RAG dapat menggunakan berbagai jenis index dan retrieval untuk mengambil grounding data sebelum diberikan kepada model. Index tersebut dapat memanfaatkan keyword, semantic, vector, maupun pendekatan gabungan.
Dengan metadata filtering, sistem dapat mencari hanya dokumen HR Indonesia dengan status aktif, misalnya.
Ini membuat retrieval lebih presisi sekaligus mengurangi jumlah konteks yang tidak perlu masuk ke prompt.
5. Jangan Mengirim Terlalu Banyak Context
Ada anggapan bahwa semakin banyak dokumen diberikan kepada LLM, semakin akurat jawabannya. Kenyataannya tidak selalu seperti itu.
Mengirim terlalu banyak chunk dapat meningkatkan biaya token dan membuat informasi penting bersaing dengan konteks yang tidak relevan.
AWS menekankan pentingnya menyeimbangkan grounding dengan token budget melalui pendekatan seperti chunking, metadata filtering, dan summarization.
Sebagai contoh, retriever menemukan 30 potongan dokumen. Daripada memasukkan semuanya ke prompt, sistem dapat mengambil kandidat terbaik, menyaringnya kembali, lalu hanya mengirim beberapa potongan yang paling kuat.
Konsepnya sederhana: lebih banyak context belum tentu lebih baik; context yang tepat jauh lebih bernilai.
6. Instruksikan Model agar Berpegang pada Sumber
Retrieval bagus belum otomatis menghasilkan jawaban akurat. LLM masih membutuhkan instruksi yang jelas tentang bagaimana menggunakan konteks.
Prompt dapat meminta model menjawab hanya berdasarkan informasi yang tersedia dan menyatakan ketidakpastian ketika sumber tidak cukup.
Pendekatan seperti ini membantu mengurangi kecenderungan model mengisi bagian informasi yang hilang dengan pengetahuan atau asumsi sendiri.
Microsoft menjelaskan bahwa grounding data dalam alur RAG digunakan bersama instruksi dan prompt untuk membantu model menghasilkan respons berdasarkan konten yang ditemukan.
Untuk aplikasi enterprise, tambahkan juga citation atau referensi sumber pada jawaban. Pengguna kemudian dapat memeriksa dokumen asli ketika diperlukan.
Ini penting terutama pada aplikasi legal, keuangan, operasional, dan layanan pelanggan yang membutuhkan tingkat kepercayaan lebih tinggi.
7. Buat Mekanisme “Saya Tidak Menemukan Jawabannya”
RAG yang baik bukan sistem yang selalu menjawab.
Jika retriever tidak menemukan informasi dengan tingkat relevansi memadai, aplikasi sebaiknya mengakui bahwa knowledge base tidak mempunyai bukti yang cukup.
Memaksa LLM menjawab setiap pertanyaan justru memperbesar risiko hallucination.
Sistem dapat menggunakan relevance threshold atau confidence signal untuk menentukan kapan jawaban boleh dibuat. Jika kualitas retrieval berada di bawah batas tertentu, tampilkan pesan bahwa informasi belum tersedia atau arahkan pengguna ke staf manusia.
Dengan desain seperti ini, apliksi mungkin terlihat sedikit lebih konservatif, tetapi kepercayaannya meningkat.
Akurasi bukan hanya kemampuan memberi jawaban benar. Kemampuan untuk tidak mengarang ketika sumber tidak tersedia juga merupakan bagian penting dari kualitas sistem.
Strategi RAG yang efektif dimulai dari knowledge base berkualitas, chunking sesuai struktur data, metadata yang jelas, retrieval presisi, dan prompt yang menjaga model tetap grounded.
Jangan langsung menyalahkan LLM ketika jawabannya buruk; sering kali masalah sebenarnya berada pada informasi yang ditemukan. Audit pipeline RAG secara bertahap dan optimalkan komponen yang paling banyak menurunkan kualitas jawaban.