Bir AI kullanım senaryosu ürüne alınmadan önce nasıl doğrulanır?

Bir AI kullanım senaryosu, gerçek bir kullanıcı problemini mevcut çözümden daha iyi karşıladığı; yeterli kalite, kabul edilebilir risk ve sürdürülebilir maliyetle çalıştığı gösterildiğinde ürüne alınmaya hazır hale gelir. Bunun için kullanıcı araştırması, ölçülebilir başarı kriterleri, gerçekçi test verileri, kullanılabilirlik testleri ve kontrollü pilot birlikte yürütülmelidir.

Bir demoda birkaç saniyede hazırlanan rapor etkileyici olabilir. Ancak rapordaki rakamları kontrol etmek, yanlış çıkarımları düzeltmek ve eksik bağlamı tamamlamak kullanıcıya on dakika daha harcatıyorsa, ürün gerçekten iş yükünü azaltmış mıdır?

AI ürün geliştirme süreçlerinde asıl soru burada başlar. Modelin bir çıktı üretebilmesi, o çıktının kullanıcı için değerli olduğu anlamına gelmez. Kullanıcının özelliği beğenmesi de onu günlük işinin bir parçası yapacağını kanıtlamaz.

Başarılı bir demo, keşfe devam etmek için iyi bir nedendir. Ürüne alma kararı ise daha güçlü kanıt ister.

AI kullanım senaryosu doğrulama nedir?

AI kullanım senaryosu doğrulama; yapay zekânın belirli bir kullanıcı, görev ve bağlam için işe yarayıp yaramadığını sistematik olarak sınamaktır. Değerlendirilen şey yalnızca modelin doğruluğu değildir. Kullanıcının girdiyi nasıl verdiği, sonucu nasıl anladığı, hatayı nasıl fark ettiği ve işi nasıl tamamladığı da doğrulamanın parçasıdır.

Bu değerlendirme beş temel soruya cevap vermelidir:

Bu yazıdaki çerçeve, özellikle üretken AI ve AI asistanları içeren dijital ürünler için önerdiğimiz pratik bir değerlendirme yaklaşımıdır. Evrensel bir sertifikasyon standardı veya her ürün için aynı şekilde uygulanacak bir kontrol listesi değildir.

1. AI fikrini ölçülebilir bir kullanıcı problemine dönüştürün

“Ürünümüze AI asistanı ekleyelim” bir çözüm fikridir. Hangi sorunu çözeceğini henüz söylemez.

Daha iyi bir başlangıç, kullanıcının bugün yapmak zorunda olduğu işi tarif etmektir:

Çok şubeli işletmelerin bölge yöneticileri, haftalık performans değerlendirmesinde farklı ekranlardan veri topluyor ve hangi şubelerde inceleme gerektiğini belirlemek için zaman harcıyor.

Bu problem tanımı, çözümü hemen bir sohbet arayüzüne bağlamaz. Belki daha iyi bir karşılaştırma ekranı yeterlidir. Belki kural tabanlı uyarılar sorunu çözer. Belki de AI’ın farklı verileri bir araya getirip inceleme önerileri sunması anlamlıdır.

Önce mevcut iş akışını gözlemleyin. Kullanıcı nerede bekliyor? Hangi bilgileri birleştiriyor? Hangi adımda hata yapıyor? İşin ne kadarını rutin işlem, ne kadarını yorumlama oluşturuyor?

Görüşmelerde “AI kullanır mıydınız?” sorusundan çok, kullanıcının son yaşadığı somut durumu inceleyin. En son hazırladığı raporu, kullandığı dosyaları ve sonucu kiminle paylaştığını anlamak, varsayımsal bir ilgi beyanından daha fazla bilgi verir.

Doğrulamanın ilk çıktısı bir özellik listesi değil; hedef kullanıcı, görev, sorun ve beklenen iyileşmenin açık tanımı olmalıdır.

2. Mevcut çözümü ölçün ve AI içermeyen alternatifi karşılaştırmaya alın

Bir AI özelliğinin değerini anlamak için karşılaştırma noktası gerekir. Buna başlangıç ölçümü, yani baseline denir.

Örneğimizde bölge yöneticisinin haftalık incelemeyi bugün nasıl tamamladığını ölçebiliriz: toplam süre, yanlış karşılaştırmalar, atlanan şubeler ve raporun yeniden hazırlanma sıklığı.

