Yapay zekâ tarafında her gün yeni bir başlık çıkıyor, biliyorum. Bir model daha büyüyor, bir araç daha “devrim” ilan ediliyor, sonra herkes aynı soruya geri dönüyor: Peki biz bunu gerçek hayatta nasıl kullanacağız? İşin aslı şu ki, sadece API çağrısı yapıp geçmek artık yetmiyor. Eğer sağlam bir ürün kurmak istiyorsanız, modelden veri katmanına, orkestrasyondan uygulama arayüzüne kadar bütün resmi görmeniz gerekiyor (evet, doğru duydunuz)
Ben bu konuyu ilk kez 2023 sonbaharında, Kadıköy’de küçük bir startup ekibiyle çalışırken fark ettim (buna dikkat edin). Herkes “LLM ekleyelim” diyordu. Kimse verinin nerede duracağını, yanıtların nasıl denetleneceğini ya da maliyetin nasıl şişeceğini konuşmuyordu. Sonunda güzel görünen ama sahada tökezleyen bir demo çıktı. Hani olur ya, kağıt üstünde süper; pratikte biraz hırçın (ki bu çoğu kişinin gözünden kaçıyor). Evet.
Bugün size o yüzden düz bir “şunu kurun bunu bağlayın” yazısı anlatmayacağım. AI stack’i parçalara ayırıp bakalım; hangi katman ne işe yarıyor, nerede para yakar, nerede işinizi büyütür… Bir de açık konuşayım: bazı yerlerde hâlâ ham. Hele bir de agent tarafı çok havalı görünüyor ama her senaryoda doğru seçim değil. Şey, işte mesele tam burada düğümleniyor.
AI Stack’in Mantığı: Katmanları Doğru Okumak
Şöyle ki, Bir AI destekli uygulamayı düşünün. Dışarıdan bakınca tek parça gibi görünür ama içeride epey kalabalık bir ekip çalışır. Model karar verir, orkestrasyon katmanı işi sıraya sokar, veri katmanı hafızayı tutar, uygulama katmanı da kullanıcıyla yüz yüze gelir. Yani aslında mutfakta ayrı ayrı işler döner; servis tabağa tek seferde gelir. Kısa olanı bu.
Şimdi gelelim işin can alıcı noktasına.
Bilmem anlatabiliyor muyum, Bu ayrımı anlamak önemli çünkü sorunlar da genelde buradan çıkar. Mesela model iyi olabilir ama veri kötü ise cevaplar saçmalar (yanlış duymadınız). Orkestrasyon düzgün değilse akış kopar. Uygulama arayüzü zayıfsa kullanıcı en (söylemesi ayıp) iyi modeli bile fark etmez. Ben geçen yıl İzmir’de bir kurumsal projede bunu birebir gördüm; ekip en pahalı modeli seçmişti ama prompt zinciri darmadağın olduğu için sonuçlar beklentinin baya altındaydı. Açıkçası şaşırdım.
Eğer bunu basit tutmak isterseniz dört ana parçaya bakabilirsiniz:
- Model katmanı: LLM, embedding modeli ya da sınıflandırıcı
- Orkestrasyon katmanı: Prompt yönetimi, araç çağrıları, görev sıralama
- Veri katmanı: Dokümanlar, vektör veritabanı, indeksler
- Uygulama katmanı: Web arayüzü, API veya CLI
Model Katmanı: Bulut mu Açık Kaynak mı?
Lafı gevelemeden söyleyeyim: model tarafında tek doğru yok. En hızlı başlangıç çoğu zaman bulut API’leriyle oluyor; OpenAI, Anthropic ya da Google gibi sağlayıcılardan hizmet alıyorsunuz ve birkaç satır kodla ilerliyorsunuz. Küçük ekipler için bu yaklaşım fena değil, hatta baya iş görüyor.
Ama burada küçük bir bedel var: maliyet artabilir, veriniz dış servise gider ve tedarikçiye bağımlılık oluşur (ben de ilk duyduğumda şaşırmıştım). Geçen ay Şişli’de tanıştığım bir SaaS ekibi tam bu yüzden sıkıntıya girdi; trafik artınca aylık fatura beklediklerinden iki kat çıktı. “Biz sadece deneme yapıyorduk” dediler… Evet ama üretimde deneme diye bir şey pek olmuyor.
Bulut API ile başlamak ne zaman mantıklı?
Eğer MVP çıkarıyorsanız veya ekipte MLOps kası henüz oturmadıysa bulut API sizi hızlandırır (şaşırtıcı ama gerçek). Sıfır altyapı derdi vardır; sadece ürüne odaklanırsınız (bizzat test ettim). Hızlı doğrulama için birebir. Butterfly CSS: 2026’da Dikkat Çeken Hafif Bir Seçenek yazımızda bu konuya da değinmiştik.
Buna karşılık hassas veri işliyorsanız biraz frene basmak gerekir. Çünkü müşteri kayıtları, iç dokümanlar veya finansal bilgiler söz konusu olduğunda uyum ve güvenlik konusu öne çıkar. Burada “kolaylık” bazen pahalıya patlayabiliyor. C++ Neden Hâlâ Ayakta? Stroustrup’tan Gelen Dersler yazımızda bu konuya da değinmiştik.
Açık kaynak modeller neden cazip?
Açık kaynak tarafta Llama ailesi, Mistral veya Qwen gibi seçenekler öne çıkıyor (inanın bana). Bunları kendi makinenizde ya da kendi bulutunuzda çalıştırabiliyorsunuz; Ollama ve vLLM gibi araçlar da işi kolaylaştırıyor. Kontrol hissi yüksek oluyor — hani anahtar sizde kalıyor ya — işte o rahatlık önemli.
Neyse uzatmayalım: açık kaynak güzeldir ama bakım ister. Donanım planlaması yapmanız gerekir, gecikme yönetirsiniz, sürüm değişikliklerini takip edersiniz… Küçük startup için yük olabilir; enterprise seviyede ise tam tersine avantaj sağlar çünkü kontrol ve veri egemenliği daha değerlidir. Bu konuyla ilgili PDF Dünyasında Bir Nefes: Ücretsiz ve Limitsiz Araçlar yazımıza da göz atmanızı tavsiye ederim.
| Kriter | Bulut API | Açık Kaynak Model |
|---|---|---|
| Başlangıç hızı | Çok hızlı | Orta |
| Maliyet kontrolü | Zorlaşabilir | Daha esnek |
| Tedari̇kçi bağımlılığı | Yüksek | Düşük |
| Saha operasyonu | Daha kolay | Daha zahmetli |
# Ollama ile yerel model çalıştırma örneği
ollama pull llama3.2:1b
ollama run llama3.2:1b
# Python ile kullanım
import ollama
response = ollama.chat(
model='llama3.2:1b',
messages=[
{'role': 'user', 'content': 'Python nedir?'}
]
)
print(response['message']['content'])Orkestrasyon Katmanı: Asıl İşin Kurgusu Burada Başlıyor
Şahsen, Bence birçok ekip orkestrasyon kısmını hafife alıyor. Oysa modelden gelen cevabı doğrudan kullanıcıya vermek çoğu zaman yetmiyor; önce bağlam toplamak lazım, sonra belki araç çağırmak gerekiyor, ardından çıktıyı filtrelemek gerekiyor… Yani tek atımlık mermi değil bu (ben de ilk duyduğumda şaşırmıştım)
Editör masasında bu konuyu tartışırken ben de sık sık aynı noktaya geliyorum: “Agent kullanalım mı?” Cevap bazen evet. Çoğu zaman hayırdır. Çünkü agent sistemi kulağa çok zeki geliyor fakat yanlış tasarlanırsa dolaşıp duran bir robot çocuğa dönüşebiliyor.
Prompt zinciri mi, agent mi?
Klasik prompt zinciri daha kontrollüdür; adımlar bellidir ve hata ayıklaması kolaydır. Agent yaklaşımı ise modele belirli hedefler verip araç seçmesini beklersiniz. Güzel fikir ama henüz pişmesi lazım diyebilirim (yanlış duymadınız)
İyi bir AI ürünü çoğu zaman “en akıllı model” üzerine kurulmaz; doğru sıraya dizilmiş orta karar bileşenlerle ayağa kalkar.
Kodla düşünmek neden önemli?
Kod tarafında orkestrasyon size disiplin verir. Örneğin önce kullanıcı sorusunu temizlersiniz, sonra ilgili belgeleri çekersiniz, ardından modele bağlam verirsiniz ve en sonda cevabı formatlarsınız. Bu akış basit görünür ama ürün kalitesini ciddi biçimde yukarı taşır. Bjarne Stroustrup ve C++: Eski Dilin Yeni Hali yazımızda bu konuya da değinmiştik.
Bunu ilk kez Ankara’daki kişisel blog projelerimden birinde denediğimde fark ettim; soru-cevap özelliği önce “gösterişli”, sonra düzenlenince gerçekten kullanılır hale geldi (arada baya ter döktüm). Kısacası sihir yok… mimari var.
Veri Katmanı: Hafıza Olmadan Zekâ Olmuyor
Şimdi gelelim en kritik yere — veri katmanı olmadan AI uygulaması eksik kalıyor dersem abartmış olmam sanırım. Model her şeyi bilmez; sizin dokümanınızı hiç bilmez mesela… O yüzden bilgi getirmeniz gerekir (ki bu çoğu kişinin gözünden kaçıyor)
Söz konusu olan şey yalnızca dosya saklamak değil elbette.
Aradığınız cümlenin anlamını bulmak istiyorsanız embedding’ler. Vektör veritabanları devreye giriyor.
Bu yapı sayesinde “benzerlik” üzerinden arama yapabiliyorsunuz; klasik anahtar kelime aramasından daha insancıl çalışıyor diyeyim size.
Bana göre burada yapılan en büyük hata veriyi olduğu gibi yüklemek oluyor.
Düz metni çuvala atıp mucize beklemek pek işe yaramaz.
Önce temizleme gerekir.
Sonra parçalama.
Ardından indeksleme…
Küçük startup ile enterprise arasında fark ne?
Küçük ekiplerde genelde basit çözümler yeterlidir; birkaç yüz belgeyi yönetiyorsanız hafif bir vektör veritabanı işinizi görür.
Ama enterprise tarafta konu değişir.
Yetki matrisi gelir,
sürümleme gelir,
loglama gelir,
uyum gereksinimleri gelir…
İşte orada iş biraz büyür.
Bunu biraz açayım.
Büyük kurumlarda benzer projelerde hep şu tabloyu gördüm:
veri iyi tasarlanmışsa sistem nefes alıyor;
dağınıksa her sorgu küçük bir yangın çıkarıyor. Bir de şu var: (söylemesi ayıp) doküman güncellendikten sonra eski yanıtların ne olacağı meselesi. Bunu çözmezseniz kullanıcıya dünün bilgisini bugün servis edersiniz — hoş olmaz!
Uygulama Katmanı ve Gerçek Ürün Deneyimi
Tüm bunların üstüne kullanıcıyla konuşan kısım geliyor.
Web uygulaması olabilir,
API olabilir,
hatta terminal tabanlı küçük araçlar bile olabilir.
Buradaki amaç gösteriş değil;
işlevdir.
Kullanıcı “soru soruyorum ve cevap alıyorum” hissini net yaşamalı.”
Neyi iyi yapmak gerekiyor?
Cevabın kaynağını göstermek bence altın değerinde.
“Bu bilgiyi hangi dokümandan aldın?” sorusuna yanıt verebilen ürünler güven kazanıyor.
Bir de hız konusu var tabi;
yanıt gecikirse en zeki sistem bile sinir bozucu hale geliyor.
Ben İstanbul’da test ettiğim birkaç prototipte şunu gördüm:
200-300 ms fark bazen önemsiz sanılıyor ama kullanıcı gözünde ciddi his bırakıyor.”
- Cevapları kısa tutun: Gereksiz laf kalabalığı güven düşürüyor. (bu kritik)
- Kaynağı gösterin: Mesela teknik veya kurumsal içerikte şart gibi düşünün.
- Maliyet takibi yapın: Token faturası sessiz sedasız kabarıyor olabilir.
- Error handling ekleyin: Model bozulursa ürününüz de bozulmasın.
Tasarım Kararları: Ne Zaman Basit Kalmalı?
Bazen insan hevesle karmaşık mimariye gidiyor çünkü kulağa profesyonel geliyor.
Ama dürüst olayım:
her problem agent istemiyor,
her veri kümesi vektör DB istemiyor,
her ürün çok katmanlı yapı istemiyor.”
Aslında dur—önce şunu söyleyeyim:
basitlik çoğu zaman en büyük mühendislik kararıdır.”
Kurumsal ölçekte ise gözlemleme (observability), erişim kontrolü ve sürümleme genelde plana girmeli.
}
Kendi deneyimimde şöyle oldu:
2024 başında Bursa’daki freelance projemde üç hafta içinde çalışan prototip çıkardık çünkü sistemi aşırı büyütmedik.
Aynı fikri altı ay sonra başka yerde yeniden ele aldığımızda ölçeklenebilirlik konuşmaları başladı;
orada açıkçası ilk versiyon kadar keyif alamadık çünkü altyapı işi hız kesiyordu.”
Yani doğru zamanda doğru karmaşıklık lazım.”
Sizin İçin Hangi Yol Daha Mantıklı?
Eğer küçük bir startup iseniz;
önceliğiniz öğrenmek olmalı.
Hızlı deneyin,
ölçün,
gerekirse yön değiştirin.”
Enterprise tarafta ise bambaşka öncelikler var:
gizlilik,
uyumluluk,
izlenebilirlik,
yedeklilik…
Burada hız hâlâ önemli ama kontrol ondan da önemli olabilir.”
Bana göre pratik yol haritası şu şekilde düşünülebilir:
ilk aşamada hazır API ile başlayın;
ikinci aşamada kendi dokümanlarınıza bağlayın;
sonra ihtiyaç varsa açık kaynak modele geçmeyi değerlendirin.”
Tabii bu sıra herkes için aynı değil ama çoğu ekipte iş görüyor.”
- MVP: Hazır model API’siyle doğrula.
- Sorgu kalitesi:İlk olarak RAG ile bilgi bağla.
Maliyet optimize etmeu: daha ucuz modele kaydır.İleri aşama: açıkkaynak/yerel dağıtıma bak.
\
Sıkça Sorulan Sorular
IDK? AI stack kurmak için illa büyük ekip gerekir mi?
RAG ile vector database aynı şey mi?
Hayir.” RAG bir yöntemdir;” vector database ise o yöntemin kullandığı depolardan biridir.” Yani biri strateji,” diğeri araç gibi düşünebilirsiniz.”
Open source model kullanmak her zaman daha ucuz mu?”\H3>
Hayir,” her zaman değil.” Donanim,” bakım,” gecikme optimizasyonu ve operasyon maliyetleri hesaba katılınca toplam tablo değişebilir.” Trafik azsa bulut bazen daha mantıklıdır.”
Agent tabanlı sistemler üretimde güvenilir mi?”\H３>
Kismen evet,” kismen hayir.” Kontrollü senaryolarda iyi çalışırlar;” ama belirsizlik arttığında hata payları yükselir.” O yüzden üretimde körlemesine kullanmamak lazım.”
Kaynaklar ve İleri Okuma”
LangChain Resmi Dokümantasyonu
LlamaIndex Resmi Dokümantasyonu
İlgili Yazılar”
dissectml: EDA ile AutoML Arasındaki Eksik Parça
Edge Computing Neden Yükseliyor BuluTA Yakın Veriye Daha Yakın
Bulut Tedarik Zinciri CodeBuild Açığı ve GDDR6 Şoku
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.
