Yapay zekâ deyince hâlâ çoğu kişinin aklına büyük laboratuvarlar, pahalı GPU kümeleri ve biraz da sisli bir “kara kutu” geliyor. Açık konuşayım — ben de 2023’ün sonlarına kadar konuya biraz böyle bakıyordum. Sonra İstanbul’da bir startup ekibinde danışmanlık verirken, iki haftada çalışan bir prototipin nasıl gayet gerçek bir ürüne dönüştüğünü bizzat izleyince fikrim değişti. İşin aslı şu: artık mesele “AI var mı yok mu?” değil, “hangi katmanda neyi kullanacağım?” sorusu.
Bu yazıda o yığını parçalarına ayırıp biraz daha sindirilebilir hale getirmeye çalışacağım. Hani marketten rastgele malzeme alıp yemek yapmaya kalkmak vardır ya — AI stack kurmak tam olarak buna benziyor. Elinizde model var, orkestrasyon var, veri var, güvenlik var; ama bunları doğru sıraya koymazsanız ortaya lezzetli bir şey çıkmıyor. Bazen de tam tersi oluyor. İlginç, değil mi? Küçük ama düzgün kurulmuş bir yapı, devasa görünen sistemleri kolayca cebinden çıkarabiliyor.
Bakın, burayı atlarsanız yazının kalanı anlamsız kalır.
AI stack neden şimdi önemli?
Eh, Geçen mart ayında Kadıköy’de bir ürün toplantısında ilginç bir şeye şahit oldum. Ekip “bir chatbot yapalım” diye başladı. Üç hafta sonra? Konu müşteri destek otomasyonu, doküman arama ve iç bilgi tabanı özetleme işine döndü. Klasik örnek bu: başlangıçta oyuncak gibi görünen şey, doğru kurgulanınca ciddi operasyon yükü azaltıyor.
Buradaki hayati nokta şu — tek başına model almak yetmiyor. Modeli uygulamaya bağlamadığınız sürece elinizde sadece çok zeki ama boş duvara bakan bir motor kalıyor (ben de ilk duyduğumda şaşırmıştım). Gerçek ürün hissi; prompt düzeniyle, veri çekmeyle, loglama ile. Bazen de küçük ama can sıkıcı güvenlik önlemleriyle geliyor. Hepsi bir arada olmak zorunda.
Bakın, Bir de maliyet meselesi var tabii. Küçük bir startup (belki yanılıyorum ama) için API üzerinden hızlı başlamak mantıklı olabilir; kurumsal tarafta ise veri kontrolü. Denetlenebilirlik daha ağır basıyor. Benim gözlemim şu: ekipler ilk aşamada hız istiyor, ikinci aşamada faturayı görünce irkiliyor… üçüncü aşamada ise hibrit mimariye geçiyor. Neredeyse her seferinde böyle oluyor (en azından benim deneyimim böyle)
Evet, doğru duydunuz.
Temel model katmanı: Kirala mı kur mu?
İşin kalbi burada atıyor. GPT-4 sınıfı kapalı — kendi adıma konuşayım — API’ler mi kullanacaksınız, yoksa Llama 3 ya da Mistral gibi açık modelleri mi koşturacaksınız? Cevap tek değil. Eğer pazara hızlı çıkmanız gerekiyorsa kapalı API’ler resmen “kolay düğme” gibi çalışıyor — birkaç satır kodla sonuç alıyorsunuz, kurulum derdi az, bakım derdi düşük. Bu konuyla ilgili Imagen-4-Fast: Google’ın Hızlı Görsel Modeli Neden Dikkat Çekiyor? yazımıza da göz atmanızı tavsiye ederim. Daha fazla bilgi için Claude Code ile Çoklu Repo Yönetimi: Context Kaybetme yazımıza bakabilirsiniz.
Ama gel gelelim her güzel şeyin bir bedeli var. Token başına ücretlendirme büyüdükçe can yakabiliyor. Bilhassa de destek botu gibi yoğun trafik alan sistemlerde aylık maliyet sessiz sedasız kabarıyor. Geçen yıl Şişli’de tanıştığım bir SaaS ekibi bunu birebir yaşadı; ilk ay faturayı görünce yüz ifadeleri değişti diyeyim, siz anlayın. Daha fazla bilgi için PDF Dünyasında Bir Nefes: Ücretsiz ve Limitsiz Araçlar yazımıza bakabilirsiniz.
Açık kaynak modellerde tablo farklılaşıyor. Kontrol sizde oluyor. Veriyi dışarı taşımadan çalışma ihtimali doğuyor ve gerektiğinde modeli ince ayar yapmak mümkünleşiyor. Fakat bu kez altyapı yükü sizin omzunuza biniyor; GPU yönetimi, sürüm uyumu, performans takibi… yani iş bitmiyor, sadece şekil değiştiriyor. Bu konuyla ilgili Butterfly CSS: 2026’da Dikkat Çeken Hafif Bir Seçenek yazımıza da göz atmanızı tavsiye ederim.
| Kriter | Kapalı API | Açık Kaynak Model |
|---|---|---|
| Kurulum hızı | Çok hızlı | Daha yavaş |
| Maliyet kontrolü | Kullanıma bağlı | Büyük ölçekte avantajlı olabilir |
| Veri gizliliği | Sınırlı esneklik | Daha yüksek kontrol |
| Bakım yükü | Düşük | Yüksek |
Kodla başlayıp sonra düşünmek yerine…
Dürüst olmak gerekirse, Bence en sağlıklı yaklaşım önce kullanım senaryosunu netleştirmek. Mesela müşteri hizmetleri için kısa cevaplar üreten bir yardımcı mı kuruyorsunuz? Yoksa kurum içi belgelerden cevap çeken ciddi bir bilgi sistemi mi? İkisi aynı şey değil — hatta birbirine uzaktan akraba bile sayılmaz, ciddiye alın bunu.
# Basit mantık:
if hız_öncelikli:
model = "kapalı_api"
elif veri_gizliliği_öncelikli:
model = "açık_kaynak"
else:
model = "hibrit_yaklaşım"Orkestrasyon katmanı olmadan ürün olmaz
Lafı gevelemeden söyleyeyim: ham model çıktısı tek başına ürün değildir. Kullanıcıya iyi deneyim vermek için çağrı zinciri gerekir, prompt tasarımı gerekir, bazen araç kullanımı gerekir, bazen de RAG gerekir ki model sallamasın. Bunların hepsi orkestrasyon katmanının işi.
Peki neden bu kadar önemli? Çünkü kullanıcı “doğru cevap” isterken aslında tutarlı davranış bekliyor. Ben geçen kasım ayında İzmir’deki küçük bir e-ticaret projesinde buna çok net takıldım. Model harika özetler çıkarıyordu ama aynı soruya farklı günlerde farklı tonlarda cevap veriyordu. Prompt şablonunu sıkılaştırınca iş toparladı. Aslında mesele zekâ değildi. Düzgün yönlendirmeydi. Python Paketlerinde Gizli Regex Tehlikesi: 20 Kütüphane Ne Gösterdi? yazımızda bu konuya da değinmiştik.
RAG neden bu kadar konuşuluyor?
RAG, yani Retrieval-Augmented Generation dediğimiz yapı — modeli kendi hafızanızla beslemek gibi düşünebilirsiniz, hafızası olmayan çok zeki birini düşünün. Dokümandan parça çekersiniz, modele verirsiniz ve cevap oradan şekillenir. Bu yöntem özellikle politika metinleri, teknik dokümantasyon ve destek içerikleri için bayağı iş görüyor.
İyi kurgulanmış RAG sistemi çoğu zaman daha büyük modelden daha faydalıdır; çünkü cevabın dayandığı kaynak bellidir ve saçmalama payı düşer.
E tabi burada da kusursuzluk yok. Eğer indekslediğiniz veri kirliyse ya da eskiyse sistem size özgüvenli yanlışlar sunabiliyor — bu kısmı hafife alan çok ekip gördüm maalesef. Hem de defalarca.
Araç kullanımı ve gateway’ler işin gizli tarafı
Eh, Bazen modele doğrudan erişmek yerine araya proxy veya gateway koyarsınız ki loglama yapabilesiniz, oran sınırlayabilesiniz ya da sağlayıcı değiştirirken köprü yanmasın. Ben bunu Nisan 2024’te Beşiktaş’taki bir demo ortamında test ettiğimde net fark ettim: tek sağlayıcıya bağımlılık kısa vadede rahat, ama orta vadede ufak çaplı bir kilitlenme yaratıyor. Farkına bile varmadan oluyorsunuz (ben de ilk duyduğumda şaşırmıştım). İşleyiş tam rayına oturunca anlıyorsunuz ki asıl değer model seçmekten çok entegrasyon disiplininde yatıyor (ben de ilk duyduğumda şaşırmıştım). Neyse, uzatmayayım.
Veri tarafı: Görünmeyen ama en pahalı kısım
İşin garibi, Konu yapay zekâ olunca herkes modeli konuşuyor. Veri ise arkada sessizce emekçi gibi çalışıyor. Benim tecrübeme göre kötü etiketlenmiş veya eksik metadata’sı olan veriyle yapılan proje, en iyi prompt’u bile tökezletiyor. Mesela şirket içi dokümanlarda tarih, sürüm numarası, dosya sahipliği gibi detaylar temiz değilse RAG hattınız çökmeye başlıyor — yavaş yavaş, sinsi sinsi.
Bu yüzden küçük startup’larda bile veri hijyenine erken yatırım yapmak lazım. Kurumsalda ise zaten başka çare yok; aksi halde denetim günü tatsız oluyor.
- Küçük ekipler için öncelik: az ama temiz veri seti
- Büyüyen ürünler için öncelik: versiyonlanmış bilgi kaynağı
- Kurumlar için öncelik: erişim kontrolü ve kayıt tutma — bunu es geçmeyin
- Tüm senaryolar için ortak ihtiyaç: kalite testi ve geri dönüş mekanizması — ciddi fark yaratıyor
- Göz ardı edilmemesi gereken konu: maliyet takibi
Kimin hangi mimariyi seçmesi mantıklı?
Küçük startup senaryosu
Eğer beş kişilik ekiple MVP çıkarıyorsanız fazla kahramanlık yapmaya gerek yok. Kapalı API ile başlayın, prompt düzenini oturtun, sonra gerekirse RAG ekleyin. Hatta ilk sürümde fine-tuning peşine düşmek çoğu zaman gereksiz lüks oluyor, söylüyorum. Benzerini Eylül 2024’te Ankara’da çalışan iki girişimde gördüm; biri direkt open source’a atlayıp iki ay altyapıyla boğuştu, diğeri sade başladığı için müşteriye daha erken ulaştı. Tahmin edin hangisi nefes aldı?
Enterprise seviyede durum nasıl?
Büyük organizasyonda işler biraz sertleşiyor (evet, doğru duydunuz). Veri dışarı çıkacak mı? Kim hangi cevabı verdi? Loglar nerede tutuluyor? Yanlış yanıt üretildiğinde kim müdahale ediyor? Bu soruların hepsi masada oluyor ve hepsine cevap vermek zorundasınız. O yüzden enterprise tarafta hibrit yaklaşım bana — kendi adıma konuşayım — daha mantıklı geliyor: can alıcı işler yerel veya kontrollü ortamda, genel amaçlı işler ise servis üzerinden yürüyebiliyor. Kağıt üstünde süper duran yapıların pratikte sınandığında aksadığına defalarca şahit oldum — “beklediğim kadar değildi” dediğim projeler oldu doğrusu.
En sağlam AI mimarisi en parlak olan değil; hata yaptığında sizi ortada bırakmayandır!
Nereden başlamalı?
- Kullanım senaryosunu tek cümlede yazın. (bu kritik)
- Cevabın ne kadar kritik olduğunu belirleyin.
- Maliyet mi, gizlilik mi, hız mı — önceliğe karar verin.
- Pilot kurup gerçek kullanıcıyla test edin.
- Tutarsızlıkları loglardan izleyip düzeltin.
Bence bu listeyi masaüstüne koymak bile bazı ekiplerin yönünü toparlıyor (ben de ilk duyduğumda şaşırmıştım). Çünkü herkes “AI stratejisi” diyor ama somut adımı kaçırabiliyor. Haziran sonunda Marmara Üniversitesi çevresindeki küçük bir ekiple bunu test ettiğimde, kağıt üstündeki plan ile gerçek kullanım arasında ciddi fark çıktı. Kullanıcı metni kopyalayıp yapıştırırken bile sistem kırılabiliyor. Evet, öyle basit şeylerden bahsediyorum.
Sıkça Sorulan Sorular
AI stack nedir?
AI stack, yapay zekâ uygulaması kurarken kullandığınız temel modelleri, orkestrasyonu, veriyi ve güvenlik katmanlarını birlikte düşünme biçimi demekdir.Basitçe söyleyeyim,hazır modeli alıp uygulamaya dönüştüren bütün yapı budur.
KAPALI API Mİ AÇIK KAYNAK MODEL Mİ DAHA İYİDİR?
Eğer hızlı çıkış istiyorsanız kapalı API genelde daha rahatdır.Veri kontrolünüz önemliyse veya uzun vadede maliyet hesabı yapmak istiyorsanız açık kaynak tarafını değerlendirmek mantıklıdır.Keskin kazanan yok;yere göre değişir.
`RAG` HER PROJEDE GEREKLİ MİDİR?
`Hayır`. Eğer uygulamanız kendi bilgisine dayanacaksa,RAG çok faydalıdır.Ama basit üretken görevlerde ekstra karmaşıklık yaratabilir.Yani her yere sopa gibi sokulmamalıdır.
MALİYET NASIL KONTROL ALTINDA TUTULUR?
Trafik artmadan token kullanımını ölçün,promptları kısaltın,gereksiz tekrarları kaldırın.Gateway veya cache katmanı da yardımcı olur.En önemlisi,test etmeyi ertelememektir.
OpenAI DokümantasyonuLangChain DokümantasyonuLlamaIndex DokümantasyonuYapay Zekâ Kodlamada Neden Adım Adım Kazanıyor?Yapay Zekâyla Kod Yazarken Kontrolü Nasıl KaybetmiyorumMulti-Turn Prompt Injection:
ML’siz Tespit Taktikleri
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
