Ukuran dan batas indeks vektor

Nota

Pencarian Azure AI tersedia melalui portal Azure, REST API, dan Azure SDK. Ini juga mendukung Foundry IQ, lapisan pengetahuan terkelola yang mengubah konten perusahaan menjadi pangkalan pengetahuan yang dapat digunakan kembali dan sadar izin untuk agen di portal Microsoft Foundry.

Untuk setiap bidang vektor, Pencarian Azure AI membuat indeks vektor internal menggunakan parameter algoritma yang ditentukan pada bidang . Karena Pencarian Azure AI memberlakukan kuota pada ukuran indeks vektor, Anda harus tahu cara memperkirakan dan memantau ukuran vektor untuk memastikan Anda tetap di bawah batas.

Secara internal, struktur data fisik indeks pencarian meliputi:

• Konten mentah (digunakan untuk pola pengambilan yang memerlukan konten yang tidak ditokenisasi)
• Indeks terbalik (digunakan untuk bidang teks yang dapat dicari)
• Indeks vektor (digunakan untuk bidang vektor yang dapat dicari)

Artikel ini menjelaskan batasan untuk indeks vektor internal yang mendukung setiap bidang vektor Anda.

Petunjuk / Saran

Teknik pengoptimalan vektor umumnya tersedia. Gunakan kemampuan seperti jenis data sempit, kuantisasi skalar dan biner, dan penghapusan penyimpanan redundan untuk mengurangi kuota vektor dan konsumsi kuota penyimpanan Anda.

Poin utama tentang ukuran kuota dan indeks vektor

• Ukuran indeks vektor diukur dalam byte.

• Total penyimpanan layanan Anda berisi semua file indeks vektor Anda. Pencarian Azure AI mempertahankan salinan file indeks vektor yang berbeda untuk tujuan yang berbeda. Kami menawarkan opsi lain untuk mengurangi overhead penyimpanan indeks vektor dengan menghilangkan beberapa salinan ini.

• Kuota vektor diberlakukan pada layanan pencarian secara keseluruhan, per partisi. Jika Anda menambahkan partisi, kuota vektor juga meningkat. Kuota vektor per partisi lebih tinggi pada layanan yang lebih baru. Untuk informasi selengkapnya, lihat Batas ukuran indeks vektor.

• Tidak semua algoritma mengonsumsi kuota ukuran indeks vektor. Kuota vektor dibuat berdasarkan persyaratan memori pencarian Perkiraan Tetangga Terdekat (ANN). Bidang vektor yang dibuat dengan algoritma Hierarkis Navigable Small World (HNSW) perlu berada di memori selama eksekusi kueri karena sifat akses acak dari traversal berbasis grafik. Bidang vektor yang menggunakan algoritma K-Nearest Neighbors (KNN) lengkap dimuat ke dalam memori secara dinamis di halaman selama eksekusi kueri dan dengan demikian tidak menggunakan kuota vektor.

Periksa ukuran dan kuantitas partisi

Jika Anda tidak yakin apa batas layanan pencarian Anda, berikut adalah dua cara untuk mendapatkan informasi tersebut:

• Di portal Microsoft Azure, pada halaman Gambaran Umum layanan pencarian, tab Properti dan tab Penggunaan memperlihatkan ukuran dan penyimpanan partisi, dan juga kuota vektor dan ukuran indeks vektor.

• Di portal Microsoft Azure, pada halaman Skala , Anda dapat meninjau jumlah dan ukuran partisi.

Batas vektor Anda bervariasi tergantung pada tanggal pembuatan layanan Anda.

Periksa ukuran indeks vektor

Permintaan metrik vektor adalah operasi sarana data. Anda dapat menggunakan portal Microsoft Azure, REST API, atau Azure SDK untuk mendapatkan penggunaan vektor di tingkat layanan melalui statistik layanan dan untuk indeks individual.

Portal

Ukuran vektor per indeks

Untuk mendapatkan ukuran indeks vektor per indeks, pilihIndeks> pencarian untuk melihat daftar indeks dan jumlah dokumen, ukuran indeks vektor dalam memori, dan ukuran indeks total seperti yang disimpan di disk.

