Yapay zekâ için web arama API'si seçmek: kendi puanlama tablonuz

Yapay zekâ işleri için tek bir doğru web arama API'si yoktur. Sizin sorgularınız için işe yarar malzeme döndüren, koşullarıyla yaşayabileceğiniz ve bir ajan görev başına birkaç arama yapmaya başladığında da maliyeti anlamlı kalan API vardır. Yayımlanan karşılaştırmaların çoğu sağlayıcıları başkasının sorgularıyla sıralar. Bu rehber size bunun yerine bir yöntem veriyor: bir yapay zekâ uygulamasının aramadan ne beklediği, sağlayıcıların sonuçlarını hangi yollarla elde ettiği, güncellik, kullanım koşulları ve maliyet konusunda nelere bakılacağı ve kendi sorgu setinizle uygulayabileceğiniz bir puanlama tablosu.

Bir yapay zekâ uygulaması aramadan ne bekler

Sonuç sayfasına göz gezdiren bir insan boşlukları kendi muhakemesiyle doldurur. Sonuçları bir araç çağrısı üzerinden okuyan model bunu yapamaz; bu yüzden API'nin işin daha büyük kısmını baştan teslim etmesi gerekir. Bir yapay zekâ uygulaması beş şey bekler:

• Kullanıcılarınızın kurduğu biçimdeki sorgular için, bir ajanın yazdığı uzun ve konuşma diline yakın sorgular dâhil, alakalı URL'ler.
• Yalnızca başlık ve iki satırlık özet değil, modelin kullanabileceği metin. Cılız özetler, kaynağa dayanıyormuş gibi görünen ama dayanmayan yanıtların sık rastlanan bir nedenidir.
• Üst veri: yayın ya da güncelleme tarihi, alınma tarihi, dil ve alan adı; uygulama bunlarla filtreleyebilsin ve doğru atıf yapabilsin.
• Kontroller: alan adlarını dâhil etme ya da hariç tutma, tarih, bölge ve dil kısıtları.
• Araç çağrısı şemasına oturan ve haber verilmeden biçim değiştirmeyen kararlı, yapılandırılmış bir yanıt.

Klasik aramada olmayan bir bütçe boyutu da var. Modele verdiğiniz her sonuç bağlam penceresinden yer harcar. Her sorgu için on tam sayfa döndürmek pahalıdır ve çoğu zaman soruyu gerçekten yanıtlayan birkaç pasaj döndürmekten daha kötü sonuç verir. Ajanlar bu sorunu keskinleştirir; tek bir görev, ajan sorgusunu iyileştirdikçe çok sayıda arama yapabilir. Kavram size yeniyse web arama API'si nedir yazısıyla başlayın.

Sonuç türleri ve her birinin işe yaradığı yer

Karşılaştırmaya başlamadan önce uygulamanızın hangi sonuç türünü tükettiğine karar verin; yoksa bir sağlayıcının özet uç noktasını diğerinin içerik uç noktasıyla kıyaslamış olursunuz.

Kendi dizini, üst arama ya da SERP kazıma

Sonuçların nereden geldiği kapsamı, güncelliği, koşulları ve uzun vadeli riski belirler. Her sağlayıcıya bunlardan hangisi olduğunu sorun; karma bir yapı yaygındır ve bildiğiniz sürece sorun değildir.

