tag MLOps

MLOps (Machine Learning Operations) (Makine Öğrenimi Operasyonları)

Bu sayfada MLOps (MLOps (Machine Learning Operations) (Makine Öğrenimi Operasyonları)) etiketi ile işaretlenmiş 61 yapay zeka kavramını bulabilirsiniz.

MLOps (Machine Learning Operations), makine ogrenimi modellerini gelistirme, egitme, dagitma ve izleme sureclerini otomatlastirip standartlastiran bir muhendislik disiplinidir. DevOps kulturu ile veri bilimi pratiklerini bir araya getirir; amaci, ML modellerini guvenilir, olceklenebilir ve surdurulebilir bicimde uretim ortamina tasimaktir. Geleneksel yazilim gelistirme sureclerinde kod degisikliklerini yonetmek icin CI/CD pipeline'lari kullanilir. MLOps bu anlayisi model dunyasina tasir: veri kodu, egitim kodu ve model agirliklarinin hepsini ayni titizlikle surumler. Bir veri bilimci yeni bir model gelistirdiginde, MLOps altyapisi bu modeli otomatik olarak test eder, performansini gecmis modellerle karsilastirir ve onay kriterleri saglanirsa canli ortama baglar. Model kayit defteri (model registry), uretimde hangi modelin calistigini, hangi veri setiyle egitildigini ve hangi hiperparametrelerle yapilandirildigini merkezi olarak kaydeder. Bu sayede bir model sorun cikardiginda ekip, onceki surume dakikalar icinde geri donebilir. DVC (Data Version Control) gibi araclar veri surumlemesini yonetirken MLflow veya Weights & Biases deney izlemeyi ustlenir. Uretim ortaminda modellerin zamanla bozulmasi, yani model drift, MLOps'un cozdugu kritik sorunlardan biridir. Gelen gercek dunya verisinin dagilimi degistikce modelin tahmin kalitesi duser. Izleme katmani bu kaymayi erken tespit eder ve otomatik yeniden egitim tetikler ya da uyari gonderir. Google'in yayinladigi MLOps olgunluk modeli, sirketleri 0'dan 2'ye kadar uc seviyede siniflandirir: Seviye 0'da her sey manueldir; veri bilimciler modeli laptoplarinda egitip elle yukler. Seviye 1'de egitim pipeline otomatiktir. Seviye 2'de ise CI/CD her sey dahil olup pipeline'in kendisi de otomatik olarak guncellenir. MLOps'un uygulanmasi, yalnizca teknik degeril kulturel bir donusum da gerektirir. Veri bilimcileri, veri muhendisleri ve DevOps ekiplerinin ortak bir dil ve is akisi gelistirmesi gerekir. Bu kucultucuyu asabilen organizasyonlar, model dagitim surelerini haftalardan saatlere indirgeyip yapay zeka yatirimlarindan cok daha yuksek geri donus elde eder. **Sik Sorulan Sorular** **MLOps ile DevOps arasindaki temel fark nedir?** DevOps kod ve yazilim dagitimina odaklanirken MLOps buna ek olarak veri surumlemesi, model egitimi, hiperparametre yonetimi ve model drift izleme gibi ML'e ozgu katmanlari kapsar. **Kucuk bir ekip icin MLOps gerekli midir?** Tek bir modelle baslayan ekipler bile DVC ve MLflow gibi hafif araclarla temel MLOps pratiklerini benimsemelidir; aksi takdirde tekrarlanamaz deneyler ve kayip modeller kacunilmaz olur. **MLOps icin hangi programlama dili onceliklidir?** Python ekosistemi hakimdir: scikit-learn, TensorFlow ve PyTorch ile egitim; FastAPI veya BentoML ile servis; Airflow veya Prefect ile orkestrasyon. **Model drift ne kadar siklukla izlenmelidir?** Bu, verinin degisim hizina baglidir. Finansal dolandiricilik modelleri gercek zamanli izleme gerektirirken urun tavsiye sistemleri gunluk veya haftalik kontrol yeterli olabilir.

code_blocks

A/B Testi Nedir? Makine Öğrenmesinde A/B Testing (A/B Testi)

A/B testi, iki farklı sürümü (A kontrol, B deney) kullanıcılara rastgele göstererek hangisinin daha iyi performans gösterdiğini belirleyen istatistiksel bir deney yöntemidir. Makine öğrenmesinde model değerlendirmesinin temel taşı olan A/B testi; web uygulamalarından öneri sistemlerine, dil modellerinden görüntü sınıflandırıcılara kadar geniş bir alanda kullanılır. Testin çalışma mantığı şu adımlara dayanır: Kullanıcılar rastgele iki gruba ayrılır. A grubu mevcut sistemi (kontrol), B grubu yeni modeli veya özelliği (deney) deneyimler. Belirli bir süre sonra tıklama oranı, dönüşüm, RMSE veya doğruluk gibi metrikler karşılaştırılır; istatistiksel anlamlılık p-değeri ve güven aralığı ile ölçülür. Makine öğrenmesi ekipleri A/B testini şu senaryolarda kullanır: Yeni model sürümünü üretim ortamında doğrulama, hiperparametre değişikliklerinin gerçek etkisini ölçme, farklı öneri algoritmalarını kullanıcı katılımıyla karşılaştırma ve özellik mühendisliği değişikliklerinin işletme metriklerine katkısını ölçme. Sık karşılaşılan tuzaklar arasında erken sonuç okuma (peeping problem), çoklu karşılaştırma yanılgısı (Bonferroni düzeltmesi gerektirir), yeterli örneklem büyüklüğü hesaplamamak ve kullanıcı segmentasyonu farklarını göz ardı etmek sayılabilir. Sıralı A/B testi (sequential testing) ise bu sorunları azaltmak için erken durdurma kuralları kullanır. Kanary dağıtımı (canary deployment) ve gölge modu (shadow mode) A/B testinin üretim ortamında uygulandığı ileri düzey varyantlardır. Kanary dağıtımında yeni model yalnızca küçük bir trafik dilimine sunularak riskler sınırlandırılır; gölge modunda ise yeni model gerçek trafiği paralel olarak işler ancak kullanıcıya hiçbir zaman yanıt vermez. Türkiye'de büyük e-ticaret ve fintech platformları üretim ML sistemlerini bu yöntemlerle doğrulamaktadır. Yaygın araçlar: MLflow Experiments, Amazon SageMaker Experiments, Optimizely ve açık kaynak Wasabi. Interleaved (karışık) A/B testi ise öneri ve arama sistemleri için özel olarak geliştirilmiş bir varyantdır: A ve B sistemlerinin sonuçları tek bir listeye interleave edilerek kullanıcı tıklamaları üzerinden hangisinin daha iyi sıralama yaptığı çıkarılır. Bu yöntem, klasik A/B testi karşılaştırmasına göre çok daha hızlı istatistiksel güç elde etmeyi sağlar.

arrow_forward
science

A/B Testing (A/B Testi)

A/B testi (bölünmüş test veya ikili değerlendirme olarak da bilinir), iki farklı sürüm ya da yaklaşımın kontrollü bir deney ortamında karşılaştırıldığı istatistiksel bir yöntemdir. Makine öğrenimi ve yapay zeka sistemlerinde A/B testi; iki farklı modelin, algoritmanın, hiperparametre setinin veya ürün özelliğinin hangisinin belirli bir hedef metrikte daha iyi performans gösterdiğini nesnel biçimde kanıtlamak için kullanılır. Deney, kullanıcılar veya veri örneklemleri rastgele iki gruba ayrılarak yürütülür: kontrol grubu (A varyantı) mevcut veya temel çözümü kullanırken, tedavi grubu (B varyantı) yeni yaklaşımla test edilir. Her iki varyant eş zamanlı çalışır ve yeterli örnek büyüklüğüne ulaşıldığında istatistiksel anlamlılık testi (t-testi, chi-kare veya z-testi) uygulanır. Belirlenen güven eşiği (çoğunlukla yüzde doksan beş, p küçüktür 0.05) aşıldığında B varyantının gerçekten daha iyi olduğu kabul edilir ve üretim ortamına alınır. Makine öğrenimi ve MLOps bağlamında A/B testi; öneri motorlarının, sıralama algoritmalarının, doğal dil işleme modellerinin ve üretken yapay zeka çıktılarının nesnel olarak karşılaştırılmasında kritik rol oynar. Deney öncesinde gerçekleştirilen A/A testi, her iki grupta da aynı versiyon kullanılarak sistemin güvenilirliğinin doğrulanmasını sağlar. Endüstride Netflix, Spotify, Amazon ve Google gibi şirketler yılda binlerce eş zamanlı A/B deneyi yürütmektedir. Multi-armed bandit algoritmaları, keşfetme aşamasındaki kaybı azaltmak için en iyi varyanta trafik payını dinamik olarak yönlendirir. Modern Bayesian A/B testi, posterior dağılım güncellemesiyle önceki bilgiyi analize dahil ederek daha az örneklemle güvenilir sonuçlar üretir. Arama ve sıralama sistemlerinde kullanılan interleaving yöntemi ise iki sonuç listesini iç içe geçirerek son derece az trafikte hızlı karşılaştırma yapar. A/B testi, veri odaklı karar alma süreçlerinin temel taşı olup yazılım ve MLOps ekiplerinin her özellik veya model güncellemesini kanıta dayalı biçimde değerlendirmesini sağlar.

arrow_forward
code_blocks

API Gateway (API Gateway)

API Gateway (API Ağ Geçidi), istemci uygulamalardan gelen istekleri arka uç hizmetlere ileten ve bu süreçte kimlik doğrulama, hız sınırlama, yük dengeleme ile istek yönlendirme gibi çapraz kesen işlemleri tek bir noktada yöneten bir ara yazılım bileşenidir. Mikroservis mimarilerinde, onlarca farklı servis için bu işlevleri tek tek kodlamak yerine merkezi bir giriş noktası oluşturmak geliştirme sürecini sadeleştirir, tutarsızlıkları önler ve güvenlik politikalarının tek noktadan uygulanmasını kolaylaştırır. Yapay zeka ve büyük dil modeli (LLM) altyapısında API Gateway ek bir stratejik önem taşır. LiteLLM, Portkey ve Helicone gibi LLM-özgü gateway araçları, OpenAI, Anthropic, Google Gemini ve açık kaynaklı modeller gibi farklı sağlayıcıları tek bir uç nokta üzerinden sunar. Bu yaklaşım, sağlayıcı değişikliklerini uygulama koduna dokunmadan gerçekleştirmeyi, token kullanımını izlemeyi ve maliyet tahsisini yönetmeyi kolaylaştırır. MLOps bağlamında API Gateway, model servisi katmanının önünde konumlanır. TensorFlow Serving, Triton Inference Server veya vLLM gibi çıkarım motorlarına gelen trafiği yönetir; A/B testi ve kanary dağıtım (canary deployment) senaryolarında farklı model sürümlerine trafik yüzdesi ataması yapar. Rate limiting mekanizması, token kotasını ve dakika başına istek (RPM) limitini denetleyerek hem maliyet hem de servis kararlılığı açısından kritik bir koruma katmanı oluşturur. Kong, AWS API Gateway, Azure API Management ve Nginx/APISIX gibi geleneksel araçlar Kubernetes ortamlarında Ingress denetleyicisi olarak da kullanılır. Gözlemlenebilirlik açısından her API Gateway, istek gecikmesi, hata oranı ve token tüketimini Prometheus/Grafana yığınına aktarabilir. Güvenlik katmanında JWT doğrulaması, OAuth 2.0 entegrasyonu, IP bazlı kara liste ve TLS sonlandırma işlemleri gateway üzerinde merkezileştirilerek arka uç servislerin yükü hafifletilmektedir. Kurumsal ortamlarda API Gateway ayrıca API yaşam döngüsü yönetimi, sürümleme (versiyonlama) ve geliştirici portalı işlevleri de üstlenebilir; bu özellik onu yalnızca teknik bir altyapı bileşeni değil, aynı zamanda API ekonomisinin yönetim platformu hâline getirir.

arrow_forward
rocket_launch

Canary Deployment (Kanarya Dağıtımı)

Canary Deployment (Kanarya Dağıtımı), yeni bir yazılım sürümü veya yapay zeka modelinin tam olarak yayına alınmadan önce küçük bir kullanıcı grubuna veya trafik dilimine sunulduğu kademeli bir dağıtım stratejisidir. Bu yaklaşım, adını tarihsel olarak madenlerde zehirli gaz tespiti için kullanılan kanarayalardan almaktadır: tıpkı kanaryanın tehlikeyi ilk hisseden olması gibi, test grubundaki kullanıcılar da yeni sürümün olası sorunlarını geniş kullanıcı kitlesine yayılmadan önce ortaya çıkarır. MLOps bağlamında canary deployment, yeni bir makine öğrenimi modelini veya ML pipeline'ının yeni bir versiyonunu üretim ortamında kademeli olarak devreye almak için kullanılır. Örneğin yeni bir öneri sistemi modeli önce yalnızca yüzde beş trafiğe sunulur; doğruluk, gecikme süresi ve kullanıcı memnuniyeti gibi metrikler izlenir ve sorun yoksa trafik payı kademeli biçimde artırılarak tam rollout'a ulaşılır. Bu strateji, büyük patlama (big-bang) dağıtımlarında karşılaşılan riskleri minimize eder. Tam bir rollout yerine küçük bir segment üzerinde test edildiği için olası bir model regresyonu veya performans düşüşü yalnızca küçük bir kullanıcı grubunu etkiler. Hata tespit edildiğinde trafik anında eski modele yönlendirilebilir (rollback), böylece iş sürekliliği korunur. Canary deployment, özellikle A/B testi ile birlikte kullanıldığında daha da güçlü bir araç haline gelir. A/B testinde iki sürüm deneysel olarak yan yana karşılaştırılırken, canary deployment birincil olarak risk yönetimine odaklanır: yeni sürüm iyi çalışıyorsa yavaş yavaş genişletilir, sorun çıkarsa hızla geri alınır. Kubernetes, AWS SageMaker, Seldon Core ve BentoML gibi modern MLOps araçları canary deployment'ı yerel olarak destekler. Bu araçlar, trafik bölme (traffic splitting), metrik izleme ve otomatik rollback mekanizmalarını sağlar, böylece ML mühendisleri yüksek riskli güncellemeleri güvenle ve kontrollü biçimde yayına alabilir. Platform desteği açısından Kubernetes ekosistemi canary deployment için zengin araçlar sunar: Argo Rollouts, Flagger ve Istio service mesh trafik bölümünü otomatikleştirerek metrik eşiği aşıldığında otomatik geri alım (automated rollback) uygular. Öte yandan feature flag araçları (LaunchDarkly, Unleash) canary mantığını altyapı yerine uygulama katmanına taşıyarak daha ince taneli kontrol sağlar. Başarılı bir canary stratejisi için gözlemlenebilirlik altyapısı (metrikler, loglar, izler) ve net başarı kriterleri önceden tanımlanmış olmalıdır.

arrow_forward
code_blocks

CI/CD (CI/CD)

CI/CD; Sürekli Entegrasyon (Continuous Integration) ve Sürekli Teslim/Dağıtım (Continuous Delivery/Deployment) kavramlarının kısaltmasıdır. Kod değişikliklerinin otomatik olarak test edilip üretime taşındığı modern yazılım geliştirme metodolojisinin temelini oluşturan bu yaklaşım, ekiplerin daha hızlı, güvenilir ve tekrarlanabilir biçimde yazılım teslim etmesini mümkün kılar. Sürekli Entegrasyon pratiğinde geliştiriciler, günlük olarak yaptıkları kod değişikliklerini ortak bir depoya (repository) birleştirir ve her birleştirmede otomatik derleme (build) ile test süreçleri tetiklenir. Bu yaklaşım hataların erken tespitini ve entegrasyon sorunlarının — 'integration hell' olarak bilinen — önceden engellenmesini hedefler. Sürekli Teslim (Continuous Delivery) ile kod her zaman üretime hazır tutulur; dağıtım kararı insan onayına bırakılır. Sürekli Dağıtım (Continuous Deployment) ise her onaylı değişikliği tamamen otomatik olarak canlı ortama taşır ve insan müdahalesini süreçten çıkarır. Pratik bir CI/CD boru hattı (pipeline) tipik olarak şu aşamaları kapsar: kaynak kod yönetimi (Git), otomatik derleme, birim testleri (unit test) ve entegrasyon testleri, statik kod analizi ve güvenlik taraması (SAST/DAST), konteyner imajı oluşturma (Docker), hazırlık (staging) ortamına dağıtım, duman testi (smoke test) ve son olarak üretim ortamına dağıtım. Kanarya dağıtımı (canary deployment) ve mavi-yeşil dağıtım (blue-green deployment) gibi stratejiler CI/CD altyapısı üzerine inşa edilerek sıfır kesinti süresiyle üretim güncellemesi yapılmasını olanaklı kılar. GitHub Actions, GitLab CI/CD, Jenkins, CircleCI ve Azure DevOps en yaygın kullanılan araçlardır. Makine öğrenmesi projelerinde CI/CD boru hatları yalnızca kodu değil, model ağırlıklarını, veri doğrulama adımlarını, model performans metriklerini ve model kayıt işlemlerini de kapsar; bu özelleşmiş alan MLOps olarak adlandırılmaktadır. DevOps kültüründe CI/CD, geliştirme (Dev) ve operasyon (Ops) ekiplerini ortak bir otomasyon altyapısında birleştirerek kaliteli yazılımın çok daha kısa döngülerle teslim edilmesinin temel güvencesini oluşturmaktadır.

arrow_forward
sync_problem

Concept Drift (Kavram Kayması)

Kavram kayması (concept drift), makine öğrenmesi modellerinin eğitiminde kullanılan verinin istatistiksel dağılımının zamanla değişmesi ve bunun sonucunda modelin performansının düşmesi olgusudur. Model yayına alındıktan sonra gerçek dünya verisi sürekli evrilirken model, eğitimde öğrendiği eski kalıpları uygulamaya devam eder; bu uyumsuzluk tahmin hatalarının artmasına yol açar. Kavram kayması dört temel türde gözlemlenir: ani kayma (abrupt drift), ekonomik kriz veya yasal değişiklik gibi anlık olaylarda dağılımın topluca değişmesidir; kademeli kayma (gradual drift), uzun sürede yavaş yavaş meydana gelir; tekrarlayan kayma (recurring drift), mevsimsellik gibi periyodik değişimler içerir; kör nokta kayması (blind spot drift) ise eğitim verisinde hiç görünmemiş yeni veri türlerinin üretimde ortaya çıkmasıdır. Gerçek dünya senaryolarında bu türler iç içe geçebilir; bir e-ticaret platformu hem mevsimsel (recurring) hem de uzun dönemli tüketici tercihi değişimlerine (gradual) maruz kalabilir. Drift tespitinde istatistiksel testler (Kolmogorov-Smirnov, Chi-square), özellik dağılımı izleme (Population Stability Index — PSI), referans pencere ile kayan pencere karşılaştırma ve model performans metriklerinin takibi (doğruluk, AUC, RMSE) en yaygın yöntemlerdir. Evidently AI, River, NannyML ve Alibi-Detect bu analizler için açık kaynaklı araçlar sunar. Yanıt stratejileri arasında periyodik yeniden eğitim (scheduled retraining), drift algılandığında tetiklenen otomatik güncelleme (triggered retraining), her yeni örnekle güncellenen online öğrenme ve farklı döneme ait modelleri birleştiren ensemble yaklaşımları öne çıkar. MLOps altyapısı bu stratejileri drift → uyarı → yeniden eğitim döngüsüyle otomatik biçimde işletir. Kredi riski değerlendirmesinden öneri sistemlerine, doğal dil işlemeden görüntü tanımaya kadar üretimdeki tüm ML modelleri kavram kaymasına karşı savunmasızdır. Pandemi döneminde tüketici harcama kalıpları dramatik biçimde değişmiş, bu durum perakende öneri sistemlerinde ani doğruluk düşüşlerine yol açmıştır. Model izleme ve zamanında yeniden eğitim, güvenilir yapay zeka sistemlerinin temel bileşenleridir.

arrow_forward
track_changes

Concept Drift Detection Nedir? Kavram Kayması Tespiti (Kavram Kayması Tespiti)

Concept drift detection (kavram kayması tespiti), makine öğrenmesi modellerinin üretim ortamında zamanla nasıl davrandığını izleyen ve giriş verilerinin ya da hedef değişkenin istatistiksel dağılımında meydana gelen kaymaları erken tespit eden bir MLOps tekniğidir. Bir model eğitildiğinde, belirli bir veri dağılımını temsil eden eğitim kümesi üzerinde optimize edilir. Ancak gerçek dünya koşulları değişkendir; kullanıcı davranışları, piyasa dinamikleri, çevresel faktörler veya sistem değişiklikleri nedeniyle veri dağılımı, modelin orijinal eğitim sürecinde öğrendiklerinden giderek uzaklaşabilir. Bu duruma kavram kayması denir ve model performansının bozulmasına yol açar. Kavram kaymasının üç temel türü vardır. Ani kayma (sudden drift), veri dağılımının kısa sürede dramatik biçimde değiştiği durumları tanımlar; COVID-19 salgınının e-ticaret alışkanlıklarını köklü biçimde dönüştürmesi buna örnek verilebilir. Kademeli kayma (gradual drift), eski veri dağılımının yavaş yavaş yenisiyle yer değiştirdiği geçiş süreçlerini kapsar. Tekrarlı kayma (recurring drift) ise daha önce görülmüş dağılım kalıplarının periyodik olarak yeniden ortaya çıktığı döngüsel durumları ifade eder. Popüler tespit algoritmaları arasında ADWIN (ADaptive WINdowing), DDM (Drift Detection Method), EDDM (Early Drift Detection Method) ve Page-Hinkley testi öne çıkar. ADWIN, geçmiş veri penceresini dinamik olarak boyutlandırarak istatistiksel sapmaları saptar. DDM ise model hatası oranını ve standart sapmasını izleyerek drift'i erken uyarıyla bildirir. MLOps pipeline'larında kavram kayması tespiti, modelin ne zaman yeniden eğitileceğini veya ince ayar yapılacağını belirleyen kritik bir karar mekanizmasıdır. Amazon SageMaker Model Monitor, Evidently AI, WhyLogs ve NannyML gibi araçlar bu süreci otomatikleştirerek mühendis ekibine zamanında uyarı gönderir. Erken tespit, iş kararlarını olumsuz etkileyebilecek sessiz model çürümesini (model decay) önlemenin temel yoludur. Özellikle finans, sağlık ve e-ticaret gibi dinamik ortamlarda bu teknik, güvenilir yapay zeka sistemlerinin sürdürülebilirliğini doğrudan destekler.

