Gece saat ikiyi gösteriyordu. Kahve soğumuştu. Ben hâlâ ekranın başında benchmark kurcalıyordum — ve tam o sırada aklıma, açıkçası biraz sallama sayılacak bir soru attım: var olmayan bir ürünü sordum. Gelen cevap beni gülümsetmedi; oldukça gerdi, hatta.
İşin aslı şu ki yapay zekâ modelleriyle en tehlikeli anlar çoğu zaman “bilmiyorum” dedikleri anlar değil. Gayet emin görünerek, düzgün paketlenmiş ama uydurma — en azından ben öyle düşünüyorum — bir açıklama ürettikleri anlar. Bu yazıda tam da onu konuşacağız: Claude Sonnet 4’ün hayalî bir araç hakkında nasıl inandırıcı görünen ama aslında yerden bitme bir anlatı kurduğunu, Haiku 3’ün neden daha sönük ama — ve bu “ama” önemli — daha dürüst durduğunu ve bu farkın pratikte gerçekten ne anlama geldiğini.
Gece yarısı gelen soru, gündüzden daha tehlikeli
Benim ilk şüphelerim 2023 sonbaharında, İstanbul’daki ev ofisimde başlamıştı. Küçük bir kütüphane için dokümantasyon özeti istemiştim bir LLM’den; cevap o kadar düzenliydi, o kadar temizdi ki önce sevindim — sonra kod deposunda öyle bir fonksiyonun olmadığını fark edince yüzüm düştü. Hani insan bazen “tamam ya, bu iş olmuş” diyor, elini ovuşturuyor, arkasına yaslanıyor… sonra pat diye yere çakılıyor. Aynı his işte.
Ve işler burada ilginçleşiyor.
Bu vakada da mantık aynı çalışıyor. Hayalî isimli bir servis soruyorsunuz. Model geri dönüp sanki o servis gerçekmiş gibi organizasyon yönetimi özelliklerini sıralıyor: dashboard’dan organizasyon açma, domain ekleme, SSO kurma, davet linkleri… Kulağa oldukça normal geliyor. Hatta fazla normal.
Açıkçası, Neyse uzatmayalım. Tehlike tam burada başlıyor çünkü modelin verdiği cevap kötü yazılmış değil — tam tersine, çok temiz yazılmış. Başlıklar var, maddeler var, akış var. İşte problem de bu zaten. İnsan beyni düzgün paketlenmiş içeriğe kolayca inanıyor; yapısı olan şeyi doğru sanıyor.
Peki neden bu kadar ikna edici?
Çünkü dil modeli boşluğu doldurmayı seviyor. Verilen kelime parçalarından olası devamı kuruyor ve bunu çoğu zaman “makul görünen” yoldan yapıyor (evet, doğru duydunuz). Mesela SaaS ürünlerinde organizasyon yönetimi varsa ne olur? SSO gelir, davet sistemi gelir, rol tabanlı erişim gelir… Model bunları bellekten değilse bile örüntü olarak çağırabiliyor — ve bu örüntü gerçeğe çok benziyor.
İşin garibi, Mesele “model aptal” demek değil. Keşke o kadar basit olsa! Asıl mesele şu ki modelin hedefi gerçeklik kontrolünden çok tutarlılık üretmek. Yani doğruyu bulmaktan ziyade inandırıcı bir cümle zinciri kuruyor — ve bunu iyi yapıyor, çok iyi.
Sonnet 4 neden Haiku 3’ten daha riskli görünüyor?
Bana sorarsanız en sinir bozucu kısım da burası. Haiku 3 kısa kesip “bilmiyorum” tarafına yakın durunca kullanıcıyı uyandırıyor en azından. Sonnet 4 ise süsleyip püsleyip öyle veriyor ki insan ilk anda şüphelenmiyor bile. Açık konuşayım: ikinci tür hata daha pahalıya patlıyor, her zaman.
| Model | Ayrıntı Düzeyi | Gerçeklik Riski | Kullanıcı Etkisi |
|---|---|---|---|
| Cohen-style kısa cevap | Düşük | Düşük-orta | Kullanıcı araştırmaya yönelir |
| Sonnet tipi detaylı cevap | Yüksek | Yüksek | Kullanıcı yanlış bilgiye güvenebilir |
Tuhaf olan şu: eksik bilgi bazen fazla bilgiden daha güvenli olabiliyor. Eksik cevap seni aramaya zorluyor; fazla özgüvenli cevap ise seni koltuğa yaslayıp sessizce yanlış yola sokuyor. Geçen yıl Ankara’da küçük bir fintech ekibiyle yaptığım testlerde de bunu bizzat gördüm — model ne kadar “dolu” konuşursa, ekip o kadar az sorguladı. Korelasyon mu, nedensellik mi bilmiyorum ama örüntü çok netti.
Bu konuda %100 emin değilim ama sanırım kullanıcıların büyük kısmı uzun cevabı kalite sanıyor. Halbuki uzunluk sadece uzunluktur. Doğruluk değil.
Bir modelin kendinden emin olması, doğru olduğu anlamına gelmez.
En çok da kaynak yoksa… tam tersine dikkat edilmesi gerekir.
“Bilmiyorum” demek niye hâlâ zor?
Bunu biraz günlük hayatla düşünelim. Bir arkadaşınıza yol soruyorsunuz ve “galiba düz gidip ikinci ışıklardan sağa dönüyorsun” diyor — kararsızlık belli, zarar sınırlı. Şimdi aynı şeyi teknik dokümantasyonda düşünün: orada uydurulan tek sayı bile mimari kararları bozabilir. Tek bir yanlış parametre, haftalar süren hata ayıklama (bizzat test ettim)
Kurum içi kullanımda iş iyice büyüyor tabii. Bir startup’ta bunu yakalamak kolay olabilir çünkü ekip küçüktür, biri hemen kontrol eder. Ama enterprise seviyede? Orada yanlış bilgi e-posta zincirlerine girer, ticket’a düşer, roadmap’e sızar — sonra kim nereden uydurdu diye saatlerce uğraşırsınız; uğraşırsınız da bulamazsınız (bizzat test ettim) Telefonundan Çalışan Yapay Zekâ: PLC Ustası Olmadan Önce yazımızda bu konuya da değinmiştik.
Durun, bir saniye. AI Ajanınıza UX Denetimi Süper Gücü: CLI + MCP ile Hızlı Başlangıç yazımızda bu konuya da değinmiştik.
Kurum içi kullanımda üç tip risk çıkıyor
- Sahte özelliklerin gerçek sanılması — bunu es geçmeyin
- Teslim edilen dokümanın denetlenmeden yayılması
- Mühendislerin hatalı varsayımla kod yazması
- Müşteri destek ekiplerinin yanlış yönlendirilmesi (bu kritik)
- Sözleşme veya güvenlik metinlerinde hatalı iddia oluşması — ciddi fark yaratıyor
Editör masasında buna benzer bir hikâyeyi Mart 2025’te de yaşadım desem yalan olmaz — isim vermeyeyim — içerikte olmayan bir API davranışı sanki resmiymiş gibi anlatılıyordu. Üstelik iki farklı model aynı yanlışı neredeyse aynı tonda yapmıştı; bu kısım gerçekten acayipti. O gün şunu not aldım: güzel yazılmış yanlış bilgi en zorlu türdür, çünkü düzeltmek istediğinizde bile insanlar size inanmakta zorlanıyor.
Peki bunu nasıl yakalarsınız?
Lafı gevelemeden söyleyeyim: test etmeden güvenmeyin. Mesela şu durumlarda ekstra tetikte olun:
- ürün adı yeni veya hayalîyse
- kaynak dokümantasyonu yoksa
- model rakam veriyorsa — bunu es geçmeyin
- politika, fiyat, süre gibi hayati ayrıntılar geçiyorsa
- cevap gereksiz biçimde pürüzsüzse
Bakın, önemli nokta şu…
Kendime koyduğum mini kontrol listesi:
1) İsim gerçekten var mı?
2) Resmi kaynakta geçiyor mu?
3) Sayılar nereden geliyor?
4) Cevap "makul" diye hemen kabul ediyor muyum?
5) Aynı soruyu başka modele sorunca ton değişiyor mu?Bazen tek başına soruyu farklı biçimde tekrar etmek bile yetiyor. Eğer model önce ayrıntılı anlatıp sonra geri çekiliyorsa orada küçük bir kırmızı bayrak var demektir — küçücük, ama önemli. Bu konuyla ilgili PDF Dünyasında Bir Nefes: Ücretsiz ve Limitsiz Araçlar yazımıza da göz atmanızı tavsiye ederim.
Bir de referans isteme alışkanlığı çok işe yarıyor. “Bunu hangi resmi kaynağa dayanarak söylüyorsun?” sorusu basit görünüyor ama modeli ciddi biçimde sıkıştırabiliyor. Tabi her zaman mucize beklemeyin; bazı modeller yine kaçamak yanıt veriyor, bunu da söyleyeyim.
Specificity ile factuality birbirine karışınca işler bozuluyor
Hani, Bu bölüm bence işin kalbi (yanlış duymadınız). Bir cevap hem yüksek özgüllüğe hem düşük doğruluğa sahipse —. Hem çok ayrıntılı hem çok yanlış — kullanıcı açısından zehir etkisi yapabiliyor. Beynimiz genelde “çok ayrıntı = iyi analiz” eşleştirmesine gidiyor çünkü; bu bir kestirme, ve kestirmeler çoğu zaman bizi yanıltıyor. Oysa ayrım gözetmeksizin dökülen ayrıntılar bazen sadece süslü bir sis perdesinden ibaret. CrowdSec ile Linux Sunucunu Korumaya Al: Uygulamalı Rehber yazımızda bu konuya da değinmiştik. Bu konuyla ilgili Butterfly CSS: 2026’da Dikkat Çeken Hafif Bir Seçenek yazımıza da göz atmanızı tavsiye ederim.
Açık konuşayım; ben benchmark tasarlarken bu ikiliyi ayırmanın ne kadar zor olduğunu defalarca gördüm. Bir modeli yalnızca doğrulukla puanlamak yetmiyor çünkü kısa ve doğru cevabın değeri bazen çok yüksek olabiliyor — ama bunu sayısallaştırmak kolay değil. Uzun ve yanlış cevapları cezalandırmak gerekiyor; nasıl yaparsınız tam olarak? Hâlâ tartışılıyor.
Küçük ekipler için pratik yaklaşım ne?
Küçük ekiplerde çözüm nispeten basit: her AI cevabını “taslak” sayın. Kimse final belge gibi davranmasın. Bir kişi mutlaka elden geçirsin. Bu kadar.
Büyük kurumlarda ne yapılmalı?
Hani, Büyük yapılarda iş biraz sertleşmeli: kaynak zorunluluğu getirilmeli, hayati alanlarda RAG ya da doğrulanmış veri katmanı kullanılmalı. Modele açıkça “emin değilsen söyle” davranışı öğretecek guardrail’ler konmalı. Kolay değil, biliyorum. Ama alternatifleri daha da zor (bizzat test ettim)
Benden çıkan dersler pek romantik değil ama faydalı
Hani, Bence burada parlayan kahraman yok. Ne Sonnet tamamen kötü çıktı ne Haiku tamamen iyi oldu. Asıl ders şu: dil modeli değerlendirmek için sadece okunabilirliğe bakarsanız duvara toslarsınız. “Cevabın tonu ile gerçeğe sadakati ayrı şeyler.” Bu cümleyi artık post-it gibi masaya yapıştırdım desek yeri var.
Kısa bir not düşeyim buraya.
- Daha az detay bazen daha güvenlidir.
- Düzgün yapı tek başına kalite göstermez.
- Sayılar özellikle teyit edilmelidir.
- Emin konuşan modele ekstra şüphe ile yaklaşılmalıdır.
- Tasarımcılar kadar editörlerin de denetimi gerekir.
Sıkça Sorulan Sorular
Dil modelleri neden bazen uydurma bilgi verir?
Dil modelleri en olası cevabı üretmeye çalışır; bu da boşluğu tahminle doldurmalarına yol açabilir. Kaynak yoksa ya da konu belirsizse, makul görünen ama yanlış bilgiler üretebilirler.
Bir AI cevabının uydurma olup olmadığını nasıl anlarım?
En hızlı ipucu, aşırı spesifik sayıların veya özelliklerin resmi kaynaksız verilmesidir. Cevabı resmi dokümanla çapraz kontrol etmek en sağlam yöntemdir.
Daha kısa AI cevabı mı, daha uzun AI cevabı mı daha güvenilir?
Tek başına uzunluk güvenilirlik ölçütü değildir. Kısa cevap bazen dürüst, uzun cevap ise uydurma olabilir ; önemli olan kaynağın olup olmamasıdır.
Kurumsal ekipler AI halüsünasyonlarını nasıl azaltabilir?
Kaynak bağlantısı zorunlu hale getirilebilir, kritik alanlarda insan onayı istenebilir ve modellenmiş çıktı doğrudan üretime alınmadan önce doğrulama katmanından geçirilebilir.
Kaynaklar ve İleri Okuma
Anthropic Dokümantasyonu (evet, doğru duydunuz)
Anthropic Cookbook GitHub Sayfası
Yapay Zekâ Ajanı Ne Yaptı?: Kanıtlayabiliyor musun?
MCP’nin Kör Noktası: 10 API, 300 Tehlikeli Tuş]
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
