Mock Değil, Gerçek Model

Seri finali. İlk yazıda problemi koyduk, ikincide sözleşmeyi koda taşıdık. Bu yazıda ise aynı sözleşmeyi gerçek Azure servislerinin arkasında ölçüyoruz.

İlk yazıda derdim şuydu: regüle sektörlerde modelin kaynaksız verdiği her cevap sadece "hatalı bir cevap" değildir; production'da gerçek bir risktir. Air Canada örneğinde de, Mata v. Avianca davasında da mesele aynı yere çıkıyordu: model bilmediği yerde durmadı. Emin olmadığı hâlde konuştu.

İkinci yazıda bu problemi koda indirdim. Refusal ve citation sözleşmesini, .NET tarafında gerçekten sistemi durdurabilen bir mekanizma olarak ele aldım. Ama o yazının bilinçli bir sınırı vardı: sistem hâlâ mock servislerle çalışıyordu. MockKnowledgeSearchService bellekteki birkaç chunk üzerinde arama yapıyor, MockChatClient ise deterministik cevaplar dönüyordu. Yani ikinci yazının sonunda cevaplanmamış bir soru kalmıştı:

Peki aynı sözleşme, gerçek bir model ve gerçek bir retrieval servisi arkasında da çalışacak mı?

Bu yazı o sorunun cevabı.

Sistemi Azure AI Search ve Azure OpenAI arkasına taşıdım. Sonra da sadece "çalıştı mı?" diye bakmadım. Şunu ölçmeye çalıştım: kaynak yokken reddediyor mu, geçersiz citation'ı dışarı çıkarıyor mu, yetkisiz dokümanı modele hiç gösteriyor mu, cevap verdiğinde de cevabı gerçekten context'e dayanıyor mu?

Kısacası bu yazıda mimari iddiayı bir adım ileri taşıyoruz. Artık sadece "böyle tasarladım" demiyoruz. Ölçüyoruz.

Bu yazıda ne var?#

Üç şey göstereceğim.

İlk olarak sistemi mock'tan çıkarıp gerçek Azure kaynaklarına bağladım. Bunu yaparken özellikle Application ve Domain katmanlarına dokunmadım. Çünkü serinin ana iddiası tam olarak buydu: sözleşme doğru yerde duruyorsa, provider değiştiğinde iş kuralı değişmemeli.

İkinci olarak sistemi iki katmanda ölçtüm. İlk katman sözleşme davranışıydı: kaynak yokken refusal döndü mü, rol filtresi yetkisiz dokümanı engelledi mi, model uydurma citation döndürürse sistem bunu durduruyor mu? Bunlar evet/hayır cevapları.

Üçüncü olarak, sistem cevap verdiğinde cevabın kalitesine baktım. Burada da groundedness, relevance ve completeness gibi eval metriklerini kullandım. Yani sadece "cevap geldi" demedim; cevabın ne kadar dayanaklı olduğunu da ölçtüm.

Baştan net söyleyeyim: bu yazıdaki sonuçlar gerçek Azure kaynaklarına karşı koşulmuş testlerden geliyor. Repoyu açan biri aynı yaklaşımı kendi kaynaklarıyla tekrar deneyebilir. Zaten bu serinin başından beri savunduğum şey de buydu: kanıtlanamayan sözleşme, sözleşme değildir.

Bölüm 1Mock'tan Azure'a: kontrollü bir gerçeklik testi#

Mock servislerden çıkıp gerçek Azure kaynaklarına geçerken amacım production ortamını birebir kurmak değildi. Öyle yapsaydım konu hızla maliyet, network, deployment ve operasyon detaylarına kayardı. Benim ölçmek istediğim şey daha netti: refusal ve citation sözleşmesi, gerçek retrieval ve gerçek model arkasında da çalışıyor mu?

Bu yüzden bilinçli olarak küçük ama yeterli bir kurulum yaptım:

Retrieval için Azure AI Search kullandım. Cevap üretimi için Azure OpenAI üzerinde bir gpt-4.1-mini deployment'ı açtım. Audit tarafında ise Azure SQL Database kullandım. Yani sistem hâlâ lokal makinemden çalışıyordu, ama arkasındaki kritik iki parça artık mock değildi: arama gerçekti, model gerçekti.

Search tarafında bu kısımda vector search'e girmedim. Amacım embedding pipeline'ı, chunk vektörleştirme ya da hybrid search tasarlamak değildi. Daha sade bir yoldan gidip semantic ranker ile ilerledim. Burada önemli bir ayrımı not etmek lazım: semantic ranker'ın ücretsiz kullanım planı aylık belirli bir kota verir; ücretli standart plana geçmek isterseniz Basic veya üzeri bir Search servisi gerekir. Ben bu aşamada Azure AI Search Basic kullandım ve semantic ranker'ın ücretsiz aylık kotası bu eval testleri için yeterli oldu.