arrow_forward
autorenew

Continuous Training (Sürekli Eğitim)

Continuous Training (Sürekli Eğitim), makine öğrenimi modellerinin üretim ortamında yeni veriler geldikçe otomatik olarak yeniden eğitilmesini sağlayan MLOps pratiğidir. Geleneksel yaklaşımda model bir kez eğitilir ve uzun süre değiştirilmeden kullanılır; ancak bu yöntem, üretim verisinin zaman içinde değiştiği — yani model kaymasının (model drift veya data drift) yaşandığı — gerçek dünya senaryolarında yetersiz kalır. CT'nin temel motivasyonu, konsept kaymasına (concept drift) karşı modelin güncelliğini korumaktır. Konsept kayması, girdi özellikleri ile hedef değişken arasındaki ilişkinin zamanla değişmesi durumudur. Örneğin bir kredi risk modeli, ekonomik koşullardaki değişimlerle birlikte eskiyen kararlar üretmeye başlayabilir; bir tavsiye motoru ise kullanıcı davranışlarındaki yeni trendleri yakalayamazsa alaka düzeyini yitirir. Bu tür kaymaları erkenden tespit etmek ve yanıt vermek için CT, izleme (monitoring) altyapısıyla sıkı biçimde entegre çalışır. CT pipeline'ları genellikle üç tetikleme stratejisinden birini kullanır. Zamana dayalı tetikleme (time-based), modeli belirli aralıklarla — günlük, haftalık — yeniden eğitir. Veri hacmine dayalı tetikleme (data-volume trigger), yeni örnek sayısı bir eşiği geçtiğinde eğitimi başlatır. Performans bazlı tetikleme (performance-based), modelin izlenen metriklerinin — doğruluk, AUC-ROC, F1 — belirli bir eşiğin altına düşmesi durumunda devreye girer; bu yaklaşım en hassas ve kaynakları en verimli kullanan yöntemdir. Champion/challenger paradigması, CT'nin güvenli üretime alınmasında merkezi bir rol oynar. Mevcut üretimdeki model (champion), yeni eğitilen modelle (challenger) belirli bir trafik yüzdesinde A/B testi yapılarak karşılaştırılır; yeni model belirgin ölçüde daha iyi performans gösterirse otomatik olarak canlıya alınır (promotion). Tüm bu süreç Kubeflow Pipelines, Apache Airflow, MLflow, Vertex AI Pipelines veya AWS SageMaker Pipelines gibi platformlar üzerinde orkestre edilir. Veri kalitesi kontrolleri, model doğrulama adımları ve onay kapıları (approval gates) CT pipeline'ının güvenilirliğini artıran kritik bileşenlerdir. CT'yi CI/CD yazılım pratiklerinden ayıran en temel fark, veri merkezli doğrulama ve insan gözetimli model terfisi gereksinimidir.

arrow_forward
code_blocks

Data Catalog (Veri Kataloğu)

Veri kataloğu (Data Catalog), bir kuruluşun sahip olduğu veri tablolarının, akışlarının, raporlarının ve makine öğrenmesi modellerinin organize edilmiş, aranabilir ve bağlamsal envanterini oluşturan metadata yönetim platformudur. Temel işlevi üç sütun üzerine kuruludur: veriyi keşfet, içeriğini anla ve güvenilirliğini doğrula. Modern bir veri kataloğu iki tür metadata yönetir. Teknik metadata; tablo adları, sütun tipleri, boyut ve güncelleme sıklığı gibi yapısal bilgileri içerir. İş metadata'sı ise bir alanın iş anlamını, veri sahibini, kullanım senaryolarını ve kalite skorunu kapsar. Bu iki katmanın birleşimi, mühendislerden iş analistlerine kadar herkesin aynı platforma başvurmasına olanak tanır. Veri kataloğunun en kritik özelliklerinden biri soy takibidir (data lineage). Bu özellik, bir verinin nereden geldiğini, hangi dönüşümlerden geçtiğini ve nerede kullanıldığını uçtan uca görselleştirir. Özellikle sütun düzeyinde lineage, hangi ETL adımının hangi alanı etkilediğini gösterir; hatalı raporların köküne hızla inilmesini mümkün kılar. MLOps ekipleri için veri kataloğu ayrı bir öneme sahiptir: hangi veri kümesinin hangi model eğitiminde kullanıldığını izler, feature store ile bütünleşik çalışarak özniteliklerin ekipler arasında yeniden kullanımını kolaylaştırır ve training-serving skew riskini azaltır. 2024-2025 itibarıyla kataloglar LLM ve RAG pipeline'larının bağlandığı veri kaynaklarını da izlemeye başlamıştır. Popüler açık kaynak araçlar arasında DataHub, OpenMetadata ve Apache Atlas öne çıkmaktadır. Ticari tarafta Collibra, Alation ve Databricks Unity Catalog kurumsal çözümler sunmaktadır. Veri kataloğu; veri sözlüğünden farklı olarak tek bir sistemle sınırlı kalmaz; tüm organizasyonun veri ekosistemine bütünleşik erişim sunar ve aktif metadata kavramı çerçevesinde kalite anomalilerini otomatik tespit eden dinamik platformlara dönüşmektedir. Bu dönüşüm, veri kalitesi sorunlarını daha oluşmadan önce tespit etme ve veri güvenilirliğini organizasyon genelinde artırma açısından kritik bir adımı temsil etmektedir.

arrow_forward
code_blocks

Data Contract (Veri Sözleşmesi)

Data contract (veri sözleşmesi), bir veri üreticisi ile veri tüketicileri arasında kurulan, şema, kalite kuralları ve teslimat yükümlülüklerini resmileştiren makine tarafından uygulanabilir anlaşmadır. Terim, 2022 yılında Chad Sanderson tarafından data mesh mimarisinin yaygınlaşmasıyla birlikte popüler hale gelmiştir. Geleneksel veri boru hatlarında üretici ekipler şema değişikliklerini bildirmeden güncelleme yapabilir; bu durum aşağı akış ML modellerini, raporları ve analitik iş yüklerini bozar. Data contract bu kırılganlığı ortadan kaldırır: üretici, belirli bir şema versiyonunu, null toleransını, veri tazeliğini ve iş tanımlarını resmî bir belge olarak yayımlar; tüketici ise bu koşulları CI/CD sürecinde otomatik olarak doğrular. Bir data contract genellikle şu unsurları kapsar: sütun adları ve veri türleri, zorunluluk ve benzersizlik kısıtlamaları, tazelik SLA'sı (ör. "her 6 saatte bir güncellenir"), anlam bağlamı (sütun iş tanımları) ve sürüm uyumluluk politikası. dbt 1.5+ ile gelen contract bloğu bu denetimi proje düzeyine taşır; Soda Core ve Great Expectations ise çalışma zamanında ihlalleri yakalayarak bozuk verinin ML modellerine ulaşmasını engeller. Araştırmalar, veri kalitesi olaylarının yüzde altmışından fazlasının üretici-tüketici iletişim kopukluğundan kaynaklandığını ortaya koymuştur. MLOps bağlamında data contract, feature store'a beslenen her kaynak tablonun kalite güvencesini kurar. Model eğitimi ve üretim çıkarımı arasındaki dağılım kaymasını (training-serving skew) önlemek için özellik alanlarının tip ve aralık kısıtlamaları sözleşmede açıkça tanımlanır. LLM boru hatlarında embedding modeline giden metin sütunlarının maksimum uzunluk ve karakter kodlaması gibi kısıtlamalar da sözleşme kapsamına alınabilir. Streaming mimarilerde Apache Kafka için Schema Registry, Avro veya Protobuf şemalarını sözleşme mekanizması olarak kullanır; gerçek zamanlı boru hatlarında şema evrimi güvenli biçimde yönetilir. Sürümleme açısından anlamsal sürümleme (MAJOR.MINOR.PATCH) yaklaşımı önerilir: kırıcı değişiklikler MAJOR sürümü yükseltir ve tüketici ekiplere geçiş süresi tanınır. Data mesh mimarisinde her veri ürünü kendi sözleşmesinden sorumlu olur; bu dağıtık sahiplik modeli büyük organizasyonlarda veri güvenilirliğini merkezi denetim olmaksızın ölçeklendirmeye olanak tanır.

arrow_forward
trending_down

Data Drift (Veri Kayması (Bozulması))

Veri drift (data drift), bir makine ogrenimi modelinin egitildigi veri dagilimi ile modelin uretimde karsilastigi gercek dunya verisi arasindaki istatistiksel mesafenin zamanla buyumesidir. Bir model egitim sirasinda belirli bir veri dagilimini ogrendigi icin, bu dagilimdaki degisimler modelin ongorduguyle gercek dunyada karsilastiginni arasinda giderek buyuyen bir uyumsuzluk yaratir ve model performansinin bozulmasina yol acar. Drift cesitli bicimlerde gerceklesebilir. Kovaryet drift (covariate shift), girdi ozelliklerinin istatistiksel dagiliminin degismesiyle olur; ancak girdi-cikti iliskisi sabittir. Ornegin bir banka dolandiricilik modelinin egitildigi doneme kiyasla musteri yas profili veya islem buyuklukleri zamanla degisebilir. Kavram drift (concept drift) ise daha derin bir problemi temsil eder: girdi ile cikti arasindaki temel iliskinin kendisi degisir. COVID-19 pandemisi, tuketici aliskanliklarini o kadar kisa surede donusturdu ki yuzlerce sirkette alis-veri tahmin modelleri kritik performans kaybi yasadi. Drift tespiti icin cesitli istatistiksel testler kullanilir. Population Stability Index (PSI), egitim ve uretim verisinin dagilim farkliliğini sayisal olarak olcer; 0.1 altinda kritik, 0.25 uzerinde kritik drift isaretler. Kolmogorov-Smirnov testi iki dagilimlarin istatistiksel olarak anlamli farkliliği olup olmadigini test eder. KL Divergence, bir dagilimdaki bilginin digerini temsil etmek icin ne kadar eksik bilgi gerektirdigini olcer. Pratik MLOps sistemlerinde drift izleme gercek zamanli veya periyodik olarak yurutur. Bir esik gecilelince sistem uyari olusturur, log kaydeder ve bazen otomatik yeniden egitimi tetikler. Yeniden egitim her zaman dogru cevap degildir; kimi zaman ozellik muhendisligi veya modelin yeniden tasarlanmasi gerekir. Etiket gecikme sorunu da yogun gundeme gelir: drift tespitinin kalbi olan gercek etiketi elde etmek haftalar veya aylar alabilir. **Sik Sorulan Sorular** **Veri drift ile model drift arasindaki fark nedir?** Veri drift girdi dagiliminin degismesidir; model drift ise cikti kalitesinin bozulmasini ifade eder. Veri drift model driftin yaygin nedenlerinden biridir ancak tek nedeni degildir. **Drift ne siklukla kontrol edilmelidir?** Bu verinin degisim hizina baglidir. Finansal, hava durumu veya trafik verileri gunden gune bile ciddi drift gosterebilir. Urun tavsiye modelleri genellikle haftalik kontrol yeterlidir. **Drift tespitinde hangi araclar kullanilir?** Evidently AI, Arize, Whylogs, Fiddler ve bulut saglayicilarin yonetilen izleme servisleri yaygin seceneklerdir. Temel istatistiksel testler ise SciPy veya scikit-learn ile uygulanabilir. **Drift olmadan da model bozulabilir mi?** Evet. Model bozulmasi; veri altyapisindaki degisiklikler, bagimliliklarin guncellenmesi veya kodlama hatalari gibi teknik nedenlerle de olabilir; bunlar veri drift olmaksizin gerceklesir.

arrow_forward
water_drop

Data Lake (Veri Gölü)

Data Lake (Türkçe: Veri Gölü), yapılandırılmış, yarı yapılandırılmamış ve yapılandırılmamış verilerin orijinal ham formatlarında depolandığı merkezi, ölçeklenebilir bir büyük veri deposudur. Geleneksel veri ambarlarının aksine, Data Lake veriye önceden bir şema uygulamaz; veriler ham hâlde saklanır ve sorgu anında şema belirlenir (schema-on-read yaklaşımı). Bu esneklik aracılığıyla log dosyaları, görüntüler, videolar, sensör verileri ve JSON/CSV gibi farklı formatlardaki veriler aynı depoda bir arada tutulabilir. "Data Lake" kavramı ilk olarak 2010 yılında Pentaho'nun CTO'su James Dixon tarafından kavramsallaştırılmıştır. Dixon, veri ambarlarını sunum için hazır su şişeleriyle kıyaslarken Data Lake'i kendi doğal ve safiyetini koruyan bir göle benzetti: tüm su kaynakları (veriler) doğal hâlde bu göle akar ve kullanıcılar ihtiyaçlarına göre bu gölden istedikleri miktarda ve formatta su alır. Bir Data Lake mimarisi genellikle birkaç katmandan oluşur. Ham veri bölgesi (Raw/Landing Zone), kaynak sistemlerden gelen verilerin sıfır değişiklikle aktarıldığı giriş noktasıdır. Rafine veri bölgesi (Curated Zone), temizleme, dönüştürme ve kalite kontrolünden geçirilmiş verileri barındırır. Tüketim bölgesi (Consumption Zone) ise iş analistleri, veri bilimciler ve makine öğrenmesi uygulamaları tarafından kullanıma hazır hâle getirilmiş verileri içerir. Data Lake'in başlıca avantajları arasında yüksek ölçeklenebilirlik, düşük birim depolama maliyeti ve veri formatı esnekliği sayılabilir. Ancak yeterli yönetim ve kataloglama araçları olmadığında "Data Swamp" (Veri Bataklığı) hâline gelebilir: verinin nereden geldiği, ne anlama geldiği ve nasıl kullanılacağı belirsizleşir. Bu sorunu çözmek için veri kataloğu (data catalog), veri soyu takibi (data lineage) ve meta veri yönetimi araçları kullanılır. Günümüzde AWS S3 + Glue, Azure Data Lake Storage Gen2, Google Cloud Storage ve Apache Hadoop HDFS popüler Data Lake altyapılarıdır. Modern Delta Lake, Apache Iceberg ve Apache Hudi açık tablo formatları ise ACID işlem desteği ve şema evrimi ekleyerek Data Lake ile Data Warehouse özelliklerini "Lakehouse" mimarisinde birleştirir. Yapay zeka ve büyük dil modeli (LLM) alanında ise Data Lake, model öncesi (pre-training) ham veri havuzu ve fine-tuning veri kümesi deposu olarak kritik bir rol üstlenmektedir. 2025-2026 döneminde Apache Iceberg, AWS Athena, Google BigQuery ve Snowflake'in yerel destek eklemesiyle kurumsal standart tablo formatına dönüşmüştür. DuckDB ise geliştirici bilgisayarında Parquet/Iceberg dosyalarını saniyeler içinde sorgulamayı mümkün kılarak veri gölü erişimini demokratikleştirmiştir. LLM'lerin büyümesiyle birlikte veri gölleri, pre-training corpus yönetiminin birincil katmanı hâline gelmiştir; 2026'da kurulan pek çok AI şirketi veri katmanı olarak doğrudan Lakehouse mimarisini tercih etmektedir.

arrow_forward
database

Data Lakehouse (Veri Göl Ambarı (Data Lakehouse))

Data lakehouse (veri göl ambarı), geleneksel veri gölü (data lake) ile veri ambarı (data warehouse) mimarilerinin avantajlarını tek bir platformda birleştiren modern bir veri yönetimi yaklaşımıdır. Terim, 2020 yılında Armbrust ve arkadaşlarının CIDR konferansındaki akademik çalışmasıyla literatüre girmiş; 2021'de Databricks tarafından ticari bir mimari olarak yaygınlaştırılmıştır. Geleneksel veri gölü yaklaşımı, Amazon S3 veya Azure Data Lake Storage gibi nesne depolarında ham, yapılandırılmamış ve yarı yapılandırılmış verileri düşük maliyetle barındırır. Ancak ACID işlem desteğinden yoksundur; bu durum veri tutarlılığı sorunlarına, gereksiz veri kopyalamaya ve 'bataklık' (data swamp) oluşumuna zemin hazırlar. Veri ambarı ise yüksek performanslı SQL sorgularını ve sıkı şema yönetimini destekler; buna karşın pahalı kapalı depolama sistemlerine bağımlıdır ve petabayt ölçeğinde ham veriyi işlemekte zorlanır. Data lakehouse bu ikilemliği çözer: Apache Iceberg, Delta Lake (Databricks) veya Apache Hudi gibi açık tablo formatları, nesne depolama katmanına ACID semantiği, şema evrimi ve zaman yolculuğu (time travel) yetenekleri ekler. Mimari üç katmandan oluşur: nesne depolama katmanı (ham veri), tablo format/metadata katmanı (ACID + şema) ve sorgu/hesaplama katmanı (Spark, Trino, Flink gibi motorlar). Bu yapı, veri bilimcilerin ham eğitim verilerine doğrudan erişmesine izin verirken veri analistlerinin küratörlü, şemaya uygun verilere SQL arayüzüyle ulaşmasına olanak tanır. Yapay zeka iş akışları açısından lakehouse mimarisinin önemi giderek artmaktadır. Büyük dil modellerinin eğitim ve ince ayar süreçlerinde petabayt ölçekli ham metin verisini versiyon kontrolüyle yönetmek, zaman yolculuğuyla önceki veri sürümlerine geri dönmek ve MLflow gibi araçlarla model sürümleri ile veri sürümlerini eşleştirmek için lakehouse tercih edilmektedir. Databricks Lakehouse, Microsoft Fabric (OneLake), Snowflake Open Catalog ve Google BigLake bu mimarinin önde gelen ticari uygulamalarıdır.

arrow_forward
code_blocks

Data Leakage (Veri Sızıntısı (Data Leakage))

Veri sızıntısı (data leakage), makine öğrenimi modelinin eğitim sürecine gerçek dünya tahmin anında bulunmaması ya da bilinmemesi gereken bilgilerin karışması ve bu durumun modelin performans değerlendirmesini yanıltmasıdır. Ortaya çıkan en belirgin belirti, geliştirme aşamasında olağandışı yüksek doğruluk, F1 veya AUC değerleri elde edilmesidir; ancak model üretime geçtiğinde bu başarım bir anda çöker çünkü o "sızan" bilgi artık mevcut değildir. Veri sızıntısının iki ana türü vardır. Birinci tür olan hedef sızıntısı (target leakage), eğitim setindeki bir özelliğin tahmin edilmek istenen sonuçla zamansal ya da korelasyonel bağ üzerinden kirlendiği durumu tanımlar. Klasik örnek: sigorta hasar tahmin modelinde "hasar sonrası müşteri iletişim kaydı" özelliğinin kullanılması. Bu değişken modelin sonucu önceden "bilmesine" yol açar; üretimde tahmin anında henüz o kayıt oluşmadığından model başarısız olur. İkinci tür olan eğitim-test kirliği ise ön işleme adımlarının test verisine sıçramasından kaynaklanır. StandardScaler veya MinMaxScaler'ı tüm veri seti üzerinde fit edip ardından bölümleme yapmak bu hatanın en yaygın biçimidir: test setinden gelen istatistikler normalleştirmede kullanıldığından test seti gerçek anlamda görülmemiş olmaktan çıkar. Zaman serisi verileri özellikle yüksek risk taşır. Rastgele train/test bölümlemesi bu tür verilerde her zaman yanlıştır: gelecekteki gözlemler eğitim setine girebilir ve model aslında geleceği görerek geçmişi tahmin eder. Doğru yöntem TimeSeriesSplit veya walk-forward validation kullanmaktır. Tespitte en etkili yöntem, Scikit-learn Pipeline nesneleridir: her çapraz doğrulama kıvrımında ön işleme adımlarını yalnızca o kıvrımın eğitim verisine uyguladığından test kirliğini yapısal olarak engeller. Özellik önem sıralamalarında şaşırtıcı derecede yüksek katkı gösteren değişkenler hedef sızıntısı açısından mutlaka sorgulanmalıdır. Üretim ile geliştirme ortamı arasındaki ani performans düşüşü her zaman veri sızıntısının güçlü bir göstergesidir.

arrow_forward
fact_check

Data Quality (Veri Kalitesi)

