Mengoptimalkan biaya untuk model harga Tanpa Server di Pencarian Azure AI

Note

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.

Pencarian Azure AI mendukung dua model harga, masing-masing dirancang untuk pola beban kerja yang berbeda:

  • Khusus: Harga tetap yang diukur oleh Unit Pencarian (SU). Anda memilih tingkat layanan, dan Anda ditagih per jam berdasarkan unit yang disediakan.

  • Tanpa server (Pratinjau): Harga berbasis konsumsi yang diukur oleh Unit Komputasi per jam (CU/jam) dan per GB/bulan untuk penyimpanan terindeks.

Important

Tingkat Pengembang Tanpa Server saat ini dalam pratinjau. Pratinjau ini disediakan tanpa perjanjian tingkat layanan dan tidak direkomendasikan untuk beban kerja produksi. Fitur tertentu mungkin tidak didukung atau mungkin memiliki kemampuan terbatas. Untuk informasi lebih lanjut, lihat Supplemental Terms of Use for Microsoft Azure Previews.

Penagihan untuk tingkat Pengembang Tanpa Server belum diaktifkan selama pratinjau. Perkiraan biaya untuk penggunaan Anda tersedia di portal Azure dan telemetri, tetapi penggunaan tersebut tidak akan muncul pada tagihan Azure Anda selama periode awal ini. Microsoft akan memberikan pemberitahuan setidaknya 30 hari sebelum penagihan dimulai. Penangguhan penagihan selama pratinjau ini bersifat sementara. Pengembang Tanpa Server adalah tingkat berbayar dan Anda akan bertanggung jawab atas biaya apa pun yang timbul setelah penagihan dimulai.

Tingkat Pengembang Tanpa Server tidak mendukung migrasi ke atau dari tingkat harga lain dan beberapa fitur yang tersedia di tingkat lain tidak didukung selama Pratinjau Umum. Batas layanan, fitur yang didukung, dan detail harga dapat berubah sebelum ketersediaan umum.

Pratinjau saat ini hanya tersedia di West Central US, Switzerland North, dan Japan East.

Untuk informasi selengkapnya tentang model harga dan perbedaan tingkat layanan, lihat Memilih model harga dan tingkat layanan.

Bagaimana biaya ditentukan dalam model Tanpa Server

Dalam model Tanpa Server, pengoptimalan performa secara langsung memengaruhi biaya. Biaya langsung terkait dengan eksekusi beban kerja:

  • Kueri dan pengindeksan menggunakan komputasi, diukur dalam Unit Komputasi per jam (CU/jam).
  • Penyimpanan ditagih secara terpisah berdasarkan ukuran indeks pada disk.
  • Ketika layanan menganggur tanpa kueri atau pengindeksan aktif, penggunaan komputasi adalah nol. Tidak ada biaya kapasitas yang dicadangkan atau biaya kapasitas minimum.

Model harga Tanpa Server paling hemat biaya untuk beban kerja dengan variabel, terputus-putus, atau lalu lintas yang tidak dapat diprediksi, di mana kapasitas yang disediakan akan kurang digunakan.

Important

Biaya Unit Komputasi per jam (CU/jam) Anda tidak termasuk peringkat semantik, pengambilan agenik, ekstraksi gambar, dan eksekusi keterampilan. Fitur ini ditagih secara terpisah.

Memahami Unit Komputasi (CUs)

Unit Komputasi (CU) mewakili sumber daya sistem terukur yang diperlukan untuk melakukan operasi pencarian dan pengindeksan dalam model Tanpa Server. Biaya CU terutama ditentukan oleh pemanfaatan CPU, memori, dan IO, serta pada tingkat kedua oleh ukuran indeks dan ukuran payload dokumen, dengan penggunaan ditagihkan dalam Unit Komputasi per jam (CU/jam).

Skala biaya komputasi dengan:

  • Kompleksitas kueri
  • Ukuran indeks (GB) dan struktur
  • Ukuran payload dokumen (KB)
  • Jumlah bidang dan hasil yang diambil

