Gecikme bütçesiyle arama: hız, ödünler ve yedek planlar

Arama API'lerinin çoğu, bir ajanın arka planda yazdığı rapor için yeterince hızlıdır. Ama arayan kişi yeniden konuşmaya başlamadan yanıt vermesi gereken bir sesli asistan ya da kullanıcı yazarken sonuç öneren bir arama kutusu için kendiliğinden yeterince hızlı değildir. Hız bir ürün gereksinimine dönüştüğünde seçim sorusu da değişir. Artık soru hangi sağlayıcının en iyi sonuçları döndürdüğü değil; hangisinin ayırabildiğiniz süre içinde yeterince iyi sonuç döndürdüğü ve döndüremediğinde ne yapacağınızdır. Bu rehber gecikmenin gerçekten nerede önemli olduğunu, onu elde etmek için nelerden vazgeçtiğinizi, önbelleğin ve yedek planların nereye oturduğunu ve yayımlanmış bir rakama güvenmek yerine kendi trafiğinizle nasıl ölçeceğinizi anlatıyor.

Hızın ürünü değiştirdiği yerler

• Ses. Telefonda sessizlik arıza gibi algılanır. Arama, konuşma tanıma ile konuşma sentezi arasında durduğu için gecikmesi doğrudan arayanın duyduğu boşluğa eklenir. Pek çok sesli tasarım arama sürerken kısa bir onay cümlesi çalar; bu biraz zaman kazandırır, sınırsız zaman değil.
• Sohbet. İnsanlar ilk kelimeler görünmeden önce kısa bir beklemeye katlanır, sonra kesintisiz bir akış bekler. Arama, yanıt üretiminden önce çalışıyorsa gecikmesi ilk kelimeye kadar geçen beklemenin tamamıdır.
• Otomatik tamamlama ve anlık sonuçlar. İstekler tuş vuruşlarıyla tetiklenir; bir sonraki tuş vuruşundan sonra gelen yanıt boşa gitmiştir. Burada ham hız kadar istekleri iptal edebilmek de gerekir.
• Ajan döngüleri. Arayan, okuyan, sonra yeniden arayan bir ajan gecikmeyi her adımda öder. Çağrı başına makul bir gecikme, çağrılar art arda ve çok sayıda olduğunda uzun bir göreve dönüşür.

Gece çalışan araştırmalarda, zamanlanmış izlemede ve uzun raporlarda hız çok daha az önemlidir; orada derinlik ve kapsam kazanmalıdır. Tek bir özellik için gecikmeye göre yaptığınız seçimin her şeyin varsayılanı olmasına izin vermeyin. O işler için web arama API'si seçme rehberi daha doğru bir çerçevedir; ajan tarafını da yapay zekâ ajanları için arama aracı seçmek yazısı ele alıyor.

Gecikme bütçesini yazıya dökün

Sağlayıcıları karşılaştırmadan önce kullanıcının bekleyeceği toplam süreyi parçalara bölün. Aramaya bu sürenin tamamı değil, bir payı düşer. Kopyalayabileceğiniz bir şablon:

Bütçe sütununu istediğiniz deneyime göre, ölçüm sütunlarını kendi testlerinizden doldurun. Arama satırı tek başına yavaş kuyrukta bütçesini zaten aşıyorsa, başka yerlerde yapacağınız hiçbir ince ayar onu kurtarmaz. Kullanıcıların aklında tipik durum değil, yavaş kuyruk kalır.

Daha hızlı yanıtın genellikle bedeli

Düşük gecikme nadiren bedavadır. Hızlı yanıt veren yapılandırmalar bunu çoğu zaman sorgu başına daha az iş yaparak başarır. Sık görülen ödünler:

• İçerik yerine özet. Başlıklar ve kısa alıntılar, çekilip temizlenmiş sayfalardan daha hızlı döner; ama cılız özetler modele yanıtını dayandıracak daha az malzeme verir.
• Daha az sonuç, daha az yeniden sıralama. İkinci bir sıralama turunu atlamak zaman kazandırır, zor sorgularda ise alaka kaybettirir.
• Önceden hazırlanmış ya da daha küçük dizinler. Hazır bir dizinden yanıt vermek hızlıdır; aynı dizin daha eski de olabilir, uzun kuyruk ve İngilizce dışı sorgularda daha zayıf da kalabilir.
• Daha az sorgu yorumlama. Hızlı modlar, uzun ve konuşma diline yakın sorularda işe yarayan yeniden yazma ya da genişletme adımlarını atlayabilir.

Bazı sağlayıcılar aynı uç noktanın arkasında birkaç mod ya da derinlik seviyesi sunar. Bu gerçekten işe yarar: etkileşimli yolda hızlı mod, arka planda daha derin olanı. Her modun yalnızca adına değil, ne döndürdüğüne bakın ve ikisini aynı sorgularla çalıştırın. Yapay zekâ aramasında kapsama ve doğruluğu değerlendirmek rehberi, hızlı bir modun neyi dışarıda bıraktığını görmenize yardım eder.

Bayat yanıt sunmadan önbellek

En hızlı arama çağrısı hiç yapmadığınız çağrıdır. Önbellek, sorgular tekrarlandığında kazandırır; destek asistanlarında, otomatik tamamlamada ve ürün aramasında sorgular sanıldığından daha sık tekrarlanır.

