Architecting offline-first generative AI applications for edge deployments using AWS services · Ahmed Ewis
Yazı somut bir rakamla açılıyor: Siemens'in raporuna göre Fortune 500 şirketleri plansız duruşlar yüzünden yılda tahmini 1,4 trilyon dolar kaybediyor — ve bu kayıp, sorunu hızlı tespit edip çözecek bilgi eksikliğiyle ağırlaşıyor. Üretken AI umut verici bir çözüm, ama endüstriyel ortamlarda ayrı bir mimari problem çıkarıyor: bulut bağlantısının güvenilmez ya da hiç olmadığı yerlere büyük ölçekli AI'ı nasıl taşırsın?
Cevap offline-first (offline-first) mimari: inference’ı uca taşı, bulutu ise model özelleştirme, dağıtım orkestrasyonu ve sürekli iyileştirme için kullan. Yani bulut karar vermez, hazırlar. Kritik yol tamamen yerelde çalışır.
Örnek senaryolar mimariyi somutlaştırıyor: bakım ekiplerinin canlı log akışlarıyla ilgili makine kılavuzlarını eşleştirememesi; uydu bağlantısı sınırlı açık deniz platformları ve boru hattı ekiplerinin güvenlik prosedürlerine ve mevzuat belgelerine anında erişme ihtiyacı; hassas tarım ekipmanı kullanan uzak tesisler.
Öne çıkanlar
- Temel ilke: kritik yol yerelde, iyileştirme bulutta. Bağlantı koptuğunda sistem bozulmaz, sadece güncellenmez.
- Uçta çalıştırmak model boyutunu kısıtlar — küçük model + iyi retrieval, büyük model + kötü bağlantıya yeğdir.
- Bu desen AI'a özgü değil: offline-first mobil uygulamalar yıllardır aynı mantıkla çalışıyor.
Neden önemli?
"Bağlantı her zaman var" varsayımı, yazılım mimarisinin en yaygın sessiz varsayımlarından biri. Bu varsayımı kaldırdığın anda tasarım değişir: durum nerede tutulur, çakışma nasıl çözülür, kullanıcı ne zaman uyarılır? Bu soruların cevabını baştan vermek, sonradan eklemekten çok daha ucuzdur.
Pratikte
Offline sync yaptıysan bu yazı onu daha iyi anlatabilmeni sağlar: offline-first tasarımın zor kısmı veriyi saklamak değil, conflict resolution ve idempotency’dir. Kullanıcı çevrimdışıyken bir kaydı iki kez gönderirse ne olur? Sunucudaki hâli daha yeniyse hangisi kazanır? Mülakatta ‘offline sync yaptım’ demek yerine ‘her isteğe istemci tarafında üretilen bir idempotency key koydum, sunucu aynı key’i ikinci kez görürse işlemi tekrarlamıyor’ diyebilmek seviye farkıdır.
Sözlük
- offline-first
- Sistemin bağlantı olmadan da tam çalışacak şekilde tasarlanması; bağlantı bir iyileştirme, önkoşul değil.
- edge inference
- Modelin bulutta değil, verinin üretildiği cihaz ya da yerel sunucuda çalıştırılması.
- idempotency
- Aynı isteğin birden çok kez işlenmesinin, bir kez işlenmesiyle aynı sonucu vermesi.
SymptomAI: Towards a conversational AI agent for everyday symptom assessment
Google Research, semptom değerlendirmesi yapan konuşma tabanlı AI prototipleriyle ulusal ölçekte bir karşılaştırmalı çalışma yürütmüş. İlgi çekici kısım tıp değil, deney tasarımı.
13.917 gönüllü katılımcı, semptomlarını beş farklı SymptomAI agent’ından birine anlatmış — her agent görüşmeyi farklı esneklik derecesinde yürütüyor. Yani tek bir sistemi test etmemişler, varyasyonları rastgele atamışlar.
Değerlendirme de iki katmanlı. Birincisi: klinisyenler, SymptomAI'ın ürettiği ayırıcı tanıyı (DDx) diğer klinisyenlerin verdiğiyle karşılaştırmış — vakaların %50'sinden fazlasında SymptomAI'ınkini tercih etmişler. İkincisi: tanılar, katılımcıların görüşme öncesi Fitbit cihazlarından gelen biyosinyallerle karşılaştırılmış.
Öne çıkanlar
- Rastgele atanmış varyantlar, tek bir sistemi test etmekten çok daha fazla bilgi veriyor: hangi tasarım tercihinin işe yaradığını gösteriyor.
- Bağımsız bir sinyalle (giyilebilir cihaz verisi) çapraz doğrulama, insan yargısının tek başına yeterli olmadığı yerlerde güven artırıyor.
Pratikte
Buradaki yöntemi kendi LLM özelliklerine uygula. ‘Prompt’u iyileştirdim, daha iyi oldu’ cümlesi ölçüm değildir. İki prompt varyantı kur, aynı girdileri ikisine de ver, çıktıları körlemesine (hangisi hangisi bilmeden) değerlendir. Örneğin bir gramer düzeltme özelliği için 30 örnekten oluşan sabit bir test seti kurmak, her prompt değişikliğinde bir sayı vermeni sağlar. Bu seti bir kere kurmak, sonraki her kararı kolaylaştırır.
Sözlük · 2 terim
- differential diagnosis (DDx)
- Belirtilere uyan olası hastalıkların olasılık sırasına göre listelenmesi.
- randomized variant
- Katılımcıların farklı sistem sürümlerine rastgele dağıtılması; hangi tasarımın etkili olduğunu ayırt etmeyi sağlar.
Building a serverless AI assistant at Pelago: concept to care in two weeks
Pelago, madde kullanım bozukluğu desteği veren bir dijital klinik. Mühendislik ekibi, bakım ekibine önerilen değerlendirmeler üreten olay-güdümlü bir AI asistanını AWS serverless servisleriyle (Bedrock, Lambda) iki haftada kurmuş.
Kısıtlar öğretici: davranışsal sağlık konuşmaları haftalar ve aylar boyunca birikiyor; koçların her cevapta bu geçmişi hesaba katması gerekiyor. Yani sistem tek bir mesaja değil, uzun bir ilişkiye bakmak zorunda.
Kritik tasarım kararı ise şu: sistem insanı döngüde tutuyor. AI hastaya cevap yazmıyor; bakım ekibine bağlama duyarlı öneriler sunuyor, kararı insan veriyor. Sağlık alanının gerektirdiği denetim korunurken aylarca sürecek geliştirme işi ortadan kalkıyor.
Öne çıkanlar
- Olay-güdümlü mimari: yeni bir mesaj geldiğinde tetiklenen Lambda, sürekli çalışan bir servise göre hem ucuz hem basit.
- "AI öneriyor, insan karar veriyor" ayrımı, riskli alanlarda ürünü hem kullanılabilir hem savunulabilir kılıyor.
Pratikte
Human-in-the-loop (human-in-the-loop) deseni, senin de varsayılanın olmalı. Bir LLM özelliğini üretime alırken sor: çıktı doğrudan kullanıcıya mı gidiyor, yoksa bir insan onayından mı geçiyor? İkincisi hem riski düşürür hem de sana etiketlenmiş veri kazandırır — insanın neyi düzelttiği, modelin nerede yanıldığının en iyi kaydıdır. Ayrıca olay-güdümlü mimariye dikkat et: Spring Boot'ta her şeyi senkron HTTP ile yapmak yerine, ağır işleri bir olay kuyruğuna atmak hem yanıt süresini düşürür hem sistemi dayanıklı kılar.
Sözlük · 2 terim
- human-in-the-loop
- Otomatik sistemin çıktısının, etki doğurmadan önce bir insan tarafından onaylandığı tasarım.
- event-driven architecture
- Bileşenlerin birbirini doğrudan çağırmak yerine olay yayınlayıp dinleyerek haberleştiği mimari.
Towards a quantum computer that learns from its errors
Google Quantum AI, reinforcement learning’i (RL) quantum error correction’le birleştirip bir kuantum bilgisayarın sürüklenmeye (drift) sürekli uyum sağlayabildiğini ve uzun hesaplamalar boyunca kararlı kalabildiğini göstermiş.
Problemin analojisi güzel: bir orkestrada kemanlar birkaç ölçüde bir akordunu kaybetseydi, topluluk sürekli durup akort yapmak zorunda kalırdı. Kuantum bilgisayar işletmenin bugünkü gerçeği bu. Kuantum bilgisayarlar temelde analog makineler ve sürüklenmeye duyarlı; güvenilir çalışma için kontrol parametrelerinin (frekans, genlik, faz) sürekli yeniden kalibre edilmesi gerekiyor.
Zorluk şurada: konser salonunda akortsuz enstrüman hemen duyulur, kuantum dünyasında böyle bir lüks yok — qubit'leri ölçmek kuantum üst üste binme durumlarını çökertiyor. Yani "dinlemenin kendisi performansı bozuyor". Çözüm, otonom bir agent’ın hata tespitlerinden öğrenerek binlerce parametreyi sürekli yönlendirmesi.
Öne çıkanlar
- Sistemin durumunu doğrudan ölçemediğinde, dolaylı sinyallerden (hata tespitleri) öğrenmek tek yol.
- Sürekli calibration, tek seferlik ayardan farklı bir mühendislik problemi: sistem değişiyor, ayar da değişmeli.
Pratikte
Kuantum alanın değil ama desen tanıdık olmalı: sistemin gerçek durumunu doğrudan göremiyorsan dolaylı sinyallerden çıkarım yap ve sürekli düzelt. Bir trading stratejisinin ‘gerçek kârlılığını’ anlık göremezsin; getiri, drawdown ve slippage gibi dolaylı sinyallerden çıkarırsın. Ve piyasa koşulları değiştikçe parametrelerin de değişmeli: bir kez ayarlanıp unutulan bir strateji, sürüklenen bir kuantum bilgisayar gibidir.
Sözlük · 3 terim
- drift
- Bir sistemin parametrelerinin zamanla yavaşça kayması; ilk ayarların geçersizleşmesi.
- reinforcement learning (RL)
- Bir agent’ın deneme-yanılma ve ödül sinyaliyle karar politikasını öğrenmesi.
- quantum error correction
- Kuantum bilgisayarlarda gürültü kaynaklı hataları tespit edip düzelten teknikler bütünü.