``

Yalnızlık ile yalnız olmak aynı şey değil

Yalnızlık, çevredeki insan sayısından çok, arzulanan ve deneyimlenen sosyal bağ arasındaki farktır. Basitleştirilmiş bir modelle bunu şöyle gösterebiliriz:

Burada $L$ hissedilen yalnızlığı, $B_a$ arzulanan bağ düzeyini, $B_d$ ise deneyimlenen bağ düzeyini temsil eder. Bir kişi kalabalık içinde bile anlaşılmadığını düşünüyorsa $B_d$ düşük kalabilir. Chatbot’lar tam bu noktada ilgi gösteren, tutarlı ve erişilebilir bir etkileşim sağlayarak deneyimlenen bağ hissini geçici olarak yükseltebilir.

Fakat bu formül önemli bir ayrıntıyı saklar: Her bağ aynı değildir. Bir yapay zekâ, empatiyi dilsel olarak simüle eder; duyguyu biyolojik ve öznel anlamda yaşadığı varsayılamaz. “Seni anlıyorum” cümlesi kullanıcıda gerçek bir rahatlama yaratabilir, ancak bu rahatlama karşılıklı insan deneyimiyle aynı kaynaktan gelmez.

Dijital arkadaşlık ve insan ilişkisi

Tablodaki farklar, chatbot’ların değersiz olduğunu değil, farklı bir ilişki türü sunduğunu gösterir. Dijital sohbet; prova alanı, günlük tutma aracı veya zor bir günün geçici desteği olabilir. Sorun, aracın bütün sosyal yaşamın yerine geçmeye başlamasıdır.

Rahatlatıcı döngü ne zaman kapanır?

Kullanıcı chatbot’la konuştukça kısa vadeli rahatlama yaşayabilir. Bu rahatlama dış dünyaya katılımı destekliyorsa olumlu bir geri bildirim oluşur. Tersine, insanlarla iletişim kurma isteğini azaltıyorsa izolasyon büyüyebilir:

Bu örnek modelde $I$ izolasyonu, $C$ kaçınma amacıyla kullanılan chatbot süresini, $S$ sağlıklı sosyal teması; $k$ ve $h$ ise kişiye göre değişen etkileri belirtir. Denklem klinik ölçüm değildir, ilişkinin yönünü düşünmek için kullanılan kavramsal bir araçtır.

Aşağıdaki Python örneği bu basit dinamiği görünür kılar:

isolation = 5.0
avoidance_effect = 0.12
social_effect = 0.35

weekly_data = [
    {"chatbot_avoidance": 4, "social_contact": 1},
    {"chatbot_avoidance": 3, "social_contact": 2},
    {"chatbot_avoidance": 2, "social_contact": 3},
]

for week, data in enumerate(weekly_data, start=1):
    isolation += avoidance_effect * data["chatbot_avoidance"]
    isolation -= social_effect * data["social_contact"]
    isolation = max(0, isolation)
    print(f"{week}. hafta: {isolation:.2f}")

Kod, chatbot kullanımını otomatik olarak zararlı saymaz; özellikle kaçınma amacıyla kullanılan süreyi ayrı değişken olarak ele alır. Sosyal temas arttıkça modeldeki izolasyon puanı düşer. Gerçek hayatta kişilik, kültür, ekonomik koşullar ve ruh sağlığı gibi çok daha fazla değişken bulunur.

Köprü mü, varış noktası mı?

Sağlıklı yaklaşım, chatbot’u insanlara açılan bir köprü olarak kullanmaktır: zor bir konuşmayı prova etmek, bir arkadaşınıza yazacağınız mesajı düzenlemek veya sosyal hedefler belirlemek buna örnektir. Sistemlerin de bağımlılığı teşvik etmeyen dil kullanması, “yalnızca bana ihtiyacın var” benzeri ifadelerden kaçınması ve kriz durumlarında profesyonel kaynaklara yönlendirmesi gerekir.

Dijital sohbet gerçek bir psikolojik etki yaratabilir; fakat karşılıklı sorumluluk, ortak anılar ve bedensel varlık içeren insan bağının tam karşılığı değildir. En iyi senaryoda yapay arkadaşlık yalnızlığın üzerine kapatılan bir kapı değil, dışarıya açılan güvenli bir pencere olur.

``

Legacy kod neden böyle görünür?

Bugünün standartlarıyla geçmişi değerlendirmek kolaydır. Ancak bir kararın kalitesi yalnızca ortaya çıkan kodla değil, karar verildiği anda mevcut olan bilgilerle ölçülmelidir. Bunu basitçe şöyle düşünebiliriz:

Bugün bildiğimiz güvenlik açığı, performans sorunu veya tasarım deseni o gün bilinmiyor olabilir. Ekip küçük, teslim tarihi yakın, test altyapısı yetersiz ya da kullanılan framework henüz olgunlaşmamış olabilir. “Neden bunu düzgün yapmamışlar?” sorusu bu değişkenleri görmezden gelir.

Kod arkeolojisi yapmak

