Bir soru, iki ayrı veri yolu
Bir geliştiriciye binlerce sözleşmeden kaçının bir kuralı ihlal ettiği sorulduğunda, sohbet arayüzü işe doğal bir giriş sağlıyor. Sorunun zor kısmı bütün sözleşmelerin hesaba katılması. AWS’nin Adjudicated Query örneğinde model altı araç arasından seçim yapıyor; taramanın kapsamını ve sonucu belirleyen hesap ise kural motorunda çalışıyor. Bu ayrım geliştiriciye kullanışlı bir yapı taşı veriyor: modelle konuşulabilen, hesabı yeniden üretilebilen bir iş akışı. Uygun, ihlal içeren, belirsiz ve okunamayan sözleşme toplamı taranan sayıya eşit olmadan sonuç veri tabanına yazılmıyor.[1]
İsteği bir katman daha takip edince araç seçiminin neden önemli olduğu görülüyor. Madde keşfi aracı, ilgili sözleşme parçalarını sıralayıp bir örneklem getiriyor. Uyum taraması ise tanımlı sözleşme kümesinin tamamını değerlendiriyor. Keşifte Titan Embeddings V2 ve Claude Sonnet 5 kullanılıyor; kesin sayım bu yoldan geçmiyor. Geliştirici, aynı soruya benzeyen iki isteğin farklı veri kapsamlarıyla çalıştığını arayüzde gösterebiliyor. Bir maddeye benzer örnekler ile bütün ihlallerin sayısı için ayrı araçlar tutmak, ajanı devralan ekibin hangi işlemi incelediğini de belirginleştiriyor.[1]
Yine de hesap doğru üretildiğinde iş bitmiyor. AWS’nin denemesinde model bir uyarıyı yeniden anlatırken düşürüyor ve küçük örneklemden genelleme yapıyor. Sonuç biçiminde gerçek toplamların ve sınırlamaların tekrar verilmesi bu soruna karşı bir önlem. Bence bu örnek geliştiricinin dikkatini iki ayrı başarısızlığa yöneltiyor: eksik evren üzerinde doğru hesap yapmak ve doğru hesabı yanlış kapsamla anlatmak. Bunlardan ilki araç sözleşmesiyle, ikincisi yanıtın kullanıcıya nasıl taşındığıyla ilgili. Birinin düzelmesi diğerinin kendiliğinden düzeleceğini göstermiyor.[1]
Bakım işi kuralların çevresine taşınıyor
Bu yapıyı devralan küçük ekip için bakımın merkezi kuralların sürümü, veri kapsamı ve kimlik bağlantısı oluyor. Bulgular geçmişin üzerine yazılmadan ekleniyor; Quick sohbeti ile QuickSight panosu aynı Aurora veri tabanını okuyor. Bir sonuç değiştiğinde hangi kural sürümü ve hangi sözleşmelerle üretildiğini incelemek anlam kazanıyor. Aynı düzenek yeni bir modelle denenebilir, ama modelin daha iyi araç seçtiği veya daha az inceleme gerektirdiği ayrıca ölçülmeli. Açık mimari, ekibe bileşenleri değiştirme olanağı sağlıyor. Başka bir modele geçerken gereken uyarlama ve inceleme işini ekip kendi uygulamasında ölçmeli.[1]
Kimlik katmanı da bu bakım işinin parçası. Örnekteki iki taraflı OAuth uygulamayı tanıyor; sözleşmeleri sorgulayan kişiyi otomatik olarak tanımlamıyor. Kullanıcı bazında iz sürmek isteyen ekip çağrıyı gerçek kişiyle ayrıca ilişkilendirmeli. Öznel maddelerin insan incelemesine bırakılması da başka bir sınır koyuyor. Böyle bir işte belirsiz sınıfın görünür tutulması yararlı: sistemin çözemediği sözleşmeler toplamdan kaybolmuyor. Fakat sınıfların toplamı doğru diye kuralların hukuki yorumu veya veri çıkarımının doğruluğu güvence altına alınmış olmuyor.[1]
Ben ilk uygulamayı sohbet arayüzü olmadan çalışan aynı kural motoruyla karşılaştırırdım. Kullanıcı yalnızca sabit bir rapor istiyorsa mevcut pano yeterli olabilir; doğal dille değişen sorular soruyorsa araç seçiminin katkısı sınanabilir. Aynı sözleşme kümesi ve kurallarla doğru araç seçimi, yanlış kapsamlı yanıt, gecikme ve insan düzeltmesi izlenmeli. Kazanımın başka açıklamaları da var: daha temiz veri ya da yeni arayüzden bağımsız biçimde iyileştirilmiş kurallar işi kolaylaştırmış olabilir. Bu tarifin geliştiriciye açtığı alan, kesin hesabın çevresinde esnek bir konuşma akışı kurmak; değerini gösterecek olan o akışın gerçek kullanımındaki sonuçlar.[1]