Yapay zekâ tarafında bir süredir aynı şeyi duyup duruyoruz: “Model iyi,. Sistem kötü.” İşin aslı şu ki, LLM mühendisliği tam da bu boşluğu kapatıyor. Geçen ay, 2025 Şubat’ta İstanbul’daki küçük bir SaaS ekibiyle yaptığım sohbette bunu yine gördüm; ekip, model seçmekten çok cevabın ne kadar tutarlı geldiğiyle uğraşıyordu — saatler harcamışlardı, üstelik çözüme yakın bile değillerdi. Çünkü mesele sadece akıllı bir model bulmak değil… onu güvenilir, ölçülebilir ve biraz da uslu hale getirmek.
Bu yazıda on kavramı tek tek didiklemeyeceğim. Daha çok sahada iş gören çerçeveyi anlatacağım — hani şu “kağıt üstünde güzel duruyor ama prod’a çıkınca dağılıyor” tipindeki sorunları azaltan şeyleri. Açık konuşayım, ilk defa 2023 sonbaharında bir finans startup’ında çalışırken bu farkı sert şekilde hissetmiştim: prompt iyi görünüyordu, giriş verisi azıcık değişince cevaplar kayıyordu. Sinir bozucu. Ama öğretici de oldu.
İşte tam da bu noktada devreye giriyor.
Önce şunu netleştirelim: LLM mühendisliği ne yapar?
LLM mühendisliği, büyük dil modellerini “kullanmak” ile “ürüne dönüştürmek” arasındaki o uzun koridoru yönetiyor. Model çağırıp cevap almak kolay. Zor olan, aynı cevabı benzer koşullarda tekrar tekrar alabilmek — bu kulağa basit geliyor. Pratikte insanın saçını ağartan türden bir problemdir. Bir müşteri destek botu düşünün mesela: bugün doğru cevap veriyor diye sevinirsiniz, yarın farklı tonda ve bambaşka bir biçimde saçmalayınca tüm sistemin tadı kaçar, kullanıcılar şikayet etmeye başlar ve siz de debug için haftalarca uğraşırsınız.
Buraya veri akışı, prompt tasarımı, değerlendirme ölçütleri ve güvenlik giriyor. Yani konu yalnızca yapay zekâ değil; biraz yazılım mimarisi, biraz ürün yönetimi, biraz da sabır işi. Ben bunu çoğu zaman mutfak metaforuyla anlatıyorum: tarif güzel olabilir ama ocak ayarı bozuksa yemek yine yanıyor. Basit.
Bir de ölçek meselesi var. Küçük bir startup’ta tek bir model ve birkaç endpoint ile idare edebilirsiniz; kurumsal tarafta ise loglama yoksa, versiyon takibi yoksa ve geri dönüş mekanizması kurulmamışsa işler çabuk karışıyor. İlginç, değil mi? Neyse, uzatmayalım; asıl farkı yaratan temel kavramlara gelelim — itiraf edeyim, beklentimin üstündeydi —
1) Prompt tasarımı tek başına yetmiyor
Evet, prompt önemli. Ama her sorunu prompt ile çözmeye çalışmak biraz tornavidayla duvar yıkmaya benziyor; olur mu? Olur… ama gereksiz yorarsınız kendinizi, hem de sonunda duvar hâlâ yerinde durur. İyi prompt demek sadece düzgün komut vermek değil, modeli doğru sınırlar içine almak demek.
Çok konuştum, örnekle göstereyim. PDF Dünyasında Bir Nefes: Ücretsiz ve Limitsiz Araçlar yazımızda bu konuya da değinmiştik.
Mesela 2024 Nisan’ında Berlin merkezli bir e-ticaret ekibinde test ettiğim sistemde kısa promptlar bazen daha iyi sonuç verdi çünkü gereksiz açıklama kalabalığını ortadan kaldırıyordu. Uzun. Süslü talimatlar ilk bakışta profesyonel görünüyordu ama modelin dikkatini dağıtıyordu — tam beklediğim tersi çıktı bu, açıkçası şaşırdım. İlginç, değil mi? Beklediğim kadar değildi dediğim nokta tam da buydu.
Bir de şunu söyleyeyim. Prompt’u kod gibi düşünmek lazım. Sürüm kontrolü yapılmalı, değişiklik notu tutulmalı ve hangi versiyonun ne ürettiği kayıt altına alınmalı — yoksa sonra “bu çıktı neden böyle oldu?” diye birbirine bakan ekipler görürsünüz (bizzat test ettim). Gördüm. Defalarca.
Kısa örnek
You are a helpful assistant.
Answer only with JSON.
If data is missing, return null.
Do not guess.
2) RAG neden bu kadar popüler?
Ne yalan söyleyeyim, RAG yani Retrieval-Augmented Generation kulağa havalı geliyor ama aslında basit bir derdi çözüyor: modele dışarıdan güncel bilgi getirmek. Model her şeyi ezberlemek zorunda kalmasın diye ona referans doküman veriyorsunuz. Fena değil, hatta baya iş görüyor; özellikle kurumsal dokümanlar sık değişiyorsa bu yaklaşım ciddi anlamda hayat kurtarıyor. Daha fazla bilgi için Apple’ın Yeni M5 MacBook Air’i İndirime Girdi: Fiyatlar Düştü yazımıza bakabilirsiniz.
Araya gireyim: Bu konuyu ilk duyduğumda hemen test etmek istedim. Benzer yapıyı 2024 Temmuz’unda Ankara’da çalışan bir hukuk teknoloji girişiminde görmüştüm (isim vermeyeyim). Orada mevzuat değiştikçe modelin eski bilgiyi özgüvenle sallaması ciddi sorun yaratıyordu — yanlış cevap değil de sanki kesinmiş gibi sunulmuş yanlış cevap, bu daha tehlikeli (bizzat test ettim). RAG devreye girince cevapların tonu bile toparlandı diyebilirim.
Gel gelelim RAG sihirli değnek değil (inanın bana). Kötü indekslenmiş dokümanlar varsa ya da arama katmanı zayıfsa model yanlış parçayı çekip yine yanlış konuşuyor. Yani önce bilgi deposu temiz olacak — sonra retrieval mantıklı olacak… en son üretim katmanı iş görecek. Zincirin herhangi bir halkası kopunca sistem çöküyor. Bu konuyla ilgili Array_map Her Derde Deva Değil: Temiz Kodun Bedeli yazımıza da göz atmanızı tavsiye ederim.
| Kavram | Neden önemli? | Zayıf tarafı |
|---|---|---|
| Prompt Tasarımı | Cevap yönünü belirler | Aşırı bağımlılık yaratır |
| RAG | Dış bilgi ekler | Kötü aramada hata büyür |
| Eğitim / İnce Ayar | Davranışı özelleştirir | Maliyetli olabilir |
| Değerlendirme | Tutarlılığı ölçer | Zor metrik seçimi gerekir |
3) İnce ayar mı, araç kullanımı mı?
Eh, Baya kilit bir ayrım bu. Herkes ilk fırsatta fine-tuning’e atlıyor, sanıyor ki sorun çözülecek — hayır, öyle olmuyor çoğu zaman (ciddiyim). Bazen araç kullanımı yeterli; yani modelin kendi kafasından üretmesi yerine dış servis çağırması gerekiyor. Mesela fiyat hesaplama yapacaksa hesap makinesine gitmesi daha mantıklı olabilir, modeli bu iş için zorlamamak lazım. Bu konuyla ilgili Poco X8 Pro Max Türkiye’de: Dev Batarya, Büyük Soru İşareti yazımıza da göz atmanızı tavsiye ederim. Butterfly CSS: 2026’da Dikkat Çeken Hafif Bir Seçenek yazımızda bu konuya da değinmiştik.
Kendi projelerimde şu farkı net gördüm: eğer görev tekrarlıysa. Dil tarzını değiştirmek istiyorsanız ince ayar işe yarıyor; fakat veri dinamikse araç kullanımı daha esnek kalıyor, özellikle API uçları sürekli değişiyorsa bu esneklik altın değerinde oluyor. Neden önemli bu? Bir arkadaşım 2025 Ocak’ta İzmir’deki lojistik şirketinde bu geçişi yaptı ve manuel düzeltme yükünü ciddi azaltmıştı — rakam söylediğinde inanamadım doğrusu.
Ama ince ayarın hayal kırıklığı yaşattığı yerler de var. Veri seti kirliyse model o kirliyi öğreniyor işte… Temizleyemediğiniz şeyi büyütmüş oluyorsunuz. Maalesef.
4) Değerlendirme olmadan güven olmaz
Lafı gevelemeden söyleyeyim: test etmiyorsanız prod’a kum atıyorsunuz demektir. LLM sistemlerinde klasik unit test yetmiyor; davranış testi gerekiyor, çıktı tutarlılığı gerekiyor, hatta bazen insan değerlendirmesi gerekiyor çünkü bazı hatalar metrikte hiç görünmüyor ama kullanıcıda pat diye hissediliyor — bunu yaşamadan anlatmak zor, inanın.
Araya gireyim: Bunu 2024 Kasım’ında Londra’daki bir medya platformunda açıkça gördüm. Sistem teknik olarak çalışıyordu ama tonlama berbat olduğu için editörler kullanmak istemedi. Kağıt üstünde süperdi… pratikte “göreceğiz artık” kısmında sınıfta kaldı diyelim. Kimse memnun değildi, hem geliştirici ekip hem de kullanıcılar.
LLM sistemlerinde en pahalı hata genelde yanlış cevaptan çok,
yanlış cevabın fark edilmemesi oluyor.
Bu paket büyüklük olarak küçük olabilir ama karar kalitesi açısından hayat kurtarıyor.
5) Güvenlik ve maliyet aynı masada oturuyor
Bence birçok ekip burada geç kalıyor çünkü güvenliği ayrı takımın işi sanıyorlar. Öyle değil. Prompt injection saldırıları, veri sızıntısı riski ve gereksiz token tüketimi aynı zincirin halkaları gibi birbirine kenetlenmiş durumda — birini ihmal edince diğerleri de sarkıyor. Bir de şu var: model ne kadar çok konuşursa maliyet o kadar artıyor. Basit gibi duruyor ama aylık faturaya bakınca insanın yüzü düşüyor.
SaaS tarafında API anahtarı yönetimi nasıl kritikse burada da guardrail tasarımı kritik hale geliyor. SaaS İçin API Anahtarları Güvenli Kurulum Rehberi konusuna da baktıysanız bilirsiniz zaten bu hassasiyeti. Gerçek dünyada yanlış loglama bile başınıza iş açabiliyor. Bilhassa de PII içeren uygulamalarda maskeleme yoksa gecenin köründe uyandırılırsınız — ben yaşadım, tavsiye etmem.
- Kullanıcı girdisini filtreleyin
- Sistem talimatlarını ayrı tutun
- Cevap uzunluğunu sınırlayın
- Sensitif veriyi loglamayın
- Maliyet izleme koyun
Küçük startup ile enterprise arasında fark ne?
Küçük ekiplerde hız öncelikli oluyor. Enterprise tarafta ise denetlenebilirlik öne çıkıyor — bu iki şey aslında birbirine zıt değil ama farklı araçlar gerektiriyor. Aynı modeli iki yerde kurarsınız ama etrafındaki emniyet kemerleri bambaşka olur. Startup’ta hızlı iterasyon kazanır… Kurumsalda ise uyumluluk kazanır. İkisi de haklı. Ama farklı dertlerle yaşıyorlar, bu farkı erken anlamak çok şey değiştiriyor.
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.