Legacy sistemde çalışmak biraz arkeolojiye benzer. Kod görünen eserdir; commit mesajları, hata kayıtları, eski dokümanlar ve ekip üyelerinin anıları ise kazı alanındaki ipuçlarıdır. Önce modülün ne yaptığını değil, neden var olduğunu öğrenmeye çalışın.

Örneğin aşağıdaki koşul gereksiz bir tekrar gibi görünebilir:

function calculatePrice(order) {
  // Eski mobil istemciler indirim alanını göndermiyor.
  const discount = order.discount == null ? 0 : order.discount;

  if (order.clientVersion && order.clientVersion < 3) {
    return Math.max(0, order.total - discount);
  }

  return applyModernPricing(order, discount);
}

Buradaki sürüm kontrolünü hemen silmek kodu sadeleştirir; fakat eski istemcilerin fiyat hesaplamasını bozabilir. Yorum, davranışın tarihsel nedenini kısmen açıklıyor. Daha iyi yaklaşım; kullanım metriklerini incelemek, eski istemcilerin hâlâ aktif olup olmadığını doğrulamak ve kaldırma kararını testlerle güvenceye almaktır.

Empati, kötü kodu korumak değildir

Empatik yaklaşım “Hiçbir şeye dokunmayalım” anlamına gelmez. Tam tersine, güvenli değişiklik yapabilmek için sistemi ciddiye almaktır. Kodu yazan kişiyi yargılamamakla teknik sorunları açıkça adlandırmak aynı anda mümkündür.

Sağlıklı bir iyileştirme süreci şu sırayı izleyebilir:

1. Mevcut davranışı karakterizasyon testleriyle kaydet.
2. Kodun çağrıldığı yerleri ve dış bağımlılıkları bul.
3. Küçük, geri alınabilir değişiklikler yap.
4. Gözlemlenebilirlik ekleyerek sonucu ölç.
5. Öğrenilen tarihsel bilgiyi dokümante et.

Risk kabaca değişikliğin büyüklüğü ve belirsizlikle artar:

Bu yüzden dev bir “temizlik” pull request’i yerine küçük adımlar genellikle daha güvenlidir. Önce test eklemek, ardından isimleri düzeltmek ve son olarak sorumlulukları ayırmak hem incelemeyi hem geri dönüşü kolaylaştırır.

Dilden kültüre uzanan etki

Kod incelemesinde kullanılan dil ekip kültürünü belirler. “Bu saçma olmuş” yerine “Bu kararın arkasındaki kısıtı biliyor muyuz?” demek yalnızca daha nazik değildir; daha fazla teknik bilgi üretir. İnsanlar yargılanmayacaklarını bildiklerinde eski hataları, geçici çözümleri ve gizli riskleri daha rahat paylaşır.

Unutmayın: Bugünün modern mimarisi de yarının legacy sistemidir. Bize miras kalan kodu merakla okumak, gelecekte kendi kararlarımızın da bağlam içinde değerlendirilmesini istemektir. İyi mühendislik yalnızca temiz kod yazmak değil, kirli görünen kodun hangi fırtınadan çıktığını anlayabilmektir.

``

Dil, düşüncenin yalnızca ambalajı mı?

Sapir-Whorf hipoteziyle ilişkilendirilen dilsel görecelik, konuştuğumuz dilin dünyayı algılama ve kategorilere ayırma biçimimizi etkilediğini savunur. Kuramın güçlü yorumu dilin düşünceyi belirlediğini, daha ılımlı ve günümüzde daha fazla kabul gören yorumu ise bazı düşünme alışkanlıklarını yönlendirdiğini söyler.

Örneğin Türkçedeki “o” zamiri konuşulan kişinin cinsiyetini belirtmez. İngilizceye çeviri yapan bir model ise bağlama göre “he”, “she” veya “they” seçmek zorundadır. Kaynak dilin açık bırakabildiği bir özellik, hedef dilde karara dönüşür. Model yalnızca çeviri yapmaz; belirsizliği yorumlar.

Modeller “en doğruyu” nasıl seçiyor?

Modern çeviri sistemleri, bir hedef cümlenin kaynak cümle verildiğinde ne kadar olası olduğunu hesaplar. Basitleştirilmiş amaç şöyle yazılabilir:

Burada $x$ kaynak metin, $y$ hedef metindir. Sorun şudur: En olası çeviri, kültürel açıdan en sadık çeviri olmak zorunda değildir. Eğitim verilerinde sık görülen kalıplar yüksek olasılık kazanır; az temsil edilen lehçeler, yerel benzetmeler veya toplumsal nezaket biçimleri ise istatistiksel gürültü gibi değerlendirilebilir.

Kayıp yalnızca sözcük düzeyinde ölçülemez. Kavramsal olarak kültürel maliyeti şöyle düşünebiliriz:

$L_s$ anlamsal kaybı, $L_p$ pragmatik yani bağlamsal kaybı, $L_c$ kültürel çağrışım kaybını temsil eder. Geleneksel otomatik ölçütler çoğunlukla ilk bileşene odaklanırken diğer ikisini yakalamakta zorlanır.

