Bir tedavinin işe yarayıp yaramayacağını hastaya uygulamadan önce görebildiğimizi düşünün. Dijital ikiz teknolojisi, bir organın veya fizyolojik sistemin verilerle beslenen sanal bir kopyasını oluşturarak bu fikri gerçeğe yaklaştırıyor. Böylece farklı ilaç dozları, cerrahi yaklaşımlar ya da yaşam tarzı değişiklikleri bilgisayar ortamında sınanabiliyor. Kısacası doktorlar, gerçek hastaya dokunmadan önce onun dijital benzeri üzerinde güvenli bir prova yapabiliyor. ``

Dijital ikiz tam olarak nedir?

Dijital ikiz, yalnızca üç boyutlu bir organ modeli değildir. Anatomik yapının yanında kan akışı, elektriksel aktivite, metabolizma ve ilaçlara verilen tepki gibi dinamik süreçleri de temsil eder. Manyetik rezonans görüntüleri, bilgisayarlı tomografi, laboratuvar sonuçları, genetik veriler ve giyilebilir sensör ölçümleri ortak bir modelde birleştirilebilir.

Modelin temelinde matematiksel denklemler bulunur. Örneğin kandaki ilaç yoğunluğunun zamanla değişimi basitleştirilmiş olarak şöyle gösterilebilir:

Burada $C$ ilaç konsantrasyonunu, $D$ uygulanan dozu, $V$ dağılım hacmini ve $k$ ilacın vücuttan uzaklaştırılma hızını temsil eder. Hastaya özgü böbrek fonksiyonu veya vücut ağırlığı değiştiğinde bu parametreler güncellenir. Böylece aynı ilacın iki kişide neden farklı sonuçlar doğurabileceği simüle edilir.

Sanal hasta nasıl oluşturulur?

Süreç genellikle dört aşamada ilerler:

1. Veri toplama: Görüntüleme, tahlil, sensör ve hasta geçmişi verileri alınır.
2. Model kurma: Organın geometrisi çıkarılır ve fizyolojik kurallar modele eklenir.
3. Kalibrasyon: Simülasyon sonuçları hastanın gerçek ölçümleriyle karşılaştırılır.
4. Senaryo denemeleri: Farklı dozlar ve tedavi seçenekleri sanal ortamda test edilir.

Basitleştirilmiş bir doz simülasyonu

Aşağıdaki Python örneği, farklı dozların kandaki tahmini ilaç yoğunluğunu nasıl değiştirdiğini hesaplar. Gerçek klinik modeller çok daha karmaşıktır; bu kod yalnızca temel mantığı gösterir.

import math

def konsantrasyon(doz, hacim, atilim_hizi, saat):
    # Tek doz sonrası üstel azalmayı yaklaşık olarak hesaplar.
    baslangic = doz / hacim
    return baslangic * math.exp(-atilim_hizi * saat)

hasta = {
    "dagilim_hacmi": 42,
    "atilim_hizi": 0.12
}

for doz in [50, 100, 150]:
    sonuc = konsantrasyon(
        doz,
        hasta["dagilim_hacmi"],
        hasta["atilim_hizi"],
        saat=8
    )
    print(f"{doz} mg için 8. saat: {sonuc:.2f} mg/L")

Bu simülasyonda dağılım hacmi ve atılım hızı hastaya göre değiştirilerek kişiselleştirme yapılır. Ardından sonuçlar, hedeflenen güvenli konsantrasyon aralığıyla karşılaştırılabilir. Ancak model çıktısı tek başına tedavi kararı değildir; doktor değerlendirmesi ve klinik kanıt gerekir.

Nerelerde kullanılabilir?

Kalbin dijital ikizi, ritim bozukluğunda elektrotların en uygun konumunu araştırabilir. Tümör modelleri, radyoterapi dozunun sağlıklı dokuya etkisini tahmin edebilir. Akciğer ikizleri ventilatör ayarlarını, damar modelleri ise stent yerleşimini değerlendirebilir. Sürekli sensör verisi geldiğinde ikiz de güncellenir; yani statik bir fotoğraf değil, hastayla birlikte değişen dijital bir yol arkadaşıdır.

Güçlü fakat kusursuz değil

Eksik veri, hatalı sensörler ve aşırı basitleştirilmiş biyolojik varsayımlar güvenilmez sonuçlar üretebilir. Ayrıca sağlık verilerinin mahremiyeti, algoritmik önyargı ve modelin kararından kimin sorumlu olacağı önemli tartışma alanlarıdır. Bu nedenle dijital ikizler doktorların yerini alan makineler olarak değil, kararlarını sayısal deneylerle destekleyen araçlar olarak görülmelidir.

Gelecekte daha hızlı hesaplama, gelişmiş yapay zekâ ve standartlaştırılmış sağlık verileri sayesinde kişiye özel sanal denemeler yaygınlaşabilir. Belki de reçete yazılmadan önce dijital ikizimiz kısa bir prova yapacak; fakat son sözü yine klinik uzmanlık, etik ilkeler ve gerçek dünya kanıtları söyleyecek.

``

Finansal zaman serisi nedir?

Bir varlığın belirli zamanlarda ölçülen fiyatları bir zaman serisi oluşturur:

