Model, istem, bilgi deposu, araçlar ve insan kontrolü tek bir hizmetin parçalarıdır. İnceleme sınırı yalnız model API’sinde biterse erişim yetkisi, güncel olmayan belge veya hatalı işlem gibi önemli riskler görünmez kalır.
tek model yanılgısı
Dışarıdan bakınca bir "chatbot" tek bir yapay zekâ gibi görünür: soru girer, cevap çıkar. Validasyon açısından bu görüntü tehlikeli bir yanılsamadır. Üretimdeki bir kurumsal AI sistemi, en az yedi-sekiz bileşenden oluşan bir boru hattıdır ve LLM bunlardan yalnızca biridir — çoğu zaman ilgili kurumunun hiç dokunmadığı, vendor'dan gelen biri.
Bu ayrımın validasyon sonucu netttir: "modeli validate ettik" cümlesi sistemi validate ettiğin anlamına gelmez. Cevabın kalitesi; hangi dokümanın getirildiğine (retrieval), dokümanın nasıl parçalandığına (chunking), sistem talimatının nasıl yazıldığına (prompt), çıktının hangi filtreden geçtiğine (guardrail) ve insanın gerçekten bakıp bakmadığına (oversight) aynı anda bağlıdır. Hata bu katmanların herhangi birinde doğabilir ve genellikle başka bir katmanın hatası gibi görünür.
Geleneksel paraleli düşün: IRB sermaye hesabında da tek "model" yoktur — PD modeli, LGD modeli, veri hazırlık katmanı, uygulama motoru (rating engine) ve raporlama vardır; validasyon her katmana ayrı bakar. AI sistemi de aynen böyle ele alınmalı. Yeni olan katmanların türü, katmanlı bakışın kendisi değil.
pipeline: her bileşene tıkla
Aşağıdaki diyagram, tipik bir banka içi RAG'li asistanın (ör. "mevzuat asistanı") anatomisini gösteriyor. Rozetler bileşenin türünü söylüyor: model (öğrenilmiş parametreler), konfigürasyon (insan eliyle yazılmış ayar), veri ve kontrol. Her bileşene tıkla.
banka içi rag'li asistan — anatomi
1
Kullanıcı girdisi
Soru, yüklenen doküman, konuşma geçmişi
veri
↓
2
Girdi guardrail'i
Konu filtresi, PII maskeleme, injection tespiti
kontrol
↓
3
System prompt & şablon
Rol, kurallar, ton, yasaklar — insan eliyle yazılmış talimat
konfig
↓
4
Retriever + vektör DB
Embedding, chunking, arama — soruya ilgili dokümanı getirir
veri
↓
5
LLM (foundation model)
Genellikle vendor'a ait; sıcaklık, top_p gibi çıkarım ayarlarıyla
model
↓
6
Tool'lar / API çağrıları
Hesaplama, CRM sorgusu, işlem başlatma — modelin "elleri"
kontrol
↓
7
Çıktı guardrail'i
Politika filtresi, groundedness kontrolü, format doğrulama
kontrol
↓
8
İnsan gözetimi
Onay katmanı, örneklem incelemesi, kullanıcı geri bildirimi
kontrol
Validasyon lensi: Scope belirlerken bu diyagramı masaya koy. "Validasyonun kapsamı nedir?" sorusunun cevabı bileşen listesidir: hangi katmanlar test edilecek, hangileri vendor güvencesine bırakılacak, hangileri kapsam dışı ve neden. Kapsam dışı bırakılan her katman, raporda gerekçesiyle yazılmalı — sessiz kapsam daraltma, en sık validasyon bulgusudur.
kırılma simülasyonu: hata nerede doğar, nerede görünür?
AI sistemlerinde teşhisin zorluğu şurada: hata doğduğu yerde değil, göründüğü yerde raporlanır. Kullanıcının gördüğü hep aynı şeydir — "kötü cevap". Aşağıda bir bileşeni boz; belirtinin ne olacağını ve hangi katmanların etkileneceğini izle.
Kritik çıkarım: kullanıcı şikâyeti "model saçmalıyor" diye gelir; kök neden çoğu zaman modelde değildir. Kök neden analizi yapılmadan "modeli değiştirelim" kararı almak, hem pahalı hem de sorunu taşımaktır. Validasyon raporun bileşen bazında konuşmalı: retrieval recall'ü düşük, prompt talimatı belirsiz, guardrail kapsamı dar — "sistem kötü" değil.
değişiklik yüzeyi: model değişmeden sistem değişir
Geleneksel change management "model versiyonu değişti mi?" sorusuna bakar. AI sistemlerinde davranışı değiştiren şeylerin çoğu model versiyonunu hiç değiştirmez. Aşağıdaki değişikliklere tıkla; her biri için üç soruya bak: model versiyonu değişti mi, sistem davranışı değişti mi, geleneksel change management bunu yakalar mı?
System prompt'a bir cümle eklendi
Sıcaklık 0.7'den 0.2'ye düşürüldü
Doküman tabanına 500 yeni sayfa yüklendi
Vendor, temel modeli sessizce güncelledi
Embedding modeli değiştirildi
Sonuç: AI sistemleri için değişiklik yönetimi "model versiyonu" değil "davranışı etkileyen her şey" üzerinden tanımlanmalı. Pratik araç: her değişiklik sınıfı için önceden tanımlı bir regression test seti (golden dataset) koş, sonucu değişiklik kaydına iliştir. Hangi değişikliğin yeniden validasyon tetiklediğini politika söylemeli — geliştiricinin insafı değil.
Sistem sınırı
Model, istem, bilgi deposu, araçlar ve insan kontrolü tek bir hizmetin parçalarıdır. İnceleme sınırı yalnız model API’sinde biterse erişim yetkisi, güncel olmayan belge veya hatalı işlem gibi önemli riskler görünmez kalır.
Sürüm kaydı bu bileşenleri birlikte izlemelidir. Bir bileşendeki değişiklik için yeniden test kapsamı, etkilenen davranış ve zarar yollarından türetilir.
anahtar çıkarımlar
sistem ≠ model
Üretimdeki AI, bileşenlerden oluşan bir pipeline'dır; LLM tek bileşendir ve çoğu zaman kurumun kontrolünde bile değildir. "Modeli validate ettik" cümlesi sistemi validate ettiğin anlamına gelmez.
hata doğduğu yerde değil, göründüğü yerde raporlanır
Kullanıcı hep "kötü cevap" görür; kök neden retrieval'da, prompt'ta, guardrail'de veya vendor güncellemesinde olabilir. Bileşen bazlı teşhis olmadan bulgu yazılamaz.
davranışı değiştiren çoğu şey model versiyonunu değiştirmez
Prompt, sıcaklık, doküman tabanı, embedding, vendor güncellemesi — hepsi davranışı oynatır. Change management "model versiyonu" değil "davranış etkisi" üzerinden kurulmalı; regression test seti bunun aracıdır.
her bileşenin sahibi olmalı
Sahipsiz bileşen denetimsiz değişiklik demektir. Bileşen-sahip matrisi, AI governance'ın en ucuz ve en etkili araçlarından biridir.
Uygulama örneği · kurgusal vaka
karar masası: Sessiz vendor güncellemesi
Senaryo: Vendor temel modeli ve embedding servisini hafta sonu güncelledi. İş birimi “arayüz aynı” diyerek devam etmek istiyor; RAG ve prompt değişmemiş, eski koşumlarla karşılaştırma yapılmamış.
Örnek değerlendirmeyi aç
DeğerlendirmeDeğişikliği maddi sistem değişikliği adayı say; kritik kullanımda hedefli regresyon bitmeden eski onayın otomatik sürdüğünü varsayma. Gerekirse kapsamı geçici daralt.
Gerekli kanıtEski/yeni sürümler; vendor değişiklik notu; veri/indeks tarihi; sabit golden set karşılaştırması; kritik ve güvenlik regresyonu; log/rollback; sözleşme hakları.
Karar kaydıDeğişiklik sınıflandırma kaydı + hedefli revalidation planı: etkilenen bileşen, test, eşik, geçici kontrol, karar sahibi ve geri dönüş kriteri.