Angka evaluasi Recall@8 pada sistem Retrieval-Augmented Generation (RAG) bisa berubah dari satu kali eksekusi ke eksekusi berikutnya, meskipun pengembang menggunakan query, dokumen, dan model kecerdasan buatan yang persis sama. Fenomena ini kerap dianggap sebagai kegagalan model dalam memberikan output yang stabil, padahal akar masalahnya terletak pada lapisan pengambilan data.
Temuan tersebut bukan lahir dari sekadar mengamati metrik yang naik-turun, melainkan dari kebiasaan sang pengembang membaca kode pengambilan data secara langsung. Ia mengadopsi kebiasaan menulis skrip evaluasi sebelum membangun fitur itu sendiri. Saat meninjau alur pengambilan di balik fitur "Ask this Book" pada perangkat lunaknya, ia menyadari bahwa lapisan retriever tidak berjalan secara deterministik.
RAG merupakan arsitektur yang kini banyak diandalkan untuk menjawab keterbatasan model bahasa besar (LLM) dalam memahami dokumen privat atau terkini. Sistem ini bekerja dengan mencari potongan informasi relevan dari basis data, lalu menyuntikkannya ke dalam prompt yang diberikan kepada model. Di Indonesia, banyak startup teknologi dan perusahaan enterprise mulai mengadopsi pendekatan ini untuk membangun chatbot internal maupun layanan bantuan pelanggan.
Pada kasus yang ditelusuri ini, implementasi RAG sengaja dibuat sederhana menggunakan PostgreSQL dan kerangka kerja .NET. Terdapat dua strategi pencarian yang berjalan di atas tabel yang sama: pencarian semantik memanfaatkan ekstensi pgvector serta pencarian leksikal melalui fitur pencarian teks lengkap (full-text search) milik PostgreSQL. Kedua hasil pencarian tersebut kemudian digabungkan menggunakan metode Reciprocal Rank Fusion (RRF).
Poin krusial dari RRF adalah algoritma ini tidak memedulikan skor kemiripan dari masing-masing mesin pencari, melainkan hanya memperhatikan peringkat (rank). Apabila sebuah pencari mengembalikan urutan dokumen A, B, lalu C, sementara pencari lainnya memberikan B, A, C, maka RRF akan menghasilkan skor gabungan yang berbeda. Skor gabungan yang berbeda berujung pada daftar Top-K yang tidak sama, yang pada gilirannya mengubah nilai Recall@K. Dalam konteks ini, urutan baris data bukan sekadar tampilan, melainkan bagian dari masukan sistem.
Kesalahan teknis bermula dari klausa SQL yang digunakan untuk mengambil data leksikal, yakni ORDER BY score DESC. Secara kasat mata, penulisan tersebut tampak wajar. Namun, fungsi ts_rank_cd pada PostgreSQL kerap menghasilkan skor yang sama (ties) untuk banyak potongan teks. SQL hanya menjamin pengurutan berdasarkan kolom yang diminta secara eksplisit. Jika beberapa baris memiliki nilai setara, PostgreSQL bebas mengembalikannya dalam urutan apa pun. Pencarian semantik juga memiliki masalah serupa terkait jarak vektor, yang memang lebih jarang terjadi, tetapi tetap tidak bisa ditoleransi dalam pipa evaluasi yang menuntut presisi.
Perbaikan atas anomali ini terbilang sangat sederhana dan hampir tidak terlihat. Pengembang cukup menambahkan pemisah seri (tie-breaker) deterministik pada kedua query, yakni mengubah klausa menjadi ORDER BY score DESC, id. Dengan demikian, baris yang memiliki skor identik akan selalu muncul dalam urutan yang sama. RRF pun menerima masukan yang seragam di setiap eksekusi, sehingga daftar Top-K tetap konsisten. Yang penting untuk digarisbawahi, perbaikan ini tidak membuat kemampuan pengambilan data menjadi lebih baik, melainkan sekadar mereproduksinya secara pasti.
Hal ini membawa pelajaran berharga bagi ekosistem teknologi di Tanah Air. Ketika melakukan evaluasi model, tim pengembang biasanya berupaya keras membuat komponen AI deterministik: menetapkan suhu (temperature) pada angka 0, menggunakan kumpulan data tetap, serta merumuskan prompt yang dapat direproduksi. Namun, ada asumsi keliru bahwa seluruh komponen di bawah model sudah pasti deterministik. Padahal, banyak layanan RAG lokal dibangun di atas PostgreSQL karena efisiensi biaya dan kemudahan operasional.
Ketidakpastian pada tahap retriever, perankingan, hingga pemuatan data dapat secara diam-diam merusak validitas evaluasi. Jika angka evaluasi berfluktuasi tanpa sebab yang jelas, bahayanya adalah tim teknis pada akhirnya kehilangan kepercayaan terhadap metrik tersebut, sekalipun metrik tersebut sebenarnya sedang menunjukkan sebuah masalah nyata pada sistem. Di Indonesia, di mana banyak tim AI masih berjuang menyeimbangkan kecepatan rilis produk dengan kualitas evaluasi, jebakan ini sangat mungkin terjadi.
Sang pengembang yang juga membangun TextStack, sebuah pembaca buku teknis sumber terbuka (open-source) berbasis .NET, menegaskan prinsip utamanya. Sebelum melakukan debug pada model, debug terlebih dahulu determinisme sistem Anda, demikian inti peringatannya. Sebuah evaluasi hanya bisa se-deterministik pipa data yang memberinya makan. Query yang sama, baris yang sama, dan urutan yang sama menjadi syarat mutlak sebelum seseorang bisa memercayai apa yang disampaikan oleh skrip evaluasi.
Ke depan, praktik penulisan evaluasi sebelum fitur dibangun (eval-driven development) diprediksi akan semakin relevan, khususnya bagi tim yang mengelola sistem RAG berskala produksi. Mendeteksi ketidakpastian sejak dari tingkat basis data akan menyelamatkan banyak jam kerja yang terbuang untuk menyalahkan model bahasa besar. Standardisasi query dengan pemisah seri harus menjadi bagian dari panduan pengembangan perangkat lunak berbasis AI.
Di samping itu, tren menggunakan tumpukan teknologi ringan seperti PostgreSQL dan .NET alih-alih basis data vektor khusus juga akan terus tumbuh seiring makin matangnya ekstensi pgvector. Pengembang di Indonesia perlu menyadari bahwa memastikan reproduktibilitas tidak berhenti pada pengaturan prompt, tetapi meliputi setiap baris perintah SQL yang dieksekusi untuk menjemput konteks bagi model.