İnsanlara iyi hizmet eden bir arama aracı, bir ajanı yine de yarı yolda bırakabilir. İnsan sonuç sayfasına göz gezdirir, birkaç sekme açar ve gereksizleri görmezden gelir. Ajan ise aracın döndürdüğü her şeyi bağlamına metin olarak alır; neye inanacağına ve sırada neyi çağıracağına karar verir ve bunu tek bir görevde defalarca yapar. Bu yüzden bir ajan için arama seçmek, ekranda hangi sonuçların daha iyi göründüğünden çok araçla ajanın döngüsü arasındaki sözleşmeyle ilgilidir. Bu rehber o sözleşmenin neleri içermesi gerektiğini, karşınıza çıkacak entegrasyon yollarını ve seçenekleri kendi görevlerinizde karşılaştırmak için bir kontrol listesini ele alıyor. Web arama sağlayıcılarının dizin, kullanım koşulları ve fiyat modeline göre daha geniş bir karşılaştırması için web arama API'si seçimi yazısına bakın.
Bir ajan aramayı gerçekte nasıl kullanır
Ajan döngüsünün içinde arama bir araç çağrısıdır. Model bir sorgu yazar, araç sonuçları döndürür, model bunları okur ve seçer: yanıt vermek, sorguyu iyileştirmek, bir sayfayı çekmek ya da başka bir araç çağırmak. Bunun dört sonucu var.
- Sorguları bir model yazar. İnsanların yazdıklarından daha uzun ve daha özgül olurlar, bazen de tuhaf kurulurlar. Aracın anahtar kelime dizilerinin yanında tam cümleli sorularla da başa çıkması gerekir.
- Dönen her şey okunur. Sonuçlar bağlamda yer kaplar ve bir sonraki adımı yönlendirir. Alakasız bir sonuç öylece atlanmaz; yanıltabilir.
- Arama tekrarlanır. Bir araştırma görevi, ajan konuyu daralttıkça çok sayıda sorgu gönderebilir; küçük gecikmeler ve maliyetler katlanır.
- Ajan yalnızca aracın çıkardığını görür. Yanıt bir tabloda, bir PDF'te ya da betiklerle oluşturulan bir sayfada duruyorsa, ajanın onu görüp görmeyeceğine aracın içerik çıkarma yeteneği karar verir.
Ajan tabanlı arama bu döngüyü ve çeşitlerini daha ayrıntılı anlatıyor.
Makinece okunur sonuçlar
Yanıt, ajanın çözmek zorunda kalacağı bir işaretleme değil, belgelenmiş ve kararlı bir şemaya sahip yapılandırılmış veri olmalıdır. Şu özelliklere bakın:
- Sonuç başına tutarlı alanlara sahip tek bir kayıt: başlık, URL, modele vereceğiniz metin ve tarihler.
- Kaynak metinle üretilmiş metin arasında net bir çizgi. Sağlayıcı bir özet ekliyorsa, bu özet sayfa içeriğine karıştırılmak yerine üretilmiş olarak etiketlenmelidir.
- Öngörülebilir boyut. Sonuç sayısı ve sonuç başına metin miktarı için parametreler, metni körlemesine kırpmak yerine bağlam bütçesini yönetmenizi sağlar.
- Veri olarak hatalar. Hız sınırı, zaman aşımı, engellenen sayfalar ve boş sonuçlar, kodunuzun ayrı ayrı ele alabileceği belgelenmiş durumlar olarak dönmelidir.
{
"query": "depo robotu güvenlik standardı revizyonu",
"status": "ok",
"results": [
{
"url": "https://example.org/standartlar/revizyon-notlari",
"title": "Standardın revizyon notları",
"published": null,
"retrieved": "çalıştırma anında atanır",
"passages": ["ajanın okuyacağı metnin kendisi"],
"generated_summary": null
}
]
}
Alan adları sağlayıcıdan sağlayıcıya değişir. Önemli olan, ajanın dayandığı her alanın bir adı olması ve eksik bir yayın tarihinin sessizce doldurulmak yerine eksik olarak gösterilebilmesidir.
Pasaj, tam sayfa ya da hazır yanıt
Ajanlar genellikle sorguya odaklı pasajlarla en iyi sonucu alır: bir iddiayı desteklemeye yetecek kadar metin, bağlamda akıl yürütmeye ve diğer araçlara yer bırakacak kadar az. Tam sayfa içeriği, ajanın yapılandırılmış veri çıkarması ya da uzun bir dokümanı dikkatle okuması gerektiğinde maliyetine değer. Sentezlenmiş yanıtlar hızlıdır ama ajanınızla kaynak arasına başka bir sistemin akıl yürütmesini koyar. Kullanıyorsanız alttaki kaynakları saklayın ve yanıtı bir olgu değil, bir ipucu olarak görün.
İyi işleyen bir desen iki aşamalıdır. Arama çok sayıda aday için pasaj döndürür, ajan önemli olan birkaçını seçer ve ayrı bir sayfa çekme ya da bilgi çıkarma aracı yalnızca onlar için tam içeriği getirir. Pahalı adım dar kalır, ajanın bağlamı da okunur olmaya devam eder.
Atıf ve köken bilgisi
Ajanınızın ürettiğine biri güvenecekse, her iddianın kaynağına giden bir yolu olmalıdır; bu yolun var olup olmadığına da arama aracı karar verir. Her sonucun kanonik bir URL, bir başlık ve tercihen ajanın gördüğü pasajın kendisini taşıdığını kontrol edin. Tarihlerin, sayfanın yayımlandığı ya da güncellendiği anı sağlayıcının onu çektiği andan ayırdığını da kontrol edin.
Ardından yalnızca aracı değil ajanı da kontrol edin. Bir model, sayfanın hiç söylemediği bir iddiaya gerçek bir URL iliştirebilir. Kaynağı açıp destekleyen cümleyi bularak örneklem kontrolü yapın. Bunun bir kısmı otomatikleştirilebilir: bir test, ajanın alıntıladığı her pasajın aracın döndürdüğü metinde gerçekten geçtiğini doğrulayabilir. İşe yarar bir atfın neye benzediğini ayakta kalan atıflar yazısı daha ayrıntılı anlatıyor.
İhtiyaç duyduğunuz yerde güncellik ve kapsam
Güncelliğin önemi her görevde aynı değildir. Fiyatlar, mevzuat, yazılım sürümleri ya da haberler hakkında soru yanıtlayan bir ajanın yeni sayfalara ihtiyacı vardır; yerleşik kavramları açıklayan bir ajanın çoğu zaman yoktur. Görevlerinizden hangilerinin zamana duyarlı olduğunu belirleyin ve yanıtı webde yakın zamanda ortaya çıkmış sorularla özellikle onları test edin.
Kapsam için de durum aynı. Kullanıcılarınız Türkçe soruyorsa, yerel şirketleri ya da niş bir teknik alanı soruyorsa, tam olarak bunu test edin. Genel İngilizce sorularda iyi iş çıkaran bir araç, ajanınızın gerçekte karşılaşacağı sorular hakkında size pek bir şey söylemez.
Araç çağrısına uyum
Aramanın ajanınıza nasıl ulaştığı, güvenilirliği en az sonuç kalitesi kadar etkiler.
| Entegrasyon yolu | Nasıl görünür | Kontrol edin |
|---|---|---|
| Araç olarak sarılmış doğrudan API | Araç şemasını siz yazarsınız ve sağlayıcının HTTP API'sini çağırırsınız | Şema yalnızca ajanın ihtiyaç duyduğu parametreleri açıyor mu, hatalar anlaşılır mesajlara dönüşüyor mu |
| SDK ya da çatı entegrasyonu | LangChain ya da Vercel AI SDK gibi bir çatı için hazır bir araç | Pasajları, tarihleri ve URL'leri koruyor mu, yoksa her şeyi tek bir metne mi düzleştiriyor |
| MCP sunucusu | Arama, Model Context Protocol üzerinden uyumlu her istemciye açılır | Beklediğiniz yerde, yerelde ya da uzakta mı çalışıyor; araç açıklamaları doğru mu |
| Bir model API'sine gömülü arama | Bazı model API'leri web aramayı barındırılan bir araç olarak sunar | Hangi kaynakların kullanıldığını görebiliyor ve alan adlarını kısıtlayabiliyor musunuz; arka ucu seçemeyebilirsiniz |
MCP yolu için web arama MCP sunucusu seçimi yazısına bakın. Hangi yolu seçerseniz seçin araç açıklamasını özenle yazın; model ne zaman arama yapacağına yalnızca bu metne bakarak karar verir. Aracın ne işe yaradığını, ne döndürdüğünü ve ne zaman kullanılmaması gerektiğini yazın; örneğin “kullanıcının kendi dosyalarıyla ilgili sorular için değil”.
GoCux nerede durur
GoCux bir arama API'si değildir; açık webi taramaz ve okumaz. Bu yüzden listenizdeki seçeneklerden biri değildir. Bilgi arama farklı bir derlem üzerinde çalışır: tek bir projenin dokümanları. Bir soru girer, pasajlar atıflarıyla birlikte geri gelir. Boş sonuç geçerli bir yanıt sayılır ve “kullanılamıyor” durumu “hiçbir şey bulunamadı” durumundan ayrı bildirilir; aşağıdaki kontrol listesinin her arama aracından beklediği ayrım da tam olarak budur.
GoCux, ajanın araçlarından biri olarak değil, araçlarının çevresinde işe yarar. MCP araçları sizin uyumlu istemcinizde çalışır, yapılandırdığınız bir sunucu bu yüzden her görevde kullanılabilir hâle gelmez ve başlamak için akıllıca yer salt okuma erişimidir; nedenini ajanlara salt okumayla başlayın yazısı açıklıyor. Bir alıntıyla desteklenen bulgular, hiçbir kaynağın yanıtlamadığı sorulardan ayrı tutulur; böylece inceleyici neyin desteklendiğini, neyin desteklenmediğini görebilir.
Kendi görevlerinizde yürüteceğiniz karşılaştırma
Genel kıyaslamalar aramayı yalıtılmış hâlde test eder. Sizin bilmeniz gereken, ajanınızın her seçenekle görevlerini doğru bitirip bitirmediğidir. Karşılaştırmayı uçtan uca yürütün:
- Ajanınızın üstlenmesi gereken 20 ile 40 arası gerçek görev seçin; doğru sonucun “bunu bulamadım” olduğu birkaç görevi de ekleyin.
- Hiçbir şey çalıştırmadan önce her görev için beklenen sonucu yazın.
- Yalnızca arama aracını değiştirin; modeli, istemi ve diğer araçları sabit tutun.
- Her görev için kaydedin: sonuç doğru mu, kaç arama çağrısı yapıldı, ne kadar token harcandı, ne kadar sürdü ve her atıf kendi iddiasını destekliyor mu.
- Sonuçların ne kadar kararlı olduğunu görmek için çalıştırmayı başka bir gün tekrarlayın.
Çalıştırmanın yanında her seçeneğe şu soruları sorun:
- Yanıt yapılandırılmış, belgelenmiş ve sürümler arasında kararlı mı?
- Sonuç sayısını ve sonuç başına metin uzunluğunu kontrol edebiliyor musunuz?
- Pasajlar dönüyor mu ve üretilmiş metin böyle etiketleniyor mu?
- Her sonuç bir URL ve yayın tarihini alınma tarihinden ayıran tarihler taşıyor mu?
- Boş sonuç, hata ve hız sınırı birbirinden ayrı durumlar mı?
- Dillerinizi, bölgelerinizi ve alanınızı kapsıyor mu?
- Alan kaybetmeden entegrasyon yolunuza oturuyor mu?
- Koşullar saklama ve gösterme biçiminize izin veriyor mu; ajanınızın gönderdiği sorgulara ne oluyor?
Erişim kalitesini daha titizlikle puanlamak için yapay zekâ aramasında geri çağırma ve doğruluğu değerlendirme yazısına ve dokümantasyondaki aramayı değerlendirme sayfasına bakın.
Bu iş akışını çalışma alanınıza taşıyın.
Kapsamı belirleyin. Kanıtları inceleyin. Gereken adımları onaylayın.