Saat kamu bertanya kepada AI, jawaban yang lancar belum tentu memakai sumber yang tepat. Bayangkan editor bertanya, “fitur ini sudah tersedia untuk semua pelanggan?” Arsip berisi pengumuman awal, revisi dokumentasi, dan artikel yang mengutip keduanya, sehingga model bisa memilih versi yang salah.
Salah satu pendekatan mengambil bahan dari penyimpanan luar lebih dulu, lalu memakainya untuk menyusun jawaban. Pendekatan ini dikenal sebagai Retrieval-Augmented Generation, atau RAG, dan dibahas dalam riset Lewis dan rekan-rekan. Untuk pekerjaan redaksi, kita juga perlu mengurus versi, hak akses, dan hubungan tiap klaim dengan sumbernya.
Artikel ini memakai contoh buatan untuk merancang alurnya. Hasilnya bukan laporan uji kinerja suatu layanan.
Tentukan dulu jawaban seperti apa yang bisa diterima
Sebelum memilih database, tulis kebutuhan hasil akhirnya. Untuk status produk, jawaban setidaknya perlu menyertakan status akses, tanggal bukti, dan rujukan yang bisa dibuka. Jika sumber kurang, aplikasi harus bisa menyatakan ketidakpastian dengan jelas.
Berikut contoh kesepakatan bentuk data, atau kontrak keluaran:
{
"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"]
}Kontrak ini adalah rancangan internal Nalarku. Adanya evidence_ids belum membuktikan kalimat benar. Editor tetap perlu memeriksa apakah bukti mendukung seluruh klaim dan apakah dokumen lebih baru sudah mengubahnya.
Jaga identitas dokumen sejak bahan masuk
Proses memasukkan dokumen ke sistem pencarian biasa disebut ingestion. Simpan identitas sumber, URL, revisi, waktu pengambilan, dan lokasi potongannya. Pisahkan tanggal dokumen dari tanggal masuk ke daftar pencarian atau indeks, agar dokumen lama yang baru diimpor tidak terlihat sebagai pengumuman baru.
Potong dokumen mengikuti bagian yang masih utuh maknanya, seperti judul bagian, paragraf, daftar syarat, atau tabel bersama kepala kolomnya. Potongan ini disebut chunk. Ukurannya perlu diuji sesuai kebutuhan, karena potongan terlalu pendek bisa kehilangan kata “belum”, sedangkan potongan panjang bisa memenuhi ruang masukan model dengan hal yang tidak relevan.
Simpan hubungan chunk_id → document_id → revision. Saat dokumen berubah, tandai status indeks baru dan lama dengan jelas. Versi lama mungkin masih dibutuhkan untuk menelusuri artikel terbit, tetapi jangan membiarkannya menjadi hasil utama tanpa penanda bahwa isinya sudah usang.
Cari lewat kata sekaligus kemiripan makna
Pencarian berdasarkan kata, atau leksikal, membantu saat kamu menyebut ID model, nomor versi, atau nama fitur yang persis. Pencarian berdasarkan deretan angka yang mewakili makna, atau vektor, membantu saat kata dalam pertanyaan berbeda dari dokumen. Gabungan keduanya sering disebut pencarian hybrid, dan skor mentahnya belum tentu bisa langsung dibandingkan.
Dokumentasi Elastic menjelaskan cara menggabungkan urutan hasil dari beberapa daftar, atau reciprocal rank fusion. Kontribusi tiap dokumen dihitung dari kebalikan peringkat yang sudah ditambah konstanta. Contoh Python lokal ini tidak memerlukan 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 mendapat kontribusi dari peringkat pertama dan kedua, sedangkan D09 dari peringkat ketiga dan pertama. Angka 60 hanya pilihan konstanta dalam contoh. Jika calon hasil tidak muncul di satu daftar, daftar itu tidak memberi kontribusi untuknya.
Fungsi ini menggabungkan peringkat saja. Ia belum memeriksa tanggal, izin, atau kebenaran isi dokumen.
Periksa izin dan kebaruan sebelum menyusun jawaban
Terapkan batas akses saat mengambil calon hasil dan saat membaca isinya. Proses pengambilan ini disebut retrieval. Jangan mengambil semua dokumen lalu berharap model menyembunyikan bagian privat; perubahan hak dokumen juga harus berlaku pada simpanan hasil sementara atau cache dan rangkuman tersimpan.
Setelah calon hasil yang boleh diakses terkumpul, alat pengurut ulang atau reranker bisa menilai kecocokannya secara lebih khusus. Namun, kecocokan topik berbeda dari kewenangan sumber. Artikel pembahasan bisa sangat relevan, sementara dokumentasi resmi memberi syarat yang lebih tepat.
Gunakan keterangan jenis sumber dan revisi sebagai alasan pengurutan yang bisa dijelaskan. Untuk pertanyaan “sekarang”, periksa dokumen terbaru yang diketahui. Jika sumber bertentangan, tampilkan bedanya, jangan mencampur dua status dari tanggal berbeda menjadi satu kepastian.
Uji pencarian dan jawaban secara terpisah
Buat daftar pertanyaan dan potongan bukti acuan. Periksa apakah sistem menemukan bukti yang benar sebelum menilai gaya jawabannya. Jika bukti tidak pernah diambil, mengubah instruksi model atau prompt saja tidak menyelesaikan penyebab masalah.
| Tahap | Contoh ukuran | Arti kegagalan |
|---|---|---|
| Pengambilan bukti | Bagian bukti berlabel yang masuk k hasil teratas, atau Recall@k | Bukti relevan tidak masuk calon hasil |
| Pengurutan | Posisi bukti yang paling membantu | Buktinya ada, tetapi tertimbun |
| Penyusunan jawaban | Klaim yang didukung bukti | Model menambah atau mengubah fakta |
| Pemberian rujukan | Kecocokan tautan untuk tiap klaim | Rujukannya ada, tetapi tidak mendukung kalimat |
| Menahan jawaban saat bukti kurang, atau abstention | Kasus tanpa bukti yang tidak dijawab | Sistem tetap menjawab yakin saat bukti kurang |
Recall@k perlu dibaca bersama ukuran lain. Mengambil ratusan potongan mungkin menaikkan recall sambil menambah biaya, waktu tunggu, dan gangguan pada fokus jawaban. Uji banyaknya bahan yang masuk sesuai batas kebutuhan pengguna.
Mulai dari percobaan kecil yang bisa diulang
Gunakan arsip terbatas dan pertanyaan nyata yang identitas pribadinya sudah dihilangkan. Simpan pertanyaan pencarian, revisi indeks, cara memotong dokumen, calon hasil, dan jawaban akhir. Bandingkan pencarian kata saja, vektor saja, lalu gabungan, dengan penyusun jawaban yang sama.
Masukkan pertanyaan yang jawabannya tidak tersedia, campuran istilah Indonesia dan Inggris, serta dokumen lama yang hampir benar. Bila memungkinkan, nilai hasil tanpa melihat pengaturan pencariannya. Catat juga waktu yang dibutuhkan editor untuk menemukan bukti, bukan hanya waktu model menjawab.
Panduan pgvector melanjutkan cara menyimpan data dan menguji indeks. Untuk bentuk keluaran yang bisa diproses aplikasi, baca kontrak Structured Outputs. Pencarian dan format yang baik tetap perlu dilengkapi pemeriksaan makna bukti.
