Yapay Zeka Agent Sağlayıcısı Seçimi İçin Başarı Ölçütleri Sözleşmeye Nasıl Yazılır?

Yapay zeka agent sağlayıcısı seçiminde ölçüm neden şarttır?

Ölçüm şarttır çünkü bir agentın değeri, yalnızca ürettiği metnin kalitesiyle değil, gerçek iş akışında doğru kararı ve doğru işlemi ne kadar güvenilir biçimde gerçekleştirdiğiyle anlaşılır. Başarı ölçütü, sağlayıcının yorumuna açık bir “iyi çalışıyor” ifadesi değil; test edilebilir, kayıt altına alınabilir ve aynı koşullarda yeniden değerlendirilebilir bir sonuç tanımı olmalıdır.

Demo yerine karşılaştırılabilir kanıt isteyin

Önce agentın rolünü sınırlandırın. AI agent ve otonom sistemlerin çalışma mantığını anlamak, hangi davranışın model çıktısı, hangisinin araç kullanımı veya otomasyon kararı olduğunu ayırmayı kolaylaştırır. Teklif görüşmesinde tüm adaylardan aynı görev kümesini, aynı izinleri ve aynı ölçüm biçimini kullanmalarını istemek, AI agent firması değerlendirmesini pazarlama anlatısından çıkarıp somut kanıta taşır. Bu ölçüm seti sözleşme ekinde tanımlandığında, pilot sırasında hedeflerin sessizce değiştirilmesi veya sonucun yalnızca olumlu örneklerle yorumlanması da önlenir.

• Görev başarı oranı
• Yanlış işlem sayısı
• Yetkisiz işlem sayısı
• İnsan müdahalesi oranı
• İşlem süresi ve maliyeti

Özünde tüm modeller yanlıştır, ancak bazıları kullanışlıdır. - George E. P. Box

Pilot için gerçek görev örnekleri nasıl seçilmelidir?

Pilot görevleri, en kolay senaryolardan değil, canlı kullanımda karşılaşılacak işlerin temsilî bir örnekleminden seçilmelidir. Yüksek hacimli rutin işler, istisnalar, eksik veri içeren vakalar ve geri dönüş gerektiren adımlar aynı test kümesinde bulunmalıdır. Böylece agent pilot projesi yalnızca ideal koşulları değil, günlük operasyonun karar yükünü ve hata riskini de ölçer.

Test kümesini iş hacmi ve riskle dengeleyin

Görev havuzunu oluştururken geçmiş işlem kayıtları, destek talepleri, CRM veya ERP senaryoları gibi gerçek örnekler tercih edilebilir; ancak kişisel ve hassas veriler uygun biçimde korunmalıdır. PoC, veri güvenliği ve entegrasyon değerlendirmesi de pilot tasarımının parçasıdır. Sağlayıcıya sadece başarılı örnekleri değil, agentın karar vermekte zorlanacağı sınır durumlarını da vermek gerekir. Görev dağılımı, gerçek operasyon içindeki yaklaşık sıklığı ve ticari etkisiyle birlikte işaretlenirse, nadir fakat yüksek riskli vakaların ortalama başarı oranı içinde kaybolması engellenir.

• Yüksek hacimli rutin görevler
• İstisnalı ve eksik veri vakaları
• Yetki gerektiren işlemler
• Geri alma gerektiren senaryolar
• İnsana aktarılması gereken durumlar

Başarılı işlem tanımı hangi metriklerle kurulmalıdır?

Başarılı işlem, agentın yalnızca doğru cevabı üretmesi değil, görevi baştan sona tanımlanan kurallara uygun tamamlamasıdır. Örneğin bir sipariş değişikliğinde doğru müşteri kaydını bulması, doğru aracı çağırması, yetki sınırını kontrol etmesi, işlemi kaydetmesi ve kullanıcıya tutarlı sonuç bildirmesi birlikte değerlendirilmelidir. Bu nedenle yapay zeka kabul kriterleri tek bir doğruluk yüzdesine indirgenmemelidir.

Sonuç kadar süreç davranışını da ölçün

Her görev için beklenen çıktı, izin verilen araçlar, kabul edilen süre, hata sınıfları ve maliyet ölçümü önceden yazılmalıdır. Başarılı işlem tanımı, “sonuç doğruysa geçer” yaklaşımından daha ayrıntılı olmalıdır; çünkü yanlış sistem çağrısı yapan fakat tesadüfen doğru cevaba ulaşan bir agent operasyonel açıdan güvenilir sayılmaz. Metrikler görevin riskine göre ağırlıklandırılabilir, ancak ağırlıklar pilot başlamadan önce sabitlenmelidir. Ayrıca her metriğin hangi veri kaynağından hesaplanacağı belirlenmeli; sağlayıcı raporu ile müşteri tarafındaki işlem kayıtları arasında denetlenebilir bir eşleşme kurulmalıdır.

• Doğru sonuç üretimi
• Doğru araç çağrısı
• Doğru kayıt güncellemesi
• Süre hedefinin karşılanması
• İşlem başı maliyet

