Peluncuran Vectroid, sebuah database vektor serverless baru, telah memicu diskusi menarik di komunitas developer tentang kondisi terfragmentasi teknologi pencarian vektor. Meskipun Vectroid berjanji untuk menyelesaikan trade-off tradisional antara kecepatan, akurasi, dan biaya, para developer mengangkat pertanyaan yang lebih besar tentang pendekatan industri dalam membangun database vektor.
Seruan untuk Universal Vector Engine
Diskusi paling menarik yang muncul dari pengumuman Vectroid berpusat pada kurangnya library pencarian vektor yang terstandarisasi dan dapat disematkan. Para developer menunjukkan bahwa lanskap saat ini memaksa tim untuk mengintegrasikan kemampuan vektor ke dalam database yang sudah ada seperti PostgreSQL atau membangun sistem yang sepenuhnya terpisah seperti Milvus dan sekarang Vectroid.
Komunitas menyerukan sesuatu yang mirip dengan Apache DataFusion - sebuah library yang berfungsi sebagai IR database tetapi untuk operasi vektor. Ini akan memungkinkan sistem database yang berbeda untuk menggabungkan pencarian vektor berkualitas tinggi tanpa harus menemukan kembali algoritma inti setiap kali. Ide ini telah mendapat perhatian, dengan beberapa developer menunjuk pada library yang sudah ada seperti USearch dan FAISS sebagai fondasi potensial, meskipun ini tidak cukup tepat sebagai komponen yang siap untuk database.
DataFusion: Sebuah framework eksekusi query yang menyediakan kemampuan perencanaan dan eksekusi query SQL yang dapat disematkan ke dalam sistem lain
Pustaka Pencarian Vektor yang Ada yang Disebutkan
- USearch: Pustaka C++11 header tunggal, digunakan dalam ekstensi DuckDB-VSS dan ClickHouse
- FAISS: Pustaka Facebook Research untuk pencarian kemiripan
- pgvector: Ekstensi PostgreSQL untuk operasi vektor
- DataFusion: Framework eksekusi kueri Apache (dikutip sebagai model untuk pustaka vektor yang diinginkan)
Tantangan Arsitektur di Luar Algoritma
Meskipun diskusi dimulai dengan seruan untuk library yang lebih baik, developer berpengalaman dengan cepat menyoroti bahwa tantangan sebenarnya terletak pada arsitektur sistem terdistribusi. Algoritma inti seperti HNSW (Hierarchical Navigable Small Worlds) sudah dipahami dengan baik, tetapi mencari tahu bagaimana menyeimbangkan biaya, akurasi, dan kecepatan dalam skala besar memerlukan keputusan arsitektur yang canggih.
Pendekatan Vectroid dalam memisahkan operasi tulis dari baca dan menskalakan keduanya secara independen merepresentasikan satu solusi untuk tantangan ini. Tim di balik Vectroid, termasuk co-founder Hazelcast, telah membangun sistem mereka pada versi modifikasi Apache Lucene dengan optimisasi khusus untuk beban kerja vektor. Mereka telah menciptakan sistem file khusus yang bekerja langsung dengan Google Cloud Storage, melewati lapisan penyimpanan tradisional untuk performa yang lebih baik.
HNSW: Algoritma berbasis graf untuk pencarian tetangga terdekat perkiraan yang menawarkan keseimbangan yang baik antara kecepatan dan akurasi
Komponen Arsitektur Teknis
- Algoritma: HNSW ( Hierarchical Navigable Small Worlds ) untuk pencarian vektor
- Backend: Apache Lucene yang dimodifikasi dengan optimasi khusus
- Penyimpanan: Integrasi langsung dengan Google Cloud Storage ( S3 akan segera hadir)
- Penskalaan: Layanan mikro terpisah untuk operasi baca dan tulis
- Infrastruktur: Deployment Kubernetes yang dikelola melalui Terraform / Helm
- Bahasa: Implementasi Java murni
Klaim Performa dan Reality Check
Klaim benchmark Vectroid telah menarik minat sekaligus skeptisisme. Perusahaan melaporkan pengindeksan 1 miliar vektor dalam 48 menit dan mencapai latensi P99 34 milidetik pada dataset besar. Namun, anggota komunitas mempertanyakan apakah koleksi vektor yang sangat besar seperti itu praktis berguna, mengutip penelitian terbaru yang menunjukkan bahwa akurasi embedding menurun secara signifikan pada skala yang sangat besar.
Struktur biaya juga menimbulkan keraguan. Meskipun Vectroid mengklaim dapat mengindeks dataset Deep1B dengan biaya di bawah 12 dolar Amerika menggunakan spot instance Google Cloud, beberapa developer berpendapat bahwa untuk banyak kasus penggunaan, pendekatan yang lebih sederhana mungkin lebih cost-effective daripada membangun sistem terdistribusi yang kompleks.
Benchmark Performa Vectroid
- Mengindeks 1 miliar vektor dalam 48 menit
- Latensi P99: 34ms pada dataset MS Marco (138M vektor, 1024 dimensi)
- Biaya pengindeksan: <$12 USD untuk dataset Deep1B menggunakan 6x n2-standard-96 spot instances
- Mempertahankan recall >90% sambil melakukan scaling hingga 10 query threads per detik
Perpecahan Open Source Versus Proprietary
Pengumuman ini telah memicu kembali perdebatan tentang pendekatan proprietary versus open-source dalam ruang database vektor. Beberapa anggota komunitas mengekspresikan frustrasi dengan solusi closed-source lainnya yang memasuki pasar di mana alternatif open source sudah ada. Namun, founder Vectroid berargumen bahwa tetap closed-source pada awalnya memungkinkan mereka bergerak lebih cepat, sambil berjanji portabilitas data untuk mengurangi kekhawatiran vendor lock-in.
Ketegangan ini mencerminkan pertanyaan yang lebih luas tentang bagaimana inovasi terjadi dalam perangkat lunak infrastruktur. Meskipun solusi open-source menyediakan transparansi dan keterlibatan komunitas, solusi proprietary sering bergerak lebih cepat dan dapat mendanai upaya optimisasi yang lebih agresif.
Kesimpulan
Peluncuran Vectroid telah menjadi katalis untuk diskusi yang lebih mendalam tentang arah masa depan ekosistem database vektor. Apakah industri membutuhkan library terstandarisasi yang lebih baik, inovasi arsitektur yang lebih banyak, atau hanya optimisasi yang lebih baik dari pendekatan yang sudah ada masih menjadi pertanyaan terbuka. Yang jelas adalah bahwa ketika aplikasi AI mendorong permintaan untuk pencarian vektor, komunitas secara aktif mencari solusi yang tidak memaksa trade-off yang menyakitkan antara performa, biaya, dan akurasi.
Referensi: Why & how we built Vectroid