• Anahtarı kurmadan önce normalleştirin. Küçük harfe çevirin, baştaki ve sondaki boşlukları kırpın, fazla boşlukları birleştirin ve filtreleri hep aynı sırayla yazın; böylece eşdeğer sorgular tek bir kaydı paylaşır.
• Süreyi sorgu sınıfına göre belirleyin. Başvuru ve dokümantasyon soruları daha uzun yaşayabilir; fiyatlar, haberler, stok durumu ve içinde bugün geçen her şey ya çabuk düşmeli ya da hiç önbelleğe alınmamalıdır.
• Benzerlik önbelleğine şüpheyle yaklaşın. Yalnızca benzer görünen bir sorgu için sonuçları yeniden kullanmak hızlıdır ve bazen yanlıştır: tek bir şirket adıyla ayrılan iki soru, ifade olarak yakın ama anlam olarak uzaktır.
• Koşulları kontrol edin. Bazı sağlayıcılar sonuçların ne kadar süre saklanabileceğini sınırlar. Önbellek politikanız sözleşmeye uymak zorundadır.
• Niyetin öngörülebildiği yerde önceden çekin. Kullanıcı bir şirket profilini açtığında, akla gelen ilk takip aramaları o sormadan başlayabilir.

Zaman aşımları ve yedek planlar

Bir gecikme hedefi, kaçırıldığında tanımlı bir şey oluyorsa gerçektir. Bu davranışa önceden karar verin:

1. Her çağrı için kesin bir zaman aşımı koyun. Süreyi bütçenizden türetin ve süre dolduğunda isteği iptal edin.
2. Yedek isteği dikkatli kullanın. İlk istek yavaşladığında yedek bir sağlayıcıya ikinci bir istek göndermek yavaş kuyruğu kısaltabilir; bedeli, bazı sorgular için iki kez ödemektir. Bunu etkileşimli yolla sınırlayın.
3. Açıkça geri çekilin. Yaşı gösterilen önbellekteki bir sonuca, daha dar bir kaynağa ya da güncel bilginin kontrol edilemediğini söyleyen bir yanıta düşün. Arama yapılmadan üretilmiş bir yanıtı asla kaynağa dayanıyormuş gibi sunmayın.
4. Zaman aşımını boş sonuçtan ayrı tutun. Aramanın bitmemesi ile aramanın hiçbir şey bulamaması farklı tepkiler gerektirir ve kayıtlarda farklı satırlara yazılmalıdır.

Son madde göründüğünden daha önemlidir. Zaman aşımını boş sonuç sanan bir ajan, bir şeyin var olmadığını kendinden emin biçimde bildirir.

Hızı kendi sorgularınızla ölçmek

• Kayıtlarınızdan gerçek sorgular alın ve sınıflara ayırın: kısa yönlendirme sorguları, konuşma diline yakın sorgular, uzun kuyruk, İngilizce dışı sorgular.
• Dizüstü bilgisayardan değil, uygulamanızın gerçekten çalıştığı sunuculardan ve bölgeden ölçün.
• Tipik ve yavaş kuyruk sürelerini, örneğin medyanı ve 95. ya da 99. persentili, ilk kez gelen ve tekrarlanan sorgular için ayrı ayrı kaydedin.
• Uçtan uca ölçün: arama artı varsa sayfa çekme ve yeniden sıralama, yanıt üretiminin başlayabildiği ana kadar.
• Zaman aşımlarını ve hataları eksik veri noktası değil, başarısızlık olarak sayın.
• Alakayı aynı çalıştırmada puanlayın. Hızlı ama yanlış yanıt yine de yanlıştır.
• Günün farklı saatlerinde tekrarlayın, çünkü sağlayıcı üzerindeki yük değişir.

Web aramayı kendi sorgularınızla değerlendirme rehberindeki yöntem alaka puanlamasını anlatıyor; bu sayfadaki süre sütunlarını ona ekleyin.

GoCux nerede durur

GoCux bir arama API'si değildir ve açık webi okumaz; bu yüzden etkileşimli arama yolunuz için bir aday değildir. O yolun çevresinde iki noktada işe yarar. Birincisi yukarıdaki ayrımdır. Bir projenin kendi dokümanları üzerinde çalışan GoCux Bilgi arama, boş sonucu geçerli bir yanıt sayar ve kullanılamıyor durumunu hiçbir şey bulunamadı durumundan ayrı bildirir. Uyarılar ve hatalar başvuru sayfası da kullanılamayan bir bağımlılığı kendi çözümü olan ayrı bir hata türü olarak ele alır. Yedek plan kodunuzun taklit etmesi gereken davranış budur.

İkincisi, hızlı bir yanıttan sonra ne olduğudur. Sesli ya da yazılı bir asistan dilediğiniz kadar hızlı bilgi arayabilir; ama mesaj göndermek ya da iş zamanlamak gibi bir şeyi değiştiren adım aynı hızlı yoldan geçmemelidir. Bir GoCux sohbetinde, bir şeyi değiştirecek araç çağrısı bir kişi karar verene kadar bekletilir; yani okumak ve harekete geçmek bilerek farklı hızlarda yürür. Gerekçeyi bir ajan neden harekete geçmeden önce sormalı notu açıklıyor.

Seçmeden önce kontrol listesi

• Hangi özelliklerin gecikmeye duyarlı olduğunu, hangilerinin olmadığını biliyorsunuz.
• Yazılı bir bütçe, toplam bekleme süresinden aramaya tanımlı bir pay ayırıyor.
• Tipik ve yavaş kuyruk sürelerini kendi sunucularınızdan, sorgu sınıfı bazında ölçtünüz.
• Alaka, süre ölçümleriyle aynı çalıştırmalarda puanlandı.
• Önbellek süresi sorgu sınıfına göre doluyor ve sağlayıcının saklama koşullarına uyuyor.
• Her çağrının bir zaman aşımı var ve süre dolduğunda kullanıcının ne gördüğünü biliyorsunuz.
• Zaman aşımları, hatalar ve boş sonuçlar ayrı kaydediliyor ve ayrı ele alınıyor.
• Sonuç doğuran eylemler, bilgi aramalarıyla aynı hızlı yolu paylaşmıyor.