Bir Yapay Zekâ Asistanı Lansmandan Önce Nasıl Test Edilir: Kendi Vakalarınızdan Bir Test Seti Oluşturun, Geçme Eşiklerini Belirleyin ve Onayı Kimin Vereceğine Karar Verin

Bir yapay zekâ asistanı belgelerinizden soruları yanıtlayabilir, müşterilere yanıt taslakları hazırlayabilir ya da formlardan veri çekebilir. Demo bunu yapabildiğini gösterir; ama sizin vakalarınızda ne sıklıkla ve ne şekilde hata yaptığını göstermez. Bunun için geçmişteki gerçek vakalardan oluşturulmuş bir teste ihtiyacınız vardır. Her vaka için doğru yanıtı kendi çalışanlarınız yazar ve her türden kaç hatayı kabul edeceğinizde önceden anlaşırsınız. Ardından sizin tarafınızda adı belirlenmiş bir kişi sonuçları onaylar.

İyi bir yapay zekâ demosu neden bir test değildir?

Bir demo, satıcının seçtiği soruları gösterir ve her biri yalnızca bir kez yanıtlanır. Müşterileriniz ve çalışanlarınız ise başka soruları kendi kelimeleriyle soracaktır; üstelik aynı soru ikinci denemede farklı bir yanıt alabilir.

OpenAI'ın değerlendirmeye ilişkin en iyi uygulamalar rehberi tam da bu noktayla açılıyor: “Üretken yapay zekâ değişkendir. Modeller bazen aynı girdiden farklı çıktılar üretir; bu da geleneksel yazılım test yöntemlerini yapay zekâ mimarileri için yetersiz kılar.” Bu yazıdaki tüm kaynaklara 4 Kasım 2026'da erişildi.

Rehber, bir modelin yanıtlarını sınayan testlere evals diyor; bu, evaluations (değerlendirmeler) sözcüğünün kısaltmasıdır. Rehberin saydığı hatalardan biri, izlenime dayalı (vibe-based) eval'dir: “‘Çalışıyor gibi görünüyor’ yaklaşımını bir değerlendirme stratejisi olarak kullanmak ya da herhangi bir eval uygulamak için ürünü yayına almayı beklemek.”

ABD Ulusal Standartlar ve Teknoloji Enstitüsü NIST, Temmuz 2024'te gönüllülük esasına dayalı bir rehber olarak Generative AI Profile adlı belgeyi yayımladı. Profil, üretken yapay zekâyı (generative AI) GAI olarak kısaltıyor. Önerdiği eylemlerden biri şöyle: “Dar, sistematik olmayan ve anekdota dayalı değerlendirmelerden yola çıkarak GAI sisteminin performansı ya da yetenekleri hakkında genelleme yapmaktan kaçının.”

Test seti, bir demonun yapamadığını yapar: her birinin beklediğiniz yanıtı olan ve her değişiklikten sonra aynı şekilde puanlanan gerçek vakalardan oluşan bir liste.

Test vakaları nereden gelmeli?

Kendi işinizden ve aşağı yukarı asistanın karşılaşacağı oranlarda. Anthropic'in Claude modelleri için başarı kriterlerini tanımlamaya ve değerlendirmeler oluşturmaya yönelik rehberi şöyle diyor: “Gerçek dünyadaki görev dağılımınızı yansıtan eval'ler tasarlayın.”

OpenAI'ın rehberi şunu ekliyor: “Test verilerinizin tipik vakaları, uç vakaları ve kötü niyetli (adversarial) vakaları içerdiğinden emin olun.” Uç vakalar nadir ya da çetrefilli girdilerdir. Kötü niyetli vakalar ise asistanı hatalı davranmaya zorlamaya çalışır. Vakaları şu kaynaklardan derleyin:

• Mevsimsel olanların da görünmesi için tam bir yılı ve her kategoriyi kapsayan geçmiş sorular ve destek talepleri
• Asistanın okuyacağı her türden belge; taramalar ve alışılmadık sayfa düzenleri dahil
• Çetrefilli vakalar; örneğin iki konuyu bir arada soran bir soru ya da bir alanı eksik bir form
• Belgelerinizin yanıtlamadığı sorular; bu durumda doğru sonuç, bunu söylemek ve konuyu bir kişiye devretmektir
• Kırmızı çizgi vakaları; örneğin başka bir müşterinin verilerini isteyen bir talep ya da politikanızın yasakladığı bir iade
• Asistanı kandırma girişimleri; örneğin bir destek talebine ya da yüklenen bir dosyaya gizlenmiş talimatlar

