AI Engineering Stack Karşılaştırması: Orkestrasyon, Deployment, Observability ve Evaluation Katmanları

Yapay zekâ projelerinde en sık görülen yanılgılardan biri, başarıyı tek bir modele, tek bir framework’e veya tek bir araca bağlamaktır. Oysa üretim seviyesinde çalışan gerçek bir AI sistemi, tekil araçlardan değil; birbiriyle uyumlu çalışan katmanlı bir mühendislik yığınından, yani AI engineering stack yapısından oluşur.

Bir organizasyon veri hazırlığını iyi yapıyor olabilir ama deployment tarafı zayıf olabilir. Model servisleme güçlü olabilir ama evaluation katmanı eksik olabilir. Observability mevcut olabilir ama orkestrasyon kırılgan olabilir. Bu nedenle üretimde değer yaratan sistemler, “en iyi aracı” seçenler değil; doğru katmanları doğru sorumluluklarla bir araya getirebilenler tarafından kurulur.

Bugün özellikle MLOps, LLMOps, RAG, agentic workflow ve üretken yapay zekâ sistemlerinin yaygınlaşmasıyla birlikte teknoloji kararları daha karmaşık hale geldi. Ekipler artık sadece “hangi modeli kullanalım?” sorusunu sormuyor. Aynı zamanda şu sorularla yüzleşiyor:

• Pipeline’ları neyle orkestre etmeliyiz?
• Model veya LLM servislerini nasıl dağıtmalıyız?
• Sistemin davranışını nasıl görünür hale getirmeliyiz?
• Kaliteyi nasıl sistematik biçimde değerlendirmeliyiz?
• Araçları ayrı ayrı değil, birlikte nasıl düşünebiliriz?

Bu yazıda, AI engineering stack’i dört ana omurga üzerinden inceleyeceğim: orkestrasyon, deployment, observability ve evaluation. Ancak bunu yalnızca araç isimleri düzeyinde değil; her katmanın hangi problemi çözdüğünü, diğer katmanlarla ilişkisini, seçim kriterlerini ve kurumsal ölçekte yapılan hataları ortaya koyan mimari bir bakışla ele alacağım.

AI engineering stack, bir yapay zekâ sisteminin veri alımından üretim davranışına kadar tüm yaşam döngüsünü destekleyen teknik katmanların bütünüdür. Bu yapı yalnızca model eğitimi veya model servisleme ile sınırlı değildir. Gerçek bir stack, veri akışlarını, pipeline yönetimini, model sürümlemeyi, üretim servislerini, izleme altyapısını, kalite ölçümünü, güvenlik kontrollerini ve yönetişim mekanizmalarını kapsar.

Buradaki kritik nokta şudur: AI engineering stack, bir araç listesi değildir. O, araçlar arasındaki görev dağılımını, veri ve kontrol akışını, işletim mantığını ve ekipler arası sorumluluk ayrımını ifade eden sistem tasarımıdır.

Sağlam bir stack şu sorulara net cevap vermelidir:

• Veri akışları nasıl tetikleniyor ve kim yönetiyor?
• Model veya LLM servisleri nasıl paketleniyor ve canlıya alınıyor?
• Üretimde hangi metrikler ve kalite sinyalleri izleniyor?
• Bir sürüm değişikliğinin kalite etkisi nasıl ölçülüyor?
• Bir problem oluştuğunda kök neden nasıl bulunuyor?
• Geri alma, yeniden eğitim veya prompt güncelleme nasıl yönetiliyor?

Birçok ekip teknoloji kararını araç merkezli verir. Örneğin güçlü bir orkestrasyon aracı bulduğunda problemin çözüldüğünü varsayar. Ya da gelişmiş bir observability platformu kullandığında sistemin artık güvenilir hale geldiğini düşünür. Gerçekte ise üretim AI sistemleri çok katmanlı bağımlılıklar üzerinden çalışır.

Örneğin orkestrasyon katmanı zayıfsa evaluation çıktıları zamanında üretilemez. Deployment standardı eksikse observability düzgün veri toplayamaz. Evaluation çerçevesi yoksa gözlemlenebilirlik sadece operasyonel metriklerle sınırlı kalır. Bu nedenle stack’i yatay ürün seçimi gibi değil, dikey sistem tasarımı gibi düşünmek gerekir.

"

Kritik gerçek: AI engineering stack’te doğru soru “hangi araç en iyi?” değil, “hangi katman hangi sorumluluğu almalı ve bu katmanlar birlikte nasıl çalışmalı?” sorusudur.

