Claude ile Research ve Web Search: Kaynaklı Araştırma ve Doğrulama

Sürüm notu: Bu yazı Claude'daki web search ve Research özelliklerini 15 Kasım 2026 itibarıyla anlatır; plan kuralları, ayarlar ve sınırlar aynı gün Claude Help Center'dan (support.claude.com) kontrol edilmiştir. Bu yazıda resmî belgelerden yararlanılmıştır. Anthropic yeni özellikleri hesaplara kademeli açtığı için anlatılanların bir kısmı senin hesabında henüz görünmeyebilir.

Önce Tahmin Et

Emre, sitedeki serilerin ortak örnek uygulaması Bookstore (bir online kitapçı) için Bookstore.Api'yi .NET 10'dan .NET 11'e taşımanın riskini çıkarmak istiyor. Claude'a Research ile "Bookstore'u etkileyecek .NET 11 breaking change'lerini listele" dedi. Birkaç dakika sonra on iki maddelik, her maddesinin yanında kaynak linki olan düzgün bir rapor geldi. Raporun son cümlesi "Bu liste .NET 11'deki tüm breaking change'leri kapsar." diyor. Emre'nin konuşmasında Selin'in Google Drive'ı da bağlıydı ve raporda ekibin geçen ayki geçiş notlarından bir alıntı var.

Üç soru: Rapordaki "tüm breaking change'ler" iddiasına güvenebilir misin? On iki linkten hangilerini açmadan kullanırsın? Claude, Research sırasında Drive'daki dokümanı okumadan önce Emre'ye sordu mu? Üçüncü sorunun cevabı Help Center'daki Research makalesinde; ilk ikisinin cevabını ise bu yazının sonunda kendin verebileceksin.

Web Search: Toggle Yok, Kararı Claude Veriyor

Birleşik deneyimde web search için açıp kapatacağın bir düğme yok. Help Center'ın "Enable and use web search" makalesi (https://support.claude.com/en/articles/10684626) ve "Claude Cowork and chat are one Claude" makalesi aynı şeyi söylüyor: Claude, web'de aramanın işe yarayacağını düşündüğünde kendisi arıyor. Eski deneyimdeki hesaplarda ise mesaj kutusunun solundaki "+" menüsünden "Web search" seçilip işaretleniyor. Team ve Enterprise'da önce organizasyon sahibinin (Owner ya da Primary Owner) özelliği Organization settings > Capabilities altında açması gerekiyor.

Makaleye göre web search kullanılan cevaplarda kaynağa doğrudan citation (cevaptaki iddiayı kaynağına bağlayan atıf), ek okuma için linkler ve yerinde olduğunda ilgili alıntılar yer alıyor. Mesajına bir URL koyarsan Claude o sayfanın içeriğini de çekebiliyor (web fetch). Görsel sonuçlar ayrı bir ayar istemeden geliyor ve her biri kaynak linkiyle gösteriliyor. Kullanım tarafında iki not var: web search ve web fetch usage limit'inden düşüyor; uzun bir makaleyi link üzerinden okutmak, özellikle Free planda limitin önemli bir kısmını harcayabiliyor.

Toggle olmamasının pratik sonucu şu: Claude'un aramasını ya da aramamasını istiyorsan bunu görev tarifine yazman gerekiyor. "Yalnız eklediğim dokümana göre cevap ver, web'de arama" ya da "cevabı vermeden önce resmî dokümantasyonda ara" gibi bir cümle, eski deneyimdeki düğmenin işini görüyor. Üçüncü yazıda konuştuğumuz "Claude tool'ları kendisi seçer" kuralının en görünür örneği bu.

Research: Ne Zaman ve Nasıl Başlatılır

Research, tek bir aramadan farklı çalışıyor. Help Center'ın "Use research on Claude" makalesine göre (https://support.claude.com/en/articles/11088861) Claude birbirinin üstüne kurulan birden çok arama yapıyor, bulduklarına göre bir sonraki adımını seçiyor ve sorunun farklı yönlerine bakıyor. Özellik ücretli planlarda var: Pro, Max, Ultra, Team ve Enterprise; web, Desktop ve mobil uygulamada çalışıyor. Birleşik deneyimde mesaj kutusuna /deep-research yazarak ya da "+" menüsünden "Research" seçerek başlatılıyor. Eski deneyimde Research seçilince mesaj kutusunun altında mavi bir gösterge çıkıyor ve Research'ün çalışması için web search'ün açık olması gerekiyor.

