Uçtan Uca Üretim: Doğrulama, İzleme ve Etik

Kazanimlar:

• Bir LLM özelliğini fikirden üretime taşıyan uçtan uca mimariyi tasarlayabilir
• Doğrulama zorunluluğu, insan onayı ve izleme (logging/metrik) katmanlarını kurar
• Sınırlar, etik ve gizlilik ilkelerini üretim kararlarına dönüştürür

Önceki on ünitede parçaları tek tek öğrendik: istek yapısı, token ekonomisi, akış, sistem promptu, model seçimi, önbellek, batch, hata yönetimi, güvenli anahtar ve otomasyon. Bu son ünitede parçaları birleştirip bir LLM özelliğini fikirden üretime taşıyan bütünsel mimariyi kuruyoruz. Üretim, "çalışan bir demo"dan farklıdır: doğrulama zorunludur, çıktı izlenmelidir, sınırlar ve etik ilkeler kararlara gömülmüş olmalıdır. Bu ünite modülün taşıyıcı kolonudur; öncekilerin hepsi burada bir araya gelir.

Üretim Mimarisinin Katmanları

Sağlam bir LLM özelliği kabaca beş katmandan oluşur:

1. Girdi katmanı: Veriyi topla, temizle, hassas alanları maskele, yalnızca gerekli olanı ilet.
2. Model katmanı: Doğru modeli seç (5. ünite), sistem promptunu ve parametreleri ayarla (4. ünite), önbellekle (6. ünite).
3. Doğrulama katmanı: Çıktıyı şema/kural, kaynak ve gerekiyorsa insan onayıyla denetle.
4. Eylem katmanı: Doğrulanmış çıktıyla eylemi gerçekleştir; yüksek etkili eylemleri kapıla.
5. İzleme katmanı: Her çağrıyı, maliyeti, hatayı ve kaliteyi kaydet ve ölç.

Bu katmanlar bir boru hattıdır; her biri bir öncekinin çıktısını denetleyerek alır.

Doğrulama Neden Zorunlu?

LLM'ler akıcı ama bazen yanlış çıktı üretebilir. Buna halüsinasyon denir: model, doğruymuş gibi görünen ama gerçek olmayan bir bilgi uydurabilir. Bir sohbet oyununda bu tolere edilebilir; bir üretim sisteminde (fatura, sağlık, hukuk, finans) tolere edilemez. Bu yüzden çıktı, körlemesine güvenilmez; doğrulanır.

Doğrulama katmanları (etkiye göre artan):

• Biçim/şema doğrulaması: Çıktı beklenen JSON şemasına uyuyor mu? (Yapılandırılmış çıktı bunu büyük ölçüde garanti eder.)
• Kural/mantık doğrulaması: Değerler makul mü? (Tutar negatif mi, tarih gelecekte mi, kategori geçerli mi?)
• Kaynak doğrulaması: İddia, sağlanan belgeye dayanıyor mu? Model belgede olmayan bir şey mi söylüyor?
• İnsan onayı: Yüksek etkili veya belirsiz kararlarda bir uzman gözden geçirir.

Dikkat: "Model çok iyi, artık doğrulamaya gerek yok" en tehlikeli üretim yanılgısıdır. Model ne kadar iyi olursa olsun, yüksek etkili kararlarda doğrulama katmanı bir güvenlik ağıdır. Bir kez bile hatalı otomatik karar, tüm zaman kazanımını götürebilir.

İnsan-Döngüde (Human-in-the-Loop)

Her karar tam otomatik olmak zorunda değildir. İnsan-döngüde yaklaşımda model işi hızlandırır, insan onaylar. Doğru denge, kararın etkisine ve modelin o görevdeki güvenilirliğine bağlıdır.

Kararın etkisi

Yaklaşım

Düşük (etiket önerisi, taslak)

Tam otomasyon; hata ucuz ve geri alınabilir

Orta (yönlendirme, önceliklendirme)

Otomasyon + örnekleme denetimi

Yüksek (para, sözleşme, sağlık, silme)

İnsan onayı zorunlu; model yalnızca önerir

