Vector search yang akurat pada seribu dokumen belum tentu tetap nyaman ketika knowledge base berkembang menjadi jutaan chunks dan menerima banyak query bersamaan.
Di production, kualitas pencarian harus berjalan bersama latency, throughput, biaya, data freshness, dan reliability.
Karena itu, Mengoptimalkan Vector Search untuk knowledge assistant membutuhkan pendekatan yang lebih luas daripada sekadar memilih embedding model.
Tim engineering perlu mengelola trade-off antara recall dan kecepatan, mengurangi ruang pencarian, mengontrol jumlah kandidat, serta memonitor perilaku retrieval seiring bertambahnya data dan pengguna.
1. Tetapkan Baseline sebelum Melakukan Tuning
Optimasi tanpa baseline mudah berubah menjadi eksperimen tanpa arah.
Mulailah dengan beberapa metrik inti seperti p50 dan p95 latency, Recall@K, jumlah query per detik, ukuran index, biaya per pencarian, serta task success rate knowledge assistant.
Misalnya konfigurasi awal menghasilkan Recall@10 sebesar 92% dengan p95 retrieval latency 700 milidetik. Setelah tuning ANN, latency turun menjadi 300 milidetik tetapi recall menjadi 75%.
Apakah itu peningkatan?
Belum tentu. Jawabannya bergantung pada kebutuhan aplikasi.
Untuk knowledge assistant internal yang mengutamakan akurasi kebijakan, penurunan recall tersebut mungkin terlalu mahal. Untuk autocomplete yang membutuhkan respons hampir instan, kompromi berbeda bisa diterima.
Karena itu, optimasi harus mempunyai target kualitas dan performa sejak awal.
2. Pahami Trade-Off Exact KNN dan ANN
Exact nearest-neighbor search membandingkan query terhadap seluruh candidate vector sehingga menghasilkan retrieval yang sangat akurat, tetapi biaya komputasinya semakin besar ketika dataset tumbuh.
Approximate nearest neighbor atau ANN mengambil pendekatan berbeda. Sistem menggunakan index agar dapat menemukan kandidat yang sangat dekat tanpa membandingkan semua vector.
Google menjelaskan bahwa exact KNN menawarkan recall lebih tinggi, sedangkan ANN menukar sedikit akurasi untuk kecepatan dan skalabilitas yang lebih baik pada dataset besar.
Amazon OpenSearch juga menyediakan approximate k-NN menggunakan algoritma seperti HNSW untuk mempercepat pencarian pada kumpulan data besar.
Artinya, tidak ada pilihan yang otomatis terbaik.
Gunakan exact search sebagai ground truth pada subset data. Kemudian bandingkan ANN terhadapnya untuk mengetahui berapa recall yang hilang demi mendapatkan peningkatan performa.
3. Tune ANN Berdasarkan Recall dan Latency Bersamaan
Algoritma ANN seperti HNSW mempunyai parameter yang memengaruhi seberapa luas graph dieksplorasi ketika melakukan pencarian.
Eksplorasi lebih luas biasanya meningkatkan peluang menemukan neighbor yang benar, tetapi latency dan kebutuhan komputasi ikut naik.
Karena itu, jangan mengoptimalkan latensy secara terpisah.
Buat eksperimen beberapa konfigurasi dan gambarkan hubungan antara recall serta response time. Pilih titik yang memenuhi service-level objective aplikasi.
Azure AI Search mendukung HNSW maupun exhaustive KNN pada vector ranking, sementara hasil pencarian kemudian diberi skor berdasarkan similarity metric yang dikonfigurasi.
Pada OpenSearch, penggunaan graph juga mempunyai konsekuensi memory. AWS bahkan menyediakan metric KNNGraphMemoryUsage untuk membantu memonitor penggunaan memori index k-NN.
Optimasi index berarti mengelola resource, bukan sekadar mengejar benchmark retrieval.
4. Persempit Kandidat dengan Metadata dan Namespace
Mencari pada seluruh knowledge base setiap kali pengguna bertanya sering tidak diperlukan.
Bayangkan perusahaan mempunyai 20 juta chunks dari berbagai negara, unit bisnis, dan tahun. Jika pengguna divisi finance Indonesia menanyakan SOP pembayaran vendor, sebagian besar index sebenarnya tidak relevan sejak awal.
Gunakan metadata atau namespace untuk mempersempit candidate set.
Pinecone memungkinkan metadata filtering berdasarkan atribut seperti string, angka, dan boolean. Google Vertex AI juga mendukung restrict atau filtering untuk membatasi similarity search pada subset index.
Contohnya:
country = Indonesia
department = Finance
document_status = Active
Setelah filter diterapkan, vector search hanya bekerja pada ruang data yang memang layak.
Pendekatan ini dapat memperbaiki relevansi sekaligus membantu permission isolation pada aplikasi multitenant.
Namun metadata harus dibuat konsisten sejak ingestion. Kesalahan penamaan atau field yang sering kosong dapat menghasilkan filtering yang justru membuang informasi penting.
5. Optimalkan Jumlah Kandidat sebelum Reranking
Pipeline production sering menggunakan pola retrieve wide, rerank narrow.
Misalnya ANN mengambil 50 kandidat dengan cepat. Reranker kemudian membaca kandidat tersebut dan hanya memilih lima terbaik untuk diberikan kepada LLM.
Cara ini memungkinkan retrieval tahap pertama lebih berorientasi pada recall sementara tahap kedua mengejar precision.
Pinecone menjelaskan reranking sebagai proses dua tahap yang mengambil kandidat terlebih dahulu lalu memberikan skor semantik baru berdasarkan hubungan query dan dokumen.
Namun jumlah kandidat harus di-tuning.
Mengambil 200 kandidat mungkin menaikkan recall sedikit, tetapi biaya reranker serta latency dapat melonjak. Mengambil lima kandidat saja murah, namun hasil relevan mungkin belum masuk candidate pool.
Uji beberapa nilai seperti 10, 25, 50, dan 100 berdasarkan golden dataset.
Pilih titik ketika tambahan kandidat tidak lagi memberikan peningkatan kualitas yang berarti.
6. Hindari Mengirim Data yang Tidak Dibutuhkan
Vector search response dapat menjadi lebih berat daripada yang terlihat, terutama ketika top-k tinggi.
Jika aplikasi hanya membutuhkan ID, similarity score, dan teks chunk, jangan mengembalikan vector lengkap setiap query.
Dokumentasi Pinecone menyarankan tidak menyertakan vector values bila tidak dibutuhkan, terutama pada nilai top_k yang besar, karena ukuran response dapat memengaruhi performa.
Prinsip yang sama berlaku untuk metadata.
Jangan mengirim metadata puluhan field jika context builder hanya membutuhkan empat.
Untuk query populer dan corpus yang jarang berubah, caching juga dapat dipertimbangkan. Namun cache key perlu memperhatikan filter, permission, versi knowledge base, dan query normalization agar pengguna tidak menerima hasil yang salah.
Optimasi sederhana pada payload sering lebih mudah dilakukan daripada tuning index yang kompleks.
7. Perhatikan Data Freshness pada Knowledge Assistant
Knowledge assistant hanya berguna jika informasi terbaru dapat ditemukan.
Masalahnya, indexing vector tidak selalu bersifat instan. Ada sistem yang memerlukan waktu sebelum data baru terlihat pada pencarian.
Pinecone, misalnya, mendokumentasikan model eventual consistency sehingga record yang baru diubah dapat membutuhkan sedikit waktu sebelum terlihat oleh query.
Untuk knowledge base yang sering berubah, ukur freshness lag.
Misalnya dokumen kebijakan baru dipublikasikan pukul 10.00. Berapa lama sampai knowledge assistant mampu menggunakannya?
Lima menit mungkin masih aman untuk dokumentasi produk, tetapi bisa bermasalah untuk sistem yang memproses perubahan operasional yang kritis.
Tim perlu menentukan SLA ingestion sekaligus mekanisme menghapus atau menonaktifkan dokumen lama.
Jangan sampai versi baru masuk ke index tetapi versi sebelumnya tetap mempunyai peluang retrieval yang sama besar.
8. Gunakan Hybrid Search untuk Query yang Sulit secara Semantik
ANN sangat efektif pada semantic similarity, tetapi pengguna knowledge assistant sering memasukkan query yang berisi nomor tiket, SKU, versi software, singkatan, dan kode error.
Keyword retrieval jauh lebih kuat untuk pola seperti itu.
Azure AI Search menggabungkan vector dan full-text search secara paralel kemudian memadukan ranking menggunakan RRF. Microsoft menyebut hybrid search dengan semantic reranking sebagai salah satu strategi utama untuk menghasilkan hasil yang relevan.
Google Vector Search juga mendukung dense dan sparse embedding untuk hybrid retrieval.
Tim tidak perlu memilih salah satu secara permanen.
Query dapat menggunakan semantic vector, lexical signal, atau keduanya sesuai karakter pencarian. Weight antara kedua signal kemudian diuji menggunakan dataset nyata.
9. Bangun Observability untuk Search Pipeline
Jika hanya memonitor uptime vector database, Anda belum benar-benar memonitor knowledge assistant.
Catat query latency, embedding latency, filter yang digunakan, candidate count, similarity score, reranking time, top document, token context, serta feedback pengguna.
Perhatikan juga distribusi p50, p95, dan p99. Average latency dapat terlihat bagus meskipun sebagian pengguna mengalami retrieval yang sangat lambat.
Setelah perubahan konfigrasi dilakukan, bandingkan bukan hanya kecepatan tetapi juga Recall@K dan task success rate.
Tambahkan query gagal atau feedback negatif ke regression dataset. Jalankan kembali pengujiaan setiap kali mengganti embedding model, ANN parameters, chunking, atau ranking logic.
Dengan observabilty seperti ini, optimasi berubah dari pekerjaan berdasarkan intuisi menjadi proses engineering yang bisa diukur.
Mengoptimalkan Vector Search di production berarti menyeimbangkan recall, latency, biaya, dan freshness.
Gunakan ANN dengan target kualitas yang jelas, perkecil ruang pencarian menggunakan metadata, tune candidate pool, lalu tambahkan hybrid search dan reranking saat diperlukan.
Bangun dashboard retrieval sejak awal agar setiap perubahan dapat dibuktikan manfaatnya sebelum diterapkan ke seluruh pengguna knowledge assistant.