Tolok Ukur Bohong - DB Vektor Layak untuk Diuji Secara Nyata

Basis Data Vektor yang Anda Pilih Berdasarkan Tolok Ukur Mungkin Gagal dalam Produksi

Ketika memilih database vektor untuk aplikasi AI Anda, tolok ukur konvensional seperti mengemudikan mobil sport di lintasan kosong, hanya untuk mendapati mobil tersebut macet di jam-jam sibuk. Kebenaran yang tidak nyaman? Sebagian besar tolok ukur hanya mengevaluasi kinerja dalam kondisi buatan yang tidak pernah ada di lingkungan produksi.

Sebagian besar benchmark menguji database vektor setelah semua data dicerna dan indeks dibangun sepenuhnya. Namun dalam produksi, data tidak pernah berhenti mengalir. Anda tidak bisa menghentikan sistem Anda selama berjam-jam untuk membangun kembali indeks.

Kami telah melihat langsung pemutusan hubungan tersebut. Sebagai contoh, Elasticsearch mungkin membanggakan kecepatan kueri tingkat milidetik, tetapi di balik layar, kami telah menyaksikannya membutuhkan waktu lebih dari 20 jam hanya untuk mengoptimalkan indeksnya. Itu adalah waktu henti yang tidak dapat ditanggung oleh sistem produksi, terutama dalam beban kerja AI yang menuntut pembaruan terus menerus dan respons instan.

Dengan Milvus, setelah menjalankan evaluasi Proof of Concept (PoC) yang tak terhitung jumlahnya dengan klien perusahaan, kami telah menemukan pola yang meresahkan: basis data vektor yang unggul di lingkungan lab yang terkendali sering kali kesulitan di bawah beban produksi yang sebenarnya. Kesenjangan kritis ini tidak hanya membuat para insinyur infrastruktur frustasi, tetapi juga dapat menggagalkan seluruh inisiatif AI yang dibangun di atas janji-janji kinerja yang menyesatkan ini.

Itulah mengapa kami membangun VDBBench: benchmark sumber terbuka yang dirancang dari awal untuk mensimulasikan realitas produksi. Tidak seperti pengujian sintetis yang memilih skenario, VDBBench mendorong basis data melalui konsumsi terus menerus, kondisi penyaringan yang ketat, dan skenario yang beragam, seperti beban kerja produksi Anda yang sebenarnya. Misi kami sederhana: memberikan alat bantu kepada teknisi yang menunjukkan bagaimana kinerja database vektor dalam kondisi dunia nyata sehingga Anda dapat membuat keputusan infrastruktur berdasarkan angka yang dapat dipercaya.

Kesenjangan antara Tolok Ukur dan Kenyataan

Pendekatan pembandingan tradisional memiliki tiga kelemahan kritis yang membuat hasilnya tidak berarti bagi pengambilan keputusan produksi:

1. Data yang sudah ketinggalan zaman

Banyak tolok ukur yang masih mengandalkan set data yang sudah ketinggalan zaman seperti SIFT atau GloVe, yang tidak memiliki kemiripan dengan penyematan vektor berdimensi tinggi yang kompleks saat ini yang dihasilkan oleh model AI. Pertimbangkan ini: SIFT berisi vektor 128 dimensi, sedangkan embedding populer dari model embedding OpenAI berkisar antara 768 hingga 3072 dimensi.

2. Metrik Kesombongan

Banyak tolok ukur yang hanya berfokus pada latensi rata-rata atau QPS puncak, yang menciptakan gambaran yang menyimpang. Metrik yang diidealkan ini gagal untuk menangkap outlier dan ketidakkonsistenan yang dialami pengguna sebenarnya di lingkungan produksi. Sebagai contoh, apa gunanya angka QPS yang mengesankan jika membutuhkan sumber daya komputasi tak terbatas yang akan membangkrutkan organisasi Anda?

3. Skenario yang Terlalu Sederhana

Sebagian besar benchmark hanya menguji beban kerja dasar dan statis - pada dasarnya adalah "Hello World" dari pencarian vektor. Sebagai contoh, mereka mengeluarkan permintaan pencarian hanya setelah seluruh dataset dicerna dan diindeks, mengabaikan realitas dinamis di mana pengguna melakukan pencarian saat data baru masuk. Desain sederhana ini mengabaikan pola kompleks yang mendefinisikan sistem produksi nyata seperti kueri bersamaan, pencarian yang difilter, dan konsumsi data yang terus menerus.

