AI Projeleri Neden Demo ile Üretim Arasında Ölüyor?

Enterprise şirketlerde AI entegrasyonu konusunda kafa karışıklığı artık istisna değil, oldukça yaygın bir durum. Yönetim tarafında büyük beklentiler oluşuyor, teknik ekip birkaç hafta içinde etkileyici bir demo çıkarıyor ve ilk kullanıcılar sistemin potansiyelinden heyecanlanıyor. Sonra production yaklaşınca tablo değişiyor: maliyet büyüyor, latency artıyor, güvenlik soruları ortaya çıkıyor, retrieval kalitesi dalgalanıyor, kullanıcı sayısı yükselince sistem aynı şekilde davranmıyor ve proje giderek “pilot” statüsünde sıkışıyor.

Bu yalnızca sahada gördüğüm bir örüntü değil. Gartner’ın 2024 AI Mandates for the Enterprise araştırmasında generative AI prototiplerinin ortalama yalnızca %41’inin production’a geçtiği raporlanıyor.[1] Gartner ayrıca GenAI projelerinin proof-of-concept sonrasında terk edilmesinde düşük veri kalitesi, yetersiz risk kontrolleri, artan maliyetler ve belirsiz iş değerini temel nedenler arasında gösteriyor.[2] McKinsey de 150’den fazla şirketle yürüttüğü çalışmalarda prototype’tan production’a geçişin özellikle risk, compliance, tekrar eden geliştirme ve maliyet aşımı nedeniyle tıkandığını belirtiyor.[3]

Sorunun önemli kısmı AI modelinin yetersiz olması değil. Çoğu zaman modelin etrafındaki sistem yeterince tasarlanmamış oluyor.

Demo yapmak kolaydır. Production sistemi tasarlamak başka bir iştir

İncelediğim birçok kurumda başlangıç örüntüsü birbirine benziyor. Şirket içinde AI konusuna en meraklı early-adopter developer’lar dokümantasyon, örnek repository’ler, YouTube videoları ve model desteğiyle kısa sürede çalışan bir MVP oluşturuyor. Bu yaklaşım kötü değildir; inovasyon çoğu zaman böyle başlar. Problem, demo mimarisinin fark edilmeden production mimarisi gibi ele alınmasıdır.

Bir demo için “çalışıyor mu?” sorusu yeterli olabilir. Production için ise aynı anda şu soruların cevaplanması gerekir: sistem kaç kullanıcıyı kaldıracak, her isteğin gerçek maliyeti nedir, hangi veri kime gösterilebilir, retrieval hatası nasıl ölçülecek, bir model veya embedding sürümü değiştiğinde ne olacak, doküman güncellendiğinde index nasıl senkronize edilecek, latency hangi yüzde diliminde kabul edilebilir, audit ve observability nasıl yapılacak?

NIST’in Generative AI Risk Management Profile’ı da generative AI sistemlerinin yalnızca model düzeyinde değil, tüm yaşam döngüsü boyunca govern, map, measure ve manage edilmesini öneriyor.[4] Yani production AI, bir API çağrısı değil; ölçülebilir ve yönetilebilir bir sistemdir.

RAG kuruyorsanız, vector database seçmek sadece ilk karardır

Kurumsal AI projelerinde ilk kullanım alanlarından biri şirket verisine erişimdir. Bu noktada RAG doğal bir seçenek haline gelir. RAG yaklaşımının temel fikri, modelin yalnızca parametrelerinde tuttuğu bilgiye güvenmek yerine harici bir bilgi kaynağından ilgili içeriği retrieve ederek generation aşamasını bu bağlamla beslemektir. Lewis ve arkadaşlarının NeurIPS 2020 çalışması RAG’in temel mimarisini parametric ve non-parametric memory’nin birlikte kullanımı olarak ortaya koydu.[5]

Ancak “bir vector database seçip dokümanları embed etmek” production RAG tasarımı değildir. Daha indexleme başlamadan önce çok sayıda karar vardır:

Dokümanları hangi parser ile okuyacaksınız?
Chunk boyutu sabit mi olacak, semantik mi olacak, parent-child ilişkisi tutulacak mı?
Dense, sparse veya hybrid retrieval mı kullanılacak?
Metadata filtering ve tenant isolation nerede uygulanacak?
Reranking gerekli mi?
Embedding modeli hosted API mi, open-source local model mi olacak?
Index güncelleme, silme, versioning ve rollback nasıl çalışacak?
Retrieval başarısını recall@k, precision, groundedness veya task-level evaluation ile nasıl ölçeceksiniz?

