Postman Ajan Modu'nu Amazon Bedrock'a Taşıdı: 40 Milyon Geliştirici İçin Dört Ders
Yazar: KOZBA
İçindekiler
Bir yapay zeka ajanını demo için kurmak, onu 40 milyon geliştirici için çalıştırmak tamamen farklı iki mühendislik problemidir. Postman, bu ölçekte geliştirdiği ajan modu Agent Mode'un mimarisini ve Amazon Bedrock üzerinde nasıl çalıştığını paylaştı. Ekibe göre beklenen zorluklar model kalitesi ve istem tasarımıydı; gerçek problemler ise ajanı, yıllardır arayüz odaklı varsayımlarla büyümüş olgun bir ürüne entegre etmekten çıktı.
1. Araç yığını kontrolden çıkıyor
Postman başlangıçta çok atomik araçları tercih etti: bir isteği açmak, tek bir alanı güncellemek, belirli bir üst veriyi çekmek gibi küçük ve kesin eylemler. Ancak gerçek iş akışları uzun araç çağrısı zincirleri gerektiriyordu. Her adım hızlı olsa da deneyim yavaş hissettiriyordu; çünkü her eylemde kontrol modele geri dönüyordu.
Ekip, görünür araç seti yaklaşık 40 aracı geçtiğinde araç seçim hatalarının arttığını gözlemledi: ajan var olmayan araçları çağırabiliyor, geçerli şemalara rağmen yanlış argümanlar verebiliyor ya da bağlama uymayan araçları seçebiliyordu. Daha büyük modeller bu davranışı azalttı ama tamamen ortadan kaldırmadı. Çözüm, modele her zaman tüm araçları göstermek değil, göreve göre yalnızca ilgili araçları sunmak oldu.
2. Şemaya dayalı okumalar, araç çoğalmasına karşı
Postman, API Catalog gibi ürünlerinde birden çok dar görünümü tek bir sorgu aracında birleştirdi. Alttaki ClickHouse tablolarının şeması verildiğinde ajan; birleştirmeler (JOIN) ve WHERE koşulları içeren karmaşık sorgular üretebiliyor. Bu yaklaşım, bir analiz sorusunu yanıtlamak için gereken araç sayısını ciddi biçimde azaltıyor.
Böylece mühendislik işi "her soru için bir araç yazmaktan" "veriyi bir kez iyi modellemeye" dönüşüyor. Ajan, ekibin tek tek araç olarak yazabileceğinden çok daha fazla sorgu üretebiliyor.
3. Asıl darboğaz: bağlam
Postman başta en büyük engelin eksik araçlar olacağını varsaydı. Uygulamada ise eksik ya da hatalı bağlam, eksik yetenekten daha çok hata üretti. Bağlam; kullanıcının ürün içinde nerede olduğu, hangi varlıkların aktif olduğu ve hangi durumun kurulduğu bilgisidir. Bağlam yanlış ya da eksik olduğunda doğru araçlar bile etkisiz kalıyordu.
Mevcut arayüz veri modelini olduğu gibi serileştirmek işe yaramadı; çünkü bu nesneler akıl yürütme için değil, ekranda gösterme ve veri aktarımı için tasarlanmıştı. Postman bu yüzden her varlığı ajanın bilmesi gerekenle sınırlayan özel bağlam işleyicileri geliştirdi.
4. Bilgi tabanı ve Bedrock'ta yönlendirme
Agent Mode, Retrieval Augmented Generation (RAG) yaklaşımıyla çalışan bir bilgi tabanı kullanıyor. Postman'in geniş ürün yüzeyinin tamamını statik istemlere sığdırmak mümkün değildi; bu yüzden öğrenme merkezinden derlenen kısa özellik yazıları, gelen sorguya göre seçilerek bağlama ekleniyor.
Çalışma zamanında her şey tek bir çıkarım (inference) çağrısına indirgeniyor. Postman, Bedrock'ın model esneklikliğinden (Claude ailesi içinde iş yüküne göre model seçimi), bölgeler arası çıkarımdan, model bazlı sıfır veri saklamadan ve çok katmanlı istem önbelleklemeden yararlanıyor. İnsan gözetimi de tasarımın parçası: Agent Mode, uygulama durumunu değiştiren eylemlerden önce kullanıcı onayı istiyor; ayrıca kişisel verileri modelden önce ayıklamak için Bedrock Guardrails kullanılıyor.
Geliştiriciler için çıkarımlar
- Araç bütçesini jeton kadar dikkatli yönet; göreve göre araç seç.
- Çok sayıda dar araç yerine şemaya duyarlı okuma tercih et.
- Ajan eylemlerini arayüz durumundan ayır; sekme açmak zorundaysa, ajan ekranda değil veride akıl yürütmelidir.
- Bağlamı bilinçli mühendislikle üret; bağlam penceresini kıt bir kaynak gibi yönet.
- Dokümantasyonu özelliklerle birlikte yayınla ki RAG tabanı güncel kalsın.
Postman ve AWS'ye göre bu dersler, üretimdeki ajanları prototip aşamasının ötesine taşımak isteyen ekiplere yol gösterebilir.