Burada $P_t$, varlığın $t$ anındaki fiyatıdır. Fakat doğrudan fiyatları modellemek çoğu zaman yanıltıcıdır. Fiyat serileri genellikle durağan değildir; ortalamaları ve oynaklıkları zamanla değişebilir. Bu nedenle analistler çoğunlukla getiri kullanır:

Logaritmik getiri ise farklı dönemleri toplamayı kolaylaştırır:

Örneğin fiyat 100’den 103’e çıkarsa basit getiri yaklaşık yüzde 3’tür. Bilgisayar açısından asıl soru şudur: Önceki getiriler, sıradaki getiri hakkında anlamlı bilgi taşıyor mu?

Bilgisayar hangi sinyalleri arar?

Algoritmalar trend, momentum, mevsimsellik, işlem hacmi ve oynaklık gibi özellikleri araştırabilir. Ancak bulunan her ilişki gerçek bir ekonomik mekanizma değildir. Bazen model, verideki rastlantısal gürültüyü öğrenir; buna aşırı öğrenme denir.

Basit bir hareketli ortalama, son $n$ fiyatın ortalamasıdır:

Kısa dönemli ortalama uzun dönemli ortalamayı geçtiğinde yükseliş sinyali üretilebilir. Ne var ki bu, geleceğin kesin yükseleceği anlamına gelmez; yalnızca geçmiş hareketin belirli bir özetidir.

Python ile küçük bir deney

Aşağıdaki kod fiyatlardan getiri üretir, beş günlük hareketli ortalamayı hesaplar ve bir sonraki günün yönünü tahmin etmek için lojistik regresyon kullanır:

import pandas as pd
from sklearn.linear_model import LogisticRegression
from sklearn.metrics import accuracy_score

# CSV dosyasında Date ve Close sütunları bulunduğunu varsayıyoruz.
df = pd.read_csv("prices.csv", parse_dates=["Date"])
df = df.sort_values("Date")

df["return"] = df["Close"].pct_change()
df["ma5"] = df["Close"].rolling(5).mean()
df["distance"] = df["Close"] / df["ma5"] - 1
df["target"] = (df["return"].shift(-1) > 0).astype(int)
df = df.dropna()

split = int(len(df) * 0.8)
train, test = df.iloc[:split], df.iloc[split:]

features = ["return", "distance"]
model = LogisticRegression()
model.fit(train[features], train["target"])

prediction = model.predict(test[features])
print("Doğruluk:", accuracy_score(test["target"], prediction))

Buradaki kronolojik ayırma kritik önemdedir. Veriyi rastgele karıştırmak, gelecekteki bilgilerin eğitim kümesine sızmasına yol açabilir. Bu durum modelin gerçekte sahip olamayacağı bir avantaj kazanmasıdır.

Tahmin başarısı nasıl değerlendirilir?

Yüzde 52 doğruluk ilk bakışta etkileyici görünmeyebilir; ancak işlem maliyetleri düşükse değerli olabilir. Tersine, yüzde 60 doğruluk yüksek komisyonlar ve büyük kayıplar nedeniyle zararla sonuçlanabilir. Bu yüzden doğruluğun yanında getiri, maksimum düşüş, Sharpe oranı ve işlem maliyetleri incelenmelidir.

Bilgisayar geçmişten olasılıksal ilişkiler öğrenebilir; fakat savaşlar, düzenlemeler, şirket haberleri ve yatırımcı psikolojisindeki kırılmalar geçmişte bulunmayabilir. En iyi yaklaşım, modeli bir kâhin değil, belirsizlik altında karar vermeye yardımcı olan ölçüm aracı olarak görmektir. Finansal tahminin asıl başarısı geleceği kusursuz bilmekten değil, yanlış çıkıldığında riski yönetebilmekten gelir.

``

Her Şeyin Kalbi: Oyun Döngüsü

Oyun motorlarının merkezinde game loop, yani oyun döngüsü bulunur. Motor çalıştığı sürece bu döngü girdiyi okur, oyun dünyasını günceller ve yeni kareyi ekrana gönderir.

Basitleştirilmiş akış şöyledir:

while oyun_calışıyor:
    girdileri_oku()
    fiziği_hesapla()
    oyun_mantığını_güncelle()
    sahneyi_render_et()

Bir karenin işlenme süresi ile saniyedeki kare sayısı arasındaki ilişki şu formülle gösterilebilir:

Örneğin bir kare $0.0166$ saniyede hazırlanıyorsa oyun yaklaşık $60$ FPS üretir. Ancak bütün sistemleri değişken $\Delta t$ ile güncellemek doğru değildir. Render döngüsü ekran hızına göre değişebilirken fizik hesaplamaları çoğunlukla sabit zaman aralıklarında çalıştırılır.

Render Döngüsü Nasıl Çalışır?

Render sistemi, oyun dünyasındaki nesneleri GPU’nun anlayabileceği komutlara dönüştürür. Kamera dışında kalan nesneler ayıklanır, görünür yüzeyler belirlenir, materyaller hazırlanır ve çizim komutları GPU’ya gönderilir.

Unity; Built-in, URP ve HDRP gibi farklı render yaklaşımları sunar. Unreal Engine ise deferred rendering, Nanite ve Lumen gibi sistemlerle yüksek detaylı sahneleri yönetir. Her iki motorda da amaç aynıdır: Görsel kaliteyi korurken kare süresini bütçe içinde tutmak. 60 FPS hedefinde bu bütçe yaklaşık $16.67$ milisaniyedir.