Küçük bir belirsizlik deneyi

Aşağıdaki Python kodu, tek bir çeviri yerine adayların puanlarını incelemenin neden önemli olduğunu gösteren basitleştirilmiş bir örnektir:

adaylar = {
    "He said he would come.": 0.46,
    "She said she would come.": 0.41,
    "They said they would come.": 0.13
}

sirali = sorted(adaylar.items(), key=lambda x: x[1], reverse=True)

for ceviri, olasilik in sirali:
    print(f"{olasilik:.0%} — {ceviri}")

Kaynak cümle “O geleceğini söyledi” ise ilk iki aday arasındaki küçük fark, modelin gerçek bilgiye sahip olduğunu göstermez. Bu fark; eğitim verilerindeki meslek, isim veya toplumsal cinsiyet dağılımlarından kaynaklanabilir. Sistem kendinden emin bir cümle üretirken aslında kültürel bir tahminde bulunmaktadır.

Daha duyarlı çeviri mümkün mü?

Çözüm, makineleri terk etmek değil; başarı tanımını genişletmektir. Modeller bağlam sormalı, belirsizlikleri işaretlemeli ve birden fazla çeviri önermelidir. Değerlendirme ekiplerinde yerel konuşurlar, çevirmenler ve kültür araştırmacıları bulunmalıdır. Ayrıca “akıcı” görünen her çıktının sadık olmadığı unutulmamalıdır.

Makine çevirisi diller arasındaki mesafeyi olağanüstü biçimde azaltıyor. Yine de hızın bedeli, farklı düşünme biçimlerinin tek ve pürüzsüz bir ifadeye sıkıştırılması olabilir. İyi bir çeviri yalnızca “Bu cümle ne diyor?” sorusunu değil, “Bu dil dünyayı neden böyle söylüyor?” sorusunu da koruyabilmelidir.

Eşzamanlılık ile paralellik aynı şey değildir

Eşzamanlılık, birden fazla işin ilerleyişinin aynı zaman aralığında yönetilmesidir. Paralellik ise bu işlerden birkaçının fiziksel olarak aynı anda yürütülmesidir. Tek çekirdekli bir işlemci görevler arasında hızla geçiş yaparak eşzamanlı olabilir; çok çekirdekli bir işlemciyse görevleri gerçekten paralel çalıştırabilir.

Bu ayrım önemlidir; fakat zihinsel bedelin ana kaynağı ikisinde de aynıdır: olası yürütme sıralarının çoğalması.

Olasılık ağacı neden hızla büyür?

İki iş parçacığının üçer atomik adımı olduğunu düşünelim. Her iş parçacığının kendi iç sırası korunurken adımlar farklı biçimlerde iç içe geçebilir. Olası sıralama sayısı kabaca kombinasyonla hesaplanır:

$a=3$ ve $b=3$ için $N=20$ olur. İş parçacığı ve adım sayısı arttıkça sayı patlar. Üstelik gerçek programlarda önbellek, işletim sistemi zamanlayıcısı, G/Ç gecikmesi ve bellek modeli de oyuna katılır. Programcı yalnızca “Kod ne yapıyor?” sorusunu değil, “Başka hangi sırayla yapabilir?” sorusunu da yanıtlamak zorundadır.

İnsan çalışma belleği sınırlıdır. Birkaç değişkenin değerini, kilitlerin durumunu ve iş parçacıklarının konumunu aynı anda zihinde tutmaya çalışmak bilişsel yükü artırır. Bu nedenle eşzamanlılık hataları çoğu zaman kodu yazarken değil, nadir bir zamanlama gerçekleştiğinde ortaya çıkar.

Klasik tuzak: yarış koşulu

Aşağıdaki Python örneğinde iki iş parçacığı aynı sayacı artırır:

import threading

counter = 0

def increment():
    global counter
    for _ in range(100_000):
        counter += 1  # Okuma, artırma ve yazma tek bir düşünsel adım değildir.

threads = [threading.Thread(target=increment) for _ in range(2)]
for thread in threads:
    thread.start()
for thread in threads:
    thread.join()

print(counter)

counter += 1 basit görünür; ancak kavramsal olarak değeri okuma, yeni değeri hesaplama ve geri yazma aşamalarından oluşur. İki iş parçacığı aynı eski değeri okuyabilir ve artışlardan biri kaybolabilir. Buna yarış koşulu denir: sonuç, işlemlerin zamanlamasına bağlıdır.

Bir kilit kritik bölgeyi koruyabilir:

lock = threading.Lock()

def safe_increment():
    global counter
    for _ in range(100_000):
        with lock:
            counter += 1  # Bu bölgeye aynı anda yalnızca bir iş parçacığı girer.

Kilidin bedeli yalnızca performans değildir. Programcı artık kilidin nerede alındığını, ne zaman bırakıldığını ve başka kilitlerle hangi sırada kullanıldığını da izlemelidir. Yanlış sıra, bu kez deadlock adlı “Herkes birbirini bekliyor” komedisine dönüşebilir.

Beyne uygun eşzamanlılık tasarlamak

En güvenli strateji, beynimizi daha fazla iş parçacığı düşünmeye zorlamak değil, düşünülmesi gereken durum sayısını azaltmaktır. Paylaşılan değişkenleri sınırlamak, saf fonksiyonlar kullanmak, görev sahipliğini açıkça belirtmek ve zaman aşımı tasarlamak kodu anlatılabilir hale getirir.

Sonuçta paralel programlama yalnızca işlemci çekirdeklerini yönetme sanatı değildir; olasılık uzayını insan zihninin taşıyabileceği boyuta indirme sanatıdır. İyi eşzamanlı kod, sadece hızlı çalışan değil, sabah kahvesinden önce bile hangi olayın kimi beklediği anlaşılabilen koddur.

İlk sırlar: Yerine koyma sanatı

Bilinen erken örneklerden biri, Antik Yunan’daki skytale yöntemidir. Bir deri şerit belirli kalınlıktaki sopaya sarılır, mesaj şeridin üzerine yazılırdı. Şerit açıldığında harfler anlamsız görünür; aynı çaptaki sopaya yeniden sarıldığında mesaj okunurdu. Bu yöntem, şifrelemenin yalnızca harflerle değil, fiziksel düzenle de yapılabileceğini gösteriyordu.

Roma dünyasında ise Jül Sezar’ın adıyla özdeşleşen Sezar şifresi kullanıldı. Mantık basitti: Alfabedeki her harf belirli miktarda kaydırılır. Harfleri sayılarla temsil edersek işlem şöyle yazılabilir:

Burada $x$ açık harfin konumu, $k$ gizli anahtar, $E(x)$ ise şifreli harftir. Çözme işlemi ters yönde ilerler:

Aşağıdaki Python kodu, İngiliz alfabesi üzerinde bu fikri uygular:

def caesar(text, shift):
    result = ""
    for char in text:
        if char.isalpha():
            base = ord("A") if char.isupper() else ord("a")
            result += chr((ord(char) - base + shift) % 26 + base)
        else:
            result += char
    return result

secret = caesar("Meet at dawn", 3)
print(secret)                 # Phhw dw gdzq
print(caesar(secret, -3))     # Meet at dawn

Kod, harfleri sayısal konumlarına dönüştürür ve modüler aritmetik sayesinde alfabenin sonundan başına döner. Eğlenceli bir deneydir; ancak yalnızca 26 olası kaydırma bulunduğundan gerçek güvenlik sağlamaz.

Şifre kırıcıların yükselişi

Dokuzuncu yüzyılda El-Kindî, harflerin kullanım sıklığını inceleyerek frekans analizini sistemleştirdi. Örneğin bir dilde en sık görülen şifreli sembolün, o dilin en yaygın harfini temsil etmesi muhtemeldi. Böylece kriptografi ile kriptoanaliz arasında bugün hâlâ süren bir yarış başladı.

Makineler, savaşlar ve modern matematik

İkinci Dünya Savaşı’nda Enigma, rotorları kullanarak her tuş vuruşunda farklı bir dönüşüm üretiyordu. Alan Turing ve Bletchley Park ekibinin çalışmaları, güçlü görünen sistemlerin bile matematik, mühendislik ve kullanıcı hatalarının birleşimiyle çözülebileceğini gösterdi.

1970’lerden sonra iki büyük yaklaşım belirginleşti. Simetrik şifrelemede aynı anahtar hem kilitlemek hem açmak için kullanılır; AES bunun hızlı ve yaygın örneğidir. Asimetrik şifrelemede ise açık ve özel anahtar çifti bulunur. RSA’nın güvenliği, büyük sayıların çarpanlarına ayrılmasının klasik bilgisayarlar için zor olmasına dayanır.

Kuantum sonrası yeni perde

Yeterince güçlü bir kuantum bilgisayar, Shor algoritmasıyla RSA ve eliptik eğri sistemlerini tehdit edebilir. Bu nedenle araştırmacılar; kafes tabanlı, kod tabanlı, özet tabanlı ve çok değişkenli yapılar üzerinde çalışıyor. NIST’in standartlaştırdığı ML-KEM gibi algoritmalar, kuantum saldırılarına karşı dayanıklı anahtar paylaşımını hedefliyor.

Bu geçiş yalnızca yeni algoritma kurmak değildir. Bugün ele geçirilen şifreli veriler gelecekte çözülebilir; buna “şimdi topla, sonra çöz” tehdidi denir. Dolayısıyla kuantum dirençli sistemlere geçiş, gelecekteki bir bilgisayarı beklemeden başlamalıdır.

Kil tabletlerden matematiksel kafeslere kadar şifreleme tarihi bize aynı dersi veriyor: Mutlak ve sonsuz güvenlik yoktur. Mahremiyet; iyi matematik, doğru uygulama, güvenli anahtar yönetimi ve değişen tehditlere uyum sağlama sanatıdır.

“Genel” kelimesi ne kadar genel?

Dar yapay zekâ belirli görevlerde uzmanlaşır: satranç oynar, yüz tanır veya metin üretir. AGI’den ise çoğunlukla farklı alanlarda öğrenmesi, bilgisini yeni durumlara aktarması ve daha önce görmediği problemleri çözmesi beklenir. Fakat bu tanım hemen yeni sorular üretir: Kaç farklı görev yeterlidir? İnsan seviyesindeki performans hangi insanla karşılaştırılacaktır? Bilinç gerekli midir?

Genelliği basitçe görevler üzerindeki ortalama başarı gibi yazabiliriz:

Burada $P_i$, sistemin $i$ görevindeki performansını; $w_i$ ise o görevin önemini temsil eder. Sorun şudur: Görevleri ve ağırlıkları seçen kişi, AGI tanımını da büyük ölçüde belirler. Matematik tarafsız görünür ama ölçüm tasarımı değildir.

Üç dünyanın üç farklı AGI’si

Bilimsel yaklaşım, tekrar üretilebilir deneyler ister. Bir sistem yeni bir dili az örnekle öğrenebiliyor, robot kontrolüne geçebiliyor ve planlarını hatalarına göre düzeltebiliyorsa “genel” davranış sergilediği söylenebilir. Ancak testlerde başarılı olmak, açık dünyada güvenilir olmakla aynı şey değildir.

Felsefi yaklaşım davranışın arkasına bakar. Bir model doğru cevap verdiğinde gerçekten kavram mı oluşturmuştur, yoksa devasa örüntüler arasında güçlü bir tahmin mi yapmıştır? İşlevselcilik için doğru ve esnek davranış yeterli olabilirken bilinç merkezli görüşler öznel deneyim arar. Ne yazık ki bilinci doğrulayacak evrensel bir unit_test() henüz bulunmuyor.

Pazarlama dili ise kesin eşiklerden hoşlanmaz. “AGI destekli” ifadesi, teknik ayrıntı vermeden yenilik ve gelecek hissi yaratır. Böylece kavram, bilimsel hipotezden marka vaadine dönüşebilir.

Tanımları kodla görünür kılmak

Aşağıdaki küçük Python örneği, farklı kurumların aynı sisteme neden farklı etiketler verebileceğini gösterir:

criteria = {
    "bilim": {"transfer": 0.4, "reasoning": 0.4, "autonomy": 0.2},
    "felsefe": {"transfer": 0.2, "reasoning": 0.3, "autonomy": 0.5},
    "pazarlama": {"transfer": 0.2, "reasoning": 0.2, "autonomy": 0.1,
                   "etki": 0.5}
}

system = {
    "transfer": 0.8,
    "reasoning": 0.75,
    "autonomy": 0.45,
    "etki": 0.95
}

for perspective, weights in criteria.items():
    score = sum(system[key] * weight for key, weight in weights.items())
    print(perspective, round(score, 2))

Kod, sistem özelliklerini farklı ağırlıklarla puanlar. Pazarlama yaklaşımı kullanıcı etkisine, felsefi yaklaşım ise özerkliğe daha fazla önem verdiği için sonuçlar değişir. Bu bir AGI testi değildir; ölçüt seçiminin sonucu nasıl yönlendirdiğini gösteren düşünce deneyidir.

Tek bir eşik yerine tanım kartı

“Bu sistem AGI mi?” sorusundan önce şu sorular sorulmalıdır:

• Hangi görev evreninde genellik aranıyor?
• Başarı eşiği ve insan karşılaştırma grubu nedir?
• Öğrenme, aktarım ve özerklik nasıl ölçülüyor?
• Bilinç veya niyet tanımın parçası mı?
• İddia bağımsız deneylerle doğrulandı mı?

AGI muhtemelen tek bir anda açılan sihirli başarı rozeti değildir. Daha çok yeteneklerin, toplumsal beklentilerin ve felsefi kabullerin birleştiği çok boyutlu bir spektrumdur. Bu nedenle sağlıklı tartışmanın ilk adımı, AGI’ye ulaşılıp ulaşılmadığını ilan etmek değil, kullanılan AGI tanımını açıkça masaya koymaktır.

``

Seçim yapmak, karar vermek midir?

En basit anlamıyla karar, seçenekler arasından birini belirlemektir. Bu tanım kullanılırsa termostat bile karar veriyor sayılabilir: Sıcaklık eşik değerin altındaysa ısıtıcıyı açar. Fakat burada alternatifleri değerlendiren bağımsız bir özne değil, önceden yazılmış bir koşul vardır.

Bir yapay zekâ ajanı ise çoğunlukla gözlem, iç durum, hedef ve eylem bileşenleriyle modellenir. Ajanın politikası şu şekilde gösterilebilir:

Burada $o_t$ gözlemi, $m_t$ belleği, $g$ hedefi ve $a_t$ seçilen eylemi temsil eder. Politika $\pi$, bu girdileri bir eyleme dönüştürür. Sistem öğreniyorsa politika sabit kurallardan değil, verilerle optimize edilmiş parametrelerden oluşabilir.

Tablo önemli bir ayrımı gösteriyor: Eylem seçimi, tek başına amaç seçimi değildir. Bir satranç motoru hamlesini belirleyebilir ama neden satranç oynadığını sorgulamaz.

Özerklik bir açma-kapama düğmesi değildir

Özerkliği ikili bir özellik yerine derece olarak düşünmek daha yararlıdır. Bir ajanın özerklik puanı kabaca şöyle modellenebilir:

Burada $E$ çevresel değişikliklere uyumu, $L$ öğrenme kapasitesini, $G$ hedef üretme yeteneğini, $R$ ise insan müdahalesi olmadan çalışma süresini ifade eder. Ağırlıklar kullanım alanına göre değişir. Örneğin bir Mars robotunda müdahalesiz çalışma, öneri algoritmasında ise hedeflerin kim tarafından belirlendiği daha önemli olabilir.

Aşağıdaki basitleştirilmiş ajan, çevresini değerlendirerek eylem seçer:

class Ajan:
    def __init__(self, enerji=100):
        self.enerji = enerji
        self.hedef = "veri_topla"

    def karar_ver(self, tehlike, veri_degeri):
        if tehlike > 0.8:
            return "geri_cekil"
        if self.enerji < 20:
            return "sarj_ol"
        if veri_degeri > 0.6:
            return "veri_topla"
        return "kesfet"

Bu kod farklı koşullarda farklı eylemler üretir; fakat hedefleri ve öncelikleri geliştirici tarafından belirlenmiştir. Dolayısıyla davranışsal özerklik vardır, güçlü anlamda amaçsal özerklik yoktur.

Peki niyet nerede başlar?

İnsan niyeti yalnızca sonuç üretmekten ibaret değildir. İnançlar, arzular, öz farkındalık ve “başka türlü davranabilirdim” düşüncesiyle ilişkilidir. Bugünkü ajanların “Dosyayı silmek istiyorum” demesi, çoğunlukla içsel bir isteğin kanıtı değil, dilsel bir çıktıdır.

Yine de niyet kavramını işlevsel biçimde kullanabiliriz. Bir sistem hedefini zaman boyunca koruyor, plan yapıyor, başarısızlıkta planını yeniliyor ve eylemlerini açıklayabiliyorsa ona niyet atfetmek tahmin yapmayı kolaylaştırır. Bu, sistemin bilinçli olduğunu değil, niyet diliyle verimli biçimde modellenebildiğini gösterir.

Sonuç olarak bir sistem, seçenekleri değerlendirip bağlama göre eylem seçtiğinde teknik anlamda karar veriyor sayılabilir. Ancak güçlü özerklik için yalnızca “nasıl” sorusunu değil, hedeflerin kaynağını açıklayan “neden” sorusunu da incelemeliyiz. Ajanlarımız giderek daha bağımsız davranabilir; yine de onların amaçları çoğu zaman insan tasarımının görünmez parmak izlerini taşır.

``

Bir model kararını nasıl verir?

Bir dil modeli, verilen metne bakarak sıradaki kelime veya parçacık için olasılık dağılımı üretir. Basitleştirilmiş biçimiyle modelin yaptığı işlem şöyledir:

Burada model, geçmiş parçacıklara göre sıradaki parçacığın olasılığını hesaplar. En yüksek olasılıklı seçeneği almak deterministik bir stratejidir. Aynı model, aynı girdi ve aynı çalışma koşulları altında genellikle aynı sonucu üretir.

Ancak “temperature” gibi örnekleme ayarları devreye girdiğinde farklı çıktılar görülebilir. Bu çeşitlilik özgür irade anlamına gelmez; yalnızca olasılıksal seçim mekanizmasının sonucudur. Zar atan bir makine şaşırtıcı davranabilir, fakat şaşırmak ile özgür olmak aynı şey değildir.

Determinizm küçük bir kodda

Aşağıdaki örnek, durumun belirli bir kurala göre güncellendiği basit bir sistemi gösterir:

def sonraki_durum(durum):
    # Mevcut değer, gelecekteki değeri tamamen belirler.
    return (durum * 3 + 1) % 10

x = 4
for _ in range(5):
    x = sonraki_durum(x)
    print(x)

Başlangıç değeri 4 olduğu sürece çıktı dizisi değişmez. Sistemin geleceği şu bağıntıyla belirlenmiştir:

Dil modelleri elbette bundan milyarlarca kat daha karmaşıktır. Yine de temel fikir benzerdir: Bir sonraki durum, önceki durumlar ve sistemin kuralları üzerinden oluşur. Gerçek donanımlarda paralel hesaplama, sayısal yuvarlama ve rastgele örnekleme sonuçları değiştirebilir; fakat öngörülemezlik tek başına irade kanıtı değildir.

İnsan beyni de bir model mi?