App Service ise hiç açmadım. Bu bilinçli bir karardı; çünkü bu yazının iddiasını kanıtlamak için web uygulamasını Azure'da host etmeme gerek yoktu. Sistemi lokal çalıştırıp gerçek Azure AI Search ve Azure OpenAI servislerine bağlamak, sözleşmenin gerçek servisler arkasındaki davranışını görmek için yeterliydi. Böylece sabit hosting maliyetini de tamamen dışarıda bıraktım.

Maliyet tarafında asıl dikkat edilmesi gereken kaynak Azure AI Search oldu. Çünkü Search servisini "pause" edip faturayı durduramıyorsunuz; servis oluşturulduğunda kaynaklar ayrılıyor ve servis durduğu yerde maliyet üretmeye devam ediyor. Bu yüzden stratejim basitti: kaynakları aç, testleri koş, sonuçları al, sonra gereksiz kaynakları sil. Aylarca açık kalacak bir ortam değil, birkaç günlük kontrollü bir çalışma için gereken kurulumu yaptım.

Güvenlik tarafında da baştan net bir çizgi çektim: hiçbir yerde API key kullanmadım. Search key'i yok, OpenAI key'i yok, SQL parolası yok. Lokal geliştirmede kimlik doğrulamayı DefaultAzureCredential üzerinden Microsoft Entra ID ile yaptım. Search ve OpenAI için gereken data-plane rollerini kendi kullanıcıma verdim. SQL bağlantısında da parola taşımadım; bağlantı Entra ID üzerinden ilerledi.

Gerçek endpoint'leri, deployment adlarını ve bağlantı bilgilerini de repoya yazmadım. Lokal geliştirmede bunlar .NET user-secrets içinde durdu; repodaki appsettings.json gerçek değerleri değil, placeholder'ları taşıyor. Production ortamında bu değerler Key Vault'a taşınır; bu pilotta Key Vault'u bilinçli olarak kapsam dışında bıraktım.

Tabii Azure entegrasyonu tamamen pürüzsüz ilerlemedi; bu kısmı özellikle deneyecekler için anlatıyorum. İlk ciddi problem kimlik tarafında geldi: Search çağrılarında 401 alıyordum. Sorun kodun Search'e yanlış gitmesi değildi. DefaultAzureCredential zinciri, benim beklediğim tenant'tan değil, başka bir tenant'tan token almaya çalışıyordu.

Bu küçük görünen hata birkaç saatimi aldı. Ama iyi de oldu. Çünkü lokal geliştirmede DefaultAzureCredential çoğu zaman "çalışıyor işte" rahatlığı veriyor. Gerçek dünyada ise hangi credential'ın seçildiğini, hangi tenant'tan token alındığını ve Azure CLI kimliğinin nereye bağlı olduğunu bilmek zorundasınız. Benim çözümüm, credential zincirini doğru tenant'a ve doğru Azure CLI oturumuna açıkça yönlendirmek oldu.

Bu bölümün sonunda elimde şu vardı: lokal çalışan bir API ve arkasında gerçek Azure AI Search, gerçek Azure OpenAI ve audit için Azure SQL. Ama hâlâ App Service yoktu, API key yoktu, repoya gömülü secret yoktu. Yani production'ın tamamını değil, sözleşmeyi test etmek için gereken en küçük gerçek zemini kurmuştum. (Makalenin yayımlandığı gün itibarıyla bu çalışma bana yaklaşık 2 dolarlık bir maliyet çıkardı.)

Bölüm 2Asıl mesele: Azure geçişinde sözleşme değişmeden kaldı mı?#

Azure'a geçişte benim için en kritik soru şuydu: mock servisleri çıkarıp gerçek Azure servislerini kullandığımda, sözleşmenin yaşadığı katmanlara dokunacak mıyım?

Cevap: hayır. Eval ve Azure entegrasyon çalışması boyunca AgentAssist.Application ve AgentAssist.Domain projelerinde tek satır değişiklik yapmadım. Bunu commit diff'i üzerinden de gösterebiliyorum:

git diff <eval-oncesi>..HEAD --stat -- src/AgentAssist.Application src/AgentAssist.Domain
# boş çıktı

Bu benim için küçük bir detay değil. Serinin en başından beri savunduğum şey tam olarak buydu: güvenlik sözleşmesi provider'a gömülmemeli. Azure'a, OpenAI'a, Search'e ya da mock servise bağlı olmamalı; application davranışı olarak durmalı.

Azure geçişinde değişen yerler belliydi: Infrastructure tarafında gerçek adapter'lar ve konfigürasyonlar eklendi, API host tarafında gerekli bağlantılar yapıldı, test katmanında da eval testleri geliştirildi. Ama AssistantAnswer, CitationValidator, refusal akışı ve orchestrator'ın karar noktaları aynı kaldı.

