RAG yang bisa diperiksa: dari pencarian hybrid ke jawaban bersumber

Seorang editor bertanya, “fitur ini sudah tersedia untuk semua pelanggan?” Arsip memiliki pengumuman awal, revisi dokumentasi, dan artikel yang mengutip keduanya. Model bisa menjawab dengan lancar sambil memilih versi yang salah. Masalahnya bukan hanya generasi teks; bukti yang masuk ke konteks juga harus tepat.

Riset RAG oleh Lewis dan rekan-rekan menggabungkan model generatif dengan memori eksternal yang diambil lewat retrieval. Untuk aplikasi editorial, kita perlu menambahkan pengelolaan versi, hak akses, dan penghubung klaim ke sumber. Artikel ini merancang sistem tersebut menggunakan contoh sintetis; tidak melaporkan benchmark suatu layanan.

Kontrak jawaban menentukan rancangan pencarian

Tentukan keluaran sebelum memilih database. Untuk pertanyaan status produk, jawaban yang diterima setidaknya memuat status akses, tanggal bukti, dan rujukan yang dapat dibuka. Jika sumber tidak cukup, aplikasi harus dapat mengembalikan ketidakpastian secara eksplisit.

{
  "question_id": "Q17",
  "status": "needs_review",
  "claims": [{
    "text": "Pengumuman menyebut private preview.",
    "evidence_ids": ["D12:r3:p4"]
  }],
  "missing": ["Bukti bahwa akun pembaca sudah mendapat akses"]
}

Ini kontrak internal rancangan Nalarku. Kehadiran evidence_ids belum membuktikan kalimat benar. Editor masih perlu melihat apakah bukti memang mendukung seluruh klaim dan apakah ada dokumen lebih baru yang mengubahnya.

Ingestion perlu mempertahankan identitas dokumen

Simpan identitas sumber, URL, revisi, waktu pengambilan, dan lokasi potongan. Pisahkan tanggal dokumen dari tanggal sistem mengindeksnya. Dokumen lama yang baru diimpor tidak boleh tampak sebagai pengumuman baru.

Potong dokumen mengikuti struktur makna: heading, paragraf, daftar syarat, atau tabel yang tetap memiliki header. Ukuran chunk adalah parameter eksperimen, bukan angka universal. Potongan terlalu pendek dapat menghilangkan kata “belum”; potongan terlalu panjang dapat memasukkan banyak informasi yang tidak relevan dan menghabiskan konteks.

Simpan hubungan chunk_id → document_id → revision. Ketika dokumen diperbarui, indeks baru dan lama perlu status yang jelas. Jangan menghapus versi lama bila masih dibutuhkan untuk menelusuri artikel yang telah terbit, tetapi cegah versi usang menjadi hasil utama tanpa penanda.

Gabungkan pencarian leksikal dan semantik

Pencarian leksikal membantu saat kueri menyebut model ID, nomor versi, atau nama fitur persis. Pencarian vektor membantu ketika istilah pengguna berbeda dari istilah dokumen. Keduanya bisa memiliki skala skor yang tidak sebanding.

Dokumentasi Elastic menjelaskan reciprocal rank fusion: peringkat dokumen dari beberapa daftar digabungkan melalui kebalikan peringkat yang ditambah konstanta. Contoh Python lokal berikut tidak membutuhkan database atau model:

def reciprocal_rank_fusion(rankings, k=60):
    if k <= 0:
        raise ValueError("k harus positif")
    scores = {}
    for ranking in rankings:
        seen = set()
        for rank, document_id in enumerate(ranking, start=1):
            if document_id in seen:
                continue
            seen.add(document_id)
            scores[document_id] = scores.get(document_id, 0) + 1 / (k + rank)
    return sorted(scores.items(), key=lambda item: (-item[1], item[0]))


lexical = ["D12", "D02", "D09"]
semantic = ["D09", "D12", "D18"]
print(reciprocal_rank_fusion([lexical, semantic]))

D12 memperoleh kontribusi dari peringkat pertama dan kedua; D09 dari peringkat ketiga dan pertama. Konstanta 60 hanyalah pilihan contoh. Kandidat yang tidak muncul pada salah satu daftar tidak memperoleh kontribusi dari daftar tersebut. Fungsi ini tidak memeriksa tanggal, akses, atau kebenaran dokumen.

Hak akses dan kesegaran bukan pekerjaan reranker saja

Batas akses harus diterapkan ketika mengambil kandidat dan ketika membaca isi untuk jawaban. Mengambil semua dokumen lalu berharap model menyembunyikan yang privat adalah rancangan yang rapuh. Hak dokumen yang berubah juga harus tercermin pada cache hasil dan ringkasan tersimpan.

Setelah kandidat yang sah terkumpul, reranker dapat menilai relevansi yang lebih spesifik. Namun, relevansi berbeda dari kewenangan sumber. Artikel yang membahas pengumuman bisa sangat relevan, sementara dokumentasi resmi memuat syarat yang lebih tepat. Gunakan metadata jenis sumber dan revisi sebagai sinyal yang dapat dijelaskan.

Untuk pertanyaan “sekarang”, tambahkan pemeriksaan dokumen terbaru yang diketahui. Bila sumber bertentangan, tampilkan perbedaannya. Jangan menyatukan dua status yang berlaku pada tanggal berbeda menjadi satu kepastian palsu.

Pisahkan evaluasi retrieval dari evaluasi jawaban

Buat daftar pertanyaan dan potongan bukti rujukan. Uji apakah sistem menemukan bukti yang benar sebelum menilai gaya jawaban. Jika bukti tidak pernah diambil, menyunting prompt generasi saja tidak menyelesaikan sumber kegagalan.

Recall@k bukan satu-satunya ukuran. Mengambil ratusan potongan mungkin menaikkan recall sambil memperburuk biaya, latensi, dan fokus jawaban. Uji ukuran konteks dengan batas yang sesuai kebutuhan pengguna.

Eksperimen kecil yang dapat direproduksi

Mulai dengan arsip terbatas dan pertanyaan nyata yang telah dianonimkan. Simpan kueri, revisi indeks, konfigurasi chunking, kandidat, dan hasil akhir. Bandingkan pencarian leksikal saja, vektor saja, lalu gabungan, dengan generator yang sama.

Sertakan pertanyaan dengan jawaban tidak tersedia, istilah Indonesia yang bercampur bahasa Inggris, serta dokumen lama yang hampir benar. Nilai hasil tanpa melihat konfigurasi pencari bila memungkinkan. Catat juga waktu editor menemukan bukti, bukan sekadar waktu respons model.

Untuk implementasi penyimpanan dan pengujian indeks, lanjutkan ke panduan pgvector. Untuk memastikan bentuk keluaran dapat diproses aplikasi, gunakan kontrak Structured Outputs. Kedua komponen itu melengkapi retrieval; keduanya tetap membutuhkan pemeriksaan makna bukti.