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. (★★★) ReAct döngüsünde, Agent'ın her bir LLM çağrısı eksiksiz geçmiş trajectory'yi görür. Trajectory büyüdükçe bu tasarımın maliyeti karesel olarak büyür. Bu karesel büyüme, kritik bilgi kaybedilmeden kırılabilir mi?

Uygulanabilir yöntemler: context sıkıştırma — erken trajectory'yi özetleyip yalnızca sonuçları ve kritik durumu tutmak (Bölüm 2'deki çok katmanlı sıkıştırma); externalized learning — ara sonuçları dosyalara veya bilgi tabanına yazmak ve context'te sürekli tutmak yerine ihtiyaç oldukça getirmek; işi alt Agent'lara bölmek.

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 aksine arttığını savunuyor. Bu iki eğilim nasıl bir arada var olabilir? Agent çerçevelerinin gelecekteki temel değeri hangi yönlerde ortaya çıkar?

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 sonsuz 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 makul olup olmadığını değerlendirin. Bu yapay zeka ürününü siz tasarlıyor olsaydınız, hangi iyileştirme alanları olurdu?

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, çok 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 yol açar. KV Cache ön ekini bozmadan, bilgi kaybını önlerken context uzunluğunu da 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 tur 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 R1 bir zamanlar tüm geçmiş düşünmenin çıkarılmasını şart koşuyordu; DeepSeek V4 ise bunu tersine çevirerek tüm reasoning_content'in zorunlu olarak geri gönderilmesini dayattı — bu iki karşıt stratejiyi karşılaştırın: her birinin artıları ve eksileri neler? Bu tersine dönüş neyi gösteriyor?

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 inildi — 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, bilgi organizasyonundaki düzensizliğin 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ın bakımı genellikle farklı zamanlarda birden fazla kişi tarafından 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ı, eksiksiz içeriği yalnızca Agent gerekli olduğuna karar verdiğinde 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 prompt'u SKILL dosyasından 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. (★★★) Agentic RAG, Agent'ın ne zaman arama yapacağına, ne arayacağına ve aramaya devam edip etmeyeceğine aktif olarak karar vermesine izin verir. Ama model neyi bilmediğini bilmiyorsa, bir aramayı doğru biçimde tetikleyemez. Bu "üst biliş (metacognition)" sorunu nasıl çözülebilir?

① "Bilginin yeterli olup olmadığını değerlendir" adımını prompt/skills içinde açık bir adım olarak sabitleyin: Deney 3-9'da olduğu gibi önce alt soruları paralel biçimde getirin, "sabıka kaydının taksirli suçlarda ceza miktarını nasıl etkilediği" bağlantısının eksik olduğunu fark edin ve ikinci bir retrieval turu çalıştırın. ② Hafif meta bilgiyi context'te sürekli tutarak genel bir görüş sağlayın: örneğin JSON Cards genel görünümü veya OpenViking'in L0/L1 özetleri — böylece Agent "depoda ne olduğunu" bilir.

4. (★★) Ç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.

5. (★★★) 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.

6. (★★★) 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.

7. (★) 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.

8. (★★) 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.

9. (★★★) 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.

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 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. (★★) 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 maliyeti nedir?

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.

3. (★★) MCP ekosisteminde, farklı MCP sunucuları yüksek oranda örtüşen işlevselliğe sahip araçlar sağlayabilir. Bir Agent, işlevsel olarak benzer ama farklı kaynaklardan gelen birden fazla araçla karşılaştığında nasıl seçim yapmalıdır? Farklı kaynaklardan gelen aynı adlı 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.

4. (★★★) 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 hangi 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ş?

5. (★★) 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).

6. (★★) 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 kendi maliyetinin veya riskinin işlemin kendisininkini aştığı, yani 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.

7. (★★) 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 düşüyor. Proaktif araç keşfinin yanı sıra başka hangi yaklaşımlar var? İnsan uzmanların çok sayıda mevcut araçla 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 — "zekânı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 ettiği 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 damıtılırsa, kural kümesi zamanla durmadan şişecektir. Birikmiş kurallar üzerinde "çöp toplama" nasıl yapılabilir — gereksiz veya güncelliğini yitirmiş girdiler nasıl belirlenip temizlenir? Başarılı tek bir kod değişikliği neden doğrudan Bölüm 8'de anlatılan sürekli evrim sayılamaz?

