Indeks pencarian di Azure AI Search
Di Azure AI Search, indeks pencarian adalah konten yang dapat dicari, tersedia untuk mesin pencari untuk pengindeksan, pencarian teks lengkap, pencarian vektor, pencarian hibrid, dan kueri yang difilter. Indeks didefinisikan oleh skema dan disimpan ke layanan pencarian, dengan impor data berikut sebagai langkah kedua. Konten ini ada dalam layanan pencarian Anda, selain dari penyimpanan data utama Anda, yang diperlukan untuk waktu respons milidetik yang diharapkan dalam aplikasi pencarian modern. Kecuali untuk skenario pengindeksan berbasis pengindeksan, layanan pencarian tidak pernah tersambung atau mengkueri data sumber Anda.
Jika Anda ingin membuat dan mengelola indeks pencarian, artikel ini membantu Anda memahami poin-poin berikut:
- Konten (dokumen dan skema)
- Struktur data fisik
- Operasi dasar
Lebih suka langsung? Lihat Membuat indeks pencarian sebagai gantinya.
Skema indeks pencarian
Di Pencarian Azure AI, indeks berisi dokumen pencarian. Secara konseptual, dokumen adalah satu unit data yang dapat dicari dalam indeks Anda. Misalnya, pengecer mungkin memiliki dokumen untuk setiap produk, perusahaan berita mungkin memiliki dokumen untuk setiap artikel, situs perjalanan mungkin memiliki dokumen untuk hotel dan tujuan, dan sebagainya. Memetakan konsep-konsep ini ke persamaan database yang lebih familiar: indeks pencarian sama dengan tabel, dan dokumen kira-kira setara dengan baris dalam tabel.
Struktur dokumen ditentukan oleh skema indeks, seperti yang diilustrasikan dalam contoh berikut. Koleksi "bidang" biasanya merupakan bagian terbesar dari indeks, di mana setiap bidang diberi nama, diberi jenis data, dan dikaitkan dengan perilaku yang diizinkan yang menentukan cara penggunaannya.
{
"name": "name_of_index, unique across the service",
"fields": [
{
"name": "name_of_field",
"type": "Edm.String | Collection(Edm.String) | Collection(Edm.Single) | Edm.Int32 | Edm.Int64 | Edm.Double | Edm.Boolean | Edm.DateTimeOffset | Edm.GeographyPoint",
"searchable": true (default where applicable) | false (only Edm.String and Collection(Edm.String) fields can be searchable),
"filterable": true (default) | false,
"sortable": true (default where applicable) | false (Collection(Edm.String) fields cannot be sortable),
"facetable": true (default where applicable) | false (Edm.GeographyPoint fields cannot be facetable),
"key": true | false (default, only Edm.String fields can be keys),
"retrievable": true (default) | false,
"analyzer": "name_of_analyzer_for_search_and_indexing", (only if 'searchAnalyzer' and 'indexAnalyzer' are not set)
"searchAnalyzer": "name_of_search_analyzer", (only if 'indexAnalyzer' is set and 'analyzer' is not set)
"indexAnalyzer": "name_of_indexing_analyzer", (only if 'searchAnalyzer' is set and 'analyzer' is not set)
"normalizer": "name_of_normalizer", (applies to fields that are filterable)
"synonymMaps": "name_of_synonym_map", (optional, only one synonym map per field is currently supported)
"dimensions": "number of dimensions used by an emedding models", (applies to vector fields only, of type Collection(Edm.Single))
"vectorSearchProfile": "name_of_vector_profile" (indexes can have many configurations, a field can use just one)
}
],
"suggesters": [ ],
"scoringProfiles": [ ],
"analyzers":(optional)[ ... ],
"charFilters":(optional)[ ... ],
"tokenizers":(optional)[ ... ],
"tokenFilters":(optional)[ ... ],
"defaultScoringProfile": (optional) "...",
"corsOptions": (optional) { },
"encryptionKey":(optional){ },
"semantic":(optional){ },
"vectorSearch":(optional){ }
}
Elemen lain diciutkan untuk brevity, tetapi tautan berikut memberikan detail:
- pemberi saran mendukung kueri type-ahead seperti pelengkapan otomatis.
- scoringProfiles digunakan untuk penyetelan relevansi.
- penganalisis digunakan untuk memproses string menjadi token sesuai dengan aturan linguistik atau karakteristik lain yang didukung oleh penganalisis.
- corsOptions, atau Scripting jarak jauh lintas asal (CORS), digunakan untuk aplikasi yang mengeluarkan permintaan dari domain yang berbeda.
- encryptionKey mengonfigurasi enkripsi ganda konten sensitif dalam indeks.
- semantik mengonfigurasi reranking semantik dalam teks lengkap dan pencarian hibrid.
- vectorSearch mengonfigurasi bidang dan kueri vektor.
Definisi bidang
Dokumen pencarian ditentukan oleh koleksi "bidang" dalam isi permintaan Buat Indeks. Anda memerlukan bidang untuk identifikasi dokumen (kunci), menyimpan teks yang dapat dicari, dan bidang untuk mendukung filter, faset, dan pengurutan. Anda mungkin juga memerlukan bidang untuk data yang tidak pernah dilihat pengguna. Misalnya, Anda mungkin ingin bidang untuk margin keuntungan atau promosi pemasaran yang dapat Anda gunakan dalam profil penilaian untuk meningkatkan skor pencarian.
Jika data masuk bersifat hierarkis, Anda dapat mewakilinya dalam indeks sebagai jenis kompleks, yang digunakan untuk struktur berlapis. Himpunan data sampel bawaan, Hotel, mengilustrasikan jenis kompleks menggunakan Alamat (berisi beberapa subbidang) yang memiliki hubungan satu-ke-satu dengan setiap hotel, dan koleksi kompleks Rooms, di mana beberapa kamar dikaitkan dengan setiap hotel.
Atribut bidang
Atribut bidang menentukan bagaimana bidang digunakan, seperti apakah bidang digunakan dalam pencarian teks lengkap, navigasi tersaring, operasi pengurutan, dan sebagainya.
Bidang string sering ditandai sebagai "dapat dicari" dan "dapat diambil". Bidang yang digunakan untuk mempersempit hasil pencarian termasuk "dapat diurutkan", "dapat difilter", dan "dapat difaset".
| Atribut | Deskripsi |
|---|---|
| "dapat dicari" | Teks lengkap atau vektor dapat dicari. Bidang teks tunduk pada analisis leksikal seperti pemecahan kata selama pengindeksan. Jika Anda mengatur bidang yang dapat dicari ke nilai seperti "hari cerah", secara internal bidang tersebut dibagi menjadi token individu "cerah" dan "hari". Untuk detailnya, lihat Cara kerja pencarian teks lengkap. |
| "dapat difilter" | Direferensikan dalam kueri $filter. Bidang jenis Edm.String yang dapat difilter atau Collection(Edm.String) tidak mengalami pemecahan kata, sehingga perbandingan hanya untuk kecocokan yang tepat. Misalnya, jika Anda mengatur bidang f seperti itu ke "hari cerah", $filter=f eq 'sunny' tidak menemukan kecocokan, tetapi $filter=f eq 'sunny day' akan. |
| "dapat diurutkan" | Secara default, sistem mengurutkan hasil berdasarkan skor, tetapi Anda bisa mengonfigurasi pengurutan berdasarkan bidang dalam dokumen. Bidang jenis Collection(Edm.String) tidak bisa "dapat diurutkan". |
| "dapat difaset" | Biasanya digunakan dalam presentasi hasil pencarian yang menyertakan jumlah klik berdasarkan kategori (misalnya, hotel di kota tertentu). Opsi ini tidak dapat digunakan dengan bidang jenis Edm.GeographyPoint. Panjang bidang jenis Edm.String yang dapat difilter, "dapat diurutkan", atau "dapat difaset" maksimal adalah 32 kilobyte. Untuk detailnya, lihat Membuat Indeks (REST API). |
| "kunci" | Pengidentifikasi unik untuk dokumen dalam indeks. Tepat satu bidang harus dipilih sebagai bidang kunci dan harus berjenis Edm.String. |
| "dapat diambil" | Menentukan apakah bidang dapat dikembalikan dalam hasil pencarian. Ini berguna saat Anda ingin menggunakan bidang (seperti margin laba) sebagai mekanisme filter, pengurutan, atau penilaian, tetapi tidak ingin bidang terlihat oleh pengguna akhir. Atribut ini harus berupa true untuk bidang key. |
Meskipun Anda dapat menambahkan bidang baru kapan saja, definisi bidang yang ada dikunci untuk masa pakai indeks. Untuk alasan ini, pengembang biasanya menggunakan portal untuk membuat indeks sederhana, menguji ide, atau menggunakan halaman portal untuk mencari pengaturan. Perulangan yang sering dilakukan melalui desain indeks lebih efisien jika Anda mengikuti pendekatan berbasis kode agar Anda dapat membangun kembali indeks dengan mudah.
Catatan
API yang Anda gunakan untuk membangun indeks memiliki berbagai perilaku default. Untuk API REST, sebagian besar atribut diaktifkan secara default (misalnya, "dapat dicari" dan "dapat diambil" berlaku untuk bidang string) dan Anda sering kali hanya perlu mengaturnya jika Anda ingin menonaktifkannya. Untuk SDK .NET, kebalikannya adalah benar. Pada properti apa pun yang tidak Anda atur secara eksplisit, defaultnya adalah menonaktifkan perilaku pencarian yang sesuai kecuali Anda mengaktifkannya secara khusus.
Struktur dan ukuran fisik
Dalam Azure AI Search, struktur fisik indeks sebagian besar merupakan implementasi internal. Anda dapat mengakses skemanya, mengkueri kontennya, memantau ukurannya, dan mengelola kapasitas, tetapi kluster itu sendiri (indeks, pecahan, dan file dan folder lainnya) dikelola secara internal oleh Microsoft.
Anda dapat memantau ukuran indeks di tab Indeks di portal Azure, atau dengan mengeluarkan permintaan GET INDEX terhadap layanan pencarian Anda. Anda juga dapat mengeluarkan permintaan Statistik Layanan dan memeriksa nilai ukuran penyimpanan.
Ukuran indeks ditentukan oleh:
- Kuantitas dan komposisi dokumen Anda
- Atribut pada bidang individual
- Konfigurasi indeks (khususnya, apakah Anda menyertakan pemberi saran)
Komposisi dan kuantitas dokumen ditentukan oleh apa yang Anda pilih untuk diimpor. Ingat bahwa indeks pencarian seharusnya hanya berisi konten yang dapat dicari. Jika data sumber menyertakan bidang biner, hilangkan bidang tersebut kecuali Anda menggunakan pengayaan AI untuk memecahkan dan menganalisis konten untuk membuat informasi yang dapat dicari teks.
Atribut bidang menentukan perilaku. Untuk mendukung perilaku tersebut, proses pengindeksan membuat struktur data yang diperlukan. Misalnya, untuk bidang jenis Edm.String, "dapat dicari" memanggil pencarian teks lengkap, yang memindai indeks terbalik untuk istilah yang ditokenisasi. Sebaliknya, atribut "dapat difilter" atau "dapat diurutkan" mendukung iterasi atas string yang tidak diubah. Contoh di bagian berikutnya menunjukkan variasi dalam ukuran indeks berdasarkan atribut yang dipilih.
Pemberi saran adalah konstruksi yang mendukung kueri typeahead atau pelengkapan otomatis. Dengan demikian, ketika Anda menyertakan pemberi saran, proses pengindeksan membuat struktur data yang diperlukan untuk kecocokan karakter verbatim. Pemberi saran diimplementasikan di tingkat lapangan, jadi pilih hanya bidang-bidang yang masuk akal untuk typeahead.
Contoh yang menunjukkan implikasi penyimpanan atribut dan pemberi saran
Cuplikan layar berikut menggambarkan pola penyimpanan indeks yang dihasilkan dari berbagai kombinasi atribut. Indeks didasarkan pada indeks sampel real estate, yang dapat Anda buat dengan mudah menggunakan wizard Impor data dan data sampel bawaan. Meskipun skema indeks tidak ditampilkan, Anda dapat menyimpulkan atribut berdasarkan nama indeks. Misalnya, indeks realestate-searchable memilih atribut "dapat dicari" dan tidak ada yang lain, indeks realestate-retrievable memilih atribut "dapat diambil" dan tidak ada yang lain, dan sebagainya.
Meskipun varian indeks ini agak buatan, kita dapat merujuknya untuk perbandingan luas tentang bagaimana atribut memengaruhi penyimpanan:
- "dapat diambil" tidak berpengaruh pada ukuran indeks.
- "dapat difilter", "dapat diurutkan", "dapat difaset" mengonsumsi lebih banyak penyimpanan.
- pemberi saran memiliki potensi besar untuk meningkatkan ukuran indeks, tetapi tidak sebanyak yang akan ditunjukkan oleh cuplikan layar (semua bidang yang dapat dibuat sadar pemberi saran dipilih, yang bukan skenario kemungkinan di sebagian besar indeks).
Juga tidak tercermin dalam tabel sebelumnya adalah efek penganalisis. Jika Anda menggunakan tokenizer edgeNgram untuk menyimpan urutan karakter verbatim (a, ab, abc, abcd), indeks lebih besar daripada jika Anda menggunakan penganalisis standar.
Operasi dasar dan interaksi
Sekarang, setelah Anda memiliki gagasan yang lebih baik tentang apa itu indeks, bagian ini memperkenalkan operasi runtime indeks, termasuk menghubungkan 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.
Isolasi indeks
Di Azure AI Search, Anda bekerja dengan satu indeks pada satu waktu, di mana semua operasi terkait indeks menargetkan satu indeks. Tidak ada konsep indeks terkait atau gabungan indeks independen untuk pengindeksan atau kueri.
Terus tersedia
Indeks segera tersedia untuk kueri segera setelah dokumen pertama diindeks, tetapi tidak akan sepenuhnya beroperasi sampai semua dokumen diindeks. Secara internal, indeks pencarian 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 dan keamanan
Semua permintaan pengindeksan dan kueri 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
Mulailah dengan portal Azure. Pelanggan Azure, atau orang yang membuat layanan pencarian, dapat mengelola layanan pencarian di portal Azure. Langganan Azure memerlukan izin Kontributor atau di atasnya untuk membuat atau menghapus layanan. Tingkat izin ini cukup untuk sepenuhnya mengelola layanan pencarian di portal Azure.
Coba klien lain untuk akses terprogram. Kami merekomendasikan mulai cepat untuk langkah-langkah pertama:
Langkah berikutnya
Anda bisa mendapatkan pengalaman langsung dalam membuat indeks menggunakan hampir semua sampel atau panduan untuk Azure AI Search. Sebagai permulaan, Anda dapat memilih salah satu mulai cepat dari daftar isi.
Namun, Anda juga ingin terbiasa dengan metodologi untuk memuat indeks dengan data. Strategi definisi indeks dan impor data ditentukan bersamaan. Artikel berikut menyediakan informasi selengkapnya tentang membuat dan memuat indeks.