Ingat bahwa kuota vektor didasarkan pada batasan memori. Untuk indeks vektor yang dibuat menggunakan algoritma HNSW, semua indeks vektor yang dapat dicari dimuat secara permanen ke dalam memori. Untuk indeks yang dibuat menggunakan algoritma KNN lengkap, indeks vektor dimuat dalam gugus, secara berurutan, selama waktu kueri. Tidak ada persyaratan residensi memori untuk indeks KNN yang lengkap. Masa pakai halaman yang dimuat dalam memori mirip dengan pencarian teks dan tidak ada metrik lain yang berlaku untuk indeks KNN lengkap selain total penyimpanan.

Cuplikan layar berikut menunjukkan dua versi indeks vektor yang sama. Satu versi dibuat menggunakan algoritma HNSW, di mana grafik vektor berbasis memori. Versi lain dibuat menggunakan algoritma KNN lengkap. Dengan KNN lengkap, tidak ada indeks vektor dalam memori khusus, sehingga portal menunjukkan 0 MB untuk ukuran indeks vektor. Vektor tersebut masih ada dan dihitung dalam ukuran penyimpanan keseluruhan, tetapi tidak menempati sumber daya dalam memori yang dilacak metrik ukuran indeks vektor.

Ukuran vektor per layanan

Untuk mendapatkan ukuran indeks vektor untuk layanan pencarian secara keseluruhan, pilih tab Penggunaan halaman Gambaran Umum. Halaman portal di-refresh setiap beberapa menit sehingga jika Anda baru saja memperbarui indeks, tunggu sebentar sebelum memeriksa hasil.

Cuplikan layar berikut adalah untuk layanan pencarian Standar 1 (S1) yang lebih lama, dikonfigurasi untuk satu partisi dan satu replika.

• Kuota penyimpanan adalah batasan disk, dan termasuk semua indeks (vektor dan nonvektor) pada layanan pencarian.

• Kuota ukuran indeks vektor adalah batasan memori. Ini adalah jumlah memori yang diperlukan untuk memuat semua indeks vektor internal yang dibuat untuk setiap bidang vektor pada layanan pencarian.

Cuplikan layar menunjukkan bahwa indeks (vektor dan nonvektor) mengonsumsi hampir 460 megabyte penyimpanan disk yang tersedia. Indeks vektor mengonsumsi hampir 93 megabyte memori di tingkat layanan.

Kuota untuk penyimpanan dan ukuran indeks vektor meningkat atau berkurang saat Anda menambahkan atau menghapus partisi. Jika Anda mengubah jumlah partisi, kotak menunjukkan perubahan yang sesuai pada penyimpanan dan kuota vektor.

Nota

Di dalam disk, indeks vektor tidak berukuran 93 megabyte. Indeks vektor pada disk memakan waktu sekitar tiga kali lebih banyak ruang daripada indeks vektor dalam memori. Lihat Bagaimana bidang vektor memengaruhi penyimpanan disk untuk detailnya.

ISTIRAHAT

API REST data plane (semua API yang lebih baru menyediakan statistik penggunaan vektor):

• GET Statistik Layanan mengembalikan kuota dan penggunaan untuk layanan pencarian secara keseluruhan.
• Statistik Indeks GET mengembalikan penggunaan untuk indeks tertentu.

Penggunaan dan kuota dilaporkan dalam byte.

Berikut adalah Statistik Layanan GET:

GET {{baseUrl}}/servicestats?api-version=2026-04-01  HTTP/1.1
Content-Type: application/json
api-key: {{apiKey}}

Respons mencakup metrik untuk storageSize, yang tidak membedakan antara indeks vektor dan nonvektor. vectorIndexSize Statistik menunjukkan penggunaan dan kuota di tingkat layanan.