Çö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 tarafından üretilen SQL veya frontend kodunun kullanıcının tarayıcısında veya veritabanında doğrudan yürütülmesine izin verir. Ancak ü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?

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ın içinde veritabanı gerçeğine dayalı doğrulamalar olarak kodlamak ve modeli çağrı öncesinde politika koşullarını denetlemeye yönlendirmek için parametre tasarımını kullanmak, özünde Agent davranışını kod yapısıyla kısıtlamaktı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.

10. (★★) Artifact kalıbı, bir Agent'ın SQL veya görselleştirme kodu üretmesine izin verir; bu kod 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ı verir" kalıbına kıyasla artıları ve eksileri nelerdir?

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.

Bölüm 6: Agent'ların Değerlendirilmesi¶

1. (★★) LLM-as-a-Judge, bir dil modelinin çıktısını değerlendirmek için yine bir dil modeli kullanır. Bu "kendi kendini değerlendirme" sistematik kör noktalar taşır mı — örneğin model belirli bir üsluptaki yanıtlara tutarlı biçimde yüksek puan verebilir ve bu tercih insan yargısıyla örtüşmeyebilir mi? Böyle bir yanlılık nasıl tespit edilip 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 karşı" tasarımı kritik önemdedir. Ama açık kaynak ekosisteminde bir benchmark verisi yayımlandığı anda hızla eğitim verisine dahil ediliyor. 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ı örtme, standart önem ağırlıklandırması, kendi kendine yeten değerlendirme) değerlendirmedeki öznelliği ortadan kaldırmayı amaçlar. Ancak bazı görev boyutları (örn. "yanıt yardımcı oldu mu", "ton uygun mu") doğası gereği özneldir. Bu öznel boyutlar için güvenilir Rubric'ler 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 kullanıcının kendisi de bir LLM'dir — belirli sınır durumlarını (örn. duygusal olarak gergin ya da kendini net ifade edemeyen kullanıcıları) sistematik olarak hafife alabilir. Simüle kullanıcının kendi 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). Ne var ki insan tercihleri geçişliliği sık sık 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 "gözlem → hipotez → deney → doğrulama" bilimsel yöntemini öneriyor. Ancak pratikte Agent'ın davranış uzayı çok geniştir 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 maksimize edilir?

Ö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.

7. (★) 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.

8. (★★) τ-bench'in kullanıcı simülasyonu "kademeli bilgi açığa çıkarma" kullanır — tüm bilgiyi bir kerede vermek yerine Agent'ın sorularına göre adım adım açar. Bu tasarım değerlendirme sonuçlarını nasıl etkiler? Simüle kullanıcının bilgi açığa çıkarma stratejisi gerçek kullanıcılarınkinden 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 7: Model Post-Training¶

1. (★★) Katastrofik unutma — belirli bir göreve yönelik tek bir fine-tuning'in modelin mevcut genel yeteneklerini (örneğin genel tool calling'i) bozması — Agent senaryolarında özellikle can sıkıcıdır. Tam parametre fine-tuning'ine kıyasla LoRA temel ağırlıkları dondurur ve unutma riski daha düşüktür, ama bağışık değildir. Fine-tuning'in getirdiği yetenek unutması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 yetenekleri model ağırlıklarına sabitler ("kas hafızası"), bağlam içi öğrenme ise bilgiyi çıkarım anındaki girdiye koyar. Ne var ki bazı yetenekler (örneğin alan bilgisi) hem post-training ile öğrenilebilir hem de few-shot örneklerle sağlanabilir. Belirli bir yeteneğin hangi yoldan gitmesi gerektiğine hangi ölçütlerle karar verirdiniz?

