Azure Yapay Zeka Arama'de Sunucusuz fiyatlandırma modeli için maliyetleri iyileştirme

Note

Azure Yapay Zeka Arama Azure portalı, REST API'leri ve Azure SDK’ları aracılığıyla kullanılabilir. Ayrıca kuruluş içeriğini Microsoft Foundry portalındaki aracılar için yeniden kullanılabilir, izin kullanan bilgi bankalarına dönüştüren yönetilen bilgi katmanı Foundry IQ'yu temel alır.

Azure Yapay Zeka Arama her birinde farklı iş yükü desenleri için tasarlanmış iki fiyatlandırma modeli desteklenir:

• Adanmış: Arama Birimleri (SU) cinsinden ölçülen sabit fiyatlandırma. Bir hizmet katmanı seçersiniz ve sağlanan birimlere göre saatlik olarak faturalandırılırsınız.

• Sunucusuz (Önizleme):Dizinli depolama için saat başına İşlem Birimleri (CU/sa) ve GB/ay başına ölçülen tüketim tabanlı fiyatlandırma.

Important

Sunucusuz Geliştirici katmanı şu anda önizleme aşamasındadır. Bu önizleme, hizmet düzeyi sözleşmesi olmadan sağlanır ve üretim iş yükleri için önerilmez. Bazı özellikler desteklenmeyebilir veya kısıtlı özelliklere sahip olabilir. Daha fazla bilgi için bkz. Microsoft Azure Önizlemeleri için Ek Kullanım Koşulları.

Sunucusuz Geliştirici katmanı için faturalama, önizleme sırasında henüz etkinleştirilmedi. Kullanımınız için tahmini maliyetler Azure portalında ve telemetride kullanılabilir, ancak bu kullanım ilk dönemde Azure faturanızda görünmez. Microsoft faturalama başlamadan en az 30 gün önce bildirimde bulunacaktır. Bu önizleme sırasında faturalamanın erteleneceği süre geçicidir. Sunucusuz Geliştirici ücretli bir katmandır ve faturalama başladıktan sonra tahakkuk eden tüm ücretlerden siz sorumlu olursunuz.

Sunucusuz Geliştirici katmanı, diğer fiyatlandırma katmanlarına veya katmanlarından geçişi desteklemez ve diğer katmanlarda kullanılabilen bazı özellikler Genel Önizleme sırasında desteklenmez. Hizmet sınırları, desteklenen özellikler ve fiyatlandırma ayrıntıları genel kullanıma sunulmadan önce değişebilir.

Önizleme şu anda yalnızca Orta Batı ABD, Kuzey İsviçre ve Doğu Japonya'da kullanılabilir.

Fiyatlandırma modeli ve hizmet katmanı farklılıkları hakkında daha fazla bilgi için bkz. Fiyatlandırma modeli ve hizmet katmanı seçme.

Sunucusuz modelde maliyet nasıl belirlenir?

Sunucusuz modelde performans iyileştirmesi maliyeti doğrudan etkiler. Maliyet doğrudan iş yükü yürütmeye bağlıdır:

• Sorgular ve dizin oluşturma, işlem tüketir ve saat başına İşlem Birimleri (CU/s) cinsinden ölçülür.
• Depolama, disk üzerindeki dizin boyutuna göre ayrı olarak faturalandırılır.
• Hizmet etkin sorgular veya dizin oluşturma olmadan boşta kaldığında işlem kullanımı sıfır olur. Rezerve veya asgari kapasite ücreti yoktur.

Sunucusuz fiyatlandırma modeli, sağlanan kapasitenin az kullanıldığı değişken, aralıklı veya öngörülemeyen trafiğe sahip iş yükleri için en uygun maliyetli modeldir.

Important

Saat başına Hesaplama Birimi (CU/h) ücretlerinize anlamsal sıralayıcı, aracı tabanlı getirme, görüntü çıkarma ve beceri yürütme dahil değildir. Bu özellikler ayrı olarak faturalandırılır.

İşlem Birimlerini (CU) Anlama

