Penyimpanan vektor di Azure AI Search

Artikel
02/16/2024

Azure AI Search menyediakan penyimpanan dan konfigurasi vektor untuk pencarian vektor dan pencarian hibrid. Dukungan diimplementasikan di tingkat bidang, yang berarti Anda dapat menggabungkan bidang vektor dan nonvektor di korpus pencarian yang sama.

Vektor disimpan dalam indeks pencarian. Gunakan Buat Indeks REST API atau metode Azure SDK yang setara untuk membuat penyimpanan vektor.

Pertimbangan untuk penyimpanan vektor mencakup poin-poin berikut:

Desain skema agar sesuai dengan kasus penggunaan Anda berdasarkan pola pengambilan vektor yang dimaksudkan.
Perkirakan ukuran indeks dan periksa kapasitas layanan pencarian.
Mengelola penyimpanan vektor
Mengamankan penyimpanan vektor

Pola pengambilan vektor

Di Azure AI Search, ada dua pola untuk bekerja dengan hasil pencarian.

Pencarian generatif. Model bahasa merumuskan respons terhadap kueri pengguna menggunakan data dari Azure AI Search. Pola ini mencakup lapisan orkestrasi untuk mengoordinasikan permintaan dan mempertahankan konteks. Dalam pola ini, hasil pencarian dimasukkan ke dalam alur permintaan, diterima oleh model obrolan seperti GPT dan Text-Davinci. Pendekatan ini didasarkan pada arsitektur Retrieval augmented generation (RAG), di mana indeks pencarian menyediakan data grounding.
Pencarian klasik menggunakan bilah pencarian, string input kueri, dan hasil yang dirender. Mesin pencari menerima dan menjalankan kueri vektor, merumuskan respons, dan Anda merender hasil tersebut di aplikasi klien. Di Azure AI Search, hasil dikembalikan dalam kumpulan baris yang diratakan, dan Anda dapat memilih bidang mana yang akan menyertakan hasil pencarian. Karena tidak ada model obrolan, diharapkan Anda akan mengisi penyimpanan vektor (indeks pencarian) dengan konten nonvektor yang dapat dibaca manusia dalam respons Anda. Meskipun mesin pencari cocok pada vektor, Anda harus menggunakan nilai nonvektor untuk mengisi hasil pencarian. Kueri vektor dan kueri hibrid mencakup jenis permintaan kueri yang dapat Anda rumuskan untuk skenario pencarian klasik.

Skema indeks Anda harus mencerminkan kasus penggunaan utama Anda. Bagian berikut menyoroti perbedaan komposisi bidang untuk solusi yang dibangun untuk AI generatif atau pencarian klasik.

Skema penyimpanan vektor

Skema indeks untuk penyimpanan vektor memerlukan nama, bidang kunci (string), satu atau beberapa bidang vektor, dan konfigurasi vektor. Bidang nonvektor direkomendasikan untuk kueri hibrid, atau untuk mengembalikan konten verbatim yang dapat dibaca manusia yang tidak harus melalui model bahasa. Untuk petunjuk tentang konfigurasi vektor, lihat Membuat penyimpanan vektor.

Konfigurasi bidang vektor dasar

Bidang vektor dibedakan oleh jenis data dan properti khusus vektornya. Berikut tampilan bidang vektor dalam kumpulan bidang:

{
    "name": "content_vector",
    "type": "Collection(Edm.Single)",
    "searchable": true,
    "retrievable": true,
    "dimensions": 1536,
    "vectorSearchProfile": "my-vector-profile"
}

Bidang vektor berjenis Collection(Edm.Single).

Bidang vektor harus dapat dicari dan diambil, tetapi tidak dapat difilter, dapat difaset, atau dapat diurutkan, atau memiliki penganalisis, normalizer, atau penetapan peta sinonim.

Bidang vektor harus diatur dimensions ke jumlah penyematan yang dihasilkan oleh model penyematan. Misalnya, text-embedding-ada-002 menghasilkan 1.536 penyematan untuk setiap potongan teks.

Bidang vektor diindeks menggunakan algoritma yang ditunjukkan oleh profil pencarian vektor, yang didefinisikan di tempat lain dalam indeks dan dengan demikian tidak ditampilkan dalam contoh. Untuk informasi selengkapnya, lihat konfigurasi pencarian vektor.

Kumpulan bidang untuk beban kerja vektor dasar

Penyimpanan vektor memerlukan lebih banyak bidang selain bidang vektor. Misalnya, bidang kunci ("id" dalam contoh ini) adalah persyaratan indeks.