Ö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 bir modelin büyük bir modelin davranışını öğrenmesini sağlar. Yetenek düzeyine göre damıtılan modeller kabaca üç kademeye ayrılabilir: Chat modelleri (tek turlu diyalog, doğrudan yanıt), Reasoning modelleri (uzun düşünce zinciriyle düşünüp sonra yanıtlama) ve Agentic modeller (çok turlu araç çağırma, ortamla etkileşim). Bu üç model türünü damıtırken zorluklar nasıl farklılaşır?

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şimlerinde ödül atfetme (credit assignment) sorunu tek turluya göre çok daha ciddidir — nihai bir başarı ya da başarısızlığı 3. turdaki mi yoksa 7. turdaki karara mı bağlayacağınızı kestirmek zordur. Ödül dağıtım stratejisini nasıl tasarlardı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 olsa (örneğin 10.000 dolar) ve bir müşteri hizmetleri Agent'ının performansını artıracak olsanız, bu bütçeyi context ve bilgi, Prompt/Skills, program kısıtları ve parametre eğitimi arasında nasıl paylaştırırdınız? Kararınız hangi etkenlere bağlı olurdu?

Ö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. (★★★) Açık bir ödül fonksiyonunun bulunmadığı ve örneklerin kıt olduğu koşullarda modelin öğrenmeyi kendi başına gerçekleştirmesi, bazılarınca post-training'in nihai hedefi sayılıyor. Mevcut RL eğitim yöntemleri bu hedeften ne kadar uzakta? Bir sonraki atılımın en çok hangi yönden gelmesini bekliyorsunuz?

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 fine-tuning'in maliyetinin yüksek olmadığını belirtiyor. Peki her kullanıcı (ya da her müşteri şirket) için, kullanıcı belleğini veya kurumsal bilgiyi Bölüm 3'teki gibi harici bir bilgi tabanında saklamak yerine parametrelere yazan özel bir LoRA eğitmek mümkün mü? Hangi senaryolarda "belleği parametrelere yazmak", "belleği bilgi tabanında saklamaktan" üstündür? Hangi senaryolarda ise ters teper?

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 teacher modele dayanır. Ne var ki OpenAI'ın Weak-to-Strong Generalization araştırması sezgiye aykırı bir bulgu ortaya koydu: zayıf bir modelin denetim sinyali, güçlü modelin kendisinde gizli kalmış ama etkinleşmemiş yetenekleri bazen açığa çıkarabiliyor. Bu fikir Agent eğitimine uygulanırsa, "küçük model büyük modeli eğitir" biçiminde tersine 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 hangisi ödüllendirilmeye daha layıktır: "doğru sürecin yanlış sonuca götürmesi" mi, yoksa "yanlış sürecin şans eseri doğru sonuca varması" mı? Bir Agent'ın çok adımlı tool calling senaryosunda bu ödünleşimi nasıl kurardı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 tartışılan değerlendirme veri kümeleri (SWE-Bench Verified, τ²-bench, AndroidWorld gibi) hem değerlendirme hem de post-training için kullanılabilir. Ama bir değerlendirme kümesi eğitimde kullanılırsa artık bağımsız bir değerlendirme kümesi olmaktan çıkar — bu, eğitim kümesi ile test kümesinin ayrı olması gerektiği temel ilkesini ihlal etmez mi? τ²-bench'in dinamik parametre üretimi ve AndroidWorld'ün parametreleştirilmiş şablonları bu sorunu bir ölçüde hafifletiyor, ama şablon yapısının kendisi hâlâ sabit. Değerlendirme verisinin eğitim değerinden tam olarak yararlanmakla değerlendirmenin bağımsızlığını korumak arasında denge nasıl kurulur?

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" eğitim paradigmasını öneriyor: SFT'yi "format kararlı, temel yetenek oluştu" noktasında bırakın, ardından RL'e geçin. Ama pratikte SFT'nin "yeterli" olduğuna ve geçiş zamanının geldiğ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 dinamikleri (bkz. Deney 7-15), az sayıdaki aşırı uzun yanıtın tüm eğitim döngüsünü belirgin biçimde uzattığını gösteriyor — bir rollout partisindeki yanıtların büyük çoğunluğu çoktan üretilmişken o birkaç en uzun yanıtın bitmesi beklenir ve bu sırada kümedeki GPU kullanımı çok düşüktür. Bu tür uzun kuyruklu yanıt senaryolarında eğitim kümesinin 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. (★★★) Bir Agent'ı LLM ile simüle edilmiş ortamlarda (simüle arama motoru, simüle kullanıcı gibi) eğitirken, Agent'ın açık aradığı nesne "gerçek ortamın kurallarından" "simülatörün kendi yanlılıkları ve açıklarına" kayar. Bu tür eğitimde hangi somut reward hacking davranışları ortaya çıkabilir? Bunlara karşı nasıl önlem alınır?

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 8: Agent'ın Sürekli Evrimi¶

