Pelancaran Vectroid , pangkalan data vektor tanpa pelayan yang baharu, telah mencetuskan perbincangan menarik dalam komuniti pembangun mengenai keadaan berpecah-belah teknologi carian vektor. Walaupun Vectroid berjanji untuk menyelesaikan pertukaran tradisional antara kelajuan, ketepatan, dan kos, pembangun membangkitkan persoalan yang lebih besar mengenai pendekatan industri dalam membina pangkalan data vektor.
Seruan untuk Enjin Vektor Universal
Perbincangan paling menarik yang muncul daripada pengumuman Vectroid berpusat pada kekurangan perpustakaan carian vektor piawai yang boleh dibenamkan. Pembangun menunjukkan bahawa landskap semasa memaksa pasukan untuk sama ada mengintegrasikan keupayaan vektor ke dalam pangkalan data sedia ada seperti PostgreSQL atau membina sistem yang berasingan sepenuhnya seperti Milvus dan kini Vectroid .
Komuniti menyeru sesuatu yang serupa dengan Apache DataFusion - perpustakaan yang berfungsi sebagai IR pangkalan data tetapi untuk operasi vektor. Ini akan membolehkan sistem pangkalan data yang berbeza menggabungkan carian vektor berkualiti tinggi tanpa mencipta semula algoritma teras setiap kali. Idea ini telah mendapat tarikan, dengan beberapa pembangun menunjuk kepada perpustakaan sedia ada seperti USearch dan FAISS sebagai asas yang berpotensi, walaupun ini tidak mencapai titik manis sebagai komponen sedia pangkalan data.
DataFusion: Rangka kerja pelaksanaan pertanyaan yang menyediakan keupayaan perancangan dan pelaksanaan pertanyaan SQL yang boleh dibenamkan ke dalam sistem lain
Perpustakaan Carian Vektor Sedia Ada yang Disebut
- USearch: Perpustakaan C++11 tajuk tunggal, digunakan dalam sambungan DuckDB-VSS dan ClickHouse
- FAISS: Perpustakaan Facebook Research untuk carian persamaan
- pgvector: Sambungan PostgreSQL untuk operasi vektor
- DataFusion: Rangka kerja pelaksanaan pertanyaan Apache (dipetik sebagai model untuk perpustakaan vektor yang diingini)
Cabaran Seni Bina Melampaui Algoritma
Walaupun perbincangan bermula dengan seruan untuk perpustakaan yang lebih baik, pembangun berpengalaman dengan cepat menyerlahkan bahawa cabaran sebenar terletak pada seni bina sistem teragih. Algoritma teras seperti HNSW (Hierarchical Navigable Small Worlds) difahami dengan baik, tetapi mengetahui cara mengimbangi kos, ketepatan, dan kelajuan pada skala memerlukan keputusan seni bina yang canggih.
Pendekatan Vectroid untuk memisahkan penulisan daripada bacaan dan menskalakan mereka secara bebas mewakili satu penyelesaian kepada cabaran ini. Pasukan di sebalik Vectroid , termasuk pengasas bersama Hazelcast , telah membina sistem mereka pada versi yang diubah suai Apache Lucene dengan pengoptimuman tersuai untuk beban kerja vektor. Mereka telah mencipta sistem fail tersuai yang berfungsi secara langsung dengan Google Cloud Storage , memintas lapisan penyimpanan tradisional untuk prestasi yang lebih baik.
HNSW: Algoritma berasaskan graf untuk carian jiran terdekat anggaran yang menawarkan keseimbangan yang baik antara kelajuan dan ketepatan
Komponen Seni Bina Teknikal
- Algoritma: HNSW ( Hierarchical Navigable Small Worlds ) untuk carian vektor
- Backend: Apache Lucene yang diubah suai dengan pengoptimuman tersuai
- Penyimpanan: Integrasi langsung dengan Google Cloud Storage ( S3 akan datang tidak lama lagi)
- Penskalaan: Perkhidmatan mikro berasingan untuk bacaan dan penulisan
- Infrastruktur: Penggunaan Kubernetes yang diuruskan melalui Terraform / Helm
- Bahasa: Pelaksanaan Java tulen
Dakwaan Prestasi dan Semakan Realiti
Dakwaan penanda aras Vectroid telah menarik minat dan keraguan. Syarikat melaporkan pengindeksan 1 bilion vektor dalam 48 minit dan mencapai latensi P99 34 milisaat pada set data yang besar. Walau bagaimanapun, ahli komuniti mempersoalkan sama ada koleksi vektor yang begitu besar berguna secara praktikal, memetik penyelidikan terkini yang menunjukkan bahawa ketepatan pembenaman merosot dengan ketara pada skala yang sangat besar.
Struktur kos juga menimbulkan keraguan. Walaupun Vectroid mendakwa mengindeks set data Deep1B dengan kos di bawah 12 dolar Amerika Syarikat menggunakan contoh spot Google Cloud , sesetengah pembangun berhujah bahawa untuk banyak kes penggunaan, pendekatan yang lebih mudah mungkin lebih kos efektif daripada membina sistem teragih yang kompleks.
Penanda Aras Prestasi Vectroid
- Mengindeks 1 bilion vektor dalam masa 48 minit
- Latensi P99: 34ms pada set data MS Marco (138M vektor, 1024 dimensi)
- Kos pengindeksan: <$12 USD untuk set data Deep1B menggunakan 6x n2-standard-96 spot instances
- Mengekalkan >90% penarikan balik sambil meningkat kepada 10 benang pertanyaan sesaat
Pembahagian Sumber Terbuka Berbanding Proprietari
Pengumuman ini telah mencetuskan semula perdebatan mengenai pendekatan proprietari berbanding sumber terbuka dalam ruang pangkalan data vektor. Sesetengah ahli komuniti menyatakan kekecewaan dengan satu lagi penyelesaian sumber tertutup yang memasuki pasaran di mana alternatif terbuka wujud. Walau bagaimanapun, pengasas Vectroid berhujah bahawa kekal sumber tertutup pada mulanya membolehkan mereka bergerak lebih pantas, sambil berjanji kemudahalihan data untuk mengurangkan kebimbangan penguncian.
Ketegangan ini mencerminkan persoalan yang lebih luas mengenai bagaimana inovasi berlaku dalam perisian infrastruktur. Walaupun penyelesaian sumber terbuka menyediakan ketelusan dan penglibatan komuniti, penyelesaian proprietari sering bergerak lebih pantas dan boleh membiayai usaha pengoptimuman yang lebih agresif.
Kesimpulan
Pelancaran Vectroid telah menjadi pemangkin untuk perbincangan yang lebih mendalam mengenai hala tuju masa depan ekosistem pangkalan data vektor. Sama ada industri memerlukan perpustakaan piawai yang lebih baik, lebih banyak inovasi seni bina, atau hanya pengoptimuman yang lebih baik bagi pendekatan sedia ada kekal sebagai persoalan terbuka. Apa yang jelas ialah ketika aplikasi AI memacu permintaan untuk carian vektor, komuniti secara aktif mencari penyelesaian yang tidak memaksa pertukaran yang menyakitkan antara prestasi, kos, dan ketepatan.
Rujukan: Why & how we built Vectroid