"name": "example-basic-vector-idx",
"fields": [
  { "name": "id", "type": "Edm.String", "searchable": false, "filterable": true, "retrievable": true, "key": true },
  { "name": "content_vector", "type": "Collection(Edm.Single)", "searchable": true, "retrievable": true, "dimensions": 1536, "vectorSearchProfile": null },
  { "name": "content", "type": "Edm.String", "searchable": true, "retrievable": true, "analyzer": null },
  { "name": "metadata", "type": "Edm.String", "searchable": true, "filterable": true, "retrievable": true, "sortable": true, "facetable": true }
]

Bidang lain, seperti "content" bidang , menyediakan setara dengan "content_vector" bidang yang dapat dibaca manusia. Jika Anda menggunakan model bahasa secara eksklusif untuk rumusan respons, Anda dapat menghilangkan bidang konten nonvektor, tetapi solusi yang mendorong hasil pencarian langsung ke aplikasi klien harus memiliki konten nonvektor.

Bidang metadata berguna untuk filter, terutama jika metadata menyertakan informasi asal tentang dokumen sumber. Anda tidak dapat memfilter bidang vektor secara langsung, tetapi Anda dapat mengatur mode prafilter atau pascafilter untuk memfilter sebelum atau sesudah eksekusi kueri vektor.

Skema yang dihasilkan oleh wizard Impor dan vektorisasi data

Kami merekomendasikan wizard Impor dan vektorisasi data untuk evaluasi dan pengujian bukti konsep. Wizard menghasilkan contoh skema di bagian ini.

Bias dari skema ini adalah bahwa dokumen pencarian dibangun di sekitar potongan data. Jika model bahasa merumuskan respons, seperti biasa untuk aplikasi RAG, Anda menginginkan skema yang dirancang di sekitar potongan data.

Pemotongan data diperlukan untuk tetap berada dalam batas input model bahasa, tetapi juga meningkatkan presisi dalam pencarian kesamaan ketika kueri dapat dicocokkan dengan potongan konten yang lebih kecil yang ditarik dari beberapa dokumen induk. Terakhir, jika Anda menggunakan peringkat semantik, ranker semantik juga memiliki batas token, yang lebih mudah dipenuhi jika pemotongan data adalah bagian dari pendekatan Anda.

Dalam contoh berikut, untuk setiap dokumen pencarian, ada satu ID gugus, gugus, judul, dan bidang vektor. CHUNKID dan ID induk diisi oleh wizard, menggunakan pengodean dasar 64 metadata blob (jalur). Potongan dan judul berasal dari konten blob dan nama blob. Hanya bidang vektor yang sepenuhnya dihasilkan. Ini adalah versi vektor dari bidang gugus. Penyematan dihasilkan dengan memanggil model penyematan Azure OpenAI yang Anda sediakan.

"name": "example-index-from-import-wizard",
"fields": [
  {"name": "chunk_id",  "type": "Edm.String", "key": true, "searchable": true, "filterable": true, "retrievable": true, "sortable": true, "facetable": true, "analyzer": "keyword"},
  { "name": "parent_id", "type": "Edm.String", "searchable": true, "filterable": true, "retrievable": true, "sortable": true},
  { "name": "chunk", "type": "Edm.String", "searchable": true, "filterable": false, "retrievable": true, "sortable": false},
  { "name": "title", "type": "Edm.String", "searchable": true, "filterable": true, "retrievable": true, "sortable": false},
  { "name": "vector", "type": "Collection(Edm.Single)", "searchable": true, "retrievable": true, "dimensions": 1536, "vectorSearchProfile": "vector-1707768500058-profile"}
]

Skema untuk APLIKASI RAG dan gaya obrolan

Jika Anda merancang penyimpanan untuk pencarian generatif, Anda dapat membuat indeks terpisah untuk konten statis yang Anda indeks dan vektorisasi, dan indeks kedua untuk percakapan yang dapat digunakan dalam alur perintah. Indeks berikut dibuat dari akselerator chat-with-your-data-solution-accelerator.

Bidang dari indeks obrolan yang mendukung pengalaman pencarian generatif:

"name": "example-index-from-accelerator",
"fields": [
  { "name": "id", "type": "Edm.String", "searchable": false, "filterable": true, "retrievable": true },
  { "name": "content", "type": "Edm.String", "searchable": true, "filterable": false, "retrievable": true },
  { "name": "content_vector", "type": "Collection(Edm.Single)", "searchable": true, "retrievable": true, "dimensions": 1536, "vectorSearchProfile": "my-vector-profile"},
  { "name": "metadata", "type": "Edm.String", "searchable": true, "filterable": false, "retrievable": true },
  { "name": "title", "type": "Edm.String", "searchable": true, "filterable": true, "retrievable": true, "facetable": true },
  { "name": "source", "type": "Edm.String", "searchable": true, "filterable": true, "retrievable": true  },
  { "name": "chunk", "type": "Edm.Int32", "searchable": false, "filterable": true, "retrievable": true },
  { "name": "offset", "type": "Edm.Int32", "searchable": false, "filterable": true, "retrievable": true }
]