Menyadari kekurangan ini, kami menyadari bahwa industri ini membutuhkan perubahan radikal dalam filosofi pembandingan- yang didasarkan pada bagaimana sistem AI berperilaku di alam liar. Itulah mengapa kami membangun VDBBench.

Dari Lab ke Produksi: Bagaimana VDBBench Menjembatani Kesenjangan

VDBBench tidak hanya mengulang filosofi pembandingan yang sudah ketinggalan zaman - VDBBench membangun kembali konsep ini dari prinsip-prinsip dasar dengan satu keyakinan yang memandu: sebuah pembandingan hanya berharga jika dapat memprediksi perilaku produksi yang sebenarnya.

Kami telah merekayasa VDBBench untuk mereplikasi kondisi dunia nyata dengan tepat di tiga dimensi penting: keaslian data, pola beban kerja, dan pengukuran kinerja.

Memodernisasi Dataset

Kami telah merombak total dataset yang digunakan untuk benchmarking VDBBench. Alih-alih menggunakan set pengujian lawas seperti SIFT dan GloVe, VDBBench menggunakan vektor yang dihasilkan dari model penyematan mutakhir yang mendukung aplikasi AI saat ini.

Untuk memastikan relevansi, terutama untuk kasus penggunaan seperti Retrieval-Augmented Generation (RAG), kami memilih korpora yang mencerminkan perusahaan dunia nyata dan skenario spesifik domain. Mulai dari basis pengetahuan untuk keperluan umum hingga aplikasi vertikal seperti menjawab pertanyaan biomedis dan pencarian web berskala besar.

Korpus	Model Penyematan	Dimensi	Ukuran
Wikipedia	Cohere V2	768	1M / 10M
BioASQ	Cohere V3	1024	1M / 10M
C4	OpenAI	1536	500K / 5M
MSMarco V2	udever-bloom-1b1	1536	1M / 10M / 138M

Tabel: Dataset yang digunakan di VDBBench

VDBBench juga mendukung dataset khusus, sehingga Anda dapat melakukan pembandingan dengan data Anda sendiri yang dihasilkan dari model penyematan khusus untuk beban kerja spesifik Anda. Lagi pula, tidak ada set data yang menceritakan kisah yang lebih baik daripada data produksi Anda sendiri.

Desain Metrik yang Berfokus pada Produksi

VDBBench memprioritaskan metrik yang mencerminkan kinerja dunia nyata, bukan hanya hasil lab. Kami telah mendesain ulang pembandingan seputar hal yang benar-benar penting di lingkungan produksi: keandalan di bawah beban, latensi ekor, throughput berkelanjutan, dan akurasi.

• Latensi P95/P99 untuk mengukur pengalaman pengguna yang sesungguhnya: Latensi rata-rata/median menyembunyikan outlier yang membuat frustasi pengguna sesungguhnya. Itulah mengapa VDBBench berfokus pada latensi ekor seperti P95/P99, yang mengungkapkan kinerja apa yang sebenarnya akan dicapai oleh 95% atau 99% kueri Anda.

• Throughput yang berkelanjutan di bawah beban: Sistem yang berkinerja baik selama 5 detik tidak cukup untuk produksi. VDBBench secara bertahap meningkatkan konkurensi untuk menemukan kueri berkelanjutan maksimum basis data Anda per detik (max_qps) - bukan angka puncak dalam kondisi yang singkat dan ideal. Hal ini menunjukkan seberapa baik sistem Anda bertahan dari waktu ke waktu.

• Daya ingat seimbang dengan kinerja: Kecepatan tanpa akurasi tidak ada artinya. Setiap angka performa di VDBBench dipasangkan dengan recall, sehingga Anda tahu persis seberapa besar relevansi yang Anda tukar dengan throughput. Hal ini memungkinkan perbandingan yang adil dan setara antara sistem dengan pengorbanan internal yang sangat berbeda.

Metodologi Pengujian yang Mencerminkan Realitas

Inovasi utama dalam desain VDBBench adalah pemisahan pengujian serial dan pengujian bersamaan, yang membantu menangkap bagaimana sistem berperilaku di bawah berbagai jenis beban. Misalnya, metrik latensi dibagi sebagai berikut:

• serial_latency_p99 mengukur kinerja sistem di bawah beban minimal, di mana hanya satu permintaan yang diproses dalam satu waktu. Ini merupakan skenario kasus terbaik untuk latensi.

• conc_latency_p99 menangkap perilaku sistem di bawah kondisi konkurensi yang realistis dan tinggi, di mana banyak permintaan datang secara bersamaan.

Dua Fase Benchmark

VDBBench memisahkan pengujian menjadi dua fase penting:

1. Uji Serial

Ini adalah proses tunggal yang menjalankan 1.000 permintaan. Fase ini menetapkan garis dasar untuk kinerja dan akurasi yang ideal, melaporkan serial_latency_p99 dan recall.

2. Uji Konkurensi

Fase ini mensimulasikan lingkungan produksi di bawah beban yang berkelanjutan.

• Simulasi klien yang realistis: Setiap proses pengujian beroperasi secara independen dengan koneksi dan kumpulan kueri sendiri. Hal ini untuk menghindari gangguan shared-state (misalnya, cache) yang dapat mendistorsi hasil.

• Awal yang disinkronkan: Semua proses dimulai secara bersamaan, memastikan bahwa QPS yang diukur secara akurat mencerminkan tingkat konkurensi yang diklaim.

Metode yang terstruktur dengan cermat ini memastikan bahwa nilai max_qps dan conc_latency_p99 yang dilaporkan oleh VDBBench akurat dan relevan dengan produksi, sehingga memberikan wawasan yang berarti untuk perencanaan kapasitas produksi dan desain sistem.

Gambar: QPS dan Latensi Milvus-16c64g-standalone pada Tingkat Konkurensi yang Bervariasi (Uji Cohere 1M). Dalam pengujian ini, Milvus pada awalnya kurang dimanfaatkan - hingga tingkat konkurensi 20, peningkatan konkurensi meningkatkan pemanfaatan sistem dan menghasilkan QPS yang lebih tinggi. Di luar konkurensi 20, sistem mencapai beban penuh: peningkatan konkurensi lebih lanjut tidak lagi meningkatkan throughput, dan latensi meningkat karena penundaan antrian.

Lebih dari Sekadar Mencari Data Statis: Skenario Produksi Nyata

Sepengetahuan kami, VDBBench adalah satu-satunya alat benchmark yang menguji database vektor di seluruh spektrum lengkap skenario produksi yang penting, termasuk pengumpulan statis, pemfilteran, dan kasus streaming.

Pengumpulan Statis

Tidak seperti benchmark lain yang terburu-buru melakukan pengujian, VDBBench terlebih dahulu memastikan setiap database telah sepenuhnya mengoptimalkan indeksnya-persyaratan produksi penting yang sering diabaikan oleh banyak benchmark. Hal ini memberikan Anda gambaran yang lengkap:

• Waktu konsumsi data

• Waktu pengindeksan (waktu yang digunakan untuk membangun indeks yang dioptimalkan, yang secara dramatis memengaruhi kinerja pencarian)

• Performa pencarian pada indeks yang dioptimalkan sepenuhnya dalam kondisi serial dan bersamaan

Pemfilteran

Pencarian vektor dalam produksi jarang terjadi secara terpisah. Aplikasi nyata menggabungkan kemiripan vektor dengan pemfilteran metadata ("temukan sepatu yang terlihat seperti foto ini tetapi harganya di bawah $100"). Pencarian vektor yang difilter ini menciptakan tantangan yang unik:

• Kerumitan Filter: Lebih banyak kolom skalar dan kondisi logika meningkatkan tuntutan komputasi

• Selektivitas Filter: Pengalaman produksi kami mengungkapkan hal ini sebagai pembunuh kinerja tersembunyi - kecepatan query dapat berfluktuasi dengan urutan besarnya tergantung pada seberapa selektif filter

VDBBench secara sistematis mengevaluasi kinerja filter di berbagai tingkat selektivitas (dari 50% hingga 99,9%), memberikan profil komprehensif tentang bagaimana database menangani pola produksi yang kritis ini.

Gambar: QPS dan Recall dari Milvus dan OpenSearch di Berbagai Tingkat Selektivitas Filter yang Berbeda (Uji Cohere 1M). Sumbu X menunjukkan persentase data yang disaring. Seperti yang ditunjukkan, Milvus mempertahankan recall yang tinggi secara konsisten di semua tingkat selektivitas filter, sementara OpenSearch menunjukkan kinerja yang tidak stabil, dengan recall yang berfluktuasi secara signifikan di bawah kondisi pemfilteran yang berbeda.

Streaming

Sistem produksi jarang menikmati kemewahan data statis. Informasi baru terus mengalir saat pencarian dijalankan - sebuah skenario di mana banyak database yang mengesankan menjadi runtuh.

Kasus uji streaming unik dari VDBBench menguji kinerja pencarian-sambil-memasukkan, mengukur:

1. Dampak Pertumbuhan Volume Data: Bagaimana kinerja pencarian meningkat seiring dengan bertambahnya ukuran data.