İzleme: Görmediğinizi Yönetemezsiniz

Üretimde her çağrıyı izlemelisiniz. İzleme olmadan ne maliyeti, ne kaliteyi, ne de bir sorunu erken yakalayamazsınız. Kaydedilecek temel metrikler:

• Kullanım/maliyet: İstek başına ve toplam token, model dağılımı, günlük harcama.
• Gecikme: Ortalama ve en kötü durum yanıt süresi.
• Hata oranı: 429/500 oranları, yeniden deneme sayıları, vazgeçmeler.
• Kalite: Doğrulama katmanında reddedilen çıktı oranı, insan onayında düzeltme oranı, kullanıcı geri bildirimi.

İpucu: İzleme kayıtlarına hassas veri (kişisel bilgi, anahtar) yazmayın. Logları da gizlilik kapsamında düşünün; gerekirse maskeleyerek kaydedin (9. ünite).

Etik ve Sınırlar

Teknik doğruluk kadar etik sorumluluk da üretim kararının parçasıdır:

• Şeffaflık: Kullanıcı bir yapay zekayla mı, insanla mı konuştuğunu bilmeli.
• Adalet ve önyargı: Model, eğitildiği veriden önyargı taşıyabilir; yüksek etkili kararlarda (işe alım, kredi) ayrımcı sonuçları denetleyin.
• Sorumluluk: Otomatik bir karar zarar verirse sorumluluk sizindir; "model öyle dedi" bir savunma değildir.
• Sınırların kabulü: Model bazı işleri güvenilir yapamaz; bunları otomatikleştirmemek de bir tasarım kararıdır.

Kopyalanabilir Şablonlar

# Doğrulama kontrol listesi (çıktı üretiminden sonra)1) Şema geçerli mi? (yapılandırılmış çıktı doğrulaması)2) Değerler mantıklı mı? (kural kontrolü: aralık, tarih, enum)3) İddia kaynağa dayanıyor mu? (belgede yoksa reddet)4) Etki yüksek mi? → insan onayına gönder5) Hepsi geçtiyse → eyleme izin ver, kaydet

# Kaynağa dayanmayı zorlayan sistem promptuYalnızca sağlanan belgedeki bilgilere dayan. Belgede olmayan hiçbir şeyi ekleme.Bir bilgi belgede yoksa "Belgede bulunamadı" yaz. Asla tahmin veya uydurma yapma.

# İnsan onayı eşiği (karar kuralı)EĞER karar_türü in [para, sözleşme, silme, sağlık] → insan onayı zorunluEĞER model_güven < eşik VEYA doğrulama "belirsiz" → insan onayına gönderDİĞER → otomatik uygula + örnekleme denetimi

# İzleme kaydı şablonu (hassas veri yazma){ "zaman":"...", "model":"...", "girdi_token":..., "cikti_token":..., "gecikme_ms":..., "stop_reason":"...", "dogrulama":"gecti|reddedildi|insan", "maliyet_usd":... } // kişisel veri ve anahtar ASLA yazılmaz

Zayıf prompt / Güçlü prompt (üretim güvenilirliği)

# ZAYIF (doğrulama yok, kaynak yok, otomatik uygular)Bu talebi değerlendirip iade kararını ver ve uygula.

# GÜÇLÜ (kaynağa dayalı, öneri üretir, insan onayına bırakır)Bu iade talebini yalnızca iade politikası belgesine göre değerlendir.Kararını gerekçesiyle öner ama uygulama: {"oneri":"onayla|reddet","gerekce":"...","politika_maddesi":"..."}.Politika belgesinde net bir dayanak yoksa "belirsiz" ver. Nihai kararı bir temsilci onaylayacak.

Güçlü sürüm; kararı kaynağa bağlar, modeli "uygulayıcı" değil "öneren" konumuna alır ve yüksek etkili adımı insan onayının arkasına koyar. Üretim güvenilirliğinin özü budur.

Üç Mini Vaka

