Aynı Yapay Zekâ Modeli Neden Farklı Uygulamalarda Farklı Sonuç Veriyor?

💡 Özet: Ana Çıkarımlar

• Model adı, bir yapay zekâ ürününün gerçek iş kabiliyetini tek başına anlatmaz. Bağlam, araçlar, yetkiler ve iş akışı da sonucu belirler.
• Aynı model farklı uygulamalarda farklı işler yapabilir. Bir yerde metin üretirken başka bir yerde kaynaklara ve yazılımlara erişerek işi tamamlayabilir.
• Ürünleri kendi işiniz üzerinde sınayın. Tamamlanan iş, düzeltme ihtiyacı, maliyet, hata davranışı ve yetki sınırı birlikte ölçülmelidir.

Bir satış ekibinin iki yapay zekâ ürününden aynı müşteri teklifini hazırlamasını istediğini düşünün.

İlk ürün, görüşme notlarından düzgün bir metin çıkarıyor. İkincisi güncel fiyatları ve müşteri geçmişini inceliyor, onay gerektiren indirimi fark ediyor ve teklif taslağını doğru CRM kaydına bağlıyor. Ekip, ikinci ürünün daha güçlü bir model kullandığını düşünebilir. Oysa iki ürünün arkasında aynı model bulunabilir.

Farkı modelin gördüğü bağlam, kullanabildiği araçlar, işlem yetkileri ve çalışmanın nasıl denetlendiği yaratmış olabilir.

Bir yapay zekâ projesine model seçerek başlamamak gerektiğini daha önce ele aldım. İş sonucu ve kabul ölçütü belirlendikten sonra model karşılaştırmasına sıra gelir. O aşamada da karşılaştırdığınız şeyin yalnızca model olmadığını bilmeniz gerekir.

Model, uygulama ve çalıştırma katmanı aynı şey değil

Bir yapay zekâ ürününü dört katmanda düşünebilirsiniz:

Teknik kaynaklarda harness denilen çalıştırma katmanı, modelin hangi bilgiyi göreceğini, hangi aracı çağırabileceğini, hata aldığında ne yapacağını ve nerede insan onayı isteyeceğini düzenler.

Bu sınırlar her üründe aynı yerde çizilmez. Ayrımın değeri kusursuz bir teknik sınıflandırma sunmasında değil, sonuçtaki farkın hangi karardan geldiğini göstermesindedir.

Modeli ürünün tamamı sanmayın

Aynı model boş bir sohbet ekranında, araştırma uygulamasında ve yazılım araçlarıyla çalışan bir agent sisteminde farklı işler yapar. Biri yalnızca kullanıcının verdiği metne dayanır. Diğeri güncel kaynakları arayabilir, işin durumunu adımlar arasında taşıyabilir, kayıt oluşturabilir ve gerektiğinde onay isteyebilir.

Ürün geliştirme rehberleri de bağlamı, araç kullanımını, onayları, hata toparlamayı ve bellek gibi bileşenleri modelin çevresindeki sistemin parçası olarak ele alır. Ham model kapasitesi ile ürünün yapabildiği iş aynı şey değildir.

Bu nedenle model adının yanında şu soruların da cevabı gerekir: Hangi güncel ve kurumsal bilgiye erişiyor? Hangi işlemleri yapabiliyor? Yetkiler yazılım tarafından uygulanıyor mu? Hata aldığında duruyor mu? Sonucu kim, hangi kayıttan doğruluyor?

Şirkete özel yapay zekâyı özel yapan bilgi, kural, araç ve ölçüm düzenini ayrı bir yazıda ele almıştım.

Model adları eskir, değerlendirme soruları kalır

Model güncellemesi araç kullanımını, talimatlara uyumu, maliyeti ve hata biçimini değiştirebilir. Bu yüzden karşılaştırmada model adı kadar sürümü, tarihi ve çalışma yapılandırmasını da kaydetmek gerekir.

Daha güçlü model, eksik sistemi tamamlamaz

Daha güçlü bir model karmaşık belgeleri daha iyi anlayabilir, doğru aracı daha az yönlendirmeyle seçebilir veya aynı kaliteyi daha düşük maliyetle üretebilir. Model seçimi hâlâ önemlidir.

Fakat güncel veriye erişemeyen, yetkileri yazılımda uygulamayan ve sonucu kaynak sistemden doğrulamayan bir ürünün açığını model tek başına kapatamaz. İyi tasarlanmış bir uygulama da yanlış modeli sınırsız biçimde güçlendirmez. Adımlar önceden biliniyorsa, agent yerine sabit bir workflow daha güvenilir ve ekonomik olabilir.

Bir yapay zekâ ürününü değerlendirirken model adının ötesine geçin: Hangi bağlam, araç, yetki ve çalışma düzeniyle hangi işi tamamlıyor? Bunu hangi sonuçlarla doğruladınız?

Ürünün gerçek kabiliyeti, kullandığı modelin adında değil, bu bütünün sizin işinizde tekrar tekrar üretebildiği sonuçta ortaya çıkar.

Yararlı Okumalar

• Codex as a platform: Codex'in bağlam, araç kullanımı, onaylar ve hata toparlama gibi çalıştırma katmanı bileşenlerini nasıl ele aldığını anlatıyor. Bu, model kapasitesi ile ürün kabiliyeti arasındaki farkı teknik düzeyde açar.
• Building effective agents: Agent sistemlerinde modelin bilgi erişimi, araçlar ve bellekle nasıl tamamlandığını ele alıyor. Sağlayıcının kendi ürün yaklaşımını yansıttığı için evrensel bir ürün mimarisi kuralı olarak okunmamalı.