Her organizasyonda detaylar değişebilir; ancak üretim seviyesinde çoğu AI sistemi şu çekirdek katmanlar etrafında şekillenir:

1. Veri ve feature katmanı
2. Orkestrasyon katmanı
3. Eğitim / deney yönetimi katmanı
4. Deployment ve serving katmanı
5. Observability ve monitoring katmanı
6. Evaluation ve kalite katmanı
7. Security ve governance katmanı

Bu yazının odak noktası özellikle 2, 4, 5 ve 6 numaralı katmanlar olacak. Çünkü kurumsal AI sistemlerinin üretimde ayakta kalmasını en çok belirleyen mimari ayrım burada ortaya çıkar.

Orkestrasyon, AI sistemlerinin arka plan operasyon mantığını yönetir. Veri işleme işlerinin ne zaman başlayacağı, hangi pipeline adımının hangi bağımlılıkla çalışacağı, bir training sürecinin hangi şartlarda tetikleneceği, evaluation’ın ne zaman koşacağı ve başarısızlık durumunda ne yapılacağı gibi kritik kararlar bu katmandadır.

Bir orkestrasyon katmanı temelde şu problemleri çözer:

• İş akışlarının zamanlanması
• Adımlar arası bağımlılık yönetimi
• Başarısız adımlarda retry ve failover
• Parametrik pipeline çalıştırma
• Batch ve event-driven akış ayrımı
• Loglama ve yürütme görünürlüğü

Orkestrasyon Katmanında İyi Tasarım Ne Demektir?

İyi bir orkestrasyon tasarımı, pipeline’ları yalnızca otomatikleştirmez; aynı zamanda görünür, yeniden çalıştırılabilir, izlenebilir ve sürdürülebilir hale getirir. Buradaki temel amaç “job çalıştırmak” değil; kurumsal akışları deterministik ve operasyonel olarak güvenli hale getirmektir.

En Sık Yapılan Hatalar

• Pipeline mantığını uygulama kodu içine gömmek
• Tüm akışı tek bir dev job haline getirmek
• Retry stratejilerini tanımlamamak
• Bağımlılıkları görünmez bırakmak
• Batch ve real-time ihtiyaçlarını aynı mantıkla çözmeye çalışmak

Orkestrasyon Seçim Kriterleri

• Akışların karmaşıklık düzeyi
• Zaman tabanlı mı event tabanlı mı olduğu
• Takımın bakım kapasitesi
• Gözlemlenebilirlik ve retry gereksinimi
• Data pipeline ile ML pipeline’ın ne kadar iç içe olduğu

Burada kritik olan, orkestrasyonu yalnızca “zamanlayıcı” gibi değil; AI sisteminin operasyonel sinir sistemi gibi görmektir.

Deployment katmanı, eğitilmiş modelin, retrieval tabanlı sistemin veya LLM uygulamasının gerçek kullanıcılar ve sistemlerle buluştuğu noktadır. Ancak deployment yalnızca bir container çalıştırmak değildir. Gerçek kurumsal deployment; versiyonlama, trafik kontrolü, rollback, ölçeklenebilirlik, latency yönetimi, çevresel konfigürasyonlar ve release güvenliği gerektirir.

Deployment Katmanının Çözdüğü Temel Problemler

• Modelin üretimde erişilebilir hale getirilmesi
• Sürüm geçişlerinin kontrollü yapılması
• Staging ve production ayrımının korunması
• Canary, shadow veya A/B rollout stratejileri
• Rollback ve incident yönetimi
• Batch scoring ile real-time inference ayrımı

Model Deployment ile LLM Deployment Arasındaki Fark

Klasik makine öğrenmesi deployment’ında çoğu zaman giriş-çıkış yapısı daha nettir. Buna karşılık LLM deployment daha karmaşık hale gelebilir; çünkü prompt yönetimi, context assembly, retrieval, tool use, policy enforcement ve token maliyeti gibi ek katmanlar devreye girer. Bu nedenle LLM deployment, çoğu zaman basit bir model serving probleminden çok sistem serving problemine dönüşür.

Deployment Katmanında En Sık Hatalar

• PoC kodunu doğrudan canlıya taşımak
• Versiyon ve release stratejisini net tanımlamamak
• Rollback planı olmadan dağıtım yapmak
• Batch ve online kullanım senaryolarını karıştırmak
• Latency ve cost dengesini deployment tasarımına yansıtmamak

