Ajan çatısında yerleşik arama aracı mı, kendi arama altyapınız mı?

Ajan çatıları aramayı giderek açıp kapatılan bir anahtar olarak sunuyor. Örneğin OpenAI'ın Responses API'sinde bir isteğe barındırılan bir web arama aracı ekleyebilirsiniz; sorgulamayı, sonuçları okumayı ve yanıta atıf eklemeyi platform üstlenir. Alternatif, kendi arka ucunuzu getirmektir: bir arama fonksiyonu tanımlarsınız, model onu çağırır ve aramayı seçtiğiniz bir sağlayıcıya ya da dizine karşı kendiniz çalıştırırsınız. İkisi de makul seçeneklerdir. Farkları şurada yatar: sorguyu ve sonuçları kim kontrol ediyor, ne tür atıflar geri geliyor, fatura nasıl şekilleniyor ve sistemi ne kadar kolay değerlendirebiliyorsunuz. Bu rehber bu farkları sırayla ele alıyor; böylece bilinçli bir seçim yapabilir ve ileride her şeyi yeniden yazmadan fikrinizi değiştirebilirsiniz.

Aynı yeteneğin iki biçimi

Yerleşik araç. Barındırılan arama aracını isteğin araçları arasında listelersiniz. Ne zaman arama yapılacağına model karar verir; platform sorguyu kendi arama entegrasyonunda çalıştırır, sonuçları modelin bağlamına koyar ve genellikle metin aralıklarını kaynak URL'lerine bağlayan notlarla birlikte bir yanıt döndürür. Platform açıkça sunmadıkça ham sonuçları kodunuz hiç görmez.

Kendi arka ucunuz. Adı, açıklaması ve parametre şeması olan bir fonksiyon aracı tanımlarsınız. Model arama yapmak istediğinde yanıtta argümanlarıyla birlikte bir fonksiyon çağrısı bulunur; kodunuz aramayı çalıştırır, sonuçları biçimlendirir ve o çağrının çıktısı olarak geri gönderir; ardından model devam eder. Responses tarzında böyle bir tanımın taslağı:

{
  "type": "function",
  "name": "search_sources",
  "description": "Onaylı kaynaklarda arar. Kimlik, URL ve tarih içeren pasajlar döndürür.",
  "parameters": {
    "type": "object",
    "properties": {
      "query": {"type": "string"},
      "recency_days": {"type": "integer"}
    },
    "required": ["query"]
  }
}

İkisinin arasında üçüncü bir yol da var: aramanızı, çatının çağırabileceği bir araç sunucusu olarak açmak; örneğin çatı destekliyorsa MCP üzerinden. İşletim açısından bu da kendi arka ucunuz gibi davranır, çünkü arka uç yine sizdedir. Çatınızın hangi araç türlerini kabul ettiğini güncel dokümantasyonundan kontrol edin; bu alan hızlı değişiyor.

Kontrol: neyin aranacağına ve döneceğine kim karar veriyor

Yerleşik araçla kolaylık karşılığında kontrolden vazgeçersiniz. Ona dayanmadan önce aracın neyi ayarlamanıza ve neyi görmenize izin verdiğini kontrol edin:

• Kaynak kısıtları. Alan adlarını sınırlayabilir ya da hariç tutabilir misiniz? Bölgeye veya dile göre kısıt koyabilir misiniz?
• Sorgu görünürlüğü. Modelin gerçekte gönderdiği sorguları görebiliyor musunuz? Onlar olmadan kötü bir yanıtın hatasını ayıklamak tahminden öteye geçmez.
• Sonuç görünürlüğü. Modelin okuduğu metne ulaşabiliyor musunuz, yoksa elinizde yalnızca son yanıt ve bağlantıları mı var?
• Özel veri. Barındırılan bir web araması şirket içi ağınıza, destek sisteminize ya da doküman deponuza ulaşamaz. İç malzeme gerektiren sorular zaten sizin çalıştırdığınız bir getirme katmanını ister.
• Veri işleme. Sorgular nerede işleniyor ve kaydediliyor, platformun veri politikası onlar hakkında ne diyor? Bir ajanın yazdığı sorgular çoğu zaman müşteri adları ve şirket içi bağlam içerir.