RAG literatüründeki güncel survey’ler de sistemi pre-retrieval, retrieval, post-retrieval ve generation gibi ayrı katmanlarda ele alıyor; performansın tek bir component seçimine indirgenemeyeceğini gösteriyor.[6]

“AI böyle önerdi” bir architecture decision değildir

Bir developer modele “dokümanlarımı RAG’e nasıl eklerim?” diye sorduğunda model sıklıkla standart bir recipe üretir: dokümanı parçala, bir embedding modeli seç, vector database’e yaz, query geldiğinde benzer parçaları getir ve LLM’e gönder.

Bu recipe yanlış değildir. Fakat şirketiniz için doğru mimari olduğu anlamına da gelmez.

Örneğin bir hosted embedding API kullandığınızda süreç document processing ile bitmez. Parser ve chunking sonrasında oluşan metin parçaları embedding servisine ayrı API çağrılarıyla gönderilir ve vektörlere çevrilir. Bu, daha sonra agent veya generation modeline yapılacak LLM çağrılarından bağımsız bir ücret kalemidir: embedding sağlayıcıları embed edilen token miktarını ayrıca faturalandırabilir. OpenAI’nin embedding modelleri input token miktarına göre fiyatlanır.[7] Cohere de embedding maliyetini embedded token miktarı üzerinden açıklar.[8] Yani kullanıcı daha ilk sorusunu sormadan bile ingestion pipeline’ında embedding maliyeti oluşabilir. Büyük doküman koleksiyonlarında, sık re-indexing yapılan yapılarda veya çok tenant’lı sistemlerde hosted API, local embedding, batch inference ve incremental indexing seçenekleri arasındaki karar toplam maliyeti doğrudan etkiler. Asıl problem, alternatifler değerlendirilmeden ilk çalışan çözümün mimariye dönüşmesidir.

Buradaki engineering görevi “hangi tool popüler?” sorusuna cevap vermek değil; kalite, latency, throughput, veri hassasiyeti, operasyonel yük ve toplam sahip olma maliyeti arasında doğru trade-off’u kurmaktır.

En pahalı hata: aynı işi birkaç kez LLM’e yaptırmak

AI sistemlerinde maliyet problemlerinin önemli bir kısmı model fiyatından değil, orchestration tasarımından doğar.

Sık gördüğüm bir pattern şu: kullanıcı mesajı önce intent detection için bir LLM’e gider; sonra output schema seçmek için ikinci bir LLM çağrılır; ardından query rewrite yapılır; retrieval’dan gelen veri başka bir model tarafından özetlenir; en sonunda asıl agent cevabı üretir. Kullanıcı tek bir soru sormuştur ama sistem arka planda üç, dört veya beş generation çağrısı yapmıştır.

Bazı uygulamalarda bu adımlar gerçekten gereklidir. Ancak her ara kararı LLM’e devretmek iyi architecture değildir. Eğer modelin bilmesi gereken intent setini, veri yapısını, tool açıklamalarını ve karar sınırlarını ana prompt içinde açıkça tanımlayabiliyorsanız, model çoğu zaman retrieval sonucunu yorumlayıp doğru tool veya response davranışını tek reasoning akışında gerçekleştirebilir. Deterministic kararlar ise mümkün olduğunda kod, metadata veya policy katmanında tutulmalıdır.

Bu zincirin maliyet etkisi doğrudandır. Her LLM invoke kendi input ve output tokenlarını işler ve sağlayıcı tarafından ayrı bir inference çağrısı olarak ücretlendirilir.[9] Örneğin tek bir kullanıcı isteğini çözmek için intent detection, schema selection ve final answer olmak üzere üç benzer LLM invoke yapıyorsanız, generation katmanındaki maliyet tek invoke’lık bir tasarıma kıyasla yaklaşık üç katına çıkabilir. Context boyutları veya output uzunlukları büyüdükçe gerçek fark daha da açılabilir. Üstelik maliyet yalnızca para değildir: her ek invoke yeni bir network round-trip, daha yüksek tail latency ve daha düşük concurrency headroom demektir. LLM serving literatürü throughput ile latency arasındaki ilişkinin özellikle yüksek eşzamanlılıkta kritik olduğunu gösteriyor. vLLM’in PagedAttention çalışmasında memory management ve batching iyileştirmelerinin aynı latency seviyesinde throughput’u 2–4 kat artırabildiği gösterildi.[10] Bunun tersinden çıkarılacak ders nettir: request başına gereksiz model çağrıları eklemek production kapasitesini doğrudan tüketir.