İşlem Birimi (CU), Sunucusuz modelinde arama ve dizin oluşturma işlemleri gerçekleştirmek için gereken ölçülen sistem kaynaklarını temsil eder. CU maliyeti öncelikle CPU, bellek ve GÇ kullanımına ve ikincil olarak Dizin boyutuna ve belge yükü boyutuna göre yönlendirilir ve kullanım saat başına İşlem Birimi (CU/s) olarak faturalandırılır.

Hesaplama maliyeti şu unsurlara göre ölçeklenir:

• Sorgu karmaşıklığı
• Dizin boyutu (GB) ve yapısı
• Belge yükü boyutu (KB)
• Alan sayısı ve alınan sonuç sayısı

Farklı işlemlerin farklı maliyet profilleri vardır:

• Arama: Düşük maliyetli. Tek bir belgenin kimliğine göre alınması en verimli işlemdir.
• Anahtar sözcük araması: Düşük maliyetli. Metin arama, hız ve düşük işlem kullanımı için iyileştirilmiş ters dizinler kullanır.
• Vektör araması: Yüksek maliyet. Vektör sorguları, yüksek boyutlu eklemeler arasında benzerlik hesaplamaları gerektirdiğinden hesaplama açısından pahalıdır. Anahtar sözcük aramasına kıyasla çok daha fazla işlem tüketirler.
• Karma arama: Her iki işlem hattı da her sorgu için çalıştırılırken anahtar sözcük ve vektör aramasının maliyetini birleştirir ve sonuçları birleştirmek için Reciprocal Rank Fusion (RRF) için küçük bir ek ek yük getirir.

Hesaplama kullanımını izleme

İşlem tüketimini izlemek pahalı işlemleri belirlemenize, sorgu desenlerini iyileştirmenize ve maliyetleri tahmin etmenize yardımcı olur. Her isteğin İşlem Birimi (CU) maliyeti HTTP yanıt üst bilgisinde kayan x-ms-request-charge nokta numarası olarak döndürülür. Pahalı işlemleri tanımlamak ve sorgu desenlerini iyileştirmek için bu üst bilgiyi kullanın. Azure İzleyici HTTP yanıt üst bilgilerini ve işlem olaylarını inceleyerek her isteğin CU maliyetini izleyebilirsiniz. Kullanılabilir izleme verilerinin türleri ve bu verileri analiz etme yöntemleri hakkında daha fazla bilgi için Azure Yapay Zeka Arama’i izleme konusuna bakın.

• Üst Bilgi: x-ms-request-charge: <value>
• Değer: Tüketilen CU'ları temsil eden kayan noktalı sayı.

Örnek:

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

Bu örnekte istek 12,45 işlem birimi tüketti. Yüksek maliyetli işlemleri tanımlamak ve farklı sorgu desenlerinin göreli maliyetini karşılaştırmak için bu değeri kullanabilirsiniz.

Sunucusuz arama hizmetinin geçmiş işlem tüketimini gözden geçirmek için Azure portalındaki Azure İzleyici ölçümlerini kullanın:

1. Arama hizmetinize gidin.
2. Ölçümler’i seçin.
3. + Metrik ekle'yi seçin.
4. Ölçüm listesinde İşlem birimleri kullanımı'nı seçin.
5. Kullanım eğilimlerini analiz etmek ve artan işlem tüketimi dönemlerini belirlemek için grafiği kullanın.

Toplam kullanımı izleme, genel hizmet maliyetlerini anlamanıza ve en fazla işlem kaynağını kullanan iş yüklerini belirlemenize yardımcı olur. Kullanılabilir izleme ölçümlerinin açıklamaları için bkz. İzleme Verileri Başvurusu. Azure İzleyici günlüklerini kullanarak zaman içindeki toplu CU kullanımını izleyebilir ve bunu sorgu hacmi ve iş yükü değişiklikleriyle ilişkilendirebilirsiniz.

İşlem kullanımı için uyarıları yapılandırın

İşlem tüketimi Azure portalında belirtilen eşiğe ulaştığında bildirim almak için bir uyarı kuralı oluşturabilirsiniz.