2. Dampak Beban Tulis: Bagaimana penulisan secara bersamaan memengaruhi latensi dan throughput pencarian, karena penulisan juga menghabiskan sumber daya CPU atau memori dalam sistem.

Skenario streaming mewakili uji beban yang komprehensif untuk basis data vektor apa pun. Namun, membuat tolok ukur yang adil untuk hal ini tidaklah mudah. Tidaklah cukup hanya dengan mendeskripsikan perilaku satu sistem-kita membutuhkan model evaluasi yang konsisten yang memungkinkan perbandingan apple-to-apple di berbagai database.

Berdasarkan pengalaman kami dalam membantu perusahaan dalam penerapan di dunia nyata, kami membangun pendekatan yang terstruktur dan dapat diulang. Dengan VDBBench:

• Anda menentukan tingkat penyisipan tetap yang mencerminkan beban kerja produksi target Anda.

• VDBBench kemudian menerapkan tekanan beban yang sama di semua sistem, memastikan hasil kinerja dapat dibandingkan secara langsung.

Misalnya, dengan dataset Cohere 10M dan target pemasukan 500 baris/detik:

• VDBBench menjalankan 5 proses produsen paralel, masing-masing menyisipkan 100 baris per detik.

• Setelah setiap 10% data tertelan, VDBBench memicu putaran pengujian pencarian dalam kondisi serial dan bersamaan.

• Metrik seperti latensi, QPS, dan recall dicatat setelah setiap tahap.

Metodologi terkontrol ini mengungkapkan bagaimana kinerja setiap sistem berevolusi dari waktu ke waktu dan di bawah tekanan operasional yang nyata-memberi Anda wawasan yang Anda butuhkan untuk membuat keputusan infrastruktur yang berskala.

Gambar: QPS dan Recall Pinecone vs Elasticsearch dalam Uji Streaming Cohere 10M (Laju Konsumsi 500 baris/s). Pinecone mempertahankan QPS dan recall yang lebih tinggi, menunjukkan peningkatan QPS yang signifikan setelah memasukkan 100% data.

Namun ini bukanlah akhir dari cerita. VDBBench melangkah lebih jauh dengan mendukung langkah pengoptimalan opsional, yang memungkinkan pengguna untuk membandingkan kinerja pencarian streaming sebelum dan sesudah pengoptimalan indeks. VDBBench juga melacak dan melaporkan waktu aktual yang dihabiskan untuk setiap tahap, menawarkan wawasan yang lebih dalam tentang efisiensi dan perilaku sistem dalam kondisi seperti produksi.

Gambar: QPS dan Recall Pinecone vs Elasticsearch dalam Tes Streaming Cohere 10M Setelah Pengoptimalan (Laju Konsumsi 500 baris/s)

Seperti yang ditunjukkan pada diagram, ElasticSearch melampaui Pinecone dalam QPS-setelah pengoptimalan indeks. Sebuah keajaiban? Tidak juga. Diagram di sebelah kanan menceritakan kisah lengkapnya: setelah sumbu x mencerminkan waktu yang telah berlalu, jelas bahwa ElasticSearch membutuhkan waktu yang jauh lebih lama untuk mencapai kinerja tersebut. Dan dalam produksi, penundaan itu penting. Perbandingan ini mengungkapkan sebuah pertukaran utama: throughput puncak vs. waktu untuk melayani.

Pilih Basis Data Vektor Anda dengan Penuh Keyakinan

Kesenjangan antara hasil benchmark dan kinerja dunia nyata seharusnya tidak menjadi permainan tebak-tebakan. VDBBench menyediakan cara untuk mengevaluasi database vektor dalam kondisi yang realistis dan mirip dengan kondisi produksi, termasuk konsumsi data secara terus menerus, pemfilteran metadata, dan beban kerja streaming.

Jika Anda berencana menerapkan database vektor dalam produksi, ada baiknya Anda memahami bagaimana kinerjanya di luar pengujian laboratorium yang ideal. VDBBench bersifat open-source, transparan, dan dirancang untuk mendukung perbandingan yang bermakna, apples-to-apples.

Cobalah VDBBench dengan beban kerja Anda sendiri hari ini dan lihat bagaimana sistem yang berbeda dapat bertahan dalam praktiknya: https://github.com/zilliztech/VectorDBBench.

Ada pertanyaan atau ingin membagikan hasil pengujian Anda? Bergabunglah dengan percakapan di GitHub atau terhubung dengan komunitas kami di Discord. Kami ingin mendengar pendapat Anda.