flowchart LR
    U["User request"] --> A["Intent LLM"]
    A --> B["Schema LLM"]
    B --> C["Query rewrite LLM"]
    C --> R["Retrieval"]
    R --> D["Summarization LLM"]
    D --> E["Final agent LLM"]
    E --> O["Answer"]

Bu zincirde her blok ayrı bir fayda kanıtlamalıdır. “Agentic” görünmesi, gerekli olduğu anlamına gelmez.

Daha yalın bir tasarım çoğu enterprise use case için şöyle başlayabilir:

flowchart LR
    U["User request"] --> P["Policy + context assembly"]
    P --> R["Retrieval / tools"]
    R --> M["Main model"]
    M --> O["Answer + citations"]

İhtiyaç kanıtlandıkça router, reranker, validator veya specialist agent eklenir. Tersi değil.

Maliyet neden demo aşamasında görünmez?

Bir geliştirici günde 30 sorgu yaptığında pahalı bir mimari bile ucuz görünebilir. Aynı sistemi yüzlerce çalışanın kullandığını, her soruda uzun context gönderildiğini, üç ayrı LLM çağrısı yapıldığını ve cevapların tekrar üretildiğini düşündüğünüzde economics değişir.

Bu nedenle AI maliyeti aylık API faturası olarak değil, cost per successful task olarak izlenmelidir. Bir cevabın model maliyeti düşük olabilir; fakat retrieval hatalıysa, kullanıcı tekrar soru soruyorsa veya insan doğrulaması uzun sürüyorsa gerçek iş değeri düşer. Aynı şekilde daha pahalı bir model, task completion oranını ciddi biçimde artırıyorsa toplam süreç açısından daha ucuz olabilir.

Bu nokta productivity araştırmalarıyla da uyumludur. Brynjolfsson, Li ve Raymond’un 5.179 müşteri destek çalışanı üzerinde yaptığı saha araştırmasında generative AI desteği ortalama productivity’yi %14 artırırken, daha az deneyimli çalışanlarda kazanım %34’e ulaşmıştır; deneyimli çalışanlarda ise etki çok daha sınırlıdır.[11] Yani “AI yüzde X verim kazandırır” diye evrensel bir sayı yoktur. Değer, use case’e, kullanıcı grubuna ve süreç tasarımına bağlıdır.

İkinci büyük sorun: AI algısı ile gerçek sistem davranışı arasındaki fark

Kurumsal AI projelerinde teknik mimari kadar tehlikeli başka bir konu daha var: beklenti mimarisi.

Frontier model şirketlerinin AGI, reasoning ve autonomous agents etrafındaki iddiaları, AI’ın zihinlerde olasılıksal bir inference engine’den ziyade her işi yapabilen genel bir süper güç gibi algılanmasına yol açabiliyor. Bir demo da bu algıyı güçlendiriyor çünkü demo genellikle iyi seçilmiş veri, kontrollü prompt ve sınırlı kullanıcı davranışı altında gösteriliyor.

Production ise edge case’lerden oluşur.

Kullanıcı eksik soru sorar. Dokümanlar çelişir. Yetkiler değişir. Bir tool timeout verir. Model yanlış confidence sergiler. Prompt injection denenir. Bir departman diğerinin verisini görmemelidir. “%95 doğru” görünen bir demo, kritik %5 hata belirli bir iş akışında kabul edilemez olduğunda kullanılamaz hale gelir.

Bu nedenle C-level beklentileri, AI’ın teknik kapasitesi ve şirketin kendi veri/süreç gerçekliği arasında daha proje başlamadan alignment yapılmalıdır. NIST’in AI RMF yaklaşımındaki “Map” ve “Measure” mantığı da sistemi kullanım bağlamında tanımlamayı ve ölçülebilir kriterlerle değerlendirmeyi merkezine alır.[12]

Gerçek AI engineering ilk müşteri görüşmesinde başlar

İyi bir AI engineer veya architect’in görevi müşterinin istediği sistemi doğrudan kodlamaya başlamak değildir. İlk iş, beklenti ile teknik ve ekonomik gerçeklik arasındaki farkı görünür hale getirmektir.