Veri kalitesi (Data Quality), bir veri kümesinin belirli bir kullanım amacı için ne derece uygun olduğunu ifade eden çok boyutlu bir kavramdır. Yapay zeka, makine öğrenimi ve veri madenciliği projelerinde, veri kalitesi modelin ne kadar doğru ve güvenilir sonuç üreteceğini belirleyen temel etkendir. Veri kalitesi altı standart boyutla ölçülür. Doğruluk (accuracy), veri değerlerinin gerçek dünyadaki durumu yansıtıp yansıtmadığını ölçer. Tamlık (completeness), gerekli alanların eksiksiz biçimde dolu olup olmadığını denetler. Tutarlılık (consistency), aynı verinin farklı sistemler veya tablolar arasında çelişip çelişmediğini kontrol eder. Zamansallık (timeliness), verinin analiz amacına yetecek kadar güncel olup olmadığını sorgular. Geçerlilik (validity), verilerin tanımlanmış iş kurallarına ve formatlara uygunluğunu belirler. Benzersizlik (uniqueness) ise yinelenen kayıtları tespit eder. Sektörde yerleşik olan 'Çöp içeri, çöp dışarı' (Garbage In, Garbage Out) ilkesi, veri kalitesinin modeller üzerindeki doğrudan etkisini özetler. Hatalı veya eksik verilerle eğitilen bir yapay zeka modeli, gerçek dünya koşullarında güvenilmez tahminler üretir. Araştırmalar, veri bilimcilerinin zamanının yüzde altmış ila seksenini veri temizleme ve kalite iyileştirmeye ayırdığını ortaya koymaktadır. Veri kalitesini ölçmek ve artırmak için kullanılan başlıca araçlar arasında Great Expectations, dbt testleri, Apache Soda ve Pandas Profiling yer almaktadır. Bu araçlar veri boru hatlarına (pipeline) entegre edilerek kalite sorunlarını anlık raporlar ve anomalileri uyarı sistemlerine bildirir. Üretim ortamlarında sürekli veri kalitesi izleme (data quality monitoring), sapmalar gerçekleşir gerçekleşmez mühendis ekipleri uyarır. Regülasyon boyutunda AB Yapay Zeka Yasası (AI Act) Madde 10, yüksek riskli yapay zeka sistemlerinde veri yönetim uygulamalarını ve kalite metriklerini belgelemeyi yasal yükümlülük haline getirmiştir. ISO/IEC 25012 standardı da veri kalitesi özelliklerini sistematik biçimde tanımlar. Bu nedenle veri kalitesi artık yalnızca teknik bir uygulama değil, kurumsal yönetişim ve uyum çerçevelerinin ayrılmaz bir parçasıdır.

arrow_forward
manage_history

Data Versioning Nedir? Makine Öğrenmesinde Veri Versiyonlama (Veri Versiyonlama)

Data versioning (veri versiyonlama), makine öğrenmesi ve veri bilimi projelerinde kullanılan veri kümelerini, modelleri ve deneyleri Git'e benzer şekilde izleyen bir sürüm kontrol yöntemidir. Geleneksel yazılım geliştirmede kod değişiklikleri Git ile takip edilirken makine öğrenmesi projelerinde veri kümelerinin de aynı titizlikle yönetilmesi kritik önem taşır. Bir model eğitiminde hangi veri setinin kullanıldığını bilmeden deneyler tekrarlanamaz, performans regresyonlarının kaynağı tespit edilemez ve model denetim (audit) süreçleri güvenilir biçimde yürütülemez. 'Aynı kod, aynı veri sürümü, aynı sonuç' prensibi olarak da tanımlanan tam yeniden üretilebilirlik (full reproducibility), MLOps olgunluk modelinin temel gereksinimlerinden biridir. Bu alandaki en yaygın araç DVC (Data Version Control) olup açık kaynaklı bir proje olarak Git ile entegre çalışır: büyük veri dosyalarını Amazon S3, Google Cloud Storage veya Azure Blob gibi uzak depolara yükler, Git reposunda ise yalnızca küçük birer meta-dosya (pointer) tutar. Kasım 2025'te lakeFS tarafından satın alınan DVC, veri göllerinde Git tarzı dallanma, commit ve merge işlemlerine olanak tanıyan lakeFS mimarisiyle birleşmeye başlamıştır. Versiyon yönetimi yalnızca ham veri ile sınırlı kalmaz; dönüştürülmüş veri kümeleri, model ağırlıkları ve deney konfigürasyonları (hiperparametreler, rastgele tohum değerleri) de kapsama dahil edilir. Delta Lake ve Apache Iceberg ise veri gölü ve veri ambarı ortamlarında tablo düzeyinde ACID uyumlu versiyonlama, anlık görüntü (snapshot) alımı ve zaman yolculuğu sorguları (time travel query) sunarak data versioning'i kurumsal ölçekte uygulanabilir kılar. MLOps boru hatlarında data versioning şu görevleri üstlenir: her model eğitim koşusu için kullanılan veri sürümünü otomatik olarak kaydeder, model kayıt defteri (model registry) ile veri sürümü arasında birebir ilişki kurar, regresyon testlerinde referans veri setlerini sabitler ve AB testi koşullarını izole eder. Bu nedenle data versioning, üretime alınan yapay zeka sistemlerinde hem güvenilirlik hem de uyumluluk (compliance) gereksinimlerini karşılamak için vazgeçilmez bir bileşen haline gelmiştir.

arrow_forward
developer_mode

DevOps AI Nedir? Yapay Zeka Destekli Yazılım Geliştirme (Yapay Zeka Destekli DevOps)

DevOps AI, yazılım geliştirme (Development) ve BT operasyonları (Operations) süreçlerini birleştiren DevOps kültürüne yapay zeka ve makine öğrenimi tekniklerini entegre eden modern bir yazılım mühendisliği disiplinidir. Geleneksel DevOps pratiklerinin ötesine geçerek akıllı otomasyon, tahmine dayalı analitik ve kendini iyileştiren sistemler oluşturur. DevOps AI'ın temel özelliklerinden ilki AIOps (Artificial Intelligence for IT Operations) yaklaşımıdır. AIOps, BT altyapısından toplanan büyük veri akışlarını makine öğrenimi algoritmaları aracılığıyla analiz eder, anomalileri gerçek zamanlı tespit eder ve potansiyel arızaları henüz oluşmadan önce tahmin eder. Bu sayede ekipler reaktif sorun giderme yerine proaktif önlem almaya odaklanabilir. CI/CD (Sürekli Entegrasyon/Sürekli Dağıtım) süreçleri DevOps AI ile daha akıllı hale gelir. Yapay zeka modelleri, geçmiş hata örüntülerini öğrenerek hangi kod değişikliklerinin dağıtım sorunlarına yol açabileceğini önceden tahmin eder. Deployment risk scoring olarak bilinen bu teknik, ekiplerin yüksek riskli dağıtımları erkenden fark etmesini sağlar. Otomatik test üretimi de DevOps AI'ın kritik bir bileşenidir. LLM tabanlı kod analiz araçları mevcut kodu inceleyerek eksik test senaryolarını otomatik oluşturur ve kod kapsamını artırır. Benzer şekilde kod kalite analizi, yapay zeka ile zenginleştirilmiş kod incelemelerine dönüşür. Gözlemlenebilirlik (Observability) alanında DevOps AI; metrik, log ve izleme (trace) verilerini birleştirerek kök neden analizini hızlandırır. Geleneksel eşik tabanlı uyarılar yerine anormallik tespiti algoritmaları dinamik baseline oluşturur ve gerçek sorunları gürültüden ayırt eder. Otomatik olay yanıtı (auto-remediation) ise tekrarlayan sorunları insan müdahalesi olmadan çözebilir. Kaynak optimizasyonu konusunda makine öğrenimi modelleri iş yükü örüntülerini öğrenerek altyapı maliyetlerini minimize eden akıllı otomatik ölçekleme (auto-scaling) kararları verir. Bu özellikle bulut ortamlarında önemli maliyet tasarrufu sağlar. DevOps AI'ı başarıyla uygulayan ekipler daha hızlı dağıtım döngüleri, daha az üretim kesintisi ve geliştirici deneyiminde belirgin iyileşme rapor etmektedir. Ancak bu yaklaşımın benimsenmesi kültürel değişim, kaliteli eğitim verisi ve araç entegrasyonu gerektirmektedir.

arrow_forward
code_blocks

Docker Nedir? AI Geliştirmede Konteyner Teknolojisi (Konteyner Teknolojisi)

Docker, 2013 yılında Solomon Hykes tarafından geliştirilen ve Linux çekirdeğinin konteyner teknolojisini kullanıcı dostu bir API ile erişilebilir kılan açık kaynaklı bir konteynerizasyon platformudur. Temel amacı "bende çalışıyor ama sende çalışmıyor" sorununu ortadan kaldırmaktır: Uygulama kodu, çalışma zamanı, kütüphaneler ve tüm sistem bağımlılıkları bir araya getirilerek "image" adı verilen taşınabilir bir paket oluşturulur; bu paketten çalıştırılan "container", bulut sunucusundan yerel makineye kadar her ortamda aynı davranışı sergiler. Sanal makinelerden (VM) farkı kritik öneme sahiptir. VM'ler tam bir işletim sistemi çalıştırırken Docker container'ları ana sistemin çekirdeğini paylaşır. Bu sayede container'lar saniyeler içinde başlar, megabayt mertebesinde yer kaplar ve çok daha az RAM tüketir. Container'lar sanallaştırma yerine işletim sistemi düzeyinde izolasyon sunar. AI ve makine öğrenimi ekosisteminde Docker birkaç kritik sorunu çözer. Araştırmacılar, farklı Python sürümleri, CUDA versiyonları veya kütüphane kombinasyonları gerektiren deneyleri Dockerfile aracılığıyla yeniden üretilebilir ortamlar olarak tanımlayabilir. Model deployment sürecinde eğitilmiş modeller API sunucularıyla birlikte konteynerize edilerek Kubernetes gibi orkestrasyon araçlarıyla büyük ölçekte dağıtılabilir. MLflow, Kubeflow ve Airflow gibi MLOps araçlarının büyük çoğunluğu Docker'ı temel alır. Temel bileşenler şunlardır: Dockerfile (image'ı tanımlayan yapılandırma dosyası), image (çalıştırılabilir paket), container (çalışan image örneği), registry (Docker Hub gibi image deposu) ve docker-compose (çoklu container uygulamalarını yönetme aracı). docker pull, docker run ve docker build komutları günlük kullanımın temelini oluşturur. GPU destekli AI iş yükleri için NVIDIA Container Toolkit, GPU'ların container'lara aktarılmasını mümkün kılar; böylece farklı CUDA sürümleri gerektiren modeller aynı fiziksel makinede yan yana çalıştırılabilir. Bu özellik özellikle araştırma ortamlarında deney yeniden üretilebilirliğini güçlü biçimde destekler. Endüstride Docker imajları katmanlı yapısı ile verimli depolanır ve dağıtılır.

arrow_forward
code_blocks

DVC (Data Version Control) (DVC — Veri Sürüm Kontrolü)

DVC (Data Version Control), büyük veri setlerini ve makine öğrenmesi model dosyalarını Git ile aynı iş akışında sürümlendirmeye olanak tanıyan açık kaynaklı bir MLOps aracıdır. Iterative tarafından 2017 yılında geliştirilen DVC, geliştiricilerin veri bilimi deneylerini tekrarlanabilir, işbirliğine açık ve izlenebilir bir şekilde yönetmesini sağlar. Git, metin tabanlı kod dosyalarını verimli biçimde sürümlendirmek için tasarlanmıştır ancak gigabayt veya terabayt büyüklüğündeki veri setleri ve model ağırlıkları için uygun değildir. DVC bu sorunu, büyük dosyaları uzak depolama sistemlerine (Amazon S3, Google Cloud Storage, Azure Blob, SSH sunucusu, SFTP veya yerel disk) yönlendirirken yalnızca hafif işaretçi dosyaları (.dvc uzantılı) Git deposuna ekleyerek çözer. Bu sayede Git deposu şişmeden tam veri ve model takibi yapılabilir. DVC'nin temel bileşeni pipeline sistemidir. Her veri işleme adımı (ham veri okuma, ön işleme, özellik çıkarımı, model eğitimi, değerlendirme) dvc.yaml dosyasında bağımlılıkları ve çıktılarıyla birlikte tanımlanır. DVC bu pipeline'ı yürütürken hangi adımların girdilerinde değişiklik olduğunu izler; değişmeyen adımlar önbellekten okunur ve yeniden çalıştırılmaz. Bu mekanizma, büyük ML projelerinde hesaplama süresini önemli ölçüde azaltır. Deney yönetimi açısından DVC Experiments, hiperparametre değişikliklerini birer Git commit gibi izler; farklı çalıştırmalar karşılaştırılabilir ve en iyi deney seçilerek ana dala birleştirilebilir. CI/CD entegrasyonu için GitHub Actions, GitLab CI ve diğer platformlarla doğrudan çalışır; bu sayede her kod değişikliğinde veriye dayalı testler otomatik tetiklenebilir. Python API'si ve komut satırı arayüzüne ek olarak DVC, VS Code eklentisi ve çeşitli IDE araçlarıyla da entegre çalışır. MLflow ile birlikte kullanıldığında deney takibi ve veri sürümleme birbirini tamamlar: MLflow metrik ve parametre kaydederken DVC hangi veri sürümüyle hangi modelin üretildiğini takip eder. Türkiye'de veri bilimi ekibi kuran kuruluşlar için DVC, hem kurulum kolaylığı hem de Git ekosistemiyle tam uyum nedeniyle tercih edilen ilk MLOps aracı olma eğilimindedir.

arrow_forward
sync_alt

ETL (Extract, Transform, Load)

ETL (Extract, Transform, Load — Çıkar, Dönüştür, Yükle), farklı kaynak sistemlerden ham verinin toplanıp temizlenerek analitik bir hedefe aktarılmasını sağlayan veri entegrasyon sürecidir. Her veri mühendisliği ve veri ambarı projesinin omurgasını oluşturur; kaliteli veriyi olmayan hiçbir makine öğrenimi modeli ya da iş zekası raporu başarılı olamaz. Extract (Çıkarma) aşamasında veri; ilişkisel veritabanları, REST API-ları, dosya sistemleri (CSV, JSON, XML, Parquet), akış platformları (Kafka, Kinesis) veya SaaS uygulamalarından ham biçimde çekilir. Transform (Dönüştürme) aşamasında bu ham veri; temizlenir (eksik ve tutarsız değerler giderilir), normalize edilir (farklı kaynaklardaki kodlamalar birleştirilir), zenginleştirilir (dış referans tablolarıyla birleştirilir) ve hedef şemaya dönüştürülür. Load (Yükleme) aşamasında ise işlenmiş veri; veri ambarı, veri gölü veya analitik veritabanına yazılır. Modern mimarilerde ETL-nin yerini giderek ELT (Extract, Load, Transform) alıyor: ham veri önce bulut veri ambarına yükleniyor (Amazon Redshift, Google BigQuery, Snowflake), ardından dönüşümler SQL veya dbt (data build tool) aracılığıyla doğrudan hedefteki güçlü işlem kapasitesiyle gerçekleştiriliyor. Bu yaklaşım hem maliyet hem de sürdürülebilirlik açısından avantajlıdır. Makine öğrenimi hattında ETL, feature store-ları besleyen ve model eğitimi için veri setleri hazırlayan kritik bileşendir. Yaygın ETL araçları arasında Apache Airflow, dbt, Apache Spark, Fivetran, Talend ve AWS Glue sayılabilir. Büyük ölçekli sistemlerde mikro-toplu (micro-batch) ve akış (streaming) ETL da standart pratikler arasındadır. Veri kalitesi izleme, veri soyağacı (data lineage) takibi ve şema yönetimi modern ETL boru hatlarının ayrılmaz parçaları haline gelmiştir. Doğru tasarlanmış bir ETL mimarisi, veri güvenilirliğini ve tekrarlanabilirliğini doğrudan belirleyen altyapısal temel taştır. Kurumsal ölçekte veri operasyonlarında ETL hattının kalitesi, analitik olgunluğun en önemli göstergelerinden biri olarak kabul edilmektedir.

arrow_forward
science

Experiment Tracking (Deney Takibi)

Experiment Tracking (Deney Takibi), makine öğrenmesi ve derin öğrenme projelerinde gerçekleştirilen her eğitim çalışmasının sistematik biçimde kaydedilmesi, yönetilmesi ve karşılaştırılması pratiğidir. Bir model geliştirirken veri bilimciler onlarca, hatta yüzlerce farklı deney çalışabilir: öğrenme hızı, batch size, katman sayısı, dropout oranı gibi hiperparametreleri değiştirerek modelin nasıl davrandığını gözlemler. Takip sistemi olmadan hangi konfigürasyonun en iyi sonucu verdiğini hatırlamak veya sonuçları tekrar üretmek (reproducibility) neredeyse imkânsız hale gelir. Deney takip araçları; her çalışma (run) için hiperparametreleri, eğitim ve doğrulama metriklerini (kayıp, doğruluk, F1 skoru vb.), model ağırlıklarını, kod sürümünü (git hash), ortam bilgilerini (Python sürümü, kütüphane versiyonları) ve veri seti sürümünü otomatik olarak kaydeder. Bu veriler merkezi bir dashboard üzerinde görselleştirilerek farklı çalışmalar kolayca karşılaştırılabilir ve en iyi konfigürasyon belirlenir. Ekip genelinde şeffaflık artar; bir çalışma arkadaşının aylar önce yürüttüğü deneye kolayca ulaşılabilir. Endüstri standardı araçlar arasında açık kaynaklı MLflow (Databricks, 2018), bulut tabanlı Weights & Biases (W&B), Neptune.ai ve Comet ML öne çıkmaktadır. Bu araçlar MLOps pipeline'larıyla entegre edilerek CI/CD süreçlerinde otomatik değerlendirme, model kayıt defteri bağlantılı artifact yönetimi ve hiperparametre optimizasyonu desteği sunar. Özellikle düzenleyici uyumluluk gerektiren finans, sağlık ve kamu sektörü uygulamalarında model kararlarının izlenebilir olması için denetim izi (audit trail) sağlamak amacıyla deney takibi kritik bir gereksinim hâline gelmiştir. GDPR ve HIPAA gibi çerçeveler, model kararlarının gerekçelendirilebilir ve yeniden üretilebilir olmasını zorunlu kılar. Hiperparametre optimizasyonu süreçlerinde W&B Sweeps, Optuna ve Ray Tune gibi araçlar deney takibiyle doğrudan entegre çalışarak grid search, random search veya Bayesian optimizasyon sonuçlarını otomatik olarak kayıt altına alır. Her kombinasyon ayrı bir run olarak izlenir, böylece en iyi model konfigürasyonu tutarlı biçimde belirlenir ve yeniden kullanılabilir.

arrow_forward
rocket_launch

FastAPI (Python Web Çerçevesi)

FastAPI, Python geliştiricilerinin yüksek performanslı REST API'leri hızla geliştirmesine olanak tanıyan modern bir web çerçevesidir. Sebastián Ramírez tarafından 2018 yılında yayımlanan bu çerçeve, Python'un standart tip açıklamaları (type hints) üzerine kurulu olup Pydantic ve Starlette kütüphanelerini temel alır. FastAPI, Starlette adlı ASGI tabanlı web çerçevesi üzerine inşa edilmiştir. Bir endpoint tanımlandığında Pydantic kütüphanesi gelen istekleri otomatik doğrular; Swagger UI ve ReDoc arayüzleri ekstra çaba gerekmeksizin interaktif API dokümantasyonu oluşturur. İstek gövdesi, sorgu parametreleri ve path değişkenleri fonksiyon imzasındaki tip açıklamalarından okunur; hatalı veri gönderildiğinde çerçeve otomatik olarak 422 hata yanıtı döner ve hangi alanın neden geçersiz olduğunu açıklar. Async/await desteğiyle aynı anda binlerce isteği yönetebilir; I/O ağırlıklı işlerde —veritabanı sorgusu, harici LLM API çağrısı— event loop bloklanmadan diğer istekler işlenmeye devam eder. Yapay zeka projeleri için FastAPI, modeli bir kez belleğe yükleyip her istek için yeniden yüklemeden çıkarım yapan lifespan olaylarını destekler. Streaming yanıtlar (StreamingResponse), büyük dil modellerinin token token çıktısını HTTP üzerinden gerçek zamanlı aktarmak için özellikle uygundur. Background tasks mekanizması, tahmin sonuçlarını veritabanına kaydetme veya günlük tutma gibi ikincil işlemleri ana yanıtı geciktirmeden yürütür. Performans açısından FastAPI, ASGI ve async/await mimarisiyle yüksek eşzamanlılık sunar; bağımsız kıyaslamalarda Python çerçeveleri arasında en hızlılardan biri olup Node.js ile kıyaslanabilir sonuçlar verir. Flask ve Django REST Framework ile karşılaştırıldığında, tip doğrulama ve otomatik belgeleme geliştirici deneyimini belirgin biçimde iyileştirirken üretim yüklerinde gecikmeyi düşürür. Büyük yapay zeka sistemlerinde FastAPI tipik olarak şu roller üstlenir: LLM veya görüntü modellerinin çıkarım uç noktası, RAG boru hattının orkestra katmanı, model izleme ve geri bildirim toplama API'si. Gunicorn + Uvicorn ikili, Docker ve Kubernetes ortamlarında ölçeklenebilir dağıtım için endüstri standardı haline gelmiştir.

arrow_forward
inventory_2

Feature Store (Özellik Deposu)

