Murat Can Ümit

Çözüm mimarı ve kurucu. Yapay zekâ sistemlerini canlıya tek başıma çıkarıyorum; neyi iddia etmemeleri gerektiğini de biliyorum.

Bankacılık, havacılık, telekom ve danışmanlıkta on iki yıl. İki yapay zekâ ürününü uçtan uca ve tek başıma tasarladım, kurdum, işletiyorum: mimari, çıkarım, hak yönetimi, sürüm ve nöbet. Şu anda İstanbul'dayım.

01 — Sistem

Tactiq

Tactiq, 175 pazarda kullanıcısı olan canlı bir futbol maç analizi platformu. Buradan sonrası özellik listesi değil. Zor olan üç karar var; yanlış verseydim hiçbir şey çökmezdi, sadece aylarca yanlış çalışırdı. Sonra sistemin tamamı, tek seferde.

2a — Platform
İstemciler iOS · Android · web · macOS API Gateway gecikme tabanlı yönlendirme sağlık kontrolü failover us-east-1 80 fonksiyon birincil · toplu iş, kalibrasyon, turnuva eu-central-1 44 fonksiyon kullanıcı yolu ap-northeast-1 52 fonksiyon kullanıcı yolu Tek bölgeli otorite haklar · yenileme token'ları tek yazıcı atomik koşullu yazma her dakika yayılım active-active · 176 fonksiyon · 41 DynamoDB tablosu 16 Route 53 sağlık kontrolü 36 tablo global replike oluyor, beşi bilinçli olarak replikasyon dışında
İstemciler iOS · Android · web · macOS API Gateway gecikme tabanlı yönlendirme sağlık kontrolü failover us-east-1 80 fonksiyon birincil · toplu iş, kalibrasyon, turnuva eu-central-1 44 fonksiyon kullanıcı yolu ap-northeast-1 52 fonksiyon kullanıcı yolu Tek bölgeli otorite haklar · yenileme token'ları tek yazıcı · atomik koşullu yazma her dakika yayılım active-active · 176 fonksiyon 41 DynamoDB tablosu · 16 Route 53 kontrolü 36 tablo global replike oluyor, beşi bilinçli olarak replikasyon dışında

Üç bölge, bir istisna

Üç AWS bölgesinde, API Gateway'in arkasında üretimde çalışan yüz yetmiş altı Lambda fonksiyonu var; gecikme tabanlı yönlendirme ve on altı Route 53 sağlık kontrolü kullanılıyor. Kırk üç ayrı fonksiyon üç bölgeye birden replike ediliyor ve active-active çalışıyor. Geri kalanı bilerek tek bölgede duran zamanlanmış işler ve backfill'ler, çünkü bir cron'u üç bölgede koşturmak aynı durum üzerinde yarışan üç yazar üretir. Dağılım simetrik değil, bilinçli: us-east-1 seksenini taşıyor ve toplu işleri, kalibrasyonu ve turnuva yüklerini o çalıştırıyor; eu-central-1 ile ap-northeast-1 kırk dört ve elli iki ile kullanıcı trafiğini karşılıyor. Tokyo'daki kullanıcıya ve Frankfurt'takine farklı bölgeler hizmet veriyor, ikisi aynı ürünü görüyor.

Durumu kırk bir DynamoDB tablosu tutuyor. Otuz altısı üç bölgeye birden replike oluyor. Beşi olmuyor ve asıl tasarım kararı bu istisnada: ücretli hak ve yenileme token'ları tek bölgeli otoritede duruyor, tek yazıcı ve atomik koşullu yazmayla. Karar her dakika dışarı yayılıyor ve her bölge onu replikasyondan değil oradan okuyor. Yayılım ile uzlaştırma iki ayrı iş: yayılım olay tetikli ve dakikalar mertebesinde, uzlaştırma ise haftalık çalışıp defteri mağaza dışa aktarımıyla karşılaştırıyor. Kimin ödediğine dair gerçeği mağazalar tuttuğu için sapmayı kendimize karşı değil kaynağa karşı ölçmek gerekiyor. Beş dakikada bir çalışan yoklama işi bölgeler arası gecikmeyi ölçüyor ve alarm veriyor; göremediğiniz replikasyon gecikmesiyle hiç replike olmamak arasında fark yoktur.

