Kurumsal Yapay Zekâ Ajanlarında Context Engineering
Kurumsal yapay zeka ajanlarının işletim maliyetini azaltmak için yalnızca model seçimine odaklanmak yetmiyor. Microsoft’un The Economics of Agent Optimization serisinin üçüncü yazısı, her turda modele gönderilen bağlamın nasıl yönetileceğini inceliyor. “Context engineering” olarak adlandırılan bu yaklaşım, ajanın hangi bilgiyi göreceğini, hangi araçlara erişeceğini, prosedürleri nasıl uygulayacağını ve geçmişten neleri hatırlayacağını düzenliyor; böylece maliyet ile yanıt kalitesini birlikte iyileştirmeyi hedefliyor.
Bağlam penceresi ajan maliyetini nasıl belirliyor?
Bir modelin kendiliğinden kalıcı hafızası yok. Modelin her turda kullanabileceği bilgiler, talimatlar, araçlar, getirilen belgeler ve konuşma geçmişiyle oluşturulan bağlam penceresine gönderiliyor. Tür bittiğinde bu bağlam ortadan kalkıyor, sonraki turda gereken içerik yeniden iletiliyor.
Tek soruluk bir sohbet botunda bu maliyet yönetilebilir. Bir sonuca ulaşmak için çok sayıda tür çalışan ajanlarda ise bağlam penceresi, işletim maliyetinin en büyük kalemlerinden birine dönüşebilir. Gereksiz içerik her turda yeniden gönderildiği için tekrar tekrar ücretlendirilir.
Uzun bağlamın etkisi maliyetle sınırlı kalmıyor. Daha fazla içerik, kendiliğinden daha iyi yanıt anlamına gelmez. Önemli bir bilginin 40 sayfalık bir belgenin içine gömülmesi, modelin bu bilgiyi kullanmasını zorlaştırabilir. Uzun bir araç listesi de yanlış aracın seçilme ihtimalini artırabilir. Hatalı seçimler ek turlara ve yeni maliyetlere yol açar.
Bu yüzden gereksiz bağlamı kaldırmak, model değiştirmek veya talimatları kısaltmak gibi kalite kaybı riski taşıyan optimizasyonlara göre daha dengeli bir seçenek olabilir. Amaç, ajanın ihtiyaç duymadığı içeriği her turda taşımamasıdır.
Context engineering neyi değiştiriyor?
Context engineering, her turda bağlam penceresine hangi içeriğin gireceğini belirler. Ajanın ihtiyaç duyabileceği her şeyi göndermek yerine, isteğin gerektirdiği bilgi ve yetenekler seçilir.
Bu süreç tek seferlik bir tasarım kararı olarak görülebilir. Sürekli uygulandığında ise ajanın zaman içinde gelişmesini sağlar. Her tür, hangi bilginin, aracın veya prosedürün gerçekten kullanıldığına dair veri üretir. Kaynakta bu çalışma dört soruyla açıklanıyor:
- Ajan neyi bilmeli?
- Ajan nelere erişebilmeli?
- Ajan işi nasıl yapmalı?
- Ajan neyi hatırlamalı?
Ajan hangi bilgileri bilmeli?
Yaygın yaklaşımlardan biri, geniş aramalar yapıp belgelerin tamamını isteme eklemektir. Kurulumu kolaydır, ama çalışma sırasında pahalı hale gelir; modelin ilgili tek ayrıntıyı geniş içeriğin içinden bulması gerekir.
Foundry IQ, bunun yerine yönetilen bir bilgi katmanı sunuyor. Bir bilgi tabanı Work IQ, Fabric IQ, Web IQ, Azure Blob Storage, SharePoint, OneLake ve Azure SQL gibi kaynaklara bağlanabiliyor. Ajan sorgu gönderdiğinde Foundry IQ sorguyu alt sorgulara ayırıyor, bağlı kaynakları paralel olarak arıyor, sonuçları anlamsal açıdan yeniden sıralıyor ve kaynak gösterimleriyle birlikte temellendirilmiş pasajlar dönduruyor.
Bu sayede modelin bağlamına tüm belgenin yerine ilgili kanıtın girmesi hedefleniyor. Aynı bilgi tabanı birden fazla ajan tarafından kullanılabiliyor. Dizine alınan kaynaklar, yapılandırılmış dizin oluşturucu planına göre artımlı olarak yenilenebilirken uzak kaynaklar istek sırasında sorgulanabiliyor.
Yetkilendirme de bilgi katmanının bir parçası. Foundry IQ, sorgu sırasında çağrıyı yapan kullanıcının Microsoft Entra kimliğiyle çalışabiliyor, desteklenen kaynakların erişim listelerini eşitleyebiliyor ve Microsoft Purview hassasiyet etiketlerine uyabiliyor. Böylece ajan yalnızca kullanıcının erişmeye yetkili olduğu içeriği alabiliyor.
Microsoft’un iç değerlendirmelerine göre Foundry IQ bilgi tabanları, BrowseComp-Plus karşılaştırmasında kanıt geri çağırmayı yüzde 54’e kadar artırırken erişim sırasında kullanılan token maliyetlerini yüzde 34 azalttı. Kaynak bu kazanımları agentic retrieval, anlamsal yeniden sıralama, daha iyi yanıt sentezi ve token kullanımındaki verimlilikle ilişkilendiriyor.
Ajan hangi araçlara erişebilmeli?
Ajana yeni bir araç eklemek kod tarafında küçük bir değişiklik gerektirebilir, ancak aracın açıklaması her turda modele gönderilen istemin parçası olur. Kurumsal ajanlar farklı sistemlere bağlandıkça araç sayısı artar, bu görünmeyen yük de büyür.
Foundry içindeki Toolboxes, yerleşik web araması, code interpreter ve file search araçlarının yanı sıra özel MCP sunucularını, OpenAPI 3.0 ve 3.1 API’lerini ve A2A ajanlarını tek bir yönetilen Model Context Protocol uç noktasında bir araya getiriyor. Kimlik doğrulama, erişim politikaları ve araç sürümleri merkezi olarak yönetilebiliyor. Test edilip kullanıma alınan yeni bir toolbox sürümü, bağlı ajanlar tarafından kod değişikliği veya yeniden dağıtım gerektirmeden kullanılabiliyor.
Toolbox içindeki tool search özelliği, tüm araç listesinin her turda modele gönderilmesini önlüyor. Model önce ihtiyacını doğal dille açıklayabileceği bir yönteme, ardından dönen aracı çağırabileceği bir yönteme erişiyor. Araç kutusu büyüse bile araç listesinin bağlam maliyeti sabit kalıyor.
Kaynakta aktarılan şirket içi karşılaştırmada Foundry Toolboxes, büyük araç kütüphanelerinde ortalama giriş token tüketimini yaklaşık yüzde 97 azalttı. Sistem ayrıca her toolbox içinde en sık kullanılan araçları belirleyerek bunlara erişimi kolaylaştırıyor. Böylece maliyetin yanı sıra yanlış araç çağrılarının ve bunları düzeltmek için gereken ek turların da azalması hedefleniyor.
Ajan işi nasıl yapmalı ve neyi hatırlamalı?
Bilgi kaynakları ve araçlar ajanın ne bulabileceğini, ne yapabileceğini belirler. Kurumun işin nasıl yürütülmesini beklediğini ise açıklamaz. Destek talebindeki eskalasyon yolu veya kod incelemesindeki kontrol listesi genellikle talimatlarda tutulur. Bu prosedürler farklı ajanlara kopyalanıp her istekte yeniden gönderildiğinde gereksiz bağlam oluşur.
Foundry’deki skills özelliği, bu talimatları adlandırılmış ve yeniden kullanılabilir prosedürlere dönüştürüyor. Beceriler merkezi olarak saklanıyor, toolbox üzerinden ajanlara sunuluyor. Ajan başlangıçta yalnızca becerinin adını ve kısa açıklamasını görüyor; ayrıntılı talimatlar yalnızca gerektiğinde yükleniyor. Bir prosedür güncellendiğinde yeni sürüm yayımlanıp varsayılan yapılabiliyor. Bu beceriyi kullanan ajanlar da kod değişikliği veya yeniden dağıtım olmadan güncel prosedürü izleyebiliyor.
Ajanların süreklilik için her konuşmanın tamamını taşıması gerekmiyor. Foundry Agent Service içindeki bellek yaklaşımı üç tür içerik sunuyor:
- Oturum belleği: Mevcut konuşma için kullanılır.
- Kullanıcı belleği: Oturumlar arasında sürdürülen tercihler ve gerçekler için kullanılır.
- Prosedürel bellek: Öğrenilen iş akışlarını ve görev yürütme kalıplarını saklar.
Bu yapı, geri dönen bir kullanıcının önceki etkileşiminin önemli kısımlarından devam etmeye yardımcı olur. Ajan ayrıca tekrarlanan görevleri yeniden talimatlandırılmadan daha tutarlı biçimde yürütebilir. Merkezi beceri ile prosedürel bellek burada birbirini tamamlar: beceri kurumun onayladığı prosedürü tanımlar, prosedürel bellek ise ajanın kendi görev yürütmesinden öğrendiklerini temsil eder.
Microsoft değerlendirmelerinde prosedürel belleğin etkinleştirilmesi STATE-Bench ve Tau-Bench üzerinde yaklaşık yüzde 5 iyileşme sağladı. Kuruluşlar kullanıcı seviyesinde yalıtım, saklama ayarları ve içeriğin ne zaman sona ereceğini belirleyen yaşam süresi politikalarıyla belleği kontrol edebiliyor.
Bağlam yönetimi neden bir sisteme dönüşüyor?
Bilgi erişimi, araçlar, beceriler ve bellek ayrı ayrı kurulabilir. Zor olan, bunları ortak izinlerle birlikte çalıştırmak ve kurum değiştikçe güncel tutmaktır. Foundry bu parçaları ortak altyapı altında yönetmeyi ve veriye erişim sırasında izinleri uygulamayı amaçlıyor. Ajanlar böylece kurumsal içerik için zaten tanımlanmış erişim denetimlerini devralabiliyor.
Foundry IQ, kurumsal bilgiyi, iş verilerini ve organizasyon bağlamını tek bir model içinde birleştiriyor; Microsoft Agent Framework, LangGraph, GitHub Copilot SDK ve Claude Agent SDK gibi çerçevelerle uyumlu kalıyor.
Bu yaklaşımda bilgi tabanları kaynak sistemler değiştikçe yenileniyor, beceriler politikalarla birlikte gelişiyor, bellek kullanıcılar ve başarılı iş akışları hakkında gereken bilgileri biriktiriyor. Tool search de insanların gerçekten kullandığı yeteneklere göre uyum sağlıyor. Foundry Agent Service içindeki agent optimizer, ajan davranışını analiz ederek talimatlar, beceriler, araç açıklamaları ve model yapılandırmaları için iyileştirmeler üretebiliyor.
Kaynağın önerdiği başlangıç noktası, her turda bağlam penceresine giren içeriği incelemek. Getirilen belgeler, sunulan araçlar, tekrar edilen talimatlar ve taşınan konuşma geçmişi gözden geçirilmeli. Pek çok durumda bu girdileri iyileştirmek, model değiştirmekten daha güçlü bir maliyet ve kalite etkisi yaratabilir.
Kaynaklar ve İleri Okuma
- Microsoft Azure Blog: The Economics of Agent Optimization: Context engineering for enterprise AI agents
- The Economics of Agent Optimization serisi
- AI pilotlarından ölçülebilir getiriye geçiş
- AI maliyetini düşürmenin dört yolu
- Microsoft Work IQ
- Microsoft Fabric IQ
- Microsoft Web IQ
- Azure Blob Storage
- Microsoft OneLake
- Azure SQL
- Microsoft Foundry IQ
- Microsoft Entra
- Agent Memory: Üretimde güven, şeffaflık ve kontrol
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
4 comments