# Menggunakan RAG sebagai Otak Kedua: Tidak Ada Solusi Terbaik, Hanya Skenario yang Paling Tepat Dalam dua tahun terakhir, hampir semua tim yang mengembangkan model besar melakukan hal yang sama: menambahkan RAG ke model mereka. Alasannya langsung. Model besar memiliki dua kelemahan bawaan—pengetahuan memiliki tanggal kedaluwarsa, dan mereka bisa mengarang-ngarang. RAG diharapkan dapat menyelesaikan kedua masalah ini sekaligus: memberinya materi eksternal terbaru, dan membiarkannya menjawab berdasarkan materi tersebut. Maka muncullah kesalahpahaman umum: **RAG adalah sebuah teknologi. Pilih yang tepat, maka Anda menang.** Namun kenyataannya: RAG bukanlah sebuah teknologi. **RAG adalah istilah umum untuk sekelompok arsitektur.** Skenario yang berbeda membutuhkan pilihan arsitektur yang sama sekali berbeda. Sama seperti model besar yang memiliki kegunaannya masing-masing—model ringan 4B bukannya tidak berguna, ia lebih praktis dalam skenario inferensi perangkat tepi, latensi rendah, dan biaya rendah dibandingkan model dengan triliunan parameter. Model triliunan memiliki penalaran yang kuat, tetapi perusahaan tidak mampu menerapkannya. Masing-masing memiliki tempatnya sendiri. Perbedaan yang sama ada di antara solusi RAG. Tidak ada solusi yang mutlak terbaik. Hanya ada yang paling cocok untuk skenario saat ini. **Yang ingin disampaikan artikel ini adalah: dalam skenario spesifik 'catatan + dokumen + RAG'—yaitu menggunakan AI untuk membangun otak kedua—solusi seperti apa yang optimal. Dan mengapa.** --- ## I. Di Mana Sebenarnya Tantangan RAG di Tahun 2025 Demo RAG hanya butuh waktu satu sore. Namun masalah yang muncul di lingkungan produksi terpusat pada tiga dimensi: ### Indeks Bukan Pekerjaan Sekali Jadi, Melainkan Beban Jangka Panjang "Menyematkan semua dokumen ke basis vektor" kedengarannya sederhana. Namun dalam praktiknya: saat model ditingkatkan, 10 juta dokumen perlu diproses ulang sekitar 5 miliar token, dengan biaya antarmuka saja $300-650. Saat dokumen dihapus, entri kedaluwarsa yang tersisa di basis vektor mungkin tidak dibersihkan selama berhari-hari. Saat izin berubah, jika indeks dokumen karyawan yang keluar tidak diperbarui tepat waktu, ada celah keamanan selama beberapa jam. Saat platform membatasi, alat seperti Slack, Notion sudah mulai membatasi pengambilan data massal pihak ketiga. ### Latensi Adalah Jalur Bertingkat Setiap permintaan kueri melalui: memahami pertanyaan → pencarian vektor → pengurutan hasil → penggabungan konteks → pembuatan jawaban AI. Jika satu tingkat lambat, keseluruhan menjadi lambat. Inferensi LLM menempati 60-80% waktu ujung ke ujung. ### Biaya Meningkat Seiring Pertumbuhan Data Semakin banyak dokumen, semakin banyak pemrosesan. Ketiga tautan tersebut ikut membengkak. **Akar masalah yang sama: dokumen harus diindeks terlebih dahulu sebelum kueri dapat dimulai.** Inilah RAG yang 'berpusat pada pencarian'. --- ## II. Dua Jenis Solusi Utama ### Solusi 1: Basis Vektor + Indeks Statis Dokumen dipotong, diubah, dan disimpan ke basis vektor terlebih dahulu. Saat kueri, konten yang paling mirip dicari dari basis. **Kelebihan:** Dokumen dalam jumlah besar, konten tetap. **Kekurangan:** Konten sering berubah, setiap pengeditan perlu membangun ulang indeks. ### Solusi 2: Aliran Data Real-time + Berbasis Peristiwa Perubahan data memicu pembaruan, indeks disinkronkan secara real-time. **Kelebihan:** Kesegaran hitungan detik. **Kekurangan:** Infrastruktur kompleks, membutuhkan lapisan cache, mekanisme peristiwa, lapisan penyimpanan ganda. ### Ada Satu Skenario yang Tidak Dilayani Kedua Jalur Tersebut Seorang pengacara sedang menyusun ringkasan kasus. 200 catatan kasus, 50 dokumen peraturan. Dia menulis sambil mencari—'Bagaimana argumen kasus tentang larangan bersaing sebelumnya?' Setelah menulis satu bagian, dia mengubah konten, lalu mencari lagi beberapa detik kemudian. Konten baru seharusnya sudah ada dalam hasil pencarian. Karakteristik skenario ini: **konten sering berubah** (bukan pustaka statis), **kueri dan penulisan terjalin** (menulis sambil mencari), **pengguna adalah orang biasa** (tidak menulis kode, tidak memahami basis vektor), **data dan privasi adalah garis merah**. **Ini bukan kebutuhan 'kompleksitas teknis yang lebih tinggi'. Ini adalah kebutuhan 'solusi teknis seharusnya tidak serumit ini'.** --- ## III. Dari Search-centric ke Memory-centric Solusi utama mengasumsikan **basis pengetahuan bersifat statis**. Kueri adalah perilaku pencarian satu kali. Paradigma ini disebut **Search-centric RAG**. Model: basis pengetahuan = kumpulan dokumen, RAG = pencarian cerdas. Namun membangun otak kedua membutuhkan paradigma lain. Anda menulis catatan, mengubah catatan, menghapus catatan, mengimpor dokumen baru setiap hari. Pengetahuan terus tumbuh dan berevolusi. Anda ingin AI tidak sekadar 'mencari', tetapi **terus 'mengingat' pengetahuan Anda, dan secara alami memanggilnya saat dibutuhkan.** Inilah **Memory-centric RAG**. Model: basis pengetahuan = memori yang terus berevolusi, RAG = akses alami. | | Search-centric RAG | Memory-centric RAG | | --- | --- | --- | | Pemahaman tentang pengetahuan | Kumpulan dokumen statis | Memori yang terus tumbuh | | Kesegaran data | Tergantung frekuensi pembaruan indeks | Real-time, langsung terekam setelah ditulis | | Cara kueri | Pencarian aktif | Percakapan alami | | Hubungan penulisan | Pencarian dan penulisan terpisah | Terjalin—pengeditan adalah pembaruan memori | | Skenario tipikal | Pencarian perusahaan, Tanya Jawab kebijakan | Manajemen pengetahuan pribadi, otak kedua | **Kedua paradigma ini bukan saling menggantikan. Mereka melayani skenario yang sama sekali berbeda.** Seperti mesin pencari dan asisten pribadi. --- ## IV. Arsitektur Seperti Apa yang Dibutuhkan Memory-centric RAG? Empat persyaratan untuk arsitektur: **1. Tidak bergantung pada pra-indeks.** Membangun ulang indeks setiap kali mengedit, real-time tidak mungkin tercapai. Sistem pencarian harus berbagi data dengan editor—konten berubah, kueri detik berikutnya sudah mencerminkannya. **2. Penggunaan konteks sangat minimal.** Catatan adalah data pribadi, tidak bisa diunggah semuanya. Tapi AI perlu melihat informasi untuk menjawab. Titik keseimbangan: hanya mengirim beberapa kalimat paling relevan, potongan terkompresi, kirim lalu hapus. **3. Kemampuan generasi menggunakan model cloud terbaik.** Pengguna tidak repot, sisi server hanya melihat konteks minimal. **4. Pengeditan adalah pembaruan memori.** Modifikasi langsung masuk ke memori, kueri berikutnya sudah mencerminkannya. --- ## V. Praktik Memory-centric RAG NoteRich ### Catatan Selalu di Lokal, Data Penuh Tidak Diunggah Catatan disimpan di lokal browser. Tidak diizinkan (biaya meledak), juga tidak seharusnya (privasi pengguna). ### Saat Kueri, Hanya Kirim Konteks Minimal yang Diperlukan Hanya kirim beberapa kalimat paling relevan yang ditemukan, potongan terkompresi. Sisi server hapus setelah diproses—tidak disimpan, tidak dicatat, tidak dilatih. **Pengunggahan dalam jumlah kecil tidak terhindarkan, pengunggahan penuh sepenuhnya bisa dihindari.** ### Tidak Ada Pra-indeks, Pengeditan Adalah Memori Tidak membangun basis vektor terlebih dahulu. Sistem pencarian sudah online saat menulis catatan. Perubahan konten tercermin secara real-time. ### Evaluasi Multi-dimensi + Tepat ke Kalimat + Server Tanpa Status Tidak hanya mengandalkan kesamaan semantik. Kembalikan tepat ke kalimat, deduplikasi dan gabungkan. Backend tidak menyimpan, tidak mencatat, tidak melatih. --- ## VI. Empat Tingkatan Otak Kedua **Tingkat 1: Memori.** Semua catatan yang pernah ditulis, AI 'mengingatnya'. **Tingkat 2: Bantuan Penulisan.** Menghasilkan konten baru berdasarkan catatan lama. **Tingkat 3: Umpan Balik Real-time.** Setelah menulis satu bagian, AI langsung merasakannya. **Tingkat 4: Pengeditan Adalah Memori.** Memodifikasi konten yang dihasilkan AI, langsung masuk ke memori. Lingkaran pengetahuan tertutup. --- ## VII. Akui Batas, Lalu Lintasi ### Batas 1: Kemampuan Browser Versi online berjalan sepenuhnya di browser. Diuji dengan puluhan ribu teks, puluhan juta karakter, sangat mulus. **Puluhan ribu dokumen aman, di luar itu performa menurun.** Ini adalah batas fisik browser. Tapi pengguna pribadi hampir tidak pernah menyentuh batas ini. Jika benar-benar menyentuhnya—Anda sudah masuk kebutuhan tingkat perusahaan. Dalam solusi penerapan offline, arsitektur yang sama berjalan di sisi server, diskalakan sesuai kebutuhan. ### Batas 2: Dukungan Multimodal Saat ini fokus pada teks. OCR gambar, transkripsi audio, analisis video—versi online terbatas oleh daya komputasi browser. Penerapan offline perusahaan dapat diintegrasikan khusus di sisi server. **Memori teks adalah dasar, memori multimodal adalah peningkatan.** ### Batas 3: Penalaran Lintas Dokumen yang Kompleks Penalaran multi-langkah adalah tugas fase generasi, bukan fase pencarian. Pencarian hanya 'mencari', bukan 'menyimpulkan'. NoteRich memungkinkan model tingkat konsumen menghasilkan efek praktis melalui konteks berkualitas tinggi. ### Batas 4: Sepenuhnya Offline Model besar teratas tidak dapat berjalan di komputer biasa—ini adalah hukum fisika. Solusi penerapan offline dapat terhubung ke model lokal yang di-deploy sendiri oleh perusahaan. --- ## VIII. Solusi Offline Kantor hukum, rumah sakit, lembaga keuangan—data sama sekali tidak boleh keluar dari jaringan internal. Penerapan offline mengemas arsitektur Memory-centric sebagai komponen backend tunggal, deploy sekali klik, seluruh proses tidak keluar dari jaringan perusahaan. --- ## IX. Visi Akhir **Search-centric RAG memecahkan masalah 'mencari'.** Memory-centric RAG memecahkan masalah 'mengingat'. Keduanya bukan hubungan kompetitif. Yang dilakukan NoteRich hanyalah, di jalur Memory-centric RAG, membuat beberapa pilihan yang lebih langsung. **Cepat, murah, berkualitas tinggi.** Memungkinkan orang biasa mulai menggunakan AI untuk mengelola pengetahuan dalam 30 detik, dan juga membuat perusahaan sepenuhnya percaya di dalam firewall. **[Coba NoteRich →](https://noterich.com/app/)** *Proyek konsep sumber terbuka [github.com/Lisanoterich/memory-centric-rag](https://github.com/Lisanoterich/memory-centric-rag)*