Bidang dari indeks percakapan yang mendukung orkestrasi dan riwayat obrolan:

"fields": [
    { "name": "id", "type": "Edm.String", "key": true, "searchable": false, "filterable": true, "retrievable": true, "sortable": false, "facetable": false },
    { "name": "conversation_id", "type": "Edm.String", "searchable": false, "filterable": true, "retrievable": true, "sortable": false, "facetable": true },
    { "name": "content", "type": "Edm.String", "searchable": true, "filterable": false, "retrievable": true },
    { "name": "content_vector", "type": "Collection(Edm.Single)", "searchable": true, "retrievable": true, "dimensions": 1536, "vectorSearchProfile": "default-profile" },
    { "name": "metadata", "type": "Edm.String", "searchable": true, "filterable": false, "retrievable": true },
    { "name": "type", "type": "Edm.String", "searchable": false, "filterable": true, "retrievable": true, "sortable": false, "facetable": true },
    { "name": "user_id", "type": "Edm.String", "searchable": false, "filterable": true, "retrievable": true, "sortable": false, "facetable": true },
    { "name": "sources", "type": "Collection(Edm.String)", "searchable": false, "filterable": true, "retrievable": true, "sortable": false, "facetable": true },
    { "name": "created_at", "type": "Edm.DateTimeOffset", "searchable": false, "filterable": true, "retrievable": true },
    { "name": "updated_at", "type": "Edm.DateTimeOffset", "searchable": false, "filterable": true, "retrievable": true }
]

Berikut adalah cuplikan layar yang memperlihatkan hasil pencarian di Search Explorer untuk indeks percakapan. Skor pencarian adalah 1,00 karena pencarian tidak memenuhi syarat. Perhatikan bidang yang ada untuk mendukung orkestrasi dan alur perintah. ID percakapan mengidentifikasi obrolan tertentu. "type" menunjukkan apakah konten berasal dari pengguna atau asisten. Tanggal digunakan untuk menua obrolan dari riwayat.

Struktur dan ukuran fisik

Dalam Azure AI Search, struktur fisik indeks sebagian besar merupakan implementasi internal. Anda dapat mengakses skemanya, memuat dan mengkueri kontennya, memantau ukurannya, dan mengelola kapasitas, tetapi kluster itu sendiri (indeks terbalik dan vektor), dan file dan folder lainnya) dikelola secara internal oleh Microsoft.

Ukuran dan substansi indeks ditentukan oleh:

Kuantitas dan komposisi dokumen Anda
Atribut pada bidang individual. Misalnya, lebih banyak penyimpanan diperlukan untuk bidang yang dapat difilter.
Konfigurasi indeks, termasuk konfigurasi vektor yang menentukan bagaimana struktur navigasi internal dibuat berdasarkan apakah Anda memilih HNSW atau KNN lengkap untuk pencarian kesamaan.

Azure AI Search memberlakukan batasan pada penyimpanan vektor, yang membantu mempertahankan sistem yang seimbang dan stabil untuk semua beban kerja. Untuk membantu Anda tetap di bawah batas, penggunaan vektor dilacak dan dilaporkan secara terpisah dalam portal Azure, dan secara terprogram melalui statistik layanan dan indeks.

Cuplikan layar berikut menunjukkan layanan S1 yang dikonfigurasi dengan satu partisi dan satu replika. Layanan khusus ini memiliki 24 indeks kecil, dengan rata-rata satu bidang vektor, setiap bidang yang terdiri dari 1536 penyematan. Petak peta kedua menunjukkan kuota dan penggunaan untuk indeks vektor. Indeks vektor adalah struktur data internal yang dibuat untuk setiap bidang vektor. Dengan demikian, penyimpanan untuk indeks vektor selalu merupakan sebagian kecil dari penyimpanan yang digunakan oleh indeks secara keseluruhan. Bidang nonvektor dan struktur data lainnya mengonsumsi sisanya.

Batas dan estimasi indeks vektor dibahas dalam artikel lain, tetapi dua poin untuk ditekankan di muka adalah bahwa penyimpanan maksimum bervariasi menurut tingkat layanan, dan juga pada saat layanan pencarian dibuat. Layanan tingkat yang sama yang lebih baru memiliki kapasitas yang jauh lebih banyak untuk indeks vektor. Untuk alasan ini, lakukan tindakan berikut:

Periksa tanggal penyebaran layanan pencarian Anda. Jika dibuat sebelum 3 April 2024, pertimbangkan untuk membuat layanan pencarian baru untuk kapasitas yang lebih besar.
Pilih tingkat yang dapat diskalakan jika Anda mengantisipasi fluktuasi dalam persyaratan penyimpanan vektor. Tingkat Dasar diperbaiki pada satu partisi pada layanan pencarian yang lebih lama. Pertimbangkan Standar 1 (S1) ke atas untuk fleksibilitas dan performa yang lebih cepat, atau buat layanan pencarian baru yang menggunakan batas yang lebih tinggi dan lebih banyak partisi di setiap tingkat nillable.

