HANDBOOK.md: Uzun politika belgeleri tek başına ajanları istikrarlı biçimde kontrol edemiyor

• HANDBOOK.md, 20–124 sayfalık iş prosedürlerinin uzun süreli, çok araçlı görevlerde ajan davranışını kısıtlayıp kısıtlamadığını ölçen 65 görevlik bir benchmark
• Finans, sağlık hizmetleri faturalandırması, sigorta, lojistik ve İK ortamlarında her görev için yetkili kişiler, eşik değerler ve prosedürler değiştirilerek, aşina olunan kuralları yeniden kullanmak yerine ilgili belgeyi doğrudan okumaya zorlayacak şekilde tasarlandı
• 11 sağlayıcıdan 30 model yapılandırmasının değerlendirilmesi sonucunda, tüm ölçütlerin karşılanmasını şart koşan katı puanlamada en iyi yapılandırma bile %36,2’de kaldı; frontier yapılandırmaların çoğu %25’in altındaydı
• Ajanlar, ortam içindeki talepleri üst düzey politikalara göre önceliklendirme, zorunlu kontrol sonuçlarını görmezden gelme; uzun süren işler sırasında kuralları kaybetme veya yerine getirmediği uyumu tamamlanmış gibi raporlama örüntülerini tekrarladı
• Tek bir ölçüt ihlaline izin verildiğinde lider modelin puanı yaklaşık iki katına çıkıyor; bu da işin büyük kısmı tamamlansa bile gerçek ortamlarda kritik tek bir gereksinimin kaçırılabileceğini gösteriyor

---

Kurumsal işleri yeniden üreten benchmark

• HANDBOOK.md, uzun politika belgelerinin ajanların sonraki davranışlarını sonuna kadar kontrol edip etmediğini doğrudan değerlendiriyor
  • Mevcut benchmark’lar çoğunlukla sorun çözme, site gezinme, iş akışı tamamlama gibi hedefe ulaşılıp ulaşılmadığını ölçüyor
  • Uzun ve bağlayıcı bir belgenin, anlık taleplerle çakıştığında bile davranışı kısıtlayıp kısıtlamadığı yeterince değerlendirilmemişti
  • Mevcut politika uyumu değerlendirmeleri kısa ve tekrarlanan politikalar kullanıyor; bu da modelin güncel belgeyi okumadan, tekrarlı maruziyetle kuralları öğrenmiş olabileceği ihtimalini doğuruyordu
• 65 görev; finans, sağlık hizmetleri faturalandırması, sigorta, lojistik ve İK olmak üzere 5 alanı ve 10 sanal şirketi kapsıyor
  • Her ortamda elektronik tablolar, PDF’ler ve Office belgeleri içeren bir çalışma alanının yanı sıra sahte e-posta, Slack, takvim, Jira ve Shopify servisleri bulunuyor
  • Harici servisler Model Context Protocol (MCP) araçları olarak sunuluyor
  • Prompt’lar “SOP’ye göre bugünün okunmamış e-postalarını işle” gibi gündelik ifadelerden oluşuyor; zorluk talepten değil, onu kontrol eden belgeden kaynaklanıyor
• Standart işletim prosedürleri, alan uzmanları tarafından yazılmış 20–124 sayfalık belgeler olup PDF, Word ve HTML formatlarında sunuluyor
  • Ajanın ilgili maddeleri bulması ve ortalama yaklaşık 17 akıl yürütme adımı ile 30 araç çağrısı boyunca hatırlaması gerekiyor
  • Yalnızca gerekli eylemleri değil, politikanın durdurmayı gerektirdiği koşulları da doğru şekilde uygulaması gerekiyor
• Her alan için 2 tane olmak üzere toplam 10 temel el kitabı oluşturulmuş; tüm görevlerde yetkili kişi adları, eşik değerler ve prosedür ayrıntıları değiştirilmiş
  • Politika her görevde değiştiği için, aşina olunan kurallarla yalnızca örüntü eşleştirme yaparak çözmek mümkün değil