Operasi yang berbeda memiliki profil biaya yang berbeda:

  • Lookup: Berbiaya rendah. Mengambil satu dokumen dengan ID-nya adalah operasi yang paling efisien.
  • Pencarian kata kunci: Biaya rendah. Pencarian teks menggunakan indeks terbalik, yang dioptimalkan untuk kecepatan dan penggunaan komputasi rendah.
  • Pencarian vektor: Biaya tinggi. Kueri vektor mahal secara komputasi karena memerlukan perhitungan kesamaan pada embedding berdimensi tinggi. Dibandingkan dengan pencarian kata kunci, mereka mengonsumsi komputasi yang jauh lebih banyak.
  • Pencarian hibrida: Menggabungkan biaya pencarian kata kunci dan pencarian vektor, karena kedua alur pemrosesan berjalan untuk setiap kueri, ditambah sedikit overhead untuk Reciprocal Rank Fusion (RRF) guna menggabungkan hasilnya.

Memantau penggunaan komputasi

Memantau konsumsi komputasi membantu Anda mengidentifikasi operasi yang mahal, mengoptimalkan pola kueri, dan memperkirakan biaya. Biaya Unit Komputasi (CU) dari setiap permintaan dikembalikan di x-ms-request-charge header respons HTTP sebagai angka titik mengambang. Gunakan header ini untuk mengidentifikasi operasi yang mahal dan mengoptimalkan pola kueri. Anda dapat melacak biaya CU dari setiap permintaan dengan memeriksa header respons HTTP dan peristiwa operasi di Azure Monitor. Untuk panduan selengkapnya tentang jenis data pemantauan yang tersedia dan metode untuk menganalisis data tersebut, lihat Memantau Pencarian Azure AI.

  • Header: x-ms-request-charge: <value>
  • Nilai: Bilangan titik mengambang yang mewakili CUs yang digunakan.

Contoh:

Status: 200 OK
Content-Type: application/json
x-ms-request-charge: 12.45

Dalam contoh ini, permintaan menggunakan 12,45 unit komputasi. Anda dapat menggunakan nilai ini untuk mengidentifikasi operasi berbiaya tinggi dan membandingkan biaya relatif berbagai pola kueri.

Untuk meninjau konsumsi komputasi historis untuk layanan pencarian tanpa server, gunakan metrik Azure Monitor di portal Azure:

  1. Buka layanan pencarian Anda.
  2. Pilih Metrik.
  3. Pilih + Tambahkan metrik.
  4. Dari daftar metrik, pilih Penggunaan unit komputasi.
  5. Gunakan bagan untuk menganalisis tren penggunaan dan mengidentifikasi periode peningkatan konsumsi komputasi.

Memantau penggunaan agregat membantu Anda memahami biaya layanan secara keseluruhan dan mengidentifikasi beban kerja yang menggunakan sumber daya komputasi terbanyak. Untuk deskripsi metrik pemantauan yang tersedia, lihat Referensi Data Pemantauan. Anda dapat menggunakan log Azure Monitor untuk melacak penggunaan CU agregat dari waktu ke waktu dan menghubungkannya dengan perubahan volume kueri dan beban kerja.

Cuplikan layar dasbor pemantauan metrik untuk Unit Komputasi tanpa server di portal Azure.

Mengonfigurasi pemberitahuan untuk penggunaan komputasi

Anda dapat membuat aturan pemberitahuan untuk diberi tahu saat konsumsi komputasi mencapai ambang yang ditentukan di portal Azure.

  1. Buka Pemberitahuan di layanan pencarian Anda.
  2. Pilih + Buat aturan pemberitahuan.
  3. Di bawah Kondisi, pilih Penggunaan unit komputasi sebagai sinyal.
  4. Tentukan logika pemberitahuan. Misalnya, pemicu ketika total penggunaan lebih besar dari nilai yang ditentukan.
  5. Konfigurasikan Tindakan, seperti email, SMS, atau pemberitahuan webhook.
  6. Selesaikan langkah-langkah yang tersisa dan pilih Tinjau + buat.