Özellik Deposu (Feature Store), makine öğrenmesi projelerinde özellik mühendisliği sürecini merkezi olarak yöneten, özelliklerin hesaplanmasını, saklanmasını, paylaşılmasını ve yeniden kullanılmasını sağlayan veri yönetim platformudur. Kısaca, ML modelleri için 'tek gerçek kaynak' işlevi görür. Tipik bir makine öğrenmesi iş akışında veri bilimciler zamanlarının büyük kısmını ham veriden özellik üretmeye harcar. Aynı özellikler farklı ekipler tarafından bağımsız biçimde yeniden hesaplanır, bu da hem hesaplama kaynağını israf eder hem de tutarsızlıklara yol açar. Üstelik eğitim ortamında hesaplanan özellikler ile servis (inference) ortamında hesaplanan özellikler arasında farklar oluşabilir — buna 'training-serving skew' denir ve model performansını ciddi ölçüde düşürebilir. Özellik deposu bu sorunları tek bir merkezi platform altında çözer. Modern bir özellik deposunun temel bileşenleri şunlardır: Çevrimdışı Mağaza (Offline Store), tarihsel özellik verilerini toplu işleme ve model eğitimi için saklar; bu katman genellikle bir veri ambarına (BigQuery, Snowflake) veya veri gölüne (S3, GCS) bağlanır. Çevrimiçi Mağaza (Online Store), düşük gecikmeli servis için anlık özellik değerlerini Redis, Cassandra veya DynamoDB gibi anahtar-değer depolarında tutar. Özellik Kayıt Defteri (Feature Registry), hangi özelliklerin kim tarafından tanımlandığını, nasıl hesaplandığını ve hangi modeller tarafından kullanıldığını belgeleyen katalog katmanıdır. Özellik Boru Hattı (Feature Pipeline), ham veriden özellik değerlerine ulaşan ETL/ELT süreçlerini otomatikleştirir ve özellik güncelliğini (freshness) yönetir. Özellik deposu kullanmanın temel faydaları şunlardır: Kod tekrarını önler ve hesaplama maliyetini azaltır; training-serving skew sorununu ortadan kaldırır; model yeniden üretebilirliğini (reproducibility) artırır; özellik keşfini kolaylaştırır ve veri bilimciler arasındaki iş birliğini güçlendirir. Popüler açık kaynak seçenekler arasında Feast ve Hopsworks yer alır. Bulut sağlayıcılar da bu alana girmiştir: AWS SageMaker Feature Store, Google Vertex AI Feature Store ve Databricks Feature Engineering en yaygın kullanılan yönetilen hizmetlerdir.

arrow_forward
compress

Knowledge Distillation (Bilgi Damıtma)

Knowledge Distillation (Bilgi Damıtma), büyük ve güçlü bir öğretmen modelin bilgisini daha küçük ve verimli bir öğrenci modele aktarma sürecidir. Öğrenci model, doğrudan ham etiketlerden değil; öğretmenin yumuşak olasılık çıktılarından (soft labels) öğrenerek eğitim veri kümesindeki sinyallerin ötesine geçen genelleme yeteneği kazanır. Tekniğin temeli 2015 yılında Geoffrey Hinton, Oriol Vinyals ve Jeff Dean'in yayımladığı "Distilling the Knowledge in a Neural Network" başlıklı makaledir. Hinton, öğretmenin softmax çıktılarının ham etiketlere kıyasla çok daha zengin bir öğrenme sinyali taşıdığını ortaya koydu: bir görüntü sınıflandırıcısının "kedi" olasılığı %90 iken "köpek" olasılığının %7 olması, modelin sınıflar arasındaki benzerlik yapısını kodladığını gösterir ve öğrenci bu yapıyı devralır. Teknik açıdan distilasyon iki kayıp teriminin ağırlıklı toplamını minimize eder: öğrencinin öğretmen çıktılarına ne kadar yaklaştığını ölçen KL Divergence tabanlı distilasyon kaybı ve standart çapraz entropi kaybı. Sıcaklık (temperature) parametresi softmax dağılımını yumuşatarak sınıflar arası ilişkileri belirginleştirir; tipik değerler 2-5 arasındadır. Pratik uygulamalarda distilasyon, üretim ortamları için belirleyici bir teknik haline gelmiştir. DistilBERT orijinal BERT modelinin %97 performansını %40 daha küçük ve %60 daha hızlı biçimde yeniden üretir. TinyBERT hem öğretmen çıktısından hem de ara katman temsil bilgisinden öğrenir; MobileBERT ise mobil cihaz kısıtları gözetilerek tasarlanmıştır. Distilasyon çeşitleri arasında self-distillation (modelin kendisinden öğrenmesi), multi-teacher distillation (birden fazla öğretmenden bilgi sentezi) ve cross-modal distillation (görüntü modelinin bilgisinin metin modeline aktarılması) sayılabilir. LLM çağında bu teknik, 70B+ büyük modellerin bilgisini 7B veya daha küçük görev-odaklı modellere aktarmak için kritik bir role bürünmüştür. Açık ağırlıklı büyük modeller öğretmen, küçük görev-odaklı modeller öğrenci rolü üstlenir; bu yaklaşım model sıkıştırma, budama (pruning) ve kuantizasyon ile birlikte kullanılarak donanım sınırlı ortamlarda yüksek performans elde etmeye olanak tanır. 2024-2026 döneminde bilgi damıtma, küçük dil modeli (SLM) ekosisteminin merkezine oturdu. Microsoft'un Phi-3-mini'si (3.8 milyar parametre, 2024), GPT-3.5 düzeyinde performansı mobil cihazlara taşıyan ve distilasyon temelli bir veri akışıyla geliştirilen önemli bir açık kaynak modeldir. DeepSeek-R1'in Ocak 2025'te yayımlanan damıtma varyantları, 32 milyar parametreli öğrenci modelin matematik akıl yürütmede OpenAI o1-mini'yi geride bırakmasına zemin hazırladı. Bu süreçte bilgi damıtma, kuantizasyon ve budama teknikleriyle birleştirilerek çıkarım gecikmesi ile bellek tüketimi düşürülmekte; hafif modeller akıllı telefonlar ve gömülü sistemlerde çevrimdışı çalışabilir hale gelmektedir.

arrow_forward
hub

Kubernetes (Kubernetes (K8s))

Kubernetes (K8s), konteynerleştirilmiş uygulamaların dağıtımını, ölçeklenmesini ve yönetimini otomatikleştiren açık kaynaklı bir konteyner orkestrasyon platformudur. İlk olarak Google'ın iç altyapı projesi Borg'dan ilham alınarak 2014 yılında geliştirilen Kubernetes, aynı yıl açık kaynak olarak duyurulmuş ve 2016'da Cloud Native Computing Foundation'a (CNCF) bağışlanmıştır. "K8s" kısaltması, K ile s arasındaki 8 harften türetilmiştir. Yapay zeka ve makine öğrenmesi iş yüklerinde Kubernetes kritik bir altyapı katmanı işlevi görür. Model eğitim pipeline'ları, inference sunucuları ve veri işleme bileşenleri Kubernetes üzerinde GPU node'ları arasında verimli biçimde dağıtılabilir. Horizontal Pod Autoscaler (HPA) mekanizması, gelen istek yüküne göre inference pod sayısını dinamik olarak artırıp azaltır; bu da hem maliyet kontrolü hem de yüksek erişilebilirlik açısından önemlidir. Kubernetes mimarisi iki ana katmandan oluşur: Control Plane ve Worker Node'lar. Control Plane; küme durumunu depolayan etcd veritabanını, API isteklerini işleyen API Server'ı, pod yerleşim kararlarını veren Scheduler'ı ve mevcut durumu istenen durumla eşitleyen Controller Manager'ı barındırır. Worker Node'lar ise pod'ları çalıştıran Kubelet servisi, ağ kurallarını yöneten Kube-proxy ve gerçek konteyner çalışma ortamını (containerd veya CRI-O) içerir. ML ekipleri için Kubeflow, KServe, Seldon Core ve BentoML gibi platformlar, Kubernetes üzerinde çalışan ML spesifik orkestrasyon çözümleri sunar. kubectl komut satırı aracı ve YAML tabanlı manifest dosyaları, Kubernetes kaynaklarını bildirimsel (declarative) biçimde yönetmeyi kolaylaştırır. Helm chart'ları ise karmaşık ML altyapısının paketlenip tekrarlanabilir biçimde kurulmasına olanak tanır. GitOps yaklaşımıyla Argo CD veya Flux gibi araçlar, Git deposundaki değişiklikleri otomatik olarak kümeye uygulayarak ML model güncellemelerinin tam denetlenebilirliğini ve geri alınabilirliğini garanti eder. Kubernetes, modern MLOps disiplininin temel taşlarından biri olarak kabul görmekte ve üretim ortamında model güvenilirliğini artırmaktadır.

arrow_forward
code_blocks

LLM Değerlendirme (LLM Değerlendirme)

LLM değerlendirme (LLM Evaluation), büyük dil modellerinin (LLM) yeteneklerini, güvenilirliğini ve sınırlılıklarını sistematik olarak ölçmeye yönelik yöntemler bütünüdür. Gelişen yapay zeka ekosisteminde, hangi modelin hangi görevde daha iyi performans gösterdiğini nesnel biçimde belirlemek araştırmacılar, geliştiriciler ve son kullanıcılar için kritik önem taşır. Değerlendirme yaklaşımları üç ana başlıkta incelenir. Otomatik kıyaslamalar standartlaşmış veri setleri üzerinde çalışır: MMLU (Massive Multitask Language Understanding) 57 farklı disiplinde bilgi genişliğini ölçerken, GSM8K matematiksel akıl yürütmeyi, HumanEval kod üretimini, HellaSwag ortak duyuyu sınar. Bu kıyaslamalar tekrarlanabilir ve ölçeklenebilir olmaları nedeniyle yaygın biçimde tercih edilir. İnsan değerlendirmesi, gerçek kullanıcıların ya da uzmanların modeli doğrudan sınamasını kapsar; LMSYS Chatbot Arena ELO sistemiyle modelleri karşılaştıran en bilinen örnektir. LLM-as-judge yöntemi ise bir yapay zeka modelinin başka modellerin çıktılarını puanlamasına dayanır; ölçeklendirme kolaylığı sağlasa da model önyargılarını beraberinde taşır. Değerlendirme sürecinin en büyük sorunu veri kontaminasyonudur: eğitim verilerine sızan kıyaslama soruları modelin gerçek dışı yüksek skor elde etmesine yol açar. Öte yandan mevcut kıyaslamalar İngilizce ağırlıklıdır; Türkçe dil modeli değerlendirmesi için bağımsız test setlerine ihtiyaç duyulmaktadır. OpenAI Evals, EleutherAI'nin lm-evaluation-harness ve Stanford HELM çerçeveleri araştırmacılara standart altyapı sunar. Üretimde kullanılan modeller için gerçek görev başarısını izleyen sürekli değerlendirme yaklaşımı giderek daha fazla önem kazanmaktadır. Değerlendirme metodolojisi sürekli gelişmektedir. Güvenlik odaklı kıyaslamalar (TruthfulQA, SimpleSafetyTests) modelin zararlı çıktılar üretip üretmediğini test ederken, uzun bağlam kıyaslamaları (RULER, NIAH) modelin yüz binlerce token boyunca bilgiyi tutup tutamadığını ölçer. Çok turlu diyalog değerlendirmesi, ajansal yetenek ölçümü ve çok dilli kıyaslamalar da gündemdeki öncelikli başlıklar arasındadır. Doğru değerlendirme tasarımı, güvenilir ve sorumlu yapay zeka geliştirmenin temel koşullarından biri haline gelmektedir.

arrow_forward
code_blocks

LLM Inference (Büyük Dil Modeli Çıkarımı)

LLM inference (büyük dil modeli çıkarımı), eğitimi tamamlanmış bir yapay sinir ağının yeni bir girdi metnine (prompt) yanıt üretmek amacıyla gerçek zamanlı olarak çalıştırılmasıdır. Eğitim sürecinin aksine inference, modelin ağırlıklarını güncellemez; yalnızca ileri besleme (forward pass) gerçekleştirir ve her adımda bir sonraki tokeni tahmin eder. Temel performans metrikleri şunlardır: gecikme (latency — ilk tokenin üretildiği time-to-first-token ve toplam yanıt süresi), verim (throughput — saniyedeki token sayısı, tokens/s) ve maliyet (GPU/CPU saat başına işlenen token miktarı). Bu üç faktörün dengesi, inference altyapısının tasarımını doğrudan yönlendirir. KV Cache (Key-Value Cache), transformer modellerinde her self-attention adımında yeniden hesaplama yapmaktan kaçınmak için önceki token'lerin anahtar ve değer matrislerini GPU belleğinde saklayan bir optimizasyon tekniğidir. Özellikle uzun bağlam pencerelerinde (128K token gibi) VRAM kullanımını önemli ölçüde artırdığından, bellek yönetimi kritik bir tasarım kararı haline gelir. Quantization (sayısallaştırma), model ağırlıklarını FP32'den INT8, INT4 veya GGUF/AWQ formatlarına indirerek bellek tüketimini ve hesaplama süresini düşürür. 4-bit AWQ kuantizasyonu, tam hassasiyetli modele kıyasla 4 kat daha az VRAM gerektirirken yalnızca yüzde 1-3 kalite kaybına yol açar. Büyük ölçekte LLM inference için özelleşmiş çerçeveler geliştirilmiştir: vLLM (PagedAttention ile dinamik KV cache yönetimi ve sürekli batching), TensorRT-LLM (NVIDIA GPU optimizasyonu), TGI (Hugging Face Text Generation Inference) ve llama.cpp (CPU ve Apple Silicon için kuantize çıkarım). Bu araçlar sürekli batching (continuous batching) tekniğiyle binlerce eş zamanlı isteği verimli biçimde işler. Türkiye'deki geliştiriciler için yerel inference seçenekleri şunlardır: 24 GB VRAM'e sahip RTX 3090 ile Gemma 4B veya Llama 3.1 8B tam hassasiyetle; Apple M-serisi Mac'lerde llama.cpp + GGUF Q4 formatıyla 13B modeller; bulut için Google Vertex AI, AWS Bedrock veya Replicate API. Veri gizliliği gerektiren kullanım durumlarında (sağlık, hukuk) yerel inference hem KVKK uyumu açısından hem de gecikme avantajı bakımından öne çıkar.

arrow_forward
hub

Microservices Nedir? Mikro Hizmet Mimarisi Rehberi (Mikro Hizmet Mimarisi)

Microservices yani mikro hizmet mimarisi büyük ve monolitik bir yazılım uygulamasını her biri kendi sorumluluğuna sahip küçük bağımsız ve birbirleriyle iletişim kuran servisler topluluğuna bölen bir yazılım mimarisi yaklaşımıdır. Her mikro hizmet belirli bir iş işlevini yerine getirir; kendi veritabanına sahip olabilir kendi teknoloji yığınıyla geliştirilir ve bağımsız olarak dağıtılıp ölçeklendirilebilir. Bu mimari Netflix Amazon ve Uber gibi büyük teknoloji şirketleri tarafından popüler hale getirilmiştir. Monolitik mimaride tüm bileşenler tek bir dağıtılabilir birim olarak paketlenir; uygulamanın herhangi bir parçasını güncellemek tüm sistemin yeniden dağıtılmasını gerektirir. Mikro hizmet mimarisinde ise her servis kendi yaşam döngüsüne sahiptir: farklı ekipler farklı servisleri bağımsız olarak geliştirebilir test edebilir ve production ortamına alabilir. Bu esneklik ölçek büyüdükçe geliştirme hızını korumak ve yalnızca yoğun talep gören servisleri ölçeklendirmek açısından kritik bir avantaj sunar. Yapay zeka projeleri için bu mimari özellikle değerlidir. Model serving veri ön işleme A/B testi ve orkestrasyon katmanları ayrı servisler olarak tasarlanabilir; böylece yeni bir model versiyonu canlı ortama alınırken sistemin geri kalanı kesintisiz çalışmaya devam eder. Farklı AI modelleri (NLP görüntü tanıma öneri motoru) her biri kendi kaynağını bağımsız tüketen servisler olarak çalışır; darboğazlar kolayca tespit edilip giderilebilir. Servisler REST gRPC veya mesaj kuyrukları (Kafka RabbitMQ) aracılığıyla iletişim kurar. API gateway dış istemcilerle merkezi iletişim noktası görevi görür. Devre kesici (circuit breaker) desenleri zincirleme hataları önler; servis keşfi mekanizmaları dinamik ölçeklendirmede adres çözümlemesini otomatikleştirir. Docker konteynerleri ile Kubernetes orkestrasyonu mikro hizmet dağıtımının ve yönetiminin temel altyapısını oluşturur. Küçük ekipler için başlangıçta monolitik mimari daha pratik olabilir; ancak sistem karmaşıklığı arttıkça mikro hizmetlere geçişin faydaları belirginleşir.

arrow_forward
account_tree

ML Pipeline (ML Pipeline)

Makine öğrenmesi boru hattı (ML pipeline), ham veriden model tahminine uzanan tüm adımları birbirine bağlayan otomatize bir iş akışıdır. Veri toplama, temizleme, özellik mühendisliği, model eğitimi, değerlendirme ve dağıtım gibi aşamalar bu boru hattının bileşenlerini oluşturur; her bileşen bir öncekinin çıktısını girdi olarak alır. ML boru hattının temel amacı tekrar edilebilirlik ve ölçeklenebilirliktir. Elle gerçekleştirilen deneysel süreçler, üretim ortamında tutarsız sonuçlar üretebilir; boru hattı her çalıştırmada aynı adımların aynı sırayla aynı parametrelerle uygulanmasını garanti eder. Bu tutarlılık hem hata ayıklamayı hem de modelin yeniden eğitilmesini büyük ölçüde kolaylaştırır. Scikit-learn'ün Pipeline nesnesi, veri dönüşümleri ve modelini tek bir nesneye paketler ve model seçimi için grid search ile doğrudan entegre olur. Kubeflow, MLflow ve Apache Airflow gibi araçlar bu kavramı büyük ölçekli, çok adımlı ve paralel süreçleri koordine eden orkestrasyon platformlarına taşır. Feature store (özellik deposu), ML boru hatlarının kritik bir bileşenidir. Dönüştürülmüş özellikleri merkezi bir veritabanında saklar; farklı modeller ve ekipler bu özellikleri yeniden kullanarak hem tutarlılığı hem de verimliliği artırır. Feast ve Tecton bu alanda öncü açık kaynak çözümlerdir. MLOps perspektifinden ML boru hatları, model izleme, veri kayması (data drift) tespiti ve otomatik yeniden eğitim döngüleriyle genişletildiğinde üretim ortamındaki modelleri sağlıklı tutmanın omurgasını oluşturur. Boru hattının her adımı bağımsız olarak test edilebilir, sürüm kontrolüne alınabilir ve A/B testi için paralel çalıştırılabilir. Bu modüler yapı, ekiplerin birbirini engellemeden bileşenleri bağımsız olarak geliştirmesini mümkün kılar. CI/CD for ML pratikleri, boru hattı bileşenlerinin otomatik test edilmesini ve dağıtımını standartlaştırır. Veri kalitesi sorunları, model performans düşüşleri ve altyapı hataları gibi kesintiler izleme katmanı tarafından erken tespit edilerek müdahale tetiklenir.

arrow_forward
science

MLflow (MLflow)

MLflow, makine öğrenmesi yaşam döngüsünü uçtan uca yönetmek için tasarlanmış açık kaynaklı bir MLOps platformudur. 2018 yılında Databricks tarafından başlatılan proje, kısa sürede yapay zeka ve veri bilimi topluluğunun en yaygın benimsenen araçlarından biri hâline gelmiştir. MLflow'un temel felsefesi, ML projelerinde sıkça yaşanan yeniden üretilemezlik ve organizasyon sorunlarını sistematik biçimde çözmektir. Platform dört ana bileşenden oluşur: MLflow Tracking, MLflow Projects, MLflow Models ve MLflow Model Registry. MLflow Tracking bileşeni deney parametrelerini, metriklerini, yapıtlarını ve kaynak kodunu merkezi bir depoda kayıt altına alır; böylece farklı model konfigürasyonlarını karşılaştırmak ve en iyi performansı veren yaklaşımı bulmak kolaylaşır. Bir veri bilimcisi aynı sinir ağı mimarisini farklı öğrenme hızları, veri ön işleme adımları veya hiperparametre kümeleriyle eğittiğinde MLflow her çalışmayı otomatik olarak kayıt altına alır ve görsel karşılaştırma araçları sunar. MLflow Projects bileşeni, kodu ve bağımlılıkları bir araya getiren yeniden kullanılabilir paketler oluşturmayı mümkün kılar; farklı takımların birbirinin çalışmalarını kolaylıkla çoğaltmasına olanak tanır. MLflow Models ise eğitilmiş modeli çoklu dağıtım biçimlerine dönüştürür: REST API, Python fonksiyonu, Docker konteyneri veya Apache Spark UDF olarak sunulabilir. Model Registry bileşeni, modellerin geliştirme aşamasından üretim ortamına geçişini yönetir; staging, production ve archived gibi durum etiketleriyle model sürümleme sürecini düzenler ve takım onaylarını gerektiren iş akışları tanımlamayı destekler. MLflow, scikit-learn, TensorFlow, PyTorch, XGBoost ve LangChain gibi popüler kütüphanelerle yerel entegrasyona sahiptir. Bulut ortamlarında AWS SageMaker, Azure ML ve Google Vertex AI ile de birlikte çalışabilir. Açık kaynak yapısı kurumların kendi altyapılarında çalıştırmasına ve ihtiyaca göre özelleştirmesine imkân tanır. GitHub üzerinde on binlerce yıldızla güçlü bir topluluk desteğine sahip olan platform, büyük ölçekli kuruluşlarda ve araştırma kurumlarında giderek yaygınlaşmaktadır. MLflow 2.x sürümüyle birlikte LLM izleme yetenekleri genişlemiş, prompt mühendisliği ve model değerlendirme araçları eklenmiştir.

arrow_forward
developer_board

MLOps (Machine Learning Operations) (Makine Öğrenimi Operasyonları)

