category Yazılım ve MLOps
Yazılım ve MLOps kategorisi, yapay zeka ve makine öğrenimi alanındaki 38 temel terim ve kavramı kapsar: A/B Testing, Açık Kaynak Model, AIOps (AI for IT Operations), API Gateway, AutoML, Canary Deployment. Her terim için tanım, örnek ve ilgili kavramları bu sayfadan keşfedebilirsiniz.
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.
Açık Kaynak Model (Açık Kaynak Model)
Açık Kaynak Model (Open-Weight Model), model ağırlıklarının ve çoğunlukla eğitim kodunun kamuya açık biçimde yayımlandığı, araştırmacıların ve geliştiricilerin serbestçe indirip inceleyebileceği, özelleştirip dağıtabileceği yapay zeka modelidir. Kapalı API modellerin aksine açık kaynak modeller dışarıya bağımlılığı ortadan kaldırır, gizlilik açısından hassas verilerin yerel ortamda işlenmesine imkân tanır ve araştırma ekosistemini güçlendirir. Açık kaynak LLM hareketi Meta AI'ın 2023'te LLaMA modelini yayımlamasıyla hız kazandı. LLaMA serisi (LLaMA 2, LLaMA 3), Mistral, Gemma (Google), Phi (Microsoft), Falcon ve DeepSeek bu kategorinin öne çıkan örnekleridir. Bu modeller Hugging Face hub üzerinden dağıtılmakta; GGUF, GPTQ ve AWQ gibi kuantizasyon formatlarıyla tüketici donanımlarında çalıştırılabilmektedir. Açık kaynak modellerin kullanım biçimleri çeşitlidir. Yerel çalıştırma için Ollama ve LM Studio gibi araçlar basit arayüzler sunar. İnce ayar (fine-tuning) ile belirli alanlara veya kurum verilerine özelleştirme yapılır; LoRA ve QLoRA teknikleri bu süreci düşük bellek bütçesiyle mümkün kılar. RAG sistemi kurulumunda açık embedding modelleriyle birleştirilerek gizlilik korunur. Lisanslama açısından dikkat edilmesi gerekir; bazı modeller ticari kullanıma kısıtlama getirir (LLaMA 2'nin kullanıcı sayısı sınırı gibi). Apache 2.0, MIT ve Mistral'ın kendi lisansı gibi permissive lisanslar ticari kullanıma tam açıktır. Model seçiminde kapasite, lisans tipi, kuantizasyon seçenekleri ve topluluk desteği değerlendirilmesi gereken başlıca faktörlerdir. Açık kaynak model ekosistemi hızla büyümektedir. Hugging Face hub'da 800.000'den fazla model bulunmakta; topluluk tarafından geliştirilen adaptörler, değerlendirme kıyaslamaları ve entegrasyon araçları bu büyümeyi hızlandırmaktadır. Araştırma şeffaflığı açısından açık ağırlıklar, model davranışı üzerinde denetlenebilir çalışma yapılmasına imkân tanır. Türkiye'de açık kaynak modeller özellikle Türkçe NLP çalışmalarında ve veri gizliliği gerektiren kurumsal projelerde yaygın tercih haline gelmektedir. KVKK uyumluluğu bağlamında müşteri verilerini işleyen şirketler, verilerin dışarıya çıkmamasını garanti eden yerel model dağıtımını kapalı API çözümlerine tercih etmektedir.
AIOps (AI for IT Operations) (Bilişim Operasyonları için YZ)
AIOps (Artificial Intelligence for IT Operations), büyük ölçekli IT altyapısını izlemek, anormallik tespiti yapmak ve olaylara proaktif yanıt vermek amacıyla makine öğrenimi ve büyük veri analitik tekniklerini operasyonel verilere uygulayan disiplindir. Gartner tarafından 2017'de kavramsallaştırılan bu alan, klasik kural tabanlı izleme sistemlerinin yetersiz kaldığı modern hibrit ve çok bulutlu mimarilerde kritik önem kazanmaktadır. Geleneksel IT Operasyonları (ITOps), uygulama günlükleri, metrikler, izleme uyarıları ve ağ olayları gibi devasa veri akışlarını manuel kurallar ve eşik değerleriyle yorumluyordu. Mikroservis mimarileri ve bulut-doğal altyapıların yaygınlaşmasıyla saniyede milyonlarca telemetri verisi üretilmektedir; bu hacimde insan operatörü yaklaşımı ölçeklenememektedir. AIOps platformları bu veri akışını gerçek zamanlı olarak işler, uyarıları ilişkilendirir ve köklü neden (root cause) analizini otomatikleştirir. Temel teknikler arasında anomali tespiti (zaman serisi modellemesi, isolation forest, autoencoderlar), log kümeleme (log anormalliklerini vektörleştirme ve gruplama), uyarı korelasyonu (binlerce uyarıyı az sayıda anlamlı olaya indirme) ve tahmini kapasite planlaması yer almaktadır. Splunk, Dynatrace, New Relic ve ServiceNow ITOM bu alandaki öncü platformlardır; bulut sağlayıcıları da AWS DevOps Guru ve Azure Monitor gibi yerel AIOps yetenekleri sunmaktadır. Türkiye'de fintech, telekom ve e-ticaret sektörlerindeki büyük ölçekli şirketler AIOps yaklaşımını benimsemeye başlamıştır. Yüksek erişilebilirlik gerektiren sistemlerde ortalama çözüm süresi (MTTR) azaltma ve olay yorgunluğunu (alert fatigue) giderme temel motivasyonlar arasında öne çıkmaktadır. AIOps ile Site Reliability Engineering (SRE) yakın ilişki içindedir: her ikisi de sistem güvenilirliğini artırmayı hedefler; AIOps araçları SRE ekiplerinin verimliliğini artıran otomasyon katmanını oluşturur. Büyük dil modellerinin AIOps platformlarına entegrasyonu (LLM-destekli olay özetleme, runbook oluşturma, otomatik yama önerisi) güncel araştırma ve ürün geliştirme alanı haline gelmektedir. Gözlemlenebilirlik (observability) — metrikler, izler (traces) ve günlüklerin (logs) bütünleşik analizi — AIOps'un operasyonel veri tabanını oluşturur.
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 ve tutarsızlıkları önler. 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 (cost attribution) 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.
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 gerektirir; NAS gibi yöntemler yüzlerce GPU-saati tüketebilir. Ayrıca otomatik sürecin ürettiği modeller bazen yorumlanabilirlikten yoksun karmaşık pipeline'lar içerir. Bu nedenle AutoML, uzman veri bilimcilerin yerini almaktan çok onları rutin model arama 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 yaygınlaşmaktadır.
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.
CI/CD (CI/CD)
CI/CD, yazılım geliştirme süreçlerinde iki temel pratiği birleştiren bir metodolojinin kısaltmasıdır: Sürekli Entegrasyon (Continuous Integration — CI) ve Sürekli Teslim/Dağıtım (Continuous Delivery/Deployment — CD). Bu yaklaşım, kod değişikliklerinin hızlı, güvenli ve tekrarlanabilir biçimde kullanıcılara ulaştırılmasını sağlar. Sürekli Entegrasyon (CI), geliştiricilerin kod değişikliklerini sık sık — genellikle günde birkaç kez — ortak bir depoya birleştirdiği bir yaklaşımdır. Her birleştirme işlemi otomatik derleme ve test süreçlerini tetikler. Bu sayede hatalar erken tespit edilir, entegrasyon sorunları minimize edilir ve takım üyeleri arasındaki kod uyumu sağlanır. CI olmadan büyük ekiplerde birleştirme işlemleri günlerce sürebilir ve ciddi çakışmalara yol açabilir. Sürekli Teslim (Continuous Delivery), başarıyla test edilmiş kod değişikliklerinin her an üretime alınmaya hazır tutulduğu bir yaklaşımdır. Sürekli Dağıtım (Continuous Deployment) ise bir adım daha ileri giderek onaylanan her değişikliği insan müdahalesi olmaksızın otomatik olarak canlı ortama taşır. Yapay zeka ve makine öğrenmesi projelerinde CI/CD, MLOps bağlamında özellikle kritik bir rol üstlenir. Geleneksel yazılımın aksine, ML boru hatları yalnızca kodu değil; model ağırlıklarını, veri doğrulama adımlarını ve model performans metriklerini de kapsar. Bir model güncellendikten sonra otomatik değerlendirme aşamalarından geçmeden üretime geçmemesi, model kalitesini güvence altına alır ve regresyonları önler. Yaygın CI/CD araçları arasında GitHub Actions, GitLab CI/CD, Jenkins, CircleCI ve Azure DevOps yer alır. Docker konteynerleri ve orkestrasyon platformlarıyla entegre çalışan bu boru hatları, ortamdan bağımsız ve tekrarlanabilir dağıtımlar sağlar. Gölge mod (shadow mode) ve kanarya dağıtımı (canary deployment) gibi ileri dağıtım stratejileri de genellikle CI/CD altyapısı üzerine inşa edilir, üretim ortamında riski kademeli olarak azaltır.
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 entegrasyonunu ifade eder. Geleneksel CI/CD, manuel kural tabanlı test, derleme ve dağıtım adımlarını otomatikleştirirken; CI/CD AI bu süreci daha akıllı, adaptif ve öngörücü hale getirir. CI/CD AI sistemleri, kod değişikliklerini analiz ederek hangi testlerin çalıştırılması gerektiğini tahmin edebilir (test seçimi ve önceliklendirme), derleme başarısızlıklarının kök nedenini otomatik belirleyebilir, güvenlik açıklarını erken tespit edebilir ve dağıtım risklerini değerlendirerek otomatik geri alma kararları verebilir. Bu sayede geliştirici ekipleri hataları çok daha hızlı bulup giderebilir, gereksiz test süreleri azalır ve teslimat hızı belirgin şekilde artar. MLOps bağlamında CI/CD AI, makine öğrenmesi modellerinin eğitim, doğrulama ve dağıtım döngüsünü de kapsar. Bir modelin performansı belirli bir eşiğin altına düştüğünde CI/CD AI sistemi otomatik olarak yeniden eğitim sürecini başlatabilir ve doğrulanmış yeni modeli canary veya shadow modlarıyla devreye alabilir. Öne çıkan araçlar arasında GitLab Duo, GitHub Copilot for CI/CD, Harness AI ve CircleCI yer almaktadır. Bu platformlar, boru hattı yapılandırma önerileri, test analizi ve güvenlik açığı açıklaması gibi özellikler sunar. Agentik CI/CD olarak da adlandırılan en güncel yaklaşımda AI ajanları boru hattında proaktif rol üstlenerek küçük hataları insan müdahalesi olmadan düzeltebilir, test suitini kod değişikliğine göre dinamik olarak ayarlayabilir ve dağıtımı risk skoruna göre yönlendirebilir.
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 sabit kalır; ancak gerçek dünyada veriler değiştiği için model performansı zamanla bozulur. Continuous Training bu sorunu çözmek için modeli periyodik olarak veya tetikleyici koşullar altında otomatik yeniden eğitim döngülerine sokar. Continuous Training, yazılım geliştirmedeki Sürekli Entegrasyon (Continuous Integration / CI) kavramından ilham alır. Nasıl ki yazılım CI sistemleri her kod değişikliğinde otomatik derleme ve test çalıştırıyorsa, CT sistemleri de yeni eğitim verisi geldiğinde otomatik model eğitimi ve değerlendirmesi çalıştırır. CT'nin iki ana tetikleme stratejisi vardır: Zaman tabanlı (time-based) strateji sabit aralıklarla yeniden eğitim çalıştırır — günlük, haftalık veya aylık. Olay tabanlı (event-based) strateji ise belirli koşullar gerçekleştiğinde tetiklenir: örneğin data drift tespiti, model performans metriklerinin belirli eşiğin altına düşmesi veya eğitim veri setinin boyutunun belli bir miktara ulaşması. Pipeline mimarisi açısından CT şunları içerir: veri toplama ve doğrulama, özellik mühendisliği, model eğitimi, otomatik değerlendirme ve karşılaştırma, onay mekanizması (challenger/champion modeli), güvenli dağıtım (canary veya blue-green). Bu adımların her biri otomasyon yönetim araçları (Vertex AI Pipelines, Kubeflow, MLflow) tarafından orkestre edilir. Continuous Training ile Continuous Learning arasındaki fark önemlidir: CT periyodik yeniden eğitim (tüm model sıfırdan ya da fine-tune) anlamına gelirken, Continuous Learning (online learning) her yeni gözlem sonrası modelin parametrelerini gerçek zamanlı güncellediği daha karmaşık bir yaklaşımdır.
Copilot (Yapay Zeka Yardımcı Pilotu)
Microsoft Copilot, yapay zeka destekli bir üretkenlik asistanıdır. Başlangıçta GitHub Copilot adıyla kod yazma süreçlerini desteklemek amacıyla piyasaya sürülen bu teknoloji, zamanla Microsoft'un tüm ürün ekosistemine entegre edilerek çok daha kapsamlı bir asistan platformuna dönüşmüştür. Büyük dil modelleri (LLM) üzerine inşa edilen Copilot, kullanıcıların doğal dil aracılığıyla kod üretmesine, metin yazmasına, veri analizi yapmasına ve karmaşık görevleri hızla tamamlamasına olanak tanır. GitHub Copilot, OpenAI'nin Codex modelini temel alarak geliştirilmiş ve milyarlarca satır açık kaynak kodu üzerinde eğitilmiştir. Bu sayede yazılım geliştiriciler, yorum satırları veya fonksiyon imzaları yazdığında Copilot otomatik olarak uygun kod önerileri sunar. Desteklenen diller arasında Python, JavaScript, TypeScript, Ruby, Go, C++ ve daha onlarcası yer almaktadır. IDE entegrasyonları aracılığıyla VS Code, JetBrains ürünleri ve Neovim ile sorunsuz çalışır. Microsoft 365 Copilot ise Word, Excel, PowerPoint, Outlook ve Teams gibi ofis uygulamalarını yapay zeka ile güçlendirir. Word'de uzun belgeler özetlenebilir veya sıfırdan taslaklar oluşturulabilir; Excel'de doğal dil sorularıyla veri analizi yapılabilir; PowerPoint'te içerik açıklamalarından slaytlar otomatik üretilebilir. Bu entegrasyon, bilgi çalışanlarının tekrarlayan görevlere harcadığı zamanı önemli ölçüde azaltmaktadır. Windows Copilot ise işletim sistemi düzeyinde bir asistan olarak görev yapar. Sistem ayarlarını değiştirmek, uygulamaları açmak, web aramalarını özetlemek ve günlük görevlerde rehberlik etmek gibi işlevler sunar. Böylece kullanıcılar, bilgisayarlarıyla daha doğal bir şekilde etkileşim kurabilmektedir. Copilot'un etik ve güvenlik boyutları da önem taşımaktadır. Kod önerilerinin açık kaynak lisanslarıyla uyumu, yanlış veya güvenlik açığı içeren kodların üretilmesi riski ve kurumsal veri gizliliği gibi konular sürekli tartışılmaktadır. Microsoft bu endişeleri gidermek amacıyla kurumsal sürümlerde veri yalıtımı garantileri sunmakta ve sorumlu yapay zeka ilkeleri çerçevesinde geliştirme yapmaktadır. Copilot'un iş akışlarına entegrasyonu, yazılım geliştirme hızını artırırken aynı zamanda geliştiricilerin kalite denetimi ve eleştirel düşünme becerilerini ön plana çıkarmaktadır. Yapay zekanın ürettiği kodu körü körüne kabul etmek yerine, öneriyi değerlendirip iyileştirmek bir beceri haline gelmiştir.
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.
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.
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.
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.
Data Warehouse (Veri Ambarı)
Veri Ambarı (Data Warehouse), farklı kaynaklardan toplanan büyük miktarda yapılandırılmış verinin analitik sorgular ve iş zekası (BI) uygulamaları için optimize edilmiş şekilde depolandığı merkezi bir veritabanı sistemidir. Günlük işlem (OLTP) veritabanlarından farklı olarak veri ambarları, tarihsel veriyi korumak, karmaşık analizler yapmak ve karar destek sistemlerine veri sağlamak amacıyla tasarlanmıştır. Bill Inmon, 1990'da veri ambarını dört temel özellikle tanımladı: (1) Konu odaklı — müşteri, ürün veya satış gibi belirli iş konuları etrafında organize edilir; (2) Entegre — farklı kaynaklardan gelen veriler tutarlı bir formatta birleştirilir; (3) Değişmez — bir kez yüklenen veriler güncellenmez, yalnızca yeni kayıtlar eklenir; (4) Zaman serili — veriler belirli dönemlere ait etiketlerle saklanır ve tarihsel analiz mümkün kılınır. Veri ambarına veri yüklemek için ETL (Extract, Transform, Load) süreci kullanılır: kaynak sistemlerden veri çekilir, temizlenip dönüştürülür ve ambar tablolarına yüklenir. Modern yaklaşımlarda ELT (ham veri önce yüklenir, sonra dönüştürülür) yöntemi de yaygınlaşmıştır. Boyutsal modelleme (dimensional modeling) tekniğiyle oluşturulan yıldız (star) ve kar tanesi (snowflake) şema tasarımları, sorgu performansını artırır. Bulut çağında Amazon Redshift, Google BigQuery, Snowflake ve Microsoft Azure Synapse Analytics gibi MPP (Massively Parallel Processing) mimarili çözümler petabayt ölçeğinde veri işlemeyi mümkün kılmaktadır. Data Lakehouse mimarisi ise veri ambarı ile Data Lake'in avantajlarını tek platformda birleştirmektedir. Veri ambarları; finans raporlaması, müşteri segmentasyonu, tedarik zinciri optimizasyonu ve makine öğrenimi feature store'ları için kritik altyapıdır.
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.
DevOps Nedir? Geliştirme ve Operasyon Bütünleşmesi (DevOps (Geliştirme ve Operasyonlar))
DevOps, "Development" (Geliştirme) ve "Operations" (Operasyonlar) kelimelerinin birleşiminden oluşan bir kültürel, metodolojik ve teknik yaklaşımdır. 2009 yılında Patrick Debois'ın öncülüğünde başlayan bu hareket, yazılım geliştirme ekipleri ile BT operasyon ekipleri arasındaki geleneksel siloları yıkmayı hedefler. Geleneksel yazılım süreçlerinde geliştirme ve operasyon ekipleri ayrı gruplar hâlinde çalışırdı: Geliştiriciler kodu yazıp teslim eder, operasyon ekibi bu kodu canlı ortamlarda yönetirdi. Bu ayrışma iletişim sorunlarına, yavaş sürümlere ve sık arızalara yol açıyordu. DevOps, iki ekibi ortak araçlar, süreçler ve sorumluluklar etrafında birleştirerek bu sorunları çözmeyi amaçlar. DevOps'un temel unsurları şunlardır: Sürekli Entegrasyon (CI), kod değişikliklerinin sık sık ortak depoya birleştirilmesi ve otomatik testlerle doğrulanmasıdır. Sürekli Teslimat (CD), yazılımın her an üretime alınabilecek hale getirilmesini sağlar. Altyapı Kod Olarak (IaC) yaklaşımında Terraform ve Ansible gibi araçlarla sunucu konfigürasyonları kod aracılığıyla yönetilir. İzleme ve Gözlemlenebilirlik katmanında Prometheus, Grafana ve Datadog ile sistem sağlığı gerçek zamanlı takip edilir. Kültürel Dönüşüm boyutunda ise ekipler arası iş birliği, ortak sorumluluk ve suçlama yerine öğrenmeye dayalı "blameless post-mortem" anlayışı benimsenir. Modern DevOps araç ekosistemi Docker (konteynerizasyon), Kubernetes (orkestrasyon), GitHub Actions (CI/CD boru hattı) ve Terraform (altyapı) gibi teknolojiler üzerine kurulmuştur. Yapay zeka ile birleşen DevOps (AIOps ve MLOps), yazılım döngülerini daha da hızlandırmakta; anormallik tespiti, otomatik iyileştirme ve tahmine dayalı ölçekleme yetenekleri katmaktadır. DORA (DevOps Research and Assessment) araştırmalarına göre olgun DevOps uygulamaları, dağıtım sıklığını 200 katına kadar artırırken arıza oranlarını ve ortalama kurtarma sürelerini önemli ölçüde azaltmaktadır. Bu veriler DevOps'un yalnızca teknik bir metodoloji değil, rekabet avantajı yaratan stratejik bir dönüşüm olduğunu ortaya koyar.
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.
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 sağlanır; 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 zorunlu hale gelmektedir. Rekabetin yoğun olduğu yapay zeka alanında tekrarlanabilir ve ölçeklenebilir deneyler yürütmek, modellerin üretim ortamına güvenle taşınmasının temel ön koşuludur.
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.
JSON (JavaScript Object Notation)
JSON (JavaScript Object Notation), insan tarafından okunabilir ve makineler arası veri değişimine uygun hafif bir metin tabanlı veri biçimidir. Douglas Crockford tarafından 2001 yılında tanımlanmış, RFC 8259 standardıyla resmileşmiş; günümüzde REST API'leri, yapılandırma dosyaları ve yapay zeka sistemleri arasında de facto veri alışveriş standardı konumundadır. JSON altı temel değer türü destekler: string (çift tırnak içinde metin), number (tam veya ondalıklı sayı), boolean (true/false), null (değersizlik) ile iki koleksiyon türü olan object (anahtar-değer çiftleri) ve array (değerler listesi). Sözdizimi minimal olduğundan tüm modern programlama dillerinde yerel destek mevcuttur. XML aksine şema gerektirmez; YAML kıyasla katı sözdizimi ayrıştırma tutarsızlıklarını önler. Yapay zeka ve LLM sistemlerinde JSON kritik öneme sahiptir. OpenAI, Anthropic ve Google gibi sağlayıcıların API'leri sohbet turlarını, araç tanımlarını (tool/function calling) ve model yanıtlarını JSON formatında iletir. Yapılandırılmış Çıktılar (Structured Outputs) özelliği, modelin JSON Schema'ya tam uyumlu yanıt üretmesini garanti ederek ayrıştırma hatalarını ortadan kaldırır. Pydantic ve Zod kütüphaneleri, JSON'ı Python ve TypeScript veri modellerine dönüştürmek için yaygın kullanılır. JSON Schema, bir JSON belgesinin yapısını, zorunlu alanlarını ve değer kısıtlamalarını tanımlayan bağımsız bir standarttır; LLM araç tanımlarının ve yapılandırılmış çıktı doğrulamasının temelini oluşturur. JSON Lines (.jsonl), her satırın bağımsız bir JSON nesnesi olduğu varyant olup LLM eğitim veri setlerinde ve büyük veri işleme boru hatlarında yaygın tercih görür. Hugging Face model hub'ında config.json ile tokenizer_config.json dosyaları model mimarisini ve tokenizer parametrelerini bu formatta tanımlar. Güvenilmez kaynaklardan gelen JSON verisi işlenirken şema doğrulaması uygulanmalıdır. LLM çıktısından JSON elde edilmesinde Markdown kod bloğu içindeki JSON'ı regex ile işlemek yerine JSON modu veya yapılandırılmış çıktı API'si tercih edilmesi çok daha güvenilir sonuç verir.
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 yeniden kullanılabilir komponent kütüphanesi sunar. Deney takibi (lineage), artifact yönetimi ve görsel pipeline grafiği de bu bileşene dahildir. KServe (eski adıyla KFServing), üretim ortamında model sunma (inference) platformudur; canary deployment, A/B testi, model versiyonlama ve otomatik ölçeklendirme (autoscaling) destekler; TensorFlow Serving, TorchServe ve NVIDIA Triton gibi backend'lerle entegre çalışır. Katib, Kubernetes üzerinde hiperparametre optimizasyonu (HPO) ve sinir ağı mimarisi araştırması (NAS) gerçekleştirir; Bayesian optimizasyon, CMA-ES ve Hyperband algoritmaları desteklenir. Training Operators bileşeni, PyTorchJob, TFJob ve MPI Operator aracılığıyla dağıtık model eğitimini yönetir; çok node'lu GPU kümeleri üzerinde veri paralelliğini koordine eder. Kubeflow Notebooks ise Jupyter Notebook sunucularını Kubernetes üzerinde başlatarak GPU/CPU kaynak yapılandırması ve çalışma ortamı seçimi 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 yüksektir. Vertex AI Pipelines (Google Cloud), SageMaker Pipelines (AWS) ve Azure ML gibi yönetilen alternatifler altyapı yükünü azaltır. Türkiye'de cloud-agnostic ve on-premises MLOps altyapısı kurmak isteyen büyük şirketler ve araştırma kurumları Kubeflow'u değerlendirmektedir; Kubernetes yetkinliğinin ekipte bulunması ön koşuldur.
LlamaIndex Nedir? Veri Bağlantı ve RAG Çerçevesi (LlamaIndex)
LlamaIndex (eski adıyla GPT Index), büyük dil modellerini (LLM) özel veri kaynaklarıyla entegre etmek için tasarlanmış açık kaynaklı bir Python çerçevesidir. 2022 yılında Jerry Liu tarafından geliştirilen ve başlangıçta GPT Index adını taşıyan bu proje, LangChain ile birlikte LLM uygulama ekosisteminin iki temel taşından biri konumuna yükselmiştir. LlamaIndex üç temel katmandan oluşur. Veri konektörleri (data connectors), PDF ve Word belgelerinden SQL veritabanlarına, REST API'lerden Slack ve Notion gibi SaaS araçlarına kadar 160'tan fazla kaynaktan veri okur; bu katman LlamaHub platformu aracılığıyla sürekli genişleyen bir ekosisteme sahiptir. İndeksleme katmanı, ham veriyi Pinecone, Weaviate, Chroma ve pgvector gibi 20'den fazla vektör veritabanında saklanan vektör temsillerine dönüştürür ya da hiyerarşik ağaç indeksleri, anahtar kelime tabanlı indeksler ve bilgi grafikleri gibi alternatif yapıları kullanır. Sorgu motoru, kullanıcının doğal dil sorusunu gelen sorguya en uygun belgeleri getiren bir retrieval adımına, ardından LLM tabanlı bir yanıt sentez adımına dönüştürür. RAG (Retrieval-Augmented Generation) mimarisinin referans uygulaması olarak LlamaIndex, modelin bilgi kesim tarihini aşan veya kuruma özel gizli verileri kullanarak güvenilir yanıtlar üretmesini sağlar. Örneğin bir hukuk firması, binlerce sözleşme belgesini vektör indeksine ekleyerek çalışanların doğal dille sözleşme araması yapmasını mümkün kılabilir. Çok-ajan sistemleri için LlamaIndex, görev planlama ve araç seçimi yapan ajan mimarileri sunar. OpenAI Assistants API ile entegrasyon, ReAct ve function calling tabanlı ajan döngüleri ve ajan aktivite izleme (tracing) bu katmanın temel özelliklerindendir. LlamaIndex Workflows, etkinlik güdümlü (event-driven) asenkron iş akışlarını Python dekoratörleri aracılığıyla tanımlamaya olanak tanır. TypeScript/JavaScript geliştiricileri için LlamaIndex.TS paralel bir ekosistem oluşturur; böylece hem sunucu taraflı Node.js hem de tarayıcı ortamı desteklenmektedir. Üretim izleme ve değerlendirme için LlamaTrace ve LlamaCloud platformları, kurumsal müşterilere yönelik yönetilen altyapı çözümleri sunar.
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.
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.
Microsoft Agent Framework (Microsoft Agent Framework)
Microsoft Agent Framework (MAF), Microsoft'un ajan tabanlı yapay zeka uygulamaları geliştirmek için ortaya koyduğu açık kaynaklı SDK ve çalışma zamanı ortamıdır. 2 Nisan 2026'da 1.0 GA (Genel Erişilebilirlik) sürümüne ulaşan MAF, AutoGen ve Semantic Kernel projelerinin birleştirilmesiyle oluşturulmuştur; böylece tek bir desteklenen platform altında aynı kavramlar ve API'ler Python ve .NET için sağlanmaktadır. MAF'ın temel programlama modeli şu bileşenlerden oluşur: sohbet istemcileri (chat clients), araçlar (tools), MCP (Model Context Protocol) entegrasyonları, bağlam sağlayıcıları (context providers), ara yazılım (middleware) ve çok adımlı iş akışları. Bu mimari, geliştiricilerin ajan altyapısının teknik ayrıntılarıyla değil, ajan mantığıyla ilgilenmesini sağlar. Build 2026'da duyurulan ek özellikler arasında Agent Harness (kabuk, dosya sistemi ve mesajlaşma döngülerine kontrollü erişim), Agent Skills (alan uzmanlığını paket olarak sunmak için taşınabilir, dosya tabanlı veya kodla tanımlanan format), prosedürel bellek (procedural memory) ve Voice Live entegrasyonu yer almaktadır. Çerçeve ayrıca Foundry üzerindeki araç kutuları (Toolboxes) aracılığıyla Microsoft'un bulut altyapısıyla entegre çalışmaktadır. MAF, AutoGen'in sade ajan soyutlamalarını Semantic Kernel'in kurumsal özellikleriyle — oturum tabanlı durum yönetimi, tip güvenliği, ara yazılım, telemetri — birleştirmekte; çok ajanlı orkestrasyon için açık graf tabanlı iş akışları eklemektedir.
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. Databricks tarafından 2018 yılında Apache 2.0 lisansıyla açık kaynak olarak piyasaya sürülen MLflow, veri bilimcilerin ve ML mühendislerinin deney takibinden model dağıtımına kadar tüm süreci tek bir araçla yönetmesine olanak tanır. MLflow dört ana bileşenden oluşur. İlk bileşen olan MLflow Tracking, makine öğrenmesi denemeleri sırasında parametreleri, metrikleri, çıktı dosyalarını ve model sürümlerini kayıt altına alır. Böylece farklı algoritma konfigürasyonlarını ve hiperparametreleri kolayca karşılaştırmak mümkün hale gelir. İkinci bileşen MLflow Projects, ML kodunu yeniden üretilebilir ve taşınabilir biçimlerde paketler; Conda veya Docker gibi ortam tanımlarını içeren MLproject dosyası sayesinde kodun farklı platformlarda tutarlı şekilde çalışması sağlanır. Üçüncü bileşen olan MLflow Models, eğitilmiş modelleri REST API, batch inference ve cloud platformlarına uygun standart bir formatta saklar. TensorFlow, PyTorch, scikit-learn, XGBoost, LightGBM ve HuggingFace Transformers dahil yirmi'den fazla ML çerçevesini destekler. Dördüncü ve son bileşen MLflow Model Registry ise modellerin versiyonlanması, etiketlenmesi ve yaşam döngüsünün yönetilmesi için merkezi bir depo sağlar; 'Staging', 'Production' ve 'Archived' gibi aşama geçişleri desteklenir. MLflow, AWS SageMaker, Azure ML, Google Cloud Vertex AI ve Databricks gibi büyük bulut platformlarıyla entegre çalışır. Kurumsal MLOps iş akışlarında deney yönetimi ve model üretim süreçleri için endüstri standardı haline gelmiştir. Açık kaynak topluluğu tarafından aktif olarak geliştirilmekte olan platform, Weights & Biases, Neptune.ai ve Comet ML gibi ticari alternatiflerin yanında popüler bir seçenek olmaya devam etmektedir.
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.
Model Monitoring (Model İzleme)
Model izleme (model monitoring), üretim ortamına alınan makine öğrenimi modellerinin performansını, davranışını ve veri kalitesini sürekli olarak takip etme ve değerlendirme sürecidir. Bir modelin eğitim aşamasındaki yüksek performansı, gerçek dünya koşullarında zamanla bozulabilir; bu bozulmayı erken tespit edip müdahale etmek için model izleme zorunludur. Temel izleme türleri şunlardır: Veri drifti (data drift) — giriş verilerinin dağılımının eğitim verisinden uzaklaşması; kavram drifti (concept drift) — hedef değişkenin özelliklerle ilişkisinin zamanla değişmesi; tahmin drifti (prediction drift) — model çıktılarının dağılımındaki kayma; veri kalitesi — eksik değerler, format bozuklukları veya beklenmeyen aykırı değerler. Model izlemenin kapsamı birkaç düzeyde ele alınır: Sistem düzeyinde gecikme süresi (latency), verim (throughput) ve hata oranı gibi altyapı metrikleri; model düzeyinde accuracy, F1 skoru, AUC gibi tahmin kalitesi metrikleri; iş düzeyinde ise dönüşüm oranı, gelir etkisi ve müşteri memnuniyeti gibi iş metrikleri izlenir. Yaygın model izleme platformları arasında Evidently AI, WhyLabs, Arize AI ve MLflow yer almaktadır. AWS SageMaker Model Monitor, Google Vertex AI ve Azure Machine Learning bu işlevi yönetilen servis olarak sunarken, açık kaynak araçlar daha fazla özelleştirme imkânı sağlar. Model izleme, MLOps yaşam döngüsünün kritik halkasıdır: Drift tespiti, uyarı üretimi, yeniden eğitim (retraining) ve yeniden dağıtım (redeployment) döngüsünü otomatikleştirir. Finans, sağlık, e-ticaret ve öneri sistemleri gibi dinamik veri ortamlarına sahip alanlarda model izleme; yasal uyum, güven ve iş sürekliliği açısından vazgeçilmezdir.
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.
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.
Model Serving (Model Servis (Çıkarım Sunumu))
Model Serving, eğitilmiş bir makine öğrenimi modelini üretim ortamında gerçek kullanıcılara veya sistemlere sunmak için kullanılan altyapı, araçlar ve süreçlerin bütününü ifade eder. Bir model ne kadar iyi eğitilmiş olursa olsun, bir servis arayüzü olmadan son kullanıcılara değer üretemez; model serving bu kritik boşluğu kapatır. Model serving süreci birkaç temel bileşenden oluşur: çıkarım sunucusu (inference server), model deposu (model registry), yük dengeleyici (load balancer) ve izleme sistemi (monitoring). Bunların bir araya gelmesiyle oluşan sistem, gelen tahmin isteklerini milisaniyeler içinde yanıtlayabilir. Sektörde yaygın olarak kullanılan servis çerçeveleri arasında TorchServe (PyTorch ekosistemi), NVIDIA Triton Inference Server (çok modelli, GPU-optimize), TensorFlow Serving, FastAPI ve BentoML yer alır. Her biri farklı performans, ölçeklenebilirlik ve model formatı gereksinimlerine göre seçilir. Servis modelleri açısından üç ana yaklaşım bulunur: çevrimiçi servis (online serving), gerçek zamanlı ve düşük gecikme süresi gerektiren tahmin isteklerinde kullanılır; toplu iş servisi (batch serving), büyük veri setleri üzerinde toplu tahmin çalıştırılmasına olanak tanır ve gerçek zamanlılık gerekmez; akış servisi (stream serving) ise Kafka veya Pub/Sub gibi mesaj kuyrukları üzerinden sürekli veri akışını işler. Çıkarım hızını artırmak için quantization (kuantizasyon), pruning (budama), ONNX formatına dönüştürme ve TensorRT optimizasyonu gibi teknikler yaygın olarak uygulanır. Kubernetes üzerinde çalışan model serving sistemi, gelen istek yüküne göre yatay olarak ölçeklendirilebilir. Otoscaling, maliyet optimizasyonu açısından kritik öneme sahiptir ve kullanım artışlarında otomatik olarak yeni sunucu instance'ları devreye girer.
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.
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.
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 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). 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ı gidermek için 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.
Token Kabul Oranı (Token Kabul Oranı)
Token Kabul Oranı (Token Acceptance Rate), spekülatif kod çözme sistemlerinde taslak modelin önerdiği tokenlerin büyük doğrulayıcı model tarafından kabul edilme yüzdesini ölçen verim metriğidir. Bu oran, spekülatif kod çözmenin pratikte ne kadar etkin çalıştığını değerlendirmenin temel göstergesidir. Spekülatif kod çözmede taslak model γ adet aday token önerir; doğrulayıcı model bunları değerlendirerek kabul veya reddeder. Eğer γ=8 öneride 6 tanesi kabul ediliyorsa token kabul oranı %75'tir. Kabul oranı yüksek olduğunda her doğrulayıcı geçişinden daha fazla yeni token kazanılır; bu durum fiili hız çarpanını artırır. Kabul oranı düştükçe spekülatif kod çözme geleneksel otoregresif kod çözmeye kıyasla avantajını yitirir ve belirli bir eşiğin altında geleneksel kod çözme daha verimli hâle gelir. Token kabul oranını etkileyen başlıca faktörler şunlardır: taslak modelin büyük modelle dağılım uyumu (kalibrasyonu), görev tipi, kontekst uzunluğu ve sıcaklık değeri. Aynı model ailesinden seçilen taslak modeller (LLaMA 3 8B + LLaMA 3 70B) dağılım uyumu yüksek olduğundan genellikle %80 üzerinde kabul oranı sağlar. Çeviri ve kod tamamlama gibi tahmin edilebilir görevler yaratıcı metin üretimine kıyasla daha yüksek kabul oranı verir. Token kabul oranı ile ortalama kabul uzunluğu (average accepted length, α) arasında doğrudan ilişki vardır. α değeri her doğrulayıcı geçişinde kabul edilen ortalama token sayısını gösterir ve teorik hız çarpanı (1 + α) olarak hesaplanır. Örneğin α=3 olduğunda teorik hız 4× artar. Pratikte bu değer GPU bellek bant genişliği ve model boyutu gibi faktörlere bağlı olarak değişir.
Torch Nedir? PyTorch'un Temeli Derin Öğrenme Kütüphanesi (Torch)
Torch, derin öğrenme modellerinin kurulup eğitildiği, GPU hızlandırmalı tensör hesaplama kütüphanesidir; bugün bu ad, Python'da `import torch` komutuyla çağrılan **PyTorch** çerçevesinin çekirdek paketini ifade eder. Yani "torch" ile PyTorch ayrı iki araç değildir: PyTorch projenin adı, `torch` ise kod içinde kullanılan paket adıdır. Hikaye 2001'de İsviçre'deki Idiap Araştırma Enstitüsü'nde C++ tabanlı orijinal Torch ile başladı. Ronan Collobert liderliğindeki ekip 2011'de kütüphaneyi Lua diliyle **Torch7** olarak yeniden yazdı; DeepMind ve Facebook araştırmacıları yıllarca bu sürümü kullandı. 2016'da Meta AI (o dönemki adıyla Facebook AI Research), aynı çekirdek felsefeyi Python'a taşıyarak PyTorch'u yayımladı. Lua tabanlı Torch7'nin geliştirilmesi 2018'de durdu ve tüm ekosistem PyTorch çatısı altında birleşti. 2022'den beri proje, Linux Foundation bünyesindeki **PyTorch Foundation** tarafından bağımsız biçimde yönetiliyor. Torch'u öne çıkaran üç teknik özellik var. Birincisi, NumPy benzeri sezgisel API ile çalışan ve `.to("cuda")` çağrısıyla GPU'ya taşınabilen **tensör** yapısı. İkincisi, geri yayılım (backpropagation) gradyanlarını tek bir `.backward()` çağrısıyla otomatik hesaplayan **Autograd** motoru. Üçüncüsü, hesaplama grafiğini her çalıştırmada anlık kuran **define-by-run** yaklaşımı; bu esneklik, hata ayıklamayı standart Python araçlarıyla yapmayı mümkün kılar. PyTorch 2.x dönemiyle (Aralık 2022'de duyuruldu, 2.0 Mart 2023'te çıktı) tabloya `torch.compile` eklendi: tek satırlık bu çağrı, modeli TorchInductor derleyicisiyle optimize ederek eğitimde tipik olarak %30-200 arası hızlanma getirir. 2025'te yayımlanan 2.6-2.9 sürümleri FP8 desteği, torchao ile nicemleme (quantization) ve Blackwell GPU uyumu gibi yenilikler taşıdı. Rakamlar üstünlüğü net gösteriyor: Hugging Face'teki modellerin %90'ından fazlası PyTorch formatında yayımlanıyor, NeurIPS gibi konferanslardaki uygulamalı makalelerin yaklaşık %80'i PyTorch kullanıyor. GPT, Llama ve Stable Diffusion gibi modellerin eğitim altyapısı da torch üzerine kurulu. Türkiye'de üniversite laboratuvarlarından bankacılık ve e-ticaret ekiplerine kadar derin öğrenme çalışan hemen her ekip, ilk satırı `import torch` olan kodlarla üretim yapıyor.
Vektör Veritabanı (Vektör Veritabanı)
Vektör Veritabanı, metin, görüntü ve ses gibi içeriklerin sayısal gömme vektörü (embedding) temsillerini depolayan ve bu vektörler arasında en yakın komşu araması (Approximate Nearest Neighbor, ANN) gerçekleştiren özelleşmiş veritabanı sistemidir. Geleneksel ilişkisel veritabanları tam eşleşme sorgularında güçlüyken vektör veritabanları anlamsal benzerlik sorgularında üstünlük sağlar. Temel işleyiş şu şekildedir: bir embedding modeli (BERT, OpenAI Embeddings, E5 gibi) metni yüksek boyutlu gerçek sayı vektörüne dönüştürür; bu vektör veritabanına kaydedilir. Sorgu zamanında sorgu cümlesi de aynı modelle vektöre dönüştürülür ve veritabanı, kosinüs benzerliği veya Öklid mesafesi ölçütüyle en yakın K vektörü geri döndürür. ANN algoritmaları (HNSW, IVF, FAISS) bu aramayı milyonlarca vektörde milisaniyeler içinde gerçekleştirir. Popüler vektör veritabanı çözümleri farklı kullanım senaryolarına hitap eder. Pinecone tam yönetilen bulut hizmetidir; Chroma ve Qdrant yerel veya kendi altyapısında barındırılabilir; Weaviate çok modlu destek ve GraphQL arayüzüyle öne çıkar; pgvector ise mevcut PostgreSQL veritabanına vektör yeteneği ekler. Büyük ölçeklerde Milvus ve Vespa tercih edilir. Vektör veritabanlarının birincil kullanım alanı RAG (Retrieval-Augmented Generation) sistemleridir: LLM'in bağlamına ilgili belgeler enjekte edilir; böylece model kendi eğitim verisinin ötesinde güncel bilgiyle yanıt üretir. Anlamsal arama motorları, öneri sistemleri, resim benzerliği arama ve kopya içerik tespiti diğer uygulama alanlarıdır. Vektör veritabanlarının performansı indeks yapısına bağlıdır. HNSW (Hierarchical Navigable Small World) yüksek sorgu hızı ve çok sayıda vektör için optimize edilmiş grafik yapısı kullanırken IVF (Inverted File Index) küme tabanlı bölümlemeyle arama uzayını daraltır. FAISS ise Facebook AI tarafından geliştirilen açık kaynak bir kütüphane olup milyarlarca vektörü GPU üzerinde indeksler. Vektör veritabanları, geleneksel tam metin aramasıyla birleştirildiğinde — hibrit arama olarak adlandırılan bu yöntem — hem anahtar kelime kesinliği hem anlamsal zenginlik sunar; kurumsal ölçekli belge arama ve chatbot sistemlerinde giderek standart mimari unsur haline gelmektedir.