Masalah RAG tetap ada - berikut adalah lima cara untuk memperbaikinya

Saatnya menghadapi kenyataan tentang Generasi dengan dukungan pengambilan data atau RAG: ini adalah solusi yang membutuhkan solusinya sendiri.

RAG dirancang untuk meningkatkan kinerja model bahasa besar dan mengurangi halusinasi dengan memberi model bahasa besar (LLM) akses ke basis pengetahuan eksternal, melampaui data pelatihan mereka. Namun, keterbatasan dunia nyata pada sistem RAG tradisional kini semakin jelas.

“Sebagian besar, RAG itu cacat,” kata Dinesh Nirmal, wakhara presiden senior IBM® Software. “RAG murni tidak benar-benar memberikan hasil optimal yang diharapkan.”

Tantangan RAG yang sering dihadapi pengguna meliputi batasan pada jendela konteks dan operasi agregasi, ketidakmampuan memahami hubungan kompleks, serta output berkualitas rendah akibat chunking yang tidak optimal. Artinya, penerapan RAG juga dapat menimbulkan masalah keamanan, seperti kebocoran data.

Kabar baiknya, kemajuan dalam alat dan strategi AI membantu menutupi kekurangan RAG tradisional, menghasilkan respons yang lebih akurat terhadap pertanyaan pengguna. Mari lihat lebih dekat cara meningkatkan kinerja RAG.

Meminta aplikasi LLM berbasis RAG tradisional melakukan operasi agregasi, (seperti menghitung jumlah) pada kumpulan data sangat besar, sering kali bukan sekadar sulit—melainkan hampir mustahil. Salah satu faktor yang membatasi kinerja sistem adalah ukuran jendela konteks: jendela konteks LLM umumnya tidak dapat diskalakan untuk memproses, misalnya, kumpulan 100.000 faktur. Selain itu, pipeline RAG tradisional bergantung pada basis data vektor, yang dirancang untuk pencarian kesamaan, bukan untuk operasi.

“Pada dasarnya, ini berarti basis data vektor tidak cukup untuk menangani kasus seperti ini,” jelas IBM® Distinguished Engineer Sudheesh Kairali. “Jendela konteks menjadi masalah. Begitu juga ketidakmampuan melakukan operasi matematika.”

Masuklah SQL RAG.  

Ketika pengguna LLM mencari jawaban dari kumpulan data besar, menggabungkan Generasi dengan dukungan pengambilan data dengan SQL dapat memberikan hasil yang tepat, Kairali menjelaskan.

SQL memiliki fungsi agregasi bawaan, dan SQL Database menawarkan kapasitas lebih besar dibanding jendela konteks LLM. Jika bisnis menyerap data faktur dalam SQL database, mereka bisa menggunakan LLM untuk mengubah kueri—misalnya “Berapa total semua faktur tahun lalu?”—menjadi perintah SQL, mengkueri SQL database melalui RAG, dan menghasilkan jawabannya.

“Jika Anda bisa membangunnya, Anda dapat melakukan banyak agregasi,” kata Kairali. Setelah SQL database menyelesaikan agregasi, “sisanya menjadi tugas pemrosesan bahasa alami (NLP) untuk LLM.”

Memahami bagaimana berbagai potongan informasi atau entitas yang diambil saling terhubung adalah kelemahan lain dari RAG tradisional. Misalnya, pertimbangkan contoh penggunaan untuk pasien dengan riwayat medis yang kompleks. Melalui proses pengambilan RAG tradisional, LLM dapat menyediakan informasi yang relevan. Data ini dapat mencakup rincian seperti jumlah dokter yang ditemui pasien dalam setahun, tetapi mungkin sulit menentukan perawatan yang diresepkan oleh masing-masing dokter.

GraphRag, yang diperkenalkan pada 2024 oleh Microsoft Research, mengatasi tantangan ini dengan memproses dan mengidentifikasi hubungan melalui grafik pengetahuan. GraphRag mengatur informasi sebagai jaringan node dan tepi yang mewakili entitas serta hubungan di antara mereka.

“Jika seorang pasien datang ke rumah sakit dan pertanyaannya adalah, tunjukkan semua kunjungan sebelumnya—ini dapat ditampilkan bukan hanya sebagai kata-kata, tetapi juga sebagai representasi pengetahuan dalam bentuk grafik,” jelas Nirmal. “Anda dapat melihat berbagai titik berbeda yang menunjukkan dokter yang ia temui, obat yang ia konsumsi, dan perawatan yang ia jalani—semuanya dalam satu tampilan grafis.”