Pemberitahuan membantu Anda secara proaktif menanggapi lonjakan penggunaan yang tidak terduga dan mengelola biaya.

Cuplikan layar pembuatan aturan pemberitahuan di portal Azure.

Estimasi biaya tanpa server

Panduan perencanaan kapasitas berbasis kalkulator harga dan unit pencarian (SU) Azure tidak berlaku untuk layanan yang menggunakan model harga tanpa server.

Untuk memperkirakan biaya tanpa server:

  1. Indeks data sampel yang representatif.
  2. Jalankan beban kerja pengindeksan dan kueri yang umum.
  3. Catat nilai x-ms-request-charge yang dikembalikan untuk setiap operasi.
  4. Gunakan metrik Azure Monitor untuk mengukur penggunaan agregat dari waktu ke waktu.
  5. Ekstrapolasi biaya berdasarkan lalu lintas produksi yang diharapkan.

Karena permintaan yang sama dijalankan terhadap data yang sama umumnya menghasilkan konsumsi komputasi serupa, beban kerja representatif dapat memberikan dasar yang dapat diandalkan untuk estimasi biaya.

Penggunaan tanpa server diukur terus menerus dan diagregasi untuk penagihan. Konsumsi komputasi dilacak sepanjang setiap menit dan dipancarkan hanya saat sumber daya komputasi digunakan.

Saat memperkirakan biaya, gunakan nilai biaya permintaan untuk memahami biaya operasi individu dan metrik Azure Monitor untuk memahami pola konsumsi layanan secara keseluruhan.

Penagihan didasarkan pada penggunaan komputasi agregat daripada permintaan individual. Penggunaan diukur dalam interval satu menit dan dibulatkan ke atas ke 0,25 CU terdekat per menit. Interval penggunaan satu menit ini terakumulasi selama satu jam untuk menentukan jumlah CU/jam yang dapat ditagih. Secara internal, penggunaan diagregasikan dari mili unit komputasi (mCU) menjadi unit komputasi (CU) lalu dikonversi menjadi penggunaan per jam yang dilaporkan untuk penagihan.

Operasi yang berbeda mengonsumsi jumlah komputasi yang berbeda. Secara umum:

  • Pencarian kata kunci biasanya menggunakan sumber daya komputasi paling sedikit.
  • Pencarian vektor biasanya menggunakan lebih banyak sumber daya komputasi daripada pencarian kata kunci.
  • Pencarian hibrid menggabungkan kata kunci dan eksekusi pencarian vektor, sehingga biasanya menggunakan lebih banyak sumber daya komputasi daripada salah satu teknik saja.

Konsumsi komputasi aktual tergantung pada faktor-faktor seperti kompleksitas kueri, ukuran indeks, volume data, konfigurasi vektor, dan jumlah hasil yang dikembalikan. Memantau biaya permintaan dan metrik penggunaan agregat dapat membantu Anda mengidentifikasi peluang pengoptimalan dan memprediksi biaya produksi dengan lebih baik.

Mengurangi biaya komputasi melalui pengoptimalan

Kueri dan desain indeks yang efisien mengurangi konsumsi komputasi dan biaya yang lebih rendah.

Mengoptimalkan skema Anda