Vaka 1 — Doğrulama katmanının kurtardığı gün. Bir fintech, işlem açıklamalarını modele sınıflandırtıp otomatik muhasebe kaydı oluşturuyordu. Kural doğrulaması eklediler: model bir kez tutarı yanlış çıkardığında (belgedeki 1.250 yerine 12.500), "tutar belgeyle eşleşmiyor" kuralı çıktıyı reddetti ve kayıt insana düştü. Doğrulama olmasaydı hatalı kayıt sessizce sisteme girecekti.

Vaka 2 — İzlemeyle yakalanan kaçak. Bir SaaS ekibi izleme paneli kurmuştu; bir sabah günlük maliyet üç katına çıktı. Log'lardan bir istemcinin döngüye girip aynı isteği binlerce kez attığı görüldü. Kota ve tekilleştirme eklediler; sorun saatler içinde çözüldü. İzleme olmasaydı fatura ay sonunda sürpriz olacaktı.

Vaka 3 — Sınırı kabul etmek. Bir sağlık startup'ı, tanı önerisini tam otomatik verip hastaya göstermeyi planlıyordu. Etik ve sorumluluk incelemesinde bunun sınır dışı olduğuna karar verdiler: model yalnızca bir hekime özet ve olası noktalar sunuyor, tanıyı hekim koyuyor. Bir işi otomatikleştirmemek de olgun bir tasarım kararıdır.

Sık yapılan hatalar

• Doğrulamayı atlamak: "Model iyi" diyerek çıktıyı körlemesine uygulamak.
• Yüksek etkili kararı otomatikleştirmek: Para/sağlık/hukukta insan onayı zorunlu.
• İzleme kurmamak: Maliyet ve kalite sorunları geç fark edilir.
• Loglara hassas veri yazmak: Gizlilik ihlali; maskeleyerek kaydedin.
• Kaynağa dayanmayı zorlamamak: Model belgede olmayanı uydurabilir.
• Sınırları görmezden gelmek: Bazı işleri otomatikleştirmemek doğru karardır; şeffaflık ve sorumluluk sizdedir.

Daha Derine: Sürüm Yönetimi, Geri Alma ve Kademeli Yayılım

Bir LLM özelliğini üretime almak, onu bir kez kurup unutmak değildir; canlı bir sistemi zaman içinde güvenle değiştirmektir. Bunun üç direği vardır.

Sürümleme (versioning). Sistem promptunuz, model seçiminiz ve doğrulama kurallarınız zamanla değişir. Her önemli değişikliği sürümleyin ve hangi sürümün canlıda olduğunu kaydedin. Bir gün kalite düşerse, "neyi değiştirdik?" sorusuna dakikalar içinde cevap verebilmelisiniz. Sürümsüz bir sistemde bir gerilemenin (regression) kök nedenini bulmak günler alır.

Geri alma (rollback). Yeni bir prompt ya da model canlıda beklenenden kötü davranırsa, hızlıca önceki iyi bilinen sürüme dönebilmelisiniz. Geri alma planı olmayan bir değişiklik, canlı bir riski körlemesine kabul etmek demektir. "Bir şeyi değiştirdim, kötü oldu, geri dönemiyorum" en pahalı üretim senaryosudur.

Kademeli yayılım (gradual rollout). Bir değişikliği tüm trafiğe bir anda uygulamak yerine, önce küçük bir yüzdeye (ör. %5) verip metrikleri (kalite, maliyet, hata) izlersiniz. İyiyse yüzdeyi artırırsınız; kötüyse yalnızca küçük bir kesim etkilenmişken geri alırsınız. Bu, riski büyük ölçüde sınırlar.

Bu üç uygulama, önceki tüm ünitelerdeki tekniklerle birleşir: eval (5. ünite) değişikliği önceden ölçer, izleme (bu ünite) yayılım sırasında erken uyarı verir, doğrulama katmanı hatalı çıktıları eyleme dönüşmeden yakalar. Üretim, tek bir doğru kurulum değil; ölçen, izleyen ve güvenle değişebilen sürekli bir disiplindir. Modülün bütünü, işte bu disiplini kurmanız içindir.

Özetle

