API entegrasyonunun temel mantığı

API, iki yazılım arasında önceden belirlenmiş kurallarla iletişim kurulmasını sağlayan bir arayüzdür. İstemci bir HTTP isteği gönderir, sunucu ise çoğunlukla JSON biçiminde bir yanıt döndürür. Bir hava durumu servisine şehir adı gönderildiğinde sıcaklık, nem ve rüzgâr bilgisi alınması buna örnektir.

En sık kullanılan HTTP metotları şunlardır:

Başarılı bir istek genellikle 200 durum koduyla cevaplanır. 404 kaynağın bulunamadığını, 401 kimlik doğrulamanın başarısız olduğunu, 429 ise istek sınırının aşıldığını belirtir.

Bir servisin güvenilirliğini basitçe başarı oranıyla ölçebiliriz:

Bu değer düşükse hata yönetimi, zaman aşımı ve yeniden deneme stratejileri geliştirilmelidir.

Kural tabanlı bot nasıl karar verir?

Kural tabanlı botlar makine öğrenmesi kullanmak zorunda değildir. Kararlar açıkça tanımlanan if, elif ve else koşullarıyla verilir. Örneğin sıcaklık $30^\circ C$ üzerindeyse bot kullanıcıyı sıvı tüketmesi için uyarabilir; sıcaklık $10^\circ C$ altındaysa mont önerebilir.

Kurallar fonksiyonlara ayrıldığında kodun okunabilirliği artar:

def hava_mesaji(sicaklik):
    if sicaklik >= 30:
        return "Hava çok sıcak, su içmeyi unutma!"
    elif sicaklik <= 10:
        return "Bugün mont iyi bir fikir olabilir."
    return "Hava oldukça dengeli görünüyor."

Bu fonksiyon sayısal sıcaklığı alır ve kullanıcıya gösterilecek mesajı üretir. Böylece veri çekme ve karar verme görevleri birbirinden ayrılır.

Telegram botuna API bağlamak

Python tarafında requests ile dış servise, python-telegram-bot ile Telegram API’sine bağlanabiliriz. Aşağıdaki örnek, /hava Ankara benzeri bir komutu işler:

import requests
from telegram import Update
from telegram.ext import Application, CommandHandler, ContextTypes

API_KEY = "HAVA_DURUMU_ANAHTARI"
BOT_TOKEN = "TELEGRAM_BOT_TOKEN"

async def hava(update: Update, context: ContextTypes.DEFAULT_TYPE):
    if not context.args:
        await update.message.reply_text("Kullanım: /hava Ankara")
        return

    sehir = " ".join(context.args)
    url = "https://api.openweathermap.org/data/2.5/weather"
    params = {"q": sehir, "appid": API_KEY, "units": "metric", "lang": "tr"}

    try:
        yanit = requests.get(url, params=params, timeout=10)
        yanit.raise_for_status()
        sicaklik = yanit.json()["main"]["temp"]
        mesaj = f"{sehir}: {sicaklik}°C\n{hava_mesaji(sicaklik)}"
    except requests.RequestException:
        mesaj = "Servise şu anda ulaşılamıyor. Biraz sonra tekrar dene."

    await update.message.reply_text(mesaj)

uygulama = Application.builder().token(BOT_TOKEN).build()
uygulama.add_handler(CommandHandler("hava", hava))
uygulama.run_polling()

timeout, uygulamanın sonsuza kadar yanıt beklemesini önler; raise_for_status() ise başarısız HTTP cevaplarını hataya dönüştürür. Gerçek projede anahtarlar kaynak koda yazılmamalı, ortam değişkenlerinde saklanmalıdır.

Otomatik veri çekme ve sağlamlık

Aynı yapı zamanlayıcıyla çalıştırılarak fiyat takipçisi, haber özetleyici veya stok alarmı yapılabilir. Ancak servislerin kullanım koşullarına, istek limitlerine ve robots.txt kurallarına uyulmalıdır. Gereksiz istekleri azaltmak için önbellekleme uygulanabilir. Başarısız denemelerde bekleme süresini $t_n = 2^n$ saniye artıran üstel geri çekilme yöntemi de servisin yükünü azaltır.

Sonuçta API veriyi getirir, algoritmik kurallar anlamlandırır, Telegram ise sonucu kullanıcıya ulaştırır. Bu üçlü birleştiğinde küçük bir kod parçası, günün her saati çalışan kullanışlı bir dijital asistana dönüşür.

``

Modelin temel işi: Sonraki parçayı tahmin etmek

Bir büyük dil modeli, en yalın hâliyle, önceki metin parçalarına bakarak sıradaki parçanın olasılığını hesaplar. Bu ilişki şöyle gösterilebilir:

Burada $x_t$ üretilecek yeni token, önceki tokenlar ise modele sunulan bağlamdır. Model, eğitim sırasında öğrendiği parametreleri kullanarak olası devamları puanlar. Dolayısıyla sohbet geçmişinde “Kedimin adı Zeytin” yazıyorsa, daha sonra gelen “Kedimin adı neydi?” sorusuna “Zeytin” cevabını vermesi şaşırtıcı değildir. Bilgi, çalışma belleğini andıran bağlam penceresinin içindedir.