Fizik Neden Sabit Döngü Kullanır?

Fizik motorları çarpışma, hız, ivme ve kuvvet hesaplarını mümkün olduğunca tutarlı gerçekleştirmelidir. Temel hareket denklemlerinden biri şöyledir:

$\Delta t$ sürekli değişirse aynı kuvvet farklı bilgisayarlarda farklı sonuçlar üretebilir. Unity bu nedenle fizik işlemlerini ağırlıklı olarak FixedUpdate düzeninde yürütür. Unreal Engine tarafında fizik güncellemeleri tick grupları ve alt adımlar aracılığıyla kontrol edilebilir.

Girdi Sistemi ve Gecikme

Klavye, fare veya kontrolcü verileri işletim sisteminden alınır ve motorun girdi katmanına aktarılır. Girdi mümkün olduğunca erken okunursa oyuncunun yaptığı hareket ile ekrandaki sonuç arasındaki gecikme azalır.

void Update()
{
    float yatay = Input.GetAxis("Horizontal");
    hareketYonü = new Vector3(yatay, 0f, 0f);
}

void FixedUpdate()
{
    govde.AddForce(hareketYonü * kuvvet);
}

Bu Unity örneğinde girdi her karede okunur; fiziksel kuvvet ise sabit döngüde uygulanır. Böylece kısa süreli tuş hareketleri kaçırılmaz ve fizik davranışı kare hızından daha az etkilenir. Modern Unity Input System ve Unreal Enhanced Input, girdileri eylem tabanlı tanımlayarak farklı cihazları ortak bir soyutlama altında toplar.

İş Parçacıkları ve Senkronizasyon

Güncel motorlar tüm işleri tek çekirdekte yürütmez. Render hazırlığı, animasyon, ses ve fizik görevleri iş parçacıklarına dağıtılabilir. Unity Job System ve Unreal Task Graph bu yaklaşımın örnekleridir. Yine de render, fizik ve oyun mantığı birbirinin verisine ihtiyaç duyduğundan senkronizasyon noktaları oluşur. Bir görev geciktiğinde diğer sistemler bekleyebilir.

Sonuç olarak oyun motoru, farklı hızlarda çalışan orkestraya benzer. Girdi sistemi notaları toplar, fizik ritmi korur, render sistemi ise performansı seyirciye sunar. Başarılı bir oyun mimarisi, bu döngülerin doğru sırada ve mümkün olduğunca az bekleyerek çalışmasını sağlar.

Bir oyunda verdiğiniz masum bir kararın saatler sonra bir krallığın çökmesine yol açtığını düşünün. Bu sonuç önceden yazılmış tek bir senaryodan değil, seçimlerinizi değerlendiren dinamik bir hikâye motorundan doğabilir. Prosedürel anlatı; karakterleri, olayları ve sonuçları belirli kurallar doğrultusunda birleştirerek her oyuncuya farklı bir hikâye deneyimi sunmayı amaçlar.

``

Prosedürel anlatı nedir?

Geleneksel anlatıda yazar, olayların sırasını büyük ölçüde önceden belirler. Oyuncu bazen farklı yollar seçse de bunlar çoğunlukla elle yazılmış dallardır. Prosedürel anlatıda ise yazar yalnızca olayları değil, olay üretme kurallarını da tasarlar.

Bir hikâye motorunun kararını basitçe şöyle modelleyebiliriz:

Burada $S_t$ mevcut dünya durumunu, $A_t$ oyuncunun eylemini, $R$ anlatı kurallarını ve $S_{t+1}$ yeni durumu temsil eder. Örneğin oyuncu bir tüccarı soyarsa para miktarı artabilir; fakat itibar düşer, muhafızların şüphe seviyesi yükselir ve tüccarın ailesi ileride intikam görevi başlatabilir.

Durum değişkenleri ve koşullar

Dinamik hikâye motorlarının hafızası, durum değişkenlerinden oluşur. İtibar, korku, sadakat, kaynak miktarı ve karakter ilişkileri bu değişkenlere örnektir. Motor, uygun olayları seçerken koşulları kontrol eder.

Aşağıdaki Python örneği, dünya durumuna göre yeni bir anlatı olayı seçer:

import random

def uygun_olaylari_bul(durum, olaylar):
    uygunlar = []

    for olay in olaylar:
        kosullar = olay["kosullar"]
        if all(durum.get(anahtar, 0) >= deger
               for anahtar, deger in kosullar.items()):
            uygunlar.append(olay)

    return uygunlar

def olay_sec(durum, olaylar):
    uygunlar = uygun_olaylari_bul(durum, olaylar)
    return random.choice(uygunlar) if uygunlar else None

olaylar = [
    {"ad": "Köylülerin İsyanı", "kosullar": {"korku": 70}},
    {"ad": "Kraliyet Daveti", "kosullar": {"itibar": 60}},
    {"ad": "Gizemli Tüccar", "kosullar": {"altin": 20}}
]

uygun_olaylari_bul fonksiyonu, koşulları sağlanan olayları filtreler. olay_sec ise bunlardan birini rastgele seçer. Gerçek bir motorda rastgelelik genellikle ağırlıklıdır; önemli olayların seçilme ihtimali daha yüksek tutulabilir.

Bir olayın puanı şu şekilde hesaplanabilir:

Burada $R$ rastgelelik, $D$ dramatik değer, $C$ mevcut durumla uyum ve $T$ yakın zamanda tekrar edilme cezasıdır. $w$ katsayıları tasarımcının hangi özelliğe önem verdiğini belirler.

Anlamlı seçim nasıl üretilir?

Her seçimin dünyayı değiştirmesi gerekmez; ancak oyuncu, kararının fark edildiğini hissetmelidir. İyi bir sistem üç katmanda tepki verir:

1. Anlık sonuç: Karakter hemen kızar veya ödül verir.
2. Sistemsel sonuç: İtibar, ekonomi ya da ilişki değeri değişir.
3. Gecikmiş sonuç: Eski karar, saatler sonra yeni bir görev veya düşman üretir.

Buradaki en büyük tehlike, sayısız ama yüzeysel seçenek sunmaktır. Beş anlamsız düğme yerine, bedeli açık olmayan iki güçlü seçenek genellikle daha etkilidir. Ayrıca sistemin tamamen kontrolsüz olması komik tutarsızlıklar doğurabilir: Dün ölen kralın bugün oyuncuya mektup göndermesi gibi!

Tasarımcı hâlâ hikâyenin yazarı mı?

Evet; fakat artık yalnızca sahneleri değil, olasılık uzayını da yazar. Karakterlerin hedeflerini, dünyanın sınırlarını ve hangi olayların birlikte anlamlı olduğunu tanımlar. Böylece motor doğaçlama yaparken temadan kopmaz.

Başarılı bir dinamik hikâye motoru, matematiksel kurallar ile insan yaratıcılığını birleştirir. Amaç sonsuz içerik üretmek değil, oyuncunun seçimlerinin hatırlandığına ve dünyanın gerçekten karşılık verdiğine inanmasını sağlamaktır.

``

Speedrun yalnızca hızlı oynamak değildir

Speedrun, belirlenmiş kurallar altında bir oyunu ya da oyun bölümünü en kısa sürede tamamlama yarışıdır. Oyuncular rotalarını tekrar tekrar deneyerek hareketleri, kaynak kullanımını ve savaşları optimize eder. Bu süreç matematiksel olarak bir maliyet minimizasyonuna benzetilebilir:

Amaç, toplam süreyi küçültmektir. Bir kısayol hareket süresini 20 saniye azaltırken başarısız olma riski nedeniyle ortalama 30 saniye kaybettiriyorsa rekor denemesi için uygun olmayabilir. Bu nedenle oyuncular yalnızca tekniğin teorik kazancını değil, başarı olasılığını da değerlendirir:

Buradaki $p$, hareketin başarı ihtimalidir. Dünya rekoru peşindeki oyuncu düşük olasılıklı bir yöntemi seçebilirken maraton yayınındaki oyuncu daha güvenli bir rota kullanabilir.

Glitch nasıl keşfedilir?

Glitch, oyunun kodu ile oyuncunun eylemleri arasındaki beklenmeyen etkileşimdir. Keşif bazen tesadüfen gerçekleşir: Oyuncu zıplarken menüyü açar ve karakter bir kapının arkasına ışınlanır. Topluluk daha sonra olayı yeniden üretmeye çalışır, gerekli koşulları belirler ve bulguları kare kare inceler.

Bir glitch’in geliştirilmesi genellikle şu aşamalardan geçer:

1. Gözlem: Beklenmeyen davranış fark edilir.
2. Yeniden üretim: Aynı sonucun hangi girdilerle oluştuğu aranır.
3. Modelleme: Kamera, çarpışma ve bellek gibi sistemlerin rolü incelenir.
4. Optimizasyon: Daha hızlı ve güvenilir uygulama geliştirilir.
5. Belgeleme: Video, zaman damgası ve rehber toplulukla paylaşılır.

Yani meşhur kısayol, çoğunlukla tek bir kişinin şans eseri bulduğu numaradan ziyade kolektif bir araştırma ürünüdür.

Kareler, girdiler ve ölçüm

60 FPS çalışan bir oyunda tek kare yaklaşık olarak $1/60$ saniye, yani 16,67 milisaniyedir. Bir hareket yalnızca iki karelik pencerede yapılabiliyorsa oyuncunun doğru girdiyi yaklaşık 33 milisaniyelik aralıkta vermesi gerekir. Bu yüzden speedrunner’lar kayıtlarını analiz eden küçük araçlar kullanır.

splitler = [42.18, 39.72, 41.05, 38.91]
hedef = 40.00

for bolum, sure in enumerate(splitler, start=1):
    fark = sure - hedef
    durum = "yavaş" if fark > 0 else "hızlı"
    print(f"Bölüm {bolum}: {abs(fark):.2f} sn {durum}")

Bu Python örneği, bölüm sürelerini hedef değerle karşılaştırır. Gerçek analiz araçları aynı mantığı kişisel en iyi dereceler, ortalamalar ve rota alternatifleri üzerinde uygular.

Glitch kullanmak hile midir?

