Embeddings dan Vector Database

Analogi: Peta Arti Kata

Bayangkan setiap kata/frasa punya koordinat di peta raksasa berdimensi ratusan. Di peta ini, "kucing" berdekatan dengan "anjing" (sama-sama hewan peliharaan), jauh dari "komputer". "Raja" - "pria" + "wanita" mendarat dekat "ratu": hubungan makna menjadi hubungan JARAK. Embedding adalah koordinat itu: representasi teks sebagai deretan angka (vektor) yang menangkap makna.

Kenapa ini revolusioner? Karena pencarian biasa mencocokkan HURUF ("cari kata 'kucing'"), sedangkan pencarian embedding mencocokkan ARTI ("cari yang berhubungan dengan hewan peliharaan" akan menemukan dokumen tentang kucing meski kata "hewan peliharaan" tidak muncul). Inilah mesin di balik RAG.

Contoh 1: Merasakan Pencarian Makna (Konsep Praktis)

Bayangkan kamu punya 4 catatan:

1. "Cara merawat kucing anggora"
2. "Panduan memberi makan anjing"
3. "Tutorial install Linux"
4. "Resep nasi goreng spesial"

Query: "hewan peliharaan yang lucu". Pencarian kata kunci (Ctrl+F): NOL hasil (tidak ada catatan mengandung frasa itu). Pencarian embedding: catatan 1 dan 2 muncul teratas, karena "makna" mereka dekat dengan query, meski katanya beda.

Inilah yang terjadi di RAG: pertanyaan user diubah jadi embedding, dibandingkan jaraknya dengan embedding tiap chunk dokumen, yang terdekat diambil. Kamu tidak perlu menghafal istilah persis yang dipakai dokumen; cukup bertanya dengan bahasamu sendiri.

Coba rasakan: buka demo pencarian semantik gratis mana pun (misal demo sentence-transformers), masukkan 5 kalimatmu sendiri, lalu query dengan kata yang TIDAK ADA di kalimat-kalimat itu tapi semakna. Lihat ia tetap menemukan yang tepat.

Contoh 2: Vector Database, Lemari Arsip Super Cepat (Praktik)

Embedding saja tidak cukup; kamu butuh tempat menyimpan jutaan vektor dan mencari yang terdekat dalam milidetik. Itulah vector database.

Pilihan praktis per kebutuhan:

• Prototipe/belajar: Chroma atau FAISS. Jalan lokal, gratis, setup 5 menit. Cukup untuk ribuan dokumen.
• Aplikasi serius dengan Postgres: pgvector (ekstensi Postgres). Kalau aplikasimu sudah pakai Postgres, ini pilihan natural: data biasa dan vektor dalam satu database.
• Skala besar managed: Pinecone, Weaviate, Qdrant. Berbayar tapi menangani jutaan vektor tanpa kamu urus infrastruktur.

Alur tipikal (dengan Chroma, Python):

# 1. Buat koleksi dan isi dengan dokumen
collection.add(
    documents=["Cara merawat kucing...", "Tutorial install Linux..."],
    ids=["doc1", "doc2"]
)
# 2. Cari yang mirip dengan query
hasil = collection.query(query_texts=["hewan peliharaan"], n_results=2)
# hasil berisi doc1 teratas: pencarian makna, bukan kata!

Perhatikan: kamu tidak menulis algoritma pencariannya; vector DB yang menangani matematika jarak vektor (biasanya cosine similarity) secara efisien.

Catatan teknis: Embedding dibuat oleh embedding model (berbeda dari LLM chat; lebih kecil, khusus). Kualitasnya diukur dengan benchmark MTEB; untuk bahasa Indonesia, tidak semua model top global bagus, jadi uji dengan datamu sendiri. Dimensi umum: 384 (kecil, cepat), 768, 1536 (besar, akurat). Trade-off: dimensi besar = akurat tapi lambat dan mahal disimpan. Jarak dihitung biasanya dengan cosine similarity (sudut antar vektor, bukan jarak fisik). Satu peringatan penting: embedding menangkap makna umum, bukan fakta presisi. "Harga produk X adalah 50 ribu" vs "harga produk X adalah 500 ribu": embedding-nya SANGAT dekat (makna mirip) padahal faktanya beda jauh. Jangan andalkan embedding untuk membedakan angka/fakta detail; itu tugas tahap generation dengan konteks lengkap.

Kesalahan Umum

1. Mengira embedding = memahami. Embedding menangkap kemiripan makna statistik, bukan pemahaman. Ia bisa mengelompokkan hal yang "terdengar mirip" tapi salah secara faktual.
2. Tidak menormalisasi teks. Dokumen dengan format berantakan (HTML mentah, header berulang di tiap chunk) menghasilkan embedding buruk. Bersihkan dulu: hapus boilerplate, pastikan tiap chunk utuh satu topik.
3. Memilih vector DB sebelum butuh. Untuk belajar, Chroma lokal cukup. Jangan langsung langganan layanan mahal untuk 100 dokumen.
4. Lupa metadata. Simpan info tambahan per chunk (sumber, halaman, tanggal). Saat menjawab, metadata ini memungkinkan sitasi ("menurut manual hal. 42") yang meningkatkan kepercayaan.

Rangkuman

Embedding = teks jadi koordinat makna; pencarian embedding = cari berdasarkan arti, bukan huruf. Vector database = penyimpanan + pencarian vektor super cepat. Bersama-sama mereka adalah mesin retrieval di jantung RAG. Pahami keterbatasannya (lemah di angka/fakta presisi) dan kamu bisa merancang RAG yang tidak asal jadi.