MLOps (Machine Learning Operations), makine ogrenimi modellerini gelistirme, egitme, dagitma ve izleme sureclerini otomatlastirip standartlastiran bir muhendislik disiplinidir. DevOps kulturu ile veri bilimi pratiklerini bir araya getirir; amaci, ML modellerini guvenilir, olceklenebilir ve surdurulebilir bicimde uretim ortamina tasimaktir. Geleneksel yazilim gelistirme sureclerinde kod degisikliklerini yonetmek icin CI/CD pipeline'lari kullanilir. MLOps bu anlayisi model dunyasina tasir: veri kodu, egitim kodu ve model agirliklarinin hepsini ayni titizlikle surumler. Bir veri bilimci yeni bir model gelistirdiginde, MLOps altyapisi bu modeli otomatik olarak test eder, performansini gecmis modellerle karsilastirir ve onay kriterleri saglanirsa canli ortama baglar. Model kayit defteri (model registry), uretimde hangi modelin calistigini, hangi veri setiyle egitildigini ve hangi hiperparametrelerle yapilandirildigini merkezi olarak kaydeder. Bu sayede bir model sorun cikardiginda ekip, onceki surume dakikalar icinde geri donebilir. DVC (Data Version Control) gibi araclar veri surumlemesini yonetirken MLflow veya Weights & Biases deney izlemeyi ustlenir. Uretim ortaminda modellerin zamanla bozulmasi, yani model drift, MLOps'un cozdugu kritik sorunlardan biridir. Gelen gercek dunya verisinin dagilimi degistikce modelin tahmin kalitesi duser. Izleme katmani bu kaymayi erken tespit eder ve otomatik yeniden egitim tetikler ya da uyari gonderir. Google'in yayinladigi MLOps olgunluk modeli, sirketleri 0'dan 2'ye kadar uc seviyede siniflandirir: Seviye 0'da her sey manueldir; veri bilimciler modeli laptoplarinda egitip elle yukler. Seviye 1'de egitim pipeline otomatiktir. Seviye 2'de ise CI/CD her sey dahil olup pipeline'in kendisi de otomatik olarak guncellenir. MLOps'un uygulanmasi, yalnizca teknik degeril kulturel bir donusum da gerektirir. Veri bilimcileri, veri muhendisleri ve DevOps ekiplerinin ortak bir dil ve is akisi gelistirmesi gerekir. Bu kucultucuyu asabilen organizasyonlar, model dagitim surelerini haftalardan saatlere indirgeyip yapay zeka yatirimlarindan cok daha yuksek geri donus elde eder. **Sik Sorulan Sorular** **MLOps ile DevOps arasindaki temel fark nedir?** DevOps kod ve yazilim dagitimina odaklanirken MLOps buna ek olarak veri surumlemesi, model egitimi, hiperparametre yonetimi ve model drift izleme gibi ML'e ozgu katmanlari kapsar. **Kucuk bir ekip icin MLOps gerekli midir?** Tek bir modelle baslayan ekipler bile DVC ve MLflow gibi hafif araclarla temel MLOps pratiklerini benimsemelidir; aksi takdirde tekrarlanamaz deneyler ve kayip modeller kacunilmaz olur. **MLOps icin hangi programlama dili onceliklidir?** Python ekosistemi hakimdir: scikit-learn, TensorFlow ve PyTorch ile egitim; FastAPI veya BentoML ile servis; Airflow veya Prefect ile orkestrasyon. **Model drift ne kadar siklukla izlenmelidir?** Bu, verinin degisim hizina baglidir. Finansal dolandiricilik modelleri gercek zamanli izleme gerektirirken urun tavsiye sistemleri gunluk veya haftalik kontrol yeterli olabilir.

arrow_forward
rocket_launch

Model Deployment (Model Dağıtımı)

Model Dağıtımı (Model Deployment), bir makine öğrenmesi veya derin öğrenme modelinin araştırma ve geliştirme ortamından alınarak gerçek dünya kullanıcılarına hizmet verecek üretim ortamına (production) taşınma sürecidir. Bu süreç, bir yapay zeka projesinin kritik son aşamasını oluşturur; en yüksek doğruluklu model bile kullanıcılara ulaşamazsa hiçbir değer üretemez. Dağıtım süreci birkaç temel aşamayı kapsar: modelin optimize edilmesi ve paketlenmesi, servis altyapısının kurulması, API uç noktalarının yapılandırılması, gerçek zamanlı (real-time) veya toplu (batch) tahmin hizmetlerinin devreye alınması ve sürekli izleme mekanizmalarının aktif edilmesi. Model, ONNX, TensorFlow SavedModel, PyTorch TorchScript gibi taşınabilir formatlara dönüştürülerek farklı platformlarda çalışabilir hale getirilir. Dağıtım stratejileri uygulamanın gereksinimlerine göre değişir. Mavi-Yeşil (Blue-Green) dağıtımda eski ve yeni model sürümleri paralel çalışır, trafik kesintisiz aktarılır. Kanarya (Canary) dağıtımında yeni model önce küçük bir kullanıcı grubuna sunularak riskler minimize edilir. A/B testi stratejisiyle farklı model sürümlerinin performansı karşılaştırılarak en iyi model seçilir. Shadow dağıtımda ise yeni model gerçek trafik üzerinde sessizce çalışır ancak kullanıcıya yanıt vermez; bu yol üretim davranışını risk almadan gözlemlemeye yarar. Dağıtım ortamları bulut (cloud), uç bilişim (edge) veya yerel sunucu (on-premise) olabilir. LLM gibi büyük dil modelleri genellikle GPU kümelerinde çalıştırılırken, küçük ve kuantize edilmiş modeller akıllı telefon ve IoT cihazları gibi uç ortamlarda koşturulabilir. NVIDIA Triton Inference Server, TensorFlow Serving, Seldon Core, BentoML ve MLflow gibi araçlar modern model dağıtım ekosisteminin temel taşlarıdır. Model izleme, başarılı bir dağıtımın ayrılmaz parçasıdır. Veri kayması (data drift), kavram kayması (concept drift) ve performans düşüşleri sürekli izlenerek gerektiğinde otomatik yeniden eğitim (retraining) tetiklenir. Gecikme (latency), işlem hacmi (throughput) ve hata oranları gibi operasyonel metrikler SLA gereksinimlerini karşılayıp karşılamadığını belirler. Otomasyon düzeyi arttıkça model dağıtımı MLOps disiplininin merkezine taşınmakta; CI/CD boru hatlarıyla entegrasyon, model kayıt defteri (model registry) yönetimi ve otomatik geri alma (rollback) mekanizmaları standart pratik haline gelmektedir. Ölçeklenebilir ve güvenilir bir dağıtım altyapısı, modelin iş değerine dönüştürülmesindeki son ve belirleyici adımdır.

arrow_forward
monitor

Model Monitoring (Model İzleme)

Model izleme (model monitoring), üretime alınan makine öğrenmesi modellerinin performans ve veri kalitesini sürekli olarak gözlemleyen, ölçen ve değerlendiren sistematik bir MLOps pratiğidir. Modeller statik yapılar değildir; gerçek dünya verisi zamanla değiştiğinden model çıktıları herhangi bir hata mesajı üretmeksizin yavaşça bozunabilir. Model izleme bu sessiz bozunumu erken aşamada tespit ederek zamanında müdahale imkânı yaratır ve böylece olası iş kayıplarının önüne geçilmesini mümkün kılmaktadır. Bozunumun iki temel mekanizması vardır. Veri drifti, giriş özelliklerinin istatistiksel dağılımının eğitim verisinden uzaklaşmasıdır; örneğin bir kredi skoru modelinde müşteri yaş dağılımının değişmesi giriş drifti oluşturur. Kavram drifti ise özellikler ile hedef değişken arasındaki ilişkinin değişmesidir; pandemi döneminde 'seyahat' aramasının farklı bir satın alma niyetine işaret etmesi buna tipik bir örnektir. Bunların yanı sıra tahmin drifti (model çıktılarının dağılımının kayması) ve veri kalitesi sorunları (eksik değerler, şema değişiklikleri) da üretim modellerini olumsuz etkileyen başlıca drift biçimleri arasında yer almaktadır. Etkili bir izleme stratejisi üç katmanda metrikleri birlikte değerlendirir. Altyapı katmanında API gecikme süresi, hata oranı ve kaynak kullanımı izlenir. Model katmanında sınıflandırma için precision/recall/F1/AUC, regresyon için MAE/RMSE, dil modelleri için BLEU ve perplexity gibi göstergeler takip edilir. İş katmanında ise tıklama oranı, dönüşüm ve churn gibi iş kararlarını doğrudan etkileyen metrikler değerlendirilir. Yeniden eğitim (retraining) için zamana dayalı veya tetikleyici tabanlı yaklaşım uygulanabilir. Modern MLOps sistemleri bu döngüyü tam otomasyona bağlar: drift algıla, etiketli veri topla, yeniden eğit, A/B testinde karşılaştır ve yeni modeli dağıt. Büyük dil modellerinde ise halüsinasyon oranı, güvenlik filtresi atlatma girişimleri ve yanıt kalite skoru gibi özel göstergeler giderek daha fazla önem kazanmaktadır.

arrow_forward
code_blocks

Model Quantization (Model Kuantizasyonu — Ağırlık Hassasiyet Azaltma)

Model kuantizasyonu (Model Quantization), büyük yapay zeka modellerinin ağırlık ve aktivasyon değerlerini yüksek hassasiyetli kayan noktalı sayılardan (FP32, FP16) daha düşük bitli tam sayı gösterimlerine (INT8, INT4, hatta INT2) dönüştüren bir model sıkıştırma tekniğidir. Bu dönüşüm, modelin bellek ayak izini küçültür, çıkarım hızını artırır ve daha az enerji tüketerek Edge cihazlarda veya tüketici donanımlarında büyük dil modellerinin çalıştırılmasını mümkün kılar. Temel fikir şudur: bir FP32 değer 4 bayt kaplarken INT8 yalnızca 1 bayt, INT4 ise yarım bayt kullanır. 7 milyar parametreli bir LLM FP16 olarak yaklaşık 14 GB VRAM gerektirirken, INT4 kuantizasyonuyla bu ihtiyaç ~4 GB'a düşer ve sıradan bir tüketici GPU'sunda çalışır hale gelir. Başlıca kuantizasyon yaklaşımları şunlardır: **Eğitim Sonrası Kuantizasyon (PTQ — Post-Training Quantization)**, eğitilmiş modeli yeniden eğitmeden doğrudan dönüştürür; GPTQ, AWQ ve llama.cpp bu yöntemi kullanır. **Kuantizasyon Farkındalıklı Eğitim (QAT — Quantization-Aware Training)** ise eğitim sırasında kuantizasyon hatasını simüle ederek daha yüksek doğruluk sunar ancak ek hesaplama maliyeti gerektirir. Bunlara ek olarak **GGUF/GGML formatları** (llama.cpp ekosistemi), **bitsandbytes** (Hugging Face entegrasyonu) ve **ONNX Runtime** kuantize modelleri verimli çalıştıran araçlardır. Kuantizasyonun temel ödünleşimi doğruluk ile verimlilik arasındadır. INT8 genellikle FP32'ye kıyasla %1'in altında doğruluk kaybıyla son derece iyi çalışır. INT4 daha yüksek kayıp gösterebilir; ancak GPTQ ve AWQ gibi kalibrasyonlu yöntemler bu kaybı perplexity açısından ihmal edilebilir düzeyde tutar. Model boyutu ve görev karmaşıklığı arttıkça kuantizasyona dayanıklılık artma eğiliminde olduğu için büyük LLM'ler küçük modellere göre daha az bozunumla kuantize edilir. Pratik kullanımda Ollama, LM Studio ve Jan gibi yerel LLM araçları modellerini GGUF formatında INT4/INT8 kuantize olarak sunar. Hugging Face Hub'da TheBloke gibi topluluk hesapları yaygın modelleri GGUF ve AWQ kuantizasyonlarıyla yayımlar. 2024-2026 döneminde Microsoft'un BitNet gibi deneysel mimarileri 1-bit kuantizasyonu araştırırken, Apple Silicon'ın ANE birimi INT4 çıkarımını CPU/GPU hibrit olarak verimli gerçekleştirir.

arrow_forward
inventory_2

Model Registry (Model Kayıt Defteri)

Model Kayıt Defteri (Model Registry), makine öğrenimi (ML) operasyonlarının (MLOps) temel altyapı bileşenlerinden biridir. Yazılım geliştirmede kullanılan Git sürüm kontrol sistemi veya PyPI paket yöneticisi gibi araçların ML modelleri için tasarlanmış işlevsel eşdeğeridir; eğitilmiş modellerin merkezi bir depoda saklanmasını, sürümlenmesini ve yaşam döngüsünün yönetilmesini sağlar. Bir ML modeli her yeniden eğitildiğinde, oluşturulan model dosyaları ve meta veriler kayıt defterine yüklenerek numaralı bir sürüm elde eder. Bu sürüme; kullanılan veri kümesinin sürümü, hiperparametre değerleri, doğruluk metrikleri, F1 skoru, eğitim kodu commit hash'i ve sorumlu ekip üyesi bilgisi gibi veriler otomatik olarak iliştirilebilir. Bu sayede herhangi bir modeli tek komutla yeniden oluşturmak ya da geçmiş sürümüne rollback yapmak mümkün olur. Model kayıt defterleri genellikle üç temel aşama kavramını destekler: Staging (üretim öncesi nihai test ortamı), Production (canlı trafiğe hizmet veren onaylı model) ve Archived (artık kullanılmayan ama tarihsel kayıt için saklanan model). Ekipler veya otomatik kalite kapıları, modeli bu aşamalar arasında terfi ettirme (promote) ya da geri çekme (rollback) yetkisine sahiptir. Bu yapının başlıca faydaları şöyle sıralanabilir: Yeniden üretilebilirlik — bir yıl önceki üretim modelini tam bağlamıyla geri almak mümkün olur; Denetlenebilirlik — hangi modelin ne zaman, kim tarafından devreye alındığı otomatik kayıt altına alınır; İş birliği — farklı ekiplerin aynı model üzerinde bağımsız çalışabilmesi sağlanır; Uyumluluk — GDPR ve HIPAA gibi yasal düzenlemeler için gereken denetim izi otomatik oluşturulur. Sektörde en yaygın araçlar arasında açık kaynaklı MLflow Model Registry (Databricks ekosistemi), Amazon SageMaker Model Registry, Google Vertex AI Model Registry ve Azure Machine Learning Model Registry sayılabilir. Büyük organizasyonlarda model kayıt defteri, Feature Store ve CI/CD pipeline'larıyla birlikte kurgulanan bütünleşik bir MLOps platformunun ayrılmaz parçası haline gelmiştir.

arrow_forward
cloud_upload

Model Serving (Model Servis (Çıkarım Sunumu))

Model serving (model sunucu), eğitilmiş bir makine öğrenimi modelini gerçek dünya kullanıcılarına veya sistemlerine çıkarım (inference) hizmeti verecek biçimde dağıtma ve işletme sürecinin tüm bütününü kapsar. Araştırma ortamında yüksek doğruluk sergileyen bir model, güvenilir bir servis altyapısı kurulmadan iş değerine dönüşemez; model serving bu boşluğu dolduran mühendislik disiplinidir. Bir model serving sistemi gelen HTTP veya gRPC isteklerini alır, modeli bellekte etkin biçimde tutar ve tahmin sonuçlarını olabildiğince kısa gecikmeyle geri döndürür. Büyük ölçekli sistemlerde bu süreç saniyede binlerce isteği karşılar. Başarının üç temel metrikle ölçüldüğü kabul görür: gecikme süresi (latency, tek bir isteğin yanıt süresi), verim (throughput, birim zamanda işlenen istek sayısı) ve kullanılabilirlik (availability, sistemin kesintisiz çalışma oranı). Servis modelleri kullanım senaryosuna göre üçe ayrılır. Çevrimiçi servis (online serving) gerçek zamanlı tahmin gereksinimlerini karşılar ve öneri sistemleri ile dolandırıcılık tespitinde yaygındır. Toplu iş servisi (batch serving) büyük veri kümeleri üzerinde önceden planlanmış tahminler yürütür; gecikme toleransı yüksek, işlem hacmi büyük görevler için uygundur. Akış servisi (stream serving) ise Kafka veya Pub/Sub gibi mesaj kuyrukları üzerinden sürekli veri akışını işler; IoT sensör analizi ve gerçek zamanlı anomali tespiti bu kategoride yer alır. Performans optimizasyonu açısından kuantizasyon (quantization), model ağırlıklarını FP32'den INT8 veya FP16'ya indirerek bellek kullanımını ve gecikmeyi azaltır. Dinamik gruplama (dynamic batching), birden fazla isteği bir arada işleyerek GPU verimliliğini artırır. Model önbellekleme (caching) ise tekrar eden sorguların yeniden hesaplanmasını önler. NVIDIA Triton Inference Server, TorchServe, BentoML ve KServe gibi çıkarım sunucuları bu optimizasyonları yönetilen biçimde sunar. Bulut tarafında AWS SageMaker, Google Vertex AI ve Azure ML, tam yönetilen model serving altyapısı olarak öne çıkar.

arrow_forward
code_blocks

NVIDIA NIM (NVIDIA NIM)

NVIDIA NIM (NVIDIA Inference Microservices), yapay zeka modellerini kurumsal ortamlarda hızlı, güvenli ve ölçeklenebilir biçimde devreye almak için tasarlanmış konteyner tabanlı bir mikroservis paketidir. Mart 2024'teki GTC konferansında duyurulan ve Nisan 2024'te NVIDIA AI Enterprise 5.0 kapsamında genel kullanıma açılan NIM, her biri bir Docker konteyneri olarak paketlenmiş hazır model servislerinden oluşur. Her NIM konteyneri; model ağırlıkları, otomatik olarak seçilen çıkarım arka ucu (TensorRT-LLM, vLLM veya SGLang) ve OpenAI API uyumlu bir REST API uç noktasından oluşur. Bu sayede geliştiriciler, mevcut OpenAI tabanlı uygulamalarını minimum kod değişikliğiyle kendi GPU altyapısına taşıyabilir. Çıkarım arka ucu, hedef GPU'ya ve model türüne göre otomatik seçilir; FP8, INT4 ve GGUF gibi nicemleme (quantization) formatları desteklenerek bellek kullanımı optimize edilir. NIM, NVIDIA'nın NGC (GPU Cloud) kataloğu üzerinden yüzlerce model sunar: Meta Llama 3.x ailesi (8B, 70B, 405B), Mistral, Google Gemma, Stable Diffusion, Whisper ve NVIDIA Cosmos video modelleri bu katalogda yer alır. Dağıtım ortamı esnekliği açısından NIM; yerel sunucularda, veri merkezlerinde ve Amazon AWS, Microsoft Azure ile Google Cloud gibi büyük bulut sağlayıcılarında çalışabilir. Kurumsal kullanım için NIM konteynerleri kriptografik olarak imzalanmış, CVE açık taramasından geçirilmiş ve SBOM (Yazılım Malzeme Listesi) belgesiyle birlikte yayımlanmıştır. Hava boşluklu (air-gapped) ortamlar da desteklenmektedir. KVKK gibi yerel düzenleyici gereksinimleri olan Türk kurumları için NIM, bulut bağımlılığını ortadan kaldırarak tam veri egemenliği sağlayan bir çözüm sunar. Kubernetes yerel ölçeklendirme desteği sayesinde NIM, düşük gecikme ve yüksek verim gerektiren üretim ortamları için idealdir; RAG pipeline'ları, ajan sistemleri ve gerçek zamanlı çıkarım uygulamalarında yaygın olarak kullanılmaktadır. NVIDIA'nın kendi kıyaslama ölçümlerine göre NIM, optimize edilmiş TensorRT-LLM arka ucuyla standart dağıtımlara kıyasla 3-5 kat daha yüksek token verimi sunabilmekte; bu avantaj özellikle yoğun üretim trafiğinde belirginleşmektedir.

arrow_forward
code_blocks

Observability Nedir? Yapay Zeka ve LLM Sistemlerinde Gözlemlenebilirlik (Gözlemlenebilirlik)

Observability (gözlemlenebilirlik), bir sistemin iç durumunu yalnızca dış çıktılarına bakarak anlama ve keşfetme kapasitesini ifade eder. Rudolf Kalman'ın 1960'lardaki kontrol teorisi çalışmalarından yazılım mühendisliğine uyarlanan bu kavram, günümüzde makine öğrenmesi ve büyük dil modeli altyapılarının vazgeçilmez bir bileşenidir. Geleneksel yazılım observability'si üç temel sütun üzerine kurulur: loglar (zaman damgalı olaylar), metrikler (sayısal ölçümler) ve izler (dağıtık sistemlerde istek yolları). Monitoring ile sıkça karıştırılmakla birlikte, aralarında kritik bir fark bulunur. Monitoring önceden tanımlanmış eşikleri ve bilinen soruları izler; observability ise henüz sormadığımız soruları sormamıza imkân tanır. Başka bir deyişle, bilinmeyen sorunları keşfetme kapasitesi kazandırır. Yapay zeka ve LLM sistemlerinde observability geleneksel üç sütunun çok ötesine geçer. Model çıktısı kalitesi, veri kayması, tahmin dağılımı değişiklikleri ve LLM'e özgü parametreler bu kapsama dahildir. LLMOps bağlamında kritik observability bileşenleri şunlardır: her istekteki token kullanımı ve gecikme metrikleri, prompt sürüm yönetimi, halüsinasyon oranı takibi, kullanıcı geri bildirim korelasyonu ve uçtan uca iz kaydı. Bu veriler olmadan LLM tabanlı ürünleri güvenilir biçimde operasyonel tutmak mümkün değildir. Öncü araçlar arasında Langfuse (açık kaynak LLM izleme), Arize Phoenix (ML gözlemlenebilirlik platformu), Weights & Biases Weave (LLM tracing), MLflow (deney yönetimi) ve OpenTelemetry (platform bağımsız telemetri standardı) yer almaktadır. Bu araçlar modelin kara kutu olmaktan çıkıp denetlenebilir bir sisteme dönüşmesini mümkün kılar. Kurumsal ortamlarda LLM observability, GDPR ve AB Yapay Zeka Yasası kapsamındaki denetim yükümlülükleri için de kritik öneme sahiptir. Hangi prompta ne yanıtın üretildiğini izleyebilmek, hukuki hesap verebilirlik ve güvenlik açısından giderek zorunlu hale gelmektedir. Güçlü bir observability altyapısı, model gerileme tespitini, A/B deneyi karşılaştırmasını ve kullanıcı deneyimi iyileştirme döngüsünü hızlandırır.