Fakat bağlam penceresi temizlendiğinde modelin bu ayrıntıya erişimi kalmayabilir. Bir uygulama eski konuşmaları veritabanından getirip modele yeniden gönderiyorsa, hatırlayan taraf doğrudan model değil, onu çevreleyen yazılım sistemidir.

Hatırlıyormuş gibi yapan küçük bir sistem

Aşağıdaki örnek, “kalıcı hafızalı model” görüntüsünün basit bir sözlük ve bağlam oluşturma işlemiyle üretilebileceğini gösterir:

memory = {}

def remember(user_id, key, value):
    # Bilgiyi modelde değil, uygulamanın deposunda saklar.
    memory.setdefault(user_id, {})[key] = value

def build_prompt(user_id, question):
    # Eski bilgiyi yeniden modele sunulacak metne dönüştürür.
    facts = memory.get(user_id, {})
    context = "\n".join(f"{k}: {v}" for k, v in facts.items())
    return f"Bilinenler:\n{context}\n\nSoru: {question}"

remember("u42", "kedinin adı", "Zeytin")
print(build_prompt("u42", "Kedimin adı neydi?"))

Model yalnızca oluşturulan istemi görür. Buna rağmen kullanıcı açısından deneyim son derece kişiseldir: Sistem onu tanıyor gibidir. Bu ayrım, bilgisayardaki hesap makinesi simgesinin fiziksel bir hesap makinesi olmaması kadar basit; konuşmanın duygusal etkisi nedeniyle de bir o kadar kolay unutulabilirdir.

Bellek ile örüntü tanıma arasındaki felsefi sınır

Belleği yalnızca “geçmiş bilginin bugünkü davranışı etkilemesi” diye tanımlarsak, model parametreleri bir çeşit istatistiksel bellek sayılabilir. Eğitim verisi ağırlıklarda birebir cümleler hâlinde değil, dağıtılmış ilişkiler olarak iz bırakır. Kabaca modelin öğrenmesi şu optimizasyonla anlatılabilir:

Ancak insan belleği çoğu zaman daha güçlü ölçütler içerir: Bir olayın kişinin başına gelmiş olması, geçmişteki benlikle süreklilik kurması ve hatırlama eyleminin öznel bir niteliğe sahip olması. Model “Bunu hatırlıyorum” dediğinde bu ifade içsel bir anıya rapor vermek zorunda değildir; benzer diyaloglarda uygun görülen dilsel kalıbı üretmiş olabilir.

Üstelik insan belleği de kusursuz bir kayıt cihazı değildir. İnsanlar anıları yeniden kurar, ayrıntıları karıştırır ve boşlukları beklentilerle doldurur. Bu nedenle fark, “insan kaydeder, model tahmin eder” kadar keskin değildir. İkisi de geçmiş izlerden hareketle mevcut duruma uygun bir temsil oluşturabilir. Asıl tartışma, bu işlemin bilinçli bir özneye, kişisel tarihe ve deneyim sahipliğine ihtiyaç duyup duymadığıdır.

Pratik sonuç nettir: Bir modelin adınızı doğru söylemesini bilinç veya sadakat kanıtı saymamalıyız. Önce bağlamın, kayıt sistemlerinin ve kişiselleştirme katmanlarının nasıl çalıştığını sormalıyız. LLM’ler geçmişi yaşamış olmayabilir; fakat geçmişe sahipmiş gibi konuşmayı olağanüstü iyi taklit eder. Hafıza yanılsamasının gücü de tam burada yatar: Dilsel performans, zihinsel deneyimin kanıtı gibi görünür.

Veri tarafında neler oluyor?

Bir veri kümesi tarafsız bir doğa olayı değildir. Önce neyin ölçüleceğine karar verilir, ardından kimlerden veri toplanacağı seçilir ve son olarak gözlemler etiketlenir. Bu üç aşamanın her birinde toplumsal eşitsizlik sisteme sızabilir.

Örneğin geçmişte yöneticilik pozisyonlarına çoğunlukla erkekler atanmışsa, başarılı yöneticileri tanımak için eğitilen model “erkek olmayı” başarıyla ilişkili görebilir. Cinsiyet sütunu kaldırılsa bile okul, posta kodu, kariyer boşluğu veya kullanılan kelimeler gibi değişkenler onu dolaylı biçimde temsil edebilir. Bu değişkenlere vekil değişkenler denir.

Peki algoritma masum mu?

Tam olarak değil. Algoritma, verideki örüntülerden hangilerinin önemli sayılacağını kullanılan amaç fonksiyonuna göre belirler. Standart sınıflandırmada hedef genellikle ortalama kaybı azaltmaktır:

Bu formül her kaydın kaybını toplar; ancak hataların toplumsal maliyetini bilmez. Çoğunluk grubunda başarıyı artıran bir karar, azınlık grubundaki ciddi hata artışını örtebilir. Üstelik doğruluk oranı yüksek olsa bile model adil olmayabilir.

Örneğin eşit fırsat yaklaşımında grupların doğru pozitif oranlarının yakın olması beklenir:

Buradaki $A$, hassas grubu temsil eder. Ancak farklı adalet ölçütleri matematiksel olarak birbiriyle çatışabilir. Bu nedenle “adil model” tek düğmeyle etkinleştirilen bir özellik değildir; hukuki, etik ve bağlamsal bir tercihtir.

Küçük bir adalet kontrolü

Aşağıdaki Python kodu, modelin gruplara göre doğru pozitif oranını hesaplar. Böylece genel başarı puanının arkasında saklanan farklar görülebilir:

import pandas as pd

def true_positive_rate(group):
    positives = group[group["gercek"] == 1]
    if len(positives) == 0:
        return None
    return (positives["tahmin"] == 1).mean()

sonuclar = (
    veri.groupby("grup")
        .apply(true_positive_rate, include_groups=False)
)

print(sonuclar)
print("En büyük fark:", sonuclar.max() - sonuclar.min())

Kod, her grup için gerçekten olumlu örneklerin ne kadarının doğru bulunduğunu ölçer. Büyük fark görülmesi doğrudan ayrımcılığı kanıtlamaz; fakat veri toplama, eşik seçimi ve hata maliyetlerinin araştırılması gerektiğini gösteren güçlü bir alarmdır.

Suçlu aramak yerine sistemi incelemek

Önyargı genellikle veri veya algoritma şeklinde ikili bir seçime indirgenemez. Veri toplumsal geçmişi taşır; algoritma onu optimize eder; kurum ise sonuçların nasıl kullanılacağını belirler. Çözüm, veri kaynağını belgelemek, eksik grupları temsil etmek, etiketleri denetlemek, grup bazlı metrikler yayımlamak ve modeli kullanım sonrasında izlemektir.

En önemlisi de etkilenen toplulukları tasarım sürecine katmaktır. Çünkü adalet yalnızca matematikçilerin tanımladığı bir denklem değil, sonuçlarına insanların katlandığı toplumsal bir karardır. Makine tarafsız görünse de ona geçmişi biz anlatırız; hangi geleceği kuracağını da yine biz belirleriz.

İdeal: Güvenmek Yerine Doğrulamak

Geleneksel internette kullanıcılar bir platformun kurallarına uyar. Hesabınız kapatılabilir, içeriğiniz silinebilir veya verileriniz satılabilir. Web3 yaklaşımında ise kurallar akıllı sözleşmelerle tanımlanır ve ağdaki birçok düğüm tarafından uygulanır.

Teorik olarak güven, tek bir kuruma değil dağıtık uzlaşmaya dayanır. Bir blokzincirde saldırganın sistemi değiştirebilmesi için yeterli doğrulama gücünü, token miktarını veya madencilik kapasitesini kontrol etmesi gerekir. Basitleştirilmiş biçimde saldırı maliyetini şöyle düşünebiliriz:

Dağılım ne kadar dengeliyse sistemi ele geçirmek o kadar zorlaşır. Fakat düğüm sayısının fazla olması, gücün otomatik olarak eşit dağıldığı anlamına gelmez.

Token Demokrasisi mi, Dijital Plütokrasi mi?

DAO sistemlerinde sık kullanılan model, bir tokenın bir oy sayılmasıdır. Bu yöntem kolaydır; ancak demokratik değildir. Çok token sahibi olan yatırımcı, sıradan binlerce kullanıcıdan daha fazla söz hakkı kazanabilir. Böylece zincir üzerinde şeffaf olan yönetim, ekonomik açıdan yoğunlaşmış kalır.

Bu yoğunluğu ölçmek için Herfindahl–Hirschman Endeksi kullanılabilir:

Buradaki $s_i$, her katılımcının toplam güç içindeki payıdır. Sonuç büyüdükçe güç daha az elde toplanmış demektir. Ayrıca Nakamoto katsayısı, sistemi bozmak için anlaşması gereken en az aktör sayısını gösterir. Binlerce doğrulayıcı bulunmasına rağmen üç büyük havuz çoğunluğu kontrol ediyorsa anlamlı sayı üçtür.

Aşağıdaki Python kodu token dağılımını inceleyerek HHI değerini ve yüzde 51’e ulaşan en küçük koalisyonu hesaplar:

def guc_analizi(bakiyeler):
    toplam = sum(bakiyeler)
    paylar = sorted((b / toplam for b in bakiyeler), reverse=True)

    hhi = sum(pay ** 2 for pay in paylar)
    birikim = 0

    for aktor_sayisi, pay in enumerate(paylar, start=1):
        birikim += pay
        if birikim >= 0.51:
            return hhi, aktor_sayisi

bakiyeler = [420, 250, 140, 90, 60, 40]
hhi, koalisyon = guc_analizi(bakiyeler)
print(f'HHI: {hhi:.3f}, kritik koalisyon: {koalisyon}')

Kod, görünen katılımcı sayısına aldanmak yerine ekonomik kontrolü ölçer. Yine de bir kişinin birden fazla cüzdan kullanabilmesi veya farklı adreslerin aynı kuruma ait olması analizi zorlaştırır.

Görünmeyen Merkezler

