Vector Databases: Embeddings, Similarity Search, dan Indexing

Daftar Isi

• Pendahuluan
• Apa yang Disimpan Vector Database?
• Apa yang Direpresentasikan Embedding?
• Cara Kerja Similarity Search
• Metadata Filtering
• Vector Indexing
• pgvector vs Dedicated Vector Database
• Kesalahan Umum
• Checklist
• FAQ
• Kesimpulan

Pendahuluan

Vector database jadi populer karena aplikasi AI modern tidak cukup hanya mengandalkan keyword search. User sering bertanya dengan bahasa natural, sementara dokumen di sistem bisa memakai istilah yang berbeda, singkatan yang tidak konsisten, atau format yang sama sekali tidak mirip. Di kondisi seperti ini, sistem tetap harus bisa menemukan konten yang relevan dengan cepat.

Vector database membantu dengan menyimpan embedding: representasi numerik dari text, gambar, produk, tiket, atau item lain yang ingin dibandingkan berdasarkan makna. Dengan cara ini, pencarian tidak cuma melihat kata yang persis sama, tetapi juga hubungan semantik di balik kontennya.

Artikel ini membahas konsep inti vector search tanpa membuatnya terdengar terlalu “magic”. Yang perlu dipahami adalah embedding, similarity search, indexing, metadata, dan kapan vector database benar-benar perlu dipakai. Kalau bagian-bagian ini sudah kebayang, alur kerja RAG dan semantic search biasanya jauh lebih gampang dipahami. Setelah ini, kamu bisa lanjut ke RAG vs Fine-Tuning untuk melihat bagaimana vector search dipakai di workflow AI yang lebih lengkap, atau baca Laravel 13 release kalau ingin melihat contoh native vector search di ekosistem Laravel.

Apa yang Disimpan Vector Database?

Vector database menyimpan vector bersama dengan metadata yang relevan. Vector dipakai untuk mencari kedekatan makna, sedangkan metadata dipakai untuk memberi konteks tambahan supaya hasilnya lebih tepat.

Field	Contoh
id	doc_42
embedding	[0.12, -0.44, 0.08, ...]
text	”Cara rotate credential staging”
metadata	{ team: "platform", env: "staging" }

Vector dipakai untuk similarity search. Sedangkan metadata membantu filter dan menjelaskan hasil pencarian, misalnya membatasi hasil berdasarkan team, environment, language, atau status dokumen.

Apa yang Direpresentasikan Embedding?

Embedding model mengubah konten menjadi daftar angka. Angka-angka ini tidak dibaca satu per satu secara manual, tapi dipelajari agar konten dengan makna yang mirip cenderung berada dekat di vector space. Karena itu, dua kalimat yang beda kata pun bisa tetap dianggap berhubungan.

Contoh:

Text	Makna
”reset password”	account recovery
”lupa credential login”	account recovery
”database connection pool”	backend infrastructure

Dua frasa pertama tidak memakai keyword yang sama, tapi embedding-nya bisa tetap berdekatan. Inilah alasan vector search sering lebih kuat daripada keyword search untuk kasus seperti FAQ, support ticket, atau pencarian dokumen internal.

Cara Kerja Similarity Search

Saat user bertanya, sistem membuat embedding dari query lalu mencari vector tersimpan yang paling dekat. Biasanya hasil ini kemudian di-rank lagi, supaya dokumen yang paling relevan muncul di urutan atas.

User query -> query embedding -> nearest vectors -> ranked results

Contoh:

Rank	Dokumen	Similarity
1	Password reset runbook	0.91
2	Account recovery FAQ	0.87
3	Login troubleshooting guide	0.82

Hasilnya bukan “kata yang sama”, tapi “makna yang dekat”.

Metadata Filtering

Similarity saja belum cukup. Hasil bisa dekat secara makna, tapi salah secara konteks operasional.

Misalnya, runbook staging tidak boleh menjawab incident production kecuali user memang bertanya tentang staging.

Gunakan metadata filter:

{
  "team": "platform",
  "environment": "production",
  "status": "active"
}

Retrieval yang bagus sering menggabungkan semantic search dengan filter seperti tenant, team, permission, version, language, atau status dokumen.

Vector Indexing

Brute-force vector search membandingkan query dengan semua vector tersimpan. Ini bisa jalan untuk data kecil, tapi lambat saat data membesar.

Vector index mempercepat pencarian dengan mempersempit kandidat.

Ide index	Yang dioptimalkan
HNSW	approximate nearest neighbor yang cepat
IVF	membagi vector ke beberapa grup sebelum search
Flat	exact search, sederhana tapi lebih lambat di skala besar

Banyak sistem production menerima approximate search karena jauh lebih cepat dan hasilnya biasanya cukup baik. Trade-off-nya ada di recall: kadang neighbor terbaik bisa terlewat.

pgvector vs Dedicated Vector Database

Kamu tidak selalu butuh database vector terpisah.

Opsi	Cocok untuk	Perlu diperhatikan
PostgreSQL + pgvector	aplikasi sudah memakai Postgres, skala sedang, butuh relational filtering kuat	batas scaling dan tuning
Dedicated vector DB	semantic search skala besar, banyak collection, workload vector-heavy	infrastruktur dan biaya operasional tambahan
Search engine hybrid	keyword + semantic search	moving parts lebih banyak

Contoh dedicated vector database yang sering dipakai antara lain Pinecone, Weaviate, Milvus, dan Qdrant. Kalau kamu butuh opsi yang lebih ringan untuk prototyping, Chroma juga sering muncul di ekosistem AI.

Mulai dari setup paling sederhana yang masih memenuhi kebutuhan latency, recall, dan operasional.

Kesalahan Umum

Meng-index data yang berantakan

Dokumen buruk menghasilkan retrieval buruk. Bersihkan, deduplicate, dan version data sumber sebelum indexing.

Mengabaikan metadata

Semantic similarity tidak otomatis paham permission, environment, atau aturan bisnis.

Menganggap similarity tinggi pasti benar

Similarity adalah sinyal ranking, bukan bukti. Evaluasi hasil dengan query nyata.

Terlalu cepat memilih infrastruktur

Banyak tim memilih database khusus sebelum memahami volume data, pola query, dan kebutuhan filtering.

Checklist

• Pilih embedding model yang cocok dengan tipe konten.
• Simpan text, vector, dan metadata bersama.
• Gunakan metadata filter untuk permission dan konteks bisnis.
• Ukur retrieval dengan pertanyaan user nyata.
• Pilih index setting berdasarkan latency dan recall.
• Jaga dokumen sumber tetap bersih dan versioned.
• Re-embed saat model atau konten sumber berubah.
• Mulai sederhana sebelum menambah dedicated infrastructure.

FAQ

Apakah RAG selalu butuh vector database?

Tidak selalu. Dataset kecil bisa mulai dari search sederhana. Vector database berguna saat semantic retrieval, skala, latency, dan metadata filtering mulai penting.

Apakah vector search lebih baik dari keyword search?

Masalahnya berbeda. Vector search mencari kedekatan makna. Keyword search tetap kuat untuk exact term, ID, error code, dan nama produk.

Apa itu hybrid search?

Hybrid search menggabungkan vector similarity dan keyword search. Ini sering lebih baik untuk dokumen teknis karena istilah exact tetap penting.

Kesimpulan

Vector database berguna saat aplikasi perlu mencari berdasarkan makna, bukan hanya keyword. Tapi database hanya satu bagian dari sistem.

Hasil yang baik datang dari data bersih, metadata yang berguna, embedding model yang tepat, indexing yang hati-hati, dan evaluasi dengan query nyata.

Kamu lagi pakai pgvector, dedicated vector database, atau masih tahap coba-coba? Ceritakan pilihanmu, use case-nya, atau tantangan yang paling terasa di kolom komentar. Pengalaman nyata sering lebih membantu daripada teori doang. 💬