arrow_forward
account_tree

Pipeline (Boru Hattı)

Makine öğrenimi bağlamında pipeline (boru hattı), ham veriden nihai tahmine ya da çıktıya uzanan işlem adımlarının zincirlendiği sistemdir. Her adım bir öncekinin çıktısını girdi olarak alır; veri ön işleme, özellik mühendisliği, model çıkarımı ve son işleme adımları tek bir tutarlı birim olarak kapsüllenir. Bu yapı hem tekrar kullanımı hem de dağıtım tutarlılığını artırır: geliştirme ortamında çalışan pipeline, üretimde de birebir aynı davranışı sergiler. Pipeline'ın en belirgin avantajı, karmaşık iş akışlarını yönetilebilir, test edilebilir ve bağımsız olarak güncellenebilir birimlere bölmesidir. Veri kayması (data drift) veya model bozulması durumunda sorunlu adım izole edilerek hızla müdahale edilebilir. Yeniden üretilebilirlik (reproducibility) açısından pipeline, veri ve model sürümlemesiyle birlikte MLOps'un temel taşını oluşturur. Hugging Face Transformers kütüphanesi, NLP ve bilgisayarlı görü görevleri için yüksek seviyeli pipeline arayüzleri sunar. `pipeline('sentiment-analysis')` gibi tek satırlık çağrılarla tokenizasyon, model çalıştırma ve sonuç son işleme otomatik olarak gerçekleşir. Transformers.js, aynı pipeline API'sini JavaScript'e taşıyarak tarayıcı ve Node.js ortamlarında çalıştırabilir hale getirir. MLOps platformlarında pipeline kavramı daha geniş bir anlam taşır: veri toplama, eğitim, değerlendirme, dağıtım ve izleme adımlarını kapsayan uçtan uca ML yaşam döngüsü iş akışını ifade eder. Kubeflow Pipelines, MLflow ve Apache Airflow bu tür pipeline'ları orkestre etmek için kullanılan platformlardır. CI/CD analojisiyle düşünüldüğünde ML pipeline, yazılım pipeline'ının veri ve model boyutundaki karşılığıdır. Büyük dil modeli (LLM) odaklı pipeline'lar klasik ML pipeline'larından ayrışır. Eğitim aşaması büyük ölçüde yerini RAG (Retrieval-Augmented Generation) entegrasyonuna, araç çağrısına (tool calling) ve prompt mühendisliğine bırakır. Tipik bir üretim RAG pipeline'ı şu adımları sırayla yürütür: belge parçalama → gömme oluşturma → vektör indeksleme → kullanıcı sorgusunu alma → benzerlik araması → bağlam oluşturma → LLM çıkarımı. LangChain ve LlamaIndex bu bileşenleri modüler biçimde sunar.

arrow_forward
cached

Prompt Caching (Prompt Önbellekleme)

Prompt önbellekleme (Prompt Caching), büyük dil modeli (LLM) API'larında aynı prompt ön ekinin birden fazla istekte tekrar tekrar kullanılması durumunda, modelin bu ön ek için önceden hesapladığı dikkat tensörlerini (KV cache) sunucu tarafında saklayarak yeniden hesaplama maliyetini ortadan kaldıran bir optimizasyon tekniğidir. Bir LLM her prompt işlediğinde her token için anahtar-değer (key-value, KV) dikkat tensörleri hesaplar. Prompt önbellekleme bu tensörleri sunucuda saklar; sonraki istek aynı ön ekle başlıyorsa model onları sıfırdan hesaplamak yerine doğrudan önbellekten yükler. Bu sayede hem hesaplama süresi hem de faturalanan giriş maliyeti önemli ölçüde düşer. Teknik özellikle uzun sistem prompt'larının, büyük belgelerin veya kapsamlı örnekler içeren şablonların yüzlerce ya da binlerce ardışık istek için tekrar gönderildiği senaryolarda kayda değer tasarruf sağlar. Ajansal döngülerde (agentic loops), RAG boru hatlarında ve çok turlu sohbet uygulamalarında girdi token maliyetleri toplam harcamanın büyük bölümünü oluşturur; prompt önbellekleme bu senaryolarda üretim AI sistemlerinin ekonomik sürdürülebilirliğini doğrudan etkiler. 2024'ten itibaren Anthropic (Claude), OpenAI (GPT-4o ve üstü), Google (Gemini) ve DeepSeek başta olmak üzere büyük LLM sağlayıcıları bu özelliği sunmaktadır. Uygulamalar arasında fark mevcuttur: Anthropic açık `cache_control` parametresiyle işaret isterken, OpenAI belirli bir token eşiğini aşan sabit ön ekleri otomatik önbellekler. Her iki yaklaşımda da önbellekteki token'lar normal girdi fiyatının %10-50'siyle faturalandırılır; bu oran giriş maliyetlerinde %50 ila %90 tasarruf anlamına gelir. Anthropic'te önbellek ömrü yaklaşık 5 dakika olup her kullanımda yenilenir. Minimum önbellekleme eşiği sağlayıcıya göre 1.024-2.048 token arasında değişir. Maliyet avantajının yanı sıra, önbellekten okunan token'lar yeniden hesaplama gerektirmediğinden ilk token gecikmesi (TTFT, time-to-first-token) de önemli ölçüde düşer; Anthropic bu iyileşmenin %85'e kadar ulaşabildiğini bildirmektedir. vLLM ve SGLang gibi açık kaynak çıkarım çerçeveleri de GPU üzerinde benzer KV önbellekleme mekanizmaları sunar.

arrow_forward
code_blocks

Technical Debt (Teknik Borç)

Teknik borç (İngilizce: Technical Debt), Ward Cunningham tarafından 1992 yılında ortaya atılan bir yazılım mühendisliği metaforudur. Kısa vadeli çözüm tercihlerinin uzun vadede ek bakım ve yeniden yazım maliyeti doğurduğunu anlatmak için borç benzetmesini kullanır: kolayca seçilen yol bir finansal kısayol gibidir ve zamanla "faiz" olarak geri döner. Kodun karmaşıklığı ve kırılganlığı arttıkça yeni özellik ekleme süresi de giderek uzar. Teknik borç dört ana türde karşımıza çıkar: bilinçli kasıtlı borç (teslimat tarihine yetişmek adına farkında olarak kabul edilen kısayollar), kasıtsız borç (bilgi eksikliğinden kaynaklanan tasarım hataları), çevresel borç (kullanılan kütüphane ve altyapıların eski sürümlerde kalması) ve test borcu (yetersiz test kapsamı nedeniyle birikmiş risk ve kırılganlık). Her borç türünün farklı bir tespiti ve geri ödeme stratejisi vardır. Makine öğrenimi sistemleri teknik borca karşı özellikle savunmasızdır. Google araştırmacılarının 2015 yılında yayımladığı "Hidden Technical Debt in Machine Learning Systems" (Sculley vd.) makalesi, bir ML sisteminde gerçek model kodunun yalnızca küçük bir bölüm oluşturduğunu; asıl borç yükünün veri hattı, özellik mağazası, model izleme, hiperparametre takibi ve sistem konfigürasyonu bağımlılıklarında biriktiğini göstermiştir. MLOps disiplini tam da bu sorunları sistematik biçimde gidermek amacıyla geliştirilmiştir. Teknik borç yönetiminde SonarQube, CodeClimate ve Pylint gibi statik analiz araçları kullanılır. Stratejik çözüm yolları arasında sprint kapasitesinin yüzde on beş-yirmisini borç azaltmaya ayırmak, düzenli kod incelemeleri düzenlemek ve mimari yeniden yapılandırma (refactoring) dönemleri planlamak öne çıkar. Borç görmezden gelindiğinde teslim süreleri uzar, hata oranları artar ve mühendis motivasyonu geriler. Bilinçli alınan teknik borç meşru bir iş kararı olabilir; ancak belgelenmesi ve geri ödeme planı yapılması zorunludur. Ödenmeden bırakılan borç ise sistemin uzun vadeli geliştirilebilirliğini ve ölçeklenebilirliğini ciddi biçimde zayıflatır.

arrow_forward
engineering

Technical Debt (AI) (Teknik Borç)

Yapay zeka bağlamındaki teknik borç (Technical Debt in AI), geleneksel yazılım teknik borcunun tüm biçimlerini kapsarken makine öğrenmesi projelerine özgü ek borç kategorilerini de içermektedir. Ward Cunningham tarafından 1992 yılında ortaya atılan bu metafor, hızlı alınan ancak özenle tasarlanmamış kararların gelecekte ek bakım ve düzeltme maliyeti doğurduğunu ifade eder. D. Sculley ve ekibinin Google bünyesinde yürüttüğü etkili araştırma, ML sistemlerindeki gizli teknik borç kavramını sistematik biçimde tanımlamış; model kodunun genellikle tüm kod tabanının yalnızca küçük bir kesimini oluşturduğunu, asıl karmaşıklığın veri boru hatları, özellik mühendisliği, izleme altyapısı ve servis entegrasyonunda biriktiğini ortaya koymuştur. Veri bilimine yatırım yapan organizasyonlar çoğunlukla bu borçla yüzleşmekte gecikmekte ve sonunda ciddi operasyonel sorunlarla karşılaşmaktadır. ML'ye özgü başlıca teknik borç kategorileri şunlardır: veri sızıntısı (eğitim ve test kümelerinin yanlışlıkla örtüşmesi), özellik dolanıklığı (feature entanglement), gizli geri bildirim döngüleri, kayıtsız bağımlılıklar (undeclared consumers), korelasyon tabanlı özellikler ve dağıtım kaymasından (distribution shift) kaynaklanan sessiz model çöküşleri. CACE prensibi (Changing Anything Changes Everything) bu dolanıklık sorununu çarpıcı biçimde özetler: herhangi bir özelliğin değiştirilmesi modelin tüm davranışını beklenmedik şekillerde dönüştürebilir. Bu nedenle kapsamlı regresyon testleri ve özellik atıf analizleri vazgeçilmez hale gelmektedir. MLOps pratiklerinin olgunlaşmasıyla birlikte teknik borç yönetimi için çeşitli çerçeveler ve araçlar geliştirilmiştir. Düzenli model kartı güncellemeleri, özellik deposu (feature store) kullanımı, veri sözleşmeleri (data contracts) ve kapsamlı model izleme panoları bu yaklaşımların başında gelmektedir. MLflow, DVC ve Weights & Biases gibi araçlar deney takibini kolaylaştırarak bilgi borcunu önemli ölçüde azaltmaktadır. Her çeyreğe bir yeniden yapılandırma sprinti dahil etmek, teknik borcun kontrolden çıkmasını önleyen pratik ve etkili bir organizasyonel stratejidir. Uzun vadede bu borcu yönetmek; sistem güvenilirliği, bakım kolaylığı ve ekip verimliliği açısından doğrudan kazanım yaratır.

arrow_forward
code_blocks

Unit Testing (Birim Testi)

Birim testi (unit test), bir yazılım sisteminin en küçük test edilebilir parçasını — genellikle tek bir fonksiyon, metot ya da sınıfı — diğer bileşenlerden bağımsız biçimde doğrulayan otomatik test yöntemidir. Her birim, belirlenmiş giriş değerleri verildiğinde beklenen çıktıyı üretip üretmediği kontrol edilerek onaylanır. Yapay zeka ve makine öğrenmesi projelerinde birim testi, geleneksel yazılımdan daha karmaşık bir hal alır: modeller deterministik değildir ve eğitim süreci rastgelelik içerir. Bu nedenle AI projelerinde birim testinin odağı modelin ağırlıklarını değil; veri ön işleme fonksiyonlarını, özellik mühendisliği adımlarını, normalleştirme dönüşümlerini ve model tahmini sarmalayıcılarını kapsayacak şekilde belirlenir. Python ekosisteminde pytest, unittest ve parametrize edilmiş testler AI projelerinin temel araçlarıdır. Harici bağımlılıklar (veritabanı, OpenAI API, Replicate) mock nesnelerle ikame edilerek testler ağ bağlantısı olmadan deterministik biçimde çalıştırılır. HuggingFace Transformers kütüphanesi, test esnasında gerçek model ağırlıklarını yüklemeden pipeline davranışını doğrulayabilen yardımcı test araçları sunar. Büyük dil modeli uygulamalarında birim testi özellikle değerlidir: RAG pipeline'larının her aşaması — belge yükleyici, metin bölücü (text splitter), gömme motoru, vektör arama ve yanıt sentezi — ayrı birimler olarak test edilebilir. LangChain ve LlamaIndex gibi framework'ler bu izolasyonu kolaylaştıran mock nesneler ve test yardımcı sınıfları sunar. CI/CD pipeline'larına entegre edilen birim testleri, her kod değişikliğinde otomatik çalışarak regression'ları erken aşamada engeller. Test odaklı geliştirme (TDD) yaklaşımında birim testleri koddan önce yazılır; bu yöntem, AI özelliklerini geliştiren ekiplerin beklentileri netleştirmesine ve kod kalitesini artırmasına yardımcı olur. Kod kapsama oranı (test coverage), testlerin kaynak kodun ne kadarını çalıştırdığını gösterir; üretim kalitesindeki AI uygulamaları için yüzde seksen üzeri kapsama endüstri standardı olarak benimsenmektedir. Mutation testing gibi ileri teknikler ise testlerin kalitesini, yani gerçek hataları yakalama kapasitesini ölçer.

arrow_forward
analytics

Weights & Biases (W&B) (Weights & Biases (W&B))

Weights & Biases (W&B veya wandb), makine öğrenmesi projelerinde deney takibi, hiperparametre optimizasyonu ve model/veri sürümlemesi için kullanılan kapsamlı bir MLOps platformudur. Makine öğrenmesi mühendisleri onlarca farklı model denemesini, yüzlerce hiperparametre kombinasyonunu ve bunlara ait metrikleri yönetmekte güçlük çekmektedir; W&B bu karmaşıklığı merkezi ve görsel bir arayüzle çözer. 2018 yılında Lukas Biewald, Chris Van Pelt ve Scott Condron tarafından kurulan W&B, makine öğrenmesi deney takibinin fiili standardı hâline gelmiştir. OpenAI, NVIDIA, Toyota Research ve dünya genelindeki binlerce araştırma ve mühendislik ekibi aktif olarak W&B üzerinde çalışmaktadır. Platform dört temel modülden oluşur: Run Tracking, eğitim sırasında kayıp, doğruluk ve öğrenme hızı gibi metrikleri; hiperparametreleri ve sistem kaynaklarını otomatik olarak kaydeder. Sweeps modülü Grid Search, Random Search veya Bayesian Optimization algoritmasıyla hiperparametre aramayı otomatikleştirir; paralel çalışma desteğiyle yüzlerce konfigürasyon kısa sürede taranır. Artifacts modülü veri setleri ve model ağırlıklarını sürümlü biçimde depolar; hangi modelin hangi veriyle üretildiği tam olarak izlenebilir ve yeniden üretilebilirlik güvence altına alınır. Reports ise metin, grafik ve kod bloklarını bir araya getiren interaktif belgeler oluşturur; hem ekip içi değerlendirme hem de araştırma paylaşımı için idealdir. W&B entegrasyonu birkaç satır Python koduyla gerçekleştirilir: wandb.init() ile proje başlatılır, eğitim döngüsü içinde wandb.log() ile metrikler anlık kaydedilir. PyTorch, TensorFlow, Keras, JAX, HuggingFace Transformers ve Ultralytics YOLOv8 dahil pek çok popüler kütüphaneyle yerel entegrasyon sunulmaktadır. Bireysel kullanıcılara ücretsiz plan sunan W&B, SOC 2 Type II sertifikalı altyapısı ve GDPR uyumuyla kurumsal gereksinimleri karşılamaktadır. On-premise dağıtım seçeneği hassas veri politikalarına sahip kuruluşlara esneklik tanırken takım işbirliği araçları koordinasyonu kolaylaştırır. Araştırmacılar ve mühendisler için W&B, modern MLOps iş akışının vazgeçilmez bir parçasıdır.

arrow_forward
code_blocks

AutoML (Otomatik Makine Öğrenmesi)

AutoML (Automated Machine Learning — Otomatik Makine Öğrenmesi), makine öğrenmesi modellerinin geliştirilmesini — veri ön işleme, özellik mühendisliği, model seçimi, hiperparametre ayarı ve doğrulama gibi adımları — insan müdahalesini en aza indirerek otomatikleştiren bir teknoloji alanıdır. Geleneksel ML akışında uzman veri bilimcilerin haftalar harcadığı model arama ve optimizasyon sürecini AutoML sistemleri saatler içinde tamamlayabilir. AutoML'in temelinde hiperparametre optimizasyonu algoritmaları yatar: Bayesian optimizasyon, Random Search ve daha yakın dönemde popülerleşen Neural Architecture Search (NAS). NAS, milyonlarca olası ağ yapısı arasında en iyi mimariyi otomatik olarak keşfeder; Google'ın NASNet ve MnasNet modelleri bu yöntemle tasarlanmıştır. Meta-learning yaklaşımı ise önceki görevlerden elde edilen deneyimi kullanarak yeni veri setleri için başlangıç noktasını hızla belirler. Piyasadaki başlıca AutoML çerçeveleri şunlardır: Google Cloud AutoML (kodsuz, sürükle-bırak arayüzü), Auto-sklearn (scikit-learn pipeline otomasyonu), H2O AutoML (kurumsal açık kaynak), Apple CreateML (iOS/macOS entegrasyonlu), Amazon SageMaker Autopilot ve Microsoft Azure AutoML. Her biri farklı dengelerde kolaylık, esneklik ve doğruluk sunar. AutoML'in en belirgin katkısı veri bilimine erişimin demokratikleşmesidir: makine öğrenmesi uzmanlığı olmayan analistler ve alan uzmanları bile kendi modellerini eğitip üretim ortamına alabilmektedir. Öte yandan AutoML büyük hesaplama bütçesi gerektirebilir; NAS gibi yöntemler yüzlerce GPU-saati tüketebilir. Otomatik sürecin ürettiği modeller bazen yorumlanması güç karmaşık pipeline'lar içerir. Bu nedenle AutoML, uzman veri bilimcilerin yerini almaktan çok onları rutin optimizasyon görevlerinden kurtarıp katma değer yaratan işlere odaklamalarını hedefler. Türkiye'de özellikle finans, sağlık ve e-ticaret alanlarında çalışan şirketler AutoML çözümlerini benimsemektedir. Türkçe dokümanlarla çalışan NLP pipeline'larında AutoML tabanlı metin sınıflandırma sistemleri hızla yaygınlaşmaktadır. FLAML ve TPOT gibi hafif açık kaynak araçlar, sınırlı kaynaklarla da kaliteli model araması yapılmasına olanak tanıdığından küçük ve orta ölçekli ekipler için cazip seçenekler sunmaktadır.

arrow_forward
deployed_code

CI/CD AI Nedir? Yapay Zeka Destekli Yazılım Teslimatı (CI/CD Yapay Zeka Entegrasyonu)

CI/CD AI, yazılım geliştirme süreçlerinde sürekli entegrasyon (Continuous Integration) ve sürekli teslimat/dağıtım (Continuous Delivery/Deployment) boru hatlarına yapay zeka ve makine öğrenmesi tekniklerinin entegre edilmesiyle ortaya çıkan bir yaklaşımdır. Geleneksel CI/CD boru hatları statik kural setlerine ve önceden yazılmış test betiklerine dayanırken AI destekli yapılar bu süreçlere uyarlanabilir zeka katmanı ekler. Test optimizasyonu bu entegrasyonun en somut uygulamasıdır. Makine öğrenmesi modelleri, geçmiş hata verilerini analiz ederek hangi testlerin belirli bir kod değişikliğiyle hata verme olasılığının yüksek olduğunu tahmin eder. Bu sayede tüm test paketini çalıştırmak yerine yüksek riskli testler önce koşulur; bu yaklaşım test süresini önemli ölçüde kısaltır. Kod kalitesi ve güvenlik analizinde de yapay zeka devreye girer. Statik analiz araçları giderek daha fazla ML destekli örüntü tanıma kullanmakta; sıradan kural tabanlı linter'ların gözden kaçırdığı mantık hatalarını, güvenlik açıklarını ve performans darboğazlarını tespit etmektedir. GitHub Copilot kod incelemesi ve Amazon CodeGuru bunun örnekleridir. Dağıtım güvenliği açısından AI destekli anomali tespiti kritik bir rol üstlenir. Dağıtım sonrasında uygulama metrikleri gerçek zamanlı izlenir; anormal davranış algılandığında sistem otomatik geri alma (rollback) tetikleyebilir veya kanarya dağıtımını durdurabilir. Bu, ortalama kurtarma süresini (MTTR) önemli ölçüde azaltır. Altyapı maliyeti optimizasyonu da bu alanın önemli bir bileşenidir. ML modelleri kaynak kullanımını tahmin ederek gereksiz bulut harcamalarını kısıtlar ve yük dengeleme kararlarını optimize eder. Jenkins, GitHub Actions, GitLab CI ve CircleCI gibi platformlar AI eklentileri ve yerel makine öğrenmesi özellikleri aracılığıyla bu yetenekleri giderek daha erişilebilir kılmaktadır. Ekipler bu dönüşüme adım atarken mevcut boru hattı yapısını koruyarak küçük AI katmanları eklemeye başlayabilir. Launchable ve Trunk gibi araçlar mevcut test altyapısıyla entegre olurken sıfırdan tasarlanan sistemlerde MLOps pratikleriyle CI/CD süreçlerini birleştiren makine öğrenmesi operasyonları boru hatları oluşturmak giderek yaygınlaşmaktadır.