1. (★★) Bir deneyim dokümanı, üç başarılı ve bir başarısız trajectory ile destekleniyor. Başarısızlık, API'nin daha yeni bir sürümünde yaşanmış. Sistem, bunun deneyimin çürütülmesi mi yoksa uygulanabilirlik koşullarının değişmesi mi olduğuna nasıl karar vermeli?

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. (★★) Bir müşteri hizmetleri Agent'ında kullanıcı memnuniyeti yükseliyor, ama kural ihlali oranı da yükseliyor. Memnuniyet neden tek başına öğrenme sinyali olamaz? 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ı "sahte vaat" 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. (★★★) Bir Agent araçları ve doğrulayıcıları değiştirebilir, ama kendi güncellemelerini onaylayan güvenlik mekanizmasını değiştirmemelidir. Bu iki parçanın izin 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 çakışmaları öğrenme kazancını götürür. Sürüm, güncellik ve eleme mekanizmalarını nasıl tasarlardı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ı garanti edemez. Tıbbi müşteri hizmetleri için parametre, bilgi, Skill ve kod kısıtlarının birlikte çalıştığı bir sürekli evrim şeması tasarlayı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 9: Multimodal ve Gerçek Zamanlı Etkileşim¶

1. (★★) Sesli Agent'ların uçtan uca modeli ASR-LLM-TTS'yi tek bir modelde birleştirir; bu gecikmeyi düşürür ama modülerliği yitirir. Uçtan uca model bir aşamada (örneğin konuşma tanımada) hata yaparsa, hata ayıklama ve düzeltme seri boru hattına kıyasla çok daha zordur. Uçtan uca bir sesli Agent için observability (gözlemlenebilirlik) 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.

2. (★) Step-Audio R1, MPS çift beyin mimarisiyle "düşünürken konuşmayı" gerçekleştirir. Ne var ki insanlar "düşünürken konuşurken" sık sık üzerinde düşünülmemiş şeyler söyler, kendilerini düzeltir ya da dolgu sözcükleri kullanır. Agent'ın "düşünürken konuşması" insanın bu özelliklerini 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.

3. (★★) SoM (Set-of-Mark) ve yapılandırılmış türevleri (DOM eleman indeksleme), Computer Use'daki görsel konumlandırmayı açık uçlu koordinat tahmininden kapalı kümeden ID seçimine dönüştürür; ama hepsi arayüz elemanlarının önce tespit edilip etiketlenmesini gerektirir — ister segmentasyon modeliyle ister DOM üzerinden. Arayüz standart dışı arayüz bileşenleri veya dinamik olarak değişen elemanlar içeriyorsa, etiketleme eksik ya da yanlış olabilir. Bu durumda koordinat tahminine geri dönülmeli 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.

4. (★★) XLeRobot gibi bin dolarlık 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, bir VLA modelinin eğitimini nasıl etkiler? Veri toplama aşamasında düşük kaliteli veri otomatik olarak nasıl elenir?

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 7'deki yargıyı yankılar: veri, mimariden daha kritiktir.

5. (★★★) Bu bölüm ses, Computer Use ve robot olmak üzere üç etkileşim biçimini kapsıyor. Bu üç biçimin ortak eğilimi, seri boru hatlarından uçtan uca modellere doğru evrilmeleridir. 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.