Çok bölgeli last-writer-wins, bir paket değişikliğini sessizce düşürene kadar sorunsuz görünür. Ücretli erişimini kaybeden müşteriyi ise alarmdan değil, öfkeli bir mesajdan öğrenirsiniz.

2b — Korumalar
İstek Uygulama doğrulaması HMAC istek imzası İmzalı kısa ömürlü token fail-closed fail-closed fail-closed Üretim Dayanak kontrolü Şema doğrulaması Dil denetimi sunucu otoriteli şekil zorunlu yalnızca istenen dil Önbellek kararı Yanıt Reddedildi atılır, onarılmaz akış kontrol ve otorite reddedilen HMAC, JWT ve toplu iş anahtarları, bölge başına dil uyuşmazlığı isimli bir alarm tetikliyor
İstek Uygulama doğrulamasıfail-closed HMAC istek imzasıfail-closed İmzalı tokenfail-closed Üretim Dayanak kontrolüsunucu otoriteli Şema doğrulamasışekil zorunlu Dil denetimiistenen dil Önbellek kararı Yanıt Reddedildi atılır, onarılmaz akış kontrol ve otorite reddedilen HMAC, JWT ve toplu iş anahtarları, bölge başına dil uyuşmazlığı isimli bir alarm tetikliyor

Talimat değil, yapısal zorlama

İstek modele ulaşmadan önce üç kontrol çalışır: uygulama doğrulaması, HMAC istek imzası ve imzalı kısa ömürlü token. Üçü de şüpheye düştüğünde geçirmek yerine reddediyor. Biri bile doğrulanamıyorsa istek orada biter.

Model çıktıyı verdikten sonra sıra denetime gelir: sunucunun belirlediği gerçeklik katmanı, şema doğrulaması ve dil denetimi. Önbelleğe alma kararı ancak bunlardan sonra veriliyor. Model, sunucunun vermediği bir sayıyı üretemez, şemanın kabul etmediği bir şekli döndüremez, isteğin sormadığı bir dilde yanıt veremez. Başarısız çıktı yamanmaz, atılır.

Yalnızca prompt'a yazılmış kurallar sessizce çöker; bunu sosyal medyaya düşen bir ekran görüntüsünden öğrenirsiniz.

2c — Kalibrasyon
Verilen tahminler Gerçek sonuçlar maç biter, sayı sabittir Derecelendirme Güven bandına göreisabet oranı Referans çizgisine görekalibrasyon hatası mutlak hedef değil Sapma alarmı eşik aşımı Elle geri alma haftalık döngü haftalık yeniden eğitim Pazar 22:00 UTC · altı saatte bir artımlı izleme · Pazartesileri karşı-olgusal tekrar ince örneklem bekletilir, yeniden fit edilmez tespit otomatik, müdahale elle yapılıyor
Verilen tahminler Gerçek sonuçlarmaç biter Derecelendirme Güven bandına göre isabet Referans çizgisine göre hata Sapma alarmıeşik aşımı Elle geri alma ↺ haftalık döngü haftalık yeniden eğitim Pazar 22:00 UTC altı saatte bir artımlı izleme ince örneklem bekletilir, yeniden fit edilmez tespit otomatik, müdahale elle

Canlı referans çizgisine karşı ölçüm

Sistem her hafta kendi tahminlerini gerçek sonuçlarla karşılaştırıp puanlıyor ve güven bandı başına isabet oranını hesaplıyor. Belirtilen güven ile gözlenen doğruluk arasındaki fark kalibrasyon hatasıdır. Bu fark eşiği aştığında, üstelik yalnızca örneklem anlamlı bir büyüklüğe ulaşmışsa, sapma alarmı çalıyor. Geri alma ise runbook üzerinden elle yapılıyor. Otomatik olan tespit, müdahale değil.

Karşılaştırma mutlak bir hedefle değil, canlı bir referans çizgisiyle yapılıyor; mutlak hedefi zaten siz seçersiniz. Futbol ise sabit bir takvimde kimin haklı olduğunu kendisi söyler ve pazarlık etmez.

İstesem bile kendimi övecek bir değerlendirme kuramazdım.

2d — Sistemin tamamı

Bütünün şekli

Kullanıcı yolu bunun en küçük parçası. Sistemin büyük kısmı kimse bakmazken çalışıyor: her biri kendi verisinin değişme hızına göre yoklanan sağlayıcılardan veri senkronizasyonu; takım derecelerini ve oyun tarzı profillerini haftalık yeniden hesaplayan tahmin motorları; kendi geçmiş işini derecelendiren kalibrasyon; ve bir kullanıcıyı uyandırmadan önce saat dilimini bilmek zorunda olan bildirim katmanı.

Dünya Kupası merkezi, kendi analiz, senkronizasyon, canlı ve doğruluk izleme fonksiyonlarıyla izole bir filo olarak kuruldu. Trafiği öngörülemeyen mevsimlik bir olay, yıl boyu çalışan bir ürünü çökertebilecek konumda olmamalı. Turnuva bitince filo başka hiçbir şeye dokunmadan kaldırılıyor.

Bunların hepsini bir kişi yazdı. Sınırların tam olarak orada olmasının sebebi de bu.

İSTEMCİLER
iOS · iPadOS
macOS · Android
32 yerel ayar
EDGE
API GATEWAY
3 REST API
10 HTTP API
bölge başına ~50 rota
CLOUDFRONT
küresel dağıtım
ROUTE 53
16 sağlık kontrolü
HESAPLAMA
KULLANICI YOLU
auth · authorizer · me · history
analyze · analyze-v2 · analyze-live
simulate · momentum · stats · search
TAHMİN
compute-v5-elo
style-profile · match-style-forecast
player-impact · counterfactual
KALİBRASYON
auto-calibration
calibration-tracker
weekly-monitor
bedrock-daily-report
VERİ SENKRONU
fixtures · teams · players
leagues · standings · injuries
xg-rolling · shot-profile
search-sync
BİLDİRİMLER
push-worker · match-reminder
daily-reminder · favorite-reminder
SQS kuyruğu + DLQ
TURNUVA
wc-26-analyze · wc-26-live
wc-26-sync · wc-26-accuracy-tracker
wc-26-push-scheduler
izole filo
PLATFORM
warmer · health · replication-canary
log-export · entitlement-sync
export-user-data · user-hard-delete
DURUM
DYNAMODB
41 tablo
36 global · 5 tek bölgeli
EN BÜYÜKLERİ
search-index 332k
football-data-v2 55k
player-impact 39k
analyses 20k
S3
11 bucket
SECRETS MANAGER
bölge başına rotasyon
her dakikadan aylığa 80 zamanlanmış iş · üç bölgede 65 CloudWatch alarmı
hazırlık ortamı kendi yetkilendiricisiyle paralel bir filo olarak çalışıyor
20.000+ kullanıcı32 dil175 pazar4 işletim sistemi
3 bölge176 fonksiyon üretimde41 tablo80 zamanlanmış iş65 CloudWatch alarmı
Tam teknik doküman Çalışırken görün: tactiq.club Stüdyo: mcvibeapps.com
02 — Envanter

Ayakta tutmanın maliyeti

Mimari diyagramlar bir sistemi olduğundan iyi gösterir. Tasarlanan parçaları gösterir, biriken parçaları gizler. Aşağıdaki sayılar hafızadan değil, canlı hesaptan alındı.

176
üç bölgede üretimde çalışan Lambda fonksiyonu
41
DynamoDB tablosu, 36'sı global replike
80
zamanlanmış iş, dakikalıktan aylığa
65
isimli eşikleri olan CloudWatch alarmı
13
API Gateway dağıtımı, REST ve HTTP
16
Route 53 sağlık kontrolü
11
S3 bucket'ı
6
normalize edilen dış veri sağlayıcısı
332.000
arama indeksinde satır
55.000
yuvarlanan istatistikli fikstür kaydı
39.000
oyuncu etki kaydı
9.900
güvenilirlik bantlı kalibrasyon kaydı
7.900
denetim kaydı
4
uçtan uca işlenen ödeme altyapısı
2
alarma bağlı sert bütçe tavanı
1
kişi