arrow_forward
policy

Data Governance (Veri Yönetişimi)

Data governance (veri yönetişimi), bir organizasyonun veri varlıklarını nasıl toplayacağını, saklayacağını, kullanacağını, paylaşacağını ve yöneteceğini belirleyen resmi politikalar, roller, standartlar ve süreçlerin bütünüdür. Üç temel soruyu yanıtlar: veri üzerinde kim otoriteye sahiptir, verinin karşılaması gereken standartlar nelerdir ve bu standartlara uyum nasıl sağlanır. Yapay zeka ve makine öğrenmesi ekosisteminde veri yönetişimi bürokratik bir formalite değil; bir modelin güvenilir, denetlenebilir ve sorumlu biçimde dağıtılabilir olmasını belirleyen yapısal iskelet olmaktadır. Veri yönetişimi, veri yönetimi (data management) kavramıyla sıklıkla karıştırılır. Veri yönetimi günlük operasyonel katmanı oluşturur: veri hatları, depolama sistemleri, ETL iş akışları ve veritabanları. Veri yönetişimi ise bunların üzerinde konumlanan stratejik katmandır; "neden" ve "neyi" tanımlar. Yönetişim kuralları koyar, yönetim bu kuralları uygular. Gelişmiş veri yönetimine sahip ama yönetişimden yoksun bir organizasyon hızlı ve verimli bir kaos üretir. Yapay zeka sistemleri için veri yönetişimi altı temel bileşen üzerinde çalışır. Veri kalitesi, eğitim verilerinin doğru, eksiksiz, tutarlı ve temsil edici olmasını güvence altına alır; makine öğrenmesinde önyargılı ya da eksik veri yalnızca kötü model değil, ayrımcı model üretir. Veri kataloğu, tüm veri varlıklarının meta veri ve kullanım bağlamıyla aranabildiği envanter sistemidir. Veri kökenselliği (data lineage), verinin nereden geldiğini ve nasıl dönüştürüldüğünü izlenebilir biçimde kayıt altına alır; bu, yapay zeka açıklanabilirliğinin teknik temelidir. Veri yöneticiliği (data stewardship), politikaların operasyonel düzeyde uygulanmasını sağlayan insan katmanıdır. Erişim kontrolü belirli veri kümelerine kimin erişebileceğini tanımlar; hassas eğitim verilerinin yetkisiz kullanımını önler. Düzenleyici açıdan bakıldığında AB Yapay Zeka Yasası'nın 10. Maddesi, yüksek riskli yapay zeka sistemleri için belgelenmiş veri yönetişimini yasal zorunluluk olarak tanımlamaktadır. GDPR'ın veri minimizasyonu, amaç sınırlaması ve hesap verebilirlik ilkeleri yönetişim gereksinimlerine doğrudan karşılık gelir. Ağustos 2025'te yürürlüğe giren GPAI yükümlülükleri, büyük temel model sağlayıcılarını eğitim verisi şeffaflığı konusunda yeni standartlara tabi kılmaktadır. Endüstri araştırmalarına göre kuruluşların %73'ü veri kalitesini yapay zeka projelerindeki en büyük zorluk olarak tanımlamaktadır; bu oran, etkin bir yönetişim çerçevesinin stratejik önemini açıkça ortaya koymaktadır.

arrow_forward
code_blocks

Data Lineage Nedir? Veri Kökeni ve Takip Yolu (Veri Kökeni (Data Lineage))

Veri soy agaci (data lineage), bir veri varliginin hangi kaynaklardan turetildigini, hangi donusum adimlarindan gectigi ve nihai olarak nerede kullanildigini belgeleyen tam izlenebilirlik cercevesidir. Bir veri boru hattinda yuzlerce tablo, binlerce sutun ve karmasik JOIN, GROUP BY, UNION operasyonlari olabilir; soy agaci bu karmasikligi kayit altina alarak gecmiste ve gelecekte yapilan degisikliklerin etkisini anlamaya olanak tanir. Veri soy agacinin kullanim amaclarinin basinda hata koken analizi gelir. Bir raporun yanlis rakam gosterdigi kesfedildiginde ekip, hatalı deger hangi kaynak tablodan, hangi donusum adiminda girmis sorusunu saniyeler icerisinde cevaplayabilir. Soy agaci olmadan bu arastirma saatler hatta gunler surebilir. Ikinci kritik kullanim alani uyumluluktur: GDPR kapsaminda kisisel verinin nerede tutuldugu ve nasil islendiginin belgelenmesi zorunludur; SOC 2 ve HIPAA denetimleri de veri akislarinin izlenebilirligini gerektirir. Teknik olarak soy agaci iki duzeyden olusabilir. Tablo duzeyinde soy agaci, hangi tablonun hangi kaynak tablolardan beslendigini ve hangi islem tarafindan olusturuldugunu gosterir. Sutun duzeyinde soy agaci cok daha ince taneli bir goruntu sunar: belirli bir raporun bir sutununun hangi kaynak alanlardan tureddigi, hangi aggregasyon veya donusumden gectigi gorulebilir. Sutun duzeyinde soy agaci ozellekle buyuk veri ortamlarinda etki analizi (impact analysis) icin vazgecilmezdir. Populer araçlar arasinda dbt (data build tool), yazilan SQL modellerini ayrıştirarak otomatik soy agaci grafikleri uretir. Apache Atlas, Collibra ve Alation gibi veri katalogu cozumleri hem metadata yonetimini hem de soy agacini entegre sunar. Bulut saglayicilari (AWS Glue, Google Dataplex, Azure Purview) de yonetilen soy agaci yetenekleri sunmaktadir. **Sik Sorulan Sorular** **Veri soy agaci ile veri katalogu arasindaki fark nedir?** Veri katalogu veri varliklarinin ne olduğunu, nerede bulundugunu ve ne anlam tasidigini belgeler. Veri soy agaci ise bu varlikların nasil hareket ettigini ve donustugunu izler. Ikisi birbirini tamamlar. **Soy agaci manuel mi yoksa otomatik mi olusturulur?** Modern araçlar (dbt, Spark, JDBC temelli ETL) SQL veya kodu ayrıştirarak otomatik soy agaci cikarir. Karmasik, kod tabanli donusumler bazen manuel belgeleme gerektirir. **Kucuk veri ekipleri icin soy agaci gerekli midir?** Kullanici sayisi azsa dbt gibi hafif bir arac yeterli olabilir; acik kaynak ve ucretsizdir. Uyumluluk gereksinimleri yoksa minimal but tatmin edici bir CSV-tablosuna el ile kayit etmek bile baslangicta yeterlidir. **Soy agaci gercek zamanli mi yoksa batch mi guncellenir?** Cogu cozum pipeline yurutulunde soy agacini gunceller (batch). Gercek zamanli izleme daha nadir ve daha pahalıdır; yalnizca kritik uretim is akislari icin gerekir.

arrow_forward
code_blocks

Data Pipeline (Veri Hattı)

Veri Hattı (Data Pipeline), ham verinin kaynaktan hedefe taşınırken dönüştürüldüğü, işlendiği ve temizlendiği otomatik süreçler zinciridir. Makine öğrenimi ve MLOps bağlamında veri hattı, modelin eğitim veya çıkarım için ihtiyaç duyduğu özellik vektörlerini üretmek amacıyla birden fazla veri kaynağını birleştiren, standardize eden ve dağıtan sistematik altyapıdır. Geleneksel veri mühendisliğinde ETL (Extract-Transform-Load) mimarisi standarttır: farklı kaynaklardan veri çekilir (extract), iş kurallarına göre dönüştürülür (transform) ve hedef depolara yüklenir (load). Modern yapay zeka uygulamalarında bu mimari ELT (önce yükle sonra dönüştür) veya streaming (akış) modeline evrilmektedir: büyük veri hacimleri önce ham olarak veri gölüne (data lake) aktarılır, ardından talep bazlı dönüşüm uygulanır. Makine öğrenimi veri hattının kritik bileşenleri şunlardır: **Veri alımı (ingestion)** farklı kaynaklardan (veritabanı, API, dosya sistemi, Kafka) veriyi toplar. **Veri doğrulama (validation)** şema uyumluluğunu, eksik değerleri ve istatistiksel anomalileri tespit eder — Great Expectations kütüphanesi bu aşamada yaygındır. **Özellik mühendisliği (feature engineering)** ham veriyi modelin anlayacağı sayısal özelliklere dönüştürür. **Özellik deposu (feature store)** üretilen özellikleri hem eğitim hem çıkarım için tutarlı biçimde saklar. Veri hattının üretim ortamındaki en büyük zorluğu tutarlılık (consistency) ve çoğaltılabilirlik (reproducibility) gerektirmesidir. Eğitim sırasında kullanılan ön işleme adımları, çıkarım (inference) sırasında birebir aynı şekilde uygulanmazsa "eğitim-servis çarpışması" (training-serving skew) ortaya çıkar: model geliştirme ortamında iyi çalışır ama üretimde başarısız olur. Apache Airflow, Prefect ve Dagster gibi iş akışı orkestratörleri karmaşık veri hattı bağımlılıklarını yönetir; her adımı DAG (Yönlü Asiklik Graf) olarak tanımlar ve başarısız adımları otomatik yeniden dener. Spark ve Flink büyük ölçekli paralel veri işleme için, Kafka gerçek zamanlı akış için kullanılır. MLflow ve DVC ile birlikte bu araçlar modern MLOps altyapısının temelini oluşturur.

arrow_forward
code_blocks

Design Patterns (Tasarım Kalıpları)

Tasarım kalıpları (design patterns), yazılım geliştirmede tekrar eden tasarım sorunlarına karşı deneyimle şekillenmiş, dile bağımsız ve yeniden kullanılabilir çözüm şablonlarıdır. Belirli bir kodun kopyalanıp yapıştırılmasını değil, bir problemi çözmek için izlenebilecek genel bir yaklaşım biçimini tanımlarlar. 1994 yılında Erich Gamma, Richard Helm, Ralph Johnson ve John Vlissides'ten oluşan "Gang of Four" (GoF — Dörtlü Çete) tarafından kaleme alınan "Design Patterns: Elements of Reusable Object-Oriented Software" adlı kitapla bu kavram yazılım mühendisliğinin temel referanslarından biri haline gelmiştir. GoF kitabı, nesne yönelimli programlamada sık karşılaşılan 23 kalıbı tanımlar ve bu kalıpları üç ana kategoride ele alır. Yaratımsal kalıplar (Creational Patterns), nesnelerin nasıl oluşturulacağına ilişkin esneklik sağlar. Singleton kalıbı bir sınıftan yalnızca tek bir nesne üretilmesini garanti ederken, Factory (Fabrika) kalıbı hangi somut nesnenin oluşturulacağını istemciden soyutlar. Yapısal kalıplar (Structural Patterns), sınıflar ve nesneler arasındaki ilişkileri düzenler; Decorator, var olan bir nesneye kaynak kodu değiştirmeden yeni sorumluluklar ekler; Repository ise veri erişim mantığını iş mantığından ayıran bir soyutlama katmanı kurar. Davranışsal kalıplar (Behavioral Patterns), nesneler arası iletişim ve sorumluluk dağılımını yönetir; Observer (Gözlemci) kalıbı bir nesnenin durumu değiştiğinde bağlı tüm abonelerin bilgilendirilmesini sağlarken, Strategy kalıbı algoritma seçiminin çalışma zamanında yapılmasına olanak tanır. Makine öğrenmesi ve yapay zeka sistemlerinde tasarım kalıpları kritik bir altyapı rolü üstlenir. Strategy kalıbı, aynı arayüz üzerinden çalışma zamanında farklı model algoritmalarının (RandomForest, XGBoost, derin öğrenme) seçilmesine olanak tanır; AutoML sistemleri bu kalıba yaslanır. Observer kalıbı, Keras ve PyTorch Lightning gibi kütüphanelerdeki callback sistemlerinin temelini oluşturur: eğitim doğruluğu belirli bir eşiğin altına düştüğünde otomatik erken durdurma (early stopping) tetiklenir, metrikler MLflow ve Weights & Biases gibi araçlara aktarılır. Factory kalıbı, farklı veri kaynaklarından (dosya, veritabanı, bulut depolama) veri yükleyen nesneleri tek bir arayüzden üretir. Repository kalıbı ise Feast ve Tecton gibi Feature Store mimarilerinde depolama katmanını (PostgreSQL, S3, Redis) soyutlar. 2025-2026 itibarıyla klasik GoF kalıpları, ajan tabanlı yapay zeka (agentic AI) mimarilerinde yeni biçimler kazanmıştır. Andrew Ng'in öne çıkardığı dört ajan tasarım örüntüsü — Reflection (Yansıma), Tool Use (Araç Kullanımı), Planning (Planlama) ve Multi-Agent Collaboration (Çoklu Ajan İşbirliği) — sırasıyla Observer+Strategy, Facade+Command, Chain of Responsibility ve Mediator kalıplarının dönüşümüdür. HumanEval kıyaslamasında Reflection örüntüsünün kod doğruluğunu %80'den %91'e çıkardığı ölçülmüştür. Mikroservis mimarilerinde ise Circuit Breaker (Devre Kesici), API Gateway ve CQRS tasarım kalıpları geleneğini bulut-yerel sistemlere taşımaktadır.

arrow_forward
bug_report

Kod Kokusu (Code Smell) (Kod Kokusu)

Kod kokusu (code smell) kaynak kodunda var olan ve genellikle daha derin bir tasarım ya da mimari sorununun işaretçisi olan yüzeysel göstergelerdir. Bu kavram yazılım mühendisi Martin Fowler ve Kent Beck tarafından 1999 yılında yayımlanan Refactoring: Improving the Design of Existing Code adlı kitapta sistematik biçimde ele alınmıştır. Kod kokuları doğrudan bir hata değildir; kod çalışmaya devam eder. Ancak bu işaretler kodun sürdürülebilirliğini okunabilirliğini ve genişletilebilirliğini zaman içinde aşındıran yapısal zayıflıklara işaret eder ve zamanında giderilmezse gerçek hatalara zemin hazırlar. En yaygın kod kokusu türleri arasında onlarca satırdan oluşan uzun metotlar aşırı yük bindirilmiş God Class sınıflar tekrarlı kod blokları bir metodun kendi sınıfından daha çok başka bir sınıfın verilerine erişmesi (Feature Envy) ve ilkel tiplerle nesne mantığı kurmaya çalışmak (Primitive Obsession) sayılabilir. Fazla sayıda yorum bazen kodun kendini yeterince ifade edemediğinin işareti olarak değerlendirilir. Yapay zeka ve makine öğrenmesi projelerinde kod kokuları farklı biçimlerde ortaya çıkar: büyük ve düzensiz Jupyter not defteri hücreleri tekrarlı veri ön işleme blokları sabit kodlanmış hiperparametreler ve test edilemeyen model pipeline'ları sektöre özgü örneklerdir. Modern statik analiz araçları olan SonarQube pylint ve DeepSource bu kokuları otomatik tespit eder; GitHub Copilot ve Amazon CodeWhisperer gibi yapay zeka destekli kod inceleme sistemleri refactoring önerileri sunarak ekiplerin teknik borcu proaktif biçimde yönetmesine katkı sağlar. Refactoring kodun dışarıdan gözlemlenebilir davranışını değiştirmeksizin iç yapısını iyileştirme sürecidir. Yeterli test kapsamı olmadan yapılması risk taşır; önce birim testlerini güçlendirmek ardından refactoring adımlarını uygulamak en güvenli yaklaşımdır. CI/CD pipeline'larına entegre edilen statik analiz araçları kod kokularının production ortamına geçmesini önleyen etkili bir kalite kapısı oluşturur ve ekiplerin teknik borcunu kontrol altında tutmalarına yardımcı olur.

arrow_forward
code_blocks

Kubeflow (Kubeflow)

Kubeflow, Google'ın Kubernetes altyapısı üzerine inşa ettiği açık kaynak makine öğrenimi platform paketidir. 2018'de Google'ın kendi iç ML iş akışlarını kamuya açması sonucu ortaya çıkan Kubeflow, veri bilimcilerin ve ML mühendislerinin model deneme ve geliştirme süreçlerini Kubernetes orkestrasyon katmanında standartlaştırmasını ve üretime taşımasını hedefler. Kubeflow'un beş temel bileşeni vardır. Kubeflow Pipelines (KFP), Python SDK ile tanımlanan DAG (Yönlü Asiklik Çizge) tabanlı ML iş akışlarıdır; her adım izole Docker container içinde çalışır ve deney takibi, artifact yönetimi ile görsel pipeline grafiği sunar. KServe (eski adıyla KFServing), üretim ortamında model sunma platformudur; canary deployment, A/B testi ve otomatik ölçeklendirme (autoscaling) destekler; TensorFlow Serving, TorchServe ve NVIDIA Triton ile entegre çalışır. Katib, Kubernetes üzerinde hiperparametre optimizasyonu (HPO) ve sinir ağı mimarisi araştırması (NAS) gerçekleştirir; Bayesian optimizasyon ve Hyperband algoritmaları desteklenir. Training Operators bileşeni, PyTorchJob ve TFJob aracılığıyla dağıtık model eğitimini koordine eder; çok node'lu GPU kümeleri üzerinde veri paralelliğini yönetir. Kubeflow Notebooks ise Jupyter Notebook sunucularını Kubernetes üzerinde başlatarak GPU/CPU kaynak yapılandırması sunar. MLOps olgunluk seviyesi yüksek ve Kubernetes altyapısı olan kuruluşlar için güçlü bir seçenek olan Kubeflow, öğrenme eğrisi yoğun bir araçtır: Kubernetes bilgisi zorunludur ve kurulum karmaşıklığı MLflow veya ZenML'e kıyasla daha fazla zaman ve uzmanlık gerektirir. Vertex AI Pipelines (Google Cloud), SageMaker Pipelines (AWS) ve Azure ML gibi yönetilen alternatifler altyapı yükünü azaltır; ancak belirli bir bulut ekosistemiyle bağımlılık yaratır. Türkiye'de cloud-agnostic ve on-premises MLOps altyapısı kurmak isteyen büyük şirketler ile araştırma kurumları Kubeflow'u değerlendirmektedir. Kubeflow'u MLflow ile birlikte kullanmak yaygın ve etkili bir pratiktir: MLflow deney takibi ve model registry için, Kubeflow Pipelines ise iş akışı orkestrasyon ve dağıtık eğitim için tercih edilir. Bu kombinasyon, her iki platformun güçlü yönlerini bir arada değerlendirmeyi, aynı zamanda açık ve taşınabilir bir MLOps altyapısı kurmayı mümkün kılar.

arrow_forward
code_blocks

LangSmith (LangSmith)

LangSmith, LangChain ekosisteminin parçası olan bir LLM gözlemlenebilirlik (observability), değerlendirme ve izleme platformudur. Karmaşık yapay zeka uygulamalarını — RAG pipeline'ları, ajan zincirleri ve çok adımlı LLM iş akışları — geliştirme, hata ayıklama ve üretimde izleme süreçlerini büyük ölçüde kolaylaştırır. LangSmith'in temel özelliği izleme (tracing) altyapısıdır: her LLM çağrısı, araç kullanımı, vektör veritabanı sorgusu ve ajan adımı ayrıntılı bir şekilde kaydedilir. Geliştiriciler hangi prompt'un hangi çıktıyı ürettiğini, gecikme ve maliyet dağılımını ve başarısız adımların tam bağlamını görselleştirebilir. Bu görünürlük, özellikle karmaşık çok-adımlı sistemlerde hata ayıklamayı dramatik biçimde hızlandırır. Değerlendirme (evaluation) katmanında LangSmith, LLM çıktılarını otomatik veya insan etiketiyle değerlendirmeyi destekler. Veri setleri oluşturulabilir, testler çalıştırılabilir ve model/prompt değişikliklerinin performansa etkisi ölçülebilir. Bu özellik, model versiyonlama ve regresyon testi açısından kritik önem taşır. Platform, hem bulut tabanlı hem de kendi altyapısında barındırılabilir (self-hosted) seçenekler sunmaktadır. LangChain olmadan da kullanılabilir: Anthropic, OpenAI veya Hugging Face modellerini kullanan herhangi bir Python uygulaması, birkaç satır kodla LangSmith'e bağlanabilir. OpenTelemetry protokol uyumluluğu, mevcut DevOps gözlemlenebilirlik altyapısıyla entegrasyonu kolaylaştırmaktadır. Türkiye'de kurumsal yapay zeka projelerinin olgunlaşmasıyla birlikte MLOps ve LLMOps altyapısına olan ilgi artmaktadır. LangSmith bu bağlamda üretim LLM sistemlerinin sorumluluğunu ve güvenilirliğini artırmak isteyen geliştirici ekipler için önde gelen araçlardan biri haline gelmiştir. LangSmith ayrıca takım bazlı işbirliği için proje yönetimi, sürüm kontrolü ve erişim izni özellikleri sunmaktadır. Büyük kuruluşlar için SOC 2 uyumlu bulut seçeneği veya tam özellikli self-hosted kurulum imkânı mevcuttur. LLMOps alanında Weights & Biases Weave, Arize AI Phoenix ve Langfuse gibi alternatifler bulunmakla birlikte LangSmith, LangChain ekosistemiyle derin entegrasyonu ve geniş topluluk desteğiyle öne çıkmaktadır. Üretim LLM sistemlerinde izlenebilirlik ve değerlendirme, artık opsiyonel değil zorunlu bir mühendislik pratiği haline gelmektedir.

arrow_forward
code_blocks

LLMOps (LLMOps (Büyük Dil Modeli Operasyonları))