6. (★★★) Bugünkü Computer Use "ekran görüntüsü → eylem → ekran görüntüsü" biçiminde ayrık bir döngüyle çalışır ve her gözlem statik bir karedir. Oysa insanın ekran algısı süreklidir — animasyonun oynadığını görürüz, yükleme ilerleyişini izleriz, video içeriğini anlarız. Bu da bugünkü Computer Use'un, zamansal görsel anlama gerektiren görevleri hiç ele alamadığı anlamına gelir. Sürekli görsel akış anlamayı desteklemek için algı katmanını nasıl yeniden tasarlardınız?

"Gözlem arayüzünün" yeniden tasarlanması gerekir: video içeriğindeki anahtar kareler çıkarılıp modele verilmeli, yalnızca son kare sunulmamalıdır. AOI (Agent Observation Interface) makalesine bakılabilir.

7. (★★) DOM/Accessibility Tree eleman indeksleme standart web uygulamalarında belirgin biçimde işe yarar, ama giderek daha çok yazılım arayüzü (Canvas/WebGL ile render edilenler, platformlar arası kendi çizimini yapan arayüz bileşenleri) erişilebilir yapılandırılmış bilgi sunmuyor; geriye yalnızca görsel etiketleme veya koordinat tahmini kalıyor. Sizce Computer Use saf görsel yola mı oynamalı, yoksa yapılandırılmış ve görsel olmak üzere 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.

8. (★★) VLA modelleri action chunking (eylem parçalama) kullanır — metinde anlatıldığı gibi, π₀'ın tipik yapılandırması 50Hz frekansta bir defada 25-50 gelecek eylem üretir — ve böylece çıkarım gecikmesini yürütme süresinin içine gizler. Ama yürütme sırasında ortam ani biçimde değişirse (örneğin bir nesne yerinden alınırsa), önceden üretilmiş eylem dizisi geçersizleşir. Action chunking'in verimlilik üstünlüğü ile ortam değişikliğine tepki hızı arasında denge nasıl kurulur?

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.

9. (★★★) Bu bölümdeki üç senaryo da (ses, Computer Use, robot) "algıla-düşün-eyle" döngüsünün gecikme sorunuyla karşı karşıyadır ve hepsi hızlı ile yavaş düşünmenin paralelleştirilmesi yönünde evriliyor. Ses senaryosunda bu "yanlış söyleyip sonra düzeltme", Computer Use senaryosunda "önce tıkla sonra bak", robot senaryosunda ise "bir adım at sonra bak" biçiminde görünür. Hızlı düşünmeye dayanan bu eylemlerin geri alınamaz sonuçlara yol açmayacağı nasıl güvence altına alınır?

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.

Bölüm 10: Çoklu Agent İş Birliği¶