1. Arama hizmetinizde Uyarılar'a gidin.
2. + Uyarı kuralı oluştur seçin.
3. Koşul'un altında sinyal olarak İşlem birimleri kullanımı'nı seçin.
4. Uyarı mantığını tanımlayın. Örneğin, toplam kullanım belirtilen bir değerden büyük olduğunda tetikleyin.
5. E-posta, SMS veya web kancası bildirimleri gibi Eylemleri yapılandırın.
6. Kalan adımları tamamlayın ve Gözden geçir ve oluştur'u seçin.

Uyarılar, beklenmeyen kullanım artışlarına proaktif olarak yanıt vermenizi ve maliyetleri yönetmenizi sağlar.

Sunucusuz maliyetleri tahmin eder

Azure fiyatlandırma hesaplayıcısı ve arama birimi (SU) tabanlı kapasite planlama kılavuzu sunucusuz fiyatlandırma modelini kullanan hizmetler için geçerli değildir.

Sunucusuz maliyetleri tahmin etmek için:

1. Temsili örnek verileri dizine ekleyin.
2. Tipik dizin oluşturma ve sorgu iş yüklerini çalıştırma.
3. x-ms-request-charge Her işlem için döndürülen değeri kaydedin.
4. Zaman içindeki toplam kullanımı ölçmek için Azure İzleyici ölçümlerini kullanın.
5. Maliyetleri beklenen üretim trafiğine göre tahmin edin.

Aynı verilerde yürütülen aynı istek genellikle benzer işlem tüketimi ürettiğinden, temsili iş yükleri maliyet tahmini için güvenilir bir temel sağlayabilir.

Sunucusuz kullanım sürekli olarak ölçülür ve faturalama için toplanır. İşlem tüketimi her dakika boyunca izlenir ve yalnızca işlem kaynakları kullanıldığında yayılır.

Maliyetleri tahmin ederken, tek tek işlemlerin maliyetini anlamak için istek ücreti değerlerini ve genel hizmet tüketimi desenlerini anlamak için Azure İzleyici ölçümleri kullanın.

Faturalama, tek tek istekler yerine toplu işlem kullanımını temel alır. Kullanım bir dakikalık aralıklarla ölçülür ve dakika başına en yakın 0,25 CU değerine yuvarlanır. Bu bir dakikalık kullanım aralıkları, faturalanabilir CU/saat tutarını belirlemek için bir saat içinde birikir. Sistem içinde kullanım, mili hesaplama birimlerinden (mCU) hesaplama birimlerine (CU) toplulaştırılır ve faturalama için raporlanan saatlik kullanıma dönüştürülür.

Farklı işlemler farklı miktarlarda hesaplama gücü tüketir. Genelde:

• Anahtar sözcük aramaları genellikle en az işlem kaynağını kullanır.
• Vektör aramaları genellikle anahtar sözcük aramalarından daha fazla işlem kaynağı kullanır.
• Karma aramalar anahtar sözcük ve vektör arama yürütmesini birleştirerek genellikle tek tek teknikten daha fazla işlem kaynağı kullanır.

Gerçek işlem tüketimi sorgu karmaşıklığı, dizin boyutu, veri hacmi, vektör yapılandırması ve döndürülen sonuç sayısı gibi faktörlere bağlıdır. İstek ücretlerini ve toplu kullanım ölçümlerini izlemek, iyileştirme fırsatlarını belirlemenize ve üretim maliyetlerini daha iyi tahmin etmenize yardımcı olabilir.

İyileştirme yoluyla işlem maliyetlerini azaltma

Verimli sorgular ve dizin tasarımı işlem tüketimini azaltır ve maliyetleri düşürür.

Şemanızı iyileştirme

Dizin şemanız temel işlem ve depolama maliyetlerini belirler:

• Alan özniteliklerini sınırla: Gerektiğinde yalnızca öznitelikleri (aranabilir, filtrelenebilir, modellenebilir, sıralanabilir) etkinleştirin. Her öznitelik, dizin boyutunu ve dizin oluşturma maliyetini artırır.
• Karmaşık türleri düzleştirme: mümkün olduğunca iç içe JSON yapılarını basit alanlara veya koleksiyonlara eşleyin.
• Yalnızca filtreleme veya sıralama için kullanılan alanlar için retrievable=false değerini ayarlayın: Bir alan filtreleme veya sıralama için kullanılıyor ancak sonuçlarda döndürülmesi gerekmiyorsa, dizinlenmiş durumda tutun ve disk üzerindeki depolama kullanımını ve GB/ay başına depolama maliyetini azaltmak için retrievable=false olarak ayarlayın.
• Mümkün olduğunda yalnızca alınabilir alanları kullanın: Örneğin, yalnızca görüntüleme için kullanılan alanlar (resim URL'leri gibi) aranamaz.
• Vektör boyutlarını azaltma: Daha yüksek boyutlu vektörler depolama ve sorgu maliyetini artırır. Uygun olduğunda daha küçük ekleme modelleri veya niceleme kullanın.
• Dizin oluşturmadan önce belge yükü boyutunu en aza indirin: Daha büyük belgelerin dizine maliyeti daha yüksektir. Gereksiz alanları kaldırın, uzun metni kırpın ve belgeleri dizine göndermeden önce HTML'yi çıkarın.

Dizin oluşturma isteklerini iyileştirme

Dizine veri gönderme yönteminiz hem maliyeti hem de aktarım hızını etkiler:

• Mümkün olduğunda daha büyük toplu işler kullanın: Toplu dizin oluşturma, ağ ve işleme maliyetlerini daha fazla belgede amorti ederek istek başına ek yükü azaltır. Genel olarak, yaklaşık 1.000 belgeye veya yaklaşık 16 MB'ye kadar olan gruplar, çok sayıda küçük isteğe kıyasla CU açısından daha verimlidir. Ancak, en uygun toplu iş boyutu iş yükünüze bağlıdır. Aktarım hızını, gecikme süresini ve güvenilirliği dengelemek için test edin.

• Yalnızca yeni veya değiştirilmiş verileri dizine alma: Mümkün olduğunda tam yeniden dizinlemeden kaçının. Yalnızca ekleme ve güncelleştirmelerin gönderilmesi, işlenen belge sayısını azaltarak işlem maliyetini düşürür ve alım hızını artırır.

• Artımlı dizin oluşturma için değişiklik algılamayı kullanın: İçeriği yeniden işlemeden önce nelerin değiştiğini algılayın. Artımlı dizinleme, değişmemiş belgelerde tekrarlı işlemleri önler ve yeniden işleme maliyetlerini düşük tutar.

• İhtiyacınız olmadığı sürece görüntü ayıklamayı atlayın: Görüntü ayıklama ek işleme çalışması ekler ve ayrı bir maliyet sürücüsü haline gelebilir. Bu özelliği yalnızca görüntü içeriğine ihtiyaç duyan belgeler veya iş akışları için açın.

• Becerileri ilgili alanlara ve belgelere hedefle: İhtiyaç duydukları belirli alanlara veya belgelere yönelik kapsam zenginleştirme becerileri. Özellikle çıktılar sonraki aşamalarda kullanılmıyorsa, zenginleştirme gerektirmeyen içerik üzerinde becerileri çalıştırmaktan kaçının.

• Dizin boyutu büyümesi için hesap: Mümkün olduğunda daha küçük dizinler oluşturun. Dizin büyüdükçe, daha fazla verinin depolanması ve korunması ve işlemlerin daha fazla işlem gerektirmesi nedeniyle dizin oluşturma maliyetleri artar. Çok büyük veri kümeleri için, performansı ve maliyetleri yönetmeye yardımcı olmak için verileri birden çok dizine bölmeyi göz önünde bulundurun. Dizin boyutuyla birlikte maliyetler artsa da, artış alt çizgi şeklindedir. Daha büyük dizinlerin maliyeti işlem başına daha fazladır ancak orantılı olarak daha fazla değildir.

Daha fazla kılavuz için bkz. Azure Yapay Zeka Arama'da daha iyi performans için İpuçları.

Sorgularınızı iyileştirme

Sorgu tasarımı, değişken maliyetin birincil sürücüsüdür:

• Döndürülen alanları sınırlamak için kullanın$select: Bu, serileştirme için gereken yük boyutunu ve işlemi azaltır.

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

• Metnin arandığı yeri sınırlamak için kullanınsearchFields: Sorgu zamanı eşleştirmesini senaryo için önemli olan alanlarla kısıtlayın. Her ek aranabilir alan sorgu çalışmasını artırır ve CU/s'i artırabilir.

• Tam eşleşme veya basit anahtar sözcük sorgularını tercih edin: Belirsiz, joker karakter, regex ve ön ek stilindeki sorgular geniş dizin taramalarını zorlayabilir ve önemli ölçüde daha fazla CU/s tüketebilir. Bunları yalnızca kısmi eşleştirme davranışına ihtiyacınız olduğunda kullanın ve mümkün olan her yerde tam eşleşme veya daha basit anahtar sözcük sorguları seçin.

• Mümkün olduğunda arama yerine aramaları kullanın: Bir belgeyi kimlikle almak, arama sorgusu çalıştırmaktan daha verimlidir. Belge kimliğini biliyorsanız, arama sorgusu yerine doğrudan sorgulama kullanın. Aramalar, belgeyi doğrudan anahtarla aldıklarından daha verimlidir; arama sorguları ise işlem maliyetini artıran tam sorgu işlem hattını (ayrıştırma, dizin geçişi, puanlama ve derecelendirme) çağırır.

• Derin sayfalamadan kaçının ($skip): Büyük $skip değerleri, motorun önceki tüm sonuçları işlemesi ve sıralaması gerektiğinden işlem yükünü artırır (örneğin, $skip=5000 döndürülmeyen en az 5.000 belgenin puanlanmasını gerektirir). Bu, işlem kaynaklarını (CU'ları) boşa harcar ve maliyeti artırır. Bunun yerine, sonuçları daraltmak için filtreleri kullanın ve $top ile döndürülen sonuç sayısını sınırlayın. $top öğesini kullanıcı arayüzü görünümünüzle eşleşecek şekilde doğru boyuta ayarlayın. Örneğin, daha az sonuç puanlanıp döndürüldüğü için $top=10, $top=50'den daha düşük maliyetlidir. Yalnızca uygulamanızın ihtiyaç duyduğu sayıda sonuç isteyin ve altyapının çok sayıda kullanılmayan sonucu işlemesini gerektiren desenlerden kaçının.

• Model sayısını ve model kapsamını en aza indirin: Yalnızca kullanıcı arabiriminizde görüntülenen modelleri isteyin ve her model count değerini olabildiğince düşük tutun. Fasetler her sorgu için toplulaştırmalar gerektirir ve yüksek sayılar hesaplama maliyetini artırır.

• Filtreleme için kullanınsearch.in: Bir kimlik veya değer listesine göre filtreleme yaparken, birden çok search.in koşul yerine işlevini kullanın or (örneğin, id eq '1' or id eq '2'). Bu yaklaşım daha verimlidir ve işlem yükünü azaltır. Ayrıca, dizin boyutunu ve sorgu maliyetini artırdığından, gerekmedikçe yüksek kardinaliteli alanları (benzersiz kimlikler veya serbest metin açıklamaları gibi çok sayıda benzersiz değere sahip olanlar) filtrelenebilir veya yüzlenebilir olarak işaretlemekten kaçınmalısınız.

Yönetim isteklerinizi iyileştirme

sorgu ve dizin oluşturma işlemlerine ek olarak, Azure Yapay Zeka Arama nesne düzeyinde ve hizmet düzeyinde yönetim işlemlerini (dizin şemalarını veya hizmet istatistiklerini alma gibi) içerir. Bu isteklerin istek başına sabit bir maliyeti vardır. Her istek ucuz olsa da, yinelenen veya gereksiz çağrılar zaman içinde birikebilir ve genel işlem kullanımını artırabilir.

• Aşırı yönetim isteklerinden kaçının: Dizin şemaları gibi meta verileri tekrar tekrar almak yerine istemci tarafında önbelleğe alın. Örneğin, her yazma işleminden önce dizin şemasını getirmek gereksiz maliyet getirir. Sunucusuz modelde bu düzen işlem ücretlerini doğrudan artırırken, Ayrılmış hizmetlerde bu etki genellikle sabit saatlik faturalamayla gizlenir.

Vektör maliyetlerini iyileştirme

Vektör iş yükleri, hem İşlem Birimlerini (sorgular ve dizin oluşturma) hem de depolamayı (diskteki vektör boyutu) etkilediğinden, sunucusuz fiyatlandırma modeli aramasında genellikle en yüksek maliyetli bileşendir. Maliyeti azaltmak için hem vektörlerin depolanma şeklini hem de sorgulanma şeklini iyileştirin.

Vektör depolamayı ve şemayı iyileştirme

Vektör alanları dizin boyutunu ve dizin oluşturma maliyetini önemli ölçüde artırabilir. Depolama ek yükünü azaltmak için aşağıdaki teknikleri kullanın:

• Vektör boyutunu küçültmek için sıkıştırmayı kullanın: Depolama ayak izini en az ilgi etkisiyle azaltmak için niceleme uygulayın. Örneğin skaler niceleme, arama kalitesini en az etkileyerek vektör depolama alanını 4×'a kadar azaltabilir.

• Gerekli olmadığında vektörler için depolamayı devre dışı bırakın: Vektörlere yalnızca arama için ihtiyacınız varsa, geri almak için değilse, vektör alanlarında stored=false olarak ayarlayın. Bu, özgün vektörlerin dizinde depolanmasını önler ve sorgu davranışını etkilemeden depolama maliyetini azaltır.

• Mümkün olduğunda daha küçük ekleme boyutları kullanın: Daha yüksek boyutlu vektörler hem depolama hem de sorgu maliyetini artırır. Kritik olmayan iş yüklerinde maliyeti azaltmak için daha küçük ekleme modelleri (örneğin, 1536 yerine 384 veya 768 boyut) kullanın.

Vektör sorgu yürütmeyi iyileştirme

Vektör sorguları, yüksek boyutlu veri yapıları üzerinde benzerlik hesaplamaları gerektirdiği için yoğun işlem gücü kullanır.

• Karma aramayı seçmeli olarak kullanın: Karma sorgular hem anahtar sözcüğü hem de vektör alma işlemini çalıştırır. Yalnızca uygunluk açısından gerekli olduğunda kullanın.

• Vektör sorgularından önce filtre uygulama: İşlenen veri miktarını azaltmak için vektör aramadan önce ayarlanan adayı daraltın. Bkz. Vektör sorgularında filtreleme nasıl çalışır?

Kullanımı en aza indirerek maliyetleri azaltma

Sunucusuz model yalnızca tüketilen kaynaklar için ücretlendirilir. İstek olmadığında işlem kullanımı buna göre düşer.

Kullanım maliyetlerini en aza indirmek için:

• Sorguları yalnızca gerektiğinde çalıştırın.
• Yedekli veya fazla sık yapılan isteklerden kaçının.
• Kullanımı izleyin ve iş yüklerini isteğe bağlı olarak ayarlayın.

Tavsiye

Aynı sorgu, hizmetin sıcak mı yoksa soğuk mu olduğuna bağlı olarak farklı gecikme süresine ve CU profillerine sahip olabilir. Okuma veya yazma trafiği olmayan bir dönemden sonra Sunucusuz fiyatlandırma modelindeki işlem kullanımı sıfıra düşer. Sonraki istek daha yüksek gecikme süresine sahip olabilir ve veri yolları ısınırken daha fazla CU tüketebilir. Büyük dizinlerin ısınması genellikle küçük dizinlere göre daha uzun sürer, bu nedenle soğuk başlangıç efektleri genellikle daha büyük hizmetlerde daha belirgindir.

Depolama maliyetlerini iyileştirme

Depolama, ham veri boyutunu aşabilen disk dizini boyutuna göre GB/ay başına faturalandırılır. Depolama maliyetlerini azaltmak için:

• Kullanılmayan dizinleri kaldırın.
• Depolanan alanları en aza indirin.
• Depolama ek yükünü göz önünde bulundurarak şemaları tasarlar.
• Depolama boyutunu önemli ölçüde artırabildiğinden önericileri seçmeli olarak kullanın.

Vektöre özgü teknikler (sıkıştırma, ayıklama ve depolama ayarları) için bkz. Vektör depolama ve işleme için iyileştirme.

Depolama ve sorgu performansıyla ilgili daha fazla bilgi için bkz. Azure Yapay Zeka Arama'da daha iyi performans için İpuçları.