Yanlış ve yetkisiz işlemler nasıl kayıt altına alınır?

Yanlış ve yetkisiz işlemler aynı hata sınıfında tutulmamalıdır. Yanlış işlem, agentın izinli bir görevi hatalı gerçekleştirmesi olabilir; yetkisiz işlem ise kapsam dışındaki bir sistemi çağırması, onay gerektiren adımı atlaması veya erişmemesi gereken veriye yönelmesi gibi daha kritik bir ihlaldir. Sözleşmede bu olayların tanımı, önem seviyesi, log kaydı ve raporlama yöntemi ayrı ayrı belirtilmelidir.

Hata taksonomisini pilot başlamadan sabitleyin

Hata sınıfları sağlayıcı tarafından sonradan yeniden yorumlanmamalıdır. hata yönetimi ve insan onayının nasıl test edileceğine ilişkin çerçeve, agent için de doğrudan uygulanabilir. Kritik hatalarda yalnızca oran değil, tekil olay sayısı da önemlidir; çünkü düşük frekansta görülen bir yetkisiz işlem bile yüksek etkili bir süreçte üretime geçişi durdurabilir. Olay kaydında görev kimliği, zaman damgası, çağrılan araç, yetki kararı ve varsa insan müdahalesi birlikte tutulmalıdır.

• Yanlış sonuç
• Yanlış araç veya API çağrısı
• Yetkisiz veri erişimi
• Onaysız işlem yürütme
• Eksik veya hatalı log

İnsan onayı gereken agent işlemleri nasıl belirlenir?

İnsan onayı, tüm işlemlere eklenen genel bir kontrol değil, hata etkisinin yüksek olduğu adımlara yerleştirilen bir risk yönetimi katmanı olmalıdır. Finansal işlem, müşteri taahhüdü, veri silme, erişim yetkisi değiştirme veya geri döndürülmesi zor operasyonlar gibi durumlarda agentın tek başına ilerlememesi; öneri üretip açık bir onay beklemesi daha güvenli bir tasarımdır.

Onay eşiğini risk ve geri döndürülebilirlikle tanımlayın

üretim ortamı, güvenlik ve insan onayı tasarımı pilot kabul kriterleriyle birlikte düşünülmelidir. İnsan onaylı agent sistemi için hangi olayda kimin onay vereceği, onay gelmezse akışın ne yapacağı ve agentın aynı işlemi tekrar deneyip deneyemeyeceği yazılmalıdır. Böylece insan müdahalesi, belirsiz bir güvenlik freni olmaktan çıkar ve ölçülebilir bir süreç kuralına dönüşür.

• Finansal veya sözleşmesel etkiler
• Silme ve geri döndürülemez işlemler
• Yetki veya erişim değişiklikleri
• Müşteriye bağlayıcı taahhütler
• Düşük güvenli karar durumları

Agent doğruluk testi tek başına neden yeterli değildir?

Agent doğruluk testi gereklidir ancak tek başına satın alma kararı için yeterli değildir; çünkü doğru bir metin yanıtı, arka plandaki işlemin doğru yürütüldüğünü kanıtlamaz. Agent yanlış müşteri kaydını açabilir, gereksiz araç çağrıları yapabilir, çok uzun sürede tamamlayabilir veya yüksek model ve API maliyeti oluşturabilir. Bu nedenle çıktı kalitesi, davranış doğruluğu ve operasyonel verimlilik birlikte izlenmelidir.

Kaliteyi davranış ve maliyetle birlikte okuyun

Agent performans ölçümü için tek bir birleşik puan kullanılacaksa, puanın alt bileşenleri görünür kalmalıdır. Aksi halde yüksek yanıt kalitesi, ciddi bir yetki ihlalini veya sürdürülemez işlem maliyetini gizleyebilir. Karşılaştırılabilir skor, adayların aynı görevlerde nasıl davrandığını gösterirken kritik hata sınıflarını ayrı eşiklerle korumalı; örneğin belirli bir güvenlik ihlali toplam skordan bağımsız olarak başarısızlık nedeni sayılabilmelidir.

• Yanıt veya karar kalitesi
• Araç kullanım doğruluğu
• Yetki sınırına uyum
• Uçtan uca işlem süresi
• Görev başına toplam maliyet

Pilot verisi ve test sonuçları nasıl tekrar üretilebilir?

Test sonuçlarının tekrar üretilebilir olması için pilotun veri kümesi, sürüm bilgileri, sistem izinleri, entegrasyon durumu ve ölçüm yöntemi kayıt altına alınmalıdır. Aynı görev farklı günlerde veya farklı sağlayıcılarda farklı koşullarla çalıştırılırsa sonuçların karşılaştırma değeri düşer. Bu nedenle değerlendirme protokolü, mümkün olduğunca sabit girdiler ve açık değişkenlerle tanımlanmalıdır.

Temsilî veri ile kontrollü test ortamını dengeleyin