Bu rakamların bir kısmı kararların sonucu, bir kısmı bedeli. Seksen zamanlanmış iş bir övünme değil, farklı yenileme ritimlerine sahip altı veri sağlayıcısının gerçekten gerektirdiği şey. Altmış beş alarm, diğer vardiyada kimse yokken uyuyabilmek için gereken şey.

03 — Kararlar

Yine yapacağım beş karar

01

Çalışan özellikleri kapattım

Dil modelinin ürettiği iki piyasa, gerçek sonuçlara karşı derecelendirildiğinde ölçülmüş negatif beceri taşıyordu. Kimse şikâyet etmiyordu ve üründeki en çok kullanılan özellikler arasındaydılar. Silmedim: belgelenmiş kapalı durumu olan bir bayrağın arkasına aldım, yerlerine gerçek veriden türeyen deterministik bir hesap varsayılan oldu ve ekranda gösterilen olasılıklar iki uçtan sınırlandı. İzleyen ay gelir kaybettim, kullanıcıların daha uzun kaldığını gördüm. Bayrak hâlâ duruyor, yani karar deploy gerektirmeden geri alınabilir.

Ürün artık daha azını yapıyor ve kullanıcılar daha uzun kalıyor.

02

Bir alarmı görmezden geldim

Sezon dışında, yaklaşık seksen olaylık dar bir örneklemde sapma alarmı çaldı. Bunların onu yüksek güven bandındaydı. On olayla modeli yeniden eğitmek ona oyunu değil o iki haftayı öğretirdi, bu yüzden dokunmadım. İki hafta sonra dört yüz olayda kalibrasyon sağlıklı çıktı.

Değerlendirmenizin henüz bir şey söylemediğini bilmek, ne söylediğini bilmek kadar önemlidir.

03

Tek bir tabloya kendi mimarisini verdim

Bir tablo dışında tüm durum çok bölgeli. Ücretli hak, tek yazıcılı ve atomik koşullu yazma yapan tek bölgeli bir otoritede tutuluyor; diğer bölgeler onu kopyalamak yerine oradan okuyor. Nadiren kullanılan bir akışta biraz gecikmeye mal oluyor ve bütün bir sessiz hata sınıfını ortadan kaldırıyor. Bu tablo aynı zamanda türetilmiş durum, kaynak kayıt değil: kimin ödediğine dair gerçeği mağazalar tutuyor, dolayısıyla o bölgeyi kaybetmek bir failover değil yeniden inşa senaryosu.

Tutarlılığı sistemin tekdüze bir özelliği olarak görmeyi bıraktım.

04

Hazır makine öğrenmesi altyapısı kullanmadım

Öğrenme katmanı saf Python. Sunucusuz mimaride küçük ayak izi ve hızlı soğuk başlangıç doğrudan kazanca dönüşür; düzeltebildiğim şeffaf bir model, tek bir kaynak kaydığında hata ayıklaması zor olan kapalı bir modelden iyidir. Kalibrasyon oynadığında sebebini kayıp eğrisinden çıkarmıyorum, kodda okuyorum.

Daha etkileyici olan yerine daha ucuz, küçük ve incelenebilir olanı seçmek bir taviz değil, bir alışkanlık.

05

Kendi çıkarım harcamama sert bir tavan koydum

Hesapta alarmlara bağlı iki bütçe tavanı var: Bedrock çıkarımı için ayda üç yüz dolar, geri kalan her şey için beş yüz. Tavanı olmayan bir üretken ürün, birim ekonomisini bir fatura e-postasında keşfeder. Tavanı önce koymak, iki kademeli model yönlendirmesini, önbellek kurallarını ve hangi isteklerin daha güçlü bir modeli hak ettiği kararını zorunlu kıldı. Token harcamasında günlük bir rapor da aynı sebeple var.

Bunlar tahmin değil. Üzerinde isim yazan alarmlar.

04 — İkinci ürün

Naryu

Naryu, tek bir doğum kaydını Batı astrolojisi, Vedik astroloji, numeroloji, Human Design, BaZi ve feng shui alanlarında günlük kişisel rehberliğe dönüştürüyor. Okur otuz beş okuma tipini isteyebiliyor, bunların üzerine bir de günlük içerik üretiliyor. Ürün lansman öncesi aşamada; hesaplama katmanı, içerik hattı ve çıkarım yolu tamamlandı.

Kişiselleştirme katmanı üretken değil, deterministik. Bir Python motoru JPL efemerisinden gezegen konumlarını hesaplıyor ve haritayı üretiyor; ev sistemleri, ikincil progresyonlar, güneş dönüşleri, transitler, Vimshottari dasha dönemleri, dört BaZi sütunu ve Kua ile uçan yıldız ızgaraları da bu üretimin parçası. Her motor, yayına girmeden önce yayımlanmış referans haritalara karşı doğrulanıyor. Üretken katman Amazon Bedrock üzerinde çalışıyor ve hiçbir şey hesaplamıyor: hesaplanmış harita ona zemin gerçeği olarak veriliyor, model yalnızca yorumluyor, şemaya uymayan yanıt ise önbelleğe alınmak yerine atılıyor.

Bu karar, Tactiq'teki sunucunun belirlediği gerçeklik katmanıyla aynı karar ve birbirinden bağımsız iki alanda iki kez alındı. Her iki üründe de model, doğrulanabilir olanı hesaplamıyor.

Yanlış bir dereceye dayanan yorum, ne kadar iyi okunursa okunsun yanlıştır.

Hiçbir vektör okuru taşımaz

Kullanıcı başına vektör yok. Naryu'nun kuracağı her embedding indeksi kendi yazdığımız içeriğin üzerinde duruyor; asla okurun haritası, okumaları, günlüğü ya da geri bildirimi üzerinde değil. Bir natal harita parmak izidir: güneş burcu, Ay, yükselen ve birkaç açı, bir insanı dakikalar genişliğinde bir doğum penceresine ve bir konuma indirir. Dolayısıyla bir haritadan üretilen embedding, sözde-anonim bir tanımlayıcıdır; içinden doğum tarihini okuyamazsınız ama iki kaydı aynı kişi diye eşleştirebilirsiniz. GDPR'da bu, anonim veri değil kişisel veridir. Üstelik vektör deposu, seçici silmenin en zor olduğu bileşendir.

24 yerel ayarda 20 dilokurun isteyebildiği 35 okuma tipi~3.400 doğrulama
2 AWS bölgesi10 Lambda fonksiyonu17 fonksiyon dağıtımı12 DynamoDB tablosu
05 — Bulgu

statedintent

Kendi iki ürünümün dokümantasyonunu koda karşı denetledim. Altı iddia yanlış çıktı. Doküman geri almanın otomatik olduğunu söylüyordu; kodda bir alarm ve bir runbook vardı, iddia ise çoktan dokümanı terk edip CV'me ve on iş başvuruma yerleşmişti. Sekiz ay önce kaldırılmış bir kapı mimari dokümanda hâlâ anlatılıyordu. Bir paket dosyası kendini günlük bir cron işi diye tanıtıyordu, ama onu tetikleyen hiçbir zamanlanmış kural yoktu.

Bu her yazılım şirketinde var ve kimse sistematik olarak çözmüyor. Yapay zekâ üretimi hızlandırdı, doğrulamayı olduğu yerde bıraktı. Üretmek ucuz, kontrol etmek değil; aradaki makas problemin kendisi.

Yaklaşım tek cümleye sığıyor: bir kod tabanını oku, ne yaptığını çıkar, bunu bir insana onaylat, sonra dokümantasyonu beyan edilmiş niyete karşı denetle. Buradaki niyet bir duygu ya da plan değil, sistemin ne yapması gerektiğine dair kaydedilmiş karar. Üç seviye ayrı duruyor: kod kanıttır, mevcut doküman iddiadır, insanın onayı otoritedir.

Ne Tactiq ne Naryu, doğrulanabilir olanı modele hesaplatıyor. Aynı ilke şimdi düzyazıya uygulanıyor: bir iddia kanıtlanabilir olmalı. Üçüncü kez, üçüncü ilgisiz alanda.

