Berikan LLM Anda akses ke data Anda tanpa fine-tuning. RAG menjembatani kesenjangan antara model bahasa tujuan umum dan pengetahuan spesifik domain.

Anda ingin membangun asisten AI yang menjawab pertanyaan tentang dokumen organisasi Anda — kontrak, kebijakan, basis pengetahuan, dokumentasi produk, rekam medis. Fine-tuning LLM pada data Anda mahal, lambat, dan menciptakan model yang beku pada titik pelatihan. Anda memerlukan arsitektur di mana LLM dapat mengakses informasi terkini, spesifik domain pada saat kueri, mengutip sumbernya, dan menghindari halusinasi fakta yang tidak ada dalam dokumen Anda. RAG (Retrieval-Augmented Generation) adalah cara untuk mencapainya.
Explore more design patterns and system architectures
Arsitek kami dapat membantu merancang dan membangun sistem menggunakan pola ini untuk kebutuhan spesifik Anda.
Hubungi KamiRAG mengaugmentasi generasi LLM dengan konteks yang diambil dari basis pengetahuan. Pada saat kueri, sistem mengubah pertanyaan pengguna menjadi embedding, mencari vector database untuk bagian dokumen yang semantik serupa, dan menyertakan bagian yang paling relevan sebagai konteks dalam prompt LLM. Ini mendasarkan respons model pada dokumen aktual, memungkinkan kutipan sumber, dan menjaga basis pengetahuan tetap dapat diperbarui tanpa pelatihan ulang. Sebuah pipeline RAG produksi menangani ingestion (parsing, chunking, embedding), retrieval (vector search, reranking, hybrid search), dan generation (prompt construction, streaming, guardrails).
Arsitektur ini memiliki dua pipeline. Pipeline ingestion memproses dokumen melalui parsing (ekstraksi PDF, DOCX, HTML), chunking (semantik atau fixed-size dengan overlap), embedding (melalui embedding model), dan penyimpanan (vector database + document store). Pipeline kueri mengambil pertanyaan pengguna, menghasilkan query embedding, mengambil kandidat chunk dari vector database, melakukan reranking untuk relevansi, membangun prompt dengan chunk teratas sebagai konteks, dan melakukan streaming respons LLM dengan kutipan sumber.
text-embedding-3-large, Cohere embed-v4, atau alternatif open-source (BGE, E5). Pemrosesan batch untuk ingestion, pemrosesan single-query untuk pencarian| Lapisan | Teknologi |
|---|---|
| Parsing Dokumen | Unstructured, Apache Tika, LlamaParse, Docling, OCR kustom (Tesseract, AWS Textract) |
| Embedding | OpenAI text-embedding-3-large, Cohere embed-v4, BGE-M3, E5-large-v2 |
| Vector Database | Milvus, Pinecone, Qdrant, Weaviate, pgvector (untuk skala kecil) |
| Pencarian Kata Kunci | Elasticsearch, OpenSearch, PostgreSQL full-text search |
| Reranking | Cohere Rerank, BGE Reranker, ColBERT v2, FlashRank |
| LLM | Claude (via AI Gateway), GPT-4, Gemini — provider-agnostic via AI SDK |
| Orkestrasi | LangChain, LlamaIndex, atau pipeline kustom (preferensi MW untuk produksi) |
| Gunakan Ketika | Hindari Ketika |
|---|---|
| Pengguna membutuhkan jawaban yang didasarkan pada dokumen spesifik organisasi Anda | Basis pengetahuan < 50 halaman — cukup masukkan ke dalam system prompt |
| Dokumen sering diperbarui dan AI membutuhkan informasi terkini | Anda membutuhkan model untuk mempelajari keterampilan/perilaku baru, bukan mengakses fakta baru (gunakan fine-tune sebagai gantinya) |
| Kutipan sumber dan auditabilitas adalah persyaratan (hukum, kepatuhan, kesehatan) | Pertanyaan bersifat murni percakapan dan tidak memerlukan dasar faktual |
| Beberapa grup pengguna membutuhkan akses ke subset dokumen yang berbeda (RAG yang difilter izin) | Anda sedang membangun alat penulisan kreatif di mana akurasi faktual bukanlah tujuannya |
MW membangun pipeline RAG mulai dari kualitas retrieval keluar — kami membenchmark presisi retrieval sebelum menyentuh prompt LLM. Sistem RAG dengan retrieval yang biasa-biasa saja dan LLM yang hebat menghasilkan jawaban yang terdengar percaya diri tetapi salah. Pipeline standar kami mencakup perangkat evaluasi retrieval: seperangkat kueri uji dengan dokumen yang diketahui relevan, diukur dengan MRR@5 dan NDCG@10. Kami berulang kali memperbaiki chunking, embedding model, dan reranking hingga metrik retrieval mencapai ambang target sebelum mengoptimalkan generasi. Kami telah membangun sistem RAG di seluruh peninjauan dokumen hukum, basis pengetahuan kesehatan, dan dukungan pelanggan multibahasa — dan pelajaran umumnya adalah bahwa kualitas retrieval menyumbang 80% dari kualitas jawaban.
Pencarian embedding mudah dilakukan pada 10K vektor. Namun, pada 100M vektor dengan P99 di bawah 100ms, ini menjadi masalah infrastruktur — dan itulah yang diselesaikan oleh pola ini.
MicrocosmWorks menerapkan resolusi konflik dalam pipeline RAG melalui pemeringkatan otoritas sumber, pembobotan keterkinian berdasarkan stempel waktu, dan penilaian kepercayaan diri yang mengevaluasi seberapa kuat setiap bagian yang diambil mendukung klaimnya. Ketika bagian-bagian yang bertentangan diambil, pipeline kami menyajikan jawaban dengan otoritas tertinggi sembari secara transparan menampilkan ketidaksepakatan dan kutipan sumber agar pengguna dapat membuat keputusan yang terinformasi. Kami juga membangun lingkaran umpan balik di mana pakar domain dapat menandai resolusi yang salah, yang meningkatkan pemeringkatan pengambilan seiring waktu.
MicrocosmWorks menggunakan chunking yang peka konteks yang menerapkan strategi berbeda berdasarkan struktur dokumen—pemisahan paragraf semantik untuk prosa, chunking tingkat baris atau tingkat bagian untuk tabel dengan konteks header yang dipertahankan, dan chunking tingkat fungsi untuk kode dengan pernyataan import terlampir. Kami memperkaya setiap chunk dengan metadata termasuk judul dokumen, hierarki bagian, dan jenis konten sehingga tahap retrieval dapat menerapkan penilaian spesifik jenis. Pendekatan ini secara konsisten mengungguli chunking ukuran tetap yang naif sebesar 25-40% pada retrieval relevance benchmarks dalam proyek klien kami.
MicrocosmWorks membangun perangkat evaluasi yang menguji pipeline RAG melalui tiga dimensi: relevansi pengambilan (apakah potongan yang tepat ditemukan), keandalan jawaban (apakah jawaban yang dihasilkan benar-benar mencerminkan konten yang diambil), dan kelengkapan jawaban (apakah itu mengatasi pertanyaan secara lengkap). Kami membuat set pengujian emas dengan pakar domain yang mencakup kueri dengan jawaban yang diketahui, kasus tepi adversari, dan pertanyaan yang memerlukan sintesis multi-dokumen. Evaluasi ini berjalan secara otomatis di CI/CD sehingga setiap perubahan pipeline di-benchmark terhadap metrik kualitas dasar sebelum penyebaran.
MicrocosmWorks memilih basis data vektor berdasarkan skala Anda, pola kueri, dan persyaratan operasional—Pinecone untuk kesederhanaan terkelola, Weaviate untuk pencarian hibrida kata kunci-vektor, pgvector untuk tim yang sudah berinvestasi pada PostgreSQL, dan Qdrant untuk deployment mandiri dengan throughput tinggi. Pada skala di bawah 10 juta vektor, sebagian besar opsi memberikan latensi di bawah 100ms, tetapi perbedaannya menjadi signifikan pada ratusan juta vektor di mana jenis indeks, kuantisasi, dan strategi sharding sangat penting. Kami melakukan benchmark dimensi embedding aktual dan pola kueri Anda terhadap opsi yang masuk daftar pendek selama fase desain arsitektur kami.
MicrocosmWorks membangun pipeline ingestion inkremental yang memantau repositori dokumen sumber untuk perubahan, melakukan re-chunk dan re-embed hanya pada bagian yang dimodifikasi, dan memperbarui vector store tanpa memerlukan reindex penuh. Kami menerapkan document fingerprinting yang mendeteksi perubahan konten pada tingkat bagian, sehingga satu edit paragraf tidak memicu pemrosesan ulang seluruh dokumen 200 halaman. Untuk klien dengan persyaratan real-time freshness, kami menambahkan live retrieval layer yang mengkueri source system secara langsung untuk dokumen yang baru saja dimodifikasi dan menggabungkan hasil tersebut dengan vector search hits.