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.

``

Fiziksel zaman ve algılanan zaman

Fiziksel zaman ölçülebilirken algılanan zaman öznel bir deneyimdir. Bunu basitleştirilmiş bir modelle şöyle ifade edebiliriz:

Burada $T_a$ algılanan zamanı, $T_g$ gerçek süreyi, $B$ belirsizliği, $D$ dikkatin beklemeye yönelmesini, $E$ eğlenceyi ve $K$ kontrol hissini temsil eder. Bu bilimsel bir ölçüm formülü değil, tasarım kararlarını düşünmek için kullanışlı bir modeldir. Belirsizlik ve beklemeye odaklanma arttıkça süre uzamış gibi hissedilir. Eğlence ve kontrol hissi yükseldiğinde ise aynı süre daha kısa algılanır.

Örneğin yüzde göstergesi bulunmayan donmuş bir ekran, oyuncuya sistemin çalışıp çalışmadığını düşündürür. Belirsizlik yükselir ve oyuncu her saniyeyi izlemeye başlar. Hareketli bir ipucu, ilerleme çubuğu veya etkileşimli mini oyun ise dikkati dağıtır.

İlerleme çubuğunun küçük oyunları

İlerleme çubukları her zaman yüklemenin gerçek hızını birebir göstermez. Dosyaların boyutu, disk hızı ve ağ gecikmesi değişken olduğu için doğrusal ilerleme üretmek zordur. Çubuğun uzun süre yüzde 99’da kalması özellikle sinir bozucudur; çünkü arayüz, bitiş sözü vermiş gibi görünür.

Daha dengeli bir gösterge için ölçülen ilerleme doğrudan ekrana verilmek yerine yumuşatılabilir:

$\alpha$ değeri 0 ile 1 arasındadır. Küçük değerler daha akıcı fakat daha yavaş tepki veren bir animasyon oluşturur. Aşağıdaki JavaScript örneği ani sıçramaları azaltır:

let displayedProgress = 0;

function updateLoading(realProgress) {
  const smoothing = 0.12;
  displayedProgress +=
    smoothing * (realProgress - displayedProgress);

  const percent = Math.floor(displayedProgress * 100);
  document.querySelector(".progress-bar").style.width = `${percent}%`;
  document.querySelector(".progress-label").textContent = `${percent}%`;
}

Kod, gerçek yükleme oranına bir anda atlamak yerine ona kademeli biçimde yaklaşır. Ancak gösterge kullanıcıyı kandırmamalıdır. Gerçek işlem tamamlanmadan yüzde 100 göstermek, kısa vadede hızlı görünse de güven kaybına yol açabilir.

Beklemeyi oynanışa dönüştürmek

Bazı oyunlar yüklemeyi dar geçitler, asansör yolculukları veya yavaş açılan kapılar içine saklar. Oyuncu hareket etmeye devam ettiği için teknik bekleme, kurgu dünyasının parçası olur. Buna karşılık aynı numara çok sık kullanılırsa oyuncular “Bu asansör aslında yükleme ekranı” diyerek perdenin arkasını görmeye başlar.

Respawn süreleri de bilinçli biçimde tasarlanır. Anında yeniden doğmak cezayı anlamsızlaştırabilir; aşırı uzun beklemek ise öfke yaratır. Takım oyunlarında bekleme süresi, oyuncuya haritayı izleme ve strateji kurma fırsatı veriyorsa pasif ceza olmaktan çıkar.

Başarılı zaman manipülasyonunun amacı oyuncuyu aldatmak değil, beklemeyi anlaşılır ve tahmin edilebilir kılmaktır. Geri bildirim verin, belirsizliği azaltın, mümkünse küçük bir kontrol alanı sunun. Saat aynı hızda ilerlese de oyuncunun zihnindeki kronometre böylece çok daha insaflı çalışır.

``

Director AI tam olarak nedir?

Director AI, tek bir düşmanın nasıl hareket edeceğini belirleyen klasik yapay zekâdan farklıdır. Bireysel düşman AI’ı hedef seçme, siper alma veya yol bulma gibi yerel kararlarla ilgilenirken yönetmen sistemi bütün oyun deneyimini denetler.

Amaç oyuncuyu sürekli cezalandırmak değildir. İyi bir yönetmen; stres, rahatlama ve yeniden yükselişten oluşan dramatik bir ritim üretir. Kesintisiz baskı yorucu, sürekli kolaylık ise sıkıcıdır.

Oyuncunun stresi nasıl ölçülür?

Sistem doğrudan oyuncunun heyecanını okuyamaz; bunun yerine ölçülebilir sinyaller kullanır. Can miktarı, takım üyeleri arasındaki mesafe, isabet oranı, alınan hasar, cephane ve son saldırıdan beri geçen süre bunlardan bazılarıdır.

Basitleştirilmiş bir stres puanı şöyle hesaplanabilir:

Burada $D$ normalize edilmiş hasarı, $H$ kalan sağlık oranını, $I$ takımın dağılma seviyesini ve $A$ aktif düşman yoğunluğunu temsil eder. Katsayıların toplamının $1$ olması yorumlamayı kolaylaştırır. Örneğin $S$ değeri $1$’e yaklaştıkça oyuncuların baskı altında olduğu varsayılır.

Tek karelik ölçümler yanıltıcı olabileceğinden üstel hareketli ortalama kullanılabilir:

Küçük bir $\alpha$, sistemin ani değişimlere aşırı tepki vermesini engeller. Böylece tek bir kötü nişan, hemen devasa bir zombi sürüsüyle sonuçlanmaz.

Gerilim döngüsü

Director AI genellikle deneyimi aşamalara böler:

1. Hazırlık: Oyuncular kaynak toplar ve çevreyi inceler.
2. Yükseliş: Düşman sayısı veya özel tehdit olasılığı artar.
3. Zirve: Yoğun bir saldırı ya da kritik karşılaşma yaşanır.
4. Rahatlama: Baskı azaltılır, oyuncuya toparlanma fırsatı verilir.

Bu döngü yalnızca düşman sayısını değiştirmez. Sağlık paketlerinin konumu, müzik, özel düşman türleri ve alternatif yollar da yönetilebilir. Ancak sistem oyuncuya açıkça yardım ederse yapaylık hissi doğar. Bu nedenle ayarlamalar çoğunlukla perde arkasında yapılır.

Basit bir yönetmen prototipi

Aşağıdaki Python örneği, stres puanına göre yönetmenin hangi aşamaya geçeceğini gösterir:

class Director:
    def __init__(self):
        self.stress = 0.0
        self.phase = "hazirlik"

    def update(self, damage, low_health, isolation, enemies):
        sample = (
            0.35 * damage
            + 0.25 * low_health
            + 0.20 * isolation
            + 0.20 * enemies
        )

        # Ölçümü yumuşatarak ani ve dengesiz kararları önler.
        self.stress = 0.2 * sample + 0.8 * self.stress

        if self.stress < 0.25:
            self.phase = "yukselis"
        elif self.stress > 0.75:
            self.phase = "rahatlama"
        else:
            self.phase = "denge"

        return self.phase

Buradaki önemli ayrıntı ters dengedir: stres düşükken tehdit artırılır, yüksekken oyuncuya nefes aldırılır. Gerçek projelerde eşiklerin sürekli aşılmasını önlemek için histerezis, aşamalar için minimum süre ve rastlantısal seçim ağırlıkları da eklenir.

Adil görünmek, adil olmaktan farklıdır

Dinamik zorluk sisteminin en büyük riski oyuncunun başarılarını değersizleştirmesidir. İyi oynayan kişiye durmadan daha güçlü düşman göndermek, ilerleme hissini yok edebilir. Çözüm; zorluğu yalnızca sayısal güçle değil, karşılaşma çeşitliliği ve tempo üzerinden düzenlemektir.

Başarılı bir Director AI, oyuncunun ne kazanacağını belirlemez; unutulmaz bir mücadele yaşayabileceği koşulları hazırlar. En iyi yönetmen de zaten varlığını hissettirmeden sahneyi yöneten yönetmendir.

Bir hastanenin dijital altyapısını, hiç uyumayan dev bir organizma gibi düşünebiliriz. Muayene notları, laboratuvar sonuçları, reçeteler, röntgen görüntüleri ve alerji bilgileri sürekli bu organizmanın içinde dolaşır. Elektronik sağlık kaydı sistemlerinin görevi, milyonlarca hastaya ait bu verileri yalnızca saklamak değil; doğru kişiye, doğru zamanda ve güvenli biçimde ulaştırmaktır. ``

Sağlık verisi neden sıradan değildir?

Bir e-ticaret sisteminde yanlış ürün önerilmesi can sıkıcıdır; sağlık sisteminde yanlış ilaç bilgisinin gösterilmesi ise hayati sonuçlar doğurabilir. Bu nedenle veri mimarisi üç temel hedef etrafında kurulur:

• Tutarlılık: Aynı hastanın kan grubu farklı ekranlarda farklı görünmemelidir.
• Erişilebilirlik: Acil servisteki doktor kayda saniyeler içinde ulaşabilmelidir.
• Gizlilik: Veriyi yalnızca yetkili kişiler, izin verilen amaçlarla görebilmelidir.

Bir sistemin kullanılabilirliği kabaca şöyle ifade edilir:

Burada $MTBF$, arızalar arasındaki ortalama süreyi; $MTTR$ ise sistemi onarmak için gereken ortalama süreyi gösterir. Sağlık platformlarında hedef genellikle %99,9 veya daha yüksek kullanılabilirliktir.

Katmanlı mimari nasıl çalışır?

Modern sağlık sistemleri tek bir dev veritabanından ziyade görevleri ayrılmış katmanlar kullanır.

Hasta kimliği gibi ilişkisel ve tutarlı olması gereken bilgiler SQL veritabanlarında tutulabilir. MR görüntüleri ise çok büyük oldukları için PACS veya nesne depolama sistemlerine yerleştirilir; veritabanında yalnızca dosyanın adresi ve açıklayıcı metadatası bulunur.

Hasta kayıtları nasıl modellenir?

Temel yaklaşım, hastayı benzersiz bir kimlikle diğer klinik olaylara bağlamaktır. Basitleştirilmiş bir tablo şöyle oluşturulabilir:

CREATE TABLE observations (
    observation_id BIGINT PRIMARY KEY,
    patient_id BIGINT NOT NULL,
    code VARCHAR(50) NOT NULL,
    numeric_value DECIMAL(10, 2),
    measured_at TIMESTAMP NOT NULL,
    version_no INTEGER NOT NULL
);

CREATE INDEX idx_observation_patient_time
ON observations (patient_id, measured_at DESC);

Bu indeks, belirli bir hastanın en güncel ölçümlerine hızla ulaşılmasını sağlar. version_no alanı ise aynı kayıt eş zamanlı güncellenirken değişikliklerin yanlışlıkla birbirini ezmesini önleyen iyimser kilitlemede kullanılabilir.

Standartlar neden kritik?

Hastaneler farklı yazılımlar kullandığından sistemlerin ortak bir dil konuşması gerekir. HL7, klinik mesajlaşmada uzun süredir kullanılırken FHIR, sağlık kaynaklarını modern web API’leri üzerinden paylaşmayı kolaylaştırır. Görüntüleme tarafında ise DICOM standardı öne çıkar.

Milyonlarca kayıt nasıl ölçeklenir?

Veriler hasta kimliğine veya coğrafi bölgeye göre bölümlenebilir. Bu işleme sharding denir. Okuma yükünü azaltmak için replikalar ve önbellekler kullanılır. Yaklaşık depolama ihtiyacı şu şekilde hesaplanabilir:

Burada $N$ hasta sayısı, $R$ hasta başına kayıt sayısı, $B$ ise ortalama kayıt boyutudur. Görüntüler hesaba katıldığında ihtiyaç petabayt seviyesine çıkabilir.

Güvenlik görünmez bir katman değildir

Veriler aktarım sırasında TLS, depolamada ise güçlü şifreleme algoritmalarıyla korunur. Rol tabanlı erişim kontrolü sayesinde doktor, teknisyen ve muhasebe çalışanı aynı bilgileri göremez. Her görüntüleme ve değişiklik denetim günlüğüne yazılır. Yedekler farklı bölgelerde saklanır ve düzenli olarak geri yükleme testleri yapılır.

Sonuç olarak elektronik sağlık kaydı mimarisi; veritabanı, standart, güvenlik ve dağıtık sistem mühendisliğinin birleşimidir. Başarılı bir sistem yalnızca büyük veriyi taşımaz; klinik kararların güvenilir, hızlı ve izlenebilir olmasını sağlar.

Modern dizileme cihazları tek bir deneyde milyarlarca DNA bazı üretebilir. Ancak cihazdan çıkan A, T, G ve C harfleri tek başına pek anlamlı değildir. Bu devasa yapbozu çözmek; kısa DNA parçalarını referans genoma yerleştirmeyi, farklılıkları bulmayı ve sonuçların güvenilirliğini ölçmeyi gerektirir. İşte biyoinformatik, moleküler biyoloji ile algoritmaların el sıkıştığı noktada devreye girer. ``

Ham veriden genoma uzanan yol

Dizileme sonucu çoğunlukla FASTQ dosyaları elde edilir. Her okuma, yani read, bir DNA dizisiyle birlikte baz kalitesini belirten sayısal değerlere sahiptir. Phred kalite skoru şu ilişkiyle tanımlanır:

Buradaki $P$, bazın yanlış okunma olasılığıdır. Örneğin $Q=30$, yaklaşık $P=0.001$ hata olasılığına, yani %99,9 doğruluğa karşılık gelir. Analizin ilk aşamasında FastQC gibi araçlarla kalite dağılımı, GC oranı ve adaptör kalıntıları incelenir. Düşük kaliteli uçlar ve adaptörler temizlenmezse sonraki algoritmalar biyolojik olmayan eşleşmeler üretebilir.

Hizalama neden zordur?

İnsan genomu yaklaşık 3,2 milyar baz çifti içerir. Buna karşılık tipik bir kısa okuma yalnızca 100–150 baz uzunluğundadır. Üstelik genomda tekrar eden bölgeler, dizileme hataları, eklemeler ve silinmeler bulunur. Dolayısıyla amaç yalnızca aynı metni aramak değil, küçük farklılıklara izin veren en olası konumu bulmaktır.

İki diziyi karşılaştıran klasik dinamik programlama yaklaşımında genel süre karmaşıklığı $O(nm)$ seviyesindedir. Milyonlarca okumada bu maliyet kabul edilemez. Modern hizalayıcılar bu yüzden genomu indeksler ve yalnızca umut vadeden bölgeleri ayrıntılı olarak değerlendirir.

BWA ve Bowtie2 gibi araçlar Burrows–Wheeler Dönüşümü ile oluşturulan FM-index yapısından yararlanır. Böylece referans genomun tamamını her okuma için baştan taramak yerine eşleşme aralığı hızlı biçimde daraltılır. Uzun okumalar için Minimap2, dizilerden seçilmiş temsilci parçaları kullanarak aday konumları bulur.

Küçük bir dizi karşılaştırma örneği

Aşağıdaki Python kodu, iki eşit uzunluklu dizinin farklı olduğu konumları belirler. Gerçek hizalayıcıların yaptığı iş çok daha karmaşıktır; ancak varyant bulmanın temel fikrini gösterir:

reference = "ACGTTGCAACGT"
sample = "ACGTCGCAATGT"

variants = []
for position, (ref_base, sample_base) in enumerate(
    zip(reference, sample), start=1
):
    if ref_base != sample_base:
        variants.append({
            "position": position,
            "reference": ref_base,
            "sample": sample_base
        })

for variant in variants:
    print(variant)

Kod, referans ile örneği baz baz karşılaştırır ve değişen konumları kaydeder. Gerçek analizlerde GATK, FreeBayes veya DeepVariant gibi araçlar yalnızca harf farkına bakmaz; okuma derinliği, baz kalitesi ve hizalama güvenini de hesaba katar.

Bir varyantın destek oranı kabaca $f = a/d$ ile ifade edilebilir. Burada $a$ alternatif bazı destekleyen okuma sayısı, $d$ ise toplam kapsama derinliğidir. Örneğin 40 okumanın 20’si farklı bazı taşıyorsa $f=0.5$ olur; bu durum diploid bir genomda heterozigot varyanta işaret edebilir.

Sonuçların biyolojik yorumu

Hizalama sonrasında SAM/BAM dosyaları düzenlenir, yinelenen okumalar işaretlenir ve varyantlar VCF biçiminde raporlanır. Ardından bulunan değişikliklerin genleri, proteinleri veya hastalık riskini etkileyip etkilemediği araştırılır. En hızlı algoritma bile kötü kaliteli veriyle güvenilir biyoloji üretemez. Bu nedenle genom analizi; doğru indeksleme, istatistiksel değerlendirme, kalite kontrolü ve biyolojik yorumun birlikte yürütüldüğü dikkatli bir süreçtir.

``

Zımni öğretim nedir?

Zımni öğretim, oyunun mekaniklerini metin kutuları veya uzun açıklamalar yerine seviye düzeni, görsel ipuçları, güvenli deneyler ve sonuçlar aracılığıyla öğretmesidir. Tasarımcı oyuncuya doğrudan ne yapacağını söylemez; doğru davranışı keşfedebileceği kontrollü bir durum hazırlar.

Bu yaklaşımın temel döngüsü şöyle modellenebilir:

Örneğin oyuncunun önüne küçük bir çukur yerleştirilir. İlerlemek için zıplaması gerekir; fakat çukur ölümcül değildir. Oyuncu düşse bile kolayca geri çıkabilir. Böylece oyun hem zıplama gereksinimini gösterir hem de hata yapmayı cezalandırmadan denemeye izin verir.

Açık ve zımni öğretimin farkı

Zımni öğretim her durumda üstün değildir. Karmaşık envanter sistemleri veya erişilebilirlik seçenekleri açık açıklamalar gerektirebilir. İyi tasarım, iki yaklaşımı rakip değil tamamlayıcı araçlar olarak görür.

Seviye tasarımı nasıl öğretmene dönüşür?

İlk yöntem odak yönetimidir. Işık, renk, hareket ve mimari çizgiler oyuncunun bakışını önemli noktaya taşır. Karanlık bir koridordaki tek parlak kapı, üzerinde “Buraya git” yazmasa da oldukça konuşkandır.

İkinci yöntem, yeni mekaniği güvenli bir ortamda tanıtmaktır. Oyuncu patlayan bir varili ilk kez düşmansız bir odada görürse ona ateş ederek sonucunu inceleyebilir. Daha sonra aynı varil düşmanların yanında kullanıldığında oyuncu bağlantıyı kendisi kurar.

Öğrenme başarısını basitçe şu şekilde düşünebiliriz:

Çarpanlardan biri sıfıra yaklaşırsa öğretim de zayıflar. Parlayan bir nesne dikkat çekebilir; ancak oyuncu onunla etkileşime giremiyorsa anlamlı öğrenme oluşmaz.

Küçük bir tasarım örneği

Bir platform oyununda duvardan zıplama mekaniğini tanıttığımızı varsayalım. Seviyenin davranışı aşağıdaki sözde kodla ifade edilebilir:

oyuncu öğretim_odasına_girince:
    çıkışı yüksek bir noktaya yerleştir
    iki zıplanabilir duvarı karşılıklı konumlandır
    düşülen zemini güvenli yap

oyuncu duvara temas edince:
    karakteri kısa süre duvara tutundur
    görsel parçacık ve ses geri bildirimi üret

oyuncu çıkışa ulaşınca:
    aynı mekaniği düşük riskli bir engelde tekrar kullan

Bu kod gerçek bir oyun motoruna bağlı değildir; tasarımın mantığını gösterir. Yüksek çıkış hedefi belirler, karşılıklı duvarlar çözüm alanını sınırlar, güvenli zemin ise korkmadan denemeyi sağlar. Parçacık ve ses, duvarın özel bir davranış sunduğunu bildirir.

Tasarımcının görünmez eli

Başarılı bir zımni öğretimde oyuncu “Tasarımcı bana bunu öğretti” demez; “Ben bunu çözdüm!” der. Bu sahiplenme duygusu motivasyonu artırır. Ancak ipuçları fazla belirgin olursa keşif hissi kaybolur, fazla belirsiz olursa oyuncu sıkışır.

Bu nedenle iyi bir seviye önce mekaniği gösterir, sonra güvenle denetir, ardından farklı bir bağlamda sınar. Oyuncu kuralları okumak yerine yaşar. Görünmez öğretmenin en büyük başarısı da ders verdiğini hiç belli etmemesidir.