Bagaimana Membangun RAG yang Dapat Diandalkan: Penyelaman Mendalam ke Dalam 7 Titik Kegagalan dan Kerangka Evaluasi

Retrieval-Augmented Generation (RAG) sangat penting untuk arsitektur AI modern, berfungsi sebagai kerangka esensial untuk membangun agen yang sadar konteks.

Namun, beralih dari prototipe dasar ke sistem yang siap produksi melibatkan navigasi hambatan signifikan dalam pengambilan data, konsolidasi konteks, dan sintesis respons.

Artikel ini menyediakan penyelaman mendalam ke dalam tujuh titik kegagalan RAG yang umum dan metrik evaluasi dengan contoh kode praktis.

Anatomi Kegagalan RAG – 7 Titik Kegagalan (FPs)

Menurut peneliti Barnett et al., Sistem RAG (Retrieval Augmented Generation) mengalami tujuh Titik Kegagalan (FPs) spesifik sepanjang pipa.

Berikut adalah ilustrasi tahap-tahap tersebut:

Gambar A. Proses Pengindeksan dan Pencarian yang diperlukan untuk membuat sistem RAG. Proses pengindeksan dilakukan pada waktu pengembangan dan pencarian pada waktu runtime. Titik-titik kegagalan yang diidentifikasi dalam studi ini ditunjukkan dengan kotak merah (sumber)

Mari kita jelajahi setiap FP yang disusun sesuai urutan pipa, mengikuti kemajuan dari kiri atas ke kanan bawah seperti yang ditunjukkan pada Gambar A.

FP1. Konten yang Hilang

Konten yang hilang terjadi ketika sistem diminta pertanyaan yang tidak dapat dijawab karena informasi yang relevan tidak ada dalam toko vektor yang tersedia pada awalnya.

Kegagalan terjadi ketika LLM (Model Bahasa Besar) memberikan jawaban yang masuk akal tetapi salah, bukan mengatakan tidak tahu.

FP2. Melewatkan Dokumen Peringkat Teratas

Ini adalah situasi di mana dokumen yang benar ada di toko vektor, tetapi pengambil (retriever) gagal untuk menempatkannya di peringkat yang cukup tinggi untuk dimasukkan dalam dokumen top-k yang diberikan kepada LLM sebagai konteks.

Akibatnya, informasi yang benar tidak pernah mencapai LLM.

FP3. Tidak dalam Konteks (Keterbatasan Strategi Konsolidasi)

Ini adalah situasi di mana dokumen yang benar ada dan diambil dari toko vektor, tetapi dikecualikan selama proses konsolidasi.

Hal ini terjadi ketika terlalu banyak dokumen yang dikembalikan dan sistem harus menyaringnya untuk memasukkannya dalam jendela konteks LLM, batas token, atau batas tarif.

FP4. Tidak Diekstrak

Ini adalah situasi di mana LLM gagal untuk mengidentifikasi informasi yang benar dalam konteks, bahkan ketika informasi yang benar ada di toko vektor dan berhasil diambil/dikonsolidasikan.

Hal ini terjadi ketika konteks terlalu berisik atau mengandung informasi yang bertentangan yang membingungkan LLM.

FP5. Format yang Salah

Ini adalah situasi di mana penyimpanan, pengambilan, konsolidasi, dan interpretasi LLM berhasil dilakukan, tetapi LLM gagal untuk mengikuti instruksi format khusus yang diberikan dalam prompt, seperti tabel, daftar berbullets, atau skema JSON.

FP6. Spesifisitas yang Tidak Tepat

Keluaran LLM secara teknis ada, tetapi terlalu umum atau terlalu kompleks dibandingkan dengan kebutuhan pengguna.

Misalnya, LLM menghasilkan jawaban sederhana untuk pertanyaan pengguna dengan tujuan profesional yang kompleks.

FP7. Jawaban yang Tidak Lengkap

Ini adalah situasi di mana LLM menghasilkan keluaran yang tidak salah, tetapi kehilangan potongan informasi kunci yang tersedia dalam konteks.

Misalnya, ketika pengguna bertanya pertanyaan yang kompleks seperti “Apa poin-poin kunci dalam dokumen A, B, dan C?”, LLM hanya menangani satu atau dua sumber.

Bagaimana FPs Membahayakan Kinerja Pipa RAG