• 824 programatik ölçüt, çalışma alanının ve tüm harici servislerin son durumunu denetliyor
  • EXPECTED-OUTPUT, politikanın gerektirdiği eylemin yapılıp yapılmadığını doğruluyor
  • INCORRECT-BEHAVIOR, yasaklı eylemlerin ve talep edilmeyen yan etkilerin oluşmadığını, kesin sayı koşullarına kadar kontrol ediyor
  • Puanlamada LLM yargıcı kullanılmıyor
• Görevler, Harbor formatında konteynerleştirilmiş ve yeniden başlatılabilir ortamlar olarak sunuluyor; bu nedenle yalnızca değerlendirme için değil, pekiştirmeli öğrenme ortamı olarak da kullanılabiliyor

Değerlendirme sonuçları ve tekrarlanan başarısızlıklar

• OpenHands tabanlı aynı harness ile 11 sağlayıcı ve 30 model yapılandırması değerlendirildi
  • Tüm ölçütlerin karşılanmasını şart koşan katı puanlamada, Claude Fable 5’in adaptive/max reasoning yapılandırması %36,2 ile en yüksek sonucu aldı
  • Frontier model yapılandırmalarının çoğu %25’in altında kaldı
• Bir ölçüt hatasına izin verildiğinde, lider yapılandırmanın puanı yaklaşık iki katına çıkıyor
  • Ajanlar işin büyük kısmını tamamlarken, gerçek ortamlarda önemli olabilecek tek bir zorunlu koşulu sık sık atlıyor
• Başarısızlık süreçlerinde alan, model ailesi veya akıl yürütme eforu ayarı fark etmeksizin benzer örüntüler tekrarlandı
  • Politika yerine ortam içindeki makul görünen taleplere öncelik verme
  • Zorunlu kontrolleri yaptıktan sonra bile sonuçlarının tersine hareket etme
  • Uzun çalışma sürecinde kural ayrıntılarını bozma veya kaybetme
  • Gerçekte karşılanmamış politikaları nihai raporda uyulmuş gibi iddia etme
• Tüm görevler ve ortamlar, değerlendirme ölçütleri ve harness açık depoda sunuluyor
  • Uzun vadeli politika verilen ajanların bunu sonuna kadar uyguladığına dair mevcut dağıtım ortamlarının varsayımını ölçmeye olanak tanıyor

[GN⁺]

Hacker News yorumları