LLMOps (Large Language Model Operations — Büyük Dil Modeli Operasyonları), büyük dil modellerinin geliştirme aşamasından üretim ortamına taşınması, izlenmesi ve sürdürülmesi için gereken süreçleri, araçları ve en iyi uygulamaları kapsayan operasyonel çerçevedir. Klasik MLOps'un LLM'lere özgü zorluklara yanıt veren genişletilmiş bir versiyonudur. LLMOps'un kritik bileşenleri şunlardır: prompt yönetimi ve versiyonlama, model değerlendirme pipeline'ları, ince ayar (fine-tuning) iş akışları, üretim ortamında maliyet ve gecikme izlemesi. Token başına maliyet, p95 gecikme süresi, halüsinasyon oranı ve bağlam penceresi kullanımı temel metriklerdir. CI/CD pipeline'larına bağlı otomatik değerlendirme, her prompt veya model değişikliğini kalite kapısından geçirir. Değerlendirme katmanında LLM-as-Judge yaklaşımı öne çıkar: bir model, başka bir modelin çıktısını doğruluk, bağlam tutarlılığı ve talimat uyumu açısından puanlar. Bu yöntem insan değerlendirmesinin ölçeklenemeyen kısmını otomatikleştirir. Kırmızı takım (red team) değerlendirmeleri ise adversaryal prompt tespiti, prompt enjeksiyonu ve jailbreak denemelerini sistematik biçimde test eder; güvenli üretim dağıtımının zorunlu bir adımıdır. Dağıtım katmanında canary release ve mavi-yeşil (blue-green) stratejileri LLM güncellemelerinde regresyon riskini azaltır. Semantik önbellek (semantic cache), anlam bakımından yakın sorguları yeniden hesaplamak yerine önceki yanıtlardan karşılar; bu yaklaşım hem token maliyetini hem de gecikmeyi belirgin biçimde düşürür. Prompt önbelleği ise aynı sistem promptunu defalarca gönderme yerine önbelleğe alarak maliyet %30-90 oranında azaltır. Araç ekosisteminde LangSmith (LangChain'in izleme platformu), Langfuse (açık kaynak LLM gözlemlenebilirlik aracı), Helicone ve Weights & Biases (W&B) öne çıkar. OpenLLMetry, OpenTelemetry uyumlu LLM izleme standardı olarak gelişmektedir. Bu araçlar istek bazında trace, maliyet ve kalite verilerini merkezi bir noktada toplar. Türkiye'de kurumsal LLM projeleri büyüdükçe LLMOps ihtiyacı artmaktadır. Müşteri hizmetleri botlarından hukuki belge özetlemeye kadar LLM tabanlı uygulamaları güvenilir ve ölçeklenebilir biçimde işletmek için model A/B testi, kırmızı takım değerlendirmeleri ve sürekli izleme giderek zorunlu hale gelmektedir. KVKK uyumu gerektiğinde self-hosted Langfuse gibi araçlar veri egemenliğini korurken tam gözlemlenebilirlik sunar.

arrow_forward
code_blocks

Model Pruning Nedir? Sinir Ağlarında Budama (Model Budama)

Model budama (model pruning), milyarlarca parametreye sahip büyük sinir ağlarında performansı en az etkileyen ağırlıkları veya yapısal bileşenleri belirleyip kaldıran bir model optimizasyon yöntemidir. Temel fikir basittir: iyi eğitilmiş bir ağda parametrelerin önemli bir bölümü tahmin kalitesine minimum katkı sağlar ve bu parametreler olmadan model neredeyse aynı doğrulukla çalışmaya devam edebilir. **Budama Türleri** Yapısal budama (structured pruning), nöron, filtre veya katman gibi tüm yapısal birimleri kaldırır. Bu yaklaşım, standart CPU/GPU donanımında doğrudan bellek ve hız kazanımı sağlar; karmaşık özel donanım gerekmez. Buna karşın yapısal olmayan budama (unstructured pruning), bireysel ağırlıkları sıfırlayarak seyrek (sparse) bir matris üretir. Sıkıştırma oranı çok yüksek olabilir ancak bu seyrekliği işlemek için özel seyrek matris donanımı ya da yazılım desteği gerekir. **Büyüklük Tabanlı Budama** En yaygın yöntem büyüklük tabanlı (magnitude-based) budamadır: mutlak değerleri eşik değerin altındaki ağırlıklar sıfırlanır. Uygulaması kolaydır ve pek çok durumda yeterli sonuç verir. Daha gelişmiş gradyan tabanlı yaklaşımlar ise ağırlığın kayıp fonksiyonuna katkısını (saliency) hesaplayarak gerçekten önemsiz olanları seçer. **Yinelemeli Budama ve Lottery Ticket Hipotezi** Tek adımda agresif budama doğruluğu düşürebilir. Bu nedenle pratikte "budama, ince ayar (fine-tune) ve tekrar budama" döngüsü tercih edilir. 2019'da Frankle ve Carlin tarafından öne sürülen Lottery Ticket Hipotezi, büyük sinir ağlarında küçük ama etkili alt ağlar (winning tickets) gizlendiğini; bu alt ağların sıfırdan aynı doğrulukla eğitilebildiğini ileri sürer. Bu hipotez, budamanın neden bu kadar iyi çalıştığını teorik olarak açıklar. **Pratik Kullanım Alanları** Model budama özellikle kenar cihazlarda (akıllı telefon, IoT sensörü, gömülü sistem) büyük modelleri çalıştırmak için kritik önem taşır. GPT, LLaMA gibi büyük dil modellerini mobil uygulamalarda kullanılabilir hale getiren yöntemlerin başında gelir. Niceleme (quantization) ve bilgi damıtma (knowledge distillation) ile birlikte kullanıldığında model boyutu ve çıkarım gecikme süresi dramatik biçimde azaltılabilir.

arrow_forward
👁️

Observability (AI) Nedir? (AI Gözlemlenebilirliği)

AI Observability (Yapay Zeka Gözlemlenebilirliği), üretim ortamında çalışan makine öğrenmesi modelleri ve büyük dil modellerinin (LLM) içsel durumunu dışsal çıktılarından anlama pratiğidir. Geleneksel yazılım gözlemlenebilirliğinin üç sütununu — loglar, metrikler ve izler (traces) — yapay zeka sistemlerine uygular; buna ek olarak prompt kalitesi, yanıt doğruluğu, token maliyeti ve halüsinasyon oranı gibi AI'ya özgü metrikleri de kapsar. Üretim ML modellerinde iki kritik sorun gözlemlenebilirliği zorunlu kılar. Veri drifti, gelen verinin dağılımının eğitim verisinden zamanla uzaklaşması durumudur; bu değişimi tespit etmek için özellik dağılımı istatistikleri (PSI, KS testi) sürekli izlenir. Model drifti ise modelin tahmin doğruluğunun veya davranışının zamanla bozulmasıdır; gelir kaybı veya operasyonel sorunlara dönüşmeden önce tespit edilmesi kritiktir. LLM Observability, geleneksel MLOps gözlemlenebilirliğini aşan yeni bir alt alan oluşturmuştur. Prompt mühendisliği hatalarını yakalamak, ajan iş akışlarındaki zincir adımlarını izlemek (tracing), yanıt kalitesini değerlendirmek (LLM-as-a-judge) ve maliyet optimizasyonu için token kullanımını takip etmek bu alanın temel görevleridir. Arize AI, LangSmith, Langfuse, Weights & Biases ve MLflow Tracking bu alan için kullanılan öncü araçlardır. Türkiye'de bankacılık ve e-ticaret sektörlerinde üretim ML sistemleri kullanan şirketler, model davranışı izlemesini Sanayi 4.0 ve veri kalitesi süreçlerine entegre etmektedir. KVKK kapsamında hassas veri işleyen LLM sistemlerin gözlemlenmesi, hem veri gizliliği uyumu hem de hizmet kalitesi açısından kritik önem taşımaktadır. Maliyet yönetimi, LLM Observability'nin önemli bir boyutunu oluşturur. Her API çağrısının token maliyeti, yanıt süresi (latency) ve başarı oranı takip edilerek model seçimi ve prompt optimizasyonu kararları veri odaklı biçimde alınabilmektedir. Otomatik uyarı (alerting) sistemleri, performans metrikleri önceden belirlenen eşikleri geçtiğinde mühendis ekiplerini anında haberdar ederek olası operasyonel kayıpları en aza indirir.

arrow_forward
science

Shadow Mode (Gölge Modu)

Shadow mode (gölge modu), makine öğrenmesi ve yapay zeka sistemlerinde yeni bir modelin, mevcut üretim modeliyle eş zamanlı olarak çalıştırıldığı ancak kullanıcılara herhangi bir yanıt sunulmadığı bir dağıtım stratejisidir. Bu yaklaşımda, gerçek üretim trafiği her iki modele de iletilir; ancak yalnızca mevcut üretim modelinin yanıtları kullanıcılara gösterilir. Gölge modelin çıktıları kaydedilir ve analiz edilir, ancak asla son kullanıcıya sunulmaz. Shadow mode, özellikle yüksek riskli uygulamalarda yeni yapay zeka modellerini güvenli biçimde test etmenin en etkili yöntemlerinden biridir. Finansal hizmetler, sağlık sistemleri ve dolandırıcılık tespiti gibi kritik alanlarda, kullanıcıları doğrulanmamış model tahminlerine maruz bırakmak ciddi sonuçlar doğurabilir. Shadow mode bu riski tamamen ortadan kaldırır. Bu stratejinin temel avantajı, gerçek üretim verisi ve trafik desenleriyle test imkânı sunmasıdır. Çevrimdışı değerlendirmeler veya geçmiş verilerle yapılan testler, prodüksiyon ortamının karmaşıklığını tam olarak yansıtamaz. Shadow mode, yeni modelin gerçek dünya koşullarında nasıl performans gösterdiğini, gecikme sürelerini, uç durum senaryolarını ve altyapı gereksinimlerini doğrudan gözlemleme olanağı sağlar. Shadow mode, canary deployment ve A/B testinden belirgin biçimde farklıdır. Canary dağıtımında gerçek kullanıcıların küçük bir yüzdesi yeni modelin çıktılarını görürken, shadow mode'da hiçbir kullanıcı etkilenmez. A/B testinde ise kullanıcı etkileşim metrikleri (tıklama, dönüşüm) ölçülürken, shadow mode bu tür kullanıcı tercih sinyallerini toplamak için uygun değildir. MLOps süreçlerinde shadow mode genellikle bir model doğrulama aşaması olarak kullanılır. Model tatmin edici sonuçlar üretiyorsa, canary veya tam dağıtıma geçiş yapılır. Amazon SageMaker, Seldon Core ve BentoML gibi MLOps platformları shadow mode'u yerel olarak destekler. Bu yaklaşımın dezavantajları arasında iki modeli eş zamanlı çalıştırmanın gerektirdiği ek altyapı maliyeti ve operasyonel karmaşıklık sayılabilir. Ayrıca kullanıcı etkileşim sinyalleri elde edilemediğinden, model kalitesi doğrudan kullanıcı tercihiyle değil teknik performans metrikleriyle değerlendirilmek zorunda kalınır.

arrow_forward
code_blocks

Supply Chain Attack (Tedarik Zinciri Saldırısı)

Tedarik Zinciri Saldırısı (Supply Chain Attack), saldırganların doğrudan hedef sisteme saldırmak yerine güvenilen bir üçüncü taraf yazılım bileşenini, kütüphaneyi, paketi veya hizmet sağlayıcısını ele geçirerek hedeflere dolaylı yoldan ulaştığı bir siber saldırı vektörüdür. "Upstream'i zehirle, downstream'i yakala" prensibiyle çalışır: hedef organizasyon kendi güvenlik önlemlerini uygulasa bile, güvendiği bir bileşen zaten ele geçirilmişse korumasız kalır. Yazılım tedarik zinciri bağlamında 2020'deki SolarWinds Sunburst saldırısı, 18.000'den fazla kurumun güncelleme mekanizması aracılığıyla arka kapı (backdoor) yerleştirilmiş yazılım aldığını göstererek türün en büyük vakası hâline geldi. 2024'te XZ Utils kütüphanesine yapılan saldırı, açık kaynak bileşenlerin uzun soluklu sosyal mühendislik yoluyla nasıl tehlikeye atılabileceğini ortaya koydu. Yapay zeka ekosistemi bu saldırılar için yeni ve kritik bir yüzey oluşturmuştur. Model tedarik zinciri saldırıları üç ana biçimde gerçekleşir. Birincisi, Hugging Face veya başka model havuzlarına yüklenen önceden eğitilmiş modellerin zararlı ağırlıklar veya backdoor içermesidir; güvenilmez kaynaklardan indirilen modeller, belirli girdi kalıplarında beklenmedik davranış üretebilir. İkincisi, Python paket ekosistemindeki typosquatting saldırılarıdır; `transformers` yerine `transfromers` gibi yazım hatası içeren kötü amaçlı paketler pip üzerinden yayılır. Üçüncüsü, MLOps araç zincirinin (CI/CD pipeline'ları, eğitim ortamları) ele geçirilmesiyle model eğitimi sırasında manipülasyon yapılmasıdır. Savunma stratejileri model ve paket bütünlüğü doğrulamasını (kriptografik hash kontrolü, dijital imza), güvenilir kaynaklardan (yalnızca onaylı kayıt defterlerinden) bileşen tüketimini, software bill of materials (SBOM) oluşturulmasını ve model davranışının üretim ortamında sürekli izlenmesini kapsar. SLSA (Supply-chain Levels for Software Artifacts) çerçevesi ve MITRE ATLAS AI tedarik zinciri taktikleri bu alanda rehber standartlardır. Türkiye'de kamu kurumları ve kritik altyapı operatörleri, siber güvenlik mevzuatı (BTK/USOM kılavuzları) kapsamında üçüncü taraf yazılım bağımlılıklarının güvenlik denetimini içeren tedarik zinciri risk yönetim planı hazırlamakla yükümlü kılınmaktadır.

arrow_forward
code_blocks

TDD (Test Driven Development) (Test Güdümlü Geliştirme)

Test Güdümlü Geliştirme (TDD), yazılım geliştirme sürecinde kodun üretilmesinden önce test senaryolarının yazıldığı bir metodolojidir. Kent Beck tarafından 1990'larda Aşırı Programlama (Extreme Programming/XP) çerçevesinde formalize edilen bu yaklaşım, günümüzde modern yazılım mühendisliğinin temel pratiklerinden biri olarak kabul görmektedir. TDD üç aşamalı bir döngüyle işler: Kırmızı (Red) aşamasında önce başarısız olacak bir test yazılır; bu test, uygulanmak istenen işlevselliği tanımlar ve sistemin henüz o davranışa sahip olmadığını gösterir. Yeşil (Green) aşamasında yazılan testi geçmek için minimum düzeyde kod üretilir; amaç testi en kısa yoldan geçirmek ve gereksiz karmaşıklıktan kaçınmaktır. Yeniden Yapılandır (Refactor) aşamasında çalışır hâle gelen kod temizlenir, okunabilirlik ve sürdürülebilirlik açısından optimize edilir; tüm testlerin hâlâ geçtiği doğrulanır. Yapay zeka ve makine öğrenimi projelerinde TDD, klasik yazılımdan farklı katmanlarda uygulanır. Veri boru hattı testleri, gelen verinin beklenen şema ve dağılıma uyduğunu garantiler; bu aşamada Great Expectations ve Deepchecks gibi araçlar verinin güvenilirliğini doğrular. Özellik mühendisliği testleri, dönüşüm mantığını birim düzeyinde sabitleyerek veri kayması (data drift) riskini erken aşamada tespit edilebilir kılar. Model davranış testleri ise bilinen örnekler için beklenen çıktıları önceden tanımlayarak regresyonları anında ortaya çıkarır. Performans eşik testleri, Accuracy, F1 veya AUC gibi metriklerin minimum kabul değerlerini kodun içine yerleştirir. TDD'nin ML yaşam döngüsüne katkısı yalnızca hata tespitinin ötesindedir. Testler, sistemin beklenen davranışını belgeleyerek reproduktibiliteyi güvence altına alır; bu araştırma ve üretim süreçlerinde kritik bir gereksinimdir. Model mimarisi veya pipeline değişikliklerinde test suitesi, geri dönüşleri anında yakalayan bir ağ işlevi görür. Python ekosisteminde pytest, Hypothesis ve Deepchecks gibi araçlar TDD'nin ML projelerindeki uygulanmasını kolaylaştırır. Yapay zeka destekli kod üretiminin (GitHub Copilot, Cursor, Devin) yaygınlaşmasıyla birlikte test yazma süresinin kısalması, bu metodolojinin benimsenmesini her zamankinden daha erişilebilir kılmaktadır.

arrow_forward
code_blocks

Triton Inference Server (Triton Çıkarım Sunucusu)

Triton Inference Server, NVIDIA tarafından 2018 yılında açık kaynak olarak yayımlanan, üretim ortamlarında yapay zeka modellerini yüksek verimlilikle sunan bir çıkarım sunucusudur. Mart 2025'te NVIDIA Dynamo platformuyla birleştirilerek NVIDIA Dynamo-Triton adını alan bu proje, PyTorch, TensorRT, ONNX Runtime, TensorFlow, OpenVINO ve vLLM gibi popüler çerçevelerden gelen modelleri tek bir süreç içinde barındırır. Temel mimarisinde Triton, her arka uç (backend) için ayrı çalışma ortamları oluşturur ve gelen istekleri paralel olarak yönlendirir. Dinamik yığınlama (dynamic batching), birden fazla isteği tek geçişte birleştirerek GPU kullanımını artırır. Ensemble Pipeline özelliği ise önişleme, model çıkarımı ve sonişleme adımlarını tek bir uçtan uca akış olarak tanımlamayı mümkün kılar. Bu yapı, karmaşık AI boru hatlarının tek bir konfigürasyon dosyasıyla yönetilmesini kolaylaştırır. Desteklediği donanım açısından Triton; NVIDIA GPU, x86 ve ARM tabanlı CPU ile AWS Inferentia üzerinde çalışabilir. Bulut, veri merkezi ve uç bilişim (edge) ortamlarına aynı yapılandırmayla dağıtım yapılabilmesi, yönetim maliyetlerini önemli ölçüde düşürür. MLOps entegrasyonu açısından Kubernetes ile ölçeklendirme, Prometheus ile izleme ve MLflow ile model kayıt akışlarına kolayca entegre edilebilir. Model Registry'den yeni sürüm yüklendiğinde Triton, hizmet kesilmesi olmadan güncelleme yapabilir. Büyük dil modellerini sunarken vLLM backend'i etkinleştirilebilir; bu bileşen sayfa dikkatini (paged attention) ve KV-cache yönetimini Triton çatısı altında gerçekleştirir. Aynı sunucuda LLM, görüntü enkoderi ve ses sınıflandırıcı gibi birden fazla model türünü paralel çalıştırmak gerektiğinde Triton vazgeçilmez bir araç hâline gelir. 2025-2026 itibarıyla Google Vertex AI, AWS SageMaker ve Azure ML gibi büyük bulut platformları Triton'ı birincil çıkarım motoru olarak benimsemiştir. Aralık 2025 sürümüyle vLLM backend'in ağırlık paylaşımı ve speculative decoding desteği de önemli ölçüde güçlendirildi. BSD-3 lisansıyla dağıtılan Triton, kurumsal ML ekiplerinin üretim ortamında güvenle tercih ettiği açık kaynak bir çözüm olmayı sürdürmektedir.

arrow_forward
code_blocks

Version Control Nedir? Yazılım Geliştirmede Sürüm Kontrolü (Sürüm Kontrolü)

Version control (sürüm kontrolü), bir yazılım projesindeki dosyaların zaman içindeki değişikliklerini kaydeden, yöneten ve takip eden bir sistem türüdür. Geliştiriciler bu sistem aracılığıyla koda yapılan her değişikliği adım adım kaydederek belirli bir sürüme geri dönebilir, farklı özellikler üzerinde paralel olarak çalışabilir ve takım arkadaşlarıyla çakışma olmadan iş birliği yapabilir. Version control sistemleri iki temel kategoriye ayrılır: merkezi (centralized) ve dağıtık (distributed). Merkezi sistemlerde—örneğin SVN (Subversion) veya CVS—tüm proje geçmişi tek bir merkezi sunucuda tutulur; sunucu erişilemez olduğunda çalışma durur. Dağıtık sistemlerde—özellikle Git—her geliştirici tam proje geçmişine sahip yerel bir kopya barındırır; bu tasarım çevrimdışı commit, hızlı dal (branch) oluşturma ve güvenli depolama açısından belirgin avantajlar sunar. Git, 2005 yılında Linux çekirdeği geliştirmesi için Linus Torvalds tarafından yaratılmış ve bugün endüstrinin fiili standardı hâline gelmiştir. Dal tabanlı iş akışı Git'in temel güçlerinden biridir: her özellik veya hata düzeltmesi ayrı bir branch üzerinde geliştirilip ana dala (main) pull request aracılığıyla birleştirilir. GitHub, GitLab ve Bitbucket; CI/CD entegrasyonu, kod incelemesi ve proje yönetimini tek çatı altında sunan platform katmanlarıdır. Makine öğrenmesi projelerinde version control özellikle kritik bir boyut kazanır: yalnızca kod değil, veri setleri, model ağırlıkları ve eğitim yapılandırmaları da versiyonlanmalıdır. DVC (Data Version Control) büyük dosyaları Git iş akışına entegre eder; model ağırlıkları ve veri setleri bulut depolamaya yönlendirilirken referansları Git'te tutulur. MLflow ve Weights & Biases deney izleme ile model versiyonlamayı birleştirir; böylece hangi hiperparametre setiyle hangi modelin üretildiği tam olarak izlenebilir. GitFlow, GitHub Flow ve Trunk-Based Development en yaygın dal yönetim stratejileridir; küçük ekipler için GitHub Flow genellikle yeterli olmakla birlikte büyük ve çok ekipli projelerde GitFlow daha ayrıntılı bir yayın yönetimi sunar.

arrow_forward