Kesalahan percaya diri yang disebabkan oleh penarikan RAG yang tinggi

Ketika banyak tim membawa RAG ke dalam bisnis untuk pertama kalinya, indikator pertama yang menjadi fokus mereka biasanya adalah volume penarikan kembali.

Jika 3 pukulan tidak cukup, sesuaikan menjadi 8 pukulan; jika 8 hit masih belum stabil, terus kendurkan ambang kesamaan vektor, lalu susun BM25, pemfilteran tag, dan perluasan sinonim bersama-sama. Tingkat keberhasilan pada panel memang terlihat bagus, dan banyak masalah tampaknya “tercakup”. Namun setelah beberapa saat berjalan di internet, jenis pertanyaan lain yang lebih sulit muncul: jawabannya mulai terdengar semakin sesuai dengan kebenaran, dan nadanya menjadi semakin lengkap. Namun, setelah sumbernya diperiksa dengan cermat, sumber tersebut tercampur dengan aturan versi lama, dokumen penyewa lainnya, SOP yang sudah usang, dan bahkan instruksi yang bertentangan.

Penilaian saya terhadap jenis masalah ini adalah: **Keandalan RAG sering kali terganggu karena “mengingat terlalu banyak hal yang seharusnya tidak muncul pada saat yang bersamaan.” Ketika konteksnya diisi dengan informasi yang bertentangan, dokumen yang kadaluwarsa, dan konten dengan izin yang tidak konsisten, model tidak akan dengan jujur ​​​​memberi tahu Anda “buktinya bertentangan dan jawabannya tidak dapat dijawab”. Yang lebih umum adalah mengikuti kelembaman bahasa dan menjahit bagian-bagian ini menjadi jawaban yang terlihat lengkap, namun kenyataannya rantai bukti telah kendor. **

Masalah seperti ini awalnya tampak seperti kurangnya daya ingat, namun kemudian berubah menjadi polusi konteks.

Ini adalah pertama kalinya saya memperjelas penilaian ini. Di permukaan, tampaknya jawaban model tersebut terlalu pendek, namun kenyataannya lebih mendekati jawaban yang terlalu mulus.

Skenarionya adalah sesi tanya jawab pengetahuan internal dalam suatu perusahaan. Pengguna mengajukan pertanyaan yang sangat spesifik di tautan persetujuan penggantian biaya: setelah perjalanan bisnis ke luar negeri melebihi batas, apakah akan menemui atasan langsung untuk mendapatkan persetujuan terlebih dahulu, atau pergi ke pusat biaya untuk ditinjau terlebih dahulu. Sistem sering kali gagal menjawab pertanyaan pada awalnya, dan alasannya sederhana. Sistem terkait tersebar di basis pengetahuan yang berbeda, dan penelusuran vektor seringkali hanya mendapatkan setengahnya.

Jadi tim melakukan serangkaian penyempurnaan yang sangat umum:

• Menaikkan topK dari 4 menjadi 10;
• Menambahkan kata kunci untuk mengingat keuntungan;
• Pencocokan ekspresi sinonim yang santai;
• Masukkan pengumuman historis, FAQ, dan teks sistem ke dalam kumpulan kandidat.

Ini bekerja dengan baik dalam jangka pendek. Balasannya tidak lagi “Tidak ditemukan informasi relevan”, tetapi sekarang dapat mengatur langkah-langkah lengkap. Masalahnya dimulai di sini: pengguna melaporkan bahwa jawabannya “kedengarannya seperti jawaban yang benar”, tetapi jika mereka benar-benar mengikutinya, mereka akan membuat urutan yang salah.

Kemudian, ketika saya membongkar jawaban yang salah dan melihatnya, tiga jenis materi muncul secara bersamaan dalam konteks model:

1. Rantai persetujuan pada sistem lama setengah tahun lalu;
2. Klausul pengecualian dalam teks sistem baru;
3. Deskripsi entitas regional lain di FAQ.

Masing-masing dari ketiga materi ini bukanlah sampah, bahkan terlihat “sangat relevan” jika dilihat satu per satu. Masalahnya adalah mereka tidak termasuk dalam ruang pengambilan keputusan yang sama. Apa yang diperoleh model tersebut adalah sekumpulan fragmen yang terkait dalam kata-kata tetapi memiliki batasan bisnis yang tidak konsisten. Pada akhirnya, jawaban yang dihasilkan adalah menguleni ketiga bahan tersebut menjadi proses baru.

Di sinilah banyak proyek RAG yang kemungkinan besar akan salah menilai: Di ​​permukaan, sepertinya “penarikan kembali menjadi lebih kuat”, namun pada intinya, hal ini meningkatkan kesalahan pengambilan dari “kurangnya bukti” menjadi “bukti kotor memasuki tahap pembuatan”.

Setelah penarikan lebih lanjut, model tidak akan menjadi lebih berhati-hati, tetapi hanya akan menjadi lebih baik dalam memperbaiki jahitan.

Situasi yang umum adalah bahwa secara default, memberikan lebih banyak informasi kepada model, paling banter, membiarkannya memilih.

Namun situasi sebenarnya lebih mirip dengan mekanisme lain: semakin panjang konteksnya, semakin banyak fragmennya, dan semakin longgar hubungan semantiknya, semakin mudah bagi model untuk mengeja “sebagian masuk akal” menjadi “benar secara keseluruhan”. **

Hal ini dikarenakan pada tahap pembangkitan dihadapkan pada rangkaian teks yang telah dilinearisasi. Selama teks-teks ini benar-benar dapat menjembatani satu sama lain, model tersebut secara alami akan cenderung menjembatani kesenjangan tersebut. Kecenderungan ini akan sangat kuat pada situasi berikut:

• Kedua dokumen tersebut memiliki kesimpulan yang berbeda, namun memiliki banyak kesamaan istilah bisnis;
• Ketika sistem baru menggulingkan sistem lama, tidak disebutkan secara jelas “aturan lama dihapuskan”;
• FAQ merangkum teks dalam istilah sehari-hari, namun mengabaikan ketentuan yang berlaku;
• Konten multi-penyewa, multi-wilayah, dan multi-versi dipanggil kembali secara bersamaan, namun hanya dibedakan dalam metadata.

Saat ini, model tidak akan secara langsung mengungkapkan “Saya melihat konflik”, tetapi sering kali akan melakukan tiga hal:

1. Mengutamakan kalimat-kalimat yang paling baik membentuk narasi utuh;
2. Secara otomatis mengisi hubungan sebab akibat yang tidak disebutkan secara eksplisit dalam konteksnya;
3. Telan kondisi batas dan gantikan dengan ekspresi yang lebih mirip aturan umum.

Pada akhirnya, apa yang dilihat pengguna adalah jawaban yang halus, lengkap, dan seolah-olah telah dinilai secara komprehensif. Bahaya sesungguhnya adalah hal ini menimbulkan konflik.

Dokumen yang sudah ketinggalan zaman tidak menimbulkan keributan, dokumen tersebut akan secara aktif melemahkan bobot bukti baru

Ketika banyak tim memecahkan masalah jawaban RAG yang salah, mereka terbiasa memperlakukan dokumen kadaluwarsa sebagai semacam “kebisingan berkualitas rendah” dan merasa bahwa selama jumlahnya kecil, itu bukan masalah besar.

Namun pada tahap pembuatan, dokumen-dokumen yang kadaluarsa seringkali menjadi bukti yang bersaing dan secara aktif mengubah fokus jawaban.

Contoh yang lebih khas yang pernah saya lihat adalah basis pengetahuan layanan pelanggan. Aturan pengembalian dana tertentu telah diubah dalam versi kebijakan yang baru, namun FAQ versi lama kemungkinan besar akan diberi peringkat lebih tinggi pada tahap penarikan kembali karena tingginya jumlah kunjungan dan lebih banyak ekspresi sehari-hari. Teks kebijakan baru ini ditulis secara akurat namun tegas; FAQ lama ditulis dengan lancar dan memiliki template retoris yang lengkap. Akibatnya, ketika model menjawab, sangat mudah untuk menganggap peraturan versi baru sebagai pembatasan lokal dan FAQ lama sebagai narasi utama.

Jawaban akhirnya sering kali terlihat seperti ini:

通常情况下用户可先申请原路退款，如遇活动商品则需进一步审核。

Hal yang paling kuat tentang kalimat ini adalah bahwa hampir setiap kata dapat ditemukan dalam konteksnya, namun keseluruhan kalimat itu sendiri tidak ada dalam satu sumber. Aturan baru yang sebenarnya mungkin telah diubah menjadi “Produk aktif tidak mendukung pengembalian dana asli”, dan “biasanya” di FAQ lama digunakan oleh model sebagai kalimat umum, yang secara langsung menekan aturan baru menjadi pengecualian.

Oleh karena itu, permasalahan dokumen kadaluarsa bukan hanya sekedar “informasi lama telah tercampur”, namun informasi lama seringkali lebih mirip ucapan manusia dan lebih mudah dijadikan kerangka oleh model**.

Mengingat izin yang tidak konsisten lebih menyusahkan daripada jawaban yang salah karena akan menghasilkan jawaban yang “tampaknya beralasan” dan melampaui otoritas.

Persoalan lain yang sering dianggap remeh adalah batasan izin.

Banyak sistem RAG internal menempatkan verifikasi izin pada tingkat “apakah dokumen dapat dibuka”, berpikir bahwa selama teks asli tidak ditampilkan kepada pengguna pada akhirnya, itu akan baik-baik saja. Bahaya nyata dari sistem generatif adalah: **Selama dokumen yang dibatasi masuk dalam konteksnya, meskipun teks aslinya tidak diposting pada akhirnya, jawabannya sendiri mungkin telah mengungkapkan penilaian yang tidak boleh diketahui. **

Misalnya, ketika bagian penjualan mengajukan pertanyaan tentang persetujuan kontrak, hanya ada prosedur umum di basis pengetahuan publik, dan ada klausul pengecualian untuk pelanggan khusus di basis pengetahuan hukum. Jika tahap pengambilan hanya “mengingat dulu, lalu memotong”, model mungkin telah memanfaatkan aturan pengecualian tersebut dalam tahap draf, dan akhirnya menghasilkan saran yang tampaknya netral:

Pelanggan seperti ini biasanya memerlukan persetujuan tambahan kepala daerah.

Pengguna tidak dapat melihat dokumen yang dibatasi, tetapi dia telah diberikan aturan organisasi yang seharusnya tidak dia ketahui. Yang lebih meresahkan lagi, kalimat ini sulit diidentifikasi sebagai kebocoran dalam bentuknya, karena kurang seperti copy paste dan lebih seperti model yang “diringkas dengan sendirinya”.

Oleh karena itu, masalah izin tidak hanya dapat dipahami sebagai kontrol akses, tetapi harus dipahami sebagai kontrol sumber bukti. Segera setelah material yang tidak termasuk dalam rentang visual yang sama dimasukkan ke dalam model secara bersamaan, sistem telah melewati batas. Pembatasan desensitisasi dan referensi berikutnya hanya menangani kontaminasi yang telah terjadi.

Yang benar-benar perlu dioptimalkan adalah membiarkan bukti-bukti menyatu sesuai batasan keputusan terlebih dahulu

Banyak sistem RAG menjadi semakin kacau di kemudian hari. Di permukaan, nampaknya model tersebut terlalu lemah. Faktanya, ini lebih dekat ke tahap pengambilan dan arah pengoptimalannya sendiri menjadi bias.

Apa yang paling mungkin dilakukan oleh tim adalah memperlakukan penarikan kembali sebagai masalah mesin pencari:

• Jika korelasinya tidak cukup, tambahkan saluran penarikan kembali;
• Jika coveragenya kurang, tambahkan topK sedikit lagi;
• Metode kueri pengguna tidak stabil, jadi lakukan lebih banyak penulisan ulang kueri.

Tindakan ini belum tentu salah, namun jika tidak ada batasan “batas keputusan”, lebih banyak materi yang tidak seharusnya muncul pada saat yang sama akan dikirim ke tahap pembuatan.

Yang lebih saya perhatikan nanti adalah rangkaian urutan konvergensi lainnya:

1. Lakukan konvergensi rentang terlebih dahulu, lalu lakukan pengurutan korelasi.

Banyak pertanyaan dan jawaban yang sebenarnya dapat membatasi ruang lingkup sebelum pengambilan semantik, seperti:

• kesatuan organisasi;
• wilayah atau negara;
• Waktu efektif;
• Jenis dokumen;
• Bidang izin pengguna.

Jika kondisi tersebut tidak diperhitungkan terlebih dahulu, dan pemeringkatan hanya didasarkan pada penyematan kesamaan, maka hasilnya pasti akan mencakup hal-hal yang “serupa”. Itu karena kumpulan kandidat didefinisikan secara salah.

2. Perlakukan versi dan waktu efektif sebagai warga negara kelas satu, bukan metadata tambahan

Banyak basis pengetahuan yang jelas memiliki bidang updated_at, version, dan status, namun hanya digunakan di lapisan presentasi dan hampir tidak berpartisipasi dalam pengambilan keputusan saat mengambil dan mengeja konteks. Dengan cara ini, dokumen lama dan dokumen baru diperlakukan sama, dan model tidak tahu siapa yang harus menimpa siapa.

Pendekatan yang lebih stabil adalah dengan menangani hubungan cakupan secara eksplisit:

• Dokumen yang tidak digunakan lagi tidak memasuki konteks pembuatan secara default;
• Ketika aturan lama dan baru bertentangan, keduanya langsung ditandai sebagai konflik dan modelnya tidak boleh disintesis secara bebas;
• FAQ tidak dapat menutupi teks utama sistem dan hanya dapat digunakan sebagai lapisan penjelasan sebagai pelengkap.

3. Biarkan konflik terekspos dan bukannya membiarkan model menjadi wasit, bukan sistem.

Banyak sistem yang secara default menggabungkan beberapa materi kandidat secara langsung dan menyerahkannya ke model, dengan harapan bahwa model tersebut akan “memahaminya secara komprehensif” dengan sendirinya. Langkah ini justru yang paling berbahaya, karena penanganan konflik bukti diserahkan kepada lapisan yang paling baik dalam menambal kesenjangan tersebut.

Jika dua dokumen berbobot tinggi memiliki kesimpulan yang bertentangan, perilaku sistem yang lebih masuk akal biasanya adalah memberi tahu pengguna secara eksplisit:

• Ditemukan peraturan yang bertentangan;
• Dimana titik konfliknya;
• Versi mana yang saat ini digunakan secara default, atau diperlukan konfirmasi manual.

Kedengarannya tidak sehalus sutra, tapi sebenarnya bisa dikontrol. Mengakui konflik lebih seperti sebuah sistem yang dapat diandalkan daripada memberikan jawaban yang lengkap namun dipalsukan.

Kasus kegagalan yang umum terjadi: menganggap penataan ulang sebagai solusi akhir

Setelah banyak tim menemukan bahwa “semakin banyak recall, semakin banyak kekacauan yang terjadi”, mereka akan segera menggunakan reranker. Hasilnya, kualitas penyortiran memang membaik, sehingga mereka menganggap masalah tersebut sudah teratasi.

Tapi apa yang bisa dipecahkan oleh reranker terutama adalah “siapa yang lebih menyukai jawaban atas pertanyaan itu”; ia tidak dapat menyelesaikan “apakah kandidat-kandidat ini termasuk dalam ruang fakta penggabungan yang sama”.

Jika kumpulan kandidat berisi keduanya:

• Peraturan Wilayah A 2024;
• Peraturan Wilayah B 2025;
• Instruksi pengecualian internal untuk administrator;
• FAQ untuk karyawan biasa;

Reranker hanya memberi peringkat dua atau tiga artikel lebih tinggi. Sistem tidak dapat memutuskan secara mendasar apakah material ini dapat dimasukkan ke dalam model secara bersamaan.

Hal ini juga menunjukkan bahwa banyak ulasan RAG terlihat bagus secara offline, namun mulai melayang begitu memasuki adegan kompleks secara online. Tanya jawab dalam kumpulan offline seringkali bersifat tunggal, standar, dan memiliki batasan yang jelas; kompleksitas sebenarnya dari pertanyaan online adalah bahwa pertanyaan tersebut terkait dengan versi, izin, struktur organisasi, dan pengecualian. Penyortiran hanya mengutamakan materi yang paling mirip dan tidak secara otomatis mengelola tim.

Batasan yang berlaku: tidak semua skenario harus mengurangi jumlah penarikan kembali

Mengatakan “terlalu banyak penarikan membuatnya mudah membuat kesalahan” tidak berarti bahwa semua sistem harus memotong topK menjadi sangat kecil.

Jika Anda melakukan tanya jawab eksplorasi, pengumpulan data, dan bantuan penelitian, masuk akal untuk menyediakan lebih banyak materi, dan pengguna bersedia menerima “ada banyak pendapat di sini”. Dalam skenario ini, tujuan sistem adalah membantu pengguna menavigasi ruang informasi.

Yang benar-benar diperlukan untuk mengontrol batas penarikan kembali secara ketat adalah skenario di mana jawabannya akan langsung dieksekusi, seperti:

• Tanya Jawab Institusional;
• Proses persetujuan;
• Kaliber layanan pelanggan;
• Runbook pengoperasian dan pemeliharaan;
• Dukungan keputusan medis, keuangan, dan kepatuhan.

Dalam skenario ini, kemampuan sistem yang paling penting adalah “tidak menggabungkan bukti yang tidak kompatibel satu sama lain ke dalam instruksi yang dapat dieksekusi.” Ketika kerugian akibat jawaban yang salah lebih tinggi dibandingkan kerugian karena tidak bisa menjawab, maka strategi pencarian tidak bisa lagi hanya berkisar pada cakupan.

Ringkasan

Hal yang paling membuat ketagihan tentang RAG adalah ia selalu dapat membuat data panel terlihat lebih baik dalam jangka pendek dengan “mengingat lebih banyak lagi”.

Namun setelah sistem pengetahuan benar-benar diluncurkan, hal yang paling sulit untuk dikumpulkan adalah apakah materi yang masuk ke dalam konteks memiliki batasan fakta yang sama, semantik versi yang sama, dan cakupan otoritas yang sama.

Selama pertanyaannya tidak diselesaikan terlebih dahulu, semakin banyak yang diingat, semakin model tersebut akan terlihat seperti orang yang sangat pandai dalam menulis ringkasan: model tersebut mungkin tidak dengan sengaja mengatakan hal yang tidak masuk akal, tetapi model tersebut akan menjahit bukti yang tidak boleh disatukan menjadi sebuah jawaban yang terlihat seperti sebuah kesimpulan.

Oleh karena itu, pada langkah pengoptimalan RAG berikutnya, sering kali kita tidak boleh menanyakan “berapa banyak lagi yang dapat diingat”, tetapi tanyakan terlebih dahulu: **Konten mana yang tidak boleh muncul bersamaan dalam prompt yang sama sama sekali. **