Argus Teknoloji: Makine Öğrenmesi Proje Mühendisi

2019-2025 yılları arasında Ankara'da Argus Teknoloji ile proje bazlı Makine Öğrenmesi Proje Mühendisi olarak çalıştım. Bu dönemde bilgisayarlı görü, derin öğrenme, örüntü tanıma, sinyal işleme ve performans odaklı yazılım geliştirme üzerinde yoğunlaştım.

Argus dönemindeki çalışmaların kamuya açık anlatımı; müşteri, veri kümesi, saha sistemi ve proje mimarisi gibi ayırt edici ayrıntılar yerine bilgisayarlı görü, derin öğrenme, örüntü tanıma, sinyal işleme ve yüksek performanslı hesaplamada karşılaştığım mühendislik problemlerine odaklanır.

C ve C++ başta olmak üzere Python, OpenCV, CUDA, OpenMP, Keras ve TensorFlow kullandım. Çalışmaların önemli bölümü Debian tabanlı Linux ortamlarında yürüdü. Bu dönem, "model doğruluğu" ile "üretimde kullanılabilir yapay zeka bileşeni" arasındaki farkı performans, veri işleme ve kaynak yönetimi üzerinden daha sistematik ele aldığım çalışma dönemidir.

Bilgisayarlı Görüyü Bir İşlem Hattı Olarak Ele Almak

Bir görüntü işleme veya derin öğrenme sisteminin performansı yalnız model çağrısının süresi değildir. Görüntünün alınması, decode edilmesi, renk uzayı veya boyut dönüşümü, normalizasyon, model girdisinin hazırlanması, inference, post-processing ve sonucun uygulamanın geri kalanına aktarılması aynı uçtan uca gecikmeye katkı verir.

Bu nedenle bilgisayarlı görü çalışmalarında modeli ayrı bir kutu gibi ele almamaya başladım. Bir optimizasyonun gerçek değeri toplam işlem hattında ölçülmediği sürece modelin birkaç milisaniye hızlanması sistem seviyesinde anlamlı olmayabilir.

OpenCV ile yapılan ön işleme ve klasik görüntü işleme adımları, derin öğrenme modeli kadar önemli olabiliyordu. Yanlış veya tutarsız preprocessing, güçlü bir modelin doğruluğunu doğrudan düşürebilir; gereksiz bellek kopyaları ise GPU hızlandırmasının kazancını azaltabilir.

C/C++ ile Performans Duyarlı Bileşenler

Performansın kritik olduğu işlem adımlarında C ve C++ kullandım. Bunun nedeni yalnız daha düşük seviyeli dil tercih etmek değildi; bellek yerleşimi, veri kopyası, döngü yapısı ve paralelleştirme üzerinde daha açık kontrol gerektiği durumlar vardı.

Büyük görüntü dizilerinde veya tekrarlanan özellik çıkarımı işlemlerinde algoritmik karmaşıklık ile bellek erişim biçimi birlikte önemlidir. Teorik olarak aynı karmaşıklıktaki iki uygulama, cache davranışı ve veri yerleşimi nedeniyle oldukça farklı sürelerde çalışabilir.

Bu dönemden itibaren performans sorunlarını yalnız profiler çıktısındaki en pahalı fonksiyon olarak görmemeye başladım. CPU'nun hangi veriyi beklediği, verinin kaç kez kopyalandığı, I/O'nun hesaplamayı ne kadar beklettiği ve paralelleştirme ek yükünün gerçek kazancı azaltıp azaltmadığı aynı ölçümün parçalarıydı.

OpenMP ile CPU Paralelliği

CPU üzerinde bağımsız veya bölünebilir iş yüklerinde OpenMP ile paralel hesaplama kullandım. Burada amaç her döngünün başına parallel for eklemek değildi.

İş parçalarının ne kadar dengeli dağıldığı, paylaşılan veri erişiminin kilit veya cache contention üretip üretmediği ve paralel bölgenin yeterince büyük olup olmadığı değerlendirilmeliydi. Küçük bir iş yükünü çok sayıda thread'e dağıtmak, senkronizasyon ve scheduling maliyeti nedeniyle tek thread'den daha yavaş olabilir.

Bu nedenle paralellik kararını veri boyutu ve gerçek ölçümle vermeye çalıştım. Thread sayısı, iş parçalama biçimi ve bellek erişimi birlikte değerlendirildiğinde daha öngörülebilir sonuçlar elde ediliyordu.

CUDA ve CPU/GPU İş Bölümü

GPU tarafında CUDA kullanırken en önemli konulardan biri hesaplama maliyeti ile veri taşıma maliyetini ayırmaktı. GPU üzerinde çok hızlı çalışan bir kernel, her çağrıda büyük miktarda veriyi CPU ile GPU arasında taşımak zorundaysa uçtan uca beklenen kazancı sağlamayabilir.