Ardından üç yaklaşımı karşılaştırabiliriz: mevcut akış, iyileştirilmiş standart arayüz ve AI destekli akış. AI’ın sağladığı katkıyı görmek için bu ayrım önemlidir. Kazanımın tamamı ekranların sadeleştirilmesinden kaynaklanıyorsa, ek model maliyetinin hangi yeni değeri sağladığı ayrıca gösterilmelidir.

Ölçümü yalnızca çıktının oluşma süresiyle sınırlandırmayın. Kullanıcının isteğini yazması, beklemesi, kaynakları kontrol etmesi, düzeltme yapması ve sonucu kullanıma hazır hale getirmesi de toplam görev süresine dahildir.

AI’ın ne kadar hızlı yanıt verdiğini değil, kullanıcının işi ne kadar hızlı ve doğru bitirdiğini ölçün.

3. Başarı kriterlerini prototipten önce tanımlayın

“İyi sonuç veriyor” ifadesi, ekip içinde aynı anlama gelmeyebilir. Tasarımcı için anlaşılır, geliştirici için tutarlı, kullanıcı için hızlı olan bir çıktı; iş birimi açısından kullanılamaz olabilir.

Bu nedenle başarı kriterlerini testlerden önce yazılı hale getirin. Örneğin AI raporlama asistanı için şöyle bir başlangıç çerçevesi kurulabilir:

Bu kriterlerin her birine ölçüm yöntemi, sorumlu kişi ve kabul eşiği eklenmelidir. Eşikler, mevcut performans ve hata etkisi dikkate alınarak belirlenir. Bir metin taslağıyla iş kararını etkileyen performans raporuna aynı tolerans uygulanamaz.

Bazı ölçütler iyileştirme hedefidir; bazıları yayına geçişi engelleyen koşuldur. Örneğin daha kısa yanıt süresi bir optimizasyon hedefiyken, başka bir müşterinin verisinin görünmesi yayını durdurmayı gerektiren bir bulgudur. Bu iki tür kriteri tek bir ortalama puana dönüştürmeyin.

4. Gerçekçi bir değerlendirme veri seti hazırlayın

Ürünü geliştiren kişinin yazdığı birkaç düzgün komut, gerçek kullanımın çeşitliliğini temsil etmez.

Test seti, ürünün karşılaşacağı girdileri ve koşulları kapsamalıdır. Raporlama asistanında bunun anlamı; farklı şube sayıları, eksik haftalar, farklı tarih formatları, çelişkili kayıtlar, belirsiz talepler ve erişim kısıtlarıdır.

Sadece başarılı yanıt beklenen örnekleri test etmeyin. “Bu soruya mevcut veriyle cevap verilemez” durumları da test setinde yer almalıdır. Kullanıcının isteğindeki eksikliği fark edip açıklayıcı bir soru sormak, bazı görevlerde doğru cevaptır.

Her test vakasında girdiyi, beklenen davranışı ve kabul edilemez sonucu tanımlayın. Açık uçlu bir analiz için tek bir ideal cümle aramak yerine, doğru veriye dayanma, gerekli kapsamı karşılama ve dayanaksız çıkarımdan kaçınma gibi ölçütler kullanın.

Geliştirme sırasında kullanılan örneklerle son değerlendirmede kullanılan örnekleri ayırın. Aynı soruları tekrar tekrar iyileştirmek, sistemin yeni durumlarda da başarılı olacağını göstermeyebilir.

Anthropic’in AI ajan değerlendirmeleri üzerine çalışması da görevleri açık başarı kriterleriyle tanımlamayı ve model çıktıları değişken olduğu için bir görevde birden fazla deneme yapmayı önerir. Bu, tek seferlik iyi bir sonucun güvenilir davranışla karıştırılmasını önlemeye yardımcı olur. [1]

Test verilerini hazırlarken veri kullanım yetkisini ve hassas bilgileri de ele alın. Sentetik örnekler uç durumları üretmek için yararlı olabilir; ancak gerçek kullanımın dağılımını veya gerçek kullanıcı davranışını tek başına doğrulamaz.

5. Prototipte yalnızca ideal akışı değil, hatayı da tasarlayın