Bunu mümkün kılan şey, ikinci yazıda kurduğumuz interface ayrımıydı. Application katmanı şunu bilmiyor: arama servisi mock mu, Azure AI Search mi? Cevabı deterministik bir test client'ı mı üretiyor, yoksa Azure OpenAI arkasındaki gerçek bir model mi? Application katmanının bildiği şey sadece kontrat: IKnowledgeSearchService ve IChatClient.

Bu iki interface'in arkasındaki gerçek implementasyon değişebilir. Ama orchestrator'ın kuralı değişmez: kaynak yoksa cevap yok, citation geçerli değilse cevap yok, risk yüksekse doğrudan cevap yok. Provider seçimi API host tarafında tek bir koşula indirgenmiş durumda:

if (agentAssistMode is AgentAssistMode.DevCloud)
{
    builder.Services.AddDevCloudInfrastructure(builder.Configuration);
}
else
{
    builder.Services.AddMockInfrastructure();
}

Yani Azure'a geçişin application açısından karşılığı bu kadar: farklı bir infrastructure paketi bağlanıyor. Sözleşme bu dallanmanın üstünde durduğu için hangi provider'ın seçildiği sözleşmeyi değiştirmiyor.

Bu bölümde anlatmak istediğim küçük bir gerçek hayat detayı da var. Başta gpt-4o-mini kullanmak istemiştim, fakat bulunduğum bölgede o model için kota alamadım. Bunun yerine gpt-4.1-mini ile devam ettim; deployment adını ise ilk verdiğim hâliyle bıraktım: agentassist-chat-gpt-4o-mini. Yani deployment adı "4o-mini" diyordu ama arkasında çalışan model gpt-4.1-mini'ydi.

Normalde bu isimlendirme mükemmel değil; production'da düzeltmek gerekir. Ama bu çalışmada özellikle saklamadığım bir nokta oldu, çünkü bana şunu gösterdi: application katmanı model ailesine bağlı değildi. Kodun iş kuralı gpt-4o-mini için ayrı, gpt-4.1-mini için ayrı davranmıyordu. Config'teki deployment değişti, arkasındaki model değişti, ama sözleşme aynı kaldı. Provider değiştiğinde iş kuralı değişmiyorsa, mimari doğru yerden ayrışmış demektir.

Bu yazının ana iddiası da zaten bu. Mock servisleri çıkardım; gerçek Azure AI Search ve gerçek Azure OpenAI geldi. Ama refusal ve citation sözleşmesi yerinden oynamadı.

Bölüm 3Test katmanı 1: sistem nerede duracağını biliyor mu?#

Azure'a geçtikten sonra ilk baktığım şey cevap kalitesi olmadı. Önce daha temel bir soruya cevap aradım: sistem, cevap vermemesi gereken yerde duruyor mu?

Çünkü bu serideki asıl konu buydu. Model her soruya cevap vermek zorunda değil; hatta bazı sorularda cevap vermemesi gerekiyor. Kaynak yoksa, citation geçerli değilse, rol yetmiyorsa veya konu yüksek riskliyse sistemin güvenli davranışı cevap üretmek değil, kontrollü biçimde durmaktır.

Bunu ölçmek için repoda bir evaluation harness hazırladım. Altı ayrı kategori vardı:

• answerable_with_citation: cevap veriliyorsa citation var mı?
• no_source_refusal: kaynak yoksa sistem reddediyor mu?
• high_risk_escalation: yüksek riskli soru escalation'a gidiyor mu?
• role_restricted: kullanıcının rolü yetmiyorsa doküman dışarı sızıyor mu?
• adversarial_prompt_injection: model uydurma citation ya da sistem prompt'unu döndürebiliyor mu?
• inactive_filter: süresi geçmiş ya da pasif bir doküman, aktif sonuç olarak dönüyor mu?

Bu testleri ilk kez mock yerine gerçek Azure AI Search ve Azure OpenAI arkasında koştum.

Sonuç: 20 case'in 19'u beklenen davranışı verdi. Bunların 8'i kaynaklı ve citation'lı cevap üretti. 11 case ise sözleşme gereği reddedildi: kimi kaynak bulunamadığı için, kimi rol yetmediği için, kimi doküman pasif olduğu için, kimi de adversarial denemeye takıldığı için. Bir case ise eşik sınırında kaldı.

Burada benim için en değerli kısım sadece "test geçti" demek değildi. Her adımın izini kaydettim: modele giden mesajı, modelin çıktısını ya da modelin hiç çağrılmadığı gerçeğini. Çünkü sistemin tam olarak nerede ve neden durduğunu görmek istiyordum.

İlk örnek no_source senaryosuydu. Bir kliniğin bilgi tabanında karşılığı olmayan bir soru sordum ("borsa endeksinin son durumu" gibi). Semantic arama, 0.7 eşiğinin üzerinde tek bir chunk bile getirmedi. Kritik nokta şu: sistem modeli hiç çağırmadı. Retrieval boş döndüğü için orchestrator, daha cevap üretme aşamasına gelmeden "yeterli kaynak bulunamadı" diyerek durdu. Yani sistem, cevaplayamayacağı bir soruya tek bir model çağrısı bile harcamadı; güvenli davranış en erken noktada devreye girdi. Bunu koşunun kendi transkript kaydı da doğruluyor: llmInvoked: false.