Skema indeks Anda menentukan biaya komputasi dan penyimpanan dasar:

  • Batasi atribut bidang: Hanya aktifkan atribut (dapat dicari, dapat difilter, dapat difaset, dapat diurutkan) jika diperlukan. Setiap atribut meningkatkan ukuran indeks dan biaya pengindeksan.
  • Meratakan jenis kompleks: Memetakan struktur JSON berlapis ke bidang atau koleksi sederhana jika memungkinkan.
  • Atur retrievable=false untuk bidang filter saja atau urutkan-saja: Jika bidang digunakan untuk pemfilteran atau pengurutan tetapi tidak perlu dikembalikan dalam hasil, biarkan diindeks dan atur retrievable=false untuk mengurangi penyimpanan pada disk dan biaya penyimpanan per GB/bulan.
  • Gunakan bidang khusus yang dapat diambil jika memungkinkan: Misalnya, bidang yang hanya digunakan untuk tampilan (seperti URL gambar) tidak boleh dapat dicari.
  • Mengurangi dimensi vektor: Vektor dimensi yang lebih tinggi meningkatkan penyimpanan dan biaya kueri. Gunakan model atau kuantisasi penyematan yang lebih kecil jika sesuai.
  • Minimalkan ukuran payload dokumen sebelum pengindeksan: Dokumen yang lebih besar lebih mahal untuk diindeks. Hapus bidang yang tidak perlu, pangkas teks panjang, dan strip HTML sebelum mengirim dokumen ke indeks.

Mengoptimalkan permintaan pengindeksan

Cara Anda mengirim data ke indeks memengaruhi biaya dan throughput:

  • Gunakan batch yang lebih besar jika memungkinkan: Pengindeksan Batch mengurangi overhead per permintaan dengan mengamortisasi biaya jaringan dan pemrosesan di lebih banyak dokumen. Secara umum, batch berisi hingga ~1.000 dokumen atau ~16 MB lebih efisien dalam penggunaan CU dibandingkan banyak permintaan kecil. Namun, ukuran batch yang optimal tergantung pada beban kerja Anda. Uji untuk menyeimbangkan throughput, latensi, dan keandalan.

  • Indeks hanya data baru atau yang diubah: Hindari pengindeksan ulang penuh jika memungkinkan. Mengirim hanya penambahan dan pembaruan mengurangi jumlah dokumen yang diproses, menurunkan biaya komputasi, dan meningkatkan kecepatan penyerapan.

  • Gunakan deteksi perubahan untuk pengindeksan bertambah bertahap: Deteksi apa yang berubah sebelum Anda memproses ulang konten. Pengindeksan bertahap menghindari pekerjaan berulang pada dokumen yang tidak mengalami perubahan dan menjaga biaya pemrosesan ulang tetap rendah.

  • Lewati ekstraksi gambar kecuali Anda membutuhkannya: Ekstraksi gambar menambahkan pekerjaan pemrosesan tambahan dan dapat menjadi pengandar biaya terpisah. Aktifkan hanya untuk dokumen atau alur kerja yang benar-benar membutuhkan konten gambar.

  • Sesuaikan keterampilan dengan bidang dan dokumen yang relevan: Perluas cakupan keterampilan ke bidang atau dokumen tertentu yang diperlukan. Hindari menjalankan skill pada seluruh konten yang tidak memerlukan pengayaan, terutama jika outputnya tidak digunakan pada tahap berikutnya.

  • Memperhitungkan pertumbuhan ukuran indeks: Jika memungkinkan, buat indeks yang lebih kecil. Seiring bertambahnya indeks, biaya pengindeksan meningkat karena lebih banyak data harus disimpan dan dipertahankan, dan operasi membutuhkan lebih banyak komputasi. Untuk himpunan data yang sangat besar, pertimbangkan untuk mempartisi data di beberapa indeks untuk membantu mengelola performa dan biaya. Meskipun biaya naik dengan ukuran indeks, peningkatannya adalah sublinear. Indeks yang lebih besar memerlukan biaya lebih besar untuk setiap operasi, tetapi kenaikannya tidak proporsional.

Untuk panduan selengkapnya, lihat Tips untuk performa yang lebih baik di Pencarian Azure AI.

Optimalkan kueri Anda