Bir AI prototipinde en kolay gösterilen an, sistemin doğru cevabı verdiği andır. Kullanıcı deneyiminin niteliği ise cevap eksik, yanlış veya gecikmiş olduğunda daha görünür hale gelir.

Raporlama asistanı “Bu şubede satış düşüşünün nedeni personel eksikliği” diyorsa, kullanıcı bunun veriye dayalı bir sonuç mu, yoksa sınanması gereken bir varsayım mı olduğunu anlayabiliyor mu?

Prototipte şu durumları görünür hale getirin:

• Veri eksik olduğunda sistem nasıl açıklama yapıyor?
• Belirsiz bir istekte hangi soruyu soruyor?
• Kullanıcı yanlış bir tarih aralığını nasıl düzeltiyor?
• Çıkarımın dayanağı nasıl inceleniyor?
• Sistem yanıt veremediğinde kullanıcı işi nasıl sürdürüyor?
• Bir aksiyon uygulanacaksa, kapsam ve onay nasıl gösteriliyor?

Erken aşamada AI yanıtlarının önceden hazırlandığı bir prototip kullanılabilir. Böyle bir prototip, kullanıcıların deneyimi anlayıp anlamadığını sınar; modelin gerçek performansını kanıtlamaz. Teknik doğrulama için gerçek model, veri kaynakları ve entegrasyonlarla ayrıca test gerekir.

Özellikle işlem yapan asistanlarda, “öneri hazırlamak” ile “işlemi gerçekleştirmek” arasındaki sınır açık olmalıdır. Rapor hazırlamakla raporu tüm şube yöneticilerine göndermek, aynı yetki ve kontrol düzeyini gerektirmez.

6. Kullanıcı testlerinde beğeniyi değil, davranışı değerlendirin

“Çok iyi olmuş” geri bildirimi memnuniyet göstergesidir. İşin başarıyla tamamlandığını göstermez.

Gerçek kullanıcı testlerinde katılımcıya bir görev verin ve nasıl ilerlediğini gözlemleyin. İlk denemede ne istediğini anlatabiliyor mu? Sonucu anlamlandırabiliyor mu? Gerekli bilgiyi kontrol ediyor mu? Yanlış yönlendiren bir çıktıyı fark ediyor mu?

Kontrollü test ortamında, gerçek iş kararlarına yansımayacak şekilde, hatalı ve eksik çıktılar da gösterilebilir. Böylece yalnızca doğru cevabın kullanılabilirliğini değil, yanlış cevabın fark edilebilirliğini de ölçebilirsiniz.

Burada hedef, kullanıcı güvenini mümkün olduğunca yükseltmek değildir. Hedef, güvenin sistemin gerçek yeterliliğiyle uyumlu olmasıdır. Kullanıcının her çıktıya kuşkuyla yaklaşması verimliliği azaltır; her çıktıyı sorgulamadan kabul etmesi ise hataları büyütebilir.

İnsan onayı da tek başına yeterli bir önlem değildir. Kullanıcı neyi kontrol ettiğini bilmiyorsa veya inceleme için yeterli bağlamı yoksa, onay düğmesi gerçek bir kontrol mekanizmasına dönüşmez.

Erken kullanılabilirlik testleri deneyimdeki sorunları keşfetmek için değerlidir. Daha geniş kullanımda benimsenme, verimlilik veya hata oranı hakkında karar vermek için ise uygun kapsamda pilot ve nicel ölçüm gerekir.

7. Teknik doğrulamayı modelin ötesine taşıyın

Kullanıcının deneyimlediği ürün; model, veri erişimi, yetkilendirme, iş kuralları, arayüz ve entegrasyonların birlikte çalışmasıyla oluşur.

Model doğru bir açıklama üretse bile eski veriyi kullanıyor olabilir. Doğru şubeyi analiz edip yanlış tarih aralığını karşılaştırabilir. Raporu hazırlayıp kayıt sırasında hata verebilir. Bu yüzden değerlendirme uçtan uca yapılmalıdır.

Raporlama örneğinde özellikle sayısal işlemlerin güvenilir hesaplama katmanlarında yapılması, AI’ın yorumunun bu sonuçlara bağlanması ve bağlantının test edilmesi önemlidir. Metnin akıcı olması, hesaplamanın doğru olduğunu göstermez.