• Kendi dizini. Sağlayıcı webi kendisi tarar ve kendi web dizinini oluşturur. Bu ona sıralama üzerinde kontrol ve sayfa içeriğine doğrudan erişim sağlar; ancak büyük ve genel bir dizini kurmak ve güncel tutmak pahalı olduğu için bunu yapan kuruluş azdır. Brave Search API ve Mojeek, bağımsız bir dizine dayanan arama API'lerine örnektir.
• Üst arama (metasearch). Servis sorgunuzu birkaç arama motoruna gönderir ve sonuçları birleştirir. Örneğin SearXNG, kendi sunucunuzda barındırabileceğiniz açık kaynaklı bir üst arama motorudur. Cazibesi genişliktir; riski ise kaynak aldığı motorlara ve onların koşullarına bağımlılıktır.
• SERP kazıma. Servis, büyük bir arama motorunun sonuç sayfasını çeker ve yapılandırılmış veri olarak döndürür. SerpApi ve Serper bu tür servislere örnektir. Sonuçlar insanların o motorda gördüğüne benzer; hangi koşulların geçerli olduğunu ve uygulanırlarsa riskin kimde kalacağını kontrol edin.
• Yapay zekâ uygulamaları için tasarlanmış arama. Exa ve Tavily gibi örnekleri olan daha yeni bir grup, çıktısını modellere göre biçimlendirir: pasajlar, sayfa içeriği, bazen de doğrudan yanıtlar. Aynı kaynak sorusunu onlara da sorun.

Hesaba katılması gereken bir risk daha var: bağımlı olduğunuz bir arama API'si geri çekilebilir ya da yeniden yapılandırılabilir. Uygulamanızla tek bir sağlayıcı arasında ince bir soyutlama katmanı tutun. Bağımlı olduğunuz bir arama API'sini değiştirmek yazısı bu durumu adım adım ele alıyor.

Güncelliğin iki saati var

"Güncel sonuç" iki ayrı şey demektir. Birinci saat, sayfanın kendisinin ne zaman değiştiğini gösterir. İkincisi, sağlayıcının sayfayı en son ne zaman çektiğini. Bu sabah güncellenen bir sayfa, dizin onu en son bir ay önce gördüyse uygulamanız için eskidir.

Üç soru sorun. API yayın tarihini mi, alınma tarihini mi, yoksa ikisini birden mi döndürüyor? Tarihe göre filtreleyebiliyor ya da sıralayabiliyor musunuz? Önem verdiğiniz sorgu türlerinde yeni sayfalar ne kadar çabuk görünüyor? Haberler, fiyat sayfaları ve dokümantasyon birbirinden çok farklı davranır.

Sonuncuyu doğrudan test edebilirsiniz. Doğru yanıtı webde yeni ortaya çıkmış birkaç sorgu toplayın: kendi ekibinizin yayımladığı bir sayfa, bir sürüm notu, yayın saati bilinen bir haber. Bunları art arda günlerde her adaya sorun ve her birinin yeni sayfayı ilk ne zaman döndürdüğünü not edin.

Kullanım koşulları ve maliyet modeli

Kullanım koşulları genellikle en son okunur, oysa en çok onlar önemlidir. Entegrasyonu kurmadan önce şunları kontrol edin:

• Sonuçları saklayabilir misiniz, ne kadar süreyle? Kullanıcılarınıza gösterebilir misiniz, hangi kaynak belirtimiyle?
• Sonuçlar ya da onlardan türetilen metinler bir modeli eğitmek veya ince ayar yapmak için kullanılabilir mi?
• Sorgularınız sağlayıcı tarafından kaydediliyor, saklanıyor ya da kullanılıyor mu? Bir ajanın yazdığı sorgular çoğu zaman müşteri adları ve şirket içi bağlam içerir.
• Sorgular nerede işleniyor; gerekirse bir veri işleme sözleşmesi yapılabiliyor mu?
• API değişmeden ya da kapanmadan önce ne kadar önceden haber alacaksınız?

Maliyette manşetteki rakamı değil, fiyatlandırma modelinin biçimini karşılaştırın. Sağlayıcılar sorgu başına, sonuç başına, çekilen sayfa başına, özellik kademesine göre ya da ön ödemeli kredilerle ücret alır; aynı iş yükü her modelde çok farklı tutarlara çıkabilir. Bir yapay zekâ uygulaması için anlamlı birim, tamamlanan görev başına maliyettir: ajanınız bir görevi bitirmek için genellikle birkaç arama ve birkaç sayfa çekimi yapıyorsa, fiyatlamanız gereken o bileşimdir.

Kendi uygulayacağınız puanlama tablosu