{
    "@odata.context": "https://my-demo.search.windows.net/$metadata#Microsoft.Azure.Search.V2023_11_01.ServiceStatistics",
    "counters": {
        "documentCount": {
            "usage": 15377,
            "quota": null
        },
        "indexesCount": {
            "usage": 13,
            "quota": 15
        },
        "knowledgeBasesCount": {
            "usage": 2,
            "quota": 10
        },
        "knowledgeSourcesCount": {
            "usage": 5,
            "quota": 30
        },
        . . .
        "storageSize": {
            "usage": 39862913,
            "quota": 2147483648
        },
        . . .
        "vectorIndexSize": {
            "usage": 2685436,
            "quota": 1073741824
        }
    },
    "limits": {
        "maxFieldsPerIndex": 1000,
        "maxFieldNestingDepthPerIndex": 10,
        "maxComplexCollectionFieldsPerIndex": 40,
        "maxComplexObjectsInCollectionsPerDocument": 3000
    }
}

Anda juga dapat mengirim permintaan GET Index Statistics untuk mendapatkan ukuran fisik indeks pada disk, serta ukuran bidang vektor dalam memori.

GET {{baseUrl}}/indexes/vector-healthplan-idx/stats?api-version=2026-04-01  HTTP/1.1
Content-Type: application/json
api-key: {{apiKey}}

Respons mencakup informasi penggunaan di tingkat indeks. Contoh ini didasarkan pada indeks yang dibuat di Mulai Cepat: Pencarian vektor yang memotong dan mem-vektorisasi PDF rencana kesehatan. Setiap bagian berkontribusi pada documentCount.

{
    "@odata.context": "https://my-demo.search.windows.net/$metadata#Microsoft.Azure.Search.V2023_11_01.IndexStatistics",
    "documentCount": 147,
    "storageSize": 4592870,
    "vectorIndexSize": 915484
}

Faktor-faktor yang memengaruhi ukuran indeks vektor

Ada tiga komponen utama yang memengaruhi ukuran indeks vektor internal Anda:

• Ukuran data mentah
• Overhead dari algoritma yang dipilih
• Overhead dari menghapus atau memperbarui dokumen dalam indeks

Ukuran data mentah

Setiap vektor biasanya berupa array angka titik mengambang presisi tunggal, dalam bidang tipe Collection(Edm.Single).

Struktur data vektor memerlukan penyimpanan, yang diwakili dalam perhitungan berikut sebagai "ukuran mentah" data Anda. Gunakan ukuran mentah ini untuk memperkirakan persyaratan ukuran indeks vektor bidang vektor Anda.

Dimensi satu vektor menentukan ukuran penyimpanannya. Kalikan ukuran satu vektor dengan jumlah dokumen yang berisi bidang vektor tersebut untuk mendapatkan ukuran mentah:

raw size = (number of documents) * (dimensions of vector field) * (size of data type)

Jenis data EDM	Ukuran tipe data
Collection(Edm.Single)	4 byte
Collection(Edm.Half)	2 byte
Collection(Edm.Int16)	2 byte
Collection(Edm.SByte)	1 byte

Overhead memori dari algoritma yang dipilih

Setiap algoritma ANN menghasilkan struktur data tambahan dalam memori untuk memungkinkan pencarian yang efisien. Struktur ini mengonsumsi ruang ekstra dalam memori.

Untuk algoritma HNSW, overhead memori berkisar antara 1% dan 20% untuk vektor float32 (Edm.Single) yang tidak dikompresi.

Saat dimensi meningkat, persentase overhead memori berkurang. Ini terjadi karena ukuran mentah vektor meningkat ukurannya sementara struktur data lainnya, yang menyimpan informasi konektivitas grafik, tetap berukuran tetap untuk yang diberikan m. Akibatnya, dampak relatif dari struktur data tambahan ini berkurang sehubungan dengan ukuran vektor keseluruhan.

Overhead memori meningkat dengan nilai yang lebih besar dari parameter HNSW m, yang menentukan jumlah tautan dua arah yang dibuat untuk setiap vektor baru selama konstruksi indeks. Ini terjadi karena setiap tautan berkontribusi sekitar 8 hingga 10 byte per dokumen, dan total overhead meningkat secara proporsional dengan m.

Tabel berikut ini meringkas persentase overhead yang diamati dalam pengujian internal untuk bidang vektor yang tidak dikompresi :

Dimensi	Parameter HNSW (m)	Persentase overhead
96	4	20%
200	4	8%
768	4	2%
1536	4	1%
3072	4	0,5%