Makalenin iki ayrıntısı model ve limit konusunda önemli. Birincisi, Research konuşmada hangi modeli seçmiş olursan ol Claude Opus 5.5 ile çalışıyor, gerekirse Opus 4.8'e geçiyor. Team ve Enterprise'da bir rol için iki model de kapatılmışsa Research o rolde çalışmıyor. İkincisi, Research normal konuşmayla aynı limitlere tabi ama limiti daha hızlı tüketebiliyor. İkinci yazıda "küçük iş için küçük ayar" dedik; Research bu kuralın ters yönünde duruyor, bu yüzden onu gerçekten çok kaynak gerektiren sorulara sakla.

Ne zaman Research, ne zaman normal konuşma? Tek bir olguyu soruyorsan ("Entity Framework Core 10'un en son sürümü hangisi?") Claude'un gerektiğinde yaptığı tek arama yeterli. Birden çok kaynağı karşılaştırman, bir değişiklik listesini kendi sistemine uygulaman ya da bir konuda kapsamlı bir tablo çıkarman gerekiyorsa Research işe yarıyor. Aradaki sınırı belirleyen soru şu: cevap tek bir sayfada mı duruyor, yoksa birkaç sayfayı okuyup birleştirmek mi gerekiyor?

Research ve Connector'lar: İç Doküman ile Web'i Birleştirmek

Research yalnız web'de aramıyor. Aynı makaleye göre Google Workspace'i (Gmail, Google Calendar ve Google Docs) ve konuşmada açık olan diğer connector'ları da kullanabiliyor. Önce Tahmin Et'in üçüncü sorusunun cevabı burada: Research sırasında connector tool'ları her kullanımda onay istenmeden, otomatik çalışıyor. Emre'nin konuşmasında Drive açık olduğu için Claude geçiş notlarını sormadan okudu; bu beklenen davranış.

Bu davranışın bir sonucu var: Research başlatmadan önce konuşmada hangi connector'ların ve hangi tool'ların açık olduğuna bak. Help Center'ın custom connector makalesi, Research sırasında connector tool'larının ek onay olmadan çağrılabildiğini hatırlatıp yazma yetkisi olan tool'ları kapatmayı ve istek hacmini sınırlamayı öneriyor. Okuma tool'ları açık, yazma tool'ları kapalı bir Research, iç dokümanla web'i güvenle birleştirmenin en basit yolu. Connector'ları ve tool izinlerini sekizinci yazıda ayrıntılı göreceğiz.

Platform farkları da var. Mobilde başlatılan Research yalnız web'de arıyor ve connector'ları hiçbir hata göstermeden atlıyor; iç dokümanların da taranmasını istiyorsan Research'ü web'den ya da Desktop'tan başlat. Claude Desktop'ta tanımlanmış local MCP (Model Context Protocol; Claude'un dış araç ve veri kaynaklarına bağlandığı açık protokol) server'larının tool'ları Research'te kullanılamıyor.

İyi Bir Araştırma Tarifi

Research'e verilen tarif, üçüncü yazıdaki görev tarifinin aynı parçalarından oluşuyor ama iki parça daha ağır basıyor: kaynak kuralı ve çıktı formatı. İyi bir araştırma tarifi şunları söylüyor:

• Soru: tek cümle, cevaplanabilir biçimde; "geçiş hakkında bilgi" değil, "hangi değişiklikler bizi etkiler".
• Bağlam: sistemin hangi parçaları kullandığı; Claude etkiyi ancak bunu bilirse değerlendirebilir.
• Kapsam ve tarih: hangi sürüm, hangi tarih aralığı; preview dönemine ait kaynakların dışarıda kalması.
• Kaynak kuralı: hangi alan adlarının birincil sayıldığı, ikincil kaynağın nasıl işaretleneceği, kaynak bulunamazsa ne yapılacağı.
• Çıktı formatı: satır satır kontrol edilebilecek bir tablo, kontrol edilmeyen alanların listesi.

Son madde en çok atlanan madde. Düz metin bir rapor okunması kolay ama doğrulanması zor; her satırında tek bir iddia ve tek bir kaynak olan bir tablo ise ekip içinde paylaştırılarak kontrol edilebilir. "Kontrol etmediğin alanları listele" talebi de raporun kapsamını görünür yapıyor: Claude'un bakmadığı yeri bilmek, baktığı yeri bilmek kadar önemli.

Bookstore: .NET 11 Geçişini Araştırmak

.NET 11, 10 Kasım 2026'da GA (genel kullanıma açılan kararlı sürüm) olarak yayımlandı. Emre'nin isteğini doğrulanabilir bir tarife çevirelim:

Research question: Which breaking changes in .NET 11 can affect Bookstore.Api
when we move it from .NET 10 to .NET 11?

About Bookstore.Api: ASP.NET Core Web API, EF Core with SQL Server,
BackgroundService workers, appsettings.json plus environment variables,
DateOnly fields in Order and Shipment, Linux containers.

Scope and sources:
- Only changes that ship in .NET 11 GA (November 2026), not previews.
- Primary sources: learn.microsoft.com and github.com/dotnet. Mark any other
  source as secondary and never use it as the only source for a claim.
- If you cannot find a primary source for something, say so instead of guessing.

Output:
1) A table: change, area, type of change, affects Bookstore.Api (yes/no/maybe),
   why, primary source URL.