Bu nedenle hangi işlemin GPU'ya taşınacağı, verinin GPU belleğinde ne kadar süre tutulabileceği, kernel çağrılarının granülaritesi ve CPU tarafında kalması daha mantıklı olan adımlar üzerinde çalıştım.

Bilgisayarlı görü ve matris ağırlıklı işlemlerde GPU doğal bir hızlandırıcı olabilir; ancak "GPU kullanıldı" tek başına performans sonucu değildir. Toplam latency, throughput, bellek kullanımı ve aktarım maliyeti birlikte ölçülmelidir.

Bu yaklaşım daha sonraki IBM POWER9 ve GPU tabanlı adli bilişim / yapay zeka çalışmalarımda da devam etti. POWER9 üzerinde heterojen hesaplama çalışmalarım, CPU SIMD, OpenMP ve CUDA'yı aynı hesaplama problemi içinde değerlendirdiğim sonraki dönemin daha kapsamlı örneklerindendir.

Derin Öğrenme ve Model Geliştirme

Keras ve TensorFlow ile derin öğrenme modelleri üzerinde çalıştım. Model geliştirmede veri hazırlama, eğitim, doğrulama ve çıkarım aşamalarının birbirinden ayrılması gerektiğini pratikte deneyimledim.

Eğitim verisinde iyi sonuç veren modelin saha verisinde aynı davranışı göstermesi garanti değildir. Görüntü ölçeği, aydınlatma, sıkıştırma, kamera özellikleri veya preprocessing farkı dağılımı değiştirebilir.

Bu nedenle yalnız accuracy gibi tek bir metriğe bakmak yerine hata sınıflarının niteliğini, false positive / false negative dengesini ve sistemin yanlış karardan nasıl etkilendiğini değerlendirmek gerekir.

Proje gereksinimine göre gecikme, throughput veya doğruluk önceliği değişebiliyordu. Bir batch işleme sistemiyle interaktif görüntü işleme sisteminin aynı model seçme kriterlerine sahip olmaması gerektiğini bu dönemde daha belirgin biçimde uyguladım.

Örüntü Tanıma ve Özellik Temsili

Derin öğrenme dışındaki örüntü tanıma yaklaşımları da çalışma alanımdaydı. Görüntü veya sinyalin doğrudan ham hali yerine, problemin ayırt edici bilgisini taşıyan özelliklerin seçilmesi ve karşılaştırılması üzerine çalıştım.

Klasik özellik çıkarımı ile öğrenilmiş özellik temsillerini birbirinin alternatifi olarak değil, problem ve veri miktarına göre farklı araçlar olarak ele aldım. Bazı problemlerde daha basit bir özellik ve sınıflandırıcı, daha düşük hesaplama maliyeti ve daha açıklanabilir hata davranışı sağlayabilir.

Bu, daha sonra benzerlik arama, yüz tanıma ve ses işleme çalışmalarımda da devam eden bir yaklaşım oldu: en karmaşık model otomatik olarak en iyi sistem tasarımı değildir.

Sinyal İşleme Perspektifi

Argus dönemindeki çalışmalar yalnız görüntüden ibaret değildi; sinyal işleme ve örüntü tanıma problemleri de aynı performans yaklaşımıyla ele alındı.

Filtreleme, dönüşüm, pencereleme veya özellik çıkarımı gibi işlemlerde sayısal doğruluk, örnekleme ve veri boyutu kadar hesaplama maliyeti de önemlidir. Özellikle büyük veri üzerinde tekrarlanan dönüşümlerde gereksiz allocation veya kopyaların toplam maliyeti büyüyebilir.

Bu alan daha sonraki konuşma ve ses işleme çalışmalarım için de doğrudan bir temel oluşturdu.

Python ve Native Kod Arasında Sınır

Python hızlı deney, veri hazırlama ve model geliştirme için güçlü bir ortam sağlıyordu. Ancak performansın kritik olduğu bütün işleri Python seviyesinde tutmak her zaman doğru değildi.

Bu nedenle işin niteliğine göre Python ile C/C++ veya GPU tabanlı bileşenler arasında sınır kurdum. Yüksek seviyede orchestration ve deneysel çalışma Python'da kalabilirken, yoğun döngüler veya mevcut native kütüphaneler daha düşük seviyede çalışabiliyordu.

Buradaki amaç "Python yavaştır" gibi genelleyici bir yaklaşım değildi. Asıl soru, darboğazın gerçekten dil seviyesinde olup olmadığı ve native sınıra geçmenin toplam karmaşıklığa değip değmediğiydi.

Linux Üzerinde Geliştirme ve Çalıştırma

Debian tabanlı Linux sistemleri bu çalışmaların önemli bir çalışma ortamıydı. Derleme zinciri, native bağımlılıklar, GPU sürücüleri ve Python paketleri aynı uygulamanın tekrarlanabilir biçimde çalışmasını etkileyebiliyordu.

Model veya kaynak kod aynı olsa bile kütüphane ve sürücü sürümü değiştiğinde sayısal sonuç veya performans farklılaşabilir. Bu nedenle çalışma ortamını yalnız "sunucu kurulum" işi olarak değil, deneyin ve üretim davranışının bir parçası olarak ele aldım.

Latency ve Throughput Ayrımı

Bu dönemde performans değerlendirmesinde latency ve throughput kavramlarını daha açık ayırmaya başladım. Tek bir görüntünün ne kadar sürede işlendiği ile sistemin uzun süre boyunca saniyede kaç öğe işleyebildiği aynı soru değildir.

Batch size büyütmek throughput'u artırırken tek öğenin bekleme süresini yükseltebilir. GPU'yu daha dolu kullanmak toplam kapasiteyi artırabilir; fakat interaktif bir uygulamada kuyruk gecikmesi kullanıcı deneyimini bozabilir.

Bu nedenle performans kararlarında hedef metrik önce tanımlanmalıydı. "Daha hızlı" ifadesi ölçülmediğinde teknik gereksinim değildir.

Bellek, I/O ve Veri Hareketi

Görüntü ve model tabanlı sistemlerde hesaplama kadar veri hareketi de maliyetlidir. Diskten veya ağdan okuma, decode, matris kopyası, CPU/GPU transferi ve çıktı serileştirme birbirini takip ettiğinde işlemci bir sonraki veriyi bekleyebilir.

Bu nedenle CPU kullanımı düşük diye sistemin hesaplama açısından rahat olduğunu varsaymamak gerekir. Darboğaz I/O, bellek bant genişliği veya senkron bekleme olabilir.

Aynı nedenle bir optimizasyonu yalnız kernel süresine göre değerlendirmek yanıltıcı olabilir. Uçtan uca pipeline profili, gerçek kullanıcı veya servis gecikmesine daha yakındır.

Doğruluk ile Üretim Maliyeti Arasında Denge

Bir modelin doğruluk metriğinde küçük bir artış, inference maliyetini büyük ölçüde yükseltiyorsa bu artış her sistem için değerli olmayabilir. Model boyutu, bellek kullanımı, yükleme süresi ve eşzamanlı çalıştırılabilecek instance sayısı da kararın parçasıdır.

Bu dönemde model seçimini yalnız akademik metrikle değil, sistemin gerçek çalışma bütçesiyle birlikte değerlendirmeye alıştım. Daha küçük ve öngörülebilir bir model bazı senaryolarda daha yüksek teorik doğruluğa sahip ağır bir modelden daha iyi toplam sistem davranışı sağlayabilir.

Deneysel Kod ile Üretim Kodunu Ayırmak

Makine öğrenmesi çalışmalarında deneysel notebook veya prototip ile uzun süre çalışacak uygulama kodu aynı kalite beklentisine sahip değildir. Deney aşamasında hızlı değişiklik değerliyken üretim tarafında hata modeli, kaynak yönetimi, tekrar üretilebilirlik ve sürüm kontrolü daha önemlidir.

Bu nedenle işe yarayan bir deney sonucunu doğrudan üretim bileşeni saymadım. Veri hazırlama adımlarını açıklaştırmak, bağımlılıkları sabitlemek, input/output sözleşmesini tanımlamak ve hata durumlarını yönetmek gerekiyordu.

Modelden Yazılım Sistemine

Argus döneminde makine öğrenmesini giderek daha az "model dosyası" olarak görmeye başladım. Gerçek uygulamada model; veri hazırlama, doğrulama, kaynak yönetimi, concurrency, I/O ve servis ya da kullanıcı arayüzüyle aynı işlem hattında çalışıyordu.

Bu yüzden modelin doğruluğunu, gereken sürede ve kabul edilebilir kaynak bütçesiyle tekrar üretilebilir sonuç verebilmesinden ayrı değerlendirmedim. Performans duyarlı projelerde algoritma seçimi kadar verinin nerede dönüştürüldüğü, kaç kez kopyalandığı ve hangi donanımda tutulduğu da mimari karar haline geliyordu.

Gizlilik ve Kamuya Açık Teknik Anlatım

Müşteri, veri kümesi ve ürün mimarisini tanımlayan ayrıntıları kamuya açık metne taşımıyorum. Buna rağmen bu dönemin teknik içeriği; bilgisayarlı görü, sinyal işleme, temsil seçimi, CPU/GPU iş bölümü ve ölçülebilir performans hedefleri üzerinden somut biçimde anlatılabiliyor.

2019-2025 arasındaki çalışmalar, daha sonra adli bilişim ve büyük ölçekli yapay zeka sistemlerinde kullandığım model + veri hattı + donanım + performans bakışının önemli kaynaklarından biri oldu.