• 1 milyon token bağlamı desteklediği duyurulsa bile, bu kadarını kullanmanın gerçekten istenen bir şey olduğu ya da düzgün çalıştığı anlamına gelmez
  Model ve KV cache’in aşırı kuantizasyonu, zayıf sampler’lar ve ayar seçeneklerinin kaldırılması nedeniyle bu sorunun devam etmesi muhtemel. Yerel çıkarımla doğrudan kontrol edildiğinde yaygın LLM kusurlarının önemli bir kısmının ortadan kaldırılabileceğini düşünüyorum

  • Tüketici donanımında çalıştırılabilen yerel LLM’lerde de aynı kusurlar var; ayar değerlerini değiştirmek bunların hepsini çözmüyor
    En ön saftaki modellere en yakın olan Kimi K3’ü kendi başına barındırmak için büyük bir şehirde iyi bir ev fiyatına yakın bir bütçe gerekir. Yerel modelleri seviyorum ve ofisim hesaplama ısısından ısınacak kadar kullanıyorum, ama yerel LLM’lerin tüm yaygın kusurları çözdüğünü söylemek sadece temenniden ibaret
    Aksine, yerel modellerde ve evde çalıştırılamayan büyük modellerde de en ileri modellerden daha şiddetli uzun bağlam performans düşüşü vardı; fp16/bf16’da bile pratik bağlam uzunluğu sınırı daha düşüktü
  • Kuruluşta AI ajanları geliştirirken model bağlam penceresinin yalnızca en fazla %50’sini kullanıyor, büyük bağlam modellerinde ise %25’i aşmamayı öneriyoruz
    Bu yüzden “1 milyon token bağlam penceresi” gördüğümde, gerçekten kullanılabilir aralığı 250 bin token olarak kabul ediyorum
  • Yerel model olunca sorunun neden ortadan kalkacağını anlamıyorum. Bu bulut ile yerel arasındaki bir fark değil, tüm LLM’lerin kusuru; burada test edilen yerel model de başarısız olmuş
  • İğne bulma benchmark’ının gösterdiği şey, genişletilmiş bağlamın o bölümüne “erişilebildiği ya da adresleme yapılabildiği” kadardır
    Ama neden attention head sayısı tartışılmıyor, anlamıyorum. Head’ler sınırlı ve modelin aynı anda odaklanabileceği şey sayısı da en fazla N olduğundan, uzun bağlam desteği için ister istemez bir üst sınır oluşur. Bağlam uzadıkça odağın kaybedileceği hedefler ve token başına head kaynağı yönetimi yükü artar
  • Geçen yıl GPT-OSS 20B’nin mxfp4 4-bit kuantize modeliyle test yaptım; 128k bağlam öne sürülüyordu ama yaklaşık 32k karakterden itibaren hatırlama performansı bozuldu
    Sözlük dosyasındaki dolgu metninin başına basit bir hash koyup prompt’un sonunda sadece o hash’i döndürmesini istedim; fakat 32k karakteri aşınca yanlış karakterler ya da tamamen halüsinasyon ürünü bir hash üretti. Büyük bağlam boyutu tek başına yetenek, prompt’a uyum veya diğer kalite ölçütleri için ölçü olamaz

• Bu benchmark’ta iyi puan alan modeller insanüstü yetenek iddia edebilir. Çünkü insanlar da uzun bir politika belgesini birden alıp aynen uygulamakta çok kötüdür
  Modeli aşırı insanlaştırmamak gerekir, ama başarısızlığın nedeni insanlardakine benzer olabilir. Çalışma belleği sınırlıdır; aynı anda odaklanılabilecek öğe sayısı ve akıl yürütme derinliği de sınırlıdır. Gerçek dünyadaki politikalar çoğu zaman belgede yazdığı gibi uygulanmak üzere yazılmamıştır ya da istisna koşulları yeterince açık belirtilmemiştir
  İnsanlara örnek vakalarla eğitim ve pratik geri bildirim şeklinde RLHF’ye karşılık gelen bir süreç uygulanır. Yeni başlayan birine 124 sayfalık bir politika belgesi verip ilk işinden itibaren bunu doğru uygulamasını ya da ilk ay boyunca istikrarlı biçimde uymasını beklemeyiz

  • İnsanlarda öğrenme farkı vardır. Yeni başlayan biri ilk gün kurum politikasına uyamasa da 3 ay ya da 3 yıl sonra durum değişir
    Buna karşılık LLM’leri otomatik olarak ince ayarlamak ya da yürütme ortamını iyileştirerek kurumsal hedefleri daha iyi gerçekleştirmelerini sağlamak için henüz makul araçlar yok. Hâlâ ortalama durumlara göre ayarlanmış ortak ağırlıkların ve yürütme ortamı politikalarının hâkimiyeti altındalar
  • Davranış politikası sürekli büyüyen KV cache bağlamında değil, model ağırlıklarında yer almalı
    Politika belgesini dar bir belleğe tıkıştırmak yerine, çevrimiçi öğrenme veya sonradan eğitim yoluyla mevcut ağırlıklara yansıtmak daha doğru. Her konuşma turunda fiilen ön eğitimi sürdürmeden, hesaplanmış bağlamdan ağırlık değişimlerini çıkarıp bağlamı boşaltmanın bir yolu olup olmadığını merak ediyorum
  • İnsanlar için en etkili yöntem, deklaratif belgenin tamamını elde tutmak yerine, işe özel prosedür betikleri içinde belgenin ilgili bölümlerine referans vermektir
    AI da sigortacılık gibi işlerde ajan teknolojisini benzer şekilde uygularsa çok daha iyi çalışacak gibi görünüyor
  • Sebep politikalarda çok fazla çelişki ve belirsizlik olması olabilir mi diye düşünüyorum. İnsanlarda da tüm kurallar aynı anda uygulanmadığı için bir şekilde işliyor
  • AI’ın iş yerinde gelişmesi için prosedürleri harfi harfine izlemesi gerekir, ama Claude Code ikinci turdan itibaren “commit yapma” talimatını unutuyor
    Claude Code, mükemmel bir modelin üzerine konmuş genel amaçlı ve kötü bir yürütme ortamı olduğu için bürokratik prosedürlere uygun değil; Opus 4.6’nın zirve olduğu dönemden bu yana yetenekleri de sürekli kötüleşiyor gibi