Kendi arka ucunuz bu takası tersine çevirir. Sağlayıcıyı, dizini, filtreleri, sıralamayı ve kaç pasaj döneceğini siz seçersiniz; her sorguyu ve sonucu kaydedersiniz; bir kaynak izin listesini ya da güncellik kuralını, modelin dolanamayacağı biçimde kodun içinde uygulayabilirsiniz. Hata biçimleri de sizindir: zaman aşımları, boş sonuçlar, sağlayıcı kesintileri ve şema kaymaları. Fonksiyonunuzun arkasındaki sağlayıcıyı seçmek için yapay zekâ ajanları için arama aracı seçimi yazısına bakın.

Atıflar: ne geri geliyor ve kontrol edilebiliyor mu

Yerleşik araçlar atıfları genellikle not olarak döndürür: bir URL, bir başlık ve desteklediği yanıt metninin karakter aralığı. Bunu ekranda göstermek kolaydır. Ona bağlanmadan önce üç soru sorun:

1. Atıf bir sayfayı mı, yoksa o sayfada iddiayı destekleyen pasajı mı gösteriyor?
2. Bir incelemecinin ya da otomatik bir kontrolün iddiayla kaynağı karşılaştırabilmesi için modelin gördüğü metni alabiliyor musunuz?
3. Okurun kanıtın ne kadar eski olduğunu bilmesi için alınma tarihi mevcut mu?

Kendi arka ucunuzda atıf tasarımı size kalır. Her pasaja kararlı bir kimlik verin, kimlikleri metinle birlikte döndürün, modelden her iddia için kimlik belirtmesini isteyin ve atıf yapılan her kimliğin bu soru için gerçekten döndürüldüğünü doğrulayın. Getirilen metnin kopyalarını da saklayabilirsiniz; yanıt yazıldıktan sonra canlı sayfa değiştiğinde bu önem kazanır. Bedeli mühendislik emeğidir; kazancı ise test edebileceğiniz atıflardır. Ayrıntılar için sohbet botlarında pasaj düzeyinde atıf yazısına bakın.

Maliyet modeli: çağrıyı değil görevi fiyatlayın

İki yaklaşım farklı biçimde faturalanır ve fark ancak bir ajan döngüye girdiğinde görünür olur.

• Yerleşik araç: Barındırılan araçlar çoğunlukla araç çağrısı başına ücretlendirilir; getirilen içerik de bağlama token ekler. Platformun eklediği sonuçlar uzun olabilir ve uzunluklarını doğrudan siz belirlemezsiniz. Arama çağrılarının ve getirilen içeriğin tam olarak nasıl sayıldığını çatının güncel fiyat sayfasından kontrol edin.
• Kendi arka ucunuz: Arama sağlayıcısına kendi modeline göre (sorgu, sonuç ya da çekilen sayfa başına veya kredilerle) ödeme yaparsınız; buna modele geri verdiğiniz her şeyin token'ları ile sistemi ayakta tutmak için gereken altyapı ve mühendislik eklenir. Kaç pasaj döndüreceğine siz karar verdiğiniz için bağlam maliyetini yanıt kalitesine karşı bilerek tartabilirsiniz.

Her iki durumda da önemli olan birim, tamamlanan görev başına maliyettir. Sorgusunu birkaç kez iyileştiren ve soru başına birkaç sayfa okuyan bir ajanın maliyeti, tek bir aramadan çok farklıdır. Bunu kendi iş yükünüzde ölçün ve görev başına araç çağrısı sayısına bir tavan koyun; böylece kafası karışan bir ajan durmadan arama yapamaz. Ajan harcamasına tavan koymak notu, görünür bir sınırın sürpriz bir faturadan neden iyi olduğunu açıklıyor.

Değerlendirme: hangi parçanın bozulduğunu anlayabiliyor musunuz