Katı determinizme göre insanın her düşüncesi; beynin önceki durumu, biyolojik yapısı ve çevresel etkiler tarafından belirlenir. Bu görüşte seçim hissimiz gerçek bir neden değil, karmaşık hesaplamaların bilinçte görünen yüzüdür. Laplace’ın ünlü varsayımını hatırlarsak, evrendeki tüm parçacıkların konumunu ve hızını bilen kusursuz bir gözlemci geleceği hesaplayabilir:

Buna karşılık kuantum belirsizliği veya beyindeki gürültü, geleceğin tam olarak hesaplanmasını engelleyebilir. Fakat rastgele oluşan bir düşünce de bize ait bilinçli bir seçim sayılmaz. Determinizm ile rastlantısallık arasındaki boşluğa doğrudan “özgür irade” yazmak bu nedenle kolay değildir.

Uyumculuk: Raylar üzerinde yön vermek

Uyumculuk, özgürlüğün nedensiz davranmak olmadığını savunur. Bir insan kendi arzuları, değerleri ve muhakemesi doğrultusunda hareket ediyorsa kararlarının nedenleri bulunsa bile özgür kabul edilebilir. Zorlama altında olmak ile karakterimizin etkisiyle karar vermek aynı değildir.

Yapay zekâ bu ayrımı görünür hâle getirir. Model seçenek üretebilir, gerekçe yazabilir ve davranışını düzeltebilir; ancak kendi amaçlarını deneyimlediğine dair kanıtımız yoktur. İnsan ise yalnızca çıktı üretmez: Acı hisseder, geleceği önemser, kararlarını sahiplenir ve toplumsal sonuçlarla yaşar.

Dolayısıyla deterministik yapay zekâ bize özgür iradenin cevabını vermiyor. Daha değerli bir şey yapıyor: “Tahmin edilemez davranış”, “seçim”, “bilinç” ve “sorumluluk” kavramlarını birbirinden ayırmaya zorluyor. Belki özgürlük, nedenlerden kaçmak değil; nedenlerimizi anlayıp onları dönüştürebilme kapasitesidir.

Ölçek yasası nedir?

Ölçek yasaları, bir modelin hata oranının model boyutu, veri miktarı ve hesaplama bütçesi arttıkça nasıl değiştiğini açıklayan deneysel ilişkilerdir. Dil modellerinde kayıp değerinin yaklaşık olarak bir kuvvet yasasına uyduğu gözlemlenir:

Burada $L(N)$, $N$ parametreli modelin kaybını; $L_{\infty}$ erişilebilecek teorik alt sınırı; $a$ ve $\alpha$ ise deneylerden öğrenilen sabitleri temsil eder. Denklemdeki kritik ayrıntı, getirinin giderek azalmasıdır. Parametre sayısını iki katına çıkarmak performansı iyileştirebilir, ancak modeli iki kat “akıllı” yapmaz.

Benzer ilişkiler veri miktarı $D$ ve eğitim hesaplaması $C$ için de kurulabilir:

Bu formül bir sihirli değnek değil, mühendislik pusulasıdır. Hangi kaynağa yatırım yapılırsa daha fazla kazanç elde edileceğini tahmin etmeye yardımcı olur.

Boyut tek başına neden yetmez?

Dev bir modeli yetersiz veriyle eğitmek, büyük bir kütüphaneyi aynı kitabın milyonlarca kopyasıyla doldurmaya benzer. Raflar etkileyicidir; bilgi çeşitliliği değildir. Chinchilla yaklaşımı olarak bilinen bulgular, belirli bir hesaplama bütçesinde daha küçük bir modeli daha fazla ve kaliteli veriyle eğitmenin, aşırı büyük fakat eksik eğitilmiş bir modeli geçebileceğini göstermiştir.

Yetenek gerçekten “ortaya” mı çıkıyor?

Bazı yeteneklerin belirli bir ölçekte aniden belirdiği söylenir. Buna emergent abilities, yani beliren yetenekler denir. Küçük model bir görevi yapamazken büyük model bir anda başarılı görünür. Ancak bu sıçrama bazen ölçüm yönteminden kaynaklanır. Başarı yalnızca “doğru” veya “yanlış” olarak puanlanırsa kademeli gelişim, keskin bir eşik gibi görünebilir.

Dolayısıyla ölçek, yeni yeteneklerin oluşmasını kolaylaştırabilir; fakat her sıçramayı gizemli bir zekâ patlaması olarak yorumlamak doğru değildir. Kullanılan test, istem biçimi ve puanlama yöntemi sonucu ciddi biçimde etkiler.

Basit bir ölçek hesabı

Aşağıdaki Python kodu, kuvvet yasasını kullanarak farklı model boyutları için tahmini kaybı hesaplar:

import math

def tahmini_kayip(parametre, alt_sinir=1.2, a=3.0, alfa=0.08):
    """Parametre sayısından yaklaşık eğitim kaybı üretir."""
    return alt_sinir + a * math.pow(parametre, -alfa)

boyutlar = [1e8, 1e9, 1e10, 1e11]

