Kâğıt üzerinde özgeçmişim iki farklı kişiye aitmiş gibi görünüyor. Biri büyük veri için tensör ayrışımları üzerine yüksek lisans tezi yazmış. Diğeri on yılı aşkın süredir canlı sistemlerde C#, .NET ve SQL Server ile çalışıyor; son dönemde de on binlerce öğrencinin aynı dakikada geldiği sınav platformlarında. Ben bunları hiçbir zaman iki ayrı kariyer olarak yaşamadım. Araştırmada edindiğim alışkanlıklar, bir backend tasarlarken ya da incelerken en çok kullandıklarım; backend işi de matematiği okuma biçimimi değiştirmeye devam ediyor.
Bu not o kesişim üzerine. Bir eğitim yazısından çok bir görüş yazısı.
Zaman çizelgesinin kısa hâli
- 2011-2015: Urmiye Üniversitesinde Uygulamalı Matematik lisansı (B.Sc.).
- 2016-2019: Tarbiat Modares Üniversitesinde Bilgisayar Bilimleri yüksek lisansı (M.Sc.). Dr. Mansoor Rezghi danışmanlığında yazdığım "Big Data Learning with Tensor Representation" başlıklı tezim tc-SVD'yi ortaya koydu. 2018'de ve ardından 2020-2021 döneminde İleri Makine Öğrenmesi ile Veri Madenciliği derslerinde asistanlık yaptım.
- 2016-2018: Aktörlere yönelik özel bir sosyal ağ olan Withem'de .NET geliştirici.
- 2019: OmidanHozoor'da React ve React Native uygulamalarını yeniden geliştirdim, Swagger ile belgelenmiş sürümlü REST API'ler oluşturdum.
- 2020-2021: Refah Bankası döviz bürosu için serbest çalışan olarak, elektronik tablolara dayalı döviz havalesi muhasebesinin yerini alan bir back-office sistemi geliştirdim; odak noktası güvenilirlik, işlem bütünlüğü ve finansal veri tutarlılığıydı.
- 2021-2023: Gozine2'de önce full-stack, ardından kıdemli backend rolünde. Veritabanı yükünü azaltmak için raporlama sistemini yeniden tasarladım, Serilog ile yapılandırılmış loglamayı getirdim, sınav zirvelerinde 45.000 ile 70.000 arası eşzamanlı kullanıcıyı taşıyan Redis Sentinel yapısını tasarlayıp deploy ettim ve dört kişilik bir veri bilimi ekibi kurup yönettim.
- Ekim 2023'ten beri: NovaTech'te kıdemli backend mühendisi. Yaklaşık 89.000 öğrenciye hizmet veren IRT tabanlı uyarlamalı test platformunun mimarisini tasarladım; .NET 6/8 mikroservis geliştirmesine liderlik ediyor ve beş ya da daha fazla geliştiriciye mentorluk yapıyorum.
- 2024: Noraco ile uzaktan bir sözleşme: 5.000'den fazla soru için LLM ile etiketleme yapan bir PDF'ten LaTeX'e pipeline'ın otomasyonu.
Aşağıda araştırmadan bugüne taşıdığım dört alışkanlık var, kabaca çalışma biçimimi değiştirdikleri sırayla.
1. Verinin şekline saygı gösterin
Tezim bir şikâyetle başladı: standart reçete, bir görüntüyü ya da videoyu daha hiçbir şey öğrenmeden tek bir uzun vektöre dönüştürür ve bunu yaparken veriyi anlamlı kılan yapıyı çöpe atar. Komşu pikseller birbirinden uzağa düşer. Bir tensör her boyutu kendi modu olarak korur; üzerine kurulan yöntemler de bu yapıyı yeniden keşfetmek yerine doğrudan kullanabilir.
Backend sistemleri aynı hatayı farklı kılıkta yapar. Her şey tek bir geniş tabloya, tek bir JSON sütununa ya da her çağıranın yalnızca bir alanını okuduğu büyük bir nesneyi tutan tek bir önbellek anahtarına gider. Araştırmada sormayı öğrendiğim soru buraya doğrudan uyarlanır: bu veriye gerçekte hangi eksenler boyunca erişiliyor? Öğrenci bazında mı, sınav bazında mı, soru bazında mı, zaman içinde mi? Bunlar modlardır ve her biri farklı bir yer önerir.
Örneğin uyarlamalı test notunda, şekilleri tamamen farklı üç tür veri yan yana durur. Madde parametreleri küçüktür, her istekte okunur ve nadiren değişir; bu yüzden değişmez (immutable), süreç içi bir önbellekte durmalıdır. Bir oturumun yetenek kestirimi her cevapla değişen kısa bir dizidir; bu yüzden TTL ile Redis'te tutulmalıdır. Yanıtlar kalıcı kayıttır ve SQL Server'da durmalıdır. Üçünü aynı politikayla aynı depoya koyarsanız en az biri için yanlış seçim yapmış olursunuz.
2. Yeniden hesaplamayın, güncelleyin
Büyük ölçekli ayrışımlar üzerine literatürün büyük bir kısmı tek bir şeyle ilgilidir: yeni veri geldiğinde, elinizdeki faktorizasyonu sıfırdan yeniden hesaplamak yerine güncelleyebilir misiniz? Yeniden hesaplamak basit ve doğrudur; ölçeklenmeyi ilk tıkayan da tam olarak odur.
Backend işinde bildiğim en faydalı tek soru bu. Uyarlamalı bir testteki yetenek kestirimi iyi bir örnek: bir cevaptan sonraki sonsal dağılım, önceki sonsal dağılımın tek bir olabilirlik eğrisiyle çarpımıdır; bu yüzden oturum geçmişini hiçbir zaman baştan oynatmaz. Bu alışkanlığın en sık karşılığını aldığım yer raporlama. Her şeyi yeniden toplayan bir sorgu yazmadan önce, son çalıştırmadan bu yana neyin değiştiğini ve yalnızca onu güncelleyip güncelleyemeyeceğimi sorarım. Bazen cevap hayırdır, çünkü veri yeterince küçüktür ya da düzeltmeler çok sık gelir; o zaman zamanlanmış bir tam yeniden hesaplama gayet yeterlidir. Tek istediğim, bunun birinin bilerek verdiği bir karar olması.
3. Dürüstçe ölçün
Araştırma size, bazen acı bir şekilde, her benchmark'ta kazanan bir yöntemin genellikle karşılaştırmanın adil olmadığı anlamına geldiğini öğretir. Gerçek baseline'larla, aynı veri üzerinde karşılaştırırsınız ve yönteminizin nerede kaybettiğini, nerede kazandığı kadar açık biçimde raporlarsınız.
Performans çalışması tam olarak bu disiplini gerektirir ve onu atlamak kolaydır. Gozine2'de sınav zirvelerinden önce darboğazları bulmak için Locust ile yük testleri yaptım; uyduğum kurallar doğrudan laboratuvardan geliyor: herhangi bir şeyi değiştirmeden önce ölçün, her seferinde tek bir şeyi değiştirin, baseline'ı saklayın ve ortalamalar yerine yüzdeliklere bakın, çünkü yavaş istekler ortalamanın içinde saklanır. Öncesi ve sonrası ölçülmemiş bir optimizasyon bir görüştür; bazen iyi bir görüş.
4. Aracın arkasındaki matematiği okuyun
Araştırmada, bir yöntemin neyi varsaydığını okumadan ona güvenmemeyi öğrenirsiniz. Tezimdeki asıl gözlem de tam olarak bu türden gizli bir varsayımdı: t-çarpımı üçüncü boyutu sanki sonu başına bağlanıyormuş gibi ele alır; bu bazı veriler için zararsızdır, görüntüler için ise sessizce yanlıştır.
Canlı sistemlerde kullandığımız araçlar da varsayımlar gizler ve bu varsayımlar genellikle en kötü anda ortaya çıkar. Redis replikasyonu asenkrondur; bu yüzden bir failover, zaten onaylanmış yazma işlemlerini kaybedebilir. Maksimum bilgiye dayalı madde seçimi en ayırt edici maddeleri aşırı kullanır, çünkü bilgi fonksiyonunun ödüllendirdiği şey budur. Bir LLM her token'ı bir olasılık dağılımından seçer; temperature 0 çeşitliliği azaltır ama pratikte çıktıyı deterministik yapmaz. Bu gerçeklerin hiçbiri gizli saklı değil. Hepsi dokümantasyonda ya da matematikte duruyor; onu bir makaleyi okur gibi, yani önce varsayımları arayarak okuyan herkes için.
İki ayak birbirini nasıl besliyor
Şimdiye kadarki en belirgin buluşma noktası, sıralama, puanlama ve öneri algoritmaları üzerinde çalışan dört kişilik bir veri bilimi ekibini kurup yönettiğim Gozine2 oldu. Bu, bir ürün şirketinin içinde araştırma tarzı bir çalışmaydı ve sonuçlarının sınav zirveleriyle karşılaşan aynı sistemlerin içinde çalışması gerekiyordu; bu da işi gerçekçi tuttu.
NovaTech platformu aynı buluşmanın öbür tarafı. Sistemin her cevaptan sonra neyi hesaplaması gerektiğine madde tepki kuramı karar verir; bunu yaklaşık 89.000 öğrenciye hizmet veren bir platform için, üstelik öğrencilerin birçoğunun aynı anda geldiği anlarda yapıp yapamayacağına ise mühendislik karar verir. Noraco'da buluşma noktası bir veri pipeline'ındaki LLM'di; orada makine öğrenmesi derslerinde geçirdiğim yıllar beni işe yarar ölçüde şüpheci yapmıştı: bir model tamamen emin olup yine de yanılabilir. İnceleme konsolunu pipeline'ın bir parçası saymamın nedeni de bu.
Öğretmek bunların hepsini besledi. İleri Makine Öğrenmesi ile Veri Madenciliği derslerinde asistanlık yapmak, konuları başka birinin kullanabileceği kadar kesin anlatmaya beni zorladı; geliştiricilere mentorluk yapmak ve inceleme standartlarını belirlemek de büyük ölçüde buna dayanır.
Etki ters yönde de işliyor. Canlı sistemler bana araştırmanın nadiren ödüllendirdiği şeyleri öğretti: işletilebilirlik, hata modları, sabahın üçünde soracağınız soruya cevap veren loglama ve ekip arkadaşlarınızın bakımını yapabileceği gösterişsiz çözümün değeri. Artık bir makale okurken onu çalıştırmanın neye mal olacağını ve başarısız olduğunda ne olacağını soruyorum. Bu sorular beni daha yavaş, ama sanırım daha iyi bir okur yapıyor.
Neden ikisini de sürdürüyorum
Bir backend mühendisinin matematik diplomasına ihtiyacı olduğunu düşünmüyorum. Bu işin zor kısımlarının çoğu insanlarla, teslim tarihleriyle ve sıradan biçimlerde çöken sistemlerle ilgili. Ama verinin şeklinin ne olduğunu, bir aracın neyi varsaydığını ve bir sayının gerçekte neyi ölçtüğünü sorma alışkanlığı benim için herhangi bir framework'ten daha değerli oldu ve bu alışkanlığı korumanın, biraz araştırma yapmaya devam etmekten daha iyi bir yolunu bulamadım.
Bu sitenin iki ayağı olmasının nedeni bu. Tensör rehberleri, tezimdeki fikirlerden yola çıkarak araştırma tarafını sürdürüyor. Backend Notları öbür taraf; ikisini de mahdimolavi.ir üzerinde bulabilirsiniz. Bir sonraki not canlı sistemlerdeki işe geri dönüyor: ASP.NET Core'da Serilog ile yapılandırılmış loglama.
Bu not İngilizce ve Farsça olarak da yayımlandı: İngilizce · Farsça.