Sağlayıcıların kıyaslamaları sağlayıcının sorularını yanıtlar. Kendi değerlendirmeniz birkaç gün sürer ve sizin sorularınızı yanıtlar. Yöntem şöyle:

1. Sorgu setini gerçek trafikten kurun. Kayıtlardan, destek taleplerinden ya da ajan izlerinden 30 ile 50 arası sorgu alın. Yönlendirme amaçlı, olgusal, yeni gelişmelere dair, uzun kuyruk ve Türkçe gibi İngilizce dışı sorguları ve alanınızın jargonunu karıştırın.
2. Her sorgu için iyi sonucun neye benzediğini hiçbir şey çalıştırmadan önce yazın. Dürüst yanıtın "alakalı hiçbir şey yok" olduğu birkaç sorguyu da ekleyin.
3. Her adayı aynı parametrelerle çalıştırın ve ham yanıtları saklayın; böylece sonradan yeniden puanlayabilirsiniz.
4. Kör puanlayın. Alakayı puanlayan kişiden sağlayıcı adlarını gizleyin.
5. Çalıştırmayı başka bir gün tekrarlayın. Sonuçlar oynar; tek bir çalıştırma bunu gizler.

Ağırlıkları sonuçları görmeden önce belirleyin ve yanıtı boş olması gereken sorguları setten çıkarmayın: iyi bir yanıtı olmayan bir soruya kendinden emin biçimde bir şey döndüren sağlayıcı, bu özgüveni uygulamanıza da taşır. Puanlamanın ayrıntıları için web aramayı kendi sorgularınızla değerlendirme rehberine, inceleme tarafı için dokümantasyondaki aramayı değerlendirme sayfasına bakın.

GoCux nerede durur

GoCux bir web arama API'si değildir ve açık webi okumaz; bu yüzden puanlama tablonuzda bir aday olarak yer almaz. Bilgi arama, tek bir projenin kendi dokümanları içindeki soruları yanıtlar ve pasajları atıflarıyla birlikte döndürür. Boş sonucu geçerli bir yanıt sayar ve "servis kullanılamıyordu" durumunu "hiçbir şey bulunamadı" durumundan ayrı tutar; bu, rehberin her arama sağlayıcısından beklediği disiplinin aynısıdır.

Ajanınız bir web arama API'si kullanıyorsa GoCux'ın rolü onun sonrasındadır. Bir araştırma planı soruyu, sıralı adımları ve bir kaynak izin listesini içerir ve çalışmadan önce onaylanması gerekir; yürütme sırasında plan genişletilemez, boş bırakılmış bir izin listesi de hiçbir kaynağa izin vermez. Bir alıntıyla desteklenen bulgular, hiçbir kaynağın yanıtlamadığı sorulardan ayrı tutulur. İzin listesini kaynak politikası sayfası açıklıyor; araçları elinizdeki işe göre tekrarlanabilir biçimde tartmak için karşılaştırma sayfasına bakabilirsiniz.

Karar vermeden önce doğrulayın

• Her adayın kendi dizinini mi kullandığını, üst arama mı yaptığını, sonuç sayfası mı kazıdığını ya da bunları karıştırıp karıştırmadığını biliyorsunuz.
• Sağlayıcılar arasında aynı sonuç türünü karşılaştırdınız.
• Sorgu setiniz gerçek trafikten geldi, kör puanlandı ve birden fazla kez çalıştırıldı.
• Yanıtlarda tarihler dönüyor ve yeni sayfaların ne kadar çabuk göründüğünü test ettiniz.
• Koşullar saklama, gösterme ve varsa eğitim amaçlı kullanımınıza izin veriyor; sorgularınıza ne olduğunu biliyorsunuz.
• Tek bir sorguyu değil, tamamlanmış bir görevi fiyatladınız.
• İnce bir soyutlama katmanı, ajanı yeniden yazmadan sağlayıcı değiştirmenize imkân veriyor.
• Kodunuz boş sonucu ve kullanılamayan servisi birbirinden farklı ele alıyor.