Nedir bu harness? En basit hâliyle AI harness anlatıyorum

Aynı yapay zekâ modelini kullanan iki üründen bir iş istediğinizi düşünün. Biri size nasıl yapacağınızı anlatıyor. Diğeri gerekli bilgiyi buluyor, ilgili yazılımda işlemi yapıyor ve sonucu kontrol ediyor. İşin kalanını çalışanların tamamlaması gerekiyorsa bu fark, günlük kullanımda oldukça somut.

“LLM laf yapar, harness iş yapar!” Bu sözü akılda kalıcı bir basitleştirme olarak kullanıyorum. Sözü teknik bir tanım gibi almamak gerekir. LLM, yani büyük dil modeli, bir yanıt üretir. Harness bu yanıtı gerçek bir görevin parçası hâline getirir.

Bu farkı anlamak için modelin çevresindeki çalışma düzenine bakmak gerekiyor. AI harness, modelin ne zaman, hangi talimatlarla ve hangi bilgilerle çalışacağını düzenleyen yazılım katmanı. Daha gelişmiş bir harness, araç kullanımını, işin durumunu ve sonuca ulaşana kadar atılacak adımları da yönetir.

Terimi bir sandviç üzerinden anlatayım. Sonra bu mutfak düzeninin bir yazılım ürününde neye karşılık geldiğine bakalım.

Çok şey bilen bir aşçıdan sandviç istemek

Karşınızda çok bilgili bir aşçı olduğunu düşünün. Ona “Bana peynirli bir sandviç yap” diyorsunuz. Aşçı isteğinizi düşünüyor ve cevap veriyor: “İki dilim ekmek al, aralarına peynir koy.”

İyi bir tarif almış olabilirsiniz. Tabağınız ise hâlâ boş.

Bir dil modelini tek başına çağırmayı böyle düşünebiliriz. Modele bir istek verirsiniz, o da bir çıktı üretir. Teknik akışın en sade gösterimi şu:

Prompt → model → response

Buradaki prompt, modele verdiğiniz istek ve talimatlar. Model bunları işler ve bir cevap üretir. İstenen iş metin yazmaksa bu cevap zaten kullanılabilir bir çıktı olabilir. Başka bir sistemde işlem yapılması gerekiyorsa o bağlantıyı ayrıca kurmak gerekir.

Şimdi aşçıya bir çalışma düzeni verelim. Önünde malzemeler, kullanabileceği mutfak araçları ve izleyeceği kurallar olsun:

1. Görev belli: Peynirli sandviç hazırlanacak.
2. Aşçı malzemelere bakıyor. Ekmek ve peynir var mı, yiyecek kişinin alerjisi var mı, mutfakta hangi kurallar geçerli?
3. Gerekli araçları seçiyor: Bıçak, tabak ve ekmek kızartılacaksa tost makinesi.
4. Sandviçi hazırlıyor.
5. İstenen malzemeleri kullanıp kullanmadığını ve sandviçin servis edilmeye uygun olup olmadığını kontrol ediyor.
6. Bir şey eksikse, düzeltebileceği durumda düzeltiyor. Uygun malzeme yoksa durup soruyor.
7. Sandviçi servis ediyor.

Harness, bu örnekte aşçının çalışmasını düzenleyen bütün. Hangi bilgiye bakacağı, neyi kullanabileceği, yaptığı işi nasıl kontrol edeceği ve ne zaman bitireceği bu düzenin içinde.

Benzetmenin bir sınırı var: Gerçek aşçının elleri var, dil modelinin yok. Yazılımda model, bir araca gönderilecek işlem isteğini üretir. O işlemi uygulamanın ya da sağlayıcının çalıştırdığı araç gerçekleştirir. Modelin “sandviçi yaptım” demesi, sandviçin hazır olduğunun kanıtı sayılmaz.

Model üretir, harness işi düzenler

Parçaları şu şekilde ayırmak, terimleri takip etmeyi kolaylaştırıyor:

Bu, kavramları anlamak için kullandığım bir zihinsel model. Terimlerin sınırları bütün ürünlerde aynı çizilmiyor. Özellikle agent sözcüğü kimi kaynaklarda modelle birlikte çevresindeki sistemi de kapsıyor.

Model işi ilerletirken tekrar tekrar devreye girebilir. Gelen bilgiyi yorumlar, sonraki adımı önerir veya hangi araca ihtiyaç duyduğunu belirler. Harness bu kararların uygulanacağı düzeni sağlar. Önceden yazılmış kurallar da hangi adımların mümkün olduğunu sınırlar.

Bellek de modelin her şeyi kendiliğinden hatırlaması demek değil. Yazılım işin durumunu saklar ve bir sonraki model çağrısına gereken kısmı verir. Kaydedilen bilginin işe yaraması için o anda modele sunulması ve model tarafından doğru kullanılması gerekir.

Harness doğrudan API çağrısıyla başlayabilir

Harness bir terminale yazılan komutlarla, masaüstü uygulamasıyla ya da kurumsal agent çatısıyla sınırlı değil. Kullanıcının gördüğü arayüzden bağımsız olarak ürünün içinde bulunabilir. Hazır bir paket kullanma zorunluluğu da yok.

Bir ürününüzün iki tür istek aldığını düşünün: Metni özetlemek ve başka bir dile çevirmek. Ürün, görev türünü belirliyor, buna uygun sistem talimatını ve modeli seçiyor. Sağlayıcının API'sine, yani yazılımın model hizmetine istek gönderdiği bağlantıya, bu bilgileri iletiyor. Gelen sonucu da kullanıcıya döndürüyor.