İlk discovery görüşmelerinden sonra en azından şu sorular cevaplanabilmelidir:

İş problemi nedir? AI olmadan bugün nasıl çözülüyor ve hangi maliyet oluşuyor?
Başarı nasıl ölçülecek? Accuracy değil; task completion, time saved, cost per task, escalation rate, groundedness veya revenue impact gibi hangi metric iş değerini temsil ediyor?
Veri gerçekten hazır mı? Kaynaklar güncel, erişilebilir, versioned ve yetkilendirilebilir mi?
Risk seviyesi nedir? Yanlış cevabın maliyeti nedir ve human-in-the-loop nerede gerekir?
En küçük yeterli mimari nedir? Tek model + tool layer yeterli mi, yoksa RAG, reranking, agent routing veya specialist modeller gerçekten gerekli mi?
Economics nasıl davranıyor? 10 kullanıcıdan 1.000 kullanıcıya çıkıldığında token, inference, storage ve observability maliyeti nasıl değişiyor?
Exit criteria nedir? Pilot hangi koşullarda production’a geçecek, hangi koşullarda durdurulacak?

Bu çalışma yapılmadan başlatılan AI projesi, teknik bir experiment ile business investment arasındaki farkı ortadan kaldırır.

AI projesine başlamadan önce fizibilite yapın

Bir AI projesinin en pahalı noktası başarısız olması değildir. En pahalı nokta, başarısız olacağını aylar sonra öğrenmektir.

Production öncesi fizibilite çalışması en az dört katmanı birlikte değerlendirmelidir:

Value feasibility: Çözülen problem yeterince değerli mi ve başarı ölçülebilir mi?
Data feasibility: Gerekli veri erişilebilir, kaliteli, güncel ve doğru izin modeliyle kullanılabilir mi?
Technical feasibility: Gerekli accuracy, latency, throughput ve entegrasyon seviyesi gerçekçi mi?
Economic feasibility: Kullanım ölçeğinde inference, retrieval, storage, observability ve insan kontrol maliyeti kabul edilebilir mi?

Bunlara regulated veya high-risk alanlarda governance ve compliance fizibilitesi de eklenmelidir.

Gartner’ın bulguları da bu yaklaşımı destekliyor: prototype’tan production’a geçemeyen projelerin temel nedenleri çoğu zaman model benchmark’ı değil; veri, risk, maliyet ve iş değeridir.[13]

Sonuç: model seçmeden önce sistemi düşünün

Enterprise AI projeleri genellikle model yeterince zeki olmadığı için ölmez. Yanlış problem seçildiği, demo mimarisi production’a taşındığı, gereksiz LLM çağrılarıyla maliyet ve latency büyüdüğü, retrieval ve authorization tasarımı sonradan düşünüldüğü veya yönetim beklentileri ölçülebilir bir business case ile hizalanmadığı için ölür.

İyi bir demo size “bu mümkün” der.

İyi bir fizibilite çalışması ise çok daha önemli dört soruya cevap verir: Bunu yapmalı mıyız? Hangi mimariyle yapmalıyız? Ölçeklendiğinde neye mal olacak? Başarılı olduğunu nasıl anlayacağız?

Production-grade AI engineering tam olarak burada başlar.

Kaynaklar

Gartner, AI Maturity Matters: Proportion of AI and GenAI Prototypes Making It Into Production (2025). Kaynak
Gartner, Why 50% of GenAI Projects Fail — And How to Beat the Odds (2026). Kaynak
McKinsey, Overcoming two issues that are sinking gen AI programs (2025). Kaynak
Autio et al., NIST AI 600-1, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile (2024). Kaynak
Lewis et al., Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, NeurIPS 2020. Kaynak
Huang & Huang, A Survey on Retrieval-Augmented Text Generation for Large Language Models (2024). Kaynak
OpenAI, text-embedding-3-small model documentation. Kaynak
Cohere, How does Cohere pricing work? Kaynak
OpenAI, GPT-5.4 model documentation. Kaynak
Kwon et al., Efficient Memory Management for Large Language Model Serving with PagedAttention (2023). Kaynak
Brynjolfsson, Li & Raymond, Generative AI at Work, NBER Working Paper 31161; later published in QJE (2025). Kaynak
NIST, AI Measurement and Evaluation. Kaynak
Gartner, Gartner Predicts 30% of Generative AI Projects Will Be Abandoned After Proof of Concept by End of 2025 (2024). Kaynak