1. (★★) Context'in paylaşıldığı çoklu Agent iş birliğinde, sonraki Agent'lar önceki Agent'ların eksiksiz context'ini devralır. Ama önceki Agent'ın biriktirdiği "düşünce ataleti" sonraki Agent'ları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 karışma nasıl tespit edilip 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 kalıbında, Manager Agent görev ayrıştırmadan ve sonuçları birleştirmekten sorumludur. Ama Manager'ın kendi yetenek tavanı tüm sistemin yetenek tavanını belirler — Manager görevi doğru ayrıştıramazsa, alt Agent'lar ne kadar güçlü olursa olsun bir 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. (★★) Merkezsizleştirilmiş kalıp, insan örgütlerinin en iyi pratiklerinden yararlanır. Ama insan örgütlerinin de çok sayıda başarısızlık kalıbı vardır: iletişimsizlik, sorumluluktan kaçma, hedef çatışmaları. Sizce bir Agent toplumunda hangi "örgütsel hastalıklar" ortaya çıkabilir? 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 kalıbında birden fazla alt Agent paralel çalışırken, bir alt Agent'ın bulgusu diğerlerinin işini anlamsız kılabilir (örneğin bir arama görevinde bir Agent cevabı çoktan bulmuştur). "Biri başarırsa herkes durur" ilkesini gerçekleştiren verimli bir kaskat 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 (optimistic locking) mekanizması tek bir dosyadaki eşzamanlı yazma çakışmalarını çözer; ama gerçek bir çoklu Agent sisteminde paylaşılan dosya sistemi, dosyalar arası anlamsal çakışmalar, isim alanı kirliliği (Agent'ların gelişigüzel dosya oluşturması sonucu dizinin karmakarışık olması) ve tek nokta arızası (bir Agent'ın yanlışlıkla tüm dosyaları silmesi) gibi sorunlarla 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 dayanan Agent iş birliği (Pinchwork, RentAHuman) ticari ilişkileri devreye sokar: bir Agent, bir görevi tamamlaması için başka bir Agent'a (ya da bir insana) para öder. 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 tamamladığını iddia ederken işveren kaliteyi yetersiz buluyorsa, anlaşmazlığı kim çözer? 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 para aracılığıyla insan kiralamasına izin vererek geleneksel insan-makine ilişkisini tersine çeviriyor. Bu model yaygınlaşırsa, insanlar Agent ekonomisinde hangi rolü oynar? Yalnızca Agent'ın yapamadığı fiziksel görevleri mi yerine getirirler?

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 çok kişili iş bölümüne ve iş birliğine ihtiyaç duymasının nedeni, her insanın yeteneklerinin sınırlı olmasıdır — frontend yapan mutlaka backend bilmez, tasarımdan anlayan mutlaka operasyon yapamaz. Ama büyük modeller daha çok bir "her işi bilene" benzer. İlgili araştırmalar, saf 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 fazla Agent kullanmanın gerçek üstünlüğü tam olarak nerededir?

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.

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.

Ç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, "context paylaşımı" ile "context paylaşmama" ayrımını çoklu Agent sistemlerinin temel tasarım boyutu olarak ele alıyor. Context paylaşımı tüm Agent'ların aynı bilgiyi görmesini sağlar ve koordinasyona daha elverişli görünür. Ne var ki Üç Cisim Problemi'ndeki Trisolarisliler'in düşünceleri tümüyle şeffaftır, ama teknolojik gelişmeleri durgunluğa saplanmıştır; ataç düşünce deneyi de bir topluluk aynı hedefe yöneldiğinde çeşitliliğin yitirildiğini gösterir. Çoklu Agent sistemlerinde verimlilik ile çeşitlilik arasında 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ı? Araştırmalar, adım bütçesini yalnızca artırmanın performans artışını garanti etmediğini gösteriyor — Agent sığ bir aramanın ardından erkenden "doyuma" ulaşıyor. Agent'ın küçük bütçede çekirdek işlevi hızla gerçekleştirmesini, büyük bütçede ise planlama, test ve inceleme aşamaları ekleyip fazladan hesaplama kaynağını tam olarak kullanmasını sağlayan 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. (★★) Bu bölüm "erken sonlandırmayı" üçe ayırıyor: tembellik kaynaklı sahte tamamlama, erken vazgeçme ve sahte başarı. Üç sorunun çözümü neden farklı yollardan aynı yere, doğrulamaya çıkıyor?

Ortak kök neden: görevin bitip bitmediğine modelin kendi beyanı karar veriyor; "tamamlandı" bir kanıt değil, yalnızca bir iddiadır. Doğrulayıcının koşulları: ① gerçek gözleme dayanmalı (testleri çalıştırmak, ekran görüntüsü render etmek, iadenin gerçekten hesaba geçip geçmediğini sorgulamak); ② açık bir tamamlanma tanımıyla madde madde karşılaştırmalı — bu, tembellik kaynaklı sahte tamamlamayı ve sahte başarıyı yakalar; ③ başarısızlık sonuçları da aynı şekilde doğrulanmalı — bu da erken vazgeçmeyi yakalar; ④ açık sonlandırma koşullarıyla (tur/bütçe üst sınırı) birlikte kullanılmalı ki erken sonlandırmadan öbür uca, yani kontrolden çıkan bir döngüye kayılmasın.

12. (★★) 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) tespiti ve zamanlama algoritmaları Agent dünyasında neye karşılık gelir? Ayrıca hangi işletim sistemi kavramlarının Agent dünyasında karşılığı yoktur ve 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.