Deployment Seçim Kriterleri

• İstek hacmi ve SLA beklentisi
• Real-time gereksinim düzeyi
• Güvenlik ve veri yerleşim gereksinimleri
• Model mi servisleniyor, yoksa tam bir LLM workflow mu?
• Yüksek kullanılabilirlik ve rollback zorunluluğu

Deployment katmanı güçlü değilse, model ne kadar iyi olursa olsun sistem kurumsal kaliteye ulaşamaz.

Observability, üretimde çalışan AI sisteminin davranışını görünür hale getiren katmandır. Buradaki amaç sadece sistem sağlığını ölçmek değil; aynı zamanda sistemin neden belli bir şekilde davrandığını anlayabilmektir. Bu yüzden observability, monitoring’den daha geniş bir disiplindir.

İyi bir observability katmanı şu sorulara cevap verir:

• Hangi istekler hata üretiyor?
• Hangi sürümden sonra kalite düşüşü başladı?
• Latency artışı retrieval katmanından mı, modelden mi, ağdan mı kaynaklanıyor?
• Hangi segmentlerde bozulma var?
• Hangi prompt veya workflow daha maliyetli çalışıyor?

Observability’nin Ana Bileşenleri

• Metrikler
• Loglar
• Trace’ler
• İstek-akış görünürlüğü
• Segment bazlı kırılımlar
• Uyarı ve alarm sistemleri

Klasik Observability ile AI Observability Arasındaki Fark

Klasik yazılım observability’si çoğu zaman servis ayakta mı, hata oranı ne, latency ne seviyede gibi metriklere odaklanır. AI observability ise buna ek olarak şu boyutları da taşır:

• Veri drift ve schema değişimi
• Skor veya çıktı dağılımı kaymaları
• Prompt versiyonu etkisi
• Retrieval kalitesi
• Token maliyeti
• Segment bazlı kalite düşüşü
• İnsan müdahalesi veya override pattern’leri

Observability Katmanında En Sık Hatalar

• Sadece altyapı metrikleri toplamak
• Prompt, retrieval veya model versiyonunu loglamamak
• İş metriği ile teknik metriği bağlamamak
• Global ortalamalara güvenmek
• Alarm tasarımını rastgele yapmak

Observability eksik olduğunda sistemin bozulduğunu çok geç anlarsınız. Daha kötüsü, bozulduğunu anlasanız bile nedenini bulamazsınız.

AI engineering stack’in en kritik ama en eksik kurulan katmanlarından biri evaluation’dır. Çünkü birçok ekip kaliteyi ya demo hissiyle ya da tek bir offline metrikle değerlendirmeye çalışır. Oysa production seviyesinde evaluation; sürüm karşılaştırma, regresyon tespiti, kalite eşiği belirleme ve release kararının temelini oluşturur.

Evaluation Katmanının Temel Sorumlulukları

• Başarı metriklerini tanımlamak
• Test veri setlerini ve benchmark setlerini yönetmek
• Sürüm karşılaştırmaları yapmak
• Regresyonları görünür kılmak
• Gerçek dünya görev başarımını ölçmek
• Canlıya alma kararına kalite zemini sağlamak

Klasik Model Evaluation ile LLM Evaluation Farkı

Klasik ML sistemlerinde doğruluk, hata oranı veya skor tabanlı metrikler daha doğrudan çalışabilir. LLM sistemlerinde ise cevapların birden fazla geçerli biçimi olabilir. Bu da evaluation katmanını çok daha zengin hale getirir. Rubric tabanlı değerlendirme, insan incelemesi, groundedness, faithfulness, retrieval relevance ve task success gibi ek ölçümler devreye girer.

Evaluation Katmanında En Sık Hatalar

• Test veri seti oluşturmamak
• İş hedefiyle ilgisiz metriklere odaklanmak
• Üretim değişikliklerini regresyon testinden geçirmemek
• LLM sistemlerinde yalnızca “çıktı güzel mi?” hissine güvenmek
• İnsan değerlendirmesini hiç kurmamak veya tamamen manuel bırakmak

Evaluation katmanı eksikse deployment katmanı kördür. Çünkü neyi canlıya aldığınızı teknik olarak biliyor olsanız da kalite açısından neyi canlıya aldığınızı tam olarak bilmiyorsunuzdur.

Hayır. En kritik mimari gerçeklerden biri şudur: Bu katmanlar tek başına değil, birbirini besleyerek çalışır.

Örneğin:

• Orkestrasyon olmadan evaluation pipeline’ları sürdürülebilir çalışmaz.
• Deployment standardı olmadan observability tutarlı veri toplayamaz.
• Observability olmadan evaluation sonuçlarını üretim davranışıyla eşleştirmek zorlaşır.
• Evaluation olmadan deployment kararları öznel kalır.
• Bu dört katman güçlü değilse governance ve rollback sağlıklı işlemez.

Bu yüzden AI engineering stack’i modüler ama kopuk olmayan bir yapı olarak düşünmek gerekir. Her katman ayrı sorumluluk taşır, ancak gerçek değer bu katmanların koordinasyonundan doğar.

Katman	Ana Sorumluluk	Temel Soru	En Büyük Risk
Orkestrasyon	Akışların, bağımlılıkların ve zamanlamanın yönetimi	Ne, ne zaman, hangi sırayla çalışacak?	Kırılgan ve görünmez iş akışları
Deployment	Model veya sistemin canlıya güvenli alınması	Bu sistemi güvenli ve kontrollü biçimde nasıl servisleyeceğiz?	Rollback’siz, ölçeklenemez servis yapısı
Observability	Davranışın, performansın ve bozulmaların görünür hale getirilmesi	Sistem gerçekte nasıl davranıyor?	Geç fark edilen sorunlar ve kök neden belirsizliği
Evaluation	Kalitenin ölçülmesi ve sürüm kararlarının desteklenmesi	Sistem gerçekten yeterince iyi mi?	Öznel kalite kararları ve sessiz regresyon

Kurumsal ekipler teknoloji seçimi yaparken çoğu zaman aşağıdaki mimari hatalara düşer:

1. Araçları katmanlardan önce düşünmek
   İhtiyaç haritası çıkmadan ürün seçmek.
2. Tek bir aracı her problem için yeterli görmek
   Örneğin orchestration aracından evaluation beklemek.
3. Orkestrasyonu uygulama koduyla karıştırmak
   Akış mantığını servis içinde saklamak.
4. Observability’yi sadece monitoring zannetmek
   Derin kök neden analizi yeteneğini kurmamak.
5. Evaluation’ı canlı sonrası konu olarak görmek
   Release kalitesini şansa bırakmak.
6. Deployment’ı yalnızca container çalıştırmak zannetmek
   Versiyon, rollout ve rollback katmanını ihmal etmek.
7. Katmanlar arası veri akışını standartlaştırmamak
   Her ekip kendi formatıyla ilerlediğinde sistem görünmez hale gelir.

Tüm organizasyonlar aynı derinlikte stack kurmak zorunda değildir. Mimari kararlar; ölçek, regülasyon, kullanım yoğunluğu, ekip kapasitesi ve risk düzeyine göre şekillenir.

Küçük ve Erken Aşama Ekipler

Daha yalın ve modüler yaklaşım uygundur. Burada amaç her katman için ağır kurumsal süreçler değil, temel görünürlük ve sürdürülebilirliği hızlıca sağlamaktır. Ancak bu aşamada bile evaluation ve observability hiç kurulmadan ilerlemek uzun vadede sorun üretir.

Orta Ölçekli Ürün Ekipleri

Burada deployment ve observability kritikleşir. Çünkü kullanıcı hacmi artar, sürüm geçişleri hızlanır, kalite dalgalanmaları daha görünür hale gelir. Orkestrasyon ve evaluation bu aşamada standardize edilmelidir.

Büyük ve Regülasyonlu Kurumlar

Bu yapılarda stack yalnızca teknik değil; aynı zamanda yönetişimsel bir mimaridir. Audit trail, risk sınıflandırması, rollback, veri erişim kontrolü ve kalite eşikleri gibi unsurlar zorunlu hale gelir. Stack tercihi burada bakım kolaylığından çok denetlenebilirlik ve kurumsal kontrol ekseninde şekillenir.

En doğru karar, ürün veya araç karşılaştırmasından önce sorumluluk haritası çıkarılarak verilir. Benim önerdiğim çerçeve şu sırayla ilerler:

1. Önce kullanım senaryosunu netleştir

Batch ML mi, real-time inference mı, RAG mi, LLM workflow mu, agentic system mi? Her yapı aynı stack derinliğini gerektirmez.

2. Ardından risk ve kalite ihtiyaçlarını tanımla

Sistem ne kadar kritik? Hataların iş etkisi ne? İnsan onayı gerekiyor mu?

3. Sonra ekip kapasitesini ve bakım gerçekliğini değerlendir

