YZ riskleri proje riskleridir

En görünür YZ hatası çoğu zaman en tehlikeli hata değildir.

Uydurulmuş bir kaynak, var olmayan bir mahkeme kararı ya da açıkça yanlış bir sayı dikkatli bir incelemeyle fark edilebilir. Asıl zor olan; yüzde 95 oranında makul görünen, fakat küçük bir noktada yanlış varsayım kullanan, bir kavramı karıştıran, ara adımı atlayan ya da güncelliğini kaybetmiş bilgiyi doğru bir bağlama o kadar ikna edici biçimde yerleştiren bir çıktıdır ki hata görünmeden yoluna devam eder.

İşte bu noktada model hatası bir proje riskine dönüşür.

Profesyonel kalite kontrolü yalnızca “YZ halüsinasyon görüyor mu?” diye sormaz. Bu projede hangi hata sınıflarının kritik olduğunu, hataların nasıl yayılabileceğini, hangi kontrollerin onları erken yakaladığını ve projenin gerçekte ne kadar doğrulama kapasitesi olduğunu sorar.

Halüsinasyon yalnızca bir hata sınıfıdır

“Halüsinasyon” popüler ve kullanışlı bir kavramdır, ancak proje yönetimi için fazla geneldir. Dikkati uydurulmuş gerçeklere yöneltirken, gerçek operasyonel kalite sorunlarının önemli bir bölümü farklı görünür.

Profesyonel bir risk kataloğu en az şu ayrımları yapmalıdır:

Böylece soru “Model iyi mi?” olmaktan çıkar ve şuna dönüşür: Bu workflow hangi hataları kesinlikle dışarı bırakmamalı?

En tehlikeli hata çoğu zaman makul görünür

Açık halüsinasyonların bir avantajı vardır: şüphe uyandırabilirler.

İnce hatalarda bu avantaj yoktur. Dil, ton, format ve argüman yapısına kusursuz uyum sağlarlar. Bir model on doğru olguyu verip yanlış öncelik çıkarabilir. Doğru düzenlemeyi kullanıp yanlış kurumsal role uygulayabilir. Çalışan kod üretebilir ama bir edge case’i yanlış ele alabilir. Pazar analizinde tüm kaynakları doğru gösterip korelasyonla nedenselliği karıştırabilir.

Yüzey ne kadar profesyonel görünürse güven etkisi o kadar tehlikeli olabilir.

Bu nedenle kalite kontrolü yalnızca bariz yanlışları değil, makul görünen ifadenin karar etkisi yarattığı noktaları aramalıdır.

Önemli kaynak düzeltmesi: “Lloyd” değil Deloitte

Temel proje materyalinde Avustralya’daki danışmanlık vakası “Lloyd skandalı” olarak adlandırılıyor. Güvenilir şekilde doğrulanabilen kamuya açık vaka ise Avustralya Department of Employment and Workplace Relations için hazırlanan Deloitte Australia raporudur.

Raporda var olmayan akademik referanslar ve bir mahkeme kararına atfedilen hatalı bir alıntı bulundu. Deloitte düzeltilmiş sürüm yayımladı ve ücretin bir bölümünü iade etti.^[5]

Bu makale açısından marka isminden daha önemli olan kontrol hatasıdır:

Profesyonel görünen bir deliverable, kritik iddialar primary source’larla yeterince doğrulanmadan müşteriye ulaştı.

Bu yalnızca bir dil modeli sorunu değil, proje yönetimi sorunudur.

Kalite risk kaydına girmelidir

Klasik projeler zaman, bütçe, tedarikçi, kaynak, scope ve bağımlılıkları risk olarak ele alır.

YZ projelerine ayrıca şu kalite riskleri eklenir:

Yanlış olgular, kanıtsız iddialar, tutarsız sürümler, görülmeyen edge case’ler, hatalı tool call’lar, eksik review’lar, model veya provider değişimi, kararsız çıktılar, context loss, hatalı evaluasyonlar — ve insan doğrulama kapasitesinin darboğaz olması.

Bunlar dipnotta kalmamalıdır. Her biri için owner, olasılık, etki, detection mekanizması ve response tanımlanmalıdır.

Surface Correctness, Semantic Correctness değildir

Bir çıktı biçimsel olarak kusursuz görünüp içerik olarak yanlış olabilir.

Bu nedenle iki kalite boyutu ayrılmalıdır.

Surface Correctness

Format doğru. Tablolar eksiksiz. Kaynaklar sentaktik olarak mevcut. Kod derleniyor. Dil profesyonel. Schema korunuyor.

Semantic Correctness

İfade gerçekten doğru. Kaynak claim’i gerçekten taşıyor. Sonuç evidenstan mantıksal olarak çıkıyor. Raporlanan süreç durumu gerçek sistem durumuyla aynı. Edge case’ler yeterince değerlendirilmiş. Karar gerçek bağlam için geçerli.

Otomasyon surface correctness konusunda çoğu zaman güçlüdür. Profesyonel kalite, semantic correctness da kontrol edildiğinde başlar.

Claim en küçük doğrulanabilir birimdir

