ai-agent-book 精选快照（<2MB 代码与文档，来自 github.com/bojieli/ai-agent-book）

book-tr/reference-answers.tr.md

@@ -0,0 +1,408 @@
+# Düşünce Soruları — Örnek Cevaplar
+
+Bu dosya, kitabın on bölümündeki düşünce sorularına verilen örnek cevapların ana hatlarını bir araya getirir. Düşünce sorularının çoğu açık uçludur; tek bir doğru cevapları yoktur. Örnek cevaplar AI tarafından üretilmiş, insan eliyle hafifçe gözden geçirilmiştir ve yalnızca okurun karşılaştırma yapıp ilham alması içindir. Okurlara, bu soruları kitabın içeriğiyle birlikte bir LLM kullanarak daha ayrıntılı tartışmaları önerilir.
+
+## Bölüm 1: AI Agent'a Giriş
+
+**1. (★★) Bir Agent sistemine yalnızca tek bir yetenek ekleyebilseydiniz—daha güçlü bir model, daha zengin bir context, ya da daha fazla araç—hangisini seçerdiniz? Seçiminiz hangi koşullarda değişirdi?**
+
+> "Beyin/gözler/el ve ayaklar" formülüne göre önce zayıf halkayı bulun: genellikle önceliği context almalıdır, yani gözlem alanını (observation space) genişletmek. Görev modelin akıl yürütme kapasitesini aşıyorsa daha güçlü bir modele geçin. Eylem alanı yetersizse (örneğin şirketin iç sistemlerine erişim yoksa) araç ekleyin. Karar ölçütü, başarısız trajectory'leri analiz edip darboğazın algıda mı, karar almada mı, yoksa eylemde mi olduğunu saptamaktır.
+
+**2. (★★★) Bir ReAct döngüsünde toplam cache okuma miktarı, tur sayısıyla yaklaşık karesel olarak büyür. Bu büyüme nasıl azaltılabilir?**
+
+> i. turda okunan cache önekinin uzunluğu yaklaşık i ile orantılıdır; dolayısıyla toplam okuma miktarı 1 + 2 + ... + n = O(n²) olur. Karesel büyüyen, toplam cache okuma ücretidir; trajectory uzunluğu ve KV Cache kullanımı ise yaklaşık doğrusal büyür. Token eşiğine ulaşıldığında eski trajectory topluca sıkıştırılıp yalnızca sonuçlar ve kritik durum tutulabilir; büyük ara sonuçlar gerektiğinde getirilmek üzere dışarı alınabilir veya alt Agent'larda yalıtılabilir. Her turda sıkıştırma yapılmamalıdır: bu, Agent performansını düşürebilir ve ek sıkıştırma çağrıları ile cache yeniden oluşturma maliyeti getirir.
+
+**3. (★★) "Model as Agent" paradigması, modellerin tool calling kararlarında giderek daha otonom hale geldiği anlamına gelir. Ancak bu bölüm, Harness engineering'in öneminin aslında arttığını savunuyor. Bu iki eğilim nasıl bir arada var olabilir? Agent çerçevelerinin gelecekteki temel değeri nerede yatıyor?**
+
+> At ve dizgin benzetmesi: model ne kadar güçlüyse ve özerklik alanı ne kadar genişse, hatanın etki alanı da o kadar büyür; kısıtlamaya, doğrulamaya ve düzeltmeye o kadar çok ihtiyaç duyulur. Çerçevelerin değeri "LLM çağrılarını orkestre etmekten" Harness'in beş öğesi içindeki güvence katmanına kayar: izin sınıflandırması, circuit breaker, hata kurtarma, context sıkıştırma ve araç ekosistemi.
+
+**4. (★★) Ablation deneyinde, "araç sonucu geri bildiriminin" yokluğu Agent'ın sonsuz bir döngüye düşmesine neden oldu. Üretim ortamında, eksik araç sonuçlarının yanı sıra bir Agent'ın döngüye girmesine hangi başka durumlar neden olabilir? Hangi tespit ve sonlandırma mekanizmalarını tasarlardınız?**
+
+> Diğer tetikleyiciler: bir aracın aynı hatayı tekrar tekrar döndürmesi, var olmayan bir aracın halüsinasyonla çağrılması, context sıkıştırılırken kritik durumun kaybolması, düşünme sürecinin soyulması yüzünden model API'sinin hata vermesi ve görevin bizzat çözümsüz olması. Mekanizmalar: maksimum yineleme sayısı gibi durma koşulları belirleyin; yinelenen çağrıları tespit edin (aynı araç + parametre parmak izi); başarısızlık eşiği aşıldığında insan müdahalesine yükseltin.
+
+**5. (★) Bu bölüm beş Agent ürününü algı, eylem ve strateji olmak üzere üç boyutta analiz etti. Günlük kullandığınız bir yapay zeka ürününü seçin, aynı üç boyutta analiz edin ve mimarisinin mantıklı olup olmadığını değerlendirin. Siz tasarlıyor olsaydınız neyi iyileştirirdiniz?**
+
+> Açık uçlu soru. Ana hatlar: bölümdeki tabloyu örnek alarak gözleri (hangi bilgi kaynaklarını görebiliyor), el ve ayakları (eylem alanı açık uçlu mu, içeriden düşünebiliyor mu) ve stratejiyi (Agent'ın yürütme döngüsünün kalıbı) yazın.
+
+**6. (★★) Özellikle uçuş rezervasyonu için bir müşteri hizmetleri sistemi tasarlıyor olsaydınız, bir workflow kalıbı mı yoksa bir autonomous Agent kalıbı mı seçerdiniz? Aynı sistemde her iki kalıbı da karıştırmak mümkün müdür?**
+
+> Gövde için workflow: kimlik doğrulama → arama → ödeme → rezervasyon şeklinde dört düğüm. Bu, "ödeme yapılmadan rezervasyon yapılamaz" gibi uyumluluk sıralamalarını garanti eder ve prompt injection saldırı yüzeyini tek bir düğümle sınırlar. Açık uçlu adımlarda (ihtiyacı anlama, bilet değişikliği, uçuş iptalinde alternatif önerme) autonomous Agent'a geçin. Yüksek riskli işlemlere (yüksek tutarlı ödeme, iade) insan onayı ekleyin.
+
+**7. (★★★) Guardrail'ler bölümü araç risk derecelendirmesinden bahsetti. Bir araç genel olarak düşük riskli olup belirli parametre kombinasyonlarıyla yüksek riskli hale geliyorsa (örn. `delete_file`'ın normal bir dosyayı silmesi ile bir sistem dosyasını silmesi), dinamik risk değerlendirmesini nasıl tasarlardınız?**
+
+> Derecelendirmenin nesnesi "araç"tan "araç + parametre"ye incelir: risk, çağrı anında geri alınabilirliğe, izinlere ve etki alanına göre hesaplanır. Model yargısı yerine kural tabanlı deterministik kontroller kullanın (yol için kara/beyaz listeler, düzenli ifadeler). Doğrulama yalnızca yapılandırılmış veriye bakmalıdır; böylece prompt injection ile manipülasyon önlenir.
+
+**8. (★★) Bu bölümdeki Agent ürünleri tablosunda, tüm Agent'ların "açık uçlu" bir eylem alanı var. Hangi senaryolarda kısıtlı bir eylem alanı (örn. yalnızca önceden tanımlanmış seçenekler arasından seçim yapabilme), açık uçlu bir alandan üstün olurdu?**
+
+> Uyumluluğun ve riskin yüksek, hataların geri alınamaz olduğu senaryolar: iade ve ödeme gibi. Kısıtlı seçeneklerin kendisi bir "kısıtlamadır", doğal bir poka-yoke'dir; hatanın tasarım gereği oluşamamasını sağlar.
+
+**9. (★★) Human-in-the-loop müdahale mekanizması, Agent'ın "zarif bir şekilde kontrolü devretmesini" gerektirir. Ancak pratikte, kullanıcı çevrimdışı olabilir, yavaş yanıt verebilir veya belirsiz talimatlar verebilir. Agent bu tür durumlarda ne yapmalıdır?**
+
+> Fail-safe: yüksek riskli işlemler, onay yokken varsayılan olarak yürütülmek yerine duraklatılır; önce geri alınabilir, düşük riskli kısmı yapın, yüksek riskli kısmı ise belgeleyin — böylece insan karar verebilir, Agent da kaldığı yerden devam edebilir; asenkron iletişim araçlarıyla (mesaj, e-posta) haber verin ve bir zaman aşımı stratejisi belirleyin; talimat belirsizse niyeti netleştirin.
+
+**10. (★★★) Giriş bölümü "iyi tasarım ilkelerinin model yineleme döngülerini aşması gerektiğini" belirtiyor; ancak bu ilkeleri uygulayan somut mühendislik yöntemleri, model yetenekleri geliştikçe eskiyebilir. Böyle bir Agent mühendisliği yöntemine örnek verin ve nedenini açıklayın.**
+
+> Örnek 1: tool call'ları katı bir formata zorlamak için kısıtlı örnekleme kullanmak. Bu, sık sık geçersiz JSON üreten veya parametre atlayan modeller için bir güvenilirlik yamasıdır. Modellerin formata uyma yeteneği geliştikçe getirisi azalabilir; yine de yüksek riskli senaryolarda deterministik format doğrulaması korunmalıdır.
+>
+> Örnek 2: modelin yeni bilgiyi sürekli olarak özümseyememesini telafi etmek için harici bir bilgi tabanı eklemek. Modeller gelecekte güvenilir sürekli öğrenme yeteneği kazanırsa, bilgi bakımının bir bölümü harici sistemlerden model parametrelerine taşınabilir. Bununla birlikte harici bilgi tabanları gerçek zamanlı güncelleme, hassas bilgi erişimi, erişim kontrolü ve kaynak izlenebilirliği için bağımsız değer taşır; bu nedenle tamamen yok olmalarından çok kullanım alanlarının daralması beklenir.
+>
+> Örnek 3: bütün yeteneklerin model API'sinin standart tool calling arayüzü üzerinden sunulmasını zorunlu tutmak ve özel çağrı formatlarını yasaklamak. Skills başka bir yol gösterir: yeteneği ve kullanım yöntemini metinle açıklayıp modelin bunu genel amaçlı bir komut satırı aracıyla yürütmesini sağlamak. Model açısından bu, genel bir yürütücünün üstündeki özel bir metinsel çağrı protokolünü anlayıp izlemek demektir. Modeller keyfi arayüzleri daha iyi anladıkça "her zaman standart tool calling formatını kullan" evrensel bir ilke olmaktan çıkar. Standart formatlar birlikte çalışabilirlik, yapılandırılmış doğrulama ve daha zayıf modeller için hâlâ yararlıdır, ancak bağlama göre verilen bir mühendislik kararı olmalıdır.
+>
+> Örnek 4: prompt'ların ve tüm araç tanımlarının context'in başına önceden yerleştirilmesini zorunlu tutmak. Bu uygulama, ilk modellerin talimat izleme yeteneğinin sınırlı olmasından ve alışılmış sabit konumların dışındaki prompt veya araç tanımlarını çoğu zaman doğru tanıyıp yürütememesinden doğdu. Skills, prompt'ları çalışma sırasında gerektiğinde context'in ortasına yükler; dinamik araç keşfi ise yeni bulunan araç tanımlarını mevcut trajectory'nin sonuna ekler. Talimat izleme yeteneği geliştikçe ve modeller bu dinamik yükleme biçimleri için özel post-training aldıkça, prompt'ların ve araç tanımlarının context'in başına sabitlenmesi artık gerekmez.
+
+## Bölüm 2: Context Engineering
+
+**1. (★★★) Deney 2-3, konuşma geçmişinin kaydırmalı bir penceresinin Agent'ın aynı tool call'ları tekrar tekrar yürütmesine neden olduğunu buldu. Ancak, eksiksiz geçmişi tutmak context'in sınırsızca genişlemesine neden olur. KV Cache ön eğini bozmadan, bilgi kaybını önlerken context uzunluğunu kontrol edebilen bir strateji tasarlayın.**
+
+> ① Atmak yerine sıkıştırın: mesajlar yalnızca eklenir, hiç silinmez veya değiştirilmez; eşiğe yaklaşıldığında (örneğin pencerenin %80'i) eski araç sonuçları toplu olarak sıkıştırılır. ② Katmanlı mekanizma: büyük çıktılar diske yazılıp yerinde özet bırakılır, gürültü doğrudan silinir, arşiv niteliğindeki özetler ana hattı korur. ③ Alt Agent izolasyonu, böylece ara durum ana context'e hiç girmez.
+
+**2. (★★) Qwen3'ün Chat Template düşünce zinciri korunum mekanizması yalnızca "son gerçek kullanıcı mesajından sonraki" düşünmeyi korur. Bir ReAct döngüsü yüzlerce tool call'a yayılıyorsa, birikmiş düşünme içeriği büyük miktarda context tüketebilir. Çok uzun döngüleri ele almak için bu mekanizmayı nasıl değiştirirdiniz? DeepSeek'in stratejisiyle (tüm geçmiş düşünmeyi çıkarmak) artı ve eksileri karşılaştırın.**
+
+> Değişikliğin yönü: kaydırmalı pencereyle koruma — son birkaç turun düşünmesi eksiksiz tutulur; pencerenin dışı, sabit tur sayısına göre değil bir token bütçesine göre kayan sıkıştırmayı tetikler ve yapılandırılmış bir durum çubuğu (mevcut hedef, doğrulanmış olgular, elenmiş yollar, yapılacaklar) üretir. Sıkıştırma yalnızca bir kez ve sabit bir konumda gerçekleşir, böylece cache'in yeniden kurulma maliyeti her turda değil tek seferde ödenir. R1'in soyma yaklaşımı: token tasarrufu sağlar, ön ek kararlı kaldığı için cache dostudur ve eğitim dağılımıyla tutarlıdır (geçmiş CoT girdide hiç bulunmaz); ama her tur sıfırdan akıl yürütülür, uzun menzilli plan kaybolur ve aynı hatalar kolayca tekrarlanır. V4'ün zorunlu geri gönderimi: düşünce akışı tutarlı kalır, uzun menzilli agentic görevlerde performans daha iyidir; ama token maliyeti yüksektir, ön ek her turda şişer ve think dışı moddan kesintisiz geçiş yapılamaz. Tersine dönüşün gösterdiği şey şudur: saf sohbet senaryolarında düşünme bir atıktır, agentic senaryolarda ise durumun ta kendisidir — sektör pratiği ikincisine kaymıştır.
+
+**3. (★★) Bağlama duyarlı sıkıştırma deneyinde, yaklaşık 148K karakterden yaklaşık 2.000 karaktere sıkıştırma—bu aşırı sıkıştırma "geri döndürülemez bilgi kaybı" riski taşır mı? Bu nasıl ele alınabilir?**
+
+> Evet, risk var: sıkıştırma kayıplı bir izdüşümdür ve soru korunmamış bir boyuta düşerse iş bozulur. Çözüm, "kayıplı sıkıştırma + kayıpsız indeks"tir: her olgu, izi sürülebilsin diye kaynak URL'siyle birlikte taşınır; ham çıktı diske kaydedilir ve context'te yalnızca özet önizlemesi kalır; öncelikler açıkça korunur — mimari kararlar, anlamsal bütünlük (tarih, şirket adı), doğrulama durumu ve UUID/hash gibi tanımlayıcılar olduğu gibi saklanır; uyarlanabilir pencereleme ise sıkıştırma anını erteler.
+
+**4. (★★) Agent Durum Çubuğu örtük durumları açık hale getirir. Ancak, durum çubuğunun kendisi hatalı bilgi içeriyorsa (örn. araç sayacında bir hata), Agent yanlış bilgiye dayanarak zararlı kararlar alabilir. Bu "meta bilgi güvenilirliği" sorunu nasıl hafifletilebilir?**
+
+> Model durum çubuğuna neredeyse koşulsuz inanır, dolayısıyla hata olduğu gibi aktarılır. Hafifletme yolları: ① Durum çubuğunu deterministik kodla bakımlayın — uzun geçmişi toplu olarak saydırma işini asla LLM'e bırakmayın (mecbur kalırsanız tek tek çıkarım yaptırın, toplamayı kod yapsın). ② Durum çubuğunun doğruluk oranını birinci sınıf bir üretim metriği olarak izleyin. ③ Bilgi yalnızca gerçek dünyaya ilişkin güvenilir gözlemlerden gelsin; böylece durum çubuğunun zehirlenmesi önlenir.
+
+**5. (★★) Prompt engineering ablation deneyi, düzensiz bilginin başarı oranında %30'un üzerinde bir düşüşe yol açtığını gösteriyor. Ancak, gerçek dünya geliştirmesinde, system prompt'lar genellikle farklı zamanlarda birden fazla kişi tarafından bakımı yapılır. System prompt'ların "entropi artışını" önlemek için hangi mühendislik pratiklerini kullanırdınız?**
+
+> ① Prompt'u kod gibi ele alın: sürüm kontrolü ve inceleme; iş kurallarını ürün müdürü belirlesin, kodlamayı mühendis üstlensin. ② Tau-Bench türü benchmark'ları regresyon testi olarak kullanın; değişiklik öncesi ve sonrası ablation deneyleri çalıştırıp etkiyi saptayın. ③ Yapıyı zorunlu kılın: kural yığmak yerine SOP akışı güdümlü tasarım, XML/Markdown ile katmanlama. ④ Parçaları "cache'lenebilir / cache'i bozan" diye sınıflandırıp adlandırın, dinamik içeriği cache sınırının arkasına yerleştirin. ⑤ Şişen içeriği Skills'e ayırıp ihtiyaç oldukça yükleyin.
+
+**6. (★★★) Bu bölüm, "bağlam içi öğrenmenin özünde reasoning değil retrieval olduğunu" öne sürüyor. Bu iddia doğruysa, "context'e daha fazla bilgi tıkıştırma"ya dayanan mevcut tüm optimizasyon yönlerinin yeniden değerlendirilmesi gerekir. Bu sınırlamanın nasıl aşılması gerektiğini düşünüyorsunuz?**
+
+> "Yalnızca yarısı olan bu retrieval motoruna" bir damıtma katmanı ekleyin: ① context damıtma / durum çubuğu — sonuçları kodla önceden hesaplayıp doğrudan getirilebilir hale getirin; ② aktif sıkıştırma — ham kayıtları yüksek yoğunluklu, yapılandırılmış bilgiyle değiştirin; ③ alt Agent izolasyonu — gürültü ana context'e girmesin; ④ üçüncü eksen olarak etkileşim — dış araçların gözlemleri, modelin kendi başına düşünemeyeceği yeni bilgiyi geri yazsın; ⑤ öncü yönler: düzenlenebilir ve birleştirilebilir KV Cache "notları" ile oturumlar arası bellek birikimi.
+
+**7. (★★★) Skills'in kademeli açığa çıkarması, yalnızca Agent gerekli olduğuna karar verdiğinde eksiksiz içeriği yükler. Ancak, bu karar bizzat modelin yeteneğine dayanır—model neyi bilmediğini bilmiyorsa, bir Skill'in yüklenmesini doğru biçimde tetikleyemez. Bu "üst biliş (meta-cognition)" sorunu nasıl çözülebilir?**
+
+> ① Skill meta verileri (ad, açıklama) context'te sürekli bulunsun; böylece model her zaman "neye sahip olduğunu bilir". ② Skill'in description'ı bir işlev tanıtımı değil, bir yönlendirme koşulu olarak yazılsın — "Use when / Don't use when" — ve geniş, muğlak açıklamalardan kaçınılsın.
+
+**8. (★★) Skills mekanizmasında, Agent SKILL dosyasından prompt'u dinamik olarak okuduktan sonra, sonraki işlemler bu talimatları doğru biçimde izleyebilir mi? Modellerin Skills kalıbını desteklemesinde ne gibi farklılıklar var?**
+
+> Skill'in nasıl enjekte edildiğine bağlıdır: system prompt'a enjekte etmek en güçlü talimat izlemeyi verir ama KV Cache'i bozar; sıradan bir dosya olarak context'in ortasına okunduğunda modelin talimat izlemesi daha zayıf olabilir; context'in sonuna enjekte edildiğinde talimat izleme iyidir, ama her tool call'da skill kısmının KV'sinin yeniden hesaplanması gerekir ve bu maliyetlidir.
+
+**9. (★★★) Bu bölüm, dinamik bilgideki değişikliklerin (örn. sistem zaman damgaları, araç listesi sırası) KV Cache ön ek isabetlerini bozabileceğini vurguluyor. Çok sayıda araca ve sık sık değişen bir araç kümesine sahip bir üretim sisteminde, cache isabet oranını maksimize etmek için context düzenini nasıl tasarlardınız?**
+
+> ① Az sayıda kararlı çekirdek araç (örneğin yedi tane) artı genel amaçlı bir yürütücü; belirli yetenekler Skills'in kademeli açığa çıkarmasıyla gelsin, araç tanımları statik ön ekte sabit bir sırayla dondurulsun. ② Alt Agent'lar üst Agent'la aynı ön eki korusun.
+
+## Bölüm 3: Kullanıcı Belleği ve Bilgi Tabanı
+
+**1. (★★) Bir kullanıcı belleği sisteminde, aynı kullanıcı farklı oturumlarda çelişkili bilgi sağladığında (örn. iki farklı ev adresinden bahsetmek), bellek sistemi bu çelişkiyi nasıl ele almalıdır?**
+
+> Mem0 tarzı bir "çıkarım — karşılaştırma — karar" boru hattı kullanın: önce vektör aramasıyla benzer eski bellek kayıtlarını getirin, ardından ADD/UPDATE/DELETE/NOOP kararını bir LLM'e verdirin — örneğin "Şanghay'a taşındı" kaydı, "Pekin'de yaşıyor" kaydını UPDATE ile üzerine yazmalıdır. Sürümleme: adres türü bilgide yalnızca en güncel sürüm zaman damgasıyla tutulur, iş deneyimi türü bilgide ise geçmişin tamamı saklanır. Getirme tarafında context ön eki (kişi, zaman, niyet — üç kez değiştirilen para transferi vakasında olduğu gibi) hangi kaydın nihayetinde geçerli olduğunu belirlemeye yardımcı olabilir.
+
+**2. (★★) Contextual Retrieval, orijinal dokümandan gelen bağlamı her chunk'a ekler. Ancak, orijinal dokümanın kendisi yapısal olarak dağınıksa veya çelişkili bilgi içeriyorsa, bu yöntem hataları yayabilir hatta büyütebilir. Retrieval aşamasında bir "bilgi kalitesi" sinyalini nasıl tanıtırdınız?**
+
+> "Bilgi tabanının güncelliği ve yönetişimi" bölümünden yararlanın: chunk'lara sürüm numarası, yürürlük/geçerlilik bitiş zamanı ve kaynak gibi meta veriler ekleyin; retrieval sırasında geçerliliğini yitirmiş içeriği filtreleyin ya da ön ekte "bu kayıt şu tarihte yürürlükten kalktı" diye açıkça belirtin. Reranking aşamasında yalnızca anlamsal benzerliğe bakmak yerine kaynağın otoritesini ve zamansal tazeliği de puana katın. İndeksleme sırasında, ön eki üreten LLM'e chunk'lar arasındaki çelişkileri de tespit ettirip işaretletin — belleğin sürümlü çelişki tespitine benzer biçimde.
+
+**3. (★★) Çok modlu bilgi çıkarımı, retrieval'dan önce grafikleri metin açıklamalarına dönüştürür. Bu "çeviri" süreci, görsel bilgideki mekânsal ilişkileri kaybedebilir. Salt metin açıklamasının tam olarak aktaramayacağı belirli bir grafik bilgisi örneği verin ve o bilgiyi korumak için bir şema tasarlayın.**
+
+> Örnekler: bir sistem mimarisi diyagramındaki mantıksal ilişkiler, bir çizgi grafiğinde iki eğrinin kesişim noktasının konumu ya da bir PDF tablosunda hücrelerin başlıklarla satır-sütun karşılığı. Birinci çözüm: yerel (native) multimodal işleme. İkinci çözüm: multimodal bir görüntü analizi aracı sağlamak.
+
+**4. (★★★) Rich Sutton'ın "Acı Ders"i, genel yöntemlerin (arama ve öğrenme) nihayetinde elle hazırlanmış özelliklerden daha iyi performans göstereceğini savunur. Bu bölümde inşa edilen tüm bilgi sistemi (chunking stratejileri, indeks yapıları, retrieval boru hatları) kendisi bir "elle hazırlanmış tasarım" biçimi midir? Model yetenekleri yeterince güçlü hale gelirse, bu tasarımlar basitçe "her şeyi girdi olarak vermekle" değiştirilebilir mi?**
+
+> Evet, bu bir elle tasarımdır ve bazı adımlar (chunking, füzyon parametrelerinin ayarı) context uzadıkça zayıflayabilir. Ama siyah kedi / beyaz kedi vakası "her şeyi girdi olarak vermenin" de yetmediğini gösteriyor: attention yumuşak bir retrieval'dır ve dokümanlar arası toplama ile istatistik hâlâ indeksleme sırasında ön damıtma ister. Bilginin eskiyip güncellenmesi, izin/kiracı izolasyonu, denetlenebilirlik ve maliyet gibi mühendislik kısıtları model yeteneğinden bağımsızdır. Üstelik retrieval ile indeksleme sırasındaki LLM damıtması bizzat "arama + öğrenme" türünden genel yöntemlerdir; Acı Ders'e karşıt değildir.
+
+**5. (★★★) Model yetenekleri iyileştikçe, alana özgü bilgi tabanlarının hâlâ önemli olacağını düşünüyor musunuz? Gelecekteki güçlü bir temel model, bir alan bilgi tabanındaki tüm bilgiyi potansiyel olarak içerebilir mi, böylece buna olan ihtiyacı ortadan kaldırabilir mi?**
+
+> Hâlâ önemli: eğitim verisinin bir kesim tarihi vardır, oysa bilgi tabanı her an güncellenebilir; şirket içi süreçler, özel emsal kararlar ve benzerleri kamuya açık derlemde zaten yoktur; çok kullanıcılı paylaşım izin filtrelemesi ve kiracı izolasyonu gerektirir, parametrelerdeki bilgi ise çağırana göre kırpılamaz; dış depolama denetlenebilir, sürümlenebilir ve geçerliliğini yitiren içerik yayından kaldırılabilir — parametrik bellek bunu güçlükle yapar; parametrik yola gidilse bile (post-training / User as Engram), "ezberlemek kolay, ama bu olguları çok atlamalı akıl yürütmede kullanmak zor" sorunuyla karşılaşılır.
+
+**6. (★) RAPTOR, aşağıdan yukarıya hiyerarşik özetleme yoluyla bir ağaç indeksi inşa ederken, GraphRAG varlık ilişkileri yoluyla graf yapılı bir indeks inşa eder. Bu iki yapılandırılmış indeks, her biri hangi tür sorguları yanıtlamada iyidir?**
+
+> RAPTOR: makro kavramlardan ayrıntılara doğru kademeli inen "katmanlar arası gezinme" tipi sorgular — örneğin önce "SIMD komut kümesi" özetini bulup sonra SSE ayrıntılarına inmek gibi; hem genel görünüm hem ayrıntı granülaritesini birlikte karşılar. GraphRAG: çok atlamalı ilişki akıl yürütmesi ("doktorumun çalıştığı hastanenin adresi" sorusunda ilişki zinciri boyunca gezinmek) ve varlık ayrıştırma (iki ayrı "Doktor Zhang" farklı düğümlerdir) gibi "A ile B arasında ne ilişki var" türü sorgular; topluluk özetleri ayrıca tema kümelemesi de sağlar.
+
+**7. (★★) Dosya sistemi paradigması, bilgiyi bir dosya sistemine benzer hiyerarşik bir yapıya organize eder. Geleneksel vektör veritabanı RAG'ına kıyasla, bu yaklaşım hangi senaryolarda avantajlıdır?**
+
+> Düz metin kullanıcı tarafından doğrudan okunabilir, düzenlenebilir ve düzeltilebilir; Git ile sürüm kontrolüne alınıp geri alınabilir — bilginin insanla makine tarafından birlikte bakımlandığı ve incelendiği senaryolara uygundur. Agent'ın write_file yeteneği olması, deneyimi otonom olarak kaydetmesine ve kendi kendini geliştiren bir bellek döngüsü (externalized learning) kurmasına yeter. L0/L1/L2 kademeli açığa çıkarma sayesinde sorguların çoğu L1'de karara bağlanır, bu da token tasarrufu sağlar. Ön koşul, Wikipedia gibi çapraz bağlantılar ve indeks sayfaları kurmaktır; yoksa yalıtık dosya sayısı arttıkça retrieval zorlaşır.
+
+**8. (★★★) Yapılandırılmış veriden (örn. hukuki karar veritabanları) "karar faktörlerini" ve "faktör önem hiyerarşilerini" otomatik olarak keşfetmek, özünde Agent'ın veriden kural çıkarsamasını içerir. Bu veri odaklı bilgi çıkarımı, insan uzmanlar tarafından elle hazırlanan kuralların kalitesine ulaşabilir mi?**
+
+> Avantajları: CAIL2018 deneyinde olduğu gibi "aşağıdan yukarıya" faktör keşfi, insan ön kabullerine değil veriye uyar; on binlerce karara dağılmış, uzmanların açıkça yazıya dökmekte zorlandığı örtük ödünleşim deneyimini yakalayabilir ve ölçülebilir. Sınırları: LLM çıkarımındaki hatalar bilgi kirliliğine yol açar; verinin kendi yanlılığı miras alınır; kümeleme prototipleri yalnızca korelasyonu yansıtır, nedenselliği açıklayamaz. Orta yol: veri güdümlü modelleme artı şemanın ve sonuçların uzman tarafından incelenmesi — soruları model sorar, açıklamaları istatistik destekler.
+
+**9. (★★★) Markdown tabanlı bir kullanıcı belleği kütüphanesi için hem artımlı güncelleme hem dönemsel düzenleme akışları tasarlayın. Reviewer ve Proposer aynı modeli kullanır ve yalnızca Proposer'ın seçtiği konuşma parçalarını görürse hangi hatalar yine de birleştirilebilir? Model bağımsızlığı, kanıt kapsamı ve araç izinleri açısından iyileştirmeleri açıklayın.**
+
+> Artımlı güncelleme: bellek kütüphanesini bir kod deposu gibi ele alın ve her değişikliği bir PR'dan geçirin. Proposer önce ilgili mevcut bilgiyi arar, ardından olabildiğince küçük ama eksiksiz bir diff önerir; bağlantıları, dizinleri, zaman meta verilerini ve kanıt referanslarını da birlikte günceller. Reviewer, değişiklik öncesi bilgi, diff ve ham kanıtla bağımsız denetim yapar; geri çevirirken belirli kanıtlara ve satır numaralarına işaret eden uygulanabilir görüşler döndürür. Yinelemeye azami sayı ya da maliyet bütçesi konur; aşılırsa varsayılan olarak onaylanmaz, insana yükseltilir. Birleştirmeden sonra CI önce biçimi, bağlantıları, meta veriyi ve izin etiketlerini denetler; ancak ondan sonra birleştirilmiş sürümden etkilenen parçalar ve vektör dizinleri artımlı olarak yeniden kurulur. Düzenli toparlama: zamana veya yeni girdi sayısına göre tam tarama tetiklenir; yinelenenler ayıklanır, birleştirilir, aşırı büyüyen dosyalar bölünür ve giriş sayfaları yeniden kurulur. Asıl önemli olan, özgün konuşmalara paragraf paragraf dönüp eski özetlerin bir olumsuzlama, zaman koşulu ya da sınırlayıcı ifadeyi düşürüp düşürmediğini denetlemektir. Çelişen ifadeler "en yenisini tut" ile kapatılmamalı; her biri kaynağına kadar izlenip hangi koşulda geçerli olduğu yazılmalıdır. Kanıt yetersizse çelişki korunur ve doğrulanmamış olarak işaretlenir. Yeniden düzenleme de PR olarak sunulur, gerekirse dizin bazında bölünür; hepsi geçtikten sonra dizini yeniden kurmanın yanı sıra tipik bir dizi arama senaryosu tekrar oynatılıp, eskiden bulunabilen bilginin görünmez hale gelmediği doğrulanır.
+>
+> Aynı model ile önceden seçilmiş parçalar üç tür hatayı kaçırır. **Model bağımsızlığı**: aynı aileden modeller eğitim önselini ve kör noktalarını paylaşır; Reviewer kanıta dönmek yerine Proposer'ın sonucunu tekrarlamaya eğilimlidir ve ortak bir yanlış okuma fark edilmez — çapraz denetim için benzer yetkinlikte ama farklı aileden bir model kullanın. **Kanıt kapsamı**: yalnızca Proposer'ın seçtiği parçalarla; bağlamdan kopmuş alıntılar, atılmış olumsuzlamalar ve ön koşullar ile diğer dosyalarla çelişkiler görünmez kalır — Reviewer, yetkilendirildiği kiracı veya kullanıcı kapsamı içinde tüm bilgi tabanını ve ham kanıt deposunu kendi başına sorgulayabilmelidir. **Araç izinleri**: Proposer ana dala doğrudan yazabiliyor ya da canlı dizini değiştirebiliyorsa denetim göstermeliktir — iş bölümünü zorunlu kılın: Proposer yalnızca çalışma dalına yazar, Reviewer yalnızca kanıt okur ve kararını sunar, ana dalı ve canlı dizini yalnızca birleştirme hattı günceller; doğrulayıcılar ve yayın kapıları ise değiştirilebilir kapsamın dışında kalır.
+
+## Bölüm 4: Araçlar
+
+**1. (★★) MCP standardı, araç tanımlarını Agent çerçevesinden ayırır. Ancak, standartlaştırma aynı zamanda karmaşık araç etkileşim kalıplarının (örn. akış çıktısı, çift yönlü iletişim, durumlu oturumlar) standart bir protokol içinde ifade edilmesinin zor olabileceği anlamına da gelir. MCP'nin gelecekte en çok hangi yeteneği genişletmesi gerektiğini düşünüyorsunuz?**
+
+> En çok gereken genişletme, oturumlar arası olay güdümlü yetenektir. MCP çok turlu etkileşimleri, değişiklik aboneliklerini ve uzun süren görevleri zaten destekler; ancak özü Agent'ı sürekli çevrimiçi tutmak değil, bir yetenek çağrısını standartlaştırmaktır. Yeni e-posta veya dış geri çağrı için Agent'ı uyandırmak; birden çok olayı sıraya almak, sürdürmek ve yeniden denemek hâlâ Agent çerçevesinin sorumluluğundadır. Bu orkestrasyon için daha birleşik kurallar, protokolün sadeliğinden ödün vermeden MCP'nin kapsamını genişletebilir.
+
+**2. (★★) MCP ekosisteminde, farklı MCP sunucuları yüksek oranda örtüşen işlevselliğe sahip araçlar sağlayabilir. Bir Agent, işlevsel olarak benzer farklı kaynaklardan birden fazla araçla karşılaştığında, nasıl seçim yapmalıdır? Farklı kaynaklardan aynı ada sahip araçlar biraz farklı davranırsa (örn. biri özet döndürür, diğeri tam metin döndürür), Agent bu farkı algılayıp kullanabilir mi?**
+
+> Seçim ölçütleri: entegrasyondan önce açıklamaları inceleyin, sürümleri sabitleyin ve en az ayrıcalıklı kimlik bilgileriyle yapılandırın; aynı adlı araçların gölgelemesine (tool shadowing) karşı dikkatli olun, çünkü hassas çağrılar kötü niyetli bir tarafa yönlendirilebilir. Çalışma zamanında adayları hiyerarşik sınıflandırma ve dinamik keşifle daraltın. Modelin davranış farkını algılayıp algılayamayacağı ise araç açıklamalarının kalitesine bağlıdır.
+
+**3. (★★) Bu bölüm bir "yürüt-doğrula-geri bildir" döngüsü önerir (örn. kod yazdıktan sonra otomatik olarak bir linter çalıştırmak). Bu "işlem sonrası anında otomatik doğrulama" kalıbı başka hangi araç senaryolarına uygulanabilir? Doğrulamanın kendisinin maliyetinin veya riskinin işlemin kendisininkini aştığı, bu kalıbı uygulanamaz kılan işlemler var mı?**
+
+> Genellenebilir senaryolar: yapılandırma değiştirildikten sonra sandbox'ta gerçekten çalıştırıp etkili olup olmadığını doğrulamak; doküman veya sunum üretildikten sonra ekran görüntüsüne render edip modelin multimodal yeteneğiyle sayfa düzenini denetlemek. Uygulanamaz olanlar: e-posta göndermek, telefon açmak, dışarıya para transfer etmek gibi geri alınamaz ve idempotent olmayan işlemler — ya gözlemlenecek bir şey yoktur ya da doğrulamanın kendisi gerçek dünyada yeni bir olayı tetikler. Burada önlem, olay öncesine kaymalıdır: Proposer-Reviewer ile ön onay.
+
+**4. (★★) Bu bölüm "araç patlaması" sorununu gündeme getiriyor—bir Agent'ın seçim doğruluğu binlerce araçla karşılaştığında kötüleşiyor. Proaktif araç keşfinin yanı sıra, başka hangi yaklaşımlar var? İnsan uzmanların devasa bir mevcut araçlar koleksiyonuyla nasıl başa çıktığından yararlanmayı düşünün.**
+
+> ① Hiyerarşik gruplama: önce "sunucu/uygulama" bulunur, sonra belirli araç seçilir. ② Skills tarzı "gerektiğinde başvurma": bir başvuru kitabına bakar gibi — dizin context'te sürekli durur, ayrıntılar ihtiyaç oldukça yüklenir. ③ Sık kullanılan az sayıda temel araç "elinizin altında", yani context'te sürekli bulunur; gerisine dizin indeksi üzerinden ulaşılır.
+
+## Bölüm 5: Kodlama Agent'ı ve Kod Üretimi
+
+**1. (★★) Kod üretimi bir Agent'ın "meta-yeteneği" olarak adlandırılır. Ancak, kod yürütme güvenlik riskleri getirir—Agent tarafından üretilen kod açıklar, sonsuz döngüler veya kaynak tükenmesi içerebilir. Sandbox izolasyonu bazı sorunları çözebilir ama aynı zamanda kod yeteneklerini de sınırlar (örn. ağa veya dosya sistemine erişememe). Güvenlik ile yetenek arasında optimal dengeyi nasıl bulabiliriz?**
+
+> Sandbox izolasyonunu senaryoya göre kademelendirin (container/microVM); ağ varsayılan olarak kapalı olsun, beyaz listeli bir proxy ihtiyaç oldukça geçit versin; kaynak kodu salt okunur bağlayın ve API key'leri sandbox'ın içinde tutmayın; sandbox'a kaynak kotası koyun; sandbox yaşam döngüsünü yönetin (zaman aşımı).
+
+**2. (★★★) Agent bootstrapping—Agent'lar yaratabilen bir Agent—"zekanın kendi kendini çoğaltmasını" başarır. Ama her bootstrapping yinelemesi yeni önyargılar veya hatalar getirebilir. Bu hatalar nesiller boyunca birikir mi? Bootstrap edilmiş Agent'ların kötüleşmesini nasıl önleyebiliriz?**
+
+> Her nesil bir öncekinin ürünleri üzerinde üremeye devam ederse bazı kusurlar birikebilir. Kilit nokta, yeterince zorlayıcı verifiable task'lara (doğrulanabilir görevlere) sahip olmaktır; örneğin yeterince zor programlama görevlerine.
+
+**3. (★★) Bir kod üretim Agent'ı log ayrıştırmayı ele aldığında, format evrimini otomatik olarak takip edebilir. Ama bir format değişikliği kasıtlı bir değişiklik değil bir hataysa, Agent'ın uyum sağlayabilirliği aslında sorunu maskeler. Bir Agent "uyum gerektiren değişiklikler" ile "bildirilmesi gereken anormallikleri" nasıl ayırt etmelidir?**
+
+> Uyum sağlamadan önce teşhis koyun: yeni formatın beklenen bir şey olup olmadığını mimari dokümanlar ve PRD ile karşılaştırarak yargılayın (Deney 5-8'deki yaklaşım); sürüm kontrolü kayıtlarını denetleyip değişikliğin meşru bir kod commit'ine mi karşılık geldiğini, yoksa kaynağı belirsiz bir sapma mı olduğunu doğrulayın; τ-bench'in log_mismatch durumuna benzer biçimde, uyum sağlamayı seçseniz bile bir uyarı kaydı düşün ve sessizce uyum sağlamak yerine otomatik olarak issue açın; emin değilseniz human-in-the-loop onayına yönlendirin. İlke şudur: uyum sağlama ile raporlama paralel yürür; uyum, anormallik sinyalini yutmamalıdır.
+
+**4. (★★) Bu bölüm, PPT üretiminde, video düzenlemede ve log görselleştirmede proposer-reviewer mekanizmasını tekrar tekrar kullanır. Reviewer'ın estetik tercihleri hedef kullanıcınınkinden farklıysa—örneğin, Reviewer bilgi yoğunluğunu makul bulurken kullanıcı çok kalabalık buluyorsa—geri bildirim döngüsü yanlış bir yerel optimumda yakınsayabilir. Kullanıcı tercih geri bildirimi Reviewer döngüsüne nasıl dahil edilebilir?**
+
+> Kullanıcı geri bildirimini Agent trajectory'sine en yüksek öncelikli, yapılandırılmış bir olay olarak enjekte edin; kullanıcı tercihlerini dışsallaştırıp MEMORY.md'ye yazarak biriktirin, böylece tercihler görevler arasında geçerli olsun; dokümanları kullanıcının inceleyebilmesi için Markdown yerine HTML biçiminde teslim edin.
+
+**5. (★★) Bu bölüm, bir Kodlama Agent'ının yürütme ve hata ayıklamadan elde edilen deneyimi kod tabanına geri yatırmasının çeşitli yollarını gösterir—bilgi tabanı dosyalarına yazmak, mimari dokümantasyonu güncellemek, proje talimat dosyalarını korumak ve işlem dizilerini koda sabitlemek. Bu deneyim system prompt içindeki kurallara daha da inceltilirse, kural kümesi zamanla genişleyecektir. Birikmiş kurallar üzerinde "çöp toplama" nasıl gerçekleştirebiliriz—gereksiz veya güncelliğini yitirmiş girdileri belirleyip temizlemek? Tek bir başarılı kod değişikliği neden Bölüm 9 anlamında henüz sürekli evrim değildir?**
+
+> Çöp toplama yaklaşımı: linter'a, CI'ye veya araç doğrulamasına kodlanabilen kuralları prompt'tan çıkarın; kuralların isabet oranını ve çakışmalarını izleyin, düzenli aralıklarla kod tabanına karşı yeniden doğrulayın; Markdown ve Git ile kaynağı, sürümleri ve geri alma yeteneğini koruyun. Başarılı bir yama yalnızca eldeki vakayı çözdüğünü gösterir; sürekli evrim ise bunun ötesinde, değişikliğin izlenebilir çalışma kanıtından doğmasını, sonraki görevleri iyileştirmesini, eski görevlerde regresyon testinden ve güvenlik doğrulamasından geçmesini gerektirir.
+
+**6. (★) "Uzaktan çalışmaya dost olan ekipler genellikle AI Agent'lara da dosttur." Ekibiniz veya kuruluşunuz bilgi dokümantasyonu açısından "yapay zekaya hazır" olmaya ne kadar yakın? En büyük engel nedir?**
+
+> Açık uçlu soru. Bu bölümdeki vekil metrikle kendinizi sınayabilirsiniz: uzaktan çalışan yeni bir ekip üyesi yalnızca depoya ve dokümantasyona bakarak bağımsız çalışabiliyor mu? Kontrol listesi: kararlar dokümanlara kaydediliyor mu; context issue/PR'lara yazılıyor mu; derleme ve test komutları için CLAUDE.md/AGENTS.md gibi talimat dosyaları var mı; kabile bilgisi geliştirici kılavuzlarına damıtılmış mı? En sık görülen büyük engel, "yandaki arkadaşa sormaya" dayanan sözlü aktarım ve beyaz tahta kültürüdür — Agent sözlü mutabakatları okuyamaz, yalnızca dokümanları okur.
+
+**7. (★★★) Simon Willison, Agent'lar için "Ölümcül Üçlüyü" (özel veriye erişim, güvenilmeyen içeriğe maruz kalma ve dış iletişim yetenekleri) önerdi. Bu bölüm dördüncüsünü ekliyor: kalıcı bellek. Dört unsuru da eş zamanlı olarak ele alması gereken bir üretim ortamında, bir güvenlik stratejisini nasıl tasarlardınız?**
+
+> Savunmayı dört sınır boyunca katmanlayın. Veri sınırı: kimlik bilgileri bağlanmaz, kaynak kod salt okunurdur, görünürlük asgaridir. Girdi güven sınırı: kaynak etiketlenir, dış içerik "başvurulabilir ama talimat gücü olmayan" veri düzeyine indirilir (sadakat kuralları). Çıktı etki sınırı: varsayılan olarak ağ kapalı ve beyaz listeli çıkış, kara liste yerine komutların anlamsal olarak ayrıştırılması, bağımsız Sidecar incelemesi artı human-in-the-loop — kritik işlemler mutlaka context'in dışındaki bir mekanizma tarafından denetlenmelidir. Oturumlar arası sınır: MEMORY.md'ye yazma işlemi, dış içerikle aynı güven incelemesinden geçer. Hedef şudur: enjeksiyon gerçekleşse bile saldırı dışarıya taşınamasın.
+
+**8. (★★) Artifact kalıbı, bir Agent'ın SQL veya görselleştirme kodu üretmesine izin verir, bu daha sonra büyük miktarda veriyi işlemek için LLM'i atlayarak doğrudan frontend tarafından yürütülür. Bu "Agent kod üretir, sistem kodu yürütür" iş bölümünün geleneksel "Agent doğrudan yanıtı sağlar" kalıbına kıyasla artıları ve eksileri nelerdir? Ayrıca, üretilen SQL yıkıcı işlemler yürütebilir ve üretilen HTML açıklar içerebilir. Sistem güvenliği nasıl sağlanabilir?**
+
+> Artılar ve eksiler: Artıları: veri, veritabanından doğrudan frontend'e akar ve LLM "aracısını" atlar — hızlıdır, token tasarrufu sağlar, çok sayıda veriyi kopyalarken oluşan halüsinasyon hatalarını önler ve büyük veri hacimlerini sunmaya uygundur; kod denetlenebilir ve yeniden kullanılabilir, ayrıca boru hattına dizilebilir (SQL sonucu doğrudan görselleştirme koduna beslenir). Eksileri: LLM sorgu sonuçlarını hiç görmez, dolayısıyla verinin içeriğine dayanarak daha ileri bir çıkarım ve karar üretemez; modelin veriyi sindirip sonra akıl yürütmesi gereken görevlere uygun değildir.
+>
+> Güvenlik: SQL: sorgular en az ayrıcalıklı, salt okunur bir hesapla çalıştırılır ve kaynak tükenmesini önlemek için CPU, bellek gibi kaynak limitleri eklenir. HTML/UI: A2UI gibi bildirimsel protokoller tercih edilir — Agent yalnızca arayüz tanımı JSON'u üretir, istemci ise güvenilir bileşen kataloğuyla render eder ve keyfi kod çalıştırmaz. Keyfi HTML şartsa, enjeksiyonu önlemek için sandbox ortamında gösterilmelidir.
+
+**9. (★★) İş kurallarını araçlar içinde veritabanı gerçeğine dayalı doğrulamalar olarak kodlamak ve modeli çağırmadan önce politika koşullarını kontrol etmeye yönlendirmek için parametre tasarımını kullanmak, özünde Agent davranışını kısıtlamak için kod yapısını kullanır. Bu "kural olarak kod" kalıbının doğal dil kurallarına kıyasla avantajları ve sınırlamaları nelerdir?**
+
+> Avantajları: belirsizlik içermez, deterministiktir ve karmaşık koşul kombinasyonlarında iyidir; politika olguları modelin kendi beyanından değil veritabanı gerçeğinden ve sunucu saatinden gelir, dolayısıyla ne halüsinasyon ne de prompt injection bunu atlatabilir — geri alınamaz işlemlere karşı son kapı bekçisidir; expected_* parametreleri aynı zamanda düşünmeyi yönlendiren zorunlu bir checklist işlevi görür. Sınırları: kod kullanıcıya politikayı açıklamaz, alternatif bir yol aramaz ve bakım maliyeti getirir. Sonuç: doğal dil kurallarının yerine geçmez, onları tamamlar.
+## Etkileşim: Gözlem ve Eylem Uzaylarının Genişletilmesi
+
+**1. (★★) Asenkron bir Agent mimarisinde, olay kuyruğu için öncelik stratejisi tasarım zamanında belirlenmelidir. Ama öncelik yargısının kendisi semantik anlayış gerektiriyorsa (örn. yeni bir mesajın mevcut görevden daha acil olup olmadığını belirlemek), bu yargıyı kim vermelidir—bir kural motoru mu yoksa başka bir LLM çağrısı mı? Her birinin maliyetleri nelerdir?**
+
+> Katmanlı bir melez yaklaşım: türü açık olan olaylar kurallarla sabit kodlanır — sıfır gecikme ve güçlü determinizm sağlar, ama "hemen dur" ile "bugün hava nasıl" arasındaki anlamsal farkı kavrayamaz; anlamı belirsiz olanlar ise olay yönlendiricisi olarak çalışan hafif bir sınıflandırma LLM'ine bırakılır — bunun bedeli birkaç yüz milisaniyelik gecikme, ek ücret ve olası yanlış sınıflandırmadır; ayrıca bu LLM de Sidecar gibi, prompt injection'a karşı yalnızca yapılandırılmış alanları okumalıdır.
+
+**2. (★★) Kuyruk tabanlı olay işlemede, modeller yalnızca son olaya odaklanma eğilimindedir. Bu bölüm bunu Agent durum çubuğu işaretleri ve özetleme yoluyla hafifletir. Ama kuyrukta 20 olay birikmişse (10 araç sonucu + 5 kullanıcı mesajı + 5 sistem uyarısı), modelin kilit bilgiyi kaçırmaması için bu olayların sunum sırasını ve formatını nasıl organize ederdiniz?**
+
+> Önce kurallar ve hafif bir LLM ile sınıflandırıp yinelenenleri ayıklayın: acil olaylar (uyarılar, kullanıcı kesintileri) toplu işleme karıştırılmadan iptal tarzı bir yolla ayrıca ele alınır. Aşırı uzun 10 araç sonucunu kısaltıp dosyaya kalıcılaştırın; geriye yalnızca baş, son ve dosya yolu kalsın. Context'in sonundaki sistem durum çubuğuna bir özet listesi ekleyin (her olay türünün sayısı + her maddeye tek tek yanıt verilmesi talebi).
+
+**3. (★★★) Bir Agent kullanıcı adına dış dünyayla etkileşime girdiğinde, özünde bir kimlik seçimiyle karşı karşıyadır: üçüncü bir taraf olarak hareket etmek için bağımsız bir sanal kimlik (özel e-posta ve telefon numarası) mı kullanmalı, yoksa kullanıcının kişisel hesaplarını kullanıcının kendisi olarak mı doğrudan işletmeli? Birincisi otonom arka plan işlemine izin verir, ama üçüncü taraflar insan olmayan bir kimliğe güvenmeyebilir; ikincisi daha eksiksiz context ve izinlere sahiptir ama güven yetkilendirmesi ve güvenlik sınırı sorunları getirir. Hangi senaryolarda her modun seçilmesi gerektiğini düşünüyorsunuz?**
+
+> Varsayılan olarak sanal kimlik: arka planda otonom çalışabilir, denetlenebilir ve hata yaptığında ya da ele geçirildiğinde kullanıcının bütün dijital kimliğini açığa çıkarmaz — tıpkı bir sekreterin kendi kurumsal e-postasını kullanması gibi; buna karşılık CAPTCHA ve IP itibarı sorunlarıyla başa çıkmak gerekir (residential proxy). Kullanıcının kendi kimliğinin zorunlu olduğu senaryolarda (hesap kimlik doğrulaması, üç yönlü telefon görüşmesiyle onay — Pine'ın müşteri hizmetlerini araması gibi) human-in-the-loop kimlik doğrulaması kullanın: VNC/RDP sayesinde kullanıcı görsel olarak bizzat oturum açar. Ölçüt şudur: karşı taraf hesap sahibinin bizzat kendisini istiyor mu, işlemin riski ve kimlik bilgilerinin kapsamı ne kadar geniş?
+
+**4. (★★) Sesli Agent'ların uçtan uca modeli ASR-LLM-TTS zincirini tek bir modelde birleştirir; gecikmeyi düşürür ama modülerliği kaybeder. Uçtan uca model bir halkada (örneğin konuşma tanımada) hata yaparsa, hata ayıklamak ve düzeltmek seri boru hattına göre çok daha zordur. Uçtan uca bir sesli Agent'ın gözlemlenebilirlik (observability) sistemini nasıl tasarlardınız?**
+
+> Modelin, çıktısıyla birlikte okunabilir ara temsiller yaymasını sağlayın: Moshi'nin "iç monolog" metin akışı ve akustik olay işaretleri (`<emotion>`, `<noise>`) gibi. Hatanın hangi katmanda olduğunu bulmak için "self-cascading" (kendi kendine kaskatlama) kullanın: aynı model önce deşifre eder, sonra akıl yürütür; sonuç uçtan uca çıktıyla karşılaştırıldığında hatanın algıda mı yoksa düşünmede mi olduğu anlaşılır. Çevrimdışı tarafta ise paralinguistik anlama, sıra alma (turn-taking) yargısı gibi boyutlarda ayrı ayrı regresyon testleri çalıştırın.
+
+**5. (★) Step-Audio R1, MPS çift beyin mimarisiyle "düşünürken konuşma"yı gerçekleştiriyor. Ama insanlar "düşünürken konuşurken" sık sık iyi düşünülmemiş şeyler söyler, kendini düzeltir ya da dolgu sözcükleri kullanır. Agent'ın "düşünürken konuşması" insandaki bu özellikleri taklit etmeli mi?**
+
+> Sinyal değeri taşıyan "kusurlar" taklit edilmelidir: duraklamalar ve dolgu sözcükleri düşünmenin dışavurumudur, gecikmeyi de örtebilir; nereye ekleneceğine LLM karar verir. Güveni yıkan kendini düzeltmeler ise taklit edilmemelidir: birinci çözümdeki hızlı-yavaş çelişkisi ("alsam mı almasam mı?!") güveni çökertir. MPS deneyleri, CoT'nin başlangıcının çoğunlukla soruyu tekrarlamak olduğunu gösteriyor; erken konuşmaya başlayıp hazırlık cümleleri kurmak güvenlidir, önce yanlış söyleyip sonra düzeltmeye gerek yoktur.
+
+**6. (★★) SoM (Set-of-Mark) ve onun yapısal türevi (DOM öğe indeksleme), Computer Use'un görsel konumlandırmasını açık uçlu koordinat tahmininden kapalı uçlu ID seçimine dönüştürür; ama her ikisi de önce arayüz öğelerinin tespit edilip işaretlenmesini gerektirir — ister segmentasyon modeliyle ister DOM'la olsun. Arayüzde standart dışı kontroller veya dinamik olarak değişen öğeler varsa, işaretleme eksik ya da hatalı olabilir. Bu durumda koordinat tahminine geri dönmeli mi?**
+
+> Koordinat tahmini yedek olarak korunmalıdır: etiketlemeye bağlı olmayan tek yoldur ve hem standart dışı bileşenler hem de dinamik elemanlar için geçerlidir. Daha pratik olanı melez bir action space (eylem alanı) kurmaktır: etiketlenebilen elemanlar için yine ID seçimi kullanılır. Koordinat tahmininde çözünürlük eşleştirmesi ve orantılı ölçekleme yapılmalıdır, aksi halde sistematik kayma oluşur.
+
+**7. (★★) XLeRobot gibi bin dolar seviyesindeki robot platformları teleoperasyon verisi toplamayı ucuzlattı. Ama teleoperasyon verisinin kalitesi büyük ölçüde operatörün becerisine bağlıdır. Deneyimsiz bir operatörün sağladığı veri, VLA modelinin eğitimini nasıl etkiler? Veri toplama aşamasında düşük kaliteli veriyi otomatik olarak nasıl elerdiniz?**
+
+> VLA esas olarak taklit öğrenmesine dayanır; düşük kaliteli gösterimler titremeyi, gereksiz dolaşmayı, tereddüdü ve başarısız hareketleri doğru strateji sanarak öğretir. Bu, Bölüm 8'deki yargıyı yankılar: veri, mimariden daha kritiktir.
+
+**8. (★★★) Bu bölüm ses, Computer Use ve robotik olmak üzere üç etkileşim biçimini kapsadı. Bu üç biçimin ortak eğilimi, seri boru hattından uçtan uca modellere doğru evrilmek. Bu eğilim sürerse, beş yıl sonraki Agent etkileşim katmanı nasıl görünecek?**
+
+> Thinking Machines Lab'in savunduğu gibi, etkileşkenlik Harness'e takılan bir eklenti değil modelin içine gömülü bir özellik olacak ve zekâyla birlikte ölçeklenecek. Computer Use, kare kare ekran görüntüsünden sürekli gözleme geçecek. Bedenlenmiş zekânın world model'i eksiksiz biçimde gerçekleşecek; ama öncü akıl yürütme modelleri çok hızlı geliştiği için hızlı-yavaş ayrışması ortadan kalkmayacak: etkileşim modeliyle SOTA düşünme modelinin hızlı-yavaş düşünme iş birliğine dayanan mimarisi uzun vadeli bir mimari haline gelebilir.
+
+**9. (★★) DOM/Accessibility Tree öğe indekslemesi standart Web uygulamalarında belirgin sonuç veriyor, ama gitgide daha çok yazılım arayüzü (Canvas/WebGL render'ı, platformlar arası kendi çizen kontroller) erişilebilir yapısal bilgi sunmuyor ve geriye yalnızca görsel işaretleme ya da koordinat tahmini kalıyor. Sizce Computer Use saf görsel yola mı oynamalı, yoksa yapısal ve görsel iki yolu birden mi sürdürmeli? İki yolu birden sürdürmenin maliyeti ve getirisi nedir?**
+
+> Kısa vadede iki yol bir arada var olur: yapılandırılmış indeks elde edilebiliyorsa konumlandırma en doğru ve en kararlı olanıdır, segmentasyonun yanlış tespitlerinden de kurtulur; saf görsel yol ise yerel yazılımlar, Canvas ve oyunlar için tek seçenektir. Modelin kendi grounding yeteneği (belirtilen koordinata tıklama) güçlü olduğunda, yapılandırılmış indeks çözümünün belirgin bir üstünlüğü ortaya çıkmaz. Uzun vadede ise saf görsel yolun tavanı daha yüksektir.
+
+**10. (★★) VLA modelleri action chunking (eylem parçalama) kullanıyor — metinde anlatıldığı gibi, π₀'ın tipik yapılandırması 50 Hz frekansta 25-50 gelecek eylemi bir seferde üretmektir — ve böylece çıkarım gecikmesini yürütme süresinin içine saklıyor. Ama yürütme sırasında ortam ani biçimde değişirse (örneğin nesne yerinden alınırsa), önceden üretilmiş eylem dizisi geçersizleşir. Action chunking'in verimlilik avantajı ile ortam değişimlerine tepki hızı arasında dengeyi nasıl kurarsınız?**
+
+> Parçalama özünde tepkiselliği pürüzsüzlükle takas eder; parça uzadıkça tepki körelir. Parça uzunluğunun yalnızca "çıkarım süresi < parça yürütme süresi" alt sınırını karşılaması yeterlidir, körü körüne uzatmayın. Yürütme sırasında algı modelini çalışır durumda tutun; ortamda ani bir değişiklik tespit edilir edilmez kalan eylemleri atıp yeniden çıkarım yapın — bu, ses senaryosundaki "araya girme" (barge-in) davranışının karşılığıdır. Parça uzunluğu senaryoya göre dinamik olarak ayarlanabilir: statik sahnelerde uzun parçalar hesaplamadan tasarruf sağlar, dinamik sahnelerde kısa parçalar tepki gecikmesini korur.
+
+**11. (★★★) Bu bölümdeki üç senaryonun (ses, Computer Use, robotik) hepsi "algılama-düşünme-eylem" döngüsünün gecikme sorunuyla yüzleşiyor ve hepsi hızlı-yavaş düşünmenin paralelleştirilmesi yönünde evriliyor. Ses senaryosunda bu, "yanlış söylediysen sonra düzelt" biçiminde; Computer Use senaryosunda "önce tıkla sonra bak" biçiminde; robotik senaryosunda ise "bir adım at sonra bak" biçiminde ortaya çıkıyor. Hızlı düşünmeye dayanan bu eylemlerin geri döndürülemez sonuçlara yol açmamasını nasıl garanti edersiniz?**
+
+> Eylemleri geri alınabilirliğe göre derecelendirin; hızlı düşünmenin yalnızca geri alınabilir eylemleri yürütmesine izin verin, geri alınamaz işlemleri ise yavaş düşünmenin denetimine bırakın. Hızlı modelin, geri alınamaz sonuçlar doğuracak tool call'ları yürütmesine izin verilmemelidir.
+
+**12. (★★★) Bu bölümde aynı ilkel kümesi (uyandırma, güvenli nokta, iptal, öne geçme, hızlı/yavaş ayrımı) farklı zaman ölçeklerinde tekrar tekrar karşımıza çıktı. Bunlardan birini seçin ve olay güdümlü işlemede (saniye—gün) ve robot eylem parçalamada (milisaniye) uygulanışının nasıl farklılaştığını açıklayın. Bu farkı esas olarak ne belirliyor—ortamın değişim hızı, eylemin geri alınabilirliği, yoksa gözlem elde etmenin maliyeti mi?**
+
+> **İptali** ele alalım. Olay güdümlü işlemede iptal, iki araç çağrısı arasındaki güvenli noktada gerçekleşir: `terminate` alan Agent kaynakları temizler, bir onay döndürür ve çıkar; gecikmenin saniyelerle ölçülmesi kabul edilebilir, çünkü tek bir araç çağrısı zaten saniyeler ila dakikalar sürer. Eylem parçalamada iptal milisaniyeler içinde etkili olmalıdır: denetim iş parçacığı bir güvenlik olayı ya da gözlemde belirgin bir değişim gördüğü anda mevcut hareketi durdurmalı, kalan parçayı atmalı ve yeniden gözlemlemelidir—bir adım geç kalması engele çarpması demektir.
+>
+> Üç aday etkenden **gözlem elde etmenin maliyeti** aslında en az belirleyici olanıdır; her iki tarafta da yeniden gözlemlemek ucuzdur. Farkı asıl belirleyen diğer ikisinin bileşimidir: **ortamın değişim hızı** güvenli noktaların ne kadar sık olması gerektiğini belirler (araç çağrıları arası yeterli mi, yoksa her denetim döngüsünde mi gerekli), **eylemin geri alınabilirliği** ise bir güvenli noktayı kaçırmanın bedelini belirler (fazladan bir e-postanın ardından özür yollanabilir, devrilen bardak geri alınamaz).
+>
+> Buradan bir tasarım kuralı çıkar: güvenli noktaların sıklığı ortamın değişim hızıyla eşleşmelidir; güvenli noktaların ötesinde ne kadar ek koruma gerektiği (donanımsal acil durdurma, bağımsız güvenlik denetleyicisi, ikincil onay) ise eylemin ne kadar geri alınamaz olduğuna bağlıdır. Bu, Bölüm 4'teki yüksek riskli işlemlerin neden ön onay gerektirdiğini, robotların ise neden modelden bağımsız bir donanım güvenlik katmanına ihtiyaç duyduğunu da açıklar—ikisi de güvenli noktaların tek başına yetmediği yere eklenen ikinci savunma hattıdır.
+
+## Bölüm 7: Agent'ların Değerlendirilmesi
+
+**1. (★★) LLM-as-a-Judge, bir dil modelinin çıktısını yine bir dil modeliyle değerlendirir. Bu "öz değerlendirmenin" sistematik kör noktaları var mıdır — örneğin model, belirli bir üsluptaki yanıtlara tutarlı biçimde yüksek puan verip bu tercih insan yargısıyla uyuşmayabilir mi? Böyle bir yanlılık nasıl tespit edilir ve düzeltilir?**
+
+> Evet, taşır: uzunluk yanlılığı, yanıt üslubu yanlılığı ve aynı aileden modellerin açık vermesi (Goodhart yasası). Tespit: 100–200 örneklik bir insan altın standart kümesi kurun ve hakem ile insan arasındaki Cohen's kappa değerini ölçün; puanlar ile yanıt uzunluğu arasındaki korelasyonu düzenli olarak denetleyin; bir red team'e çekişmeli örnekler kurgulatın. Düzeltme: Rubric'te uzun konuşmayı açıkça cezalandırın ve uzunluğu sınırlayın; farklı model ailelerinden gelen, çok kaynaklı ve heterojen hakemler kullanın.
+
+**2. (★★★) Değerlendirme veri kümelerinin "sızıntıya dayanıklı" tasarımı kritik önemdedir. Ama açık kaynak ekosisteminde benchmark verisi bir kez kamuya açıldığında hızla eğitim verisine dahil edilir. Bu "kedi-fare oyununun" bir sonu var mı? Veri sızıntısına kökten direnen bir değerlendirme yöntemi tasarlayın.**
+
+> Statik bir soru bankasının sonu yoktur; yalnızca kovalayabilirsiniz. Kökten çözüm, "üretim mekanizmasını" kamuya açıp "somut örnekleri" özel tutmaktır: τ²-bench ve AndroidWorld'de olduğu gibi parametreleştirilmiş şablonlar her seferinde rastgele örneklenir ve doğrulama, sabit bir cevap dizisine değil nihai ortam durumuna dayanır.
+
+**3. (★★) Scale AI'ın dört ölçütü (uzman rehberliğine dayanma, kapsamlı kapsama, standartlaştırılmış önem ağırlıkları, kendi kendine yeten değerlendirme) değerlendirmedeki öznelliği ortadan kaldırmayı amaçlar. Ne var ki bazı görev boyutları ("yanıt faydalı mı", "ton uygun mu" gibi) doğası gereği özneldir. Bu öznel boyutlar için güvenilir bir Rubric nasıl tasarlanır?**
+
+> Soyut ölçütleri doğrulanabilir davranışlara çevirin. Her kademeye somut örnekler ve sınır durumları ekleyin; Rubric yinelemeli bir üründür — deneme kullanımı sırasında değerlendiriciler arasındaki görüş ayrılıklarını toplayın ve Rubric'i giderek bir emsal derlemesine dönüştürün. Buna çok hakemli ağırlıklandırma ve tutarlılık kontrolleri ekleyin, anlaşmazlık içeren vakaları insan incelemesine gönderin ve uyum oranını altın standart kümesi üzerinde kalibre edin.
+
+**4. (★★) τ-bench, gerçek kullanıcı davranışını simüle ederek Agent'ları değerlendirir. Ama simüle edilen kullanıcının kendisi de bir LLM'dir — bazı uç senaryoları (duygusal olarak taşkın ya da kendini net ifade edemeyen kullanıcılar gibi) sistematik biçimde hafife alabilir. Simüle edilen kullanıcının kalitesi nasıl doğrulanır?**
+
+> τ-bench'in ilk sürümünden çıkan ders: simülatör fazla mekanikti ve talimatları fazla basitti (Agent cevapları tahmin edebiliyordu). Doğrulama yöntemleri: simüle diyalogları elle örnekleyerek denetleyin, kademeli açığa çıkarmaya uyulup uyulmadığını ve senaryo dışı bilgi uydurulup uydurulmadığını kontrol edin; küçük örneklemli gerçek kullanıcı testleri yapıp sıralamanın simülasyon değerlendirmesiyle örtüşüp örtüşmediğine bakın.
+
+**5. (★★) İkili karşılaştırma (Bradley-Terry modeli), tercihlerin geçişli olduğunu varsayar (A > B ve B > C ise A > C). Oysa insan tercihleri geçişliliği sıkça ihlal eder. Agent değerlendirmesinde geçişsiz tercihler hangi senaryolarda ortaya çıkabilir? Bu, sıralamanın güvenilirliğini nasıl etkiler?**
+
+> Senaryolar: çok boyutlu ödünleşimlerde (A doğru ama yavaş, B hızlı ama üstünkörü, C ayrıntılı ama pahalı) farklı hakemler ve farklı görevler farklı boyutlara ağırlık verir. Chatbot Arena'nın sıralaması da zaten kullanıcı sorularının dağılımına bağlıdır. Etkisi: Bradley-Terry gücü tek bir puana sıkıştırır; geçişsizlik varsa sıralama kararsızlaşır ve eşleşme dağılımıyla birlikte kayar. Hafifletme: yetenek boyutlarına göre ayrı ayrı sıralayın ve ikili kazanma oranı matrisini raporlayın.
+
+**6. (★★) Bu bölüm, yetenek tavanı olarak Pass@k ile iş güvenilirliği ölçüsü olarak Pass consecutive@k arasında ayrım yapar. Tek seferlik başarı oranı yalnızca %60 olan bir Agent için, hangi metriği raporlayacağınıza ve $k$ değerini ne kadar alacağınıza karar verirken görevin başarısızlık maliyetini, yeniden deneme maliyetini ve yan etkilerini nasıl bir araya getirirsiniz?**
+
+> Başarısızlığın geri alınıp alınamayacağından başlayın. Başarısızlıklar otomatik olarak yeniden denenebiliyor ve dışarıya yan etki bırakmıyorsa (getirme, taslak üretimi, kod tamamlama), soru “yeterince şans verilirse başarabiliyor mu” olduğundan Pass@k raporlanır ve k, fiilen izin verilen yeniden deneme bütçesi olarak alınır. Başarısızlık geri döndürülemez sonuçlar bırakıyorsa (ödeme, iade, dışarıya e-posta, üretime dağıtım), tek bir hata gerçek bir kayıptır; bu durumda Pass^k raporlanır. Tek seferlik başarı oranı 0,6 iken Pass@5 ≈ %99,0, Pass^5 ise ≈ %7,8—aynı Agent için bir büyüklük mertebesi fark eden iki sayı; yalnızca ilkini raporlamak güvenilirliği ciddi biçimde abartır.
+>
+> k, en güzel görünen sayıdan değil dağıtım gerçekliğinden gelsin: Pass@k için yeniden deneme bütçesini, Pass^k için bir vardiyada ya da bir partide arka arkaya çalışan görev sayısını alın. Yeniden deneme pahalıysa kabulü iki aşamalı yapın—önce Pass@1 ile eleyin, ardından kalan az sayıdaki adaya Pass^k uygulayın. Hangi metriği raporlarsanız raporlayın, k'yı ve örnekleme protokolünü belirtin; yan etkili işlemlerde örneklemeyi bir kum havuzunda veya geri alınabilir bir ortamda yapın ve “başarana kadar yeniden dene” yerine her başarısızlığı güvenilirlik istatistiğine dahil edin.
+
+**7. (★★) Bu bölüm "gözlem → hipotez → deney → doğrulama" biçiminde bilimsel bir yöntem öneriyor. Ama pratikte Agent'ın davranış uzayı devasadır ve tek bir hipotezi doğrulamak yüzlerce değerlendirme koşusu gerektirebilir. Sınırlı bir hesaplama bütçesi altında değerlendirmeden elde edilen bilgi miktarı nasıl en üst düzeye çıkarılır?**
+
+> Önce başarısızlıkları kümeleyerek en çok bilgi taşıyan görevleri bulun; ardından düşük maliyetli, tek değişkenli eşleştirilmiş pilotlar yapın. Küçük örneklemi dağıtım kanıtı değil, testi büyütme kapısı sayın. İstatistikte standart hatayı muhafazakâr bir elek olarak kullanın; aynı görevlerde McNemar gibi eşleştirilmiş analiz uygulayın; beklenen fark gürültü bandının altındaysa değerlendirme kümesini büyütün. Birden çok seçeneği paralel eliyorsanız çoklu karşılaştırmayı düzeltin ve olumlu sonuçları bağımsız koşuyla doğrulayın.
+
+**8. (★) AndroidWorld pilotunda tam öğe ağacı başarıyı 25%'ten 100%'e çıkarırken token kullanımını kontrolün 2.498 katına yükseltti; budama 100% başarıyı koruyup token kullanımını 0.506 kata indirdi. Erişilebilirlik, durum doğrulama veya sonraki eylemler için gerekli bilgileri atmadan anlamsal olarak boş UI düğümlerini kaldıracak otomatik budama kurallarını nasıl tasarlardınız?**
+
+> “Varsayılan olarak sil, kanıt varsa tut” ilkesiyle katmanlı kurallar kullanılabilir. Görünür, metinli, eyleme açık, odaklanabilir, kaydırılabilir, durum/değer taşıyan veya accessibility etiketi olan düğümleri; bunların köke giden gerekli ata yolunu ve ilgili komşu etiketleri koruyun. Yalnızca yerleşim sağlayan container'ları kaldırın, tekrarlanan alt ağaçları özetleyin. Budama öncesi ve sonrası eyleme açık kimlik, durum ve değerlerin korunduğunu doğrulayın; görsel yedek olarak ekran görüntüsünü saklayın. Kuralları başarısız trajectory'lerde oynatın, sonra ayar için kullanılmamış uygulamalarda regresyon testi yapın. Başarı, token ve gecikme ortak guardrail olsun; accessibility gerilemesi sürümü engellesin.
+
+**9. (★★) τ-bench'in kullanıcı simülasyonu "kademeli bilgi açıklama" kullanır — bütün bilgi tek seferde verilmez, Agent'ın sorularına göre adım adım açıklanır. Bu tasarım değerlendirme sonuçlarını nasıl etkiler? Simüle edilen kullanıcının bilgi açıklama stratejisi gerçek kullanıcılardan belirgin biçimde farklıysa, değerlendirme sonuçları hâlâ güvenilir midir?**
+
+> Etkisi: açığa çıkarma stratejisi çarpıksa Agent yalnızca "simülatöre uyum sağlamayı" öğrenmiş olabilir (Goodhart) ve mutlak puanların referans değeri kalmaz; modeller arasındaki göreli sıralama yine de referans değeri taşıyabilir. Telafi: simülatörü gerçek diyaloglarla kalibre edin, elle örnekleme denetimi yapın ve sonuçların geçerli olduğu sınırları açıkça belirtin.
+
+## Bölüm 8: Model Post-Training
+
+**1. (★★) Felaket unutma — belirli bir göreve yönelik bir ince ayarın modelin var olan genel yeteneklerini (örneğin genel tool calling'i) bozması — Agent senaryolarında özellikle çetrefillidir. Tüm parametrelerin ince ayarına kıyasla LoRA taban ağırlıkları dondurur ve unutma riski daha düşüktür, ama bağışık değildir. İnce ayarın getirdiği yetenek kaybını daha da hafifletmek için hangi stratejiler kullanılabilir?**
+
+> Veri oranlaması: yaklaşık %20 genel/özgün dağılım verisi karıştırın, böylece yeni görevin payı eski yetenekleri ezmez. Eğitim miktarında ölçülü olun: SFT'yi "format kararlı, temel yetenek oluştu" noktasında bırakın; erken durdurma çöküşü önler. RL'de küçük rank (8–32) kullanın ve KL cezasını koruyun, böylece politika referans modelin yakınında kalır. Kritik bileşenleri dondurun (örneğin bir VLM'de yalnızca projeksiyon katmanını eğitin). Yetenekleri izole etmek için göreve göre birden fazla LoRA adapter takın. Genel benchmark'larla regresyon testi yapın.
+
+**2. (★★) Post-training yeteneği model ağırlıklarına sabitler ("kas hafızası"), in-context learning ise bilgiyi çıkarım zamanındaki girdiye koyar. Ama bazı yetenekler (örneğin alan bilgisi) hem post-training ile öğrenilebilir hem de few-shot örneklerle sağlanabilir. Bir yeteneğin hangi yoldan gitmesi gerektiğine karar verirken hangi ölçütleri kullanırsınız?**
+
+> Önce yeteneğin dış sembollerle yeterince ifade edilip edilemeyeceğine bakın: olgular ve kanıtlar RAG'a, dile dökülebilen ilkeler Prompt/Skill'e, deterministik süreçler ve katı kısıtlar ise programa yakışır. Tıbbi görüntü anlama, doğal ton ve örtük politikalar gibi yüksek boyutlu yetenekler, alan hâlâ değişiyor olsa bile çoğu zaman parametre güncellemesi gerektirir. Sonra güncelleme maliyetine, çağrı ölçeğine, güncellik ihtiyacına ve riske bakın: keşif aşamasında context ile hızlıca doğrulayın; yaklaşım kararlı biçimde işe yarıyorsa ve geniş genelleme gerekiyorsa eğitime geçin. Katı kurallar ise ne kadar kararlı olurlarsa olsunlar yalnızca parametre belleğine bırakılmamalıdır.
+
+**3. (★★) Model damıtma, küçük modelin büyük modelin davranışını öğrenmesini sağlar. Yetenek katmanlarına göre damıtılan modeller kabaca üç seviyeye ayrılır: **Chat modelleri** (tek turlu diyalog, doğrudan yanıt), **Reasoning modelleri** (uzun zincirli düşünmeden sonra yanıt), **Agentic modeller** (çok turlu araç çağırma, ortamla etkileşim). Bu üç türü ayrı ayrı damıtırken zorluklar nasıl farklılaşır? (İpucu: "asıl damıtılan şey nedir" sorusundan başlayın — çıktının üslubu mu, eksiksiz düşünme trajectory'si mi, yoksa ortamla etkileşimin karar politikası mı; trajectory'deki hangi token'lar öğrenilmeli, hangileri ortamın döndürdüğü ve öğrenilmemesi gerekenler; ayrıca başarı/başarısızlık sinyali ne kadar geç ve ne kadar seyrek ortaya çıkıyor.)**
+
+> Chat: yalnızca "girdi → çıktı" eşlemesi ile üslup öğrenilir; standart SFT yeter, en basiti budur. Reasoning: eksiksiz düşünme trajectory'si gerekir, dolayısıyla açık kaynaklı bir teacher modele dayanılmalıdır; cevabı yanlış olan trajectory'ler ayıklanmalıdır. Agentic: gerçek bir simülasyon ortamı gerekir; çevrimdışı öğrenmede learner-sampler mismatch kolayca ortaya çıkar, bu yüzden açık kaynaklı bir teacher modele dayalı On-Policy Distillation önerilir.
+
+**4. (★★★) Çok turlu Agent etkileşiminde ödülün atfedilmesi (credit assignment) sorunu tek turluya göre çok daha ciddidir — nihai bir başarıyı ya da başarısızlığı 3. turdaki karara mı yoksa 7. turdakine mi yazacağınızı belirlemek zordur. Ödül dağıtım stratejisini nasıl tasarlarsınız?**
+
+> Ara adımlar yargılanabildiğinde süreç ödülü ekleyin (V-IRL her adımda ±1 verir); RLVP'yi örnek alarak deterministik kurallarla her eyleme yol sinyali verin ve böylece tamamı başarısız ya da tamamı başarılı grupların grup içi varyansını geri kazanın.
+
+**5. (★★★) Sabit bir bütçeniz varsa (örneğin 10.000 dolar) ve bir müşteri hizmetleri Agent'ının performansını iyileştirecekseniz, bütçeyi context ve bilgi, Prompt/Skills, program kısıtları ve parametre eğitimi arasında nasıl dağıtırsınız? Kararınız hangi etkenlere bağlıdır?**
+
+> Önce bütçenin bir kısmını değerlendirme kümesi ve trajectory doğrulayıcıları kurmaya ayırın; yoksa kalan yatırımlar karşılaştırılamaz. Ürün olgularını ve politikaları izlenebilir bir bilgi tabanına koyun. Dile dökülebilen az sayıda hizmet ilkesini önce Prompt/Skills ile hızlıca doğrulayın. İade yetkisini, gizliliği ve söz–eylem tutarlılığını programla emniyete alın. Yalnızca doğal ton ve karmaşık niyet anlama gibi kurala dökülmesi zor olan ve yeterince büyük çağrı ölçeğine sahip yetenekler için parametre eğitimine yatırım yapın. Kesin oranlar darboğaza, riske, güncelleme sıklığına, çağrı hacmine ve mevcut modelin yeteneğine bağlıdır.
+
+**6. (★★★) Net bir ödül fonksiyonu olmadan ve örnek sayısı azken modelin öğrenmeyi kendi başına gerçekleştirmesi, bazılarına göre post-training'in nihai hedefidir. Bugünün RL eğitim yöntemleri bu hedeften ne kadar uzakta? Bir sonraki atılımın büyük olasılıkla hangi yönden geleceğini düşünüyorsunuz?**
+
+> Aradaki mesafe: Silver ve Sutton'ın işaret ettiği gibi, bugünkü RL yalnızca nihai başarı ya da başarısızlıktan öğrenebiliyor; müşterinin "kredi kartının son dört hanesi gerekiyor" demesi gibi zengin geri bildirimler tamamen ziyan oluyor ve yüzlerce kör deneme gerekiyor; örnek verimliliği ile doğrulanabilir ödül başlıca darboğazlar. Olası atılımlar: kendi ilkelerini kendisi koyan ve tek bir başarısızlıktan yön çıkarabilen üretici ödül modelleri; bir de ortamı modelleyen world model yolu.
+
+**7. (★★) Bu bölüm, LoRA ince ayarının maliyetinin yüksek olmadığını belirtiyor. Peki her kullanıcı (ya da her müşteri şirket) için özel bir LoRA eğitip kullanıcı belleğini veya kurumsal bilgiyi, Bölüm 3'teki gibi dış bir bilgi tabanında saklamak yerine parametrelere yazmak mümkün mü? Hangi senaryolarda "belleği parametrelere yazmak", "belleği bilgi tabanına koymaktan" daha avantajlıdır? Hangi senaryolarda ise tersine sonuç verir?**
+
+> LoRA çok sayıda olguyu doğru biçimde ezberlemekte zorlanır (bunun için pre-training'in sürdürülmesi gerekir, bu da maliyeti fırlatır); ezberlese bile model bu olguları çok atlamalı akıl yürütmede güçlükle kullanır. Dolayısıyla olguları LoRA ile ezberletmek pek iyi bir teknik yol değildir. Ayrıca olgular sık değişiyorsa ve izlenebilir denetim gerekiyorsa RAG daha üstündür.
+
+**8. (★★★) On-Policy Distillation, öğrenciyi denetlemek için daha güçlü bir öğretmen modele dayanır. Ama OpenAI'nin Weak-to-Strong Generalization araştırması sezgiye aykırı bir bulgu ortaya koydu: zayıf modelin denetim sinyali bazen güçlü modelin kendisinde var olan ama henüz etkinleşmemiş yetenekleri harekete geçirebiliyor. Bu fikir Agent eğitimine uygulanırsa, "küçük modelin büyük modele öğretmesi" biçiminde ters yönlü bir damıtma mümkün olur mu?**
+
+> Mümkün; kilit nokta "doğrulamanın üretmekten kolay olmasıdır": zayıf model gösterici rolünü üstlenmemeli (SFT'nin tavanı göstericinin düzeyidir), doğrulayıcı/ödül modeli rolünü üstlenmelidir — keşfi güçlü model kendisi yapar, zayıf model yalnızca yargılar.
+
+**9. (★★) Süreç ödül modeli (PRM) her düşünme adımını değerlendirir, sonuç ödül modeli (ORM) ise yalnızca nihai sonuca bakar. Peki "doğru sürecin yanlış sonuca yol açması" ile "yanlış sürecin şans eseri doğru sonuca ulaşması" durumlarından hangisi ödüllendirilmeyi daha çok hak eder? Agent'ın çok adımlı tool calling senaryosunda dengeyi nasıl kurarsınız?**
+
+> Şans eseri başarı daha tehlikelidir: kural ihlali içeren kestirmeler çoğu zaman görünürdeki başarı oranını şişirir (test dosyasını değiştirmek, doğrulamayı atlamak) ve reward hacking için verimli bir zemin oluşturur. RLVP'nin "sonucu ödüllendir, yolu cezalandır" ilkesine uyun: yanlış eylemleri (tool call'ları) doğrulamak kolaydır, eylem başına puan kırın; ara adımların doğruluğu kolay yargılanabildiğinde süreç ödülü verilebilir. Ancak süreç kısıtlarını fazla sıklaştırmayın — "pushcut" tarzı daha üstün strateji, tam da sonuç ödülünün tanıdığı keşif özgürlüğü sayesinde bulunmuştu.
+
+**10. (★★★) Bu bölümde ele alınan değerlendirme veri kümeleri (SWE-Bench Verified, τ²-bench, AndroidWorld gibi) hem değerlendirme hem de post-training için kullanılabilir. Ama değerlendirme kümesini eğitimde kullanırsanız, artık bağımsız bir değerlendirme kümesi olmaktan çıkar — bu, eğitim kümesiyle test kümesinin ayrı olması gerektiği temel ilkesini ihlal etmez mi? τ²-bench'in dinamik parametre üretimi ve AndroidWorld'ün parametrik şablonları bu sorunu bir ölçüde hafifletiyor, ama şablon yapısının kendisi yine de sabit. Değerlendirme verisinin eğitim değerinden tam olarak yararlanmakla değerlendirmenin bağımsızlığını korumak arasındaki dengeyi nasıl bulursunuz?**
+
+> Ortamı yeniden kullanın, soruları değil. Dinamik parametreler yalnızca "cevabı ezberlemeyi" önler, şablona aşırı uyumu önlemez; bu yüzden değerlendirme için hiç görülmemiş şablonlardan ve alan dışı senaryolardan oluşan bütün partiler ayrı tutulmalıdır (V-IRL'in New York'ta eğitilip dokuz yabancı şehirde test edilmesine benzer biçimde). Parametreleştirilmiş şablonlarla toplu eğitim varyantları üretip müfredat öğrenmesini besleyin ve gerçek genelleme göstergesi olarak OOD skorunu alın.
+
+**11. (★★★) Bu bölüm "önce biçim, sonra ruh" biçiminde bir eğitim paradigması ortaya koyuyor: SFT "biçim kararlı, yetenek başlangıç düzeyinde" noktasında durur, sonra RL'e geçilir. Peki pratikte SFT'nin çoktan "yeterli" olduğuna ve artık geçiş yapılması gerektiğine nasıl karar verilir?**
+
+> Format sinyali: tool call çıktıları kararlı biçimde ayrıştırılıp yürütülebiliyor ve araç yürütme hata oranı, ödülün güvenilir biçimde hesaplanmasına izin verecek düzeye iniyor. Kazanç sinyali: daha fazla gösterim verisi eklemek OOD yeni senaryolardaki performansı artık yükseltmiyor — bu, darboğazın artık SFT'nin ezberleme hedefinin kendisinde olduğunu, yani kritik eşiğe gelindiğini gösterir. Aşırı uyum sinyali: doğrulama kümesindeki performans bozulmaya başladığı anda durulmalıdır — V-IRL deneyi, SFT aşırı eğitimle eğitim dağılımına çöktükten sonra RL'in bile OOD performansını geri getiremediğini gösteriyor.
+
+**12. (★★★) ReTool'un eğitim dinamiği (bkz. Deney 7-15), az sayıdaki aşırı uzun yanıtın tüm eğitim döngüsünü belirgin biçimde geciktirdiğini gösteriyor — bir rollout partisindeki yanıtların büyük çoğunluğu çoktan üretilmiş olsa da en uzun birkaç yanıtın bitmesi beklenir ve bu süre boyunca cluster'ın GPU kullanımı çok düşüktür. Bu uzun kuyruklu yanıt senaryosunda eğitim cluster'ının kaynak kullanımı nasıl artırılabilir?**
+
+> Altyapı katmanında: rollout'u eğitim kümesinden ayırın ve asenkron bir boru hattı kurun; boştaki GPU'ları sürekli gruplamayla (continuous batching) yeni isteklerle doldurun. Uzun kuyruğu kaynağında bastırın: DAPO'nun Overlong Reward Shaping yöntemi aşırı uzun yanıtları yumuşak biçimde cezalandırır.
+
+**13. (★★★) Agent'ı LLM ile simüle edilmiş bir ortamda (simüle arama motoru, simüle kullanıcı gibi) eğitirken, Agent'ın açık aradığı hedef "gerçek ortamın kurallarından" "simülatörün kendi önyargıları ve açıklarına" kayar. Bu tür eğitimlerde hangi somut reward hacking davranışları ortaya çıkabilir? Bunlara karşı nasıl önlem alınabilir?**
+
+> Tipik davranışlar: "simüle kullanıcıya" aşırı söz vermek, özür ve gönül alma kalıplarını üst üste yığmak — simüle kullanıcı kolayca yatıştırılır, gerçek kullanıcı gibi verilen sözün tutulup tutulmadığının hesabını sormaz; simülatörün doğrulamaya gitmeyeceği olguları uydurmak; "simüle arama motoruna" yönlendirici query'ler kurup onun cevabı içeren dokümanları döndürme eğiliminden yararlanarak kestirmeden gitmek, yani gerçek retrieval'ı öğrenmemek; ödül simülatörün ya da bir LLM hakemin puanından geliyorsa, uzun, şablonlaşmış ve "profesyonel görünen" yanıtlarla puan toplamak; daha sinsi olanı ise politikanın simülatörün aşina olduğu dağılıma çekilip onun bilgi kör noktalarından kaçınmasıdır — kör noktalarda geri bildirim güvenilmezdir ve sık sık yanlış yargılanır, böylece Agent yalnızca "simülatörün iyi olduğu dünyada" hareket etmeyi öğrenir. Korunmanın birinci ilkesi, **ödülü programla doğrulanabilir gerçek duruma bağlamaktır** (görevin tamamlanması, veritabanına yazma, API'nin gerçek dönüşü); simülatörün veya LLM hakemin puanı yalnızca yardımcı sinyal olarak kullanılır, gerçek sonuçlarla korelasyonu düzenli olarak denetlenir ve şüpheli eylemleri cezalandıran yol kısıtlarıyla desteklenir. Bir adım ileride iki tür simülatörü ayırmak gerekir: arama gibi **gerçek bir karşılığı olan** simülatörlerde "melez" yol izlenebilir — etkileşimlerin çoğu simülasyonda geçer, aralara gerçek API çağrıları serpiştirilir ve simülatör bu gerçek çağrılarla düzenli olarak kalibre edilir (ZeroSearch'ün müfredat tarzı kalite düşürmesi gibi). Ama simüle kullanıcı söz konusu olduğunda eğitim sırasında **gerçek kullanıcı devreye sokulamaz**; "simüle kullanıcı gerçek kullanıcıya ne kadar benziyor" ayrı bir soruya dönüşür ve buna yalnızca canlıdan gelen trace'lerle yanıt verilebilir: canlıdaki gerçek kullanıcı davranışıyla simüle kullanıcının aynı durumdaki davranışını karşılaştırın, sistematik farkları bulun (gerçek kullanıcı üsteler, sabırsızlanır, konuşmayı aniden bitirir; simüle kullanıcı çoğu zaman bunları yapmaz) ve simülatörü buna göre sürekli kalibre edin. Canlıdaki gerçek metrikler aynı zamanda tek yayın eşiğidir — simülatördeki puan ne kadar yüksek olursa olsun sayılmaz.
+
+## Bölüm 9: Agent'ın Sürekli Evrimi
+
+**1. (★★) Bir deneyim dokümanı üç başarılı ve bir başarısız trajectory tarafından destekleniyor. Başarısızlık, API'nin daha yeni bir sürümünde gerçekleşmiş. Sistem bunun deneyimin çürütülmesi mi, yoksa uygulanabilirlik koşullarının değişmesi mi olduğuna nasıl karar vermelidir?**
+
+> Dört kanıt parçasını sayıya göre oylamak yerine önce API sürümüne, görev koşullarına ve ortam durumuna göre katmanlayın. Eski strateji yalnızca eski sürümde başarılı oluyor, yeni sürümde ise istikrarlı biçimde başarısız oluyorsa, deneyimin uygulanabilirlik kapsamını daraltın ve yeni sürüm için bir aday üretin. Aynı sürümde ve aynı ön koşullarda da başarısız oluyorsa güven düzeyini düşürün veya deneyimi geri çekin.
+
+**2. (★★) Müşteri hizmetleri Agent'ının kullanıcı memnuniyeti yükseliyor, ama kural ihlali oranı da yükseliyor. Memnuniyet neden tek başına öğrenme sinyali olarak kullanılamaz? Guardrail metriklerini nasıl tasarlardınız?**
+
+> Memnuniyet; kural dışı iadeleri, bilgi sızdırmayı veya aşırı vaatleri ödüllendirebilir, dolayısıyla yalnızca bir kalite metriği olabilir, güvenlik tabanının yerine geçemez. Guardrail'ler en azından kural ihlalini, gizlilik sızıntısını, kanıtsız ifadeyi, söz–eylem tutarsızlığını ve yetki aşımı içeren işlemleri kapsamalıdır. Bu metriklere, ortalama bir puanla telafi edilemeyecek katı eşikler konmalıdır; çözüm oranı, uyumlu alternatif çözümler, özlülük ve memnuniyet ise yalnızca uyumlu adaylar arasında karşılaştırılmalıdır.
+
+**3. (★★★) Aynı "asılsız söz" sorunu Prompt ile, Harness denetimiyle veya parametre eğitimiyle hafifletilebilir. Değişikliğin nereye yapılacağını hangi kanıtlara dayanarak seçerdiniz?**
+
+> Önce kök nedeni saptayın. Model aracın yürütülmediğini bildiği halde yine de tamamlanmış gibi bir ifade kullanıyorsa, en küçük bir Prompt kuralı bunu düzeltebilir. Vaat, yanıt metniyle araç durumunun deterministik karşılaştırmasıyla saptanabiliyorsa Harness denetimi daha güvenilirdir ve yüksek riskli senaryolarda son savunma hattı olarak kalmalıdır. Sorun çok sayıda ifade biçimine yayılıyorsa ve geniş bir dil–eylem hizalanması yeteneğine işaret ediyorsa, parametre eğitimi düşünülebilir. En küçük, doğrulanması ve geri alınması en kolay değişikliği tercih edin; karşılaştırmayı hem başarısızlık kümesinde hem de ayrı tutulan eski görev kümesinde yapın.
+
+**4. (★★★) Agent araçları ve doğrulayıcıları değiştirebilir, ama kendi güncellemesini onaylayan güven kökünü değiştirmemelidir. Bu iki parçanın yetki ve kod sınırlarını nasıl ayırırdınız?**
+
+> Evrilebilen kodu düşük ayrıcalıklı bir sandbox'a koyun ve yalnızca yama ile test üretmesine izin verin. İzin sistemi, API key'ler, yayın kontrolü yapılandırması ve güncelleme doğrulayıcıları güvenlik mekanizmasına aittir; sandbox'taki Agent'ın bunlar üzerinde okuma veya yazma yetkisi yoktur. Agent'ın ürettiği kod değişiklikleri, yayına alınmadan önce güvenlik mekanizması tarafından izole bir ortamda yeniden üretilip regresyon testinden geçirilmelidir.
+
+**5. (★★) Deneyim bilgi tabanı sürekli büyüdükçe retrieval hataları ve bilgi çatışmaları öğrenme kazancını götürür. Sürüm, güncellik ve eleme mekanizmalarını nasıl tasarlarsınız?**
+
+> Her deneyim kaydı; kaynak trajectory'sini, uygulanabilirlik koşullarını, ortam sürümünü, doğrulama zamanını ve güven düzeyini saklamalıdır. Çakışan kayıtlar sessizce birbirinin üzerine yazılmamalı, koşula göre dallandırılmalı veya işaretlenmelidir. Yinelenen kayıtları birleştirmek için düzenli aralıklarla "uyku öğrenmesi" çalıştırın.
+
+**6. (★★★) Parametre öğrenmesi doğal dil üslubunda başarılıdır, ama katı iş kurallarını güvence altına alması zordur. Tıbbi müşteri hizmetleri için parametre, bilgi, Skill ve kod kısıtlarının birlikte çalıştığı bir sürekli evrim tasarımı yapın.**
+
+> Parametreler (post-training'den geçmiş model), tıbbi dilin anlaşılmasından, doğal ve empatik ifadeden ve karmaşık niyet tanımadan sorumludur. Bilgi tabanı, kılavuzların en güncel sürümlerini, ilaç prospektüslerini ve kurum politikalarını saklar; yanıtların kaynak göstermesi zorunlu kılınır. Skill; anamnez bilgisi toplama, risk sınıflandırması, insana devretme ve takip süreçlerini tarif eder. Sunucu tarafındaki kod ise kimlik doğrulamayı, gizlilikte asgariliği, kontrendikasyon denetimini, acil risk yükseltmesini ve yetki sınırlarını zorunlu kılar. Üretim trajectory'leri önce tıbbi güvenlik, olgusal güvenilirlik, söz–eylem tutarlılığı ve ifade kalitesi açısından değerlendirilir, ardından dört sınıf aday güncelleme üretilir. Herhangi bir parametre veya süreç değişikliği, ayrı tutulan tıbbi güvenlik kümesinden ve insan incelemesinden geçmeden kademeli yayına (canary release) alınamaz.
+
+## Bölüm 10: Çoklu Agent İş Birliği
+
+**1. (★★) Paylaşılan context'li çoklu Agent iş birliğinde sonraki Agent, önceki Agent'ın eksiksiz context'ini devralır. Ama önceki Agent'ın biriktirdiği "düşünme ataleti" sonraki Agent'ın yargısını etkileyebilir — örneğin "gereksinim analisti" context'ini devralan bir "kod inceleyici", kod kalitesi açısından değil, hâlâ gereksinim açısından düşünmeye eğilimli olabilir. Roller arasındaki bu bulaşma nasıl saptanır ve nasıl ortadan kaldırılır?**
+
+> Tespit: bir LLM'e Agent trajectory'sini analiz ettirin ve yeni rolün hâlâ eski role "bürünmüş" gibi davranıp davranmadığını yargılatın. Ortadan kaldırma: aşama değişiminde system prompt ile araç kümesini birlikte değiştirin (soru sorma araçlarını kaldırıp linter/test araçlarını devreye alın) ve yeni kimliği pekiştirin. Context'in sonuna eklenen sistem durum çubuğunu kullanarak mevcut rol bilgisini güçlendirin. Rol karışması gerçekten giderilemiyorsa, context'i paylaşmayan bir iş birliği biçimine geçmeyi düşünün.
+
+**2. (★★) Yönetici modelinde görev ayrıştırması ve sonuçların birleştirilmesi Manager Agent'ın sorumluluğundadır. Ama Manager'ın kendi yetenek tavanı bütün sistemin yetenek tavanını belirler — Manager görevi doğru ayrıştıramazsa alt Agent'lar ne kadar güçlü olursa olsun işe yaramaz. Manager'ın ayrıştırma kalitesi nasıl güvence altına alınır?**
+
+> Plan-and-Act'in "zayıf planlayıcı sistemin darboğazıdır" sonucuna dayanarak en güçlü modeli Manager'a atayın. Harness tarafındaki önlemler: ayrıştırma çıktısı yürütülmeden önce bir inceleyici LLM tarafından çapraz doğrulansın; Manager'dan görevi ayrıştırırken her alt görev için açık kabul ölçütleri ve bağımlılıklar tanımlaması istensin.
+
+**3. (★★) Merkezsiz model, insan örgütlerinin en iyi uygulamalarından esinlenir. Ama insan örgütlerinin de sayısız başarısızlık kalıbı vardır — iletişimsizlik, sorumluluğu başkasına atma, hedef çatışmaları. Sizce Agent toplumunda en çok hangi "örgüt hastalıkları" görülür? Bunlar nasıl önlenir?**
+
+> MAST'ın üç ana sorun kategorisiyle karşılaştıralım: arayüzlerin belirsizliği ve sorumlulukların örtüşmesi; hedefin farklı anlaşılması ve bilginin akış aşağısında yanlış yorumlanması; "tamamlandı" diye yalan söylemek. Bunlara ek olarak hataların kaskat biçimde büyümesi (kulaktan kulağa oyunu), roller arasında döngüsel devretme ve Agent'lar arası grup sohbetinin dağılıp toparlanamaması sayılabilir. Önleme: sözleşmeli arayüzler ve tek tip mesaj zarfı, görev durum makineleri ve kabul doğrulaması, bağımsız bakış açılarıyla çapraz doğrulama, roller arası sorumluluk atma tespiti gibi yöntemler.
+
+**4. (★★★) Yönetici modelinde birden çok alt Agent paralel çalışırken, bir alt Agent'ın bulgusu diğerlerinin işini tümüyle anlamsızlaştırabilir (örneğin arama görevinde bir Agent yanıtı çoktan bulmuşsa). "Biri başarılı olursa herkes durur" ilkesini gerçekleştiren verimli bir kademeli sonlandırma mekanizması tasarlayın.**
+
+> Alt Agent yöneticiye `target_found` gönderir, yönetici de ardından `terminate` yayınlar; her alt Agent, ReAct döngüsündeki güvenli noktalarda sonlandırma sinyalini düzenli olarak kontrol eder ve zarif bir temizlikten sonra (tarayıcı oturumlarını kapatarak, kilitleri serbest bırakarak, yazmakta olduğu dosyayı tamamlayarak) sonlanır.
+
+**5. (★★★) Bu bölümde tanıtılan iyimser kilitleme mekanizması tek bir dosyadaki eşzamanlı yazma çakışmasını çözer, ama gerçek çoklu Agent sistemlerinde paylaşılan dosya sistemi ayrıca dosyalar arası anlamsal çakışmalarla, ad alanı kirlenmesiyle (Agent'ların gelişigüzel dosya yaratıp dizini karıştırması) ve tek nokta arızasıyla (bir Agent'ın yanlışlıkla bütün dosyaları silmesi) da karşılaşır. Daha eksiksiz bir dosya sistemi yönetişim mekanizmasını nasıl tasarlardınız?**
+
+> Bölümlere ayrılmış yönetişim: Tablo 10-4'teki dört alan türüne göre bölün, deneme-yanılma alanlarını özel scratchpad'lerle izole edin. Anlamsal çakışmalar: orkestrasyon katmanı dizin düzeyinde kilit dosyaları üzerinde uzlaşsın; değişiklik yapılmadan önce dizin kilidi denetlenip alınsın. İsim alanı kirliliği: dizin standartları ve adlandırma kuralları. Tek nokta arızası: bir sürüm kontrol sistemi kullanın; sürüm geçmişi geri alınabilir olsun ve izinler en aza indirilsin.
+
+**6. (★★★) Piyasa mekanizmasına dayalı Agent iş birliği (Pinchwork, RentAHuman) alışveriş ilişkilerini de getirir: bir Agent para ödeyerek başka bir Agent'ı (ya da insanı) işe alır. Peki işveren Agent, yürütücünün teslim ettiği sonucun kalitesini otomatik olarak nasıl ölçer? Yürütücü işi bitirdiğini söylerken işveren kaliteyi yetersiz buluyorsa, anlaşmazlığı kim karara bağlar? Kötü paranın iyi parayı kovması nasıl önlenir?**
+
+> Kabul, yalnızca Agent trajectory'sini okumaktan ibaret olamaz; test çalıştırma, render edilmiş ekran görüntüleri ve araçla doğrulama gibi deterministik dış doğrulamalar kullanılmalıdır; üretme–doğrulama arasındaki zorluk asimetrisinden yararlanarak kabul maliyeti düşürülür. Anlaşmazlıkları bağımsız, üçüncü taraf bir inceleyici Agent çözer; buna emanet hesabı (escrow) eşlik eder. Kötü paranın iyi parayı kovmasına karşı: geçmiş teslimatlara dayalı bir itibar sistemi kurun ve fiyat sinyalini kaliteye bağlayın.
+
+**7. (★★) RentAHuman, Agent'ların kripto parayla insan işe almasını sağlayarak geleneksel insan-makine ilişkisini tersine çevirir. Bu model yaygınlaşırsa, insan Agent ekonomisinde hangi rolü üstlenir? Yalnızca Agent'ın yapamadığı fiziksel görevleri yerine getirmek mi?**
+
+> Yalnızca Agent'ın yapamadığı fiziksel görevleri yerine getirmezler. İnsanlar ayrıca Agent'ın üretim anında erişemediği yeni bilgiyi de sağlar: sahadaki algı ve gerçek dünyadan gelen geri bildirim. Nihai kabul edici ve anlaşmazlık hakemi olurlar; hukuki ve sorumlu özne olarak yetkilendirmeyi ve hesap verebilirliği üstlenirler; hedefleri belirleyip değer yargısında bulunurlar ve bilgi asimetrisinin bulunduğu yerlerde, ahlaki sınırlarda denge unsuru işlevi görürler.
+
+**8. (★★) İnsan toplumunun iş bölümüne ve iş birliğine ihtiyaç duymasının nedeni her insanın yeteneğinin sınırlı olmasıdır — frontend yapan mutlaka backend bilmez, tasarım bilen mutlaka sistem yönetimi yapamaz. Oysa büyük model daha çok bir "her işi bilen" gibidir. İlgili araştırmalar, salt metin akıl yürütme görevlerinde çoklu Agent tartışmasının eşit hesaplama kaynağı altında tek Agent'tan üstün olmadığını gösteriyor. Öyleyse tek Agent yerine birden çok Agent kullanmanın gerçek üstünlüğü tam olarak nerededir?**
+
+> 1. Dış geri bildirimi devreye sokar: yürütme sonuçları, görsel ekran görüntüleri gibi — üretim anında var olmayan yeni bilgiyi getirir.
+> 2. Farklı hedeflere ve farklı rol tanımlarına sahip birden fazla Agent, insan toplumundaki gibi birbiriyle tartışıp yarışarak tek bir Agent'ın düşünce tuzağına düşmesini engelleyebilir.
+> 3. Çoklu Agent'ın context izolasyonu, context penceresi sınırını aşarak çok uzun tool call zincirlerini mümkün kılar.
+
+**9. (★★★) Bu bölüm "paylaşılan context" ile "context paylaşmamayı" çoklu Agent sistemlerinin temel tasarım boyutu olarak ele aldı. Paylaşılan context bütün Agent'ların aynı bilgiyi görmesini sağlar ve koordinasyon için daha elverişli görünür. Ama Üç Cisim Problemi romanındaki Üç Cisim uygarlığında düşünce tümüyle saydamdır, buna karşın teknolojik gelişme durgunluğa saplanır; ataç maksimizasyonu düşünce deneyi de bir topluluk tek bir hedefe yöneldiğinde çeşitliliğin yitirildiğini gösterir. Çoklu Agent sistemlerinde verim ile çeşitlilik arasındaki denge nasıl kurulur?**
+
+> Tam paylaşım düşünce ataletini ve hata kaskatlarını büyütür; bilişsel çeşitlilik ancak izolasyonla doğar. Yöntemler: farklı prompt'lar ve modeller kullanarak düşünce eğilimleri yaratmak (brainstorm, debate); çapraz doğrulayıcıların önceki düşünme sürecine değil yalnızca ham kanıta bakması.
+
+**10. (★★★) Bir Kodlama Agent'ına 30 adımlık ve 300 adımlık bütçe verildiğinde, çalışma stratejisi nasıl farklılaşmalıdır? Araştırmalar, adım bütçesini artırmanın tek başına performans artışını güvenceye almadığını gösteriyor — Agent sığ bir aramadan sonra erkenden "doyuma" ulaşıyor. Agent'ın küçük bütçede çekirdek işlevi hızla gerçekleştirdiği, büyük bütçede ise planlama, test ve inceleme adımlarını ekleyerek fazladan hesaplama kaynağını sonuna kadar kullandığı bir "bütçe farkındalığı" mekanizması tasarlayın.**
+
+> Mekanizma: her adımda prompt'a toplam bütçeyi ve kalan bütçeyi enjekte edin, kalan orana göre keşif/kullanım ağırlığını dinamik olarak ayarlayın. Örneğin küçük bütçede (30 adım): planlamayı ve incelemeyi atlayıp doğrudan çekirdek işleve ve temel doğrulamaya gidin. Büyük bütçede (300 adım): önce planlayın, sonra uygulayın, sonra test edin, sonra inceleyip iyileştirin; ilerlemeyi değerlendirmek için kilometre taşlarına kontrol noktaları koyun ve sığ doygunluğu önleyin.
+
+**11. (★★) Tablo 10-3, çoklu Agent sistemlerini işletim sistemleriyle satır satır eşleştiriyor. Bu tabloyu birkaç satır daha uzatın: sanal bellek ve sayfalama, dosya izinleri, kilitlenme (deadlock) algılama, zamanlama algoritmaları — bunların Agent dünyasındaki karşılıkları nedir? Hangi işletim sistemi kavramlarının Agent dünyasında karşılığı yoktur, neden?**
+
+> Olası uzantılar: sanal bellek/sayfalama ↔ context sıkıştırma ve retrieval (sıcak bilgi pencerede kalır, soğuk bilgi dosyalara ve bellek deposuna takas edilir, gerektiğinde geri alınır); dosya izinleri ↔ araç beyaz listeleri, salt okunur bağlamalar, kimlik bilgisi sınırları; kilitlenme tespiti ↔ döngüsel devretmenin ve karşılıklı beklemenin tespiti (devir sayısı üst sınırı, zaman aşımı); zamanlama algoritmaları ↔ asenkron olay işleme (Bölüm 4). Karşılığı bulunmayan yerlerin kaynağı, zorlayıcılığın farklı olmasıdır: bir sürecin komutları donanım tarafından zorla yürütülür, Agent ise prompt'a yalnızca yüksek olasılıkla uyar.