Cevap kategoriye bağlıdır. Any% kategorisi oyunu izin verilen her yöntemle bitirmeyi hedefler. Glitchless kategorisi belirli hataları yasaklar. 100% ise tanımlanan tüm içeriklerin tamamlanmasını ister. Kuralları topluluk belirler; emülatör, mod, makro veya dışarıdan kod müdahalesi çoğunlukla yasaktır.

Speedrun kültürünü ilginç yapan şey, oyuncuların oyunu bozarken aslında onu olağanüstü ayrıntılı biçimde öğrenmesidir. Geliştiricinin kurduğu dünya bir laboratuvara, kontrolcü deney aracına, her başarısız deneme de yeni bir veri noktasına dönüşür. Ekranda birkaç saniyelik kısayol görünür; arkasında ise yüzlerce saatlik merak, iş birliği ve ustalık vardır.

Yerel işleme nedir?

Klasik bulut mimarisinde sensörden alınan veri internete çıkar, sağlayıcının sunucusunda değerlendirilir ve sonuç tekrar eve gönderilir. Yerel mimaride ise karar; Home Assistant çalıştıran bir mini bilgisayar, Raspberry Pi, NAS ya da özel bir otomasyon merkezi tarafından evin içinde verilir.

Örneğin koridordaki hareket sensörü etkinleştiğinde ışığın açılması için bulut sunucusundan cevap beklemek gerekmez. Merkez, sensör olayını yerel ağ üzerinden alır ve lambaya anında komut yollar.

Toplam tepki süresini basitçe şöyle düşünebiliriz:

Bulut tabanlı sistemde internet yolculuğu nedeniyle $T_{iletim}$ ve $T_{cevap}$ büyür. Yerel işlemede veri yalnızca ev ağı içinde dolaştığından toplam gecikme çoğu zaman belirgin biçimde azalır.

Bulut ve edge computing karşılaştırması

Yerel yaklaşım her durumda bulutu çöpe atmak anlamına gelmez. Hava durumu tahmini veya ev dışından bildirim gönderme gibi hizmetlerde bulut yararlıdır. En dengeli çözüm, kritik kararları evde verip yalnızca gerekli verileri dış servislere aktaran hibrit mimaridir.

Bir otomasyon nasıl çalışır?

Yerel merkezler genellikle olay güdümlü bir model kullanır. Sensör bir olay üretir, sistem koşulları denetler ve uygun eylemi gerçekleştirir:

1. Hareket sensörü aktif durumuna geçer.
2. Merkez saatin gece olup olmadığını kontrol eder.
3. Işık seviyesi belirlenen eşikten düşükse lambayı açar.
4. Hareket kesildikten sonra zamanlayıcı başlatır.
5. Süre dolunca lambayı kapatır.

Aşağıdaki Home Assistant otomasyonu bu mantığın sade bir örneğidir:

alias: Gece koridor ışığı
trigger:
  - platform: state
    entity_id: binary_sensor.koridor_hareket
    to: "on"
condition:
  - condition: numeric_state
    entity_id: sensor.koridor_aydinlik
    below: 30
action:
  - service: light.turn_on
    target:
      entity_id: light.koridor
  - delay: "00:02:00"
  - service: light.turn_off
    target:
      entity_id: light.koridor

Bu kod, hareket algılandığında ortam aydınlığı 30 lüksün altındaysa ışığı açar ve iki dakika sonra kapatır. Sensörler ile merkez aynı yerel ağdaysa işlem internet kesildiğinde de devam edebilir.

Mahremiyet ve kaynak kullanımı

Kameralar yerel işlemenin değerini daha görünür hâle getirir. Görüntüyü buluta göndermek yerine cihaz üzerinde insan algılama modeli çalıştırılabilir. Böylece dışarıya video yerine yalnızca insan algılandı olayı çıkar.

Yerel donanım seçerken işlemci gücü, bellek ve enerji tüketimi birlikte değerlendirilmelidir. Verimlilik kabaca şu oranla yorumlanabilir:

Basit sensör otomasyonları için düşük güçlü bir Raspberry Pi yeterli olabilir. Birden fazla kamera üzerinde yapay zekâ çalıştırılacaksa mini PC veya donanım hızlandırıcısı gerekebilir.

Sonuç

Edge computing, akıllı evi yalnızca daha hızlı değil, aynı zamanda daha dayanıklı ve mahremiyet dostu hâle getirir. En iyi başlangıç yöntemi; ışık, sıcaklık ve hareket gibi basit otomasyonları yerelleştirmek, ardından kamera analizi gibi ağır işlemlere geçmektir. Böylece internet gittiğinde akıllı eviniz bir anda oldukça pahalı bir sıradan eve dönüşmez!

``

Sesli asistan gerçekte neyi dinliyor?

Akıllı hoparlörler genellikle konuşmaların tamamını sürekli olarak buluta iletmez. Bunun yerine cihaz üzerinde çalışan düşük güçlü bir model, “Hey Asistan” gibi uyandırma sözcüğünü arar. Model yeterince yüksek bir güven skoru üretirse asıl ses kaydı işlenmeye başlanır.

Bu karar basitçe şöyle gösterilebilir:

Buradaki $\theta$, sistemin karar eşiğidir. Eşik düşürülürse kullanıcı asistanı daha kolay uyandırır; fakat televizyon sesi, benzer kelimeler ve arka plan konuşmaları da komut sanılabilir. Eşik yükseltildiğinde yanlış tetiklenmeler azalırken gerçek komutların kaçırılma ihtimali artar.