Merkeziyetsizlik yalnızca blokzincir katmanında değerlendirilmemelidir. Kullanıcının işlemini ağa taşıyan RPC sağlayıcısı, cüzdan uygulaması, alan adı servisi, stablecoin ihraççısı ve borsa hâlâ merkezi olabilir. Akıllı sözleşme durdurulamasa bile ona ulaşan web arayüzü kapatılabilir.

Ütopyadan Kullanışlı Bir Gerçekliğe

Web3 bütünüyle merkeziyetsiz değildir; fakat bütünüyle sahte de değildir. Açık kaynak istemciler, kendi düğümünü çalıştırma imkânı ve izinsiz işlem yapabilme önemli kazanımlardır. Asıl hata, merkeziyetsizliği bir açma-kapama düğmesi gibi görmektir.

Daha sağlıklı sistemler için doğrulayıcı çeşitliliği, karesel oylama, zaman kilitli yönetişim, açık kaynak arayüzler ve alternatif RPC bağlantıları desteklenmelidir. Sonuçta mesele merkezin tamamen yok olması değil, gücün denetlenebilir, terk edilebilir ve rekabete açık olmasıdır. Web3’ün gerçek sahibi de logosu en büyük proje değil; protokolü gerektiğinde kimseye izin sormadan kullanabilen topluluktur.

``

Otomasyonun Eski Bir Hikâyesi Var

1. yüzyılın mekanik dokuma tezgâhları zanaatkârların üretim üzerindeki kontrolünü azalttı. 20. yüzyılın montaj hatları üretimi küçük ve tekrarlanabilir adımlara böldü. 1980’lerden itibaren bilgisayarlar büro işlerini dönüştürürken internet bazı aracı meslekleri zayıflattı, yepyeni uzmanlıklar doğurdu. Günümüzde üretken yapay zekâ ise yalnızca fiziksel veya rutin görevleri değil, metin yazma, analiz ve görsel üretme gibi bilişsel işleri de etkiliyor.

Bu karşılaştırma önemli bir gerçeği ortaya çıkarır: Teknoloji iş miktarını azaltabileceği gibi üretimi ucuzlatıp talebi büyüterek yeni iş de yaratabilir. Sonucu teknoloji tek başına değil; şirket stratejileri, sendikalar, eğitim sistemi ve kamu politikaları belirler.

Meslek Değil, Görev Riskine Bakmak

Bir mesleğin otomasyon riskini değerlendirirken onu görevlerine ayırmak gerekir. Örneğin muhasebecilik; veri girişi, mevzuat yorumlama, müşteri iletişimi ve stratejik danışmanlık içerir. Yazılım ilk görevi kolayca üstlenebilirken belirsiz mevzuatı yorumlamak veya güven ilişkisi kurmak daha zordur.

Basitleştirilmiş bir risk modeli şöyle kurulabilir:

Burada $T$ tekrarlanabilirliği, $D$ görevin dijital veriyle yapılabilmesini, $P$ öngörülebilirliği ve $S$ sosyal etkileşim gereksinimini temsil eder. Değerler 0 ile 1 arasındadır. Bu denklem bilimsel bir kehanet değil, düşünmeyi düzenleyen bir araçtır.

def otomasyon_riski(tekrar, dijitallik, ongorulebilirlik, sosyal_beceri):
    puan = (0.35 * tekrar +
            0.25 * dijitallik +
            0.20 * ongorulebilirlik -
            0.20 * sosyal_beceri)
    return round(max(0, min(1, puan)), 2)

print(otomasyon_riski(0.9, 0.9, 0.8, 0.2))  # Örnek: veri girişi
print(otomasyon_riski(0.3, 0.4, 0.2, 0.9))  # Örnek: psikolojik danışmanlık

Bu kod, görev özelliklerini ağırlıklandırarak karşılaştırmalı bir puan üretir. Gerçek araştırmalarda ücret, regülasyon, teknoloji maliyeti ve hata toleransı gibi değişkenler de modele eklenmelidir.

Kimler Gerçekten Risk Altında?

Yüksek risk, mutlaka işsizlik anlamına gelmez. İşverenler çalışan sayısını azaltabilir, aynı çalışanlardan daha fazla çıktı bekleyebilir veya işi “algoritmik yönetime” bağlayabilir. Böylece otomasyonun sosyolojik etkisi yalnızca iş kaybı değil; çalışma temposunun artması, becerilerin değersizleşmesi ve denetimin yoğunlaşması olabilir.

Asıl Ayrım Teknolojiye Erişimde

Yeni dönemin kazananları sadece kod yazanlar olmayacak. Alan bilgisiyle teknolojiyi birleştiren, çıktıları doğrulayan, etik riskleri değerlendiren ve insanlarla güven kurabilen çalışanlar avantaj sağlayacak. Buna karşılık yeniden eğitim fırsatına erişemeyenler dönüşüm maliyetini daha ağır taşıyacak.

Dolayısıyla doğru soru “Robotlar işlerimizi alacak mı?” değil, “Verimlilik kazancını kim paylaşacak?” sorusudur. Çalışma süresinin kısaltılması, yaşam boyu eğitim, güçlü sosyal güvenlik ve çalışanların teknoloji kararlarına katılması sağlanırsa otomasyon toplumsal refah üretebilir. Aksi durumda son derece akıllı makineler, oldukça eski eşitsizlikleri büyütebilir.