2) A list of areas you did not check.
3) Say whether the official list itself claims to be complete.

Bu tarife beklenen cevap, her satırı bir değişikliğe ve bir Microsoft Learn sayfasına bağlanan bir tablo, kontrol edilmeyen alanların kısa bir listesi ve resmî listenin tamlığı hakkında bir cümle. Üçüncü maddenin cevabını Microsoft'un sayfasından kendin de görebilirsin: "Breaking changes in .NET 11" sayfası (https://learn.microsoft.com/en-us/dotnet/core/compatibility/11, 15 Kasım 2026'da okundu, son güncellemesi 12 Kasım 2026) kendini hazırlığı süren ve tam olmayan bir liste olarak tanımlıyor ve ASP.NET Core değişikliklerini ayrı bir sayfaya bırakıyor. Yani Önce Tahmin Et'teki "tüm breaking change'leri kapsar" cümlesi, birincil kaynağın kendisiyle çelişiyor. Bu tek cümle, raporu Emre'nin olduğu gibi kullanamayacağını gösteriyor.

Sayfadaki maddelerin bazıları Bookstore.Api'nin anlattığımız yapısına doğrudan dokunuyor gibi görünüyor: örneğin Extensions altında bir BackgroundService hata verdiğinde IHost.RunAsync ve IHost.StopAsync'in exception fırlatması, zincirlenmiş configuration'da boş string'lerin önceki provider'ları ezmesi, Core .NET libraries altında DateOnly ve TimeOnly'nin TryParse method'larıyla ilgili bir davranış değişikliği. Burada dikkat edilecek nokta başlığın tek başına yetmemesi. Bir maddenin Bookstore'u etkileyip etkilemediğini, o maddenin ayrıntı sayfasında hangi koşulda ne değiştiği yazıyorsa anlarsın. Claude'un tablosundaki "etkiler" sütununu bu yüzden bir hüküm değil, bakılacak yerlerin listesi olarak oku.

İlk rapordan sonra ikinci bir mesajla belirli satırların dayanağını iste:

For rows 3, 5 and 8 of your table, quote the exact sentence from the primary
source that supports the row, with its URL and the page's last update date.
If the page does not say it, change the row to "not confirmed".

Bu mesaj Claude'u kendi iddiasını kaynağın kendi cümlesine bağlamaya zorluyor; dayanağı olmayan satırlar "not confirmed" olarak işaretleniyor. Sonra kontrolü sen yapıyorsun. Her satır için aynı beş soruyu sormak işini kolaylaştırır:

Aynı yöntem bookstore-web'in Angular sürüm geçişlerinde de işliyor; orada birincil kaynak angular.dev'deki Update Guide (https://angular.dev/update-guide), yani başlangıç ve hedef sürümü seçince yapılacak adımları listeleyen sayfa. Kontrol ettiğin tabloyu tarihiyle birlikte dördüncü yazıdaki teknik dokümantasyon project'ine koyarsan, ekip sonraki geçişte sıfırdan başlamaz.

Citation'ı Okumak

Citation bir kanıt değil, kanıtın adresi. Linkin varlığı, linkteki sayfanın iddiayı desteklediğini göstermez; model bir cümleyi yanlış sayfaya bağlayabilir, sayfanın eski bir sürümünü anlatabilir ya da iki kaynağı tek cümlede birleştirebilir. Halüsinasyonun genel mekaniği ve "kaynak göster, doğrula" alışkanlığı LLM Temelleri serisinin "LLM Halüsinasyonu ve Güvenilirlik: Kaynak Göster, Doğrula, Ölç" yazısında anlatılıyor; uzun dokümanlarda alıntı istemenin prompt tarafı Prompt Engineering Uygulamada serisinin "Uzun Doküman ve Context ile Çalışmak: Yerleşim, Alıntı İstemek, Bölmek ve Prompt Caching'e Uygun Sıralama" yazısında.

Claude'a özgü pratik olarak üç alışkanlık yeterli. Rakam, tarih ve sürüm içeren her iddianın kaynağını aç. Kaynağın kim tarafından ve ne zaman yazıldığına bak: bir ürünün resmî dokümanı, değişiklik notu ya da kaynak kodu birincil; aynı konuyu anlatan bir blog yazısı, ne kadar iyi olursa olsun ikincil. Birincil kaynakla ikincil kaynak çelişiyorsa birincili esas al ve çelişkiyi not et; bazen ikincil kaynak, birincil kaynağın sonradan güncellenmiş hâlini değil eski hâlini anlatıyordur.

Üretimde Dikkat

Web içeriği talimat taşıyabilir. Research, senin seçmediğin onlarca sayfayı okuyor; bunlardan birine gizlenmiş bir talimat, Claude'u raporu çarpıtmaya ya da açık bir connector'la bir şey yapmaya yönlendirmeye çalışabilir. Research sırasında connector tool'larının onaysız çalıştığını düşünürsen, yazma tool'larını kapatmak bu riski doğrudan azaltıyor. Konunun savunma tarafı LLM Uygulama Güvenliği serisinin "Prompt Injection'a Katmanlı Savunma: Direct, Indirect ve Multimodal Injection, Spotlighting ve Privilege Separation" yazısında.

Limit planlaması gerekiyor. Research limiti normal konuşmadan hızlı tüketiyor ve her zaman Opus sınıfı bir modelle çalışıyor. Ekipte herkesin aynı soruyu ayrı ayrı araştırması yerine tek bir araştırmayı yapıp kontrol edilmiş sonucu project'e koymak, hem limiti hem de kontrol emeğini paylaştırıyor.

Sonuç bir tarihe bağlı. Bir araştırma raporu, yapıldığı günün durumunu anlatır; Microsoft'un sayfası gibi kaynaklar da güncellenmeye devam ediyor. Raporu kaydederken araştırmanın tarihini ve kaynakların okunduğu günü yaz; geçiş birkaç hafta sürecekse kritik satırları geçişten hemen önce yeniden kontrol et.

Sık Düşülen Tuzaklar

Citation'ı okumadan kabul etmek. Linkin varlığı iddianın doğru olduğunu göstermez. En azından rakam, tarih ve sürüm içeren satırların kaynağını aç.

İkincil kaynağı birincil sanmak. Bir blog yazısı ya da forum cevabı ürünün resmî belgesi değildir. Tarifte birincil alan adlarını yazmak ve ikincil kaynakları işaretletmek bu hatayı görünür yapar.

Raporun tam olduğunu varsaymak. Claude'un "tüm değişiklikler bunlar" demesi, kaynağın kendisi tam olmadığını söylüyorsa bir anlam taşımaz. Kontrol edilmeyen alanların listesini her zaman iste.

Connector'lar açıkken düşünmeden Research başlatmak. Research sırasında tool'lar onay istemeden çalışıyor. Yazma tool'larını kapat, yalnız gereken connector'ları aç.

Her soruyu Research'e göndermek. Tek bir olgu için Research hem yavaş hem pahalı; Claude'un normal konuşmada yaptığı tek arama çoğu zaman yeterli.

Küçük Bir Deneme

★☆☆ Normal bir konuşmada, kullandığın bir paketin en son sürümünü sor; cevaptaki citation'ı aç ve sürüm numarasını paketin resmî sayfasıyla karşılaştır. Sonra aynı soruyu "web'de arama, yalnız bildiğini söyle" diye sor; iki cevap arasındaki farkı not et.

★★☆ Yazıdaki .NET 11 tarifini kendi projenin bağlamıyla doldurup Research ile çalıştır. Tablodan üç satır seç ve değerlendirme tablosundaki beş kontrolü uygula. Kaç satır "not confirmed" oldu, kaçının "etkiler" gerekçesi kodda karşılığını buldu?

★★★ Ekibin için bir araştırma şablonu yaz: soru, bağlam, kapsam, kaynak kuralı ve çıktı formatı bölümleri olsun. Şablonu iki farklı konuda (bir sürüm geçişi ve bir mevzuat değişikliği) dene ve hangi bölümün her seferinde değiştirilmesi gerektiğini belirle.

Research'ün connector'ları onaysız kullanabildiğini gördük. Sekizinci yazıda connector'ların kendisine geçiyoruz: Connectors Directory, tool izinleri, custom connector olarak kendi MCP server'ını eklemek ve Bookstore'un MCP server'ını yalnız okuma tool'larıyla Claude'a bağlamak.