Setiap FPs ini berdampak pada kinerja pipa RAG:

Kegagalan Integritas Data & Kepercayaan

Ketika informasi yang hilang atau salah ada, sistem tidak lagi menjadi sumber informasi yang dapat diandalkan. FPs utama termasuk:

• FP1 (Konten yang Hilang): Jawabannya tidak ada di dokumen pada awalnya.
• FP4 (Tidak Diekstrak): LLM memutuskan untuk mengabaikan jawaban yang benar dalam dokumen.
• FP7 (Tidak Lengkap): LLM memberikan setengah kebenaran, kehilangan potongan informasi penting.

Botol Leher Pengambilan & Efisiensi

Pipa RAG dapat tidak efisien ketika melewatkan informasi kunci dalam tahap pengambilan dan konsolidasi. FPs utama termasuk:

• FP2 (Melewatkan Dokumen Peringkat Teratas): Model pengambil gagal untuk memilih pengambilan top-k.
• FP3 (Keterbatasan Strategi Konsolidasi): Skrip untuk memotong dokumen untuk memasukkannya dalam batas LLM menghilangkan bagian paling penting.

Kesalahan Pengalaman Pengguna & Format

Meskipun benar, keluaran dengan keterbacaan yang buruk atau dalam format yang salah dapat merusak pengalaman pengguna. FPs utama termasuk:

• FP5 (Format yang Salah): LLM gagal untuk mengikuti format keluaran khusus seperti JSON.
• FP6 (Spesifisitas yang Tidak Tepat): LLM menghasilkan keluaran yang panjang untuk pertanyaan ya/tidak, atau sebaliknya (terlalu singkat untuk pertanyaan yang rumit).

Tumpukan Evaluasi: Kerangka untuk Mengurangi FPs

Metrik evaluasi dirancang untuk secara sistematis mengurangi FPs ini.

Bagian ini menjelajahi metrik evaluasi utama RAG dengan contoh kode praktis.

Metrik Evaluasi RAG Utama:

• DeepEval
• RAGAS
• TruLens
• Arize Phoenix
• Braintrust

DeepEval – Pengujian Unit Sebelum Penerapan

DeepEval menghitung skor tertimbang berdasarkan kriteria.

Sebuah LLM-sebagai-hakim (misalnya, GPT-4o) mengevaluasi setiap kriteria terhadap keluaran LLM:

DeepEval menggunakan G-eval, sebuah kerangka rantai-pemikiran (CoT) yang mengambil pendekatan multi-langkah untuk mengevaluasi keluaran:

1. Definisikan kriteria untuk diukur (misalnya, “kohesi,” “kelancaran,” atau “relevansi”).
2. Generasikan langkah evaluasi (menggunakan LLM evaluator).
3. Ikuti langkah evaluasi dan menganalisis input dan keluaran LLM.
4. Menghitung jumlah tertimbang yang diharapkan dari skor setiap kriteria.

Skenario Umum dalam Praktik

• Situasi: Asisten dokumentasi teknis (bot) untuk produk perangkat lunak kompleks tampaknya bekerja setiap kali tim insinyur memperbarui basis kode.
• Masalah: Tidak ada bukti kuantitatif jika bot masih dapat menjawab pertanyaan pengguna (Anda hanya “berpikir” itu bekerja…).
• Solusi: Integralkan fungsi PyTest sebagai suite regresi CI/CD ke dalam Github Action di mana DeepEval menjalankan G-Eval dan metrik lainnya atas kasus uji:

• Hasil yang diharapkan: Jika skor metrik mana pun turun di bawah ambang batas (0,85), PyTest memicu AssertionError – langsung menggagalkan build CI, mencegah regressi sunyi dari mencapai produksi.

Kelebihan

• Sejumlah metrik (50+) termasuk pemeriksaan bias dan toksisitas khusus tersedia.
• Terintegrasi dengan pipa CI/CD yang ada.
• Tidak memerlukan referensi. Menilai keluaran berdasarkan prompt dan konteks yang diberikan saja.

Kelemahan

• Kualitas evaluasi sangat bergantung pada kemampuan LLM hakim.
• Biaya komputasi yang mahal ketika LLM hakim adalah model tingkat tinggi.

Catatan Pengembang – Kasus Uji untuk DeepEval
Sebuah set LLMTestCase objek mendefinisikan kasus uji yang dijalankan DeepEval.

Dalam praktik, kasus uji ini harus berisi sebagian besar pertanyaan pengguna dan keluaran yang dilabeli dengan konteks yang diterima.

Ini dapat diperoleh dari file JSON atau CSV.

RAGAS – Optimizer Jarum di Tumpukan

RAGAS (Retrieval Augmented Generation Assessment) bertujuan untuk mengevaluasi RAG tanpa dataset yang dianotasi oleh manusia dengan menghasilkan set uji sintetis.

Kemudian, ia menghitung metrik bendera:

Gambar B. Diagram triad evaluasi RAGAS yang menghubungkan Pertanyaan, Konteks, dan Jawaban melalui metrik Presisi, Recall, Kejujuran, dan Relevansi (Dibuat oleh Kuriko IWAI)

Metrik bendera tersebut dikelompokkan ke dalam tiga kelompok:

• Pipa pengambilan (garis hitam, garis padat, Gambar B): Presisi konteks, recall konteks.
• Pipa generasi (garis hitam, garis putus-putus, Gambar B): Kejujuran, relevansi jawaban.
• Kejujuran (kotak merah, Gambar B): Kesamaan semantik jawaban, kebenaran jawaban.

Skenario Umum dalam Praktik

• Situasi: Sistem RAG untuk kontrak hukum kehilangan klausa kunci. Anda tidak yakin apakah masalahnya ada di Pencarian (Pengambil) atau Pembacaan (Penghasil).
• Masalah: Tidak ada gagasan tentang top-k optimal (jumlah potongan yang diambil).
• Solusi: Gunakan RAGAS untuk membuat set uji sintetis dengan 100 pasang pertanyaan dan bukti. Kemudian, jalankan pipa RAG melawan set uji untuk menghitung recall konteks dan presisi konteks:
• Hasil yang diharapkan: Bergantung pada hasil metrik, rencana tindakan dapat berupa:

Tabel 1. Matriks Tindakan Diagnostik RAGAS – Pemetaan Skor ke Penyesuaian Sistem.

Kelebihan

• Sangat baik untuk proyek tahap awal tanpa dataset kejujuran (Seperti yang kita lihat di potongan kode, RAGAS dapat membuat set uji sintetis).

Kelemahan

• Set uji sintetis mungkin melewatkan kesalahan faktual yang halus.
• Memerlukan model pengambil yang kuat untuk memecah jawaban menjadi klaim individual (Saya menggunakan gpt-4o dalam contoh).

TruLens – Spesialis Lingkaran Umpan Balik

TruLens fokus pada mekanika internal proses RAG daripada hanya keluaran akhir dengan menggunakan fungsi umpan balik.

Ini juga menggunakan skor LLM yang mencerminkan seberapa baik respons memenuhi niat pertanyaan, menggunakan skala Likert 4 poin (0-3), membuatnya unggul untuk peringkat kualitas hasil pencarian yang berbeda.

Skenario Umum dalam Praktik

• Situasi: Bot penasihat medis menjawab pertanyaan pengguna dengan benar tetapi menambahkan tips yang tidak ada dalam basis PDF yang diverifikasi.
• Masalah: Tips tambahan mungkin berguna, tetapi tidak berbasis.
• Solusi: Gunakan TruLens untuk mengimplementasikan fungsi umpan balik yang berbasis dengan ambang batas seperti skor > 0,8.

• Hasil yang diharapkan: Ketika LLM menghasilkan respons yang mengandung informasi tidak hadir dalam potongan yang diambil, TruLens menandai catatan di dashboard Anda.

Kelebihan

• Visualisasikan rantai pemikiran untuk mengidentifikasi secara tepat di mana agen menyimpang.
• Menyediakan dukungan bawaan untuk grounding untuk menangkap halusinasi secara real-time.

Kelemahan

• Belajar kurva untuk mendefinisikan fungsi umpan balik kustom.
• Dasbor dapat terasa berat untuk skrip sederhana.

Arize Phoenix – Peta Kegagalan Sunyi

Arize Phoenix adalah alat observabilitas dan evaluasi sumber terbuka untuk mengevaluasi keluaran LLM, termasuk sistem RAG yang kompleks.