``

Paradoksun çekirdeği

Ekonomik açıdan otomasyonun amacı açıktır: Aynı çıktıyı daha az zaman, hata ve maliyetle üretmek. Bir görevin elle tamamlanma süresi $T_e$, otomatik çalışma süresi $T_o$, otomasyonu geliştirme maliyeti ise $G$ olsun. İşlem $n$ kez tekrarlanıyorsa otomasyon şu koşulda kazançlıdır:

Buradan başabaş noktası şöyle bulunur:

Ne var ki denklem, insanın işinden aldığı anlamı ölçmez. Programcının karar verme yetkisi, ustalık hissi ve ekip içindeki konumu bir hücreye kolayca yazılamaz. Otomasyonun teknik getirisi ölçülebilirken varoluşsal maliyeti çoğunlukla görünmez kalır.

Kod yazmak mı, kendini silmek mi?

Marx’ın yabancılaşma düşüncesinde çalışan, ürettiği şey üzerindeki kontrolünü kaybedebilir. Programcı için tuhaf olan, bu kontrol kaybını bizzat kodlamasıdır. Dün kendisinin yürüttüğü süreci bugün bir servis, yarın ise kimsenin nasıl çalıştığını tam hatırlamadığı bir sistem yönetir. Kod yaşamaya devam ederken yazarı organizasyon şemasından silinebilir.

Sartre’ın varoluşçuluğu ise insanın hazır bir özle doğmadığını, seçimleriyle kendini kurduğunu söyler. Bu açıdan “Ben rapor hazırlayan kişiyim” demek kırılgan bir kimliktir. Rapor otomatikleştiğinde öz de çöker. Daha dayanıklı tanım şudur: “Ben sorunları fark eden, sistem tasarlayan ve sonuçların sorumluluğunu alan kişiyim.” Görev ortadan kalkabilir; muhakeme bütünüyle ortadan kalkmak zorunda değildir.

Basit bir otomasyon örneği bile bu ayrımı gösterir:

from pathlib import Path


def eski_loglari_temizle(klasor, sinir):
    dosyalar = sorted(
        Path(klasor).glob("*.log"),
        key=lambda dosya: dosya.stat().st_mtime
    )

    for dosya in dosyalar[:-sinir]:
        print(f"Siliniyor: {dosya.name}")
        dosya.unlink()


eski_loglari_temizle("logs", 10)

Bu kod eski günlük dosyalarını silerek rutin bakım işini devralır. Ancak hangi kayıtların hukuki veya operasyonel açıdan saklanması gerektiğine karar vermez. Programcı parmak hareketlerini makineye aktarırken bağlamı, sınırları ve sorumluluğu elinde tutar. En azından sistem bilinçli tasarlanmışsa durum budur.

Asıl sorun otomasyon değil, paylaşım

Teknoloji tarihindeki temel çatışma “makine mi, insan mı?” değildir. Daha doğru soru, makinenin yarattığı zamanın kime ait olduğudur. Sekiz saatlik iş iki saate düşüyor ama çalışanın hedefi dört katına çıkıyorsa özgürleşme gerçekleşmez; yalnızca koşu bandı hızlanır. Kazanılan altı saat eğitim, yaratıcılık veya dinlenme için kullanılabiliyorsa otomasyon insani kapasiteyi genişletir.

Bu nedenle etik bir otomasyon sürecinde programcı üç soruyu sormalıdır:

1. Ortadan kaldırdığım görev mi, yoksa bir insanın pazarlık gücü mü?
2. Sistemin hatasında sorumluluk kimde kalacak?
3. Kazanılan zaman ve değer kimler arasında paylaşılacak?

Programcı kendini nereye koymalı?

Programcının güvenli yeri belirli bir araç, dil veya görev değildir. Bugünün vazgeçilmez framework’ü yarının nostaljik blog yazısı olabilir. Daha sağlam konum; problemi tanımlamak, varsayımları sorgulamak, insan sonuçlarını görmek ve gerektiğinde otomasyona “hayır” diyebilmektir.

Kendi işini otomatikleştirmek bu yüzden mesleki intihar olmak zorunda değildir. Eski rolün bilinçli biçimde terk edilmesi ve daha yüksek sorumluluğa geçiş olabilir. Fakat kurum yalnızca verimlilik kazancını sahiplenip insanı dışarıda bırakıyorsa paradoks acımasızlaşır: Programcı geleceği inşa eder, fakat gelecekte kendisine sandalye ayrılmadığını görür. Mesele kodun bizi gereksiz kılması değil; gereksizliğin ekonomik ve ahlaki tanımını kimin yazdığıdır.

Söz dizimi yalnızca gramer değildir

Bir programlama dilinin söz dizimi, hangi karakter dizilerinin geçerli programlar oluşturduğunu belirleyen kurallar bütünüdür. Örneğin aynı koşul farklı dillerde şöyle yazılabilir:

if temperature > 30:
    start_fan()