Ortalama başarı oranını kullanıcı grupları ve görev türleri bazında da inceleyin. Sistem yaygın, kısa sorularda iyi çalışırken uzun ve karmaşık taleplerde başarısız olabilir. Benzer şekilde ortalama yanıt süresi, bazı kullanıcıların yaşadığı uzun beklemeleri gizleyebilir.

NIST’in üretken AI profili, laboratuvar koşullarındaki testlerle gerçek kullanım bağlamı arasındaki farkların değerlendirmede boşluk oluşturabileceğine dikkat çeker. Bu nedenle ürünün kendi verileri, kullanıcıları ve çalışma koşullarıyla sınanması gerekir. [2]

Yetkisiz erişim, yanıltıcı belge içeriği ve sistemin talimatlarını değiştirmeye çalışan girdiler gibi senaryolar da ürünün risk düzeyine uygun olarak test edilmelidir. Özellikle dış kaynaklardan bilgi okuyan veya işlem yapabilen asistanlarda yalnızca cevabı değil, sistemin hangi eylemleri gerçekleştirdiğini de kontrol edin.

8. Kontrollü pilotla gerçek iş değerini ölçün

Kullanılabilirlik testi, kullanıcının görevi nasıl yaptığını gösterir. Pilot ise bu deneyimin günlük iş içinde anlamlı ve sürdürülebilir olup olmadığını sınar.

Pilotu belirli kullanıcı grupları, görevler ve yetkilerle sınırlayın. Başlangıçta sistemin önerilerini işlem uygulamadan mevcut sonuçlarla karşılaştırabilir, ardından uygun görevlerde insan onaylı kullanıma geçebilirsiniz.

Mümkün olduğunda benzer görevleri yerine getiren bir karşılaştırma grubu kullanın. Yalnızca önceki hafta ile sonraki haftayı karşılaştırmak; iş yoğunluğu, veri kalitesi veya kullanıcı deneyimi gibi başka değişkenlerin etkisini AI’a atfetmenize yol açabilir.

Ölçüm planı görev sıklığına göre hazırlanmalıdır. Ayda bir yapılan bir iş için birkaç günlük kullanım, tekrar kullanım davranışını göstermeye yetmez.

AI özelliğinin gerçek maliyeti nasıl hesaplanır?

API faturası, toplam maliyetin yalnızca bir parçasıdır. Veri hazırlama, entegrasyon, izleme, insan incelemesi, yeniden deneme, destek ve bakım yükünü de hesaba katın.

Örneğin tamamen varsayımsal bir senaryoda mevcut rapor hazırlama süresi 20 dakika olsun. AI ilk çıktıyı 2 dakikada hazırlasın; kullanıcının kontrol ve düzeltmesi de 8 dakika sürsün. Gerçek kazanım 18 dakika değil, 10 dakikadır. Bazı raporların baştan hazırlanması gerekiyorsa bunun etkisi de hesaplamaya dahil edilmelidir.

Bu nedenle maliyeti yalnızca istek başına değil, başarıyla tamamlanan görev başına izlemek daha anlamlıdır. Kazanılan zamanın başka işe ayrılıp ayrılamadığını da değerlendirin; zaman tasarrufu otomatik olarak aynı tutarda nakit tasarrufu yaratmaz.

9. Yayına alma kararını önceden belirlenmiş koşullara bağlayın

Doğrulamanın sonunda yalnızca bir sunum değil, gerekçeli bir ürün kararı çıkmalıdır.

Karar kaydında test edilen kapsam, kullanılan sürümler, kabul eşikleri, bilinen sınırlamalar ve sorumlular bulunmalıdır. Bir ürün yöneticisi, tasarımcı ve teknik ekip aynı kanıtlara bakabilmelidir.

Testlerde kritik hata görülmemesi, gerçek kullanımda hiç hata olmayacağını garanti etmez. Bu nedenle yayından önce hangi koşulda özelliğin kapatılacağını, kullanıcıların hangi alternatif akışa döneceğini ve sorunlara kimin müdahale edeceğini belirleyin.

Doğrulama yayında bitmez. Model, istem, veri kaynağı veya araç izinleri değiştiğinde ilgili testler yeniden çalıştırılmalıdır. NIST AI Risk Management Framework de sistemlerin yayına alınmadan önce ve kullanım sırasında düzenli olarak test edilmesini önerir. [3]

VOYA’da AI ürün dönüşümü: Önce değeri doğrulamak

VOYA’nın AI ürün dönüşümü yaklaşımı, ürünü ve kullanıcıyı anlamakla başlar. AI’ın değer yaratabileceği alanlar belirlendikten sonra iş akışları yeniden düşünülür, prototipler oluşturulur ve gerçek kullanıcılarla değer, güven ve kontrol değerlendirilir. Doğrulanan deneyim daha sonra ürüne ve tasarım sistemine taşınır.

Bu yaklaşımda doğrulama, geliştirme tamamlandıktan sonra yapılan son kontrol değildir. Hangi deneyime yatırım yapılacağını belirleyen bir ürün kararıdır.

Bir raporlama ürününde amaç daha uzun analizler üretmek olmayabilir. Kullanıcının hangi şubeye bakması gerektiğini daha hızlı anlaması yeterli değer yaratabilir. Başka bir üründe ise kullanıcıya öneri sunmak yeterli olmaz; sonuca kadar uzanan iş akışını yeniden tasarlamak gerekir.

Ürününüzde hangi AI kullanım senaryolarının önceliklendirilmesi gerektiğini ve bu deneyimlerin nasıl doğrulanabileceğini değerlendirmek için VOYA’nın AI ürün dönüşümü yaklaşımını inceleyin.

Doğru başlangıç sorusu “AI ile ne yapabiliriz?” kadar, “Kullanıcının hangi işini gerçekten iyileştirdiğimizi nasıl gösterebiliriz?” olmalıdır.

Sık sorulan sorular

Bir AI kullanım senaryosunu doğrulamak için çalışan bir ürün gerekir mi?

Hayır. Kullanıcı problemini ve önerilen deneyimin anlaşılabilirliğini araştırma ve prototiplerle sınayabilirsiniz. Ancak modelin doğruluğunu, gecikmesini, maliyetini ve entegrasyon davranışını doğrulamak için çalışan bir teknik kurulum gerekir. Deneyim prototipi, teknik performansın kanıtı değildir.

AI PoC ile ürün doğrulaması arasındaki fark nedir?

PoC, yani kavram kanıtı, genellikle bir yaklaşımın teknik olarak mümkün olup olmadığını sınar. Ürün doğrulaması ise bunun kullanıcı için anlamlı, kullanılabilir ve sürdürülebilir olup olmadığını değerlendirir. Teknik olarak çalışan bir PoC, tek başına yayına alma kararı için yeterli değildir.

AI özelliği için kaç test örneği gerekir?

Her ürün için geçerli tek bir sayı yoktur. Örnek sayısı; görev çeşitliliğine, hata etkisine, beklenen hata sıklığına ve ölçüm hassasiyetine bağlıdır. Önce kritik senaryoları kapsayan bir set oluşturulmalı, gerçek kullanımda keşfedilen durumlarla genişletilmelidir. Küçük bir sette hiç hata görülmemesi, düşük hata oranını güvenilir biçimde kanıtlamaz.

AI çıktılarının doğruluğu tek başına yeterli mi?

Hayır. Doğru bir çıktı, kullanıcının ihtiyacına uymayabilir veya onu kontrol etmek çok uzun sürebilir. Görev tamamlama, düzeltme yükü, gecikme, yetkilendirme, toplam maliyet ve kullanıcının kontrolü birlikte değerlendirilmelidir.

AI değerlendirmelerini başka bir AI ile yapmak doğru mu?

Bir değerlendirici model, açık ölçütlerle çok sayıda çıktıyı incelemek için kullanılabilir. Ancak onun kararları da hatalı veya tutarsız olabilir. Temsili örneklerde uzman değerlendirmesiyle uyumu kontrol edilmeli; kritik doğruluk ve yetkilendirme kontrolleri uygun olduğunda doğrudan sistem kontrolleriyle yapılmalıdır. Değerlendirici modelin puanı, gerçek kullanıcı testlerinin yerine geçmez. Anthropic de model tabanlı değerlendirmelerin insan değerlendirmeleriyle kalibre edilmesini ele alır. [1]

Kaynaklar

1. Anthropic — Demystifying evals for AI agents
2. NIST — Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile
3. NIST — Artificial Intelligence Risk Management Framework, AI RMF 1.0
4. VOYA — AI Ürün Dönüşümü ve AI-Native Deneyim Tasarımı