Üretim, çalışan bir demodan fazlasıdır: girdi, model, doğrulama, eylem ve izleme katmanlarından oluşan bir boru hattıdır. Çıktı doğrulanmadan güvenilmez; yüksek etkili kararlar insan onayına bağlanır; her çağrı maliyet, hata ve kalite açısından izlenir. Etik, şeffaflık, önyargı denetimi, sorumluluk ve sınırların kabulü teknik kararların ayrılmaz parçasıdır. Bu modülde öğrenilen her parça, bu bütünsel tasarımda bir araya gelir.

Uygulama görevi

Bir LLM özelliğini uçtan uca tasarlayın. (1) Beş katmanı (girdi, model, doğrulama, eylem, izleme) kendi göreviniz için doldurun. (2) Hangi kararların insan onayı gerektireceğini etkiye göre işaretleyin. (3) En az üç doğrulama kontrolü (şema, kural, kaynak) yazın. (4) İzleyeceğiniz temel metrikleri ve loglara neyi yazmayacağınızı belirleyin. (5) Bu özellikte kabul ettiğiniz bir sınırı ve bir etik ilkeyi yazın.

Kontrol listesi

• [ ] Üretim boru hattının beş katmanını tasarlayabiliyorum.
• [ ] Çıktıyı şema, kural ve kaynak açısından doğrulayabiliyorum.
• [ ] Kararın etkisine göre insan onayı eşiği koyabiliyorum.
• [ ] Maliyet, hata ve kaliteyi izleyip loglara hassas veri yazmamayı uyguluyorum.
• [ ] Etik, sorumluluk ve sınırları üretim kararlarına dönüştürebiliyorum.

Modul Sinavi

1. Bir LLM sohbet API'sinde 'system' rolü ne işe yarar?

• A) Modele tüm konuşma boyunca geçerli kalıcı talimat ve davranış kurallarını verir ✔
• B) Kullanıcının yazdığı son soruyu tutar
• C) Modelin ürettiği yanıtı saklar
• D) API anahtarını şifreler

Aciklama: system rolü, modele konuşmanın tamamı boyunca geçerli olacak kalıcı talimatları, kişiliği ve kuralları verir; kullanıcı mesajlarından ayrı, üst düzey bir yönlendirmedir.

2. Bir API isteğinde konuşma geçmişi (önceki mesajlar) neden her seferinde tekrar gönderilir?

• A) Sunucu geçmişi sildiği için yedeklemek gerekir
• B) API çağrıları durumsuzdur; model geçmişi hatırlamadığı için bağlam her istekte yeniden gönderilir ✔
• C) Yalnızca faturalama için gereklidir, modele etkisi yoktur
• D) Geçmiş göndermek yanıtı yavaşlatmamak için zorunludur

Aciklama: LLM API çağrıları durumsuzdur (stateless); model önceki turları hatırlamaz, bu yüzden bağlamı korumak için tüm ilgili geçmiş her istekte yeniden gönderilir.

3. LLM fiyatlandırmasında 'token' nedir?

• A) API'ye giriş yapmak için kullanılan tek seferlik parola
• B) Her istekte ödenen sabit bir ücret
• C) Modelin metni işlediği en küçük birim; genellikle kelime parçasına karşılık gelir ✔
• D) Yalnızca çıktının uzunluğunu ölçen bir birim

Aciklama: Token, modelin metni işlediği en küçük birimdir; genellikle bir kelime parçasına karşılık gelir ve hem girdi hem çıktı token sayısı üzerinden ücretlendirilir.

4. Çoğu LLM sağlayıcısında çıktı token'ları neden girdi token'larından daha pahalıdır?

• A) Çıktı token'ları her zaman girdiden daha uzundur
• B) Girdi token'ları ücretsizdir
• C) Çıktı token'ları internet üzerinden iki kez gönderilir
• D) Çıktı üretimi her token için ek hesaplama gerektirdiğinden birim maliyeti daha yüksektir ✔

Aciklama: Çıktı token'larının her biri modelin adım adım üretim (hesaplama) yapmasını gerektirir; bu üretim maliyeti girdiyi bir kerede işlemekten daha yüksektir, bu yüzden çıktı birim fiyatı genellikle daha yüksektir.

