Anda telah mengirimkan sistem RAG. Ini berhasil... sebagian besar. Terkadang jawabannya sangat bagus. Terkadang model tersebut dengan yakin menyatakan sesuatu yang sepenuhnya salah, dengan mengutip dokumen yang tidak menyatakan apa yang diklaim oleh model. Dan terkadang jawabannya tidak terjawab sepenuhnya meskipun dokumen yang tepat ada di basis pengetahuan Anda.
Ini adalah keadaan normal sistem produksi RAG. Pertanyaannya bukanlah apakah Anda mempunyai masalah kualitas — memang demikian — melainkan apakah Anda mempunyai cara sistematis untuk menemukan dan memperbaikinya. Itulah gunanya retrospektif RAG: memeriksa secara berkala di bagian mana saluran pipa Anda rusak dan melakukan perbaikan yang ditargetkan, alih-alih hanya menebak-nebak.
Mengapa RAG Sistem Membutuhkan Retrospektifnya Sendiri
RAG bukan satu sistem. Ini adalah rangkaian komponen, dan kualitas setiap tautan menentukan hasil akhir. Jika jawabannya buruk, kegagalannya bisa terjadi dimana saja:
- Penyerapan: Dokumen tidak diurai dengan benar, potongannya terpecah di tempat yang buruk, metadata hilang
- Pengambilan: Kueri penelusuran tidak cocok dengan dokumen yang benar, model penyematan kehilangan koneksi semantik, K teratas Anda terlalu kecil atau terlalu besar
- Perakitan konteks: Potongan yang diambil relevan satu per satu namun bertentangan satu sama lain, atau jendela konteks dipenuhi dengan noise
- Generasi: Model berhalusinasi meskipun konteksnya bagus, atau mengabaikan konteks relevan demi pengetahuan parametriknya
Retrospektif perangkat lunak standar tidak dilengkapi untuk menguraikan mode kegagalan ini. Anda memerlukan format yang melacak kembali keluaran buruk melalui saluran untuk menemukan titik kegagalan sebenarnya. Jika tidak, Anda akan "memperbaiki" pengambilan saat masalah sebenarnya sedang terpecah, atau menulis ulang perintah saat masalah sebenarnya adalah pengambilan.
Metrik yang Layak Dilacak
Sebelum menjalankan retrospektif RAG, Anda memerlukan data. Tidak semua metrik yang memungkinkan — hanya cukup untuk mendiagnosis mode kegagalan yang paling umum.
Kualitas Pengambilan
Precision@K: Dari K dokumen yang diambil, berapa banyak yang benar-benar relevan? Jika Anda menarik kembali 10 bagian dan hanya 2 yang berguna, Anda membanjiri jendela konteks dengan noise.
Recall@K: Dari semua dokumen relevan di basis pengetahuan Anda, berapa banyak yang masuk dalam hasil K teratas Anda? Ingatan yang rendah berarti jawaban yang benar ada tetapi pengambilan Anda tidak dapat menemukannya.
MRR (Mean Reciprocal Rank): Di manakah hasil relevan pertama yang muncul di peringkat Anda? Jika dokumen terbaik selalu berada di posisi 5 dan bukannya 1, peringkat Anda perlu diperbaiki meskipun penarikan kembali baik-baik saja.
Anda tidak perlu menghitungnya di seluruh basis pengetahuan Anda. Ambil sampel 50-100 kueri terbaru, mintalah hakim manusia yang mengambil dokumen yang relevan, dan hitung dari sana. Lakukan ini setiap bulan.
Kualitas Generasi
Kesetiaan: Apakah jawaban yang dihasilkan benar-benar mencerminkan isi dokumen yang diambil? Ini adalah pertanyaan halusinasi. Anda dapat memeriksanya dengan membandingkan keluaran dengan konteks yang diberikan.
Relevansi jawaban: Apakah jawaban benar-benar menjawab pertanyaan yang diajukan? Ringkasan dokumen yang diambil dapat dibuat dengan benar dan benar-benar tidak sesuai dengan maksud pengguna.
Pemanfaatan konteks: Ketika informasi yang benar berada dalam konteks yang diambil, apakah model benar-benar menggunakannya? Jika Anda terus-menerus mengambil dokumen yang bagus dan model mengabaikannya, itu adalah masalah sisi generasi (biasanya merupakan masalah pemicu).
Metrik Operasional
Latensi: Berapa lama waktu yang dibutuhkan seluruh pipeline mulai dari kueri hingga respons? Uraikan berdasarkan komponen sehingga Anda tahu apakah pengambilan atau pembuatan adalah hambatannya.
Biaya per kueri: Lacak penggunaan token dan biaya API. Beberapa peningkatan kualitas (seperti memperluas jendela konteks atau memberi peringkat ulang) meningkatkan biaya secara signifikan.
Menjalankan Retrospektif
Persiapan (Sebelum Rapat)
Tugaskan seseorang untuk menyiapkan "sampel kegagalan" — 10-15 kueri terbaru yang keluarannya salah atau berkualitas buruk. Untuk masing-masingnya, tangkap status alur lengkap: kueri asli, apa yang diambil, konteks apa yang dikirim ke model, dan model apa yang dihasilkan. Jejak ini sangat penting. Tanpanya, Anda melakukan debug secara buta.
Siapkan juga tren metrik Anda. Apakah keadaan menjadi lebih baik atau lebih buruk sejak retro terakhir? Adakah perubahan drastis?
Rapat (60 menit)
Peninjauan metrik (10 menit). Pelajari metrik pengambilan dan pembuatan. Fokus pada tren dan kejutan, bukan pembacaan angka demi angka. "Precision@5 turun dari 0,72 menjadi 0,58 bulan ini" berguna. Membaca setiap metrik dari dasbor tidaklah demikian.
Analisis kegagalan (35 menit). Ini adalah inti dari retro. Ambil sampel kegagalan dan klasifikasikan setiap kegagalan berdasarkan lokasi kerusakan pipa:
- Kegagalan pengambilan: Dokumen yang benar tidak diambil. Mengapa? Ketidakcocokan dokumen kueri? Menyematkan batasan model? Pemfilteran metadata terlalu agresif?
- Kegagalan pemotongan: Dokumen yang tepat telah diambil, namun batas potongan membagi jawaban menjadi dua bagian dan hanya satu yang dikembalikan. Atau potongannya terlalu besar dan diencerkan dengan konten yang tidak relevan.
- Kegagalan konteks: Potongan yang bagus telah diambil, namun pengurutan atau pemotongan jendela konteks kehilangan informasi penting. Atau bagian yang bertentangan membingungkan model.
- Kegagalan generasi: Konteks yang baik diberikan, namun model tetap berhalusinasi, mengabaikan konteks, atau memberikan jawaban yang tidak jelas dan bukan jawaban spesifik yang tersedia dalam dokumen.
Untuk setiap kegagalan, tanyakan: "Perbaikan termurah apa yang dapat mengatasi atau mencegah hal ini?" Terkadang ini adalah perubahan yang cepat. Kadang-kadang dilakukan pengelompokan ulang dokumen tertentu. Terkadang itu adalah perubahan yang sistemis.
Item prioritas dan tindakan (15 menit). Kelompokkan kegagalan berdasarkan akar permasalahan. Pola yang paling banyak menyebabkan kegagalan mendapat perhatian paling besar. Pilih 2-3 peningkatan untuk diterapkan sebelum retro berikutnya.
Pola dan Perbaikan Kegagalan Umum
Berikut pola yang paling sering Anda lihat dan pendekatan praktis untuk masing-masing pola:
"Dokumen yang benar ada dalam basis pengetahuan kami, namun pengambilannya meleset." Ini biasanya merupakan masalah kesamaan yang melekat. Kueri pengguna menggunakan kosakata yang berbeda dari dokumen sumber. Perbaikan: tambahkan langkah perluasan kueri (tulis ulang kueri pengguna menjadi beberapa frasa), terapkan penelusuran hibrid (gabungkan penyematan semantik dengan pencocokan kata kunci seperti BM25), atau tingkatkan pemfilteran metadata untuk mempersempit ruang penelusuran.
"Kami mengambil dokumen yang benar tetapi bagiannya salah." Strategi pengelompokan Anda lebih penting daripada yang disadari sebagian besar tim. Jika Anda menggunakan pengelompokan berukuran tetap (misalnya 500 token), Anda hampir pasti membagi konten penting melintasi batasan. Perbaikan: gunakan pengelompokan semantik (dipisahkan berdasarkan peralihan topik), tambahkan potongan yang tumpang tindih, coba pengelompokan hierarki dengan potongan induk yang lebih besar memberikan konteks untuk potongan turunan yang lebih kecil.
"Model mengabaikan konteks yang baik dan mengada-ada." Ini adalah masalah perilaku yang mendorong dan menjadi model. Pengetahuan parametrik model bertentangan dengan konteks yang diberikan, dan pengetahuan parametriklah yang unggul. Perbaikan: sesuaikan perintah sistem Anda untuk secara eksplisit menginstruksikan model agar hanya menggunakan konteks yang disediakan, tambahkan instruksi "jika konteks tidak berisi jawabannya, katakan demikian", pertimbangkan untuk mengurangi suhu model.
"Jawabannya benar tetapi terlalu lambat." Masalah latensi biasanya disebabkan oleh salah satu dari tiga hal berikut: terlalu banyak panggilan pengambilan, jendela konteks yang terlalu besar (lebih banyak token = pembuatan lebih lambat), atau langkah pemeringkatan ulang yang menambah waktu pemrosesan. Profil komponen saluran Anda berdasarkan komponen. Cara mengatasinya tergantung kemana arah waktu.
"Kualitas tidak konsisten — bagus untuk beberapa topik, buruk untuk topik lainnya." Ini biasanya berarti beberapa bagian basis pengetahuan Anda diindeks lebih baik dibandingkan bagian lainnya. Mungkin dokumen tertentu diurai dengan buruk, atau topik tertentu kurang mendapat liputan. Petakan kegagalan Anda berdasarkan area topik dan Anda akan menemukan kesenjangannya.
Membangun Lingkaran Peningkatan Berkesinambungan
Tim RAG yang paling efektif memperlakukan sistem mereka seperti sebuah produk, bukan sebuah proyek. Itu tidak pernah "selesai". Setiap retrospektif harus menghasilkan peningkatan bertahap, dan peningkatan tersebut harus dapat diukur pada retrospektif berikutnya.
Irama praktis:
- Mingguan: Tinjauan singkat terhadap metrik kualitas otomatis (bisa asinkron, cukup periksa dasbor)
- Dua mingguan atau bulanan: Retrospektif penuh dengan analisis kegagalan
- Kuartalan: Keputusan arsitektur yang lebih besar — haruskah kita mengubah model penyematan, merestrukturisasi basis pengetahuan, mengadopsi strategi pengelompokan baru?
Simpan dokumen berjalan tentang apa yang telah Anda coba dan apa dampaknya. RAG pengoptimalan bersifat iteratif dan nonlinier — terkadang Anda akan meninjau kembali pendekatan yang sebelumnya tidak berhasil karena alur lainnya sudah cukup berubah sehingga bisa berfungsi sekarang.
Hindari Perangkap Benda Mengkilap
Setiap minggu ada makalah atau kerangka kerja baru yang mengklaim dapat memecahkan masalah kualitas RAG. Tahan keinginan untuk merancang ulang saluran Anda berdasarkan postingan blog. Sebaliknya, gunakan data retrospektif untuk mengidentifikasi masalah kualitas terbesar yang sebenarnya, dan selesaikan masalah spesifik tersebut. Mungkin jawabannya adalah model pemeringkatan baru yang mewah. Kemungkinan besar, ini memperbaiki cara Anda membagi dokumentasi produk Anda.
Tim yang berkembang paling cepat bukanlah tim yang menggunakan arsitektur tercanggih. Merekalah yang memiliki feedback loop paling ketat antara "output ini buruk" dan "inilah alasan spesifiknya, dan inilah yang kami ubah."
Coba NextRetro gratis — Kategorikan pola kegagalan RAG dengan kolom dan pilih perbaikan pipeline mana yang akan diprioritaskan.
Terakhir Diperbarui: Februari 2026
Waktu Membaca: 7 menit