Dibangun di atas OpenTelemetry oleh Arize AI, ini fokus pada observabilitas dengan mengobati evaluasi LLM sebagai subset dari MLOps.

Dalam konteks evaluasi RAG, Phoenix unggul dalam analisis embedding, menggunakan Uniform Manifold Approximation and Projection (UMAP) untuk mengurangi embedding vektor tinggi dimensi menjadi ruang 2D/3D.

Analisis embedding ini secara matematis mengungkapkan apakah kueri yang gagal dikelompokkan secara semantik bersama, yang menunjukkan celah dalam basis data vektor.

Skenario Umum dalam Praktik

• Situasi: Bot dukungan pelanggan bekerja dengan baik untuk pengembalian dana, tetapi memberikan jawaban tidak masuk akal untuk klaim garansi.
• Masalah: Lubang data di basis data vektor (Tidak dapat ditemukan dalam log).
• Solusi: Gunakan Arize Phoenix untuk menghasilkan Visualisasi Embedding UMAP (UEV), peta 3D untuk basis data vektor – untuk menumpangkan kueri pengguna pada potongan dokumen.
• Hasil yang diharapkan: Secara visual lihat kumpulan kueri pengguna yang mendarat di zona gelap di mana tidak ada dokumen, menunjukkan bahwa beberapa dokumen dilupakan untuk diunggah ke toko vektor.

Kelebihan

• Berasal dari OpenTelemetry; terintegrasi dengan tumpukan pemantauan perusahaan yang ada.
• Alat terbaik untuk visualisasi titik buta toko vektor.

Kelemahan

• Lebih fokus pada pengamatan, bukan pada skoring.
• Dapat berlebihan untuk aplikasi skala kecil atau alat tunggal.

Braintrust – Jaring Pengaman Regresi Prompt

Braintrust dirancang untuk siklus iterasi frekuensi tinggi dengan menggunakan perbandingan antar-model.

Skenario Umum dalam Praktik

• Situasi: Tim insinyur meningkatkan prompt dari “Jawab pertanyaan” (Kasus A) ke instruksi sistem 500 kata yang lebih kompleks (Kasus B).
• Masalah: Meningkatkan prompt untuk Kasus B mungkin secara tidak sengaja merusak Kasus A.
• Solusi: Gunakan Braintrust untuk membuat dataset emas dengan set contoh sempurna (misalnya, N = 50). Biarkan Braintrust menjalankan perbandingan sampingan (SxS) setiap kali tim memperbarui satu kata dalam prompt:

• Hasil yang diharapkan: Laporan perbedaan yang menunjukkan persis mana kasus yang menjadi lebih baik/lebih buruk untuk setiap dataset emas (N = 50).

Kelebihan

• Sangat cepat untuk diuji sebelum penerapan.
• Antarmuka yang hebat untuk pemangku kepentingan non-teknis untuk meninjau dan menilai keluaran.

Kelemahan

• Proprietary/SaaS-fokus (meskipun mereka memiliki komponen sumber terbuka).
• Metrik teknis dalam lebih sedikit dibandingkan dengan DeepEval atau Ragas.

Mengakhiri

Ketika ditangani dengan kerangka evaluasi yang tepat, RAG dapat menjadi alat kompetitif untuk memberikan konteks LLM yang paling relevan dengan pertanyaan pengguna.

Strategi Implementasi: Pemetaan Metrik ke Titik Kegagalan

Meskipun tidak ada solusi yang pas untuk semua, Tabel 2 menunjukkan metrik evaluasi mana yang diterapkan untuk setiap FP yang dibahas dalam artikel ini:

Tabel 2. Matriks Mitigasi Titik Kegagalan – Alat Mana yang Menyelesaikan FP Mana?

DeepEval dan RAGAS dapat menggunakan metrik kejujuran mereka untuk mengukur kegagalan integritas data (FP1, FP4, FP7).

TruLens menggunakan presisi konteks / recall untuk mengukur relevansi konteks terhadap keluaran – secara efektif menilai FP2.

Arize Phoenix menyediakan jejak visual proses pengambilan, membuatnya mudah untuk melihat apakah dokumen yang diambil hilang selama konsolidasi (FP3).

Untuk kegagalan UX, DeepEval membuat metrik kustom untuk menilai kegagalan UX, sementara Braintrust unggul dalam perbandingan dataset kejujuran.