Yanlış iddiaları bulan bir araç, kendi yanlış iddialarıyla ayakta kalamaz.

İlk denetlediği kod tabanı kendisi

Kendi kapılarını kendi CI hattında koşuyor ve orada kırmızıya düşebiliyor. Her kapı, yakalamak için var olduğu hatayı bilerek enjekte ederek doğrulanıyor. İki üründen üç dokümanda elli yedi iddia elle etiketlendi ve doğruluk bu kümeye karşı ölçülüyor. Kendi doğruluğunu ölçmeyen bir denetim aracı, eleştirdiği şeyin ta kendisidir.

etiketlenmiş 57 değerlendirme öğesi2 üretim ürününden 3 doküman5 MISALIGNED bulgu, 3'ü koda karşı
13 bloklayan CI kontrolü9'u bir kapının düşebildiğini kanıtlıyor1'i uyarıyor, bloklamıyorApache 2.0
06 — Öncesi

Bundan önceki on iki yıl

Kurumsal yıllar Doğan Dağıtım'da başladı. Yaysat ve Hürriyet DPP tarafında, 81 ildeki basın dağıtımı ve medya lojistiği operasyonlarının kurumsal web uygulamalarını ve PL/SQL veri işleme katmanını yazdım; bayi ağı portalları ve raporlamanın üzerinde çalıştığı veri ambarı da bu işin parçasıydı. Yazdığımız şeyin çıktısı bir ekran değildi; hangi aracın nereye gideceğiydi. Sonra BBVA Garanti Teknoloji'ye geçtim. Türkiye'nin en büyük özel bankalarından birinde CRM ve kampanya ekibinde, otuz sekiz milyon müşteri kaydına dokunan sistemlerde, hem güncel yığında hem mainframe tarafında çalıştım. Ardından Amadeus'ta, havacılık teknolojisi tarafında müşteri sadakat sistemlerinin arka ucunu geliştirdim; orada ölçekte doğruluk bir özellik değil, ürünün kendisi.

Sonra Tosia Tech'i kurucu ortak olarak kurdum ve bir fintek ürününden mobil oyunlara kadar portföyün tamamının ürün sorumluluğunu aldım. Blokzincir tabanlı ödeme ürününün fonu çekildiğinde değişimi ben yönettim: ekibi, teknolojiyi ve yol haritasını mobil ürünlere ve bir tedarikçi teslim modeline taşıdık. Şirket sonrasında stüdyoya dönüştü, yatırım aldı ve beş milyon kullanıcıyı geçti. Teknik kısım daha kolay olan yarısıydı.

Sonra Orion Innovation'a geçtim; kıdemli yazılım geliştirici olarak telekom platformları ve müşteri kabul süreçleri üzerinde çalıştım. Kendi birimim ise BlockchainIST Center'da oldu: üç buçuk yıl boyunca yedi kişilik bir mühendis ekibini yönettim, araştırma, danışmanlık ve ürün tarafında, bankacılık, sigorta ve kamu sektöründen kurumsal müşterilerle. Tekrar eden durum şuydu: teknolojisini çoktan seçmiş, ama problemini henüz adlandırmamış bir kurum gelirdi. İşin çoğu, talebin altındaki problemi bulmak ve bunu söylemekti.

Sonra Vodafone'a geçtim. Yirmiden fazla mühendislik ve iş ekibini kapsayan girişimlerde çözüm tasarımı yaptım; ekiplerin üstünde değil, kendi mimarlarıyla birlikte çalışarak. İki büyük projenin liderliği bendeydi. Kurum içi bir yapay zekâ ürününün teknik mimarlarından biriydim; tüm çalışan tabanını kapsayan kimlik ve erişim yönetimi modeli bu işteki payımdı.

07 — İletişim

Mimari, üst düzey mühendislik rolleri ve gerçek kullanıcılarla temasa dayanması gereken yapay zekâ sistemleri kuran ekipler üzerine konuşmalara açığım.

Şu anda İstanbul'dayım. İhbar süresi yok.