Pilot verisi canlı iş yükünü temsil etmeli fakat ölçümü bozacak kontrolsüz değişikliklerden arındırılmalıdır. Sağlayıcıdan kullanılan model sürümünü, prompt veya politika katmanındaki önemli değişiklikleri, araç sürümlerini ve test tekrarlarının tarihini kaydetmesi istenebilir. Tekrar testinde aynı başarısız görevlerin düzelip düzelmediği görülebilmeli; yeni sürümün önceki başarılı görevlerde gerilemeye yol açıp açmadığı da ayrıca kontrol edilmelidir.

• Sabit görev kimlikleri
• Model ve yapılandırma sürümleri
• Aynı izin ve entegrasyon koşulları
• Standart log ve rapor formatı
• Tekrar test ve regresyon kayıtları

Başarısız pilotta düzeltme kapsamı nasıl yazılmalıdır?

Pilot başarısız olduğunda sözleşme, sağlayıcının hangi hataları hangi kapsamda düzelteceğini ve yeniden testin nasıl yapılacağını önceden açıklamalıdır. “Gerekli iyileştirmeler yapılır” gibi açık uçlu bir ifade yerine, kabul kriterini karşılamayan senaryoların sınıflandırılması, düzeltme sorumluluğu, yeniden test kapsamı ve üretime geçiş kararının ertelenmesi gibi sonuçlar tanımlanmalıdır.

Kabul maddesini yeniden test süreciyle birlikte kurun

test ve kabul kriterlerinin sözleşmeye dahil edilmesi agent projelerinde de teslim yönetiminin temelidir. Düzeltme yalnızca başarısız örneği “özel olarak” geçecek hale getirmek değil, aynı hata sınıfının kök nedenini gidermek olmalıdır. Yeniden testte hem başarısız vakalar hem de önceki başarılı vakalardan seçilen regresyon kümesi çalıştırılmalıdır.

• Başarısız senaryoların listesi
• Kök neden ve düzeltme kaydı
• Yeniden test kapsamı
• Regresyon kontrolü
• Kabul veya erteleme kararı

Üretime geçiş ve canlı performans sorumluluğu kimdedir?

Canlı performansın takibi tek başına sağlayıcıya veya müşteriye bırakılmamalı; veri üretimi, teknik izleme, operasyonel yorumlama ve aksiyon alma sorumlulukları taraflar arasında açıkça bölünmelidir. Sağlayıcı teknik logları ve agent davranış metriklerini sunarken, iş sahibi ekip hangi sonuçların operasyonel hata sayılacağını ve hangi değişikliğin iş kuralı güncellemesi gerektirdiğini belirlemelidir.

Canlı izlemeyi pilotun devamı olarak tasarlayın

Üretime geçiş kararı, pilot kabulünden sonra yeni bir izleme dönemini başlatmalıdır. Sözleşmede raporlama sıklığı, kritik olay bildirimi, model veya entegrasyon değişikliği sonrası yeniden test ve performans düşüşünde uygulanacak aksiyon belirtilmelidir. Sorumluluk matrisi, kimin alarmı izleyeceğini, kimin iş kuralını onaylayacağını, kimin teknik düzeltmeyi yapacağını ve kimin üretimi durdurma yetkisine sahip olduğunu netleştirir.

• Teknik izleme sorumlusu
• İş metriği sahibi
• Kritik olay bildirim akışı
• Değişiklik sonrası yeniden test
• Üretimi durdurma yetkisi

AI otomasyon hizmet sözleşmesi teklifleri nasıl karşılaştırılır?

AI otomasyon hizmet sözleşmesi teklifleri, vaat edilen özellik sayısıyla değil, aynı pilot görevleri ve aynı kabul kriterlerini hangi kapsamda karşıladıklarıyla karşılaştırılmalıdır. Yapay zeka sağlayıcı teklifi; test verisinin hazırlanmasını, entegrasyon sorumluluklarını, ölçüm araçlarını, düzeltme turunu, canlı izlemeyi ve destek sınırlarını açıkça göstermelidir. Böylece düşük görünen bir teklifin kritik faaliyetleri kapsam dışında bırakıp bırakmadığı anlaşılabilir. Teklifler arasında kıyas yapılırken tek seferlik kurulum bedelinden çok, ölçüm altyapısı, model ve API kullanımı, bakım, yeniden test ve destek gibi toplam sahip olma maliyeti kalemlerinin kapsamı karşılaştırılmalıdır.

Teklif görüşmesine ortak değerlendirme listesiyle girin

Karar vericiler tüm adaylara aynı soruları yönelttiğinde fiyat dışındaki farklar daha görünür hale gelir. Pilotun kabul eşiği, yetkisiz işlem toleransı, insan onayı noktaları, tekrar test yöntemi ve canlı izleme sorumluluğu teklif ekinde yazılı hale getirilmelidir. Bu yaklaşım, sağlayıcı seçimini öznel demo beğenisinden çıkarır ve satın alma ekibine sözleşme öncesinde karşılaştırılabilir bir karar zemini sağlar.

• Aynı pilot görev kapsamı
• Aynı başarı ve hata tanımları
• Açık düzeltme ve yeniden test şartları
• Canlı izleme ve destek sorumluluğu
• Entegrasyon ve kullanım maliyeti kapsamı