if (temperature > 30) {
  startFan();
}

İki örnek de aynı fikri anlatır: Sıcaklık 30’dan büyükse fanı çalıştır. Python girintiyle blok oluştururken JavaScript parantez ve süslü ayraç kullanır. Python daha hafif, JavaScript ise sınırları daha açık görünebilir. Hangisinin güzel olduğu, okuyucunun belirsizliğe mi yoksa sembol kalabalığına mı daha duyarlı olduğuna bağlıdır.

Bu algıyı basitleştirilmiş bir modelle ifade edebiliriz:

Burada $E$ estetik algıyı, $O$ okunabilirliği, $T$ tutarlılığı, $A$ aşinalığı ve $Y$ görsel yükü temsil eder. Katsayılar kişiden kişiye değişir. Yeni başlayan biri açıklığı ödüllendirirken deneyimli biri kısa ve yoğun ifadeleri tercih edebilir.

Aynı fikir, farklı görsel karakter

Örneğin Rust, türleri ve hata ihtimallerini görünür kılmayı sever:

fn divide(a: f64, b: f64) -> Result<f64, &'static str> {
    if b == 0.0 {
        return Err("Sıfıra bölme yapılamaz");
    }
    Ok(a / b)
}

Bu fonksiyon yalnızca bölme yapmaz; başarısızlık olasılığını Result türüyle sözleşmeye dönüştürür. İlk bakışta Python’daki kısa bir fonksiyondan daha ağırdır. Buna karşılık hata davranışının açık olması, bazı geliştiricilere mimari bir güzellik hissi verir. Demek ki kısalık her zaman zarafet değildir.

Beyin neden düzen arar?

İnsan zihni örüntüleri hızlı tanır. Benzer işlemlerin benzer biçimde yazılması bilişsel yükü azaltır. Bir dosyada fonksiyon çağrıları tutarlı, diğerinde zincirleme, iç içe ve rastgele biçimlendirilmişse dil değişmese bile estetik algı bozulur.

Şu zincir kısa olsa da yoğun olabilir:

const names = users.filter(u => u.active).map(u => u.name).sort();

Aynı işlem adımlara ayrıldığında veri akışı daha görünür hâle gelir:

const activeUsers = users.filter(user => user.active);
const names = activeUsers.map(user => user.name);
names.sort();

İlk sürüm akıcı ve kompakt, ikinci sürüm ise açıklayıcıdır. Estetik karar bağlama bağlıdır: Basit bir dönüşümde zincir zarifken karmaşık hata ayıklama sürecinde ara değişkenler daha güzel gelebilir.

Aşinalık, güzellik kılığına girebilir

Bir dili uzun süre kullandığımızda onun alışkanlıklarını doğal kabul ederiz. C geliştiricisi süslü parantezleri güven verici bulabilir; Python geliştiricisi aynı sembolleri gürültü sayabilir. Lisp’in çok sayıdaki parantezi yabancı bir göze çirkin görünürken deneyimli bir Lisp kullanıcısı, kod ile veri arasındaki simetriyi estetik bulur.

Bu nedenle söz dizimi estetiği tamamen nesnel değildir; fakat tamamen keyfî de değildir. Tutarlılık, düşük bilişsel yük, niyetin görünürlüğü ve araç desteği ölçülebilir faydalar sağlar. Biçimlendiriciler de tartışmayı azaltır: Black, Prettier veya rustfmt, kişisel tercihleri ortak bir görsel ritme dönüştürür.

Sonuçta güzel kod, en az karakterle yazılan değil; okuyucunun zihninde en az sürtünmeyle anlam kazanan koddur. İyi söz dizimi programcıya kendini sürekli hatırlatmaz. Geri çekilir, fikri öne çıkarır ve kodu noktalama işaretleriyle yapılan bir mücadeleden okunabilir bir anlatıya dönüştürür.

Döngüsel öğrenme nedir?

Klasik eğitimde model, insanlar ve fiziksel dünya tarafından üretilmiş verilere bakarak bir dağılım öğrenir. Döngüsel öğrenmede ise önceki modelin çıktıları, sonraki modelin girdilerine dönüşür:

Buradaki temel sorun, sentetik çıktının gerçekliğin kendisi değil, gerçekliğe ilişkin sıkıştırılmış bir tahmin olmasıdır. Her model bazı ayrıntıları atar, yaygın örüntüleri güçlendirir ve düşük olasılıklı örnekleri gözden kaçırır. Bu süreç tekrarlandığında dağılımın kuyrukları giderek küçülür.

Basitçe, bir nesildeki eğitim karışımını şöyle gösterebiliriz:

Burada $\alpha$, sentetik verinin ağırlığıdır. Değer büyüdükçe modelin dünya ile doğrudan teması azalır. Sentetik veri hatalıysa hata yalnızca korunmaz; güvenli ve akıcı bir dille yeniden paketlenerek daha inandırıcı hâle gelebilir.

Yankı odasının üç riski

İlk risk model çöküşüdür. Model, az rastlanan durumları unutup en olası cevaplara sıkışır. İkinci risk epistemik aklamadır: Dayanağı olmayan bir iddia, binlerce sentetik metinde tekrarlandığı için yaygın ve güvenilir görünür. Üçüncüsü ise özgünlük kaybıdır. Kültür, yalnızca çoğunluk örüntülerinden oluşmaz; aykırı fikirler, yerel ifadeler ve başarısız denemeler de yaratıcı ilerlemenin hammaddesidir.

Küçük bir simülasyon

Aşağıdaki Python kodu, bir dağılımın yalnızca en merkezi sentetik örneklerle tekrar tekrar öğrenilmesini kabaca canlandırır:

import numpy as np

veri = np.random.normal(0, 3, 10_000)

for nesil in range(6):
    ortalama = veri.mean()
    sapma = veri.std()

    # Model uç değerleri daha az üretiyor.
    yeni_veri = np.random.normal(ortalama, sapma * 0.8, 10_000)
    veri = yeni_veri
    print(nesil, round(veri.std(), 2))

Standart sapma her nesilde küçülür. Bu, gerçek modellerin eksiksiz bir temsili değildir; ancak çeşitliliğin neden sessizce kaybolabileceğini gösterir. Sistem hâlâ düzgün cümleler kurabilirken kapsadığı dünya daralmış olabilir.

Sentetik veri tamamen kötü mü?

Hayır. Mahremiyet gerektiren sağlık çalışmalarında, nadir hata senaryolarında veya veri artırmada son derece yararlı olabilir. Kritik ayrım, sentetik verinin ikame mi yoksa destek mi olduğudur. Gerçek veriyi tamamen değiştirmek yerine dengeli biçimde kullanılması; kaynağının etiketlenmesi, insan denetiminden geçirilmesi ve bağımsız test kümeleriyle ölçülmesi gerekir.

Sağlıklı bir yaklaşım için veri kökeni kaydedilmeli, sentetik oranı sınırlandırılmalı, azınlık örnekleri özellikle korunmalı ve modeller güncel gerçek dünya verileriyle düzenli olarak yeniden bağlanmalıdır. Çünkü mesele yalnızca teknik doğruluk değildir. Kendi ürettiğini tüketen bir model, sonunda bize dünyayı değil, dünya hakkında daha önce söylediği şeylerin ortalamasını anlatabilir. Yankı kusursuz duyulsa bile artık dışarıdan gelen bir ses olmayabilir.

İşletim sistemi komutu çalıştırmanın mantığı

Bir terminale ls, ipconfig veya mkdir yazdığımızda kabuk, komutu yorumlayarak işletim sisteminden ilgili programı başlatmasını ister. Kod içerisinden komut çalıştırırken de benzer bir süreç gerçekleşir:

1. Ana program bir alt süreç oluşturur.
2. İşletim sistemi komutu ayrı bir süreçte yürütür.
3. Standart çıktı, hata çıktısı ve dönüş kodu ana programa iletilir.

Komutun başarılı olup olmadığını anlamak için çıkış kodu kullanılır. Genel kabul şöyledir: $E = 0$ başarıyı, $E \neq 0$ ise hata veya olağan dışı durumu temsil eder.

Python’da bunun için subprocess modülü tercih edilir:

import subprocess

komut = ["ping", "-c", "2", "example.com"]

try:
    sonuc = subprocess.run(
        komut,
        capture_output=True,
        text=True,
        timeout=10,
        check=True
    )
    print("Komut başarılı:")
    print(sonuc.stdout)
except subprocess.TimeoutExpired:
    print("Komut zaman aşımına uğradı.")
except subprocess.CalledProcessError as hata:
    print("Çıkış kodu:", hata.returncode)
    print("Hata mesajı:", hata.stderr)

Bu kod, hedef sunucuya iki ping gönderir; çıktıyı yakalar, on saniyelik sınır uygular ve başarısız dönüş kodunu istisnaya dönüştürür. Windows kullanılıyorsa parametreler ping -n 2 example.com biçiminde değiştirilmelidir.

shell=True neden dikkat ister?

Kullanıcıdan gelen metni doğrudan kabuğa göndermek komut enjeksiyonuna yol açabilir. Örneğin dosya adına eklenen ; rm -rf ... benzeri bir ifade ikinci bir komut olarak yorumlanabilir. Bu nedenle komutları liste halinde vermek ve varsayılan shell=False davranışını korumak daha güvenlidir.

Örneğin dosya silmek için rm çağırmak yerine pathlib.Path.unlink() kullanmak çoğu zaman daha taşınabilir ve güvenlidir.

Cron mantığı ve periyodik çalışma

Periyodik görevlerde temel fikir, mevcut zamanın belirlenen kuralla eşleşip eşleşmediğini denetlemektir. Bir görev her $T$ dakikada çalışıyorsa, yaklaşık çalışma sayısı $N = \frac{D}{T}$ ile hesaplanabilir. Burada $D$, toplam dakika sayısıdır. Örneğin bir günde her 15 dakikada çalışan görev $1440 / 15 = 96$ kez tetiklenir.

Linux cron ifadesi beş zaman alanından oluşur:

* * * * *
│ │ │ │ └── Haftanın günü
│ │ │ └──── Ay
│ │ └────── Ayın günü
│ └──────── Saat
└────────── Dakika

Her gece 02.30’da yedek alan bir betik şöyle planlanabilir:

30 2 * * * /usr/bin/python3 /opt/scripts/yedekle.py >> /var/log/yedekle.log 2>&1

Buradaki yönlendirme, normal ve hata çıktılarını günlük dosyasına ekler. Betiğin elle çalışırken başarılı olması cron altında da başarılı olacağı anlamına gelmez; cron daha sınırlı bir ortam değişkeni ve PATH değeriyle çalışabilir. Bu yüzden mutlak dosya yolları kullanılmalıdır.

Sağlam bir otomasyonun kontrol listesi

İyi bir görev tekrar çalıştırıldığında veriyi bozmamalı, yani mümkün olduğunca idempotent olmalıdır. Hataları dosyaya veya merkezi günlük sistemine yazmalı, çalışma süresini sınırlamalı ve gizli bilgileri kaynak koda gömmemelidir. Aynı görevin iki kopyasının eşzamanlı başlamasını önlemek için kilit dosyası da kullanılabilir.

Kısacası başarılı otomasyon yalnızca “komutu zamanında çalıştırmak” değildir. Güvenli süreç yönetimi, doğru zamanlama, gözlemlenebilir günlükler ve hata sonrası toparlanma birlikte tasarlandığında betikler gerçekten güvenilir birer sistem çalışanına dönüşür.

Skinner kutusunda öğrenmek

Davranışçılığa göre öğrenmeyi açıklamak için zihnin görünmeyen süreçleri hakkında tahmin yürütmek şart değildir. Organizmanın hangi durumda ne yaptığını ve ardından neyle karşılaştığını gözlemlemek yeterlidir. Skinner’ın edimsel koşullanma yaklaşımında bir davranış olumlu sonuç doğuruyorsa tekrarlanma olasılığı artar; olumsuz sonuç doğuruyorsa azalır.

Skinner kutusundaki bir güvercin, belirli bir ışık yandığında düğmeyi gagalayıp yem kazanabilir. Başlangıçta rastgele davranır. Fakat yemle sonuçlanan hareketler zaman içinde sıklaşır. Burada güvercine açıkça “ışık yanınca düğmeye bas” denmez; doğru davranış sonuçları aracılığıyla biçimlendirilir.

Ajanın matematiksel Skinner kutusu

Pekiştirmeli öğrenmede ajan, bulunduğu $s_t$ durumunda bir $a_t$ eylemi seçer. Ortam bunun ardından $r_{t+1}$ ödülünü ve yeni $s_{t+1}$ durumunu üretir. Ajanın amacı yalnızca anlık ödülü değil, gelecekte elde edebileceği ödülleri de büyütmektir:

Buradaki $\gamma$, gelecekteki ödüllerin ne kadar önemsendiğini belirleyen iskonto katsayısıdır. Değer sıfıra yakınsa ajan sabırsız, bire yakınsa uzun vadeli düşünmeye yatkındır. Güvercinin hemen verilen yeme daha hızlı tepki vermesi gibi, algoritmalar da yakın ödülleri daha güçlü değerlendirebilir.

Basit Q-learning güncellemesi bu davranış-sonuç bağını sayısallaştırır:

Formüldeki $Q(s,a)$, belirli durumda yapılan eylemin beklenen değeridir. $\alpha$ öğrenme hızını, köşeli parantez içindeki bölüm ise beklenti ile gerçekleşen sonuç arasındaki farkı temsil eder. Beklenenden iyi bir ödül gelirse eylemin değeri yükselir.

# Tek bir deneyimden Q değerini günceller.
def q_guncelle(q, durum, eylem, odul, yeni_durum,
               alpha=0.1, gamma=0.95):
    mevcut = q[durum][eylem]
    en_iyi_gelecek = max(q[yeni_durum])
    hata = odul + gamma * en_iyi_gelecek - mevcut
    q[durum][eylem] += alpha * hata

Bu kod, ajanın yaşadığı tek bir deneyimi hafızasındaki davranış değerine dönüştürür. Yem geldiyse ilgili “gagalama” seçeneği güçlenir; ceza geldiyse zayıflar.

Benzerlik nerede sona eriyor?

En önemli fark, yapay ajanın ödülü gerçekten “istememesidir”. Ödül onun için haz değil, optimizasyon sinyalidir. Üstelik yanlış tanımlanan bir ödül fonksiyonu beklenmedik davranışlar doğurabilir. Ajan oyunu kazanmak yerine sonsuz puan veren bir hatayı keşfedebilir. Bu durum, güvercinlerin rastlantısal ödüller sonucunda batıl davranışlar geliştirmesini hatırlatır.

Sonuç olarak pekiştirmeli öğrenme, davranışçılığın dijital bir kopyası değildir; fakat onun güçlü sezgisini taşır: Karmaşık davranışlar, eylemler ile sonuçları arasındaki geri bildirim döngüsünden doğabilir. Skinner’ın kutusu bugün sanal ortamlara dönüşmüş olsa da temel soru aynıdır: Hangi sonuç, hangi davranışı güçlendiriyor?