Hemen her kurumda aynı sahne yaşanıyor: bir öğleden sonra kurulan LLM demosu toplantıda alkış alıyor, üç ay sonra aynı sistem üretimde ya hiç yok ya da kimsenin güvenmediği bir deneme olarak köşede duruyor. Aradaki mesafenin adı teknoloji değil; LLM entegrasyonu işinin görünmeyen yüzü olan mühendislik disiplini.
Üretim ortamında güvenilir bir LLM sistemi dört ayak üzerinde durur: çıktı kalitesini düzenli ölçen bir değerlendirme seti (eval), hatalı çıktıyı kullanıcıya ulaşmadan yakalayan korkuluklar (guardrail), ne olup bittiğini gösteren gözlemlenebilirlik ve bir şey ters gittiğinde devreye giren yedek yol (fallback). Prompt bu yapının girişidir, kendisi değil.
Demo neden yanıltır?
Demo, koşulları özenle seçilmiş bir sahnedir: temiz girdi, bilinen soru, izleyen gözler ve tek bir çalıştırma. Üretim ise tam tersi — kirli veri, beklenmedik girdiler, günde yüzlerce çağrı ve kimsenin izlemediği saatler. Modelin on denemede dokuz iyi cevap vermesi demoda başarıdır; üretimde, günde yüz çağrı alan bir sistemde her gün on hatalı çıktı demektir ve o onun tanesi hangi müşteriye denk geleceğini seçemezsiniz.
Bu yüzden üretime alma kararının sorusu "çalışıyor mu" değil, şudur: yanlış çalıştığında ne oluyor? Yanlış cevabın maliyeti düşükse (taslak metin, iç özet) hızlı ilerlenebilir; çıktı bir müşteriye, bir fiyata ya da bir kayda dokunuyorsa aşağıdaki dört ayak pazarlıksız kurulur.
Üretimin demoda görünmeyen gerçekleri kabaca şu listedir: girdiler beklediğiniz biçimde gelmez (boş alan, yanlış dil, yapıştırılmış tablo), kullanıcılar sistemi tasarlanmadığı işler için zorlar, yük gün içinde dalgalanır, sağlayıcı gecikmeleri müşteri deneyimine yansır ve hiçbir hata mesai saatini beklemez. Güvenilir sistem bu listeyle savaşan değil, bu listeyi varsayılan kabul eden sistemdir.
Birinci ayak: eval — ölçmeden hiçbir şeyi değiştirmeyin
Değerlendirme seti, sistemin işinden derlenmiş gerçek örnek vakalardır: girdiler ve beklenen çıktı nitelikleri. Elli iyi seçilmiş vaka, bin rastgele vakadan değerlidir. Prompt'ta tek kelime değiştirmek, model sürümünü yükseltmek, RAG'e yeni belge eklemek — hepsi bu setten geçirilerek yapılır; geçmiyorsa değişiklik üretime çıkmaz.
Bunu kendi ürünümüzde yaşadık: YouContent360'ta zararsız görünen bir istem sadeleştirmesi, değerlendirme setindeki birkaç kenar vakayı sessizce bozdu — üretilen içeriklerin bir kısmı biçim kuralını kaybediyordu. Değişiklik üretime çıkmadan sette yakalandı; set olmasaydı bunu ilk fark eden bir kullanıcı olacaktı.
Eval'siz ekiplerin iyileştirme döngüsü izlenime dayanır: biri "sanki kötüleşti" der, biri "bence düzeldi" der ve tartışma veriyle değil rütbeyle biter. Eval kavramının kendisi için sözlükteki tanıma bakabilirsiniz; kurulumu yarım günlük iştir ve projenin en yüksek getirili yarım günüdür.
İkinci ayak: guardrail — çıktı ile dünya arasına katman koyun
Model çıktısı hiçbir zaman doğrudan kalıcı bir sonuca bağlanmaz. Aradaki katman üç işi yapar: biçim denetimi (beklenen alanlar var mı, sayı gerçekten sayı mı), kural denetimi (tutar limiti, yasaklı içerik, kapsam dışı konu) ve eşik denetimi (modelin emin olmadığı durumda işlemi insana devretme). Kritik akışlarda son sözü insanın onayladığı yarı otomatik tasarım, tam otomasyondan neredeyse her zaman daha hızlı benimsenir — çünkü ekip sisteme güvenmeyi kademeli öğrenir.
Guardrail'in gözden kaçan bir faydası daha var: modeli değiştirme özgürlüğü. Çıktı denetimi katmanda yaşadığı için, yarın daha ucuz ya da daha iyi bir modele geçtiğinizde güvence mekanizmanız yerinde kalır — güvenliği prompt'un içine gömen ekipler her model değişiminde sıfırdan başlar.
RAG kullanıyorsanız: getirme katmanı da üretim parçasıdır
Şirket belgeleriyle çalışan sistemlerde hata çoğu zaman modelden değil, getirme (retrieval) katmanından gelir: soruya yanlış belge parçası getirilmiştir ve model o yanlış parçayı gayet güzel özetler. Bu yüzden RAG'li sistemlerde eval iki katmanlıdır — "doğru parçalar mı getirildi" ve "cevap getirilene sadık mı" ayrı ayrı ölçülür. Cevaplara kaynak gösterme zorunluluğu da bir guardrail'dir: kaynak gösteremeyen cevap, kullanıcıya "doğrulanamadı" etiketiyle gider ya da hiç gitmez. Belge güncelliği ise sessiz katildir: kimsenin sahiplenmediği bir doküman deposu, altı ay içinde sistemin güvenilirliğini eskitir — depo sahipliği ve güncelleme ritmi baştan atanır.
Üçüncü ayak: gözlemlenebilirlik — istem ve cevap da log'dur
Klasik uygulama izlemesi yetmez; LLM sisteminde istemler, cevaplar, gecikme ve token tüketimi birlikte izlenir. Bu dört veri olmadan iki soruya da cevap veremezsiniz: "kalite neden düştü" ve "fatura neden büyüdü". Token bazlı maliyet, kullanım büyüdükçe doğrusal büyür — ayda yüz çağrılık pilotta önemsiz görünen birim maliyet, günde bin çağrıda bütçe kalemine dönüşür ve bunu ancak ölçüyorsanız yönetirsiniz.
Dördüncü ayak: fallback ve sürüm sabitleme
Model sağlayıcıları kesinti yaşar; bu bir olasılık değil, takvim sorusudur. Üretim sistemi ana model cevap veremediğinde ne yapacağını baştan bilir: ikinci bir modele düşmek, önbellekten cevap vermek, işi kuyruğa alıp insana haber vermek ya da dürüst bir "şu an yanıt veremiyorum" mesajı. Sessizce boş dönen sistem, güveni bir kesintide kaybeder.
Büyük sağlayıcılardan birinin saatler süren bir kesintisini canlı sistemle yaşadık. Fallback tasarımı o gün kendini ödedi: akış ikinci modele düştü, kritik adımlar kuyruğa alındı ve kullanıcı tarafında tek görünen şey hafif bir yavaşlamaydı. Aynı kesintiyi fallback'sız yaşayan ekiplerin günü nasıl geçirdiğini sonradan forumlardan okuduk.
Aynı başlığın ikizi sürüm sabitlemedir: sağlayıcının "otomatik en yeni model" seçeneği üretimde kumar demektir. Sürüm sabitlenir, yeni sürüm önce eval setinden geçirilir, sonra geçiş yapılır. Kavramların hızlı özeti için sözlükteki fallback ve model güncellemesi maddelerine bakın.
Veri sınırını baştan çizin
Üretime giden her LLM akışında "hangi veri modele gidebilir" sorusunun yazılı bir cevabı olmalı. Kişisel veri içeren akışlarda maskeleme sınırda yapılır, sağlayıcının eğitimde kullanmama taahhüdü sözleşmeyle alınır ve akış envantere işlenir. Bu tarafın yedi somut kontrolünü KVKK yazısında ayrıntısıyla anlattım; buradaki kural kısa: güvenlik sonradan eklenen bir özellik değil, mimarinin girdisidir.
30 günlük üretime alma planı
Pratikte işleyen sıra şu: ilk hafta eval seti kurulur ve mevcut sistemin taban puanı alınır; ikinci hafta guardrail katmanı ve insan onay noktaları eklenir; üçüncü hafta izleme panosu (istem, cevap, token, gecikme) devreye girer; dördüncü hafta fallback senaryoları test edilir — sağlayıcı bilerek kapatılır ve sistemin davranışı izlenir. Bu dört haftanın sonunda elinizde demo değil, arızasını haber veren bir sistem olur.
Her haftanın çıkış ölçütünü de yazın: eval taban puanı kayıt altında mı, kritik akışlarda insan onayı fiilen çalışıyor mu, panoya bakan biri dünkü token maliyetini söyleyebiliyor mu, sağlayıcı kapatıldığında kullanıcı ne gördü? Bu dört soruya cevap verilemeyen hafta bitmemiştir — takvimde bitmiş görünse bile.
Sıranın kendisinden önemli tek şey kapsam disiplinidir: tek akış, uçtan uca, ölçülerek. Beş akışı yarım güvenilirlikte işletmektense bir akışı tam güvenilir işletip şablonu çoğaltmak, hem daha hızlı hem de ekibe güven kazandıran yoldur.
Sahada en sık gördüğüm üç hata
Prompt'u tek kişinin kafasında tutmak. İstemler sürümlenmeyen, gözden geçirilmeyen metinler olarak kaldığında sistemin davranışı bir kişinin hafızasına bağlanır. İstem de koddur: depoda durur, değişikliği izlenir, eval'den geçmeden yayına çıkmaz.
Her işi en büyük modele göndermek. Sınıflandırma gibi basit işler küçük ve hızlı modellerle hem daha ucuz hem çoğu zaman daha tutarlı çalışır. Katmanlı model kullanımı — basit işe küçük, muhakeme isteyen işe büyük — üretim sistemlerinde faturayı yarıdan fazla düşürebilen tek karardır.
Pilotu sessizce büyütmek. Beş kullanıcılık pilotta sorunsuz görünen sistem, elli kullanıcıya sessizce açıldığında izleme ve maliyet kontrolleri kurulmamışsa aynı hafta sürprize dönüşür. Genişleme bir karar anıdır: eval puanı, hata oranı ve birim maliyet eşikleri tanımlanır, eşik geçilmeden kapsam büyütülmez.
Sık sorulan sorular
Çalışan bir PoC'umuz var; üretim için ne eksik?
Genellikle dört şey: çıktı kalitesini düzenli ölçen bir eval seti, hatalı çıktıyı yakalayan guardrail katmanı, istem-cevap-token düzeyinde izleme ve sağlayıcı kesintisine karşı fallback. PoC "çalışabilir mi" sorusuna cevaptır; üretim "yanlış çalıştığında ne olur" sorusunun cevabını ister.
Hangi modeli seçmeliyiz?
Kendi eval setinizde en iyi puanı, kabul edilebilir maliyet ve gecikmeyle veren modeli. Genel sıralama tabloları başlangıç için fikir verir ama sizin vakalarınızı temsil etmez; doğru cevap markadan değil ölçümden çıkar. Çoğu kurumsal sistemde farklı işler için farklı modeller birlikte kullanılır.
Eval setini nasıl kurarız, kaç vaka gerekir?
Gerçek kullanımdan derlenmiş 30-50 vaka ile başlayın: tipik girdiler, bilinen zor örnekler ve geçmişte hata çıkarmış durumlar. Her vakaya "iyi cevabın taşıması gereken nitelikler" yazılır; puanlama başta elle, oturduktan sonra kısmen otomatik yapılır. Set yaşayan bir varlıktır — üretimde görülen her ilginç hata sete eklenir.
Maliyeti nasıl kontrol altında tutarız?
Üç kaldıraçla: izleme (hangi akış kaç token yakıyor), istem sadeleştirme ve doğru model eşleme — her işi en pahalı modele göndermek yerine basit işleri küçük modele yönlendirmek. Önbellekleme de sık atlanan bir kalemdir: aynı sorunun cevabını ikinci kez modele sormak, parayı ısıtmaya harcamaktır.
Model güncellenince sistemimiz bozulur mu?
Sürüm sabitlemediyseniz bozulabilir ve bunu en kötü yoldan, kullanıcıdan öğrenirsiniz. Doğru düzen: üretimde sabit sürüm, yeni sürüm çıktığında önce eval setinden geçirme, puan düşmüyorsa kontrollü geçiş. Bu döngü kurulduğunda model güncellemesi risk olmaktan çıkıp rutin bakıma dönüşür.
Bu yapıyı kurmak için ekip mi büyütmeliyiz?
Çoğu kurumda hayır — eksik olan kadro değil disiplindir. Eval, guardrail ve izleme mevcut mühendislik ekibinin öğrenebileceği pratiklerdir; kritik olan bunların proje planında "sonra yaparız" kalemine düşmemesidir. Ekibin bu pratikleri edinmesi için kurumsal yapay zekâ eğitimi hızlandırıcı olur.
Sonuç: prompt giriş biletidir, sistem ise yapı
İyi bir prompt sizi oyuna sokar; oyunda tutan şey eval, guardrail, gözlemlenebilirlik ve fallback'ten örülen yapıdır. Bu yapı bir kez kurulduğunda her yeni akış aynı iskeletin üzerine hızla oturur — demo ile üretim arasındaki üç aylık uçurum, iki haftalık şablona iner.
Bu yapıyı kendi sisteminiz için kurgularken teknoloji liderliği düzeyinde destek isterseniz CTO danışmanlığı tam bu kesişimde çalışır.
Bu yazıyı, telekomünikasyon ve havacılık sektörlerinde üretim sistemleri işletirken ve DijitalAI'de LLM tabanlı sistemler kurarken edindiğim deneyimle yazdım. Hakkımda daha fazlası: Ufuk Aytaş kimdir.