Hasil ini menunjukkan hubungan antara dimensi, parameter mHNSW, dan overhead memori untuk algoritma HNSW.

Untuk bidang vektor yang menggunakan teknik kompresi, seperti skalar atau kuantisasi biner, persentase overhead tampaknya menggunakan persentase yang lebih besar dari ukuran indeks vektor total. Ketika ukuran data menurun, dampak relatif dari struktur data ukuran tetap yang digunakan untuk menyimpan informasi konektivitas grafik menjadi lebih signifikan.

Overhead dari menghapus atau memperbarui dokumen dalam indeks

Saat dokumen dengan bidang vektor dihapus atau diperbarui (pembaruan diwakili secara internal sebagai operasi hapus dan sisipkan), dokumen yang mendasarinya ditandai sebagai dihapus dan dilewati selama kueri berikutnya. Saat dokumen baru diindeks dan indeks vektor internal tumbuh, sistem membersihkan dokumen yang dihapus ini dan mengklaim kembali sumber daya. Ini berarti Anda kemungkinan akan mengamati jeda antara menghapus dokumen dan dibebaskannya sumber daya yang mendasar.

Kami menyebutnya sebagai rasio dokumen yang dihapus. Karena rasio dokumen yang dihapus tergantung pada karakteristik pengindeksan layanan Anda, tidak ada heuristik universal untuk memperkirakan parameter ini, dan tidak ada API atau skrip yang mengembalikan rasio yang berlaku untuk layanan Anda. Kami mengamati bahwa setengah dari pelanggan kami memiliki rasio dokumen yang dihapus kurang dari 10%. Jika Anda cenderung melakukan penghapusan atau pembaruan frekuensi tinggi, maka Anda mungkin mengamati rasio dokumen yang dihapus lebih tinggi.

Ini adalah faktor lain yang memengaruhi ukuran indeks vektor Anda. Sayangnya, kami tidak memiliki mekanisme untuk memunculkan rasio dokumen Anda yang dihapus saat ini.

Memperkirakan ukuran total data dalam memori

Mempertimbangkan faktor-faktor yang dijelaskan sebelumnya, untuk memperkirakan ukuran total indeks vektor Anda, gunakan perhitungan berikut:

(raw_size) * (1 + algorithm_overhead (in percent)) * (1 + deleted_docs_ratio (in percent))

Misalnya, untuk menghitung raw_size, mari kita asumsikan Anda menggunakan model Azure OpenAI populer, text-embedding-ada-002 dengan 1.536 dimensi. Ini berarti satu dokumen akan mengonsumsi 1.536 Edm.Single (float), atau 6.144 byte karena masing-masing Edm.Single adalah 4 byte. 1.000 dokumen dengan satu bidang vektor 1.536 dimensi akan mengonsumsi total 1000 dokumen x 1536 float/dokumen = 1.536.000 float, atau 6.144.000 byte.

Jika Anda memiliki beberapa bidang vektor, Anda perlu melakukan perhitungan ini untuk setiap bidang vektor dalam indeks Anda dan menambahkan semuanya bersama-sama. Misalnya, 1.000 dokumen dengan dua bidang vektor 1.536 dimensi, mengonsumsi 1000 dokumen x 2 bidang x 1536 float/doc x 4 byte/float = 12.288.000 byte.

Untuk mendapatkan ukuran indeks vektor, kalikan raw_size ini dengan overhead algoritma dan rasio dokumen yang dihapus. Jika overhead algoritma Anda untuk parameter HNSW yang Anda pilih adalah 10% dan rasio dokumen anda yang dihapus adalah 10%, maka kita mendapatkan: 6.144 MB * (1 + 0.10) * (1 + 0.10) = 7.434 MB.

Bagaimana bidang vektor memengaruhi penyimpanan disk

Sebagian besar artikel ini menyediakan informasi tentang ukuran vektor dalam memori. Untuk informasi tentang biaya penyimpanan dari indeks vektor, simak Hapus instans vektor opsional dari penyimpanan.

Konten terkait

• Pencarian vektor di Pencarian Azure AI
• Pilih pendekatan untuk mengoptimalkan penyimpanan dan pemrosesan vektor
• Menangani ketidaksesuaian penyimpanan dan metrik