AI Projelerinde Demo vs Production İllüzyonu: Olasılıksal Sistemlere Geçiş

·

AI projelerinde demo vs production farkını ve Kontrol Düzlemi (Control Plane) mimarisini gösteren teknik şema.
Okuma süresi 3 dakika

Problem: “Show Business” ve Politik İllüzyon

Kurumsal yapay zeka projelerinde 50 sayfalık temizlenmiş bir PDF ile kurulan demo, yönetim kurulundan alkış aldığında o en tehlikeli cümle kurulur: “Sistem çalışıyor.” Ancak gerçekte, ai projelerinde demo vs production arasındaki fark, bir kağıt uçakla yolcu uçağı arasındaki fark kadar büyüktür.

Çoğu kurumda bu cümlenin arkasındaki temel sorun teknik bir yetersizlik değil, politik bir tercihtir. AI hype’ının yarattığı baskı, şişirilmiş KPI’lar ve “yönetime bir şey gösterme” kültürü, kurumları bir illüzyonun içine çeker. Burada sorulması gereken asıl soru şudur: Eğer kurum demo üzerinden PR yapmaya odaklanmışsa, gerçekten canlı ortama (production) çıkmayı istiyor mu? Demo bir şov işidir; canlı ortam ise mühendislik ve risk yönetimidir. Gerçekten de ai projelerinde demo vs production sınırlarını birbirine karıştıran projeler, “Pilot Mezarlığı”nda (Pilot Purgatory) sessizce yok olmaya mahkumdur.

AI projelerinde demo vs production farkını ve Kontrol Düzlemi (Control Plane) mimarisini gösteren teknik şema.
Görsel 1: Model bir sistem değildir. Canlı ortam kaosu ancak bir Kontrol Düzlemi ile yönetilebilir.

AI Projelerinde Demo vs Production Farkı: MLOps Neden Yetersiz Kalır?

Canlı ortama geçişte ekiplerin düştüğü en büyük yanılgı, ellerindeki MLOps süreçlerinin bu yeni yapıyı yönetebileceğini sanmalarıdır. Burada net bir paradigma ayrımı yapmak gerekir:

  • Geleneksel Yazılım ve MLOps: Deterministiktir. Durum (state) yönetilebilir, hatalar kod bazlıdır ve sunucu sağlığı izlenerek sistem ayakta tutulabilir.
  • LLM Tabanlı AI Sistemleri: Olasılıksaldır (Probabilistic). Modele giren aynı prompt farklı sonuçlar üretebilir, sistem kod hatası fırlatmaz ama “semantik hatalar” (halüsinasyon) üretir.

İşte bu noktada devreye giren Kontrol Düzlemi (Control Plane), mevcut mikroservis mimarilerinin veya DevOps pratiklerinin yeni bir adı değildir; olasılıksal sistem yönetimi yaklaşımıdır. Amacı modeli değil, modelin kurumsal gerçeklikle olan ilişkisini orkestre etmektir.

Deterministik MLOps süreçleri ile LLM tabanlı olasılıksal sistemlerin Kontrol Düzlemi ihtiyacını karşılaştıran mimari şema.
Görsel 2: Deterministik yazılımlardan, olasılıksal sistemlere (Probabilistic Systems) geçiş.

Canlı Ortam Neden Kırılır? (3 Analitik Vaka)