Bir test seti için standart bir büyüklük yoktur. Pratik bir başlangıç, soru türü başına birkaç düzine vakadır; çünkü yalnızca on vaka olduğunda tek bir başarısızlık o türün puanını on yüzde puan değiştirir. Her kırmızı çizgi vakasını birkaç farklı ifadeyle yazın; çünkü bir model bir ifadeyi reddedip bir başkasını kabul edebilir.

Set gerçek müşteri verileri içerir; bu yüzden ona, alındığı destek talepleri ve belgelerle aynı erişim kurallarını uygulayın.

Beklenen yanıtları kim yazar ve bunlara neler girer?

Beklenen yanıtları asistanı geliştiren firma değil, kendi uzmanlarınız yazar. Mühendislerin ground truth adını verdiği beklenen yanıt, dikkatli bir çalışanın kabul edeceği yanıttır. Biçimi işin türüne bağlıdır:

• Belgelere dayalı yanıtlar: yanıtın içermesi gereken bilgiler, bu bilgilerin geldiği belge ile bölüm ve yanıtın söylememesi gerekenler. Eksiksiz bir örnek yanıt daha az işe yarar, çünkü doğru bir yanıt pek çok farklı şekilde ifade edilebilir
• Yanıt taslakları: kısa bir kontrol listesi; örneğin doğru bilgiler, izlenen politika ve politika dışında hiçbir söz verilmemesi
• Belgelerden çıkarılan veriler: her alanın, sisteminizin sakladığı biçimdeki doğru değeri

OpenAI'ın belgeler üzerinden soru yanıtlamaya ilişkin örneği, test verilerini kısmen “alan uzmanlarının hazırladığı sorulara ait, sabit olarak girilmiş doğru yanıtlardan” oluşturuyor. Sizin şirketinizde bu uzmanlar, destek ekibi liderleri ve politika sahipleridir.

Her yanıtı ikinci bir uzman kontrol eder. İki dikkatli kişi aynı fikirde değilse, vakanın dayandığı politika muhtemelen belirsizdir ve onu okuyan bir asistan da zorlanacaktır. Anthropic'in rehberi bu tür vakaları uç vaka örnekleri arasında sayıyor: “İnsanların bile bir değerlendirme üzerinde uzlaşmakta zorlanacağı belirsiz test vakaları”. Kararı politikanın sahibi verir; siz de test vakasıyla birlikte belgeyi düzeltirsiniz.

Her vakayla birlikte soru türünü ve dayandığı belge sürümünü kaydedin. Bir politika değiştiğinde ilgili vakaları güncelleyin; yoksa set artık doğru olan yanıtları başarısız sayar.

Geçme eşiklerini nasıl belirleriz?

Geçme eşiği, lansmandan önce kabul ettiğiniz en düşük sonuçtur. Her soru türü ve her hata türü için ayrı bir eşik belirleyin; çünkü asistanın tamamı için tek bir geçme eşiği çok fazla şeyi gizler. Anthropic'in rehberi şunu belirtiyor: “Çoğu kullanım senaryosu, birkaç başarı kriterine göre çok boyutlu bir değerlendirme gerektirir.”

Başarısız olan her vakayı şu hata türlerinden birine ayırın:

• Yanlış bilgi: yanıt doğru olmayan bir şey söylüyor. NIST'in profili buna konfabülasyon (confabulation) diyor: “Kullanıcıları yanıltabilecek ya da aldatabilecek, kendinden emin bir şekilde ifade edilmiş ama hatalı ya da yanlış içerik üretilmesi (gündelik dilde ‘halüsinasyonlar’ ya da ‘uydurmalar’ olarak bilinir).”
• Eksik yanıt: yanıt belgelerde vardı, ama asistan bilmediğini söyledi ya da önemli bir bilgiyi atladı
• Yanlış kaynak: yanıt, kendisini desteklemeyen bir belgeye ya da belgenin eski bir sürümüne atıf yapıyor
• Güvenli olmayan yanıt: bir kırmızı çizgi vakası yanlış gitti
• Biçim ve ton: bilgiler doğru, ama yanıt fazla kısa ve soğuk ya da yanlış formatta

Bu hataların maliyeti aynı değildir. Eksik bir yanıt genellikle vakayı bir kişinin devralmasıyla sonuçlanır. Yanlış bir bilgi ise müşteriye doğruymuş gibi görünerek ulaşır ve kimse fark etmeyebilir. Bu yüzden yanlış bilgilere eksik yanıtlardan daha sıkı bir geçme eşiği, tona ise en esnek eşik uygulanır.

Kırmızı çizgi vakalarının hepsi geçmek zorundadır. Tek bir başarısızlık, siz nedenini düzeltene ve setin tamamı yeniden geçene kadar lansmanı durdurur.

Soru türleri de birbirinden farklıdır; çünkü çalışma saatleriyle ilgili bir hata, ücretlerle ilgili bir hatadan daha ucuza mal olur. Her geçme eşiğini, o hatanın size maliyetine ve ekibinizin bugün aynı vakalarda ne sıklıkla hata yaptığına dayandırın. Kimse onları sonuçlara uyacak şekilde ayarlamasın diye geçme eşiklerini ilk çalıştırmadan önce yazıya dökün.

Asistanın yanıtlarını kim ya da ne puanlar?

Belgelerden çıkarılan verileri kod puanlayabilir: her alan ya beklenen değerle eşleşir ya da eşleşmez. Serbest metin yanıtlar ve taslaklar ise insanların ya da kontrol listesine göre çalışan ikinci bir dil modelinin yargısına ihtiyaç duyar.

Anthropic'in rehberi, insanların yaptığı puanlamayı şöyle tanımlıyor: “En esnek ve yüksek kaliteli, ancak yavaş ve pahalı. Mümkünse kaçının.” Bir modelin yaptığı puanlamayı ise “hızlı ve esnek, ölçeklenebilir ve karmaşık yargılar için uygun” olarak tanımlıyor ve ardından şunu öneriyor: “Önce güvenilirliği sağlamak için test edin, sonra ölçeklendirin.”

Puanlayıcı olarak kullanılan bir modelin bilinen eğilimleri vardır. OpenAI'ın rehberi, karşılaşılan zorluklar arasında şunları sayıyor: “Konum yanlılığı (yanıtların sırası), uzunluk yanlılığı (daha uzun yanıtları tercih etme)”. Yani yanıtların sırası kararı etkileyebilir ve daha uzun bir yanıt yalnızca uzunluğu sayesinde kazanabilir. Rehberin ipuçları arasında şu da var: “Otomatik puanlamayı kalibre etmek için insan geri bildirimini kullanın.” Uygulamada uzmanlarınız, modelin de puanladığı bir örneklemi puanlar ve ikisinin ayrıştığı her noktada kontrol listesini düzeltirsiniz.

Taslaklar için kör test işe yarar. Asistanın taslaklarını çalışanlarınızın aynı destek taleplerine verdiği yanıtlarla karıştırın ve inceleyicilerin, hangisinin hangisi olduğunu bilmeden bunları puanlamasını sağlayın. OpenAI'ın rehberi, insanların yaptığı puanlamaya örnek olarak “randomize, kör bir test” veriyor.

Her beklenen yanıt kaynağını belirttiği için getirme (retrieval) adımını, yani modelin okuduğu pasajları bulan arama adımını da kontrol edebilirsiniz. Arama doğru pasajı hiç bulamadıysa, modeli değil aramayı düzeltin. NIST'in profili bununla ilişkili bir kontrol öneriyor: “Devreye alma öncesi risk ölçümü ve süregelen izleme faaliyetleri sırasında GAI sistemi çıktılarındaki kaynakları ve atıfları gözden geçirin ve doğrulayın.”

Her vakayı birkaç kez çalıştırın ve önemli soruları birden fazla ifadeyle sorun. Anthropic'in rehberi tutarlılığı başlı başına bir kriter olarak ele alıyor: “Bir kullanıcı aynı soruyu iki kez sorarsa, anlamsal olarak benzer yanıtlar alması ne kadar önemlidir?” Anlamsal olarak benzer, yanıtların farklı kelimelerle de olsa aynı şeyi söylemesi demektir.

Test setini ne zaman yeniden çalıştırırız?

Her değişiklikten sonra, değişiklik müşterilere ulaşmadan önce. Bu; yeni bir model sürümü, düzenlenmiş belgeler, yeni arama ayarları ya da yeni bir prompt, yani modelin izlediği yazılı talimatlar demektir. OpenAI'ın rehberi bunu ayrı bir adım olarak ele alıyor: “Her değişiklikte eval'leri çalıştırmak için sürekli değerlendirme (CE) kurun”.

Her çalıştırma gerilemeleri (regression), yani bir değişiklikten önce geçen ama sonra başarısız olan vakaları arar. Bir soru türü bozulurken ortalama yükselebilir; bu yüzden her türe ayrı ayrı bakın. Bir değişiklik ancak şu koşullarda canlıya çıkar:

• Hiçbir kırmızı çizgi vakası başarısız olmuyor
• Hiçbir soru türü kendi geçme eşiğinin altına düşmüyor
• Her yeni başarısızlığı bir kişi okumuş ve nedenini biliyor

Her çalıştırmanın sonuçlarını, test edilen model, prompt ve belge sürümleriyle birlikte saklayın.

Sağlayıcılar da modelleri kendi takvimlerine göre kullanımdan kaldırır. OpenAI'ın kullanımdan kaldırma (deprecations) sayfasına göre, güvenlik ya da uyum kaygıları daha hızlı bir takvim gerektirmedikçe genel kullanıma sunulmuş modeller için en az altı ay önceden bildirim yapılır. Önizleme modelleri çok daha kısa bir bildirimle kullanımdan kaldırılabilir. Anthropic'in sayfasına göre herkese açık olarak yayımlanan modeller için en az 60 gün önceden bildirim yapılır; sayfa şu uyarıda da bulunuyor: “Kullanımdan kaldırma tarihini geçmiş modellere yapılan istekler başarısız olur.”

Bu bildirim süresi, seti yerine gelecek model üzerinde çalıştırmanız, başarısız olanları düzeltmeniz ve yeniden onay vermeniz için size kalan zamandır. Bunu en baştan planlayın ve bütçelendirin.

Lansmandan sonra neleri kontrol ederiz?

Her hafta bir uzman, gerçek yanıtlardan ve taslaklardan alınmış rastgele bir örneklemi aynı kontrol listesiyle puanlar; çünkü canlı trafik kimsenin aklına gelmemiş vakalar getirir. Bu, her yanıtın değil, bir örneklemin insan tarafından incelenmesidir.

NIST'in, Ocak 2023 tarihli ve gönüllülük esasına dayalı bir rehber olan AI Risk Management Framework'ü şöyle diyor: “Yapay zekâ sistemleri devreye alınmadan önce ve çalışırken düzenli olarak test edilmelidir.” NIST, çerçevenin gözden geçirilmiş bir sürümü üzerinde çalışıldığını söylüyor.

Çalışanlara ve müşterilere kötü bir yanıtı kolayca işaretleyebilecekleri bir yol sunun ve doğrulanan her başarısızlığı yeni bir test vakasına dönüştürün. OpenAI'ın ipuçlarından biri şöyle: “Geliştirme sırasında loglama yapın; böylece loglarınızı tarayarak iyi eval vakaları bulabilirsiniz.”

Lansmanı kim onaylar ve hangi kanıtlara dayanarak?

Onayı sürecin sahibi verir: örneğin bir destek asistanı için destek biriminin yöneticisi. Kırmızı çizgi vakalarını uyum ya da hukuk birimi onaylar. Asistanı geliştiren taraf sonuçları sunar, ama kendi işini onaylamaz.

NIST'in çerçevesi, değerlendirmeler için benzer bir ayrım tarif ediyor: “Sistemin ön saftaki geliştiricileri arasında yer almamış kurum içi uzmanlar ve/veya bağımsız değerlendiriciler, düzenli değerlendirmelere ve güncellemelere dahil edilir.” Çerçevenin Manage (yönetme) adlı bölümü de ardından yapay zekâ sistemine ilişkin bir kararla açılıyor: “geliştirilmesine ya da devreye alınmasına devam edilip edilmeyeceği.”

Bu karar için hazırlanan kanıt dosyası şunları göstermelidir:

• Setin nasıl oluşturulduğu, soru türü başına büyüklüğü ve yanıtları kimin yazdığı
• Test edilen sürümler: model, prompt, belgeler ve arama ayarları
• Önceden üzerinde anlaşılan geçme eşiklerine göre, soru türü ve hata türü başına sonuçlar
• Her kırmızı çizgi vakası ve sonucu
• Okunmuş ve açıklanmış her başarısızlık
• Ekibinizin aynı vakalardaki sonuçları
• Asistanın neleri ele almadığı ve lansmandan sonra haftalık örneklemi kimin incelediği

Onay kısmi olabilir. Asistan, testi geçen soru türlerinde canlıya çıkabilir; geri kalan türlerdeki sorular ise bu türler de geçene kadar bir kişiye yönlendirilir.

Test setinin sahibi kim?

Vakaların, beklenen yanıtların, kontrol listelerinin, betiklerin ve sonuç geçmişinin sahibi şirketiniz olmalıdır. Bunlar birlikte, iyi bir yanıtın sizin için yazılı tanımıdır. Sonradan gelen her modeli ya da tedarikçiyi aynı standarda göre değerlendirmenizi sağlarlar.

Bunları kontrol ettiğiniz bir depolama alanında tutun, çünkü tedarikçilerin araçları da kullanımdan kaldırılır. OpenAI'ın kullanımdan kaldırma sayfası, Evals platformunu kullanan geliştiricilere 3 Haziran 2026'da ürünün kullanımdan kaldırılacağını bildirdiğini söylüyor. Sayfa, mevcut eval'lerin salt okunur hâle geleceği tarih olarak 31 Ekim 2026'yı, panelin ve API'nin planlanan kapatılma tarihi olarak da 30 Kasım 2026'yı veriyor.

Sizin tarafınızda, vaka eklemeye ve politikalar değiştiğinde yanıtları güncellemeye zaman ayırabilecek bir set sorumlusu belirleyin.

Bir tedarikçiye ya da asistanı geliştirecek bir firmaya neler sormalıyız?

Bir tedarikçi bir doğruluk rakamı verdiğinde, bunun neyin üzerinde ölçüldüğünü sorun. NIST'in profili şunu öneriyor: “Model yeteneklerine ilişkin iddiaları ampirik olarak doğrulanmış yöntemlerle değerlendirin.” Ardından listenizdeki her tedarikçiye ya da firmaya şu soruları yöneltin:

• Beklenen yanıtları kendi çalışanlarımızın yazdığı vakalarımız üzerinde test yapacak mısınız?
• Test setinin hangi bölümünü son çalıştırmadan önce görmeyeceksiniz?
• Her soru türü ve hata türü için hangi geçme eşiklerini öneriyorsunuz ve neden?
• Serbest metni nasıl puanlıyorsunuz ve puanlayıcı modelinizi insanlarla karşılaştırarak nasıl kontrol ettiniz?
• Her değişiklikten sonra setin tamamını size ihtiyaç duymadan kendimiz yeniden çalıştırabilir miyiz?
• Model sağlayıcısı modeli kullanımdan kaldırdığında yeniden testin bedelini kim öder?
• Sonunda vakaları, kontrol listelerini, betikleri ve sonuç geçmişini teslim alacak mıyız?

amBrain nerede devreye girer?

Bu blogu amBrain yayımlıyor. amBrain kendi ürünü hakkında şöyle diyor: “Kendi ürünümüz shyash.ai, şirket bilgilerinin tek bir ortak belleğinden araştıran, yazan, kontrol eden ve ölçen yapay zekâ ajanları üzerinde çalışır. Yayınlanan her şeyi bir kişi onaylar.”

amBrain, müşterileri için bir dil modeliyle yaptığı çalışma hakkında şöyle diyor: “Bir müşterinin FinTech perimetresi içinde bir LLM entegrasyonunu üretime aldık: yapılandırılmamış broker ve işlem yeri bildirimlerinin — kurumsal işlemler (corporate actions), enstrüman ve teminat değişiklikleri — çıkarılıp normalize edilerek trading sisteminin tükettiği yapılandırılmış kayıtlara dönüştürülmesi.”

Bu yazı bir vaka çalışması değildir ve o satırın ötesinde hiçbir müşteri çalışmasını anlatmaz; o satır da projenin nasıl test edildiğini söylemez. Buradaki hiçbir şey, amBrain'in yukarıda anlatılan test setlerini, geçme eşiklerini ya da onay adımlarını oluşturduğunu iddia etmez ve shyash.ai'ın nasıl test edildiğini söylemez. Örnekler geneldir, amBrain'in çalışmalarından alınmamıştır.

Burada adı geçen kuruluşlar yayımlanmış sayfalarından alıntılanmıştır. Yazı, amBrain ile bunların herhangi biri arasında bir ilişki iddia etmez ve amBrain'e ait fiyat ya da takvim vermez.

amBrain 2019'dan bu yana yazılım geliştiriyor. Müşterileriyle nasıl çalıştığı konusunda şöyle diyor: “Üç format: tam teslim, özel ekip ya da sizin ekibinize yerleşen mühendisler.” Mülkiyet konusundaki satırı ise şöyle: “Müşteri, yeniden kullanılabilir bileşenlerimiz dışında ürünün ve kodun tam mülkiyetini elinde tutar.” İmzalamadan önce bu bileşenlerin adlarıyla listesini isteyin.

Bu yazı hukuki tavsiye de değildir. Gizlilik hukukunun müşteri verilerinden oluşturulan test setlerine nasıl uygulandığını avukatlarınıza sorun. amBrain kısa listenizdeyse, ona da diğer her firmaya sorduğunuz soruların aynısını sorun.