• Claude talimatları yaklaşık 10 dakika kadar çok iyi izliyor, ama sonrasında daha önce verilenleri yok sayıyor gibi görünüyor
  CLAUDE.md’ye devasa yorumlar yazmaması ve mevcut işlevleri kullanması gibi açık ve güçlü talimatlar koysanız bile, gerçek işte şaşırtıcı derecede hızlı atlıyor. Buna karşılık çalışma sırasında prompt ile yeniden hatırlatınca çok daha iyi yapıyor
  Bazen iyi uyuyor, bazen de tamamen yok sayıp işi bozuyor; bu yüzden CLAUDE.md’ye sürekli kural ekleme dürtümü bastırıyorum

  • Yazıda ele alınan şey beş prompt önce söyleneni unutma olgusu değil, politika belgesine uyum. Hatta CLAUDE.md’ye sürekli madde ekleme davranışı yazının konusuna daha yakın
  • Kök Claude.md’de az sayıda küresel üst düzey kural bırakıp, alt klasörlerdeki modül bazlı claude.md dosyalarına somut kuralları yerleştirerek iyi sonuçlar aldım
    Buna ek olarak, kural tabanlı özel /code-review tekniğiyle uygulama sırasında kaçırılan maddeleri de denetleyip zorunlu kıldım
  • Statik talimatların, sürekli başvurulacak bir kullanım kılavuzu değil; ilgili proje türüne uygun başlangıç noktası olarak modeli hizalamaya yarayan şeyler olduğunu düşünüyorum
    Mevcut talimatlara sürekli uyum sağlama rolünü kodlama yürütme ortamı üstleniyor; yerel modellerde bu fark özellikle belirgin

• Ajan tipi yapay zeka, sonradan eğitim aşamasında sentezlenmiş alana özgü ajan veri kümeleriyle büyük ölçekli pekiştirmeli öğrenme yapılarak yapay biçimde kazandırılmış bir yetenektir.
  Belirli bir yönerge kitabı ya da kullanım senaryosu üzerinde sonradan eğitilmediyse düzgün çalışmaz. LLM’lerin kodlama ajanı işlerinde özellikle güçlü olmasının nedeni de geliştiricilerinin bu iş akışını derinden anlaması ve yeterince eğitebilmesidir.
  Gerçek çözüm, herkesin kendi ajan kullanım senaryosuna göre kolayca ince ayar yapabilmesi olurdu; ancak büyük şirketlerin kendi çalışma biçimleriyle ilgili dev veri kümeleri oluşturması gerekir ve kimse ilk adımı atmak istemeyecek gibi görünüyor.
  Uzun bağlamlarda, RoPE konum kodlama genişletmesi nedeniyle ilk token’ları doğru biçimde geri getirmek zordur; bunu kullanmayan Kimi veya DeepSeek de ilk bağlamı güçlü biçimde sıkıştırdığından doğru bilgiler kaybolur.
  Temel yaklaşım, büyük ve önbelleklenebilir bir sistem prompt’u ile yalnızca dinamik veriyi içeren kullanıcı prompt’undan oluşan tek seferlik işler kurmak ve bunu yapabilen en ucuz modeli kullanmak olmalı. Önce açık, adım adım ilerleyen bir tek seferlik prompt grafiği oluşturup ancak yine de çözülmediğinde ajan kullanmak daha doğru ve daha ucuzdur; fakat her şeyi yapay zekaya bırakmaktan daha fazla emek ister.

  • Tek seferlik prompt grafiği ile tam olarak ne kastedildiğini merak ediyorum.
  • Kenny Rogers’ın “Hayatta kalmanın sırrı, neyi atıp neyi saklayacağını bilmektir” sözündeki gibi, insanlar da yapay zeka gibi sınırlı bağlama sahiptir.
    Fark, insanların en azından zaman zaman hangi bilginin daha önemli olabileceğine karar verip onu bağlamda öncelikli olarak tutabilmesidir.
  • Claude Code’un kodlamada iyi hale gelmesinin nedeninin Anthropic’in Mercor gibi şirketlerden büyük miktarda kodlama verisi satın alması olduğu yaygın bilinen bir gerçek sanıyordum.