Desain kueri adalah penggerak utama biaya variabel:

  • Gunakan $select untuk membatasi bidang yang dikembalikan: Ini mengurangi ukuran payload dan komputasi yang diperlukan untuk serialisasi.

    GET /docs?search=test&$select=id,title,url

  • Gunakan searchFields untuk membatasi tempat teks dicari: Membatasi pencocokan waktu kueri ke bidang yang penting untuk skenario. Setiap bidang tambahan yang dapat dicari meningkatkan pekerjaan kueri dan dapat meningkatkan CU/jam.

  • Utamakan kueri pencocokan tepat atau kueri kata kunci sederhana: Kueri fuzzy, wildcard, regex, dan prefiks dapat memaksa pemindaian indeks yang luas dan menggunakan CU/h jauh lebih banyak. Gunakan hanya saat Anda memerlukan perilaku pencocokan parsial dan pilih kueri kecocokan yang tepat atau kata kunci yang lebih sederhana jika memungkinkan.

  • Gunakan pencarian alih-alih pencarian jika memungkinkan: Mengambil dokumen menurut ID lebih efisien daripada menjalankan kueri pencarian. Jika Anda mengetahui ID dokumen, gunakan pencarian alih-alih kueri pencarian. Operasi lookup lebih efisien karena mengambil dokumen secara langsung berdasarkan kunci, sedangkan kueri penelusuran melewati seluruh alur kueri (penguraian, penelusuran indeks, pemberian skor, dan pemeringkatan), yang meningkatkan biaya komputasi.

  • Hindari penomoran mendalam ($skip): Nilai besar $skip meningkatkan komputasi karena mesin harus memproses dan memberi peringkat semua hasil sebelumnya (misalnya, $skip=5000 memerlukan penilaian setidaknya 5.000 dokumen yang tidak dikembalikan). Ini membuang-buang sumber daya komputasi (CU) dan meningkatkan biaya. Sebagai gantinya, gunakan filter untuk mempersempit hasil dan membatasi angka yang dikembalikan dengan $top. Sesuaikan ukuran $top dengan tampilan UI Anda. Misalnya, $top=10 biaya kurang dari $top=50 karena lebih sedikit hasil yang dinilai dan dikembalikan. Hanya minta hasil sebanyak yang dibutuhkan aplikasi Anda, dan hindari pola yang mengharuskan mesin memproses sejumlah besar hasil yang tidak digunakan.

  • Minimalkan jumlah faset dan lingkup faset: Minta hanya faset yang ditampilkan di UI Anda, dan pertahankan count setiap nilai faset serendah praktis. Faset memerlukan agregasi per kueri, dan jumlah tinggi meningkatkan biaya komputasi.

  • Gunakan search.in untuk pemfilteran: Saat memfilter menurut daftar ID atau nilai, gunakan search.in fungsi alih-alih beberapa or kondisi (misalnya, id eq '1' or id eq '2'). Pendekatan ini lebih efisien dan mengurangi overhead komputasi. Anda juga harus menghindari penandaan bidang kardinalitas tinggi (bidang dengan sejumlah besar nilai unik, seperti ID unik atau deskripsi teks bebas) sebagai dapat difilter atau dapat difaset kecuali diperlukan, karena ini meningkatkan ukuran indeks dan biaya kueri.

Mengoptimalkan permintaan administratif Anda

Selain operasi kueri dan pengindeksan, Pencarian Azure AI mencakup operasi administratif tingkat objek dan tingkat layanan (seperti mengambil skema indeks atau statistik layanan). Permintaan ini memiliki biaya per permintaan yang tetap. Meskipun setiap permintaan relatif murah, panggilan yang berulang atau tidak perlu dapat menumpuk seiring waktu dan meningkatkan penggunaan sumber daya komputasi secara keseluruhan.

  • Hindari permintaan administratif yang berlebihan: Metadata cache, seperti skema indeks, di sisi klien alih-alih mengambilnya berulang kali. Misalnya, mengambil skema indeks sebelum setiap operasi tulis menimbulkan biaya yang tidak perlu. Dalam model Tanpa Server, pola ini secara langsung meningkatkan biaya komputasi, sedangkan di Layanan khusus, dampaknya sering disembunyikan oleh penagihan per jam tetap.

Mengoptimalkan biaya vektor

Beban kerja vektor biasanya merupakan komponen berbiaya tertinggi untuk mencari model harga Tanpa Server karena berdampak pada Unit Komputasi (kueri dan pengindeksan) dan penyimpanan (ukuran vektor pada disk). Untuk mengurangi biaya, optimalkan bagaimana vektor disimpan dan bagaimana mereka dikueri.