Sistem talimatı (system prompt), modelin o görevde nasıl davranacağını belirleyen yönergedir. Özet çıkarırken ana bilgileri korumasını, çeviri yaparken anlamı değiştirmemesini isteyebilirsiniz. Hangi talimatın ve modelin kullanılacağını seçen kod, burada tarif ettiğim anlamıyla, asgari bir prompt/model yönlendirme harness'idir.

Bu sistemde henüz araç kullanımı, kalıcı bellek veya tekrar deneme döngüsü bulunmayabilir. Yine de modelin nasıl kullanılacağını düzenleyen bir katman vardır. Görev türü arayüzde seçiliyorsa bu seçim için ayrıca bir model çalıştırmanız bile gerekmez.

Model yönlendirmesinin farklı biçimlerini ve ne zaman ek yük yarattığını istekleri farklı modellere yönlendirme yazısında daha ayrıntılı ele aldım. Buradaki nokta, bu basit seçimin de modelin çevresindeki çalışma düzenine ait olması.

İş birkaç adıma yayıldığında

Görev büyüdükçe harness'e yeni yetenekler ekleyebilirsiniz. Modelin o adımda göreceği talimatları, belgeleri ve önceki sonuçları bir araya getirmeye bağlam hazırlama deniyor. Gerekli araçları bağlamak, tamamlanan adımları saklamak, çıktıyı doğrulamak ve düzeltilebilir hatalarda yeniden denemek de bu düzeni genişletir.

Araç kullanan, birden fazla adımda ilerleyen bir sistemin akışını şöyle gösterebiliriz:

Task → inspect context → use tools → execute → check the result → retry when needed → finish

Yani görev alınır, gerekli bilgi incelenir, araçlar kullanılarak işlem yapılır ve sonuç kontrol edilir. Gerekiyorsa yeniden denenir, ardından iş tamamlanır. Araç kullanmak ile işlemi gerçekleştirmek çoğu uygulamada aynı adımın parçalarıdır. Bir belgeyi okumak da araç kullanımı gerektirebilir. Bu sıra, bütün harness'lerin uyması gereken bir protokol değil, çalışma döngüsünü anlamanın basit bir yolu.

Kontrolü her zaman aynı modele “Doğru yaptın mı?” diye sorarak yapmak zorunda değilsiniz. Dosyanın oluşup oluşmadığını yazılım kontrol edebilir. Bir kaydın doğru yere yazıldığını ilgili sistemden okuyabilirsiniz. Bir metnin amaçlanan anlamı taşıyıp taşımadığını ise insanın değerlendirmesi gerekebilir.

Tekrar denemenin de bir sınırı olmalı. Bir kayıt oluşturulduğu hâlde cevap gelmediyse aynı işlemi körlemesine tekrarlamak ikinci bir kayıt yaratabilir. Harness, yeniden denemeden önce ne olduğunu kontrol etmeli. İş ilerlemiyorsa veya yetki eksikse durup insana dönmesi gerekir.

Bu döngüde sıradaki adımı bazen yazılımın sabit kuralları, bazen de yeni bilgiyi yorumlayan model seçer. Workflow ile agent arasındaki ayrım burada önem kazanır. Basit bir harness kullanmak, bütün işi açık uçlu bir agent'a bırakmayı gerektirmez.

Ürünü değerlendirirken bu düzeni de görün

Aynı aşçı, malzemeleri önceden hazırlanmış bir mutfakta başka, her malzemeyi aramak zorunda kaldığı bir mutfakta başka türlü çalışır. Kontrol düzeni de değişirse hız ve sonuç değişebilir. Yazılım ürünlerinde modelin gördüğü bilgi, erişebildiği araçlar ve hataların ele alınışı benzer bir fark yaratır.

Bu yüzden aynı modelin farklı uygulamalarda farklı sonuç vermesini değerlendirirken model adının yanında çalışma düzenine de bakmak gerekir. Daha çok araç veya daha uzun bir döngü otomatik olarak daha iyi sonuç getirmez. Gereksiz adımlar bekleme süresini, maliyeti ve hata ihtimalini artırabilir.

Bir özetleme işi için doğru talimat, uygun model ve kısa bir kontrol yeterli olabilir. Birden fazla sistemde işlem yapılacaksa bağlam, yetki, durum takibi ve doğrulama daha fazla önem kazanır. Adımları ve kuralları tamamen belli bir işte mevcut bir otomasyon da yeterli olabilir.

Bir AI ürününü değerlendirirken kendi işinizden somut bir görev seçin. Hangi bilginin kullanıldığını, hangi işlemin gerçekten yapıldığını ve işin tamamlandığının nasıl anlaşıldığını birlikte inceleyin. Çalışanların sonradan ne kadar düzeltme yaptığını da hesaba katın. Harness'in değeri, o işin kabul edilebilir bir sonuçla tamamlanmasına yaptığı katkıda ortaya çıkar.

Yararlı okumalar

• Building effective agents: Doğrudan API kullanımı, yönlendirme ve araçlarla çalışan modeller için temel tasarım örnekleri sunuyor. Bir sağlayıcının mimari rehberi; burada kullandığım geniş harness tanımını bir sektör standardı olarak belirlemiyor.
• Tool use with Claude: Modelin ürettiği araç çağrısıyla işlemi çalıştıran yazılımın görevlerini ayırıyor. Uygulama ve sağlayıcı tarafında çalışan araçların farkını Claude API'si üzerinden gösteriyor.
• Effective harnesses for long-running agents: Uzun işlerde ilerleme kayıtları ve sonuç kontrolünün neden gerektiğini somutlaştırıyor. Web uygulaması geliştirme deneyimine dayanıyor; bütün görevlerde aynı düzenin üstün olduğunu göstermiyor.