Bu ilişki, istatistikte yanlış pozitif ve yanlış negatif kavramlarıyla açıklanır. Yanlış pozitif, asistanın söylenmeyen bir komutu var sanmasıdır. Yanlış negatif ise gerçekten verilen komutu algılayamamasıdır.

Neden yanlış tetiklenir?

Başlıca nedenler arasında fonetik benzerlik, televizyon ve radyo sesleri, yankılı odalar, çocukların tiz konuşmaları, farklı aksanlar ve düşük kaliteli mikrofonlar bulunur. Ayrıca ses tanıma modeli belirli yaş veya dil gruplarını yeterince temsil etmeyen verilerle eğitilmiş olabilir.

Saldırganlar da bu zayıflıklardan yararlanabilir. İnsan kulağında anlamsız veya zor fark edilen seslerin içine komut gizlenmesi, adversarial audio saldırısı olarak bilinir. Açık bir pencereden, televizyondaki videodan ya da ele geçirilmiş bir IoT cihazından yayılan ses teorik olarak asistana komut verebilir.

Güvenlik ve mahremiyet etkileri

Her komut aynı risk düzeyine sahip değildir. Müziğin yanlışlıkla başlaması yalnızca can sıkıcıyken akıllı kilit, garaj kapısı, kamera veya alarm üzerinde işlem yapılması fiziksel güvenlik riski oluşturur. Yanlış tetiklenme sonrasında kaydedilen konuşmanın buluta gönderilmesi de mahremiyet sorununa dönüşebilir.

Basit bir risk tabanlı kontrol

Aşağıdaki Python örneği, komutun güven skoru ile işlem riskini birlikte değerlendirir. Kritik işlemlerde yalnızca ses tanımaya güvenmek yerine ikinci doğrulama ister:

def komutu_degerlendir(guven_skoru, risk_seviyesi):
    esikler = {"dusuk": 0.70, "orta": 0.85, "yuksek": 0.95}

    if guven_skoru < esikler[risk_seviyesi]:
        return "Komut reddedildi"

    if risk_seviyesi == "yuksek":
        return "Telefon üzerinden ek onay gerekli"

    return "Komut uygulanabilir"

print(komutu_degerlendir(0.92, "yuksek"))

Bu yaklaşım, güvenliği yalnızca model doğruluğuna bırakmaz; işlemin muhtemel zararını da hesaba katar.

Daha güvenli bir akıllı ev için

Kullanıcılar ses kayıt geçmişini düzenli olarak kontrol etmeli, gereksiz satın alma özelliklerini kapatmalı ve kritik cihazları ayrı bir IoT ağına yerleştirmelidir. Üreticiler ise yerel ses işleme, kişiye özel konuşmacı doğrulama, görünür kayıt göstergeleri ve kolay erişilen fiziksel mikrofon düğmeleri sunmalıdır.

Kusursuz ses tanıma gerçekçi olmayabilir. En sağlam çözüm, sistemin hata yapacağını kabul edip sonuçları sınırlandırmaktır. Başka bir deyişle iyi bir akıllı ev, yalnızca sahibini anlayan değil, emin olmadığında “Bunu gerçekten yapmak istiyor musunuz?” diye sorabilen evdir.

``

Sinir sistemi protezle nasıl konuşur?

Beyin bir hareket başlatmak istediğinde omurilik ve çevresel sinirler üzerinden kaslara elektriksel komutlar gönderir. Bir uzuv kaybedilmiş olsa bile geride kalan sinirler çoğu zaman bu komutları üretmeye devam eder. Elektromiyografi adı verilen yöntem, kasların üzerindeki elektrotlarla bu elektriksel etkinliği ölçer.

Ölçülen ham sinyal genellikle gürültülüdür. Kalp atışı, elektrotun kayması ve çevredeki elektronik cihazlar ölçümü etkileyebilir. Bu nedenle sinyal önce filtrelenir, ardından küçük zaman pencerelerine bölünür. Her pencereden ortalama mutlak değer, varyans veya frekans enerjisi gibi özellikler çıkarılır.

Bir sinyalin basitleştirilmiş enerji ölçümü şöyle ifade edilebilir:

Burada $x_i$ ölçülen sinyal örneğini, $N$ ise pencere içindeki örnek sayısını gösterir. Kas daha güçlü kasıldığında enerji çoğunlukla yükselir. Ancak farklı hareketleri ayırmak için yalnızca enerji yetmez; sinyalin zamansal ve frekans özellikleri birlikte değerlendirilir.

Komuttan mekanik harekete

Sistemin işleyişi dört temel aşamaya ayrılır:

1. Elektrotlar sinir veya kas sinyalini toplar.
2. Filtreleme işlemi paraziti azaltır.
3. Bir makine öğrenmesi modeli hareket niyetini sınıflandırır.
4. Denetleyici, protezin motorlarına uygun komutları yollar.

Örneğin model, sinyali “eli aç”, “yumruk yap” veya “bileği döndür” sınıflarından birine yerleştirebilir. Motor komutu için basit bir oransal denetim kullanılabilir:

Burada $e$, hedef konum ile mevcut konum arasındaki fark; $K$ ise tepki kuvvetini belirleyen katsayıdır. Büyük hata daha güçlü motor komutu üretir.

Küçük bir hareket sınıflandırıcısı

Aşağıdaki Python örneği, önceden çıkarılmış sinyal özelliklerinden hareket türünü öğrenen basit bir modeli gösterir:

from sklearn.ensemble import RandomForestClassifier

# Her satır: enerji, ortalama genlik ve frekans özelliği
X = [[0.2, 0.1, 15], [0.8, 0.7, 32],
     [0.3, 0.2, 18], [0.9, 0.8, 35]]
y = ["ac", "kapat", "ac", "kapat"]

model = RandomForestClassifier(n_estimators=50, random_state=42)
model.fit(X, y)

yeni_sinyal = [[0.75, 0.68, 30]]
print(model.predict(yeni_sinyal)[0])

Bu kod doğrudan bir protezi yönetmez; sinyal çözümleme mantığının sadeleştirilmiş bir örneğidir. Gerçek sistemlerde binlerce örnek, gerçek zamanlı veri akışı ve güvenlik kontrolleri bulunur. Yanlış bir tahminin bardağı kırabileceği düşünülürse düşük gecikme kadar güvenilirlik de önemlidir.

Dokunmayı geri getirmek mümkün mü?

Akıllı protezlerin en heyecan verici yönü çift yönlü iletişimdir. Basınç sensörleri, parmak ucundaki kuvveti ölçerek sinirlere kontrollü elektrik darbeleri gönderebilir. Böylece kullanıcı yalnızca protezi hareket ettirmez; tuttuğu nesnenin sertliği veya kaymak üzere olduğu hakkında geri bildirim de alabilir.

Gelecekte daha küçük elektrotlar, enerji verimli motorlar ve kullanıcıyla birlikte öğrenen algoritmalar göreceğiz. Bununla birlikte mahremiyet, bakım maliyeti, siber güvenlik ve erişilebilirlik unutulmamalıdır. Çünkü sinir sinyali yalnızca teknik veri değil, insan bedenine ait son derece kişisel bir bilgidir. Başarılı bir akıllı protez, metal ve koddan fazlasıdır: İnsan niyetiyle makine hareketi arasında güvenilir, sezgisel ve güvenli bir köprüdür.

``

Bitkinin su ihtiyacı nasıl hesaplanır?

Sistemin temel girdilerinden biri referans evapotranspirasyon değeridir. Evapotranspirasyon, topraktan buharlaşan ve bitkinin yapraklarından atmosfere aktarılan toplam suyu ifade eder. Belirli bir bitkinin yaklaşık ihtiyacı şöyle bulunabilir:

Burada $ET_0$ hava koşullarına bağlı referans evapotranspirasyon, $K_c$ ise bitki katsayısıdır. Örneğin domatesin gelişim dönemindeki katsayısı, yeni ekilmiş bir bitkininkinden farklıdır.

Yağış ve mevcut toprak nemi de hesaba katıldığında net sulama ihtiyacı basitleştirilmiş biçimde şöyle modellenebilir:

$D$ verilecek suyu, $P_e$ etkili yağışı, $M$ ise kök bölgesinde kullanılabilir nem katkısını gösterir. max işlemi, yağış ihtiyacı zaten karşıladıysa negatif miktarda sulama yapılmasını engeller.

Takvim tabanlı ve akıllı sulama karşılaştırması

Akıllı yaklaşım açıkça avantajlı görünse de sensör kalibrasyonu ihmal edilirse sistem son derece kararlı biçimde yanlış karar verebilir. Başka bir deyişle, kötü veri kullanan harika bir algoritma hâlâ kötü bir sulamacıdır.

Optimizasyon problemi

Bir tarlada birden fazla sulama bölgesi bulunduğunu düşünelim. Her bölgenin ihtiyacı farklıdır, fakat pompanın debisi ve depodaki su sınırlıdır. Hedef fonksiyonu, ihtiyaç ile verilen su arasındaki farkı küçültebilir:

Burada $D_i$ bölgenin ihtiyacı, $x_i$ tahsis edilen su ve $w_i$ öncelik katsayısıdır. Yeni dikilmiş veya su stresine hassas bitkilere daha yüksek ağırlık verilebilir. Model ayrıca şu kısıtları taşıyabilir:

• Toplam dağıtılan su depo kapasitesini aşmamalıdır.
• Bir vananın çalışma süresi teknik sınırlar içinde kalmalıdır.
• Yağmur olasılığı yüksekse tahsis azaltılmalıdır.
• Pompa aynı anda yalnızca belirli sayıda bölgeyi beslemelidir.

Basit bir Python karar mekanizması

Aşağıdaki fonksiyon, nem eşiklerini ve beklenen yağışı kullanarak sulama süresi üretir:

def sulama_suresi(nem, hedef_nem, alan_m2,
                   yagis_mm, debi_litre_dk):
    nem_acigi = max(0, hedef_nem - nem)

    # Beklenen yağmur arttıkça ihtiyaç azaltılır.
    gerekli_mm = max(0, nem_acigi * 0.5 - yagis_mm)

    # 1 mm yağış, 1 m² alanda yaklaşık 1 litre sudur.
    gerekli_litre = gerekli_mm * alan_m2
    dakika = gerekli_litre / debi_litre_dk

    return round(dakika, 1)

sure = sulama_suresi(
    nem=24,
    hedef_nem=35,
    alan_m2=120,
    yagis_mm=2,
    debi_litre_dk=18
)
print(f'Sulama süresi: {sure} dakika')

Bu örnek üretim sistemi için tek başına yeterli değildir; ancak sensör verisinin fiziksel su miktarına ve vana süresine nasıl dönüştürüldüğünü gösterir. Gerçek projede sensör okumaları filtrelenmeli, anormal değerler elenmeli ve vana komutları kayıt altına alınmalıdır.

Daha akıllı bir mimari

Uygulamada nem sensörleri MQTT gibi bir protokolle merkezi sunucuya veri gönderebilir. Sunucu hava tahminini alır, optimizasyonu çalıştırır ve vanalara komut iletir. Elektrik veya internet kesintisine karşı yerel denetleyicide güvenli bir varsayılan program bulunması önemlidir.

Sonuç olarak akıllı sulama; sensör, tarım bilgisi ve optimizasyonun ortak çalışmasıdır. Başarı yalnızca su tasarrufuyla değil, bitki sağlığı, enerji tüketimi ve ürün verimi birlikte izlenerek ölçülmelidir. En iyi sistem en çok sulayan değil, doğru damlayı doğru köke ulaştırandır.

Işıkla nabız ölçmek: PPG

Saatlerin arkasındaki yanıp sönen yeşil LED’ler, fotopletismografi (PPG) yönteminin parçasıdır. LED cilde ışık gönderir; fotodiyot ise geri yansıyan ışığı ölçer. Kalp her attığında damarlardaki kan hacmi değişir. Hemoglobin yeşil ışığı emdiği için yansıma miktarındaki periyodik değişim nabzı ortaya çıkarır.

İki tepe arasındaki süre $\Delta t$ saniye ise kalp atış hızı yaklaşık olarak şöyle hesaplanır:

Örneğin tepeler arasında $0.8$ saniye varsa sonuç $75$ BPM olur. Ne var ki kol hareketi, ter, dövme, gevşek kayış ve ortam ışığı sinyali bozabilir. Saat bu nedenle ivmeölçer verisini kullanarak hareket kaynaklı parazitleri ayıklamaya çalışır.

Oksijen, elektrik ve sıcaklık

Kandaki oksijen doygunluğu için kırmızı ve kızılötesi ışık kullanılır. Oksijenli ve oksijensiz hemoglobin bu dalga boylarını farklı oranlarda emer. Cihaz, emilim oranını kalibrasyon modeliyle karşılaştırarak SpO₂ tahmini üretir.

Elektrokardiyografi özellikli saatlerdeyse kullanıcı elektrotlara dokunarak elektrik devresini tamamlar. Elde edilen tek derivasyonlu EKG, kalbin elektriksel aktivitesini gösterir. Hastanedeki 12 derivasyonlu cihaz kadar kapsamlı değildir; yine de düzensiz ritim belirtilerinin yakalanmasına yardımcı olabilir.

Hareketten adıma, adımdan uykuya

İvmeölçer genellikle $x$, $y$ ve $z$ eksenlerinde örnek toplar. Yön etkisini azaltmak için toplam hareket büyüklüğü hesaplanabilir:

Yerçekimi ve gürültü filtrelendikten sonra belirli eşikleri aşan ritmik tepeler adım olarak yorumlanır. Uyku takibi ise çoğunlukla hareketsizlik, kalp hızı, solunum eğilimi ve kalp hızı değişkenliğini birleştirir. Saat beynin elektriksel aktivitesini ölçmediği için uyku evreleri kesin teşhis değil, algoritmik tahmindir.

Aşağıdaki Python örneği, basitleştirilmiş ivme verisindeki tepeleri sayar:

import numpy as np
from scipy.signal import find_peaks

# Üç eksenli ivmeden hareket büyüklüğünü hesapla
x, y, z = np.loadtxt("ivme.csv", delimiter=",", unpack=True)
magnitude = np.sqrt(x**2 + y**2 + z**2)

# Yerçekimi çevresindeki sapmaları belirginleştir
movement = magnitude - np.mean(magnitude)

# Birbirine çok yakın titreşimleri adım saymamak için mesafe uygula
peaks, _ = find_peaks(movement, height=0.25, distance=20)
print(f"Tahmini adım: {len(peaks)}")

Gerçek cihazlar sabit bir eşikten fazlasını kullanır: filtreleme, kişisel kalibrasyon ve makine öğrenmesi modelleri farklı yürüyüş biçimlerini ayırır.

Ölçüm mü, tahmin mi?

Giyilebilir cihazların asıl gücü tek bir ölçümden ziyade zaman içindeki değişimi göstermeleridir. Dinlenik nabzın günlerce yükselmesi veya sıcaklık eğiliminin değişmesi anlamlı olabilir. Yine de sensör hatası ile sağlık sorununu ayırmak her zaman kolay değildir. Bu nedenle saat bildirimleri tanı kabul edilmemeli; devam eden veya ciddi belirtilerde sağlık uzmanına başvurulmalıdır. Bileğinizdeki teknoloji iyi bir gözlemci olabilir, fakat henüz doktor önlüğü giymiyor.