Catatan
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba masuk atau mengubah direktori.
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba mengubah direktori.
Di Pencarian Azure AI, indeks pencarian adalah konten yang dapat dicari di layanan pencarian, tersedia untuk mesin pencari lokal untuk pengindeksan, pengambilan agenik, pencarian teks lengkap, pencarian vektor, pencarian hibrid, dan kueri yang difilter. Indeks didefinisikan oleh skema yang disimpan ke layanan pencarian Anda, dengan penyerapan data berikut sebagai langkah kedua. Konten terindeks ada di layanan pencarian Anda, selain dari penyimpanan data eksternal utama Anda, yang diperlukan untuk waktu respons milidetik yang diharapkan dalam aplikasi pencarian modern. Kecuali untuk skenario pengambilan berbasis agen jarak jauh dan pengindeksan yang digerakkan oleh pengindeks, layanan pencarian tidak pernah tersambung ke atau melakukan kueri data sumber eksternal Anda.
Artikel ini membahas konsep utama untuk membuat dan mengelola indeks pencarian, termasuk:
- Konten (dokumen dan skema)
- Struktur data fisik
- Operasi dasar
Tip
Ringkasan cepat:
- Indeks menyimpan konten yang dapat dicari
- Skema mendefinisikan bidang dan perilakunya
- Dokumen adalah item individual yang dapat dicari (mirip dengan baris dalam database)
- Langsung ke pembuatan indeks →
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, peritel mungkin memiliki dokumen untuk setiap produk, universitas mungkin memiliki dokumen untuk setiap kelas, situs perjalanan mungkin memiliki dokumen untuk setiap 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.
Berikut adalah contoh tampilan skema indeks.
{
"name": "name_of_index, unique across the service",
"description" : "Health plan coverage for standard and premium plans for Northwind and Contoso employees.",
"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 (only Edm.String fields can be keys) | false (default where applicable),
"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 embedding models" (applies to vector fields of type Collection(Edm.Single)),
"vectorSearchProfile": "name_of_vector_profile" (indexes can have many configurations but 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){ }
}
Koleksi fields ini biasanya merupakan bagian terbesar. Setiap bidang memiliki nama, jenis data, dan atribut yang menentukan penggunaan pada waktu kueri.
Elemen lain diciutkan untuk keperluan singkat, tetapi tautan berikut menyediakan detail:
- suggesters mendukung kueri pencarian cepat 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 Cross-Origin Resource Sharing (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 fields koleksi 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, Hotels, mengilustrasikan tipe kompleks dengan menggunakan Alamat (yang berisi beberapa subbidang) yang memiliki relasi satu-satu dengan masing-masing hotel, serta koleksi kompleks 'Rooms', dimana beberapa kamar dihubungkan dengan setiap hotel.
Atribut lapangan
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
searchabledanretrievable. - Bidang yang digunakan untuk mempersempit atau mengurutkan hasil pencarian ditandai sebagai
sortable,filterable, danfacetable.
| Attribute | Description |
|---|---|
| dapat dicari | Teks lengkap atau vektor dapat dicari. Bidang teks tunduk pada analisis leksikal seperti pemecahan kata selama pengindeksan. Untuk detailnya, lihat Cara kerja pencarian teks lengkap. |
| dapat difilter | Direferensikan dalam kueri $filter. Bidang yang dapat difilter dari jenis Edm.String atau Collection(Edm.String) tidak mengalami pemisahan kata, sehingga perbandingannya hanya untuk kecocokan yang tepat. Mengingat string "hari cerah", $filter=f eq 'sunny' tidak menemukan kecocokan, tetapi $filter=f eq 'sunny day' berhasil. |
| bisa diurutkan | Secara default sistem mengurutkan menurut skor pencarian, tetapi Anda bisa mengonfigurasi pengurutan eksplisit berdasarkan bidang dalam dokumen. Bidang tipe Collection(Edm.String) tidak 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. Bidang jenis Edm.String yang dapat difilter, dapat diurutkan, atau dapat difaset dapat memiliki panjang paling banyak 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 Azure untuk membuat indeks sederhana, menguji ide, atau menggunakan halaman portal Azure 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.
Note
API yang Anda gunakan untuk membangun indeks memiliki berbagai perilaku default. Untuk REST API, sebagian besar atribut diaktifkan secara default (misalnya, atribut dapat dicari dan diambil bernilai benar untuk bidang string) dan Anda sering hanya perlu mengubahnya jika ingin menonaktifkannya. Untuk SDK .NET, kebalikannya adalah benar. Pada properti apa pun yang tidak Anda tetapkan secara eksplisit, defaultnya adalah menonaktifkan perilaku pencarian yang sesuai kecuali Anda secara khusus mengaktifkannya.
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 kapasitasnya. Namun, Microsoft mengelola infrastruktur dan struktur data fisik yang disimpan dengan layanan pencarian Anda.
Anda dapat memantau ukuran indeks pada halaman Indeks manajemen > pencarian di portal Microsoft Azure. Atau, Anda dapat mengeluarkan permintaan GET INDEX terhadap layanan pencarian Anda atau permintaan Statistik Layanan untuk memeriksa nilai ukuran penyimpanan.
Note
Jika Anda secara aktif menghapus konten, penyimpanan dan ukuran indeks diperbarui setiap beberapa menit. Penghapusan dijalankan sebagai proses latar belakang. Harapkan penundaan kecil pada pembaruan metrik.
Ukuran indeks ditentukan oleh:
- Kuantitas dan komposisi dokumen Anda.
- Atribut pada bidang individual: retrievable tidak membengkakkan indeks Anda, tetapi filterable, sortable, dan facetable menggunakan lebih banyak penyimpanan untuk menyimpan teks yang tidak terpecah menjadi token.
- Konfigurasi indeks. Secara khusus, apakah Anda menyertakan pemberi saran atau penganalisis khusus. Jika Anda menggunakan tokenizer edgeNgram untuk menyimpan urutan karakter verbatim (
a, ab, abc, abcd), indeks lebih besar daripada jika Anda menggunakan penganalisis standar.
Komposisi dan kuantitas dokumen ditentukan oleh apa yang Anda pilih untuk diimpor. Ingatlah bahwa indeks pencarian hanya boleh berisi konten yang berguna untuk aplikasi pencarian Anda. 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.
Sugester merupakan konstruksi yang mendukung kueri pengetikan depan atau pelengkapan otomatis. Saat Anda menyertakan pemberi saran, proses pengindeksan membuat struktur data yang diperlukan untuk kecocokan karakter verbatim. Pemberi saran diimplementasikan di tingkat kolom, jadi pilih hanya bidang-bidang yang masuk akal untuk pengetikan otomatis.
Operasi dasar dan interaksi
Sekarang setelah Anda memiliki gambaran yang lebih baik tentang apa itu indeks, bagian ini memperkenalkan operasi waktu berjalan dari indeks, termasuk menyambungkan dan mengamankan sebuah indeks tunggal.
Note
Tidak ada dukungan portal atau API untuk memindahkan atau menyalin indeks. Biasanya, Anda mengarahkan penyebaran aplikasi ke layanan pencarian yang berbeda (menggunakan nama indeks yang sama) atau merevisi nama untuk membuat salinan di layanan pencarian Anda saat ini lalu membangunnya.
Isolasi indeks
Di Azure AI Search, Anda bekerja dengan satu indeks dalam satu waktu. 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 sepenuhnya beroperasi sampai semua dokumen diindeks. Secara internal, indeks didistribusikan di seluruh partisi dan dijalankan pada replika. Indeks fisik dikelola secara internal. Anda mengelola indeks logis.
Indeks terus tersedia dan tidak dapat dijeda atau diambil secara offline. Karena dirancang untuk operasi berkelanjutan, pembaruan pada kontennya dan penambahan indeks itu sendiri terjadi secara real time. Jika permintaan bertepatan dengan pembaruan dokumen, kueri mungkin untuk sementara mengembalikan hasil yang tidak lengkap.
Kelangsungan kueri ada untuk operasi dokumen, seperti refresh atau penghapusan, dan untuk modifikasi yang tidak memengaruhi struktur atau integritas indeks yang ada, seperti menambahkan bidang baru. Pembaruan struktural, seperti mengubah bidang yang ada, biasanya dikelola menggunakan alur kerja drop-and-rebuild di lingkungan pengembangan atau dengan membuat versi baru indeks pada layanan produksi.
Untuk menghindari pembangunan ulang indeks, beberapa pelanggan yang melakukan perubahan kecil membuat "versi" baru dari sebuah bidang yang hidup berdampingan dengan versi sebelumnya. Seiring waktu, ini mengarah ke konten yatim melalui bidang usang dan definisi penganalisis kustom yang usang, terutama dalam indeks produksi yang mahal untuk direplikasi. Anda dapat mengatasi masalah ini selama pembaruan terencana untuk indeks sebagai bagian dari manajemen siklus hidup indeks.
Koneksi titik akhir dan keamanan
Semua permintaan pengindeksan dan kueri menargetkan indeks. Titik akhir biasanya merupakan salah satu dari berikut ini:
| Endpoint | 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 dan 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 akses baca sudah memadai dan tersedia melalui kunci API kueri atau melalui peran pembaca data. Untuk refresh data, hak admin diperlukan. |
Cara menyambungkan ke indeks
Mulailah dengan portal Microsoft Azure dan dasbor layanan pencarian Anda.
Coba klien lain untuk akses terprogram. Kami merekomendasikan mulai cepat untuk langkah-langkah pertama:
Langkah selanjutnya
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 mengenal metodologi untuk mengisi indeks dengan data. Strategi definisi indeks dan impor data ditentukan bersamaan. Artikel berikut menyediakan informasi selengkapnya tentang membuat dan memuat indeks.