Uzun YZ dokümanları sıkça bütün halinde incelenir: “iyi görünüyor”, “mantıklı”, “kaynakları var”.

Kritik içerikte bu yaklaşım fazla kabadır.

Daha iyi yaklaşım claim-level verification yöntemidir. Karar etkisi olan claim bir nesne olarak ele alınır:

Tam olarak ne iddia ediliyor? İddia açıklayıcı mı, nedensel mi, normatif mi, tahmin mi? Hangi evidence bunu desteklemeli? Kaynak tam olarak bu ifadeyi destekliyor mu? Kaynak yeterince güncel ve yetkili mi? Hangi belirsizlik kalıyor? Hangi proje kararı buna bağlı?

Böylece “kaynak kontrolü” tekrarlanabilir bir kalite sürecine dönüşür.

Her ifade aynı doğrulama derinliğine ihtiyaç duymaz

Her cümleyi tamamen doğrulamak büyük projeleri ekonomik olarak imkânsız hale getirebilir.

Bu nedenle kalite için claim risk sınıflandırması gerekir.

Soru “Ne kadar kontrol edeceğiz?” değil, kıt doğrulama kapasitesini nereye yatıracağız? olmalıdır.

Review-budget hatası

Sık görülen proje hatalarından biri YZ çıktısını büyütürken insan review kapasitesini büyütmemektir.

Bir sistem dakikalar içinde 50 sayfa oluşturduğunda 50 sayfalık bitmiş sonuç üretmiş olmaz. Önce 50 sayfalık doğrulama işi üretmiş olur.

Burada Verification Fatigue başlar:

Reviewer yalnızca başlıkları okur. Uzun doğru bölümler dikkati düşürür. Makul dil rutin güven yaratır. Zaman baskısı örneklemi küçültür. Zor claim’ler kolay claim’lerden daha hızlı geçilir. “Reviewed” gerçek inceleme yerine durum etiketi olur.

Böylece Human-in-the-Loop biçimsel olarak mevcut ama operasyonel olarak etkisiz olabilir.

Verification Capacity bir proje kaynağıdır

Bütçe, GPU süresi ve token yanında YZ projeleri Verification Capacity de planlamalıdır.

Bu kapasite şunlardan oluşur:

Uzman zamanı, uygun otomatik kontroller, bağımsız model review, test verisi, referans kaynaklar, tekrarlanabilir eval’ler ve tartışmalı vakalar için zaman.

100 birim çıktı üretebilen ama yalnızca 10 birimi gerçekten doğrulayabilen ekip 100 birimlik bir sisteme sahip değildir. 90 birimlik kalite açığına sahiptir.

Verification Debt

Çıktı doğrulamadan hızlı üretildiğinde Verification Debt birikir.

Tipik belirtiler:

Kaynaksız açık claim’ler, kontrol edilmemiş agent çıktıları, yeni model sürümü için eski eval kullanımı, büyüyen review queue, kısmen incelenmiş raporlar, “sonra kontrol ederiz” notları, belirsiz onaylar.

Verification Debt tehlikelidir çünkü çoğu zaman hemen patlamaz. Sessizce sonraki proje aşamasının girdisine dönüşür.

Hata yayılımı: küçük hata proje durumuna dönüşür

Agentic workflow’larda erken bir hata birçok kez büyütülebilir.

Örnek:

Research agent yanlış pazar rakamı alır. Planning agent bunu bütçe varsayımı yapar. Risk agent business case’i bu temelde değerlendirir. Presentation agent sayıyı ikna edici biçimde görselleştirir. Reviewer kaynağı değil sunumu kontrol eder. Karar onaylanır.

İlk hata artık belirsiz bir ifade gibi görünmez. Konsolide proje durumuna dönüşmüştür.

Bu nedenle kritik bilgiye kalite kontrolü mümkün olduğunca üretim noktasına yakın uygulanmalıdır.

Error Propagation Graph

Karmaşık projelerde basit bağımlılık haritası yararlıdır:

Source → Claim → Assumption → Decision → Artifact → Action

Downstream etkisi yüksek claim, izole bir yan nottan daha derin kontrol edilmelidir.

Bu çoğu zaman “her şeyi iki kez kontrol et” yaklaşımından daha verimlidir.

Cross-model kontrol yararlıdır — ama ground truth değildir

İkinci model hata bulabilir, blindspot gösterebilir veya alternatif argüman üretebilir. Üçüncü model anlaşmazlığı görünür yapabilir.

Fakat model konsensüsü doğruluk kanıtı değildir.

Birden fazla model:

Aynı popüler yanlış bilgiyi öğrenmiş olabilir, aynı zayıf kaynağa dayanabilir, aynı muğlak görevi yanlış yorumlayabilir veya ilk gösterilen çıktıya anchor olabilir.

Cross-model triangulation bir disagreement detector’dır; truth oracle değildir.

Reviewer yeterince bağımsız olmalıdır

Generator ile tamamen aynı context, varsayım ve reasoning’i alan reviewer’ın bağımsızlığı sınırlıdır.