GraphRag, kata Nirmal, memiliki keterbatasan karena rendering grafik menjadi lebih sulit seiring meningkatnya volume data. Memetakan ratusan ribu node lebih menantang dibandingkan hanya beberapa lusin, misalnya. “Semuanya memiliki keterbatasan,” kata Nirmal, “tetapi GraphRAG sukses karena keterbatasan RAG murni itu sendiri.”

Pelajari lebih lanjut tentang GraphRAG.

Pemotongan sangat penting dalam aplikasi RAG. Dalam model pemotongan tradisional melalui model penanaman, dokumen relevan dipecah pada titik tertentu menjadi potongan lebih kecil, yang masing-masing direpresentasikan dalam basis data vektor. Namun, metode ini dapat membuat aplikasi memberikan jawaban yang tidak lengkap atau kurang akurat, meskipun menggunakan pencarian semantik algoritma machine learning pada basis pengetahuan domain khusus.

“Dalam proses ini, Anda sering kehilangan akurasi karena tidak tahu di mana data terpotong,” jelas Nirmal. “Misalnya, jika Anda memotong di tengah tabel, saat Anda mengambilnya kembali, Anda hanya mendapatkan separuhnya. Sekarang, Anda sudah kehilangan keakuratannya."

Untungnya, strategi chunking yang lebih baik melalui metode agen dapat meningkatkan pengambilan informasi. Chunking agen ini mencakup strategi seperti membuat potongan yang saling tumpang tindih dan mengubah ukuran potongan secara dinamis berdasarkan konteks dalam dokumen yang diambil. Kerangka kerja orkestrasi LLM dapat membantu untuk tujuan ini. Misalnya, alat TextSplitters LangChaindapat membagi teks menjadi potongan-potongan kecil yang bermakna secara semantik. Strategi semacam itu membantu menghindari hilangnya informasi yang relevan ketika dokumen didekomposisi.

Pelajari lebih lanjut tentang pemotongan agen.

AI agen sangat membantu untuk chunking dan juga dapat meningkatkan akurasi pengambilan dengan cara lain. Pertimbangkan RAG agen: Ini adalah kerangka kerja AI yang dapat mengintegrasikan pipeline RAG untuk menanyakan data terstruktur dalam SQL Database dan data tidak terstruktur dalam repositori dokumen, memanfaatkan basis data vektor untuk pencarian kesamaan. 

RAG Agen juga menambahkan metadata pada setiap potongan. Proses ini menghubungkan data terstruktur (metadata dalam basis data transaksional) dengan data tidak terstruktur untuk meningkatkan akurasi pengambilan.

“Jika kita bisa menggabungkan kekuatan basis data vektor dengan aspek transaksional atau SQL,” kata Nirmal, “kita dapat meningkatkan akurasi dan kinerja secara signifikan.”

Pelajari apa yang diperlukan untuk mengatasi tiga tantangan inti data tidak terstruktur.

Kebocoran data merupakan masalah umum pada sistem AI, termasuk LLM yang menggunakan RAG. Tanpa tindakan yang tepat, LLM bisa mengungkap informasi pengguna yang seharusnya tidak diakses, mulai dari informasi identifikasi pribadi (PII) hingga data keuangan sensitif.

“Ini adalah kenyataan dengan RAG,” kata Kairali. “Saat memulai dengan pembuktian konsep, semua orang senang. Tetapi ketika Anda mendorongnya ke produksi dan ingin memastikan kualitas tingkat produksi, Anda mulai menyadari adanya masalah perlindungan data.”

Mengatasi masalah ini berarti menjaga daftar kontrol akses (ACL) dan kebijakan tata kelola lainnya saat data tidak terstruktur dimasukkan ke berbagai basis data. “Ketika kueri dilakukan dan data diambil, penting memastikan ACL dan kebijakan tata kelola dipatuhi,” kata Kairali. "Pada dasarnya ini adalah masalah teknik."

Memecahkan masalah teknis ini menjadi lebih mudah dengan platform data yang tepat, seperti data lakehouse yang terstruktur dan bersifat sumber terbuka. Misalnya, watsonx.data dari IBM®, data lakehouse hybrid dan terbuka, memastikan kontrol akses tetap diwarisi dari sistem sumber dokumen saat data diambil. Solusi ini juga menyediakan anotasi untuk PII guna mencegah informasi sensitif tersebar.

Seiring LLM dan AI generatif semakin terintegrasi dalam alur kerja sehari-hari, peningkatan RAG membantu perusahaan mendapatkan nilai lebih besar dari data mereka. Alat dan strategi perusahaan yang tepat “memungkinkan kinerja dan akurasi lebih tinggi, sehingga data menjadi lebih mudah dikelola dan bernilai,” kata Nirmal. “Itulah yang dicari setiap pelanggan. "