En gelişmiş araç her zaman en doğru seçenek değildir. Ekip sürdüremeyeceği bir stack kurmamalıdır.

4. Katmanlar arası veri ve kontrol akışını çiz

Orkestrasyon hangi olayları tetikleyecek? Deployment hangi sinyalleri observability’ye gönderecek? Evaluation nasıl release kararını etkileyecek?

5. Son olarak teknoloji seçimini yap

Teknoloji, mimarinin sonucu olmalıdır; mimarinin sebebi değil.

• Orkestrasyon katmanında bağımlılıklar ve retry stratejileri tanımlı mı?
• Deployment sürecinde staging, canary veya rollback mekanizması var mı?
• Observability katmanında model/prompt/retrieval sürümü görünür mü?
• Evaluation için test setleri ve regresyon kontrolleri tanımlı mı?
• Teknik metriklerle iş metrikleri arasında bağ kurulmuş mu?
• Katmanlar arası veri akışları standartlaştırılmış mı?
• Alarm ve müdahale süreçlerinin sahipliği net mi?
• Stack’in her parçası ekip tarafından sürdürülebilir mi?

İlk 30 Gün: Mevcut Yığını Haritala

• Mevcut veri, pipeline, deployment ve izleme yapısını çıkar
• Katman eksiklerini ve çakışmaları belirle
• Hangi problemin hangi katmanda çözüldüğünü netleştir
• İlk kritik boşlukları önceliklendir

31-60 Gün: Çekirdek Katmanları Standardize Et

• Orkestrasyon akışlarını görünür hale getir
• Deployment release mantığını tanımla
• Observability dashboard’unu kur
• Evaluation test seti ve kalite eşiğini belirle

61-90 Gün: Katmanlar Arası İşletim Disiplini Kur

• Release kararını evaluation çıktısına bağla
• Observability sinyallerini incident yönetimine bağla
• Retraining veya rollback karar akışını netleştir
• İlk referans AI engineering stack standardını kurumsallaştır

AI engineering stack’i doğru anlamanın en önemli yolu, onu araç koleksiyonu olarak değil; birbirini tamamlayan işletim katmanları olarak görmektir. Orkestrasyon sistemin akışını yönetir. Deployment sistemi güvenli şekilde canlıya taşır. Observability davranışı görünür kılar. Evaluation kaliteyi karar seviyesine taşır. Bu katmanlardan biri eksik olduğunda üretimdeki zayıflık hızla büyür.

Gerçek kurumsal olgunluk, her katman için “en popüler aracı” seçmekten değil; doğru sorumluluk haritasını kurup bu katmanların birlikte nasıl çalışacağını netleştirmekten doğar. Uzun vadede ayakta kalan AI organizasyonları, teknoloji karmaşasını azaltıp mimari açıklığı artırabilen organizasyonlardır.

Sonuç olarak doğru AI engineering stack, yalnızca sistemleri çalıştırmaz; aynı zamanda sistemleri anlaşılır, ölçülebilir, güvenilir ve yönetilebilir hale getirir. Üretim seviyesinde fark yaratan da tam olarak budur.

AI engineering stack ile MLOps stack aynı şey mi?

Hayır. MLOps stack daha çok klasik makine öğrenmesi yaşam döngüsüne odaklanır. AI engineering stack ise ML, LLM, RAG, agentic systems ve üretim operasyonlarını daha geniş bir çerçevede kapsar.

Her ekip tüm katmanları ayrı ayrı kurmalı mı?

Hayır. Katmanların mantıksal olarak ayrılması önemlidir, ancak aynı araç veya platform birden fazla katmanda rol alabilir. Önemli olan görevlerin ve sınırların net olmasıdır.

En kritik katman hangisidir?

Tek bir katman seçmek doğru değildir. Ancak üretimde en sık kırılma noktaları genellikle deployment, observability ve evaluation eksikliğinde ortaya çıkar. Orkestrasyon ise bu yapının sürdürülebilirliğini belirler.

Evaluation olmadan observability yeterli olur mu?

Hayır. Observability sistem davranışını gösterir, evaluation ise bu davranışın ne kadar iyi veya kabul edilebilir olduğunu ölçer. Birlikte çalışmaları gerekir.

Stack kararı verirken araç mı, ihtiyaç mı önce gelmeli?

Her zaman ihtiyaç, kullanım senaryosu, risk ve ekip kapasitesi önce gelmelidir. Araç seçimi bu çerçevenin sonucu olmalıdır.