5. Akış (streaming) kullanmak hangi durumda en çok fayda sağlar?

• A) Uzun yanıtlarda; algılanan gecikmeyi azaltır ve zaman aşımını önler ✔
• B) Sadece çok kısa, tek kelimelik yanıtlarda
• C) Maliyeti sıfıra indirmek için
• D) API anahtarını gizlemek için

Aciklama: Uzun yanıtlarda akış, ilk kelimelerin hemen görünmesini sağlayarak algılanan gecikmeyi azaltır ve büyük max_tokens değerlerinde HTTP zaman aşımını önler.

6. Modern modellerde 'çaba' (effort) parametresini yükseltmek genellikle neyi etkiler?

• A) Yanıtı her zaman kısaltır
• B) API anahtarını otomatik olarak rotasyona sokar
• C) Yalnızca girdi token fiyatını düşürür
• D) Düşünme derinliğini ve token harcamasını artırır; kaliteyi yükseltebilir ama gecikme ve maliyeti de artırır ✔

Aciklama: Çaba parametresi, modelin bir göreve ne kadar derin düşüneceğini ve ne kadar token harcayacağını ayarlar; yükseltmek kaliteyi artırabilir ama gecikmeyi ve maliyeti de artırır. Basit görevlerde düşük çaba yeterlidir.

7. Basit, yüksek hacimli bir sınıflandırma görevinde maliyet açısından genellikle en doğru yaklaşım nedir?

• A) Her zaman en pahalı ve en güçlü modeli kullanmak
• B) Her istekte tüm modelleri aynı anda çağırmak
• C) Görevi başaran en hafif/ucuz modeli, küçük bir eval ile doğrulayarak seçmek ✔
• D) max_tokens değerini gereksiz yere çok yüksek tutmak

Aciklama: Görev karmaşık değilse, en pahalı ve en güçlü modeli kullanmak yerine görevi rahatça başaran daha hızlı ve ucuz bir model (ör. Haiku sınıfı) seçmek maliyeti ciddi biçimde düşürür.

8. Prompt önbellekleme (prompt caching) hangi senaryoda maliyeti en çok düşürür?

• A) Büyük ve sabit bir bağlam birçok istekte tekrar tekrar kullanıldığında ✔
• B) Her istekte tamamen farklı bir metin gönderildiğinde
• C) Yalnızca tek bir istek yapıldığında
• D) Çıktı token'larını azaltmak için

Aciklama: Önbellekleme bir önek (prefix) eşleşmesidir; büyük ve değişmeyen bir bağlamın (sistem promptu, dokümanlar) birçok istekte tekrar kullanıldığı durumlarda önbellekten okuma tam fiyatın küçük bir kesri (~0,1 kat) kadardır.

9. Prompt önbelleğinin isabet etmesi (cache hit) için promptu nasıl düzenlemek gerekir?

• A) Değişken içeriği başa, sabit içeriği sona koymak
• B) Sistem promptuna her istekte güncel tarih ve saat gömmek
• C) Sabit içeriği (sistem promptu, dokümanlar) başa, değişken içeriği sona koymak ✔
• D) Her istekte araç (tool) listesinin sırasını değiştirmek

Aciklama: Önbellek bir önek eşleşmesi olduğundan, sabit/değişmeyen içerik (sistem promptu, dokümanlar) başa; değişken içerik (tarih, kullanıcı sorusu, istek kimliği) sona konur. Başta değişen tek bir bayt bile önbelleği geçersiz kılar.

10. Toplu işleme (batch) hangi tür iş yükü için en uygundur?

• A) Kullanıcının ekranda anında yanıt beklediği canlı sohbet
• B) Yalnızca tek bir kısa soru
• C) API anahtarı üretmek
• D) Gecikmeye toleranslı, büyük hacimli ve anında sonuç gerektirmeyen işler ✔

Aciklama: Toplu işleme, anında yanıt gerektirmeyen, gecikmeye toleranslı büyük hacimli işler için uygundur; sonuçlar bir süre sonra teslim edilir ancak birim maliyet genellikle daha düşüktür.