Göreve göre daha güçlü reviewer şunları alabilir:

Orijinal görev, değerlendirme kriterleri, primary source’lar, gerekirse çıktı — ancak generator’ın tüm reasoning yolunu değil.

Bu anchoring’i azaltır ve gerçek karşı kontrol üretir.

Generator ve reviewer farklı hedeflere sahip olmalıdır

Generator üretmeye optimize olur.

Reviewer hata bulmaya optimize olur.

Bu mimari fark önemlidir. Aynı prompt önce “ikna edici tavsiye oluştur” sonra “kendi tavsiyeni eleştir” diyorsa model genellikle kendi trajectory’sinde kalır.

Güçlü reviewer’ın misyonu farklıdır:

Onaylamak yerine falsify etmek. Karşı örnek aramak. Eksik evidence işaretlemek. Edge case üretmek. Gerekliyse belirsizliği yükseltmek. On stil iyileştirmesinden önce bir kritik hata bulmak.

Üç grader türü

Modern eval mimarileri genellikle birden fazla grader türünü birlikte kullanır.

1. Deterministic grader’lar

Unit test, schema check, regex ve string check, database state, hesap kontrolü, static analysis.

Hızlı ve tekrarlanabilirler; fakat yalnızca kriterlerin makineye açık biçimde tanımlanabildiği yerde güçlüdürler.

2. Model-based grader’lar

Coherence, coverage, groundedness, tone, rubric veya açık uçlu kalite kriterlerini değerlendirebilirler.

Zayıflıkları: reviewer’ın kendisi de probabilistic modeldir.

3. İnsan / alan grader’ları

Normatif, domain-specific ve yüksek etkili sorularda vazgeçilmezdir; ancak daha yavaş ve pahalıdır.

Olgun kalite sistemi üçünü birleştirir; tek grader’ı “gerçek” ilan etmez.

Outcome, self-report’tan daha güçlüdür

Agent “dosya kaydedildi”, “rezervasyon yapıldı” veya “test geçti” diyebilir.

Bu yalnızca metin çıktısıdır.

Mümkün olduğunda kalite gerçek son durumdan kontrol edilmelidir:

Dosya gerçekten var mı? Database kaydı oluşmuş mu? Sipariş gerçekten açılmış mı? Kod testleri geçiyor mu? Doğru dataset değiştirilmiş mi?

Gerçek sistem durumu agent’ın kendi durum açıklamasından çoğu zaman daha güçlü kanıttır.

Yürütme izi ve outcome farklı şeyleri test eder

Outcome sorar: Çalıştı mı?

Trace sorar: Nasıl gerçekleşti?

İkisi de önemli olabilir.

Agent doğru sonuca yasak bir yoldan ulaşabilir. Ya da doğru süreç izleyip dış servis kesintisi nedeniyle başarısız olabilir.

Bu nedenle kritik eval’ler process quality ile outcome quality ayrımını yapmalıdır.

Non-determinism birden fazla trial gerektirir

Stokastik sistemde tek başarılı run çok az şey kanıtlar.

Aynı görev beş kez çalıştırılıp yalnızca üçünde başarılı oluyorsa “çalıştı” yeterli kalite ifadesi değildir.

Önemli workflow’lar birden fazla trial, seed veya scenario gerektirir.

İki soru farklıdır:

Sistem görevi en az bir kez çözebiliyor mu?

Sistem görevi güvenilir şekilde tekrar tekrar çözebiliyor mu?

Yaratıcı keşifte birincisi yeterli olabilir. Müşteri süreçlerinde ikincisi çoğu zaman belirleyicidir.

Capability eval ve regression eval

Bu iki eval türü farklı işlev görür.

Capability eval: Sistem artık hangi zor görevleri çözebiliyor?

Regression eval: Dün çalışan şeyler hâlâ çalışıyor mu?

Yeni model, prompt update veya tool bir benchmark’ı iyileştirirken eski workflow’u bozabilir.

Bu nedenle regression test her önemli change sürecinin parçası olmalıdır.

Gerçek hatalar test case’e dönüşmelidir

En değerli eval dataset’i çoğu zaman teorik sorulardan değil gerçek proje hatalarından gelir.

Her önemli incident regression case olabilir:

Hatayı dokümante et. Minimal reproducible input’u sakla. Beklenen davranışı tanımla. Failure mode’u işaretle. Grader oluştur. Case’i suite’e ekle. Model, prompt veya tool değişiminde tekrar çalıştır.

Böylece proje geçmişi kalite altyapısına dönüşür.

Groundedness “yanında kaynak var” demek değildir

Bir claim’in ardından link gelmesi onu grounded yapmaz.

Sağlam groundedness kontrolü şunları sorar:

Kaynak gerçek mi? Primary source mu yoksa yalnızca başka bir kaynağı mı tekrar ediyor? İddia edilen bilgi gerçekten kaynakta var mı? Sonuç metinden gerçekten çıkarılabilir mi? Zaman veya coğrafya bağlamı kaybolmuş mu? Daha güçlü kaynak çelişiyor mu? Kaynak güncel sürüm için hâlâ geçerli mi?