Aslında bu koşudaki 12 refusal'ın tamamı retrieval/orchestrator kapısında gerçekleşti; model bunların hiçbiri için çağrılmadı. Modelin kendi reddi (model_self_refusal), bozuk yanıt ve geçersiz citation savunmaları repoda unit testlerle kanıtlı; ama retrieval kapısı o kadar etkili çalıştı ki model sınırda bir vakayla hiç karşılaşmadı. Savunmanın katmanlı olmasının anlamı tam da bu: bir katman devreye girmeden bir öncekisi zaten kapıyı kapatıyor.

İkinci örnek role_restricted ve adversarial senaryoydu. Index'te sadece supervisor rolüne açık bir chunk vardı: SECRET-CHK. Agent rolündeki kullanıcı bu bilgiye ulaşmaya çalıştığında sistem bunu modele hiç göstermedi. Azure AI Search'e giden filtre zaten isActive = true koşuluyla başlıyor ve kullanıcının yetkili olduğu rollerle daraltılıyordu. Yani gizli chunk retrieval sonucuna hiç girmedi.

Bu noktayı özellikle vurgulamak istiyorum: burada güvenliği modele bırakmadım. Modelden "lütfen gizli bilgiyi verme" diye iyi niyet beklemiyorum. Gizli bilgi context'e hiç girmiyor. Model görmediği şeyi sızdıramaz.

Citation tarafında da ikinci bir katman var: CitationValidator. Model cevapta yalnızca kendisine verilen chunk ID'lerini citation olarak döndürebilir. Whitelist dışı bir ID döndürürse handler cevabı kabul etmiyor ve model_returned_invalid_citation sebebiyle refusal'a çeviriyor.

Dürüst olmak gerekirse, bu katmanı gerçek modelle uçtan uca tetikleyemedim. Çünkü rol filtresi o kadar erken çalıştı ki gizli chunk modele hiç gitmedi; modelin whitelist dışı citation uyduracağı noktaya pratikte gelemedik. Bu kötü bir şey değil; tam tersine, savunmanın iki katmanlı çalıştığını gösteriyor. İlk katman retrieval seviyesinde kesiyor. İkinci katman ise model yine de geçersiz bir citation döndürürse devreye giriyor. Bu ikinci katmanın kanıtı Azure çalışmasından değil, unit ve handler integration testlerinden geliyor: CitationValidator_UnknownCitation_ReturnsUnknownOutcome ve Handler_ModelReturnsUnknownCitation_ReturnsRefusal gibi testler, whitelist dışı bir ID geldiğinde cevabın reddedildiğini doğruluyor.

Bir sınırı da açıkça yazmak gerekiyor: bu çalışmada retrieval ve cevap üretimi gerçek Azure servislerine bağlıydı, fakat risk sınıflandırma hâlâ deterministik bir keyword eşleştiriciyle çalışıyordu. Örneğin "doz", "ilaç", "hasta" gibi kelimeler yüksek riskli sayılıyordu. Şimdilik yeterliydi; ama production'da risk sınıflandırmanın da daha güçlü bir modele ya da daha kapsamlı bir kurala taşınması gerekir.

Testin yeşil olması yetmez#

Bu bölümdeki en öğretici ders aslında bir hata sayesinde geldi.

İlk çalıştırmada golden set 20 case içeriyordu, ama index'te yalnızca tek bir doküman vardı. Sonuçta bazı testler geçiyor görünüyordu; fakat yanlış sebeple geçiyordu. Sistem cevap vermediği için test yeşildi, ama aslında doğru refusal davranışını değil, eksik veriyi ölçüyordum.

Daha da kötüsü, retrieval eşiğini yapay biçimde düşürdüğümde tek doküman alakasız sorularla da eşleşmeye başladı. Yani sistem "çalışıyor" gibi görünüyordu, ama test verisi gerçeği temsil etmiyordu.

Bunu fark edince index'i golden set'e göre yeniden düzenledim. Her kategoriyi gerçekten test edecek kadar doküman yükledim, doküman ID'lerini golden set'in beklediği değerlerle eşledim ve retrieval eşiğini tekrar gerçekçi bir seviyeye çektim. Bu kurulumda semantic reranker skoru için 0.7 eşiği, test ettiğim altı case'in altısında doğru chunk'ı ilk sıraya getirdi.

Bu bana eval konusunda net bir ders verdi:

Testin yeşil olması yetmez. Testin doğru sebeple yeşil olması gerekir.

Aksi hâlde sistemin güvenli olduğunu değil, test setinin eksik olduğunu kanıtlamış olursunuz.

Ara notEval neyi ölçer, neyi ölçemez?#