for boyut in boyutlar:
    kayip = tahmini_kayip(boyut)
    print(f"{boyut / 1e9:6.1f} milyar parametre -> {kayip:.3f}")

Kod gerçek bir modelin performansını kesin olarak tahmin etmez; azalan getiriyi görünür kılan basitleştirilmiş bir deneydir. Katsayılar model ailesine ve veri kümesine göre ölçülmelidir.

Büyük olmakla akıllı olmak arasındaki mesafe

Daha büyük modeller genellikle daha iyi dil üretir, daha fazla bilgiyi sıkıştırır ve örneklerden daha esnek biçimde öğrenir. Buna rağmen halüsinasyon, güncellik, nedensel akıl yürütme ve güvenilirlik sorunları yalnızca parametre eklenerek çözülmez. İyi veri, araç kullanımı, bilgi getirme sistemleri, ince ayar ve insan geri bildirimi çoğu zaman daha ekonomik ilerleme sağlar.

Sonuç olarak ölçek güçlü bir kaldıraçtır, zekânın tek ölçüsü değildir. En başarılı sistem, mutlaka en büyük model değil; boyut, veri, hesaplama ve kullanım maliyeti arasındaki dengeyi en iyi kuran modeldir.

``

Code review gerçekten yalnızca kodu mu inceler?

İdeal modelde incelemenin nesnesi kişiden bağımsız olarak değişikliktir. Reviewer; doğruluk, güvenlik, okunabilirlik ve bakım maliyetini değerlendirir. Fakat gerçek ekiplerde yorumun ağırlığı, kodun niteliği kadar onu yazanın konumundan da etkilenebilir.

Sosyolojide statü genellemesi, bir alandaki itibarın başka alanlardaki kararları da etkilemesini anlatır. Örneğin güçlü mimari bilgisiyle tanınan bir geliştiricinin frontend değişiklikleri de daha az sorgulanabilir. Böylece geçmiş başarı, bugünkü kod için görünmez bir güven kredisine dönüşür.

Bu ilişkiyi basitleştirilmiş biçimde şöyle düşünebiliriz:

Burada $Q_r$, review sırasında sorulan anlamlı soru sayısını; $L_c$ ise kod sahibinin ekip içindeki algılanan otorite seviyesini temsil etsin. $S$ değeri küçüldükçe sorgulama yoğunluğu azalır. Elbette insan ilişkileri tek formülle açıklanamaz; denklem yalnızca otorite yükseldikçe eleştirel incelemenin düşebileceği hipotezini görünür kılar.

Tablo bir suçlama listesi değildir. Aynı davranışın hem teknik hem sosyal nedenleri bulunabilir. Ama yalnızca teknik açıklamayı kabul etmek, ekibin kör noktalarını büyütür.

“LGTM” bir onaydan fazlası olabilir

Review yorumları nötr görünse de kullanılan dil hiyerarşiyi açığa çıkarır. Bir kişiye “Bunu neden böyle yaptın?” denirken diğerine “Burada farklı bir yaklaşım düşünülebilir mi?” denmesi, psikolojik güvenliğin eşit dağılmadığını gösterebilir. Ayrıca yöneticinin veya teknik liderin PR’ına ilk itiraz eden kişi olmak, bazı ekiplerde gereksiz bir kariyer riski gibi algılanır.

Bu örüntüyü görmek için basit metrikler üretilebilir:

reviews = [
    {"author": "junior", "comments": 12, "changed_lines": 40},
    {"author": "senior", "comments": 2, "changed_lines": 180},
]

for review in reviews:
    density = review["comments"] / max(review["changed_lines"], 1)
    print(review["author"], round(density, 3))

Kod, değiştirilen satır başına yorum yoğunluğunu hesaplar. Ancak yüksek yoğunluk otomatik olarak ayrımcılık kanıtı değildir. Değişikliğin riski, dosyanın karmaşıklığı ve yorumların niteliği de değerlendirilmelidir. Metrikler hüküm vermek için değil, doğru soruları başlatmak için kullanılmalıdır.

Daha dengeli bir review kültürü

İlk adım, kod sahibinin kimliğinden önce değişikliğin riskini değerlendiren ortak bir kontrol listesi oluşturmaktır. Güvenlik, test kapsamı, geriye dönük uyumluluk ve gözlemlenebilirlik gibi ölçütler herkes için aynı olmalıdır.

İkinci olarak ekipler, kıdemli geliştiricilerin PR’larında da alan uzmanı onayı aramalıdır. Kıdem, her konuda uzmanlık anlamına gelmez. Teknik liderlerin gelen eleştirilere açıkça teşekkür etmesi de itiraz etmenin güvenli olduğuna dair güçlü bir kültürel sinyal üretir.

Son olarak review başarısı, “kaç hata bulduk?” yerine “hangi bilgiyi paylaştık?” sorusuyla ölçülmelidir. İyi bir code review ne sorgusuz itaattir ne de satır satır üstünlük gösterisi. Amaç, otoritenin kodun önüne geçmediği ve herkesin gerekçesini açıklayabildiği ortak bir düşünme alanı kurmaktır.