Kusursuz Görünen Yanlış: 3B Beyin Simülatöründe Bulduğum Hata ve Yapay Zekâ Projeleri İçin Anlamı
7 Ağustos 2026 · Güncelleme: 10 Ağustos 2026
Bir eğitim materyali hazırlıyordum. 3B bir beyin simülatörü: modeli döndürüyorsunuz, bir loba tıklıyorsunuz, o bölge renkleniyor ve yan panelde işlevi, nörotransmiterleri, hasar bulguları çıkıyor.
İlk refleks koda bakmaktır. Segmentasyon kuralları basitti: modelin her köşesi (vertex) 0–1 aralığına normalize ediliyor, sonra eşiklerle loblara ayrılıyordu. "Ön tarafta ve yukarıdaysa frontal lob", "arka altta ise beyincik" gibi.
Kurallar mantıklıydı. Kod da doğru çalışıyordu.
Sorun verinin kendisindeydi — daha doğrusu verinin nasıl durduğunda.
3B model dosyasını (.glb) açıp içindeki düğüm matrislerine baktığımda şunu gördüm: dosya, geometriyi X ekseni etrafında 90 derece çeviren bir dönüşüm taşıyordu. Bu, 3B üretim hatlarında son derece yaygın bir durumdur; Blender ve benzeri araçlar "Z yukarı" çalışırken web standardı olan glTF "Y yukarı" kabul eder, dönüşüm de dosyaya gömülür.
Yani her lob sınırı, doğru mantıkla ama yanlış eksene uygulanıyordu.
Peki neden fark edilmedi?
İşin kritik kısmı burası.
Görüntüleme motoru bu dönüşümü zaten uyguluyordu. Ekrana çizilen beyin, dik ve doğru duruyordu. Model hiçbir görsel belirti vermiyordu.
Hata yalnızca etiketleme katmanındaydı. Ve etiketler renkli olduğu için, ekranda gördüğünüz şey "bir bölge seçilmiş ve boyanmış" izlenimi veriyordu — ki bu doğruydu. Yanlış olan tek şey hangi bölge olduğuydu.
Bunu doğrulamak için sayıya baktım: frontal etiketi, modelin köşelerinin %51'ini kaplamıştı. Frontal lob, serebral korteksin yaklaşık %38'idir. Sistem "çalışıyor" görünürken, elimizdeki rakam anatomik olarak imkânsızdı.
Bir öğrenci bu simülatörle çalışsa, şakak lobunun yerini yanlış öğrenecekti. Ve ekrandaki hiçbir şey ona bir terslik olduğunu söylemeyecekti.
Bunun yapay zekâ ile ne ilgisi var?
Doğrudan ilgisi var. Çünkü bu, YZ projelerinde karşılaştığım en yaygın başarısızlık biçiminin birebir aynısı.
Bir dil modeli akıcı bir özet üretir. Bir sınıflandırıcı %94 doğruluk raporlar. Bir tahmin modeli grafiği yukarı çizer. Herkes tatmin olur — çünkü çıktı doğru görünür.
Oysa:
Akıcı özet, kaynakta olmayan bir cümle uydurmuş olabilir.
%94 doğruluk, veri sızıntısından (data leakage) geliyor olabilir; test kümesindeki bilgi eğitim kümesine karışmıştır.
Yükselen grafik, hedef değişkenin geleceğe ait bir bilgiyi taşımasından kaynaklanıyor olabilir.
Bunların hiçbiri hata mesajı vermez. Kod çöker de değildir. Sistem sessizce, güvenle ve yanlış çalışır.
Makul görünen çıktı ile doğrulanmış çıktı arasındaki fark, bir sistemi işe yarar kılan tek şeydir.
Nasıl düzelttim: hipotez, ölçüm, kanıt
Hatayı bulma süreci de anlatmaya değer, çünkü aynı disiplin YZ projelerinde birebir geçerli.
1. Kodu değiştirmeden önce ölçtüm. İlk refleks eşikleri kurcalamak olurdu — "0.68'i 0.62 yapayım, bakalım düzelir mi." Bu, hatayı gizlemenin en hızlı yoludur. Onun yerine modelin dosya yapısını açıp düğüm matrislerini okudum.
2. Hipotezi tarayıcıda doğruladım. Modelin yerel eksenlerinin uç noktalarını sahneye izdüşürüp ekranda nereye düştüklerine baktım. Yerel "Y+" ekseni ekranın arkasına, yerel "Z+" ekseni yukarıya düşüyordu. Hipotez kanıtlandı.
3. Kök nedeni düzelttim, belirtiyi değil. Segmentasyon artık ham koordinatlar üzerinde değil, dünya uzayına taşınmış koordinatlar üzerinde çalışıyor. Böylece dosya hangi dönüşümü taşırsa taşısın kurallar doğru eksene uygulanıyor.
4. Sonucu ölçerek kabul ettim. Yan görünümde 44×20'lik bir ızgarada her noktaya ışın atıp hangi lobun döndüğünü haritaladım. Çıkan harita, ders kitabındaki lob şemasıyla örtüştü. Ancak bundan sonra "düzeldi" dedim.
Bu arada iki hata daha çıktı: modelin boştaki yavaş dönüşü, kamera ön ayarlarını 20 saniye içinde anlamsız hâle getiriyordu; ve hızlı ardışık seçimlerde iki kamera animasyonu birbiriyle yarışıyordu. İkisi de "yanlış yeri gösteriyor" şikâyetinin parçasıydı ama farklı sebeplerdi.
Sonra: tahmini tamamen kaldırmak
Hatayı düzelttim ama rahatsızlığım geçmedi. Çünkü kurallar düzeltilmiş olsa da hâlâ tahmindi. Elimdeki beyin modeli tek parça bir yüzeydi; loblar veride işaretli değildi, ben koordinatlardan çıkarıyordum.
Bu yüzden ikinci bir şey yaptım: tam boy insan anatomisi simülatörü.
Bu sefer veri seçimini mimarinin merkezine koydum. BodyParts3D (Japonya, DBCLS) ve üzerine kurulu Z-Anatomy projesi, insan anatomisinin tamamını açık lisansla (CC BY-SA) paylaşıyor — ve kritik nokta şu: her kemik, her kas, her organ dosyada ayrı bir nesne olarak duruyor, adıyla birlikte.
Yani tıkladığınızda dönen ad, benim hesapladığım bir tahmin değil; verinin kendi etiketi.
Sonuç:
Anatomik sistem
7 (iskelet, kas, eklem, sinir, dolaşım, iç organlar, lenf)
Ayrı tıklanabilir yapı
2.914
Üçgen sayısı
~1,9 milyon
Kaynak dosya
293 MB Blender
Web sürümü
33 MB
Tek engel şuydu: veri bir Blender dosyası olarak dağıtılıyor. Açmak için Blender kurmanız ve Blender bilmeniz gerekiyor — yani öğretmenin, öğrencinin eline geçmiyor.
Aradaki mesafeyi kapatan dönüştürme hattını yazdım. Burada da dört sessiz tuzak çıktı; ilki tam olarak aynı türdendi: nesnelerin poligon sayısını dosyadan okuyup ona göre sadeleştirme yapınca, 66 bin poligonluk bir katman 44 MB olarak dışa aktarıldı. Sebep, nesnelerde sonradan uygulanan bir alt bölümleme (subdivision) katmanının bulunmasıydı — dosyadaki ham sayı gerçeği söylemiyordu. Yine aynı ders: okuduğunuz sayı, ölçtüğünüz sayı değildir.
Açık kaynak — ikisi de canlı
Her iki simülatörün tamamı — kod, dönüştürme hattı ve web'e hazır 3B dosyalar — açık kaynak olarak yayında. Kurulum, üyelik ya da ücret yok; telefondan da açılıyor.
Beyin simülatörü de bu arada tamamen yeniden kuruldu: ilk sürümdeki model dosyasının lisansı belirsiz çıktığı için Z-Anatomy verisine taşındı ve loblar atlasın kendi hiyerarşisinden okunur oldu — yani oradaki tahmin de ortadan kalktı.
Kod MIT lisanslı. 3B anatomi verisi CC BY-SA 4.0 ile lisanslı ve BodyParts3D (DBCLS) ile Z-Anatomy'den türetilmiştir; anatominin kendisi onların emeği, bu depolar yalnızca web'e taşıma katmanıdır.
Doğrulama yetmedi: uzman gözü
Buraya kadar anlattığım hatayı ölçerek buldum: "frontal lob köşelerin %51'i" rakamı, ekrandaki hiçbir görüntünün söylemediğini söyledi.
Ama sonraki üç hatayı ölçüm bulmadı. Onları, anatomi bilen biri modele bakarak buldu.
Birincisi: "Dolaşım sisteminde neden sadece kalp var?"
Sistem çalışıyordu. Kalp dönüyordu, tıklanıyordu, adı çıkıyordu. Hiçbir hata yoktu — çünkü olmayan bir şeyin hatası olmaz. Dosyayı açıp baktığımda gördüm ki atlasta damarlar mesh değil, bevel'li Bézier eğri olarak modellenmiş. Dönüştürme betiğim "mesh olmayanı atla" diyordu; 654 damarı sessizce atlamış. Arter ve ven ağacının tamamı eksikti ve hiçbir sayı bunu haber vermiyordu.
Düzeltince dolaşım sistemi 22 yapıdan 676'ya çıktı — 356 arter, 203 ven. Aynı hata sinir sistemini de vurmuştu: 335 → 582 (kranial sinirler dahil).
İkincisi: "Lenf sisteminde ve oynamaz eklemlerde bir sorun var mı?"
Baktım: atlasta lenf damarları ve duktus torasikus adlandırılmış ama modellenmemiş — koleksiyonlar boş. Aynı şekilde kafatası suturları, gomfoz ve sinkondroz için de klasör var, içi yok.
Bu bir hata değildi. Asıl sorun şuydu: arayüzüm olmayan şeyi vaat ediyordu. Bilgi kartı "lenf damarları, düğümler, dalak" yazıyordu — damarlar yoktu. "Sinovyal, kıkırdaksı ve lifli eklemler" yazıyordu — lifli eklem yoktu. Katmanın adı bile yanlıştı; "Eklemler" değil, fiilen bağlar, kapsüller ve disklerti.
Üçüncüsü telefonda çıktı: bir sistem seçilip menü kapatıldığında model iskelete geri dönüyordu. Sebep, menüyü kapatmak için ekrana yapılan dokunuşun aynı zamanda "yapı seçimi" sayılmasıydı.
Ben "loblar doğru yerde mi?" diye sordum ve ölçüp doğruladım. Ama "dolaşım sisteminde kaç damar olmalı?" diye sormadım — çünkü bilmiyordum. Ekranda kırmızı bir kalp dönüyordu ve bana yeterli görünüyordu.
Yapay zekâ projelerinde bunun karşılığı çok tanıdık: model kendi içinde tutarlıdır, metrikler yerindedir, çıktı akıcıdır — ama bütün bir kategori veri setinden düşmüştür ve bunu ancak sahayı bilen biri fark eder. Sigorta modelinde belirli bir poliçe tipi, tıbbi kayıtta belirli bir tanı grubu, müşteri analizinde belirli bir segment. Model bunların yokluğundan şikâyet etmez; sadece o alanda sessizce yanılır.
Bu yüzden ekibe alan uzmanı katmak "iyi olur" değil, doğrulama zincirinin parçasıdır. Veri bilimci modelin tutarlı olduğunu gösterir; alan uzmanı modelin eksik olduğunu gösterir. İkisi farklı işlerdir ve biri diğerinin yerine geçmez.
Çıkarılacak ders
Yapay zekâ eğitimlerinde en çok vakit ayırdığım konu model kurmak değil. Model kurmak artık kolay — üç satır kodla sınıflandırıcı eğitiliyor, bir API çağrısıyla metin üretiliyor.
Zor olan, kurduğunuz şeye ne zaman güvenmeyeceğinizi bilmek.
Bunun için üç alışkanlık öneriyorum:
Sayıyı yeniden türetin. Sistemin verdiği metriği bir de kendiniz, farklı bir yoldan hesaplayın. Benim vakamda "frontal lob %51" rakamı, ekrandaki hiçbir görüntünün söylemediğini söyledi.
Bilineni, çıkarımı ve bilinmeyeni ayırın. "Model %94 doğru" bir ölçümdür. "Model işe yarıyor" bir çıkarımdır. "Sahada da %94 olacak" ise bilinmeyendir. Üçünü aynı cümlede kullanmayın.
Kabul ölçütünü davranışla tanımlayın. "Kod eklendi" bir kabul ölçütü değildir. "Yan görünümde 44×20 ızgara ders kitabı haritasını verdi" bir kabul ölçütüdür.
Alan uzmanına gösterin — ölçümden sonra, yayından önce. Ölçüm neyi kontrol ettiğinizi doğrular; uzman neyi kontrol etmediğinizi söyler. "Dolaşım sisteminde neden sadece kalp var?" sorusunu hiçbir test yazmaz.
Bu dört alışkanlık, bir beyin simülatöründe de, bir kredi risk modelinde de aynı işi görüyor.
Bu yazıdaki simülatörler Yapay Zekâ Okulum eğitimlerinde örnek materyal olarak kullanılmaktadır. Yapay zekâ ve veri bilimi eğitimlerimiz için kurslarımıza göz atabilirsiniz.
Kaynaklar: BodyParts3D — The Database Center for Life Science (DBCLS) — CC BY-SA 2.1 Japan · Z-Anatomy — The libre 3D atlas of anatomy — CC BY-SA 4.0
Kusursuz Görünen Yanlış: 3B Beyin Simülatöründe Bulduğum Hata ve Yapay Zekâ Projeleri İçin Anlamı