Arama ve üretim barındırılan bir aracın içinde birleştiğinde, kötü bir yanıtın iki olası nedeni vardır ve çoğu zaman bunları birbirinden ayıramazsınız. Arama zayıf malzeme mi döndürdü, yoksa model iyi malzemeyi mi yanlış okudu? Kendi arka ucunuz ikisini ayırır: getirmeyi kendi başına (doğru pasajlar geldi mi?) ve üretimi kendi başına (bu pasajlar verildiğinde yanıt doğru ve düzgün atıflı mı?) değerlendirebilirsiniz.

Bu karar için pratik bir değerlendirme:

1. Kullanıcılardan ya da ajan kayıtlarından 30 ile 50 arası gerçek soru toplayın; yeni olaylar, alan jargonu, Türkçe gibi İngilizce dışı sorgular ve iyi bir yanıtı olmayan birkaç soru da bulunsun.
2. Hiçbir şey çalıştırmadan önce doğru yanıtın ve kabul edilebilir kaynakların neye benzediğini yazın.
3. Her soruyu aynı istem ve modelle iki yapılandırmadan da geçirin ve izlerin tamamını saklayın: gönderilen sorgular, dönen sonuçlar, son yanıt, atıflar.
4. Yanıtları doğruluk, atıf desteği ve güncellik açısından kör puanlayın; görev başına maliyeti ve yanıt süresini kaydedin.
5. Başka bir gün tekrarlayın. Arama sonuçları oynar; tek bir çalıştırma bunu gizler.

Puanlamanın ayrıntıları için web aramayı kendi sorgularınızla değerlendirme ve yapay zekâ aramasında geri çağırma ve doğruluğu yargılama rehberlerine bakın.

Bir karar tablosu

Birçok ekip sonunda ikisini birden kullanır: açık uçlu, kamuya açık sorular için yerleşik aracı, iç ya da kısıtlı kaynaklar için kendi fonksiyonunu. Bu yolu seçerseniz yönlendirmeyi talimatlarda ve kayıtlarınızda açık hâle getirin; her yanıtı hangi yolun ürettiğini bilin.

GoCux nerede durur

GoCux ajan çatıları için bir arama arka ucu değildir ve açık webi okumaz; bu yüzden bu tabloda bir seçenek olarak yer almaz. Farklı bir noktada durur: altta hangi arama olursa olsun, ajanın yaptığı araştırmayı yönetir. GoCux'ta bir araştırma planı soruyu, sıralı adımları ve bir kaynak izin listesini belirtir ve çalışmadan önce bir kişi tarafından onaylanır; yürütme onaylananın ötesine geçemez, boş bırakılmış bir izin listesi de hiçbir kaynağı içeri almaz. İş emirleri çalışma süresi ve araç çağrısı sayısı gibi sınırlar taşır; sıfır araç çağrısı sınırı hiç araç çağrısı yapılmayacağı anlamına gelir. Bir alıntıyla desteklenen bulgular, hiçbir kaynağın yanıtlamadığı sorulardan ayrı tutulur. Arama arka uçlarını destekledikleri işe göre karşılaştırma sayfasına ve izin listesinin işleyişi için kaynak politikası sayfasına bakın.

Karar vermeden önce doğrulayın

• Çatınızın bugün hangi araç türlerini kabul ettiğini biliyorsunuz: barındırılan arama, fonksiyon araçları, harici araç sunucuları.
• Yerleşik aracın neyi kısıtlamanıza ve neyi görmenize izin verdiğini kontrol ettiniz: sorgular, sonuçlar, alınma tarihleri.
• Atıflar bir incelemecinin kontrol edebileceği bir şeye, ideal olarak yalnızca bir sayfaya değil bir pasaja işaret ediyor.
• Görev başına araç çağrısına bir tavan koyarak, kendi iş yükünüzde tamamlanmış bir görevi fiyatladınız.
• Aynı soru setini iki yapılandırmadan da geçirdiniz, kör puanladınız ve bunu birden fazla kez yaptınız.
• İç ya da kısıtlı kaynaklar sizin kontrol ettiğiniz bir getirme katmanından geçiyor.
• Arama, ajanı yeniden yazmadan değiştirebileceğiniz bir arayüzün arkasında duruyor.