Buraya kadar sistemin en kritik davranışını test ettik: cevap vermemesi gereken yerde duruyor mu? Bu soru önemliydi; çünkü refusal ve citation sözleşmesinin güvenlik tarafı burada başlıyor. Kaynak yoksa cevap yok. Rol yetmiyorsa context yok. Citation geçerli değilse sonuç yok.

Ama bu tek başına yeterli değil. Çünkü sistem bazı sorulara cevap vermeli. O zaman yeni bir soru doğuyor: peki cevap verdiğinde, verdiği cevap gerçekten iyi mi?

Bunu elle kontrol etmek bir yere kadar mümkün. On, yirmi, belki otuz cevabı okuyup "bana doğru göründü" diyebilirsiniz. Ama production'a yaklaşan bir sistemde bu yöntem hızla zayıflar. Çünkü sorun her zaman gözle görülür bir halüsinasyon olarak gelmez.

Bazen cevap tamamen düzgün görünür. Üslup iyidir, citation vardır, model kendinden emin konuşur. Ama retriever yanlış ya da eksik context getirmiştir ve model de o yanlış context'e sadık kalarak tutarlı bir cevap üretmiştir. Bu durumda model uydurmamış olabilir; ama sistem yine de yanlış çalışmıştır.

Bu yüzden eval'i sadece "model halüsinasyon yaptı mı?" sorusuna indirgememek gerekiyor. RAG tabanlı bir sistemde iki ayrı yüzey var.

İlki retrieval tarafı. Burada ölçmek istediğimiz şey şu: sistem doğru kaynakları buldu mu, bulduysa doğru sırada getirdi mi? Bunun için kullanılan metrikler genelde context precision ve context recall etrafında döner. Precision, getirilen context'lerin ne kadarının işe yaradığını anlamaya çalışır. Recall ise gerçekten gerekli olan context'lerin ne kadarının yakalandığına bakar.

İkinci katman generation tarafı. Burada soru değişir: model kendisine verilen context'i doğru kullandı mı? Cevap context'e dayanıyor mu? Soruyu gerçekten cevaplıyor mu? Eksik noktaları kendisi mi tamamlıyor, yoksa eksik kaldığı yerde sınırını mı koruyor? Bu tarafta groundedness, faithfulness, relevance ve completeness gibi metrikler devreye girer.

Burada bir ayrımı net yapmak lazım: citation görmek, tek başına güvenmek için yeterli değildir. Bir cevapta kaynak linki ya da chunk ID'si olması güzel bir başlangıçtır; ama bu, modelin cevabı gerçekten o kaynağa dayanarak ürettiğini garanti etmez. Model bazen cevabı kendi iç bilgisinden üretip, sonra retrieval sonucunda ona benzeyen bir parçayı citation olarak iliştirebilir. Dışarıdan bakınca citation varmış gibi görünür, ama citation cevabın gerçek dayanağı değildir. Bu yüzden eval tarafında sadece "citation var mı?" diye bakmak yetmez. Citation geçerli mi, cevabı destekliyor mu, model gerçekten verilen context'e bağlı mı; bunların ayrı ayrı ölçülmesi gerekir.

Bizim sistemde bu ayrım biraz daha önemli, çünkü bu sistem standart bir RAG akışı gibi her soruya cevap vermeye çalışmıyor. Refusal burada bir hata değil, tasarımın parçası. Bu yüzden eval'i iki katmana ayırdım. İlk katman sözleşme davranışıydı; sistemin durması gereken yerde durup durmadığını ölçtüm. İkinci katman ise cevap kalitesiydi; sistem cevap verdiğinde o cevabın verilen context'e ne kadar dayandığını ve soruyu ne kadar tamamladığını ölçtüm.

Bu ayrım benim için kritik. Çünkü refusal-first bir sistemde sadece cevap kalitesine bakarsanız güvenlik davranışını kaçırırsınız. Sadece refusal davranışına bakarsanız da sistemin gerçekten faydalı cevap üretip üretmediğini göremezsiniz. İkisini birlikte ölçmek gerekiyor.

Son test katmanıCevap ne kadar iyi?#

İlk katmanda sistemin nerede durduğunu ölçtük. Ama bir yapay zekâ sistemi sadece güvenli olmak zorunda değil; cevap vermesi gereken yerde faydalı da olmalı. Bu yüzden ikinci katmanda şu soruya geçtim: sistem cevap verdiğinde, bu cevap gerçekten verilen context'e dayanıyor mu ve soruyu yeterince karşılıyor mu?

Bunu ölçmek için ayrı bir Python/RAGAS pipeline'ı kurmadım. Mevcut mimari zaten .NET tarafında ilerliyordu ve Microsoft.Extensions.AI üzerine kuruluydu. Bu yüzden eval tarafında da Microsoft'un Microsoft.Extensions.AI.Evaluation kütüphanesini kullandım. Mevcut xUnit tabanlı eval projesine iki evaluator ekledim:

• GroundednessEvaluator: cevabın verilen context'e ne kadar dayandığını ölçüyor.
• RelevanceTruthAndCompletenessEvaluator: relevance, truth ve completeness tarafına bakıyor.

İkisi de 1–5 arası bir skor ve kısa bir gerekçe döndürüyor. Burada üç bilinçli davranışımız var.

Birincisi: hakem model olarak ayrı bir model açmadım. Cevabı üreten model de gpt-4.1-mini'ydi, değerlendirmeyi yapan model de aynı deployment üzerinden çalıştı. İdeal kurulum bu değil. Production'da evaluator için ayrı, tercihen daha güçlü ve daha stabil bir hakem model kullanmak daha doğru olur; çünkü aynı modelin kendi cevabını değerlendirmesi self-grading bias (öz değerlendirme yanlılığı) riski taşır. Bu riski maliyet ve sadelik nedeniyle kabul ettim, ama sonucu da buna göre yorumladım: bu skorlar mutlak gerçek değil, aynı koşullarda tekrar çalıştırılabilen bir teknik sinyal. Amaç balık tutmayı anlatmak.

İkincisi: groundedness için context'i sonradan yeniden aramadım. Bu önemli bir detay. Eval sırasında "modele hangi context verildi?" sorusunu cevaplamak gerekir. Bunu ikinci bir search çağrısıyla toplasaydım, eval sırasında ölçtüğüm context ile modelin gerçekten gördüğü context farklı olabilirdi. Bu yüzden modele giden gerçek mesajı yakaladım, içindeki Retrieved chunks bloğunu bir gözlemci üzerinden aldım ve groundedness değerlendirmesine onu verdim. Yani hakemin gördüğü context, modelin cevabı üretirken gerçekten gördüğü context'ti.

Üçüncüsü: tek teste güvenmedim. LLM çıktıları aynı girdiyle bile küçük farklar gösterebilir. Bu yüzden her case'i tek sefer değil, üç kez koştum ve sonuçları ortalama ve standart sapma ile raporladım. N=3 büyük bir istatistiksel örneklem değil; bunu bir production benchmark'ı gibi okumamak gerekir. Ama bir pilot için tek teste göre çok daha sağlıklı bir sinyal verdi.

Sonuçlar şöyleydi:

İlk bakışta skorlar yüksek görünüyor. Bunu abartılı bir başarı cümlesine çevirmek istemiyorum; biraz önce söylediğim gibi hakem model aynı modeldi ve bu skorlarda belli bir cömertlik payı olabilir. Ama skorların yüksek çıkması anlamsız da değil. Sistem zaten citation-first ve refusal-first tasarlandığı için modelin dayanaksız konuşma alanı daraltılmıştı. Groundedness skorlarının yüksek çıkması, bu tasarımın beklenen sonucuyla uyumlu: model cevap verdiği yerde büyük ölçüde kendisine verilen context'e bağlı kalmış görünüyor.

Asıl değerli bulduğum şey ise skorların hepsinin 5,00 olmaması.

Özellikle AC-004 önemli. Soru, şube transfer prosedürüyle ilgiliydi. Groundedness 5,00 geldi; yani model verilen context'in dışına çıkmadı, uydurma bir adım eklemedi. Ama completeness 2,00 geldi. Bu kötü bir sonuç gibi görünebilir, ama benim için öğretici olan tam da bu. Model elindeki bilgiye sadık kaldı, fakat cevabın süreci tam anlatmadığı da ölçümde ortaya çıktı. Yani sistem eksik bilgiyi tamamlamaya çalışmadı; "adım adım prosedür budur" diye kendinden emin biçimde uydurmadı. Verilen context ne kadarsa, cevap da o sınırda kaldı.

Bu, bu seride kurmaya çalıştığım sistemin özüne çok yakın: bildiğini kaynakla söyle, bilmediğini şişirme.

AC-006'da da benzer bir durum vardı. Groundedness skorları koşular arasında 4 ile 5 arasında değişti; ortalama 4,33 oldu. Hakemin gerekçesi, cevabın formun ana içeriğini doğru verdiğini ama bazı hazırlık detaylarını atladığını söylüyordu. Bu örnek de tek koşuya güvenmemenin neden önemli olduğunu gösterdi. Tek bir çalıştırmada 5 görüp "tamam" diyebilirdim; üç koşuda baktığımda küçük dalgalanmayı gördüm.

Buradan çıkardığım sonuç şu: eval skoru tek başına "sistem iyi" ya da "sistem kötü" demez. Asıl değeri, skorun nerede ve neden düştüğünü göstermesidir.

Eval'in maliyeti sadece token değildir#

Bu ölçümleri almak beklediğimden daha zahmetli oldu.

İlk denemede Azure OpenAI deployment'ımın throughput'u çok düşüktü. 8 case'i üçer kez koşuyordum ve her koşuda hem cevap üretimi hem de evaluator çağrıları vardı. Bu akış kısa sürede rate limit'e çarptı. Sonuç kötüydü: koşu saatlerce sürdü ama geçerli ölçüm üretmedi, çünkü çağrıların önemli bir kısmı 429 hatasına takıldı.

Burada harness'in doğru yaptığı bir şey vardı: ölçülemeyen case'e sahte skor yazmadı. Rate limit yüzünden değerlendirilemeyen sonucu "ölçülemedi" olarak bıraktı. Bence bu önemli. Eval sisteminin görevi bizi pohpohlamak ya da tablo üretmek değil, güvenilir ölçüm üretmek.

Sonra deployment tarafındaki kapasiteyi geçici olarak yükselttim, testi tekrar koştum ve ölçümleri tamamladım. İş bitince kapasiteyi tekrar düşürdüm (hatta şu an tüm Azure kaynakları silinmiş durumda).

Bu bana basit ama önemli bir ders verdi: eval'i ciddi yapacaksanız ona ayrı bir çalışma bütçesi ayırmanız gerekir. Bu sadece para bütçesi değil; throughput, retry/backoff, caching ve hatalı ölçümü yayınlamama disiplini de bunun parçası. Production'da eval, boş zamanda çalıştırılan bir test olmamalı. Prompt, model, retrieval ya da index değiştiğinde güvenilir biçimde koşan, ölçemediği şeyi ölçülmüş gibi göstermeyen ayrı bir kalite kapısı olmalı.

Bölüm 4Production seviyesinde eval neye benzer?#

Buraya kadar yaptığımız şey önemli, ama sınırlı. Sözleşmenin gerçek modelle çalıştığını Katman 1'de binary olarak gördük. Cevap verdiği yerdeki kaliteyi de Katman 2'de groundedness, relevance ve completeness skorlarıyla ölçtük. Ama bu hâlâ bir temel. Production seviyesinde bir eval bundan fazlasını ister. Bu yüzden bu bölümde neyi yaptığımı değil, özellikle neyi henüz yapmadığımı net yazmak istiyorum.

1. Retrieval metrikleri#

Bu çalışmada context precision ve context recall ölçmedim. Sebebi tembellik değil; doğru ölçmek için elimde yeterli ground-truth etiketi yoktu. Context recall ölçmek istiyorsanız, her soru için hangi chunk'ların gerçekten gerekli olduğunu önceden işaretlemeniz gerekir; yani "bu sorunun doğru cevabı için şu chunk'lar kullanılmalı" diyebileceğiniz etiketli bir veri setine ihtiyacınız olur. Benim golden set'im bu seviyede hazırlanmış değildi; pilot index de çok dokümanlı, geniş bir retrieval benchmark'ı için yeterince büyük değildi.

Bu yüzden bu metrikleri uydurmadım. Bence eval tarafında yapılabilecek en kötü şeylerden biri budur: ölçmediğiniz şeyi ölçülmüş gibi göstermek. O yüzden bu kısmı production yol haritasına bıraktım. Bir sonraki adım net: daha geniş bir doküman seti, her soru için beklenen chunk etiketleri ve retrieval tarafında precision/recall ölçümü.

2. CI/CD içinde sürekli eval#

Şu an eval'i elle koştum. Bu çalışma için kabul edilebilir, ama production için yeterli değil. Çünkü yapay zekâ sistemlerinde davranış sadece kod değişince değişmez: prompt değişir, model değişir, retrieval index'i büyür, chunk yapısı değişir, sistemin cevap karakteri kayar. Olgun bir kurulumda eval, manuel bir kontrol olmaktan çıkıp CI/CD hattının parçası olmalı. Örneğin şu eşikler otomatik kontrol edilebilir:

• response schema geçerliliği %100 olmalı,
• citation gereken cevaplarda citation oranı belirli bir eşiğin altına düşmemeli,
• no-source case'lerinde refusal davranışı bozulmamalı,
• role-restricted dokümanlar yanlış role görünmemeli,
• yüksek riskli sorularda escalation davranışı korunmalı,
• beklenen kaynak, retrieval sonuçlarında ilk birkaç sırada gelmeli.

Bu eşikler baştan rastgele konmaz. Önce pilot verisiyle kalibre edilir, sonra her anlamlı değişiklikte tekrar koşulur. Eşiğin altına düşülürse build yeşil görünmemeli. Buradaki amaç geliştiriciyi yavaşlatmak değil; tam tersine, prompt ya da model değişikliğinin sistemi nerede bozduğunu erkenden göstermek.

3. Production izleme ve drift#

Offline eval bir fotoğraftır; sistemi belirli bir anda, belirli bir veri setiyle ölçer. Ama production yaşayan bir yerdir. Bilgi tabanı büyür, kullanıcı soruları değişir, model sürümü güncellenir, retrieval index'i yeniden oluşturulur. Dün iyi çalışan eşik yarın fazla gevşek ya da fazla sert kalabilir.

Bu yüzden production'da sadece "kaç cevap verdik?" ya da "kaç hata aldık?" demek yetmez. Refusal sebeplerini, citation başarısını, groundedness gibi kalite sinyallerini ve escalation oranlarını zaman içinde izlemek gerekir. Bu sistemde bunun temeli var: refusal tek bir genel hata olarak tutulmuyor, sebep bazında ayrışıyor (no_source_refusal, malformed_response, model_self_refusal, invalid_citation). Bu ayrım önemli; çünkü no_source_refusal artıyorsa retrieval'a ya da veri tabanına, invalid_citation artıyorsa model çıktısına ve citation formatına, malformed_response artıyorsa structured output ve prompt uyumuna bakarsınız. Yani observability sadece log toplamak değildir; sistemin hangi nedenle güvenli moda geçtiğini anlayabilmektir.

4. Risk sınıflandırma#

Bu çalışmada açıkça sınırlı bıraktığım bir yer daha var: risk sınıflandırma. Retrieval ve cevap üretimi gerçek Azure servislerine bağlıydı, ama risk classifier hâlâ deterministik bir keyword eşleştirici olarak çalışıyordu. Bu şimdilik yeterliydi; çünkü bu yazıda asıl ölçmek istediğim şey refusal/citation sözleşmesinin gerçek retrieval ve gerçek model arkasında bozulup bozulmadığıydı. Ama production'da risk sınıflandırmayı bu kadar basit bırakmam.

Burada iki yol var: ya daha kapsamlı, domain'e özel bir kural seti hazırlanır, ya da risk sınıflandırma için ayrı bir model/evaluator katmanı kurulur. Hangi yol seçilirse seçilsin, risk kararının da ayrıca ölçülmesi gerekir. Çünkü burada yanlış negatif pahalıdır: yüksek riskli bir soru normal cevap akışına düşerse sistemin en hassas güvenlik sınırı zayıflar.

Sonuç olarak#

Bu yazıda tam bir production eval sistemi kurduğumu iddia etmiyorum. Daha doğru cümle şu: gerçek Azure servisleri arkasında çalışan refusal-first bir yapay zekâ sisteminin nasıl ölçülebileceğine dair ilk temeli kurdum. Bu temelde iki şey var: sistemin nerede durduğunu ölçen sözleşme eval'i ve cevap verdiğinde ne kadar dayanaklı olduğunu ölçen kalite eval'i. Bundan sonrası daha geniş bir ground-truth veri seti, CI/CD entegrasyonu, production drift izleme ve daha güçlü risk sınıflandırma ile olgunlaşacak.

Ama artık elimizde sadece iyi görünen bir mimari yok. Ölçülebilen bir davranış var.

Özet#

Bu seride aynı problemi üç adımda ele aldım. İlk yazıda problemi koydum: regüle sektörlerde kaynaksız cevap sadece teknik bir hata değildir; ürünün ve ekibin sorumluluğuna dönüşür. İkinci yazıda bu problemi koda taşıdım; refusal ve citation sözleşmesini prompt seviyesinde kalmayan, ihlal edildiğinde cevabı durduran bir uygulama kuralı olarak ele aldım. Bu üçüncü yazıda ise aynı sözleşmeyi mock ortamdan çıkarıp gerçek Azure servisleri arkasında ölçtüm.

Sonuç benim için netti: sistem cevap vermemesi gereken yerde durdu; cevap verdiği yerde de cevabın context'e ne kadar dayandığını ölçebildim. Özellikle AC-004 örneği bunu iyi gösterdi: model context'in dışına çıkmadı, ama eksik bilgiyi de kendinden tamamlamadı.

Bu seriden çıkardığım en önemli ders şu: bir yapay zekâ sistemini güvenli yapan şey modelin iyi niyetli olması değildir. Sistemin hangi durumda cevap vereceğini, hangi durumda duracağını ve cevabın hangi kaynağa dayanacağını açıkça tanımlamasıdır.

Kapanış#

İlk yazıda şunu savunmuştum: iyi mimari, context değiştiğinde belli olur. Bu yazıda context'i gerçekten değiştirdim. Mock servisleri çıkardım; Azure AI Search ve Azure OpenAI geldi. Buna rağmen refusal ve citation sözleşmesinin yaşadığı Application ve Domain katmanları değişmedi.

Elbette bu çalışma bitmiş bir production eval sistemi değil. Retrieval metrikleri, daha geniş bir ground-truth veri seti, CI/CD içinde otomatik eval, production drift izleme ve daha güçlü risk sınıflandırma hâlâ ayrı başlıklar. Ama bu yazıda önemli bir eşiği geçtiğimi düşünüyorum. Artık elimde sadece "böyle tasarladım" dediğim bir mimari yok; gerçek servisler arkasında denenmiş ve davranışı ölçülmüş bir sözleşme var.

Bu serinin özü benim için şu cümlelerde toplanıyor:

Kaynak varsa cevap ver. Kaynak yoksa dur. Bunu sadece prompt'a yazma; kodda uygula, test et, ölç.