Mengoptimalkan penyimpanan dan skema vektor

Bidang vektor dapat secara signifikan meningkatkan ukuran indeks dan biaya pengindeksan. Gunakan teknik berikut untuk mengurangi overhead penyimpanan:

  • Gunakan kompresi untuk mengurangi ukuran vektor: Terapkan kuantisasi untuk mengurangi jejak penyimpanan dengan dampak relevansi minimal. Misalnya, kuantisasi skalar dapat mengurangi penyimpanan vektor hingga 4× dengan dampak minimal pada kualitas pencarian.

  • Nonaktifkan penyimpanan untuk vektor saat tidak diperlukan: Atur stored=false pada bidang vektor jika Anda hanya memerlukan vektor untuk pencarian, bukan pengambilan. Ini menghindari penyimpanan vektor asli dalam indeks, mengurangi biaya penyimpanan tanpa memengaruhi perilaku kueri.

  • Gunakan dimensi penyematan yang lebih kecil jika memungkinkan: Vektor dimensi yang lebih tinggi meningkatkan biaya penyimpanan dan kueri. Untuk beban kerja non-kritis, gunakan model penyematan yang lebih kecil (misalnya, 384 atau 768 dimensi, bukan 1536) untuk mengurangi biaya.

Mengoptimalkan eksekusi kueri vektor

Kueri vektor bersifat intensif komputasi karena memerlukan perhitungan kesamaan atas struktur data berdimensi tinggi.

  • Gunakan pencarian hibrid secara selektif: Kueri hibrid menjalankan pengambilan kata kunci dan vektor. Gunakan hanya jika perlu untuk relevansi.

  • Terapkan filter sebelum kueri vektor: Persempit kumpulan kandidat sebelum pencarian vektor untuk mengurangi jumlah data yang diproses. Lihat Cara kerja pemfilteran dalam kueri vektor.

Mengurangi biaya dengan meminimalkan penggunaan

Model Tanpa Server hanya dikenakan biaya untuk sumber daya yang digunakan. Ketika tidak ada permintaan, penggunaan komputasi turun sesuai.

Untuk meminimalkan biaya penggunaan:

  • Jalankan kueri hanya jika diperlukan.
  • Hindari permintaan yang berlebihan atau terlalu sering.
  • Pantau penggunaan dan setel beban kerja berdasarkan permintaan.

Tip

Kueri yang sama dapat memiliki latensi dan profil CU yang berbeda tergantung pada apakah layanan hangat atau dingin. Setelah periode tanpa lalu lintas baca atau tulis, penggunaan komputasi dalam model harga Tanpa Server turun menjadi nol. Permintaan berikutnya mungkin mengalami latensi yang lebih tinggi dan menggunakan lebih banyak CUs saat jalur data mulai aktif. Indeks yang lebih besar umumnya membutuhkan waktu lebih lama untuk dihangatkan daripada indeks yang lebih kecil, sehingga efek cold-start sering lebih terlihat pada layanan yang lebih besar.

Mengoptimalkan biaya penyimpanan

Penyimpanan ditagih per GB/bulan berdasarkan ukuran indeks pada disk, yang dapat melebihi ukuran data mentah. Untuk mengurangi biaya penyimpanan:

  • Hapus indeks yang tidak digunakan.
  • Minimalkan bidang tersimpan.
  • Rancang skema dengan mempertimbangkan overhead penyimpanan.
  • Gunakan saran secara selektif karena mereka dapat secara dramatis meningkatkan ukuran penyimpanan.

Untuk teknik khusus vektor (kompresi, pemangkasan, dan pengaturan penyimpanan), lihat Mengoptimalkan penyimpanan dan pemrosesan vektor.

Untuk panduan lebih lanjut tentang kompromi antara penyimpanan dan performa kueri, lihat Tips untuk meningkatkan performa di Pencarian Azure AI.

  • Last updated on