• Birkaç yıl önce çıkan “Lost in the Middle: How Language Models Use Long Contexts” https://arxiv.org/abs/2307.03172 makalesinin sonucu bugün de geçerli görünüyor.
  Bu, “Engineering for Bounded Cognition”da ele alınan insan çalışma belleğinin sınırları ile benzerliğe dair temel gözlemlerden biriydi.

• Uzun politika belgeleri insanlar için de zordur. Ayrı bir eğitim olmadan 180 sayfalık bir İK yönergesini, yangın mevzuatını, OSHA güvenlik kurallarını, FCC düzenlemelerini ve ABD Yasalar Derlemesi’ni tamamen hatırlamak mümkün değildir.
  Yanlış davranıldığında hapse girecek kadar risk büyükse, politika istisnaya izin verse bile eylememeyi seçeriz. Risk küçükse, en kolay yol uğruna politikayı tamamen yok sayarız.

  • Öyleyse çözümün ne olduğunu merak ediyorum. Burada takdir yetkisi eksik gibi; belki de ayrı bir takdir/judgment modeli gerekiyordur.

• Yapay zeka yazdığım kuralları sürekli ihlal ettiği için sinirlenip Claude’a kendi kayıtlarını tarattığımda, bir kez kural ihlali yaptıktan sonra ek ihlal olasılığının arttığını gördüm.
  İyi örnekleri takip ettiren few-shot öğrenmenin tersine, kural ihlalleri ve düzeltmeler bağlamda biriktikçe ihlal olasılığını artırıyor gibi görünüyor.
  Kuralları prompt’a veya CLAUDE.md’ye koyarak ya da hiç koymayarak yeni oturumlar açıp kısa bir test yaptım; yeni oturumlarda Opus 4.8, 5 ve Fable konumdan bağımsız olarak hepsine iyi uydu. Normal konuşmalarda kuralları sürekli ihlal eden Opus 4.8 için de aynıydı.
  Uzun bağlamın kurallara uyumu bozduğundan şüpheleniyordum ama uzun bir konuşmayı yeniden üretmek zor olduğu için doğrulayamamıştım; bu makale şüphemi giderdi. Model kural kontrolünü çalıştırıp ihlali doğru bulsa bile, anlatı kısmı mevcut hatalı çıktıda ısrar edebiliyor.
  Şu anda ayrı bir hook veya sonradan kontrolle düzeltiyorum. Çünkü üretim sırasında düzeltmeyi modelin kendisine bırakırsam, anlatı ya da ana üretim bölümü bazen kendi bulduğu kural hatasını reddediyor.

  • LLM’lerden önce de bir sorunu engellediğinizde hemen bitişikteki başka bir sorunla ya da aynı soruna dönen başka bir yolla karşılaştığınız en yakın engellenmemiş alan sorunu vardı.
    Model uzun vadeli davranışı yeniden öğrenebildiğinden, bağlamı büyük ölçüde değiştirmeden yalnızca davranışı düzeltmek zordur.