11. Bir toplu işte (batch) sonuçların hangi isteğe ait olduğunu güvenle eşleştirmek için ne kullanılır?

• A) İsteklerin gönderim sırası (konumu)
• B) Yanıtların uzunluğu
• C) API anahtarının son 4 hanesi
• D) Her isteğe verilen benzersiz bir custom_id ✔

Aciklama: Toplu sonuçlar gönderim sırasından farklı bir sırada dönebilir; bu yüzden her isteğe verilen benzersiz bir custom_id ile sonuçları konuma göre değil kimliğe göre eşleştirmek gerekir.

12. API'den 429 (rate limit) hatası aldığınızda önerilen davranış nedir?

• A) Aynı anda çok daha fazla istek göndererek zorlamak
• B) retry-after başlığına uyarak üstel geri çekilme ile yeniden denemek ✔
• C) İsteği tamamen iptal edip hatayı kullanıcıya çökme olarak göstermek
• D) API anahtarını değiştirmek

Aciklama: 429 yeniden denenebilir bir hatadır; retry-after başlığına saygı göstererek üstel geri çekilme (exponential backoff) ile yeniden denemek doğru yaklaşımdır. Çoğu resmi SDK bunu otomatik yapar.

13. Aşağıdaki HTTP hata kodlarından hangisi genellikle yeniden denenebilir (retryable) kabul edilir?

• A) 400 (geçersiz istek)
• B) 401 (kimlik doğrulama hatası)
• C) 529 (sunucu aşırı yüklü) ✔
• D) 404 (bulunamadı)

Aciklama: 429 (hız limiti), 500 (sunucu hatası) ve 529 (aşırı yük) geçici hatalardır ve geri çekilmeyle yeniden denenebilir. 400 ve 401 gibi hatalar istek/kimlik sorunudur; yeniden denemek çözmez.

14. API anahtarlarını yönetmenin güvenli yolu aşağıdakilerden hangisidir?

• A) Ortam değişkeni/gizli yöneticide saklamak, koda gömmemek ve düzenli rotasyon yapmak ✔
• B) Anahtarı doğrudan kaynak koduna yazıp depoya göndermek
• C) Anahtarı istemci tarafı (tarayıcı) JavaScript'ine koymak
• D) Tek bir anahtarı tüm ekiple e-posta ile paylaşmak

Aciklama: Anahtarlar asla kaynak koduna veya depoya yazılmaz; ortam değişkeni ya da gizli yönetim aracında saklanır, en az yetkiyle verilir ve düzenli olarak rotasyona tabi tutulur.

15. Bir otomasyon aracıyla (n8n, Zapier, Make) LLM entegrasyonunda gizlilik açısından en doğru yaklaşım nedir?

• A) Tüm ham veriyi, gerekli olmasa bile modele göndermek
• B) API anahtarını akış adımının içine düz metin olarak yazmak
• C) Hassas veriyi en aza indirip maskelemek ve anahtarı gizli kimlik bilgisi olarak saklamak ✔
• D) Kişisel veriyi kalıcı olarak akış geçmişinde tutmak

Aciklama: Otomasyona giren veriler üçüncü taraf sistemlerden ve modelden geçtiği için, hassas/kişisel verinin en aza indirilmesi, maskelenmesi ve yalnızca gerekli alanların gönderilmesi gerekir; API anahtarı da araç içinde gizli kimlik bilgisi olarak saklanır.

16. LLM tabanlı bir üretim özelliğinde çıktının doğrulanması neden zorunludur?

• A) Model asla hata yapmadığı için yalnızca biçimlendirme gerekir
• B) Model akıcı ama bazen yanlış üretebildiğinden; şema/kural, kaynak ve insan onayıyla denetlenmelidir ✔
• C) Doğrulama yalnızca maliyeti artırdığı için kaçınılmalıdır
• D) Doğrulama sadece token sayısını azaltmak içindir

Aciklama: LLM'ler akıcı ama bazen yanlış (halüsinasyon) çıktı üretebilir; bu yüzden yüksek etkili kararlarda çıktı; şema/kural kontrolü, kaynak doğrulaması ve gerektiğinde insan onayı ile denetlenmelidir.