Skip to content
‹ All articles

· Catatan kerja · Written in Indonesian

Menggabungkan vector dan full-text search di Averra AI

Menangani makna, istilah persis, embedding model, dan reranking dalam pencarian dokumen Averra AI.

Duration 6:01 · Synthetic Indonesian voice from OmniVoice

Untuk menjawab pertanyaan dari database, agent dapat membaca schema tabel sebelum menyusun query. Pada dokumen, jawabannya bisa tersebar dalam paragraf, judul bagian, daftar, atau potongan kode. Agent perlu menemukan bagian yang relevan terlebih dahulu.

Di Averra, proses ini menggabungkan pencarian berdasarkan makna dan kecocokan kata, lalu menilai kembali kandidat yang ditemukan. Embedding dan reranking yang saya ukur dalam pengujian AI lokal digunakan pada tahap-tahap tersebut.

Dokumen masuk sebagai teks yang dapat ditelusuri#

Sebelum dapat dicari, isi dokumen perlu disiapkan. PDF dikonversi menjadi Markdown, lalu teksnya dipotong berdasarkan heading dan paragraf dengan code fence yang tetap utuh. Setiap potongan kemudian diberi embedding, yaitu representasi vector untuk pencarian berdasarkan makna, dan dimasukkan ke knowledge store.

Naskah Markdown juga disimpan terpisah dari potongannya. Potongan yang memiliki overlap tidak dapat langsung digabung kembali menjadi naskah asli karena sebagian teks berulang dan pengaturan pemotongannya dapat berbeda. Penyimpanan naskah ini membantu proses edit dan import ulang.

Jika embedding salah satu potongan gagal, import ditolak. Naskah ditulis paling akhir agar editor tidak menawarkan teks yang belum tersedia pada jalur retrieval.

Dua cara menemukan kandidat#

Setelah potongan tersimpan, Averra mencarinya melalui dua jalur. Vector search mencari kedekatan makna, sedangkan full-text search mencari kecocokan kata. Keduanya digunakan karena sebuah pertanyaan dapat memuat parafrasa sekaligus identifier yang harus tepat.

Sebagai ilustrasi, pertanyaan tentang aturan pada dokumen KM 526 tidak cukup dijawab dengan paragraf dari KM 525 walaupun topiknya mirip, karena angka tersebut menentukan dokumen yang dimaksud.

Alur pencarian menggabungkan dua jalur kandidat sebelum reranking:

flowchart TD
    Q[Pertanyaan] --> V[Vector search]
    Q --> T[Full-text search]
    Q --> I[Identifier yang harus cocok]
    V --> F[Gabungkan skor dan periksa identifier]
    T --> F
    I --> F
    F --> R[Rerank kandidat teratas]
    R --> A[Potongan sumber untuk jawaban]

Untuk jalur full-text, PostgreSQL menggunakan konfigurasi bahasa Inggris dan Indonesia serta mencocokkan judul bagian. Kata fungsi bahasa Indonesia yang termasuk stopword dibersihkan dari query. Jika tidak ada kata yang tersisa setelah pembersihan, pencarian dapat mengandalkan jalur vector.

Identifier tidak diperlakukan seperti topik#

Untuk menangani contoh seperti KM 526, RequiredTerms mengenali bentuk yang menamai objek, seperti frasa dalam tanda kutip, kode huruf dan angka, atau nama kolom dengan underscore. Kandidat dari jalur full-text maupun vector harus memenuhi persyaratan tersebut.

Pencocokan frasa menjaga kedekatan kata, sehingga nomor yang muncul jauh dari nama dokumen tidak otomatis setara dengan identifier lengkap. Ketika tidak ada potongan yang memenuhi syarat, hasil kosong lebih sesuai daripada daftar paragraf yang hanya mirip topiknya.

Meski begitu, mekanisme ini tidak menghapus kebutuhan untuk menilai sumber. Identifier yang cocok dapat muncul pada daftar referensi sementara pembahasan utamanya berada di bagian lain, sehingga pemilihan kandidat hanyalah tahap awal menuju jawaban.

Model embedding merupakan bagian dari data#

Selain kecocokan identifier, jalur vector bergantung pada model yang menghasilkan embedding. Dua model dengan dimensi vector yang sama belum tentu memakai ruang representasi yang sama. Karena itu, vector query dari model baru tidak boleh langsung dibandingkan dengan vector dokumen dari model lama.

Untuk menjaga kecocokan tersebut, Averra menyimpan nama model bersama embedding. Jalur vector hanya menilai potongan yang dibuat dengan model yang sesuai, sedangkan potongan dari model lain masih dapat ditemukan melalui kata. Saat konfigurasi model diganti, vector yang sudah tersimpan perlu diperbarui melalui re-embedding.

Reranking dan batas kandidat#

Setelah kedua jalur pencarian menghasilkan kandidat, reranker yang dikonfigurasi menilai kembali kandidat teratas. Model cross-encoder membaca pertanyaan dan setiap potongan secara berpasangan untuk menilai relevansinya. Skornya berupa raw logit, bukan persentase keyakinan. Nilainya tidak dibandingkan langsung antarpertanyaan atau dicampur dengan skor pencarian awal.

Penilaian ulang ini hanya berlaku pada kandidat yang sudah ditemukan. Potongan yang terlewat pada pencarian awal tetap tidak akan muncul, karena pengaturan scan indeks HNSW dan filter collection membatasi pencarian sebelum tahap reranking.

Jika reranker gagal atau mengembalikan jumlah skor yang tidak sesuai, pencarian dinyatakan gagal. Skor yang hilang tidak diisi dengan nol, karena kandidat tanpa penilaian justru dapat ditempatkan di atas kandidat yang mendapat logit negatif.

Mengukur sebelum mengganti ranking#

Dengan batas tersebut, evaluasi retrieval perlu memeriksa dua hal: apakah bahan yang relevan berhasil ditemukan dan apakah urutannya membantu menjawab pertanyaan. Repository memiliki harness evaluasi untuk mengukur recall, reciprocal rank, nDCG, dan penanganan pertanyaan tanpa jawaban. Angka dari harness itu hanya berlaku untuk dataset yang diukurnya, sehingga perubahan ranking dibandingkan pada dataset yang sama sebelum dan sesudah perubahan.

Potongan yang lolos reranking diberikan kepada model bersama sumbernya, sehingga jawaban dapat menyebut dokumen asal dan menyatakan bila bahan yang ditemukan tidak cukup. Kemampuan pencarian ini juga dapat digunakan dari client lain melalui MCP server Averra, yang akan saya bahas pada artikel berikutnya.

Comments

0 comments

No comments yet.