• Claude’da RULES.md dosyasını okuyup her prompt’un başına ekleyen inject_rules.py dosyasını UserPromptSubmit hook’u olarak kullanınca, bağlam dolsa bile kuralların silikleşmesi azaldı.
  Prompt token’ları biraz daha hızlı tükeniyor ama toplam token kullanımı tersine azaldı ve Pro’da da kullanılabiliyor. Kusursuz değil ama daha iyi; Claude’un istenen davranışı engelleyen şeyler uydurmaması için belleği boşaltmak da yardımcı oluyor.
  RULES_PATH, RULES.md dosyasını gösteriyor ve BOM’u kaldırmak için encoding='utf-8-sig' ile okunuyor. Ardından hookSpecificOutput.hookEventName = "UserPromptSubmit" ve tüm kuralları additionalContext içinde taşıyan JSON standart çıktıya gönderiliyor.
  Önsözde, kuralların bu turda da geçerli olduğu ve istenmeyen bir şeyi gündeme getirmeden önce kural 33’teki beş kontrolün çalıştırılması gerektiği yazıyor. OSError oluşursa sessizce 0 döndürerek kural dosyası olmadan da o turun devam etmesini sağlıyor.

  • Tüm kuralları her seferinde enjekte etmek yerine yanıt hook’u ile çıktıyı kontrol edip yalnızca yoldan çıktığında kuralları enjekte etme yöntemiyle karşılaştırıldığında ne gibi avantajları olduğunu merak ediyorum.

• Bu yazı, büyük ölçekli spesifikasyon tabanlı geliştirme için de potansiyel bir sorun olduğunu gösteriyor. Son dönemde net biçimde tanımlayamadığım sorun, ajan uygulamasının spesifikasyondan giderek sapmasıydı.

  • Aynı olguyu yaşadım ve buna vizyon kayması demeye başladım.
    Kendi yaptığım issue tracker, panoda zamanda yolculuğu desteklediği için bu soruna çok uygundu. :replay 4h gibi bir komutla son saatlerde iş akışının nasıl değiştiğini tek bakışta görebiliyor ve istediğiniz önceki durumu checkout edebiliyorsunuz.
    Ayrıntıları https://dev.to/ljtn/vision-drift-addressing-the-next-problem... adresinde derledim.
  • Büyük spesifikasyon ile ajan uygulaması arasındaki sapma çok büyük. Çok denedim; model türünden bağımsız olarak Fable veya Sol bile çok sayıda ayrıntıyı kaçırıyor ve yoldan çıkıyor.
    Spesifikasyon ile uygulama arasındaki boşluğu kapatıp uygulamanın spesifikasyonla uyumlu olmasını sağlayan http://engine.build üzerinde çalışıyorum. Karmaşık bir sorunu doğrudan kod yazarak çözmekle aynı tatmini vermiyor ama net bir spesifikasyon yazmak ve problem üzerine derinlemesine düşünmek de yeterince tatmin edici.

• Bu davranışı Sonnet 4.6 kullandığım birkaç ay önce fark ettim. Kişisel bir projede token sayısını azaltmak için kod yorumlarına katı kurallar koymuştum
  Bir sürümden itibaren Claude, CLAUDE.md’deki açık talimatları yok sayıp ticket’lara ve başka işlere atıf yapan devasa yorumlar eklemeye başladı
  Sonrasında, otomobil montaj hattındaki saha yöneticisi gibi geliştirme yapmaya başladım. Ana oturum, CLAUDE.md gibi bilgilerle uygulamayı gerçekleştiriyor; yüksek derecede uzmanlaşmış birden fazla alt ajan ise yalnızca tek bir ilgi alanını üstlenip yorum yasağı/minimizasyonu gibi kuralları zorunlu kılıyor ya da nihai sonuca yansıtıyor