AI projelerinde demo vs production çöküşlerinin temel nedeni sadece teknik bir yavaşlama (latency) değil, sistemin kurumsal gerçekliği temsil edememesi yani epistemolojik bir kırılma sorunudur.

  • Vaka 1: Çelişkili Politika Belgeleri (Version Drift)
    • Senaryo: Vektör veritabanında “2019 İK Politikası” ve “2024 Güncel Politika” bir arada duruyor. Kullanıcı yıllık izin gününü soruyor. Model, vektörel benzerliği daha yüksek olduğu için 2019 belgesinden cevap üretiyor.
    • Canlı Ortam Sonucu: Yanlış kurumsal bilgi, hukuki risk ve anında güven kaybı.
  • Vaka 2: Yetki İhlali (Veri Sızıntısı)
    • Senaryo: Finans uzmanı ile CEO’nun strateji dokümanları aynı index’te tutuluyor. Finans uzmanı “2025 şirket satın alma planları neler?” diye sorduğunda sistem doğru cevabı getiriyor.
    • Canlı Ortam Sonucu: Teknik olarak kusursuz bir “veri sızıntısı”.
  • Vaka 3: Ölçeklenme ve Dayanıklılık Çöküşü
    • Senaryo: Demoda tek kullanıcıyla 2 saniyede yanıt veren sistem, canlı ortamda 400 eşzamanlı kullanıcıyla karşılaştığında LLM servisinin “Rate Limit” (istek sınırı) engeline takılıyor.
    • Canlı Ortam Sonucu: Kilitlenen iş akışları ve düşen sistemler.

AI Projelerinde Demo vs Production İllüzyonu: Olasılıksal Sistemlere Geçiş

Elbette her “Proof of Concept” (PoC) veya şirket içi basit bir IT destek chatbot’u ilk günden devasa bir kontrol düzlemiyle tasarlanmak zorunda değildir. Aşırı mühendislik (over-engineering), inovasyon hızını boğabilir.

Ancak ai projelerinde demo vs production geçişinin en kritik noktası şudur: Sistem, regüle edilmiş bir sektörde karar destek mekanizması (knowledge-critical domain) olarak kullanılacaksa, canlı ortamda gerçekten “çalışıyor” diyebilmek için şu 3 teknik kriterin karşılanması zorunludur:

  1. Epistemolojik İzlenebilirlik (Kaynak İspatı): Sisteminizin ürettiği bir cevabı, hangi dokümanın, hangi versiyonunun, hangi parçasının (chunk) ürettiğini saniyeler içinde ispatlayabilmelisiniz. Bu mimari, versiyon kaymasını (version drift) engeller.
  2. Bağlamsal Yetki ve Güvenlik (RBAC-Aware Retrieval): Arama motoru, sorguyu yapan kullanıcının organizasyonel rolünü bilmeli ve sadece onun yetkisi dahilindeki vektörleri getirmelidir. Aksi takdirde veri sızıntısı kaçınılmazdır.
  3. Olasılıksal Dayanıklılık (Resilience): Sistem, anlık kullanıcı yığılmalarında dış LLM API’lerinin çökmelerine karşı Semantik Önbellekleme (Semantic Caching) ve Devre Kesici (Circuit Breaker) gibi dayanıklılık altyapılarıyla donatılmalıdır.
Yapay zeka projelerinin pilot mezarlığından çıkıp canlı ortama (production) geçmesi için gereken 3 teknik kriteri (izlenebilirlik, yetki, dayanıklılık) gösteren köprü diyagramı.
Görsel 3: Pilot mezarlığından (Pilot Purgatory) canlı ortama geçişi sağlayan mimari köprü.

“Eğer sisteminizin ürettiği bir cevabı, hangi dokümanın hangi versiyonunun hangi parçasının (chunk) ürettiğini saniyeler içinde ispatlayamıyorsanız; sisteminiz çalışmıyor, sadece ikna edici tahminlerde bulunuyordur.”

Mimari İlke

Özetle, ai projelerinde demo vs production ikilemini aşmanın yolu, “çalışan” bir demo yapmaktan değil, deterministik olmayan bir zekayı hesap verebilir bir kurumsal altyapıya dönüştürmekten geçer. Eğer bir sistemin epistemolojik sınırlarını, yetki haritasını ve performans kriterlerini net bir Kontrol Düzlemi üzerinden denetleyemiyorsanız, o sistemi canlı ortama almamalısınız.

Onur Akgün avatarı

Yazan

Yorumlar


Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir