Bir AI modelinden yanıt almak tek başına sistemin doğru çalıştığı anlamına gelmez. Klasik yazılımda çoğu zaman bir fonksiyonun beklenen sonucu döndürüp döndürmediğini açıkça kontrol edebiliriz. AI sistemlerinde ise yanıt akıcı, mantıklı ve ikna edici olabilir; buna rağmen hatalar içerebilir.
Bu yüzden AI'nın gelişimiyle birlikte yeni bir mühendislik sorunu ortaya çıkıyor: Yanıtları her zaman aynı olmayan bir sistemin kalitesi sistematik olarak nasıl ölçülür?
İşte bu, AI evaluation yani yapay zeka sistemlerinin değerlendirilmesi alanıdır.
Ve bu, bir chatbot’un “iyi cevap verip vermediğini” kontrol etmekten çok daha geniştir.
Klasik yazılım testi ile AI testi aynı şey değildir
Aplikasyonda basit bir fonksiyon hayal edelim.
Kullanıcı şunu yazar: 2 + 2
Sistem şunu döndürmelidir: 4
Eğer 5 döndürürse, açık bir hata vardır.
Şu testi hazırlayabiliriz: expect(calculate("2 + 2")).toBe(4)
ve her seferinde net bir sonuç alırız: test geçer ya da geçmez.
AI sistemlerinde durum farklıdır.
Kullanıcı şöyle sorabilir: “Siparişin teslim tarihi hakkında soran bir müşteri için kısa bir cevap yaz.”
Sistem birkaç farklı cevap üretebilir. Hepsi dil açısından doğru olabilir. Hepsi profesyonel duyulabilir. Ancak bunlardan biri yanlış bir tarih içerebilir, diğeri fazla uzun olabilir, üçüncüsü önemli bir bilgiyi atlayabilir, dördüncüsü ise kusursuz olabilir.
Bu yüzden yalnızca cevabın teknik olarak üretilip üretilmediğini kontrol etmek yeterli değildir.
Belirli kalite kriterlerini karşılayıp karşılamadığını kontrol etmek gerekir.
İlk problem: iyi cevap her zaman doğru değildir
Bu, üretken AI'nın en karakteristik özelliklerinden biridir.
Model, çok ikna edici görünen ama kaynak verilerde karşılığı olmayan bir yanıt üretebilir.
RAG kullanan bir sistemde sorun daha da ilginçtir. Sistem bir soru alabilir, belgelerden birkaç parça arayabilir ve ardından bir cevap üretebilir.
Bu durumda en az üç şeyi kontrol etmek gerekir:
- Doğru bilgiler bulundu mu? Arama mekanizması soruyla gerçekten ilgili parçaları mı getirdi?
- Cevap bulunan bilgileri kullanıyor mu? Model, kaynaklarda olmayan bir şeyi eklemiş olabilir mi?
- Cevap gerçekten soruyu yanıtlıyor mu? Çünkü retrieval doğru çalışsa bile son cevap kötü olabilir.
İşte bu yüzden RAG değerlendirmesi; getirilen bağlamın alakalılığı, aramanın kapsamlılığı, cevabın doğruluğu ve kaynaklarla uyumu gibi yönleri birbirinden ayırır.
Bu, test etmeye bakışta önemli bir değişimdir.
Artık yalnızca şunu test etmiyoruz: soru → cevap
ama tüm zinciri: soru → arama → bağlam → model → cevap
İyi bir modeliniz olabilir ama kötü bir AI sisteminiz de olabilir
Bu, kolayca unutulan bir başka noktadır.
Bir şirket çok iyi bir dil modeli seçip yine de zayıf bir AI ürünü ortaya çıkarabilir.
Neden? Çünkü son sistemin kalitesi yalnızca modele bağlı değildir.
Şunlar da önemlidir:
- veri kalitesi,
- bağlamın hazırlanma biçimi,
- prompt,
- bilgi arama yöntemi,
- model parametreleri,
- AI’ya sunulan araçlar,
- uygulama mantığı,
- hafıza,
- hata yönetim biçimi,
- güvenlik önlemleri,
- yanıtların değerlendirilme biçimi.
Bu, “Hangi model en iyisidir?” sorusunun
çoğu zaman “Hangi model bizim özel kullanım senaryomuzda en iyi sonuç veriyor?” sorusundan daha az faydalı olduğu anlamına gelir.
İçerik üretiminde harika olan bir model, doküman sınıflandırma, veri analizi veya iş süreçlerinin yönetimi için en iyi çözüm olmak zorunda değildir.
Bu yüzden modelleri karşılaştırmak, sistemin gerçekten yapacağı görevler üzerinde yapılmalıdır.
Önce kendi test setinizi oluşturmanız gerekir
Neyin beklendiğini bilmiyorsak, bir AI sistemini anlamlı biçimde değerlendiremeyiz.
Bu yüzden değerlendirmenin en önemli unsurlarından biri, test dataseti yani gerçek ya da temsili örneklerden oluşan bir set hazırlamaktır.
Örneğin bir şirket müşteri destek ekibi için AI geliştiriyor.
Promptta her değişiklikten sonra tek bir cevabı elle kontrol etmek yerine, birkaç yüz örnek hazırlanabilir:
- basit sorular,
- belirsiz sorular,
- hatalı varsayımlar içeren sorular,
- bir doküman aramayı gerektiren sorular,
- istisnalarla ilgili sorular,
- şikayetlerle ilgili sorular,
- reddetmeyi gerektiren sorular,
- AI’nın ifşa etmemesi gereken veriler içeren sorular.
Sistemdeki her değişiklik daha sonra aynı set üzerinde çalıştırılabilir.
Ve tam da burada AI, klasik yazılıma benzemeye başlar.
Artık tek bir cevabı test etmiyoruz. Sistemin tüm örnek seti üzerindeki davranışını test ediyoruz.
Prompt da test edilebilir
Prompt çoğu zaman biri tarafından bir kez yazılıp üretimde bırakılan bir metin gibi görülür.
Oysa gerçekte uygulamanın mantıksal bir parçası olabilir.
Tek bir cümleyi değiştirmek şunlara yol açabilir:
- bir senaryoda cevabın iyileşmesine,
- başka bir senaryoda cevabın kötüleşmesine,
- reddetmeye daha fazla eğilim oluşmasına,
- daha fazla halüsinasyona,
- daha uzun cevaplara,
- daha yüksek maliyete,
- daha fazla token tüketimine.
Bu yüzden prompt da koda benzer şekilde ele alınmalıdır.
Promptu değiştiriyorsak, şunu bilmek isteriz:
- neyin iyileştiğini?
- neyin kötüleştiğini?
- bir regresyon oluşup oluşmadığını?
Bu yüzden otomatik değerlendirme, birkaç örnek cevabı elle puanlamaktan giderek daha önemli hale geliyor.
AI testi geçebilir ve yine de kötü bir ürün olabilir
100 test vakası hazırladığımızı varsayalım.
Sistem 95'ine doğru cevap verdi. Sonuç harika görünüyor. Peki ya yanlış cevapların beşi kritik durumlarla ilgiliyse?
Chatbot açılış saatleri hakkında soruları yanıtlıyorsa, beş hata sorun olmayabilir.
AI, çalışanların finansal, tıbbi ya da hukuki belgeleri analiz etmesine yardımcı oluyorsa, bu hataların anlamı tamamen farklı olabilir.
Bu yüzden yalnızca ortalama yeterli değildir.
Ayrıca vaka ağırlıklandırmasına da ihtiyacımız vardır.
Şöyle kabul edebiliriz:
- sıradan bir sorunun ağırlığı 1,
- önemli bir hatanın ağırlığı 5,
- Bir güvenlik açığının ağırlığı 10’dur,
- gizli bir bilginin ifşa edilmesinin ağırlığı 100’dür.
O zaman sistem bize “%95” vermez. Riskin çok daha kullanışlı bir resmini elde ederiz.
Her şey tek bir sayıyla ölçülemez
Bu, AI değerlendirmesinin en önemli sorunlarından biridir.
Birkaç metriğimiz olabilir:
- Doğruluk (Accuracy) - yanıt doğru mu?
- İlgililik (Relevance) - soruya cevap veriyor mu?
- Sadakat / dayanaklılık (Faithfulness / groundedness) - sağlanan kaynaklara dayanıyor mu?
- Bağlam hassasiyeti (Context precision) - getirilen parçalar uygun mu?
- Bağlam geri çağırma (Context recall) - sistem gerekli bilgileri buldu mu?
- Güvenlik (Safety) - istenmeyen eylemler gerçekleştirmiyor mu?
- Gecikme (Latency) - kullanıcı ne kadar bekliyor?
- Maliyet (Cost) - görevi yerine getirmek ne kadara mal oluyor?
Dolayısıyla RAG, yanıt kalitesi çok iyi olabilir ama aynı zamanda çok büyük miktarda bağlam çekip kabul edilemez bir maliyet oluşturabilir.
Başka bir sistem çok ucuz ve hızlı olabilir, ama çok fazla hata yapabilir.
Bu yüzden AI’nin “iyi” olup olmadığını belirleyen tek ve evrensel bir sayı yoktur. Kalite, belirli kullanım bağlamında tanımlanmalıdır.
Peki ya AI’yi başka bir AI ile değerlendirmek?
Burada bir başka ilginç mekanizma ortaya çıkıyor.
Ewaluasyonu otomatikleştirmenin yollarından biri, modeli bir hakem olarak kullanmaktır; yani LLM-as-a-judge.
Örneğin:
Model A bir yanıt üretir.
Model B soru, yanıt ve belirli kriterleri alır.
Ardından şunları değerlendirir:
- doğruluk,
- talimata uygunluk,
- eksiksizlik,
- stil,
- güvenlik.
Modern değerlendirme araçları, bu tür bir değerlendirmeyi klasik metin karşılaştırmaları, kendi betikleri veya belirli kurallara dayalı derecelendiricilerle birleştirmeye de izin verir.
Bu, test ölçeğini büyük ölçüde artırır. Ama bu, insanın artık gerekli olmadığı anlamına gelmez. Değerlendirme modeli de hata yapabilir. Bu nedenle iş açısından daha kritik sistemlerde otomatik değerlendirmeleri dönemsel uzman değerlendirmesiyle birleştirmek gerekir.
En büyük sorun: regresyon
Çok iyi çalışan bir sistem hayal edelim. Ekip modeli daha yeni bir sürümle değiştirir. Yeni sürüm daha hızlı ve daha ucuzdur. Bu yüzden her şeyin doğru yönde gittiği görülür.
Ancak dağıtımdan sonra şunlar ortaya çıkar:
- yanıtlar daha az hassas olur,
- model daha sık yanıt vermeyi reddeder,
- dokümantasyonu daha kötü kullanır,
- talimatları farklı yorumlar,
- bazı senaryolarda yanlış bilgiler vermeye başlar.
İşte bu AI regresyonudur.
Klasik yazılımda regresyonu yıllardır biliyoruz. AI’de de bunu tespit etmemiz gerekir, ancak sorun daha zordur; çünkü sistemin davranışı klasik bir “hata” olmadan değişebilir. Bu yüzden her büyük değişiklik, önceki sürümle karşılaştırılmalıdır.
Model.
Prompt.
Embedding.
Retriever.
Dokümantasyon.
Ajan mantığı.
Parametreler.
Bu unsurların her biri sonucu etkileyebilir.
Bir ajanı yalnızca nihai yanıtına bakarak değerlendirmek yeterli değildir
AI ajanları söz konusu olduğunda iş daha da zorlaşır.
Klasik bir chatbot tek bir görev yapabilir: soru → cevap.
Bir ajan ise tamamen farklı çalışabilir: hedef → plan → araç → sonuç → sonraki adım → karar → eylem → cevap.
Eğer ajan hedefe ulaşamadıysa, sadece kaybettiğini bilmek istemeyiz.
Bilmek isteriz: Hata nerede yapıldı?
- Görevi yanlış mı anladı?
- Yanlış aracı mı seçti?
- Yanlış parametre mi iletti?
- Yanlış verileri mi çekti?
- Sonucu aldıktan sonra yanlış bir karar mı verdi?
- Çok fazla adım mı yaptı?
- Çok erken mi durdu?
Ajanların değerlendirilmesine yönelik araştırmalarda giderek daha fazla yalnızca nihai sonuç değil, aynı zamanda çalışma akışı, araç kullanımı, planlama, hafıza, güvenilirlik ve güvenlik de analiz edilir.
Bu, AI test etme geleceğinin büyük ölçüde trace’lerin, yani sistemin tam çalışma akışının analizine bağlı olacağı anlamına gelir.
AI, CI/CD’ye benzer bir şeye ihtiyaç duyar
AI bir ürünün parçasıysa, onu yalnızca ilk dağıtımdan önce test etmek yeterli değildir.
Sistem değişecektir.
Model değişecektir.
Prompt değişecektir.
Bilgi tabanı değişecektir.
Arama biçimi değişecektir.
Yapılandırma değişecektir.
Bu yüzden değerlendirme, geliştirme sürecine dahil edilmelidir.
Şema şu şekilde olabilir: değişiklik → testler → değerlendirme → önceki sürümle karşılaştırma → dağıtım kararı
Yeni sürüm bir alanda kaliteyi artırıyor ama başka bir alanda belirlenen hata eşiğini aşıyorsa, dağıtım durdurulabilir.
Bu, klasik CI/CD’ye çok benzer bir felsefedir, ancak kriterler farklıdır.
AI uygulamalarında aynı anda yanıt kalitesi, doğruluk, güvenlik, maliyet ve gecikme kontrol edilebilir. LLM/RAG sistemlerinin dağıtım sürecinde değerlendirmeyi observability ve kalite kapılarıyla birleştiren araştırma çözümleri de ortaya çıkmaktadır.
Peki AI, klasik yazılım ile aynı şekilde test edilebilir mi?
Evet, ama yalnızca kısmen.
Klasik yaklaşım hâlâ gereklidir.
Şunları test ederiz:
- API,
- entegrasyonlar,
- yetkiler,
- veri doğrulama,
- hatalar,
- zaman aşımı (timeout),
- güvenlik,
- performans,
- uygulama mantığı.
Ama bununla bitiremeyiz.
İkinci bir katman devreye girer: AI davranışının değerlendirilmesi.
- Yanıt doğru mu?
- Kaynaklarla uyumlu mu?
- Model talimatlara uyuyor mu?
- Sistem beklenmedik durumlarda doğru davranıyor mu?
- Ajan doğru araçları seçiyor mu?
- Yeni sürüm kaliteyi düşürmedi mi?
- Çalışma maliyeti kabul edilebilir düzeyde mi kalıyor?
- Kullanıcı gerçekten değer elde ediyor mu?
Bu artık klasik bir unit test değildir.
AI için en iyi test her zaman laboratuvar testi değildir
Bir önemli unsur daha var.
Sistem hazırlanmış bir test setinde çok iyi performans gösterebilir, ama yine de gerçek dünyada sorun yaşayabilir. Bu yüzden gerçek etkileşimleri de gözlemlemek gerekir. Her kullanıcı testçi olsun diye değil. Amaç, sistemi gerçek vakalara dayanarak sürekli iyileştirebilmektir:
- kullanıcıların AI’yi düzelttiği yerler,
- yanıtın yeniden denenmesini istedikleri yerler,
- sohbeti yarıda kestikleri yerler,
- konuyu bir insana eskale ettikleri yerler,
- ajanın hedefe ulaşamadığı yerler,
- alışılmadık soruların ortaya çıktığı yerler.
Bu şekilde sürekli bir değerlendirme döngüsü oluşur: kullanıcı → AI eylemi → sonuç → analiz → yeni test vakası → sistemin bir sonraki sürümü
Bu, bir kerelik “AI’yi devreye aldık ve çalışıyor” yaklaşımından tamamen farklı bir geliştirme modelidir.
AI şu soruyla değerlendirilmemelidir: “çalışıyor mu?”
Bu çok yetersiz.
Daha iyi sorular şunlardır:
- Ne sıklıkla doğru çalışıyor?
- Hangi durumlarda hata yapıyor?
- Bu hatalar ne kadar ciddi?
- Yeni sürüm önceki sürümden daha mı iyi?
- Sistem yeterince güvenli mi?
- Yanıtlar doğru verilere mi dayanıyor?
- Belirli bir sonuca ulaşmak ne kadara mal oluyor?
Ancak bu tür sorular dizisi, olgun bir AI sisteminden söz etmeyi mümkün kılar.
Düşünmede en önemli değişim
Yıllarca yazılım geliştirmede basit bir ilke geçerliydi: kod çalışmalıdır.
AI sistemlerinde bunu genişletmek gerekir: sistem iyi, öngörülebilir ve ölçülebilir biçimde çalışmalıdır.
Bu çok büyük bir farktır. Çünkü AI, her zaman aynı sonucu döndüren bir işlev değildir. Modele, verilere, bağlama, talimatlara ve çevresindeki tüm mimariye bağlı davranan olasılıksal bir sistemdir.
Bu yüzden profesyonel bir AI uygulaması, model cevap vermeye başladığı anda sona ermez.
Asıl soru o zaman başlar: ona güvenebileceğimizi nereden biliyoruz?
İşte iyi tasarlanmış bir değerlendirme tam da bu soruya yanıt vermelidir.
Gelecekte AI sistemlerinin test edilmesi, muhtemelen birim testleri, entegrasyon testleri ya da izleme kadar geliştirme sürecinin doğal bir parçası haline gelecek. Bunun nedeni AI’nin “tanım gereği tehlikeli” olması değildir. Basitçe, çıktısı her zaman deterministik olmayan bir sistemin, kaliteyi ölçmek için farklı bir yönteme ihtiyaç duymasıdır.
Ve AI metin üretiminden gerçek süreçleri yönetmeye, verileri kullanmaya, RAG’e ve ajanlar aracılığıyla eylemler gerçekleştirmeye doğru ilerledikçe, yalnızca “AI bunu yapabiliyor mu?” sorusu değil, aynı zamanda şu soru da daha önemli hale gelir: “Bunu yeterince iyi yaptığını kanıtlayabiliyor muyuz?”