Operasi dasar dan interaksi

Bagian ini memperkenalkan operasi run time vektor, termasuk menyambungkan dan mengamankan satu indeks.

Catatan

Saat mengelola indeks, patikan bahwa tidak ada dukungan portal atau API untuk memindahkan atau menyalin indeks. Sebaliknya, pelanggan biasanya mengarahkan solusi penyebaran aplikasi mereka pada layanan pencarian yang berbeda (jika menggunakan nama indeks yang sama), atau merevisi nama untuk membuat salinan pada layanan pencarian saat ini, dan kemudian membuatnya.

Terus tersedia

Indeks segera tersedia untuk kueri segera setelah dokumen pertama diindeks, tetapi tidak akan sepenuhnya beroperasi sampai semua dokumen diindeks. Secara internal, indeks didistribusikan di seluruh partisi dan dijalankan pada replika. Indeks fisik dikelola secara internal. Indeks logis dikelola oleh Anda.

Indeks terus tersedia, tanpa kemampuan untuk menjeda atau membuatnya offline. Karena dirancang untuk operasi berkelanjutan, setiap pembaruan pada kontennya, atau penambahan indeks itu sendiri, terjadi secara real time. Akibatnya, kueri mungkin menampilkan hasil yang tidak lengkap untuk sementara waktu jika permintaan bertepatan dengan pembaruan dokumen.

Perhatikan bahwa kelangsungan kueri ada untuk operasi dokumen (menyegarkan atau menghapus) dan untuk modifikasi yang tidak memengaruhi struktur dan integritas indeks saat ini (seperti menambahkan bidang baru). Jika Anda perlu membuat pembaruan struktural (mengubah bidang yang ada), biasanya dikelola menggunakan alur kerja drop-and-rebuild dalam lingkungan pengembangan, atau dengan membuat versi baru indeks pada layanan produksi.

Untuk menghindari pembangunan ulang indeks, beberapa pelanggan yang membuat perubahan kecil memilih untuk "versi" bidang dengan membuat bidang baru yang hidup berdampingan dengan versi sebelumnya. Seiring waktu, ini mengarah pada konten tanpa induk dalam bentuk bidang usang atau definisi penganalisis kustom usang, terutama dalam indeks produksi yang mahal untuk ditiru. Anda dapat mengatasi masalah ini pada pembaruan yang direncanakan untuk indeks sebagai bagian dari pengelolaan siklus hidup indeks.

Koneksi titik akhir

Semua permintaan pengindeksan dan kueri vektor menargetkan indeks. Titik akhir biasanya merupakan salah satu dari berikut ini:

Titik akhir	Kontrol koneksi dan akses
`<your-service>.search.windows.net/indexes`	Menargetkan kumpulan indeks. Digunakan saat membuat, mencantumkan, atau menghapus indeks. Hak admin diperlukan untuk operasi ini, tersedia melalui kunci API admin atau peran Kontributor Pencarian.
`<your-service>.search.windows.net/indexes/<your-index>/docs`	Menargetkan kumpulan dokumen dari satu indeks. Digunakan saat mengkueri indeks atau refresh data. Untuk kueri, hak baca sudah cukup, dan tersedia melalui kunci API kueri atau peran pembaca data. Untuk refresh data, hak admin diperlukan.

Cara menyambungkan ke Azure AI Search

Pastikan Anda memiliki izin atau kunci akses API. Kecuali Anda mengkueri indeks yang sudah ada, Anda memerlukan hak admin atau penetapan peran kontributor untuk mengelola dan menampilkan konten di layanan pencarian.
Mulailah dengan portal Azure. Orang yang membuat layanan pencarian dapat melihat dan mengelola layanan pencarian, termasuk memberikan akses ke orang lain melalui halaman Kontrol akses (IAM).
Lanjutkan ke klien lain untuk akses terprogram. Kami merekomendasikan mulai cepat dan sampel untuk langkah pertama:
- Mulai cepat: REST
- Sampel vektor

Akses aman ke data vektor

Azure AI Search mengimplementasikan enkripsi data, koneksi privat untuk skenario tanpa internet, dan penetapan peran untuk akses aman melalui ID Microsoft Entra. Berbagai fitur keamanan perusahaan diuraikan dalam Keamanan di Azure AI Search.

Mengelola penyimpanan vektor

Azure menyediakan platform pemantauan yang menyertakan pengelogan dan pemberitahuan diagnostik. Kami merekomendasikan praktik terbaik berikut:

Bagikan melalui