İnsan denetimi, onay adımının akışın neresinde duracağını ve modelin neye karar veremeyeceğini sistem kurulurken belirleyen bir kuruluş kararıdır. Karar akışın biçiminde verilir: hangi olayın neyi tetikleyeceği ve çıktının kullanıcıya hangi yoldan ulaşacağı model seçilmeden önce çizilir. Tahlil.com’da onay ekranı hekimin yorumu yazdığı ekranın kendisi; hastaya ulaşan metnin son hâli bu adımda hekimin elinden çıkıyor.
Model çıktı üretir, sorumluluk kimde kalır
Bir dil modelinin ürettiği metin, arkasında duran bir kişi olmadığı sürece kimsenin sözü değildir. Kullanıcı o metni okur, ona göre davranır ve bir şey ters gittiğinde cevabı verecek birini arar. Bu soruya sistem kurulurken cevap verilmezse ürün yayına girdikten sonra da verilemez, çünkü sorumluluk bir niyet değil, akışın içinde belirli bir adıma bağlanan bir bağdır.
Modelin yorum taslağı ürettiği ve son sözün hekimde kaldığı hekim denetimli platformda cevap ilk günden belliydi. Şartın nerede yazılı olduğu önemli: “AI ön okuma yaparken hastaya giden metnin son sözü hekimde kalmalı” cümlesi projenin çözülecek zorluklar listesinde duruyor. Yani sistem henüz kurulmamışken, çözülmesi gereken problemin bir parçası olarak konmuş.
Bir şartın hangi listede durduğu, o şartın sisteme ne kadar işleyeceğini belirliyor. Çözülecek zorluklar listesindeki bir madde mimarinin biçimini değiştirme yetkisine sahiptir: hangi ekranın hangi ekrandan sonra geleceğini, hangi olayın neyi tetikleyeceğini o madde belirler. Yayına girmiş bir ürüne sonradan gelen aynı cümle ise mevcut akışın kenarına yerleşir ve çoğunlukla bir uyarı metnine dönüşür.
Sonuç tarafında bağ kapanıyor: hastaya ulaşan her yorumun sorumluluğu onu onaylayan hekimde kalıyor. Sorumluluk modele ya da yazılıma dağılmıyor, tek bir kişide toplanıyor. Bunu söyleyebilmek ancak sistemde o kişinin gerçekten geçtiği bir adım varsa mümkün. Adım yoksa cümle bir temenni olur.
Denetimi sonradan takılan bir filtre olarak kurmak da mümkündü: model üretsin, çıktı yayımlansın, hekim de arkadan baksın. O kurgu daha az iş çıkarır ve daha erken yayına girer. Karşılığında sorumluluk zinciri açık kalır — hasta metni okumuşken hekim henüz bakmamıştır ve o aralıkta metnin sahibi yoktur.
Ön okuma ile son söz aynı şey değildir
Modelin ürettiği şeye ne ad verdiğimiz, sistemin nasıl davranacağını belirliyor. Tahlil.com’da model bir ön okuma hazırlıyor. Bu metin taslak statüsünde duruyor; karar statüsüne bir kişinin onayıyla geçiyor. İki statü arasındaki fark metnin kalitesinde değil, arkasında kimin durduğunda.
Hekim yorumu panelde yazıp onaylıyor. Buradaki asıl ayrıntı onayın nerede yapıldığı: onay ayrı bir araçta değil, yazma yüzeyinin kendisinde. Hekim ön okumayı düzenlediği ekranda onaylıyor; düzenleme ile onay aynı yüzeyde duruyor. Bu yüzden hekim taslağı görmeden onaylayamıyor — onay, yazdığı ekranın bir adımı.
Onay ayrı bir yere konduğunda ne olduğu farkı somutlaştırıyor: bekleyen çıktılar bir liste hâlinde durur, her satırın yanında bir düğme olur ve gün içinde biriken listeyi eritmenin en ucuz yolu düğmelere sırayla basmaktır. Metni okumak isteğe bağlı bir adıma dönüşür. Onay bir kez isteğe bağlı hâle geldiğinde, kayıtta duran imza gerçekte neyin onaylandığını anlatmaz.
Hekim yorum yazma işini tek panelde topluyor. Bu, denetimin gündelik iş yükünün içine yerleştiği anlamına geliyor: hekim zaten yorum yazmak için o ekrana giriyor. Denetim böylece işin yapıldığı yerde duruyor; ayrıca bir tur açılmıyor.
Hastanın okuduğu metnin son hâli bu yüzden hekimin elinden çıkıyor. Taslağı model yazmış olabilir; yayımlanan cümleleri hekim düzenlemiş ve altına imzasını atmış oluyor. Hastaya giden metnin sahibi tam bu adımda belirleniyor.
Kural sade: bir onay adımı, onaylanan şeyin görüldüğü yerde durmalı. Görme ile onaylama arasına mesafe girdiği anda o mesafe zamanla büyür ve onay bir forma dönüşür. Model çıktısının statüsünü belirleyen şey de bu: taslağı karara çeviren, üzerine gerçekten bakılmış olması.
Onay adımı akışın neresine konur
Onay kapısının varlığı tek başına yetmiyor; kapının akışın neresinde durduğu asıl kararı taşıyor. Tahlil.com’da push bildirimi yorum üretildiğinde değil, hekim onayladığında tetikleniyor; bildirimi OneSignal gönderiyor. Tetikleyici, onay olayının kendisi.
Bu sıralamanın sonucu şu: hasta onaysız metni görme yoluna hiç girmiyor. “Model üretti, hasta gördü, hekim sonra kontrol etti” zinciri bu üründe kurulamıyor, çünkü hastayı sonuca çağıran olayın kendisi onay. Sıralama sonradan değiştirilebilir bir ayar değil, olay zincirinin biçimi.
Kapının yerini akış şemasında bir kutu olarak düşünmek yanıltıcı olur. Kapı, çıktının kullanıcıya ulaştığı yolun önünde duruyor. Yolun kaç tane olduğu da önemli: bildirim onaydan geçse bile hasta ekranı ham çıktıyı gösterseydi kapı işlevsiz kalırdı. Denetimi kurmak, çıktının kullanıcıya varan bütün yollarının aynı adımdan geçmesi demek.
Aynı üründe kapıdan geçmeyen bir yol da var ve bu yol, kapının neye göre konduğunu gösteriyor. Tahlilmatik hesaplayıcılarında hasta tek bir değeri giriyor ve sonucunun hangi referans aralığında durduğunu görüyor. Burada onay adımı yok. Çıktı bir yorum değil; girilen değerin bilinen bir aralığa göre nerede durduğunu gösteren bir karşılaştırma.
İki rejimin aynı üründe yan yana durması denetimi keyfi olmaktan çıkarıyor. Ölçüt şu: çıktı bir yorum mu taşıyor, yoksa girdinin bilinen bir ölçüte göre yerini mi gösteriyor. Birincisinde arkasında duracak bir kişi gerekiyor. İkincisinde ölçütün kendisi zaten hastanın elindeki çıktıda yazılı.
Her çıktıyı kapıdan geçiren bir kurulum da mümkün ve bedeli görünür: hesaplayıcı da onay beklerse randevusuz erişim diye bir şey kalmaz. Kapıyı her yere koymak denetimi güçlendirmiyor, ürünün kendi vaadini iptal ediyor.
Hatanın maliyeti denetimin biçimini belirler
Denetimin biçimi hatanın nereye kadar gittiğine bakılarak seçiliyor. Sorulacak soru şu: bir hata tek çıktıda mı kalıyor, yoksa sisteme mi yayılıyor?
Soru sınırı kararının dil modeline hiç verilmediği içerik hazırlama aracında problem tanımı doğrudan bu maliyetle kurulmuştu: anahtarda tek satır kaydığında sınavın tamamının değerlendirmesi yanlışa dönüyor. Hata tek soruda kalmıyor; o anahtarla değerlendirilen her kâğıda taşınıyor. Üstelik sonuçlar tutarlı görünmeye devam ediyor, çünkü kayma her kâğıda aynı biçimde işliyor.
Böyle bir yerde çıktı başına onay işe yaramıyor. Onaylanacak şey uzun bir eşleşme listesi olduğunda, bakan kişi hatanın olmadığını değil, listenin makul göründüğünü doğrular. Denetim burada biçim değiştiriyor: insan çıktının önüne değil, modelin yetkisinin önüne geçiyor.
Aracı kuran taraf bu kararı kurulum anında aldı. Bir sorunun sayfada nerede bittiği kararı dil modelinin yorumuna bırakılmadı; proje tanımında gerekçe doğrudan yazılı: kırpma doğruluğu modelin yorumuna bırakılırsa soru sınırları güvenilmez oluyor. Yetkiyi daraltan şey modelin yeteneği hakkında bir kanaat değil, hatanın taşınabilir olması.
Modele kalan işler de aynı ölçüte göre seçildi. Cevap anahtarındaki cevabı ilgili soruya bağlamak modelin işi. Eldeki soruları örnek alıp aynı biçimde yeni soru yazmak da modelin işi. İkisinde de hata tek kayıtta duruyor: yanlış eşleşen bir cevap yalnız o soruyu ilgilendiriyor, biçimsiz üretilmiş bir soru o soru olarak kalıyor.
Kurulumun ikinci yarısı aynı mantığı taşıyor. Anahtar ayrı bir belge olmaktan çıkıp kırpılan soru kaydının içine yazılıyor. Elle tutulan bir listede satır kaymasının zemini vardı; anahtar sorunun kendi kaydının parçası olduğunda o zemin kalkıyor.
Bu yaklaşım her ürüne uymuyor. Tahlil.com’da ön okumanın kendisi model işidir ve daraltılmamıştır. Oradaki güvence bir yetki sınırından değil, çıktının hastaya ulaşmadan önce geçtiği onay adımından geliyor. Aynı soruya iki ayrı cevap veriliyor, çünkü hatanın yayılma biçimi iki üründe aynı değil.
Üç denetim biçimi yan yana
Portföyde insan denetimi tek bir kalıpta durmuyor. Hangi biçimin seçileceğini hatanın maliyeti ve yayılma biçimi belirliyor.
| Denetim biçimi | İnsan nerede devreye giriyor | Model neyi üstleniyor | Bu biçim neden seçildi | Proje ve durum |
|---|---|---|---|---|
| Çıktı onayı | Hekim ön okumayı panelde düzenleyip onaylıyor; push bildirimi ancak onaydan sonra tetikleniyor | Yorumun ön okuma taslağını hazırlamak | Yanlış metin doğrudan hastaya ulaşır; son sözün hekimde kalması baştan tasarım şartıydı | Tahlil.com — yayında |
| Karar yetkisi sınırı | Kurulum anında: soru sınırı kararı dil modelinin yorumuna hiç bırakılmadı | Cevap anahtarını soruya bağlamak, örnekten cevabıyla birlikte yeni soru yazmak | Anahtarda tek satır kayması tek çıktıda kalmaz, sınavın tamamının değerlendirmesini yanlışa döndürür | Vipkurum soru kırpma — yayında |
| Kalıcı çerçeve | Kullanıcı karakterin kimliğini kuruyor; kimlik ve biriken geçmiş hesaba bağlı kalıcı kayıtta duruyor | İnsanın tanımladığı karakter çerçevesinin içinde metin ve görsel üretmek | Çerçeve oturumda yaşarsa oturum kapandığında yok oluyor; denetlenecek referans ancak kayıtta kalırsa var | Secretum — şu an inşa ediyoruz |
Satırlar bir olgunluk sıralaması vermiyor; üçü de kendi probleminin cevabı. Üstteki satır yanlış metnin doğrudan kullanıcıya ulaştığı bir yerde duruyor. Ortadaki satır hatanın tek çıktıda kalmayıp bütün sonuçlara yayıldığı bir yerde. Alttaki satır ise üretim başlamadan önce, modelin neyin içinde üreteceğini belirliyor.
Bu tür işleri yapay zekâ danışmanlığı tarafında kurarken ilk soru model seçimi olmuyor. Önce şu soruluyor: bu çıktı yanlış olduğunda kim ne kaybeder ve yanlış nereye kadar gider. Cevap denetimin biçimini belirliyor; model seçimi ondan sonra gelen çok daha küçük bir karar oluyor.
Üç biçim birbirini dışlamıyor: aynı sistemde bir çıktı için onay kapısı kurulurken başka bir karar hiç modele verilmeyebilir. Ayrımı yapan şey ürünün adı değil, tek tek kararların hata profili.
Çerçeveyi baştan insan kurar: karakter kaydı örneği
Denetimin bir biçimi üretimden önce devreye giriyor. Model bir çerçevenin içinde üretiyor ve o çerçeveyi insan kuruyor. Çerçevenin denetlenebilir olması ise onun nerede durduğuna bağlı.
Karakterin kimlik ve geçmiş çerçevesini modele bırakmadığımız, şu an inşa ettiğimiz platformda kullanıcı kendi yapay zekâ karakterini kuruyor ve karakter bir akışta paylaşım yapıyor. Üzerinde çalıştığımız temel karar şu: karakteri sohbet oturumuna değil hesaba bağlıyoruz. Kimliği ve biriken geçmişi hesaba bağlı kalıcı bir kayıt olarak tutuyoruz.
Bu kararı denetim açısından okumak gerekiyor. Bir sohbet arayüzünde kurgulanan karakter oturum kapandığında yok oluyor. Çerçeve yok olduğunda modelin neye göre ürettiği de izlenemiyor: elde yalnız çıktılar kalıyor, çıktıların dayandığı tanım kalmıyor. Denetlenecek bir referansın var olabilmesi için önce kalıcı olması gerekiyor.
Kayıt tarafını buna göre kuruyoruz. Karakter kaydını MongoDB’de tutuyoruz; karakter yeni özellikler kazandıkça doküman yapısı esniyor ve her eklemede şemayı baştan kurmamız gerekmiyor. Metni Anthropic API üretiyor, görseli Flux API ve Replicate; görsel işini Redis kuyruğuna alıyoruz, dosyayı S3’e yazıyoruz.
Buradaki denetim bir onay düğmesi değil. Kullanıcı tek tek gönderileri onaylamıyor; karakterin ne olduğunu tanımlıyor ve model o tanımın içinde üretiyor. Denetimin gücü tanımın kalıcılığından geliyor. Tanım kayıtta durduğu için sonradan okunabiliyor, değiştirilebiliyor ve bir çıktının hangi çerçeveden çıktığı sorulabiliyor.
Secretum şu an inşa aşamasında ve bu kuruluş kararı üzerinde hâlâ çalışıyoruz. Kalıcı çerçevenin kendi bedeli de var. Oturumda yaşayan bir kurgu hiçbir şey saklamaz; kalıcı kayıt ise sakladığı her şeyin sorumluluğunu beraberinde getirir. Denetlenebilirlik, o sorumluluğu üstlenmeyi kabul etmekle başlıyor.
Denetim kayıt modelinde başlar: girdi ve karar aynı kayıtta
Denetimin en sessiz katmanı kayıt modelinde duruyor. Bir çıktının denetlenebilir olması, kararın dayanağının kararla aynı yerde bulunmasına bağlı. Dayanak başka bir belgedeyse denetim bir eşleştirme işine dönüşüyor ve o eşleştirme her sorguda yeniden yapılıyor.
Girdi ile değerlendirme kararının aynı kayıtta durduğu optik okuma aracında sınavın iki ucu tek çatıda buluşuyor. Soru kırpma aracı cevap anahtarını üretiyor, optik okuma aracı öğrencinin işaretlediği cevabı çıkarıyor. Değerlendirme kararının dayanağı ile üzerine karar verilen girdi ayrı dosyalarda değil, aynı sınav kaydında duruyor. Bir sonucun neye dayandığı sorulduğunda cevap kayıttan okunuyor.
İkisi ayrı ayrı satın alınmış ürünler olsaydı aradaki bağ bir dışa aktarma dosyası ya da elle yapılan bir eşleştirme olurdu. O adım hem yeni bir hata kaynağı açardı hem de denetimi zorlaştırırdı: hangi sonucun hangi anahtarla üretildiği artık kaydın içinde durmazdı.
Aynı kalıp Tahlil.com’da da var. Hastanın girdiği değerler ile hekimin yazıp onayladığı yorum aynı Laravel çekirdeğine bağlı; MySQL kayıtları tutuyor. Hekimin neyi onayladığı, değerlerin girildiği kayıtla aynı yerde duruyor. Onay bir kişiye bağlanıyor ve o bağ kayıtta izlenebiliyor.
Ortak kuruluş kararı şu: kararın dayanağı ayrı bir belgede değil, kararın kendisiyle aynı kayıtta tutulur. Bu karar sonradan alınamıyor. Girdiyle kararı aynı kayıtta tutan veri modelini kurmak, veri modelinin çizildiği ana ait bir iş. Sistem yayına girdikten sonra aynı bağı kurmaya çalışmak, geçmiş kayıtların bir bölümü için hiç mümkün olmuyor.
Denetimin bu katmanı gündelik kullanımda görünmüyor ve tam bu yüzden en kolay atlanan katman. Onay kapısı bir ekranda durur, yetki sınırı bir tartışmada konuşulur; kayıt modeli ise yalnız bir sonuç sorgulandığında kendini gösterir. O gün gelene kadar eksikliği hiçbir yerde hata gibi görünmez.
