# Üretimde LLM İzleme: Neyi Loglamalı, Neye Alarm Kurmalı > Source: https://sukruyusufkaya.com/blog/llm-izleme-loglama > Updated: 2026-08-24T00:29:56.571Z > Type: blog > Category: yapay-zeka **TLDR:** LLM izleme, üretimdeki bir dil modeli sisteminin kalite, maliyet ve performansını loglama, trace ve alarm ile görünür kılan disiplindir. Ne loglanmalı, nasıl ölçülür? LLM izleme, üretim ortamında çalışan bir büyük dil modeli uygulamasının davranışını, kalitesini, maliyetini ve performansını sürekli görünür kılan gözlemlenebilirlik disiplinidir. Kısacası, sisteminizin ne yaptığını, ne kadara mal olduğunu ve ne kadar iyi çalıştığını kör tahminle değil, kayıtla bilmektir. Bu rehber, konuyu bir teori olarak değil, üretimde bir dil modeli sistemini ayakta tutmuş bir mühendisin gözünden, pratik kararlar ve somut örneklerle ele alır. Bir dil modeli uygulamasını demoda çalıştırmak kolaydır; onu üretimde binlerce gerçek kullanıcının önünde, ay boyunca, bütçeyi patlatmadan ve sessizce bozulmadan ayakta tutmak ise bambaşka bir mühendislik problemidir. Bu ikisinin arasındaki fark büyük ölçüde görünürlüktür. Klasik bir web servisinde "çalışıyor mu" sorusunun cevabı nettir; bir LLM sisteminde ise sistem teknik olarak "çalışıyor" görünürken çıktının kalitesi çoktan çökmüş olabilir. Bu rehberde llm izleme nedir, neyi loglamalı, mahremiyeti nasıl korumalı, hangi kalite, maliyet ve performans sinyalleri izlenmeli, alarm kurulumu nasıl tasarlanmalı, trace ve span kök neden analizinde nasıl kullanılır, inceleme rutini nasıl kurulur ve tüm bunları hangi sırayla hayata geçirmeli sorularını üretim deneyiminden damıtılmış bir titizlikle ele alıyoruz. ## Görünmeyen Bozulmanın Maliyeti: Neden İzlemeden Üretime Çıkılmaz Bir LLM sisteminin en tehlikeli tarafı, bozulduğunda çoğu zaman gürültü çıkarmamasıdır. Bir veritabanı çöktüğünde alarm zilleri çalar; bir dil modeli sessizce daha kötü yanıtlar üretmeye başladığında ise hiçbir hata kodu dönmez, hiçbir servis "down" olmaz. Sistem kâğıt üzerinde sapasağlam görünür — 200 döner, birkaç saniyede yanıt verir — ama kullanıcıya verdiği cevaplar giderek yanlışlaşır. İşte bu "görünmeyen bozulma", LLM izleme disiplininin var olma nedenidir. Bu sessiz bozulmanın birkaç kaynağı vardır. Model sağlayıcısı arka planda modeli günceller ve sizin promptlarınız yeni sürümde farklı davranır. Bağlı olduğunuz bir RAG bilgi tabanı eskir, çelişkili belgeler girer ve getirme kalitesi düşer. Kullanıcıların soru kalıpları zamanla değişir (dağılım kayması) ve sisteminiz artık gelen sorulara uygun tasarlanmamıştır. Bir prompt değişikliği bir senaryoyu düzeltirken üç başka senaryoyu bozar. Bunların hiçbiri bir istisna fırlatmaz; hepsi yalnızca çıktının kalitesini aşındırır. Ölçmüyorsanız, fark ettiğinizde iş çoktan işten geçmiş, kullanıcı güveni çoktan aşınmış olur. Görünmeyen bozulmanın maliyeti üç biçimde ortaya çıkar. Birincisi itibar ve güven maliyetidir: kullanıcı birkaç kez yanlış cevap alınca sistemi kullanmayı bırakır ve bir daha geri dönmez; kaybedilen güveni yeniden kazanmak, en baştan kazanmaktan zordur. İkincisi kaçak maliyettir: token tüketimi fark edilmeden tırmanır, bir hata döngüsü aynı isteği defalarca yeniden dener veya bir kullanıcının uzun konuşmaları faturayı sessizce şişirir. Üçüncüsü uyum ve güvenlik maliyetidir: maskelenmemiş kişisel veri loglara sızar, bir prompt injection saldırısı fark edilmez veya model uygunsuz bir çıktı üretir ve bunun kaydı bile tutulmamıştır. Üç maliyet de ortak bir kök nedene dayanır — görünürlük eksikliği. Üretimde bir dil modeli uygulamasını izlemeden çalıştırmak, göstergesiz bir uçağı bulutların içinde uçurmaya benzer. Motor çalışıyor gibi hissedilebilir, ama irtifayı, yakıtı ve rotayı görmeden nereye gittiğinizi bilemezsiniz. LLM izleme, bu göstergeleri kurmaktır: sistem ne yapıyor, ne kadara mal oluyor, ne kadar iyi çalışıyor ve ne zaman rotadan çıktı? Bu sorulara kayıtla cevap veremiyorsanız, henüz üretime hazır değilsiniz. Somut bir örnek bu maliyeti görünür kılar. Bir müşteri destek asistanı düşünün: aylarca sorunsuz çalışır, kullanıcı memnuniyeti yüksektir. Sonra model sağlayıcısı arka planda bir güncelleme yapar ve asistan, daha önce kısa ve net verdiği yanıtları artık gereksiz uzun ve bazen konudan sapan biçimde vermeye başlar. Hiçbir hata dönmez; sistem "çalışır". Ama yanıtlar uzadıkça token maliyeti sessizce yükselir, kullanıcılar uzun cevapları okumaktan sıkılıp destek talebini yineler ve memnuniyet yavaşça düşer. İzlemesi olan bir ekip bunu ilk günden — token grafiğindeki tırmanış ve olumsuz geri bildirimdeki artış olarak — görür ve promptu hızla ayarlar. İzlemesi olmayan bir ekip ise aynı sorunu ancak haftalar sonra, şişen fatura ve azalan kullanımla fark eder; o zamana kadar hem para hem güven kaybedilmiştir. Aradaki tek fark görünürlüktür. Bu yüzden olgun ekipler izlemeyi "sonra ekleriz" listesine koymaz; onu üretime çıkışın ön koşulu sayar. Gözlemlenebilirlik altyapısı, ilk kullanıcı sisteme dokunmadan önce yerinde olmalıdır — çünkü izlemediğiniz ilk günlerde biriken sessiz bozulmayı geriye dönük teşhis etmek neredeyse imkânsızdır. LLM izleme, bir lüks veya olgunluk göstergesi değil; üretim sorumluluğunun temel bir parçasıdır. ## LLM İzleme Nedir? Klasik Uygulama İzlemesinden Farkı LLM izleme, en yalın tanımıyla, bir dil modeli sisteminin her isteğini kaydeden, bu kayıtlardan anlamlı sinyaller türeten ve bir şeyler ters gittiğinde uyaran bütünleşik bir gözlemlenebilirlik pratiğidir. "İzleme" (monitoring) sistemin şu anki durumunu; "gözlemlenebilirlik" (observability) ise elimizdeki kayıtlardan sistemin neden o durumda olduğunu anlayabilme yeteneğini anlatır. LLM gözlemlenebilirliğinin temelini LLM gözlemlenebilirliği nedir yazısında ayrıca ele alıyoruz. Peki bu, klasik uygulama izlemesinden (APM) neden farklıdır? Fark, çıktının doğasında yatar. Geleneksel bir serviste doğruluk ikili ve nesneldir: istek ya başarılı ya da başarısızdır, yanıt ya doğru ya yanlıştır, süre ölçülebilir bir sayıdır. Bir dil modelinde ise çıktı olasılıksaldır — aynı prompt farklı zamanlarda farklı yanıtlar üretebilir — ve "doğruluk" özneldir. Teknik olarak kusursuz görünen bir yanıt (200 döndü, hızlı geldi, biçimi düzgün) içerik olarak tamamen yanlış olabilir. Bu yüzden LLM izleme, altyapı metriklerini ölçmekle yetinemez; çıktının anlamsal kalitesini de ölçmek zorundadır. İkinci temel fark maliyetin değişkenliğidir. Klasik bir API çağrısının maliyeti aşağı yukarı sabittir; bir LLM çağrısının maliyeti ise girdi ve çıktı token sayısına bağlı olarak istekten isteğe değişir. Tek bir kullanıcının uzun bir belgeyi bağlama gömen konuşması, sıradan bir isteğin onlarca katı maliyet üretebilir. Bu yüzden token nedir ve tokenin maliyeti nasıl birikir bilmek gerekir; token nedir yazısı bu temeli verir. LLM izleme, maliyeti gerçek zamanlı bir sinyal olarak sürekli takip eder. Üçüncü fark gizlilik boyutudur. Klasik bir servis logu genellikle teknik meta veriden ibarettir; bir LLM logu ise kullanıcının doğrudan yazdığı serbest metni — ki bu metin kişisel veri, sağlık bilgisi veya ticari sır içerebilir — barındırır. Bu, izlemeyi aynı zamanda bir mahremiyet problemi hâline getirir. Dolayısıyla LLM izleme üç boyutu aynı anda kucaklar: kalite, maliyet ve gizlilik. Bu bütünlük, onu klasik APM'den ayıran şeydir. Bu disiplinin operasyonel çerçevesini LLMOps nedir ve genel MLOps bağlamını MLOps nedir yazılarında ele alıyoruz. Bu tablo, neden var olan izleme araçlarınızı olduğu gibi bir LLM sistemine uygulayamayacağınızı özetler. Altyapı izlemesi hâlâ gereklidir — sunucu, gecikme, hata izlenmeye devam eder — ama tek başına yetersizdir. LLM izleme, bunun üstüne çıktı kalitesi ve token maliyeti katmanlarını ekler. Sağlam bir üretim izleme yaklaşımı, bu üç katmanı tek bir bütün olarak ele alır. ## Loglanacak Minimum Alan Seti: Her İstekten Ne Kaydedilmeli İzlemenin temeli logdur; ama "her şeyi logla" bir strateji değildir — hem maliyeti hem gizlilik riskini kontrolsüz büyütür. Doğru başlangıç, her istekten kaydedilmesi gereken bir minimum alan setidir. Bu set, sorun çıktığında kök nedeni bulmaya yetecek kadar zengin, mahremiyeti ve maliyeti kontrol altında tutacak kadar disiplinli olmalıdır. İyi bir loglama stratejisi tam olarak bu dengeyi kurar. Minimum alan seti şu alanları içerir. Kimlik ve bağlam: istek kimliği (trace id), zaman damgası, kullanıcı/oturum kimliği (tercihen takma adlaştırılmış), uygulama/özellik adı. Model bilgisi: model adı ve sürümü, sağlayıcı, sıcaklık (temperature) ve diğer önemli parametreler — çünkü bir sağlayıcı sürümü değiştiğinde bunu geriye dönük görebilmek şarttır. İçerik: prompt ve yanıt (maskelenmiş veya örneklenmiş biçimde), sistem promptu sürümü ve RAG kullanılıyorsa getirilen belgelerin kimlikleri. Sayısal metrikler: giriş token sayısı, çıkış token sayısı, ilk token süresi, toplam gecikme, hesaplanan maliyet ve hata/durum kodu. Sonuç sinyalleri: kullanıcı geri bildirimi (varsa), guardrail/güvenlik filtresi tetiklendi mi, yanıt boş veya kesildi mi. Bu alanların çoğu sayısaldır ve mahremiyet riski taşımaz; bunları her istek için toplamak hem ucuz hem güvenlidir. Asıl hassas olan prompt ve yanıt metnidir; onu nasıl ele alacağımızı bir sonraki bölümde ayrıntılandırıyoruz. Buradaki kilit ilke şudur: sayısal metrikleri tam topla, metin içeriğini disiplinli topla. Giriş ve çıkış token sayısını ayrı loglamak özellikle önemlidir; çünkü çıkış token'ı genellikle giriş token'ından pahalıdır ve bir yanıtın neden pahalı olduğunu ancak bu ayrımla anlarsınız. Bir ayrıntı sık atlanır: promptun kendisini değil, prompt şablonunun sürümünü loglamak. Üretimde promptlar ve sistem promptları zamanla değişir; bir kalite düşüşünü "hangi prompt sürümünden sonra başladı" diye ilişkilendirebilmek için, her isteğe kullanılan şablon sürümünü iliştirmek gerekir. Aynı şey model parametreleri için de geçerlidir. Bu meta veri olmadan, bir bozulmanın nedenini bulmak tahmin oyununa döner. İyi bir loglama stratejisi, "ne oldu" kadar "hangi koşulda oldu" sorusuna da cevap verecek şekilde tasarlanır. ## Mahremiyet ve Log İçeriği Dengesi: KVKK Altında Loglama LLM loglarının en değerli ama en tehlikeli parçası prompt ve yanıt metnidir. Değerlidir, çünkü kök neden analizinin, kalite denetiminin ve değerlendirme setinin ham maddesidir. Tehlikelidir, çünkü kullanıcının serbestçe yazdığı bu metin doğrudan kişisel veri, sağlık bilgisi, finansal detay veya ticari sır içerebilir. Bu yüzden loglama stratejisinin kalbinde bir denge sorusu yatar: kök neden analizi için yeterince bilgi saklamak, ama KVKK yükümlülüklerini ihlal etmemek. Türkiye bağlamında bu, KVKK (Kişisel Verilerin Korunması Kanunu) çerçevesinde ele alınır; LLM loglamanın KVKK boyutunu ayrıntısıyla LLM loglama ve KVKK yazısında işliyoruz. Aşağıdaki ilkeler tanımsal ve bilgilendirme amaçlıdır; hukuki tavsiye değildir ve kurumunuzun hukuk/uyum birimiyle birlikte uygulanmalıdır. Temel yaklaşım, ham metni olduğu gibi ve süresiz saklamamaktır. Pratikte birkaç teknik bir arada kullanılır. Maskeleme: loga yazmadan önce metindeki kişisel veri kalıplarını (ad, TC kimlik numarası, telefon, e-posta, kart numarası) tespit edip yıldızla veya bir etiketle değiştirmek. Bu konuyu yapay zeka veri anonimleştirme ve maskeleme yazısında ele alıyoruz. Takma adlaştırma (pseudonymization): kullanıcı kimliğini doğrudan değil, geri döndürülebilir olmayan bir belirteçle loglamak; takma adlaştırma yazısı bu tekniği açıklar. Saklama süresi (retention): logları sonsuza kadar değil, tanımlı bir süre tutup ardından silmek. Erişim kısıtı: ham loglara yalnızca yetkili kişilerin, denetim kaydıyla erişebilmesi; denetim kaydının rolünü audit trail yazısında bulabilirsiniz. Örnekleme: her isteğin tam metnini değil, küçük bir yüzdesini artı tüm hata vakalarını saklamak. Ekiplerin en sık düştüğü tuzak, hata ayıklamayı kolaylaştırmak için tüm prompt ve yanıtları ham, maskesiz ve süresiz loglamaktır. Bu, kullanıcının sisteme yazdığı her kişisel veriyi bir güvenlik yüküne dönüştürür ve bir sızıntı anında doğrudan KVKK ihlaline yol açar. Maskeleme ve saklama politikası, ilk log satırı yazılmadan önce tasarlanmalıdır; çünkü loglar biriktikten sonra geriye dönük temizlemek hem zor hem risklidir. Gizlilik, sonradan yamanan değil, baştan kurulan bir katmandır. Bu denge, konfigüre edilebilir olmalıdır. Farklı özellikler farklı hassasiyet taşır: bir pazarlama metni üreticisi ile bir sağlık danışma asistanı aynı loglama politikasına tabi olamaz. Olgun bir üretim izleme kurulumu, loglama derinliğini akışın hassasiyetine göre ayarlamaya izin verir — düşük riskli akışlarda daha zengin, yüksek riskli akışlarda daha kısıtlı loglama. Bu esneklik, mahremiyet ile hata ayıklanabilirlik arasındaki gerilimi akışa özel çözmenizi sağlar. Kişisel veri ve KVKK'nın genel çerçevesi için KVKK nedir yazısı temel oluşturur. ## Kalite Sinyalleri: Çıktının Sessizce Bozulduğunu Nasıl Anlarsınız LLM izlemenin klasik izlemeden en çok ayrıldığı yer kalite sinyalleridir; çünkü burada ölçtüğünüz şey bir sayı değil, bir yargıdır. "Yanıt iyi mi" sorusunun tek ve nesnel bir cevabı yoktur, ama bu onu ölçülemez yapmaz — yalnızca birden çok dolaylı gözetim sinyali birleştirmeyi gerektirir. İyi tasarlanmış gözetim sinyalleri, çıktının sessiz bozulmasını erkenden yakalar. En doğrudan kalite sinyali kullanıcı geri bildirimidir. Yanıtın yanında bir beğen/beğenme düğmesi, bir "bu işe yaradı mı" sorusu veya kullanıcının yanıtı kopyalayıp kopyalamaması gibi örtük işaretler, gerçek dünya kalitesinin en dürüst göstergesidir. Olumsuz geri bildirim oranındaki bir artış, çoğu zaman bir bozulmanın ilk ve en güvenilir sinyalidir. Ancak geri bildirim seyrektir — çoğu kullanıcı düğmeye basmaz — bu yüzden tek başına yeterli değildir ve başka sinyallerle desteklenmelidir. İkinci kaynak otomatik değerlendirmedir. Bir modelin çıktısını başka bir modele puanlatmak (LLM-as-a-judge), üretim trafiğinden alınan bir örneklem üzerinde ölçeklenebilir bir kalite tahmini verir. Bu yaklaşımın ayrıntısını LLM-as-a-judge ile değerlendirme yazısında ele alıyoruz; değerlendirme metodolojisinin genelini ise LLM değerlendirme nedir yazısında bulabilirsiniz. RAG kullanan sistemlerde ek bir kritik sinyal kaynak sadakatidir (groundedness): yanıt gerçekten getirilen belgeye mi dayanıyor, yoksa uyduruyor mu? Bu ölçümü RAG değerlendirme yöntemi yazısında derinleştiriyoruz. Üçüncü kaynak dolaylı davranış sinyalleridir. Bunlar ucuzdur ve her istek için toplanabilir: boş veya çok kısa yanıt oranı, yanıtın istenen biçime (örneğin JSON) uyup uymama oranı, kullanıcının aynı soruyu yeniden sorma (retry) sıklığı, konuşmayı yarıda bırakma oranı. Bu sinyallerin her biri tek başına kesin değildir, ama birlikte güçlü bir kalite göstergesi oluşturur. Halüsinasyon riskini izlemek de bu katmana girer; halüsinasyonun doğasını yapay zeka halüsinasyonu nedir ve teknik tanımını hallucination yazısında ele alıyoruz. Kalite izlemesinin altın kuralı, tek bir sinyale güvenmemektir. Kullanıcı geri bildirimi seyrektir, otomatik değerlendirme maliyetlidir, dolaylı sinyaller gürültülüdür; ama üçünü birlikte bir panoda görünce, çıktının sessiz bozulması artık gizlenemez. Bu gözetim sinyalleri birleştiğinde, "sistem çalışıyor ama kalite düştü" durumunu — LLM izlemenin en zor yakaladığı durumu — erkenden yakalarsınız. ## Maliyet Sinyalleri: Kaçak Harcamayı Faturadan Önce Yakalamak Bir LLM sisteminin maliyeti, klasik bir servisin aksine, kullanımla doğrusal ve öngörülebilir değildir; token bazlı, değişken ve sürpriz yapmaya yatkındır. Bu yüzden maliyet, LLM izlemenin gerçek zamanlı bir sinyali olmak zorundadır — ay sonu faturasını görünce değil, harcama tırmanırken fark edilmelidir. Kaçak maliyet, sessiz kalite bozulmasının finansal ikizidir. İzlenecek temel maliyet sinyalleri şunlardır. İstek başına token: giriş ve çıkış token sayısının ortalaması ve dağılımı; ani bir artış, bağlamın şiştiğini veya promptların gereksiz uzadığını gösterir. Zaman birimi başına harcama: saatlik ve günlük toplam maliyet; bunun temel çizgiden sapması ilk alarm noktasıdır. Boyut başına maliyet: model başına, özellik başına, hatta kullanıcı segmenti başına harcama; hangi akışın bütçeyi yediğini bu kırılım gösterir. Başarısız istek başı maliyet: hata verip yeniden denenen isteklerin maliyeti — çünkü başarısız bir çağrı da token yakar. Bu son metriğin önemini başarılı çıktı başına maliyet yazısında ele alıyoruz. Maliyet izlemesi olmadan tipik kaçak senaryoları şöyle gelişir. Bir hata döngüsü, aynı isteği saniyeler içinde yüzlerce kez yeniden dener ve her denemede token yakar; kimse fark etmez çünkü sistem "çalışıyor" görünür. Ya da bir prompt değişikliği bağlama gereksiz belge ekler ve her istek sessizce iki kat pahalı hâle gelir. Ya da az sayıda "ağır" kullanıcı, çok uzun konuşmalarla toplam maliyetin orantısız bir bölümünü tüketir. Bu senaryoların üçü de maliyet sinyalleriyle anında görünürken, izleme yoksa yalnızca ay sonu faturasında bir şok olarak belirir. Maliyet izlemesinin en değerli yan ürünü, optimizasyon fırsatlarını görünür kılmasıdır. Hangi promptların gereksiz uzun olduğunu, hangi isteklerin daha küçük bir modelle karşılanabileceğini, hangi tekrarların önbelleğe alınabileceğini ancak veriyle görürsünüz. Bu yüzden LLM izleme, bir maliyet gideri değil, bir maliyet tasarrufu aracıdır: iyi kurulmuş bir izleme, ortaya çıkardığı israfı gidererek kendi maliyetinden fazlasını geri kazandırır. Optimizasyon tekniklerini LLM maliyet optimizasyonu ve token ekonomisini TokenOps ve FinOps yazılarında ele alıyoruz. ## Performans Sinyalleri: Gecikme, Verim ve Hata Oranı Performans, LLM izlemenin klasik APM'ye en çok benzeyen ama yine de kendine özgü nüanslar taşıyan boyutudur. Kullanıcı deneyimini doğrudan etkileyen bu sinyaller, "sistem hızlı mı, güvenilir mi ve yükü kaldırıyor mu" sorusuna cevap verir. Gecikmenin kullanıcı deneyimine etkisini kardeş yazımız gecikme (latency) nedir ayrıntısıyla ele alır; burada onu bir izleme sinyali olarak inceliyoruz. LLM performansında en kritik ayrım, ilk token süresi (time to first token) ile toplam yanıt süresi arasındadır. İlk token süresi, kullanıcının "sistem beni duydu, cevap geliyor" hissini belirler; akış (streaming) kullanılan arayüzlerde algılanan hızın asıl belirleyicisidir. Toplam süre ise yanıtın tamamının ne zaman bittiğidir. Bu ikisini ayrı izlemek gerekir; çünkü ilk token hızlı ama toplam süre uzun bir sistem, akışla birlikte hâlâ iyi bir deneyim sunabilir. Gecikmeyi ortalama ile değil, yüzdelik dilimlerle (p50, p95, p99) izlemek şarttır: ortalama gecikme iyi görünürken, kullanıcıların yüzde birinin dakikalarca beklediği bir kuyruk sorunu yalnızca p99'da görünür. Diğer temel performans sinyalleri şunlardır. Hata ve timeout oranı: sağlayıcı hataları, hız sınırı (rate limit) reddedilmeleri ve zaman aşımları; bunlar doğrudan kullanıcı deneyimini kırar. Verim (throughput): birim zamanda işlenen istek sayısı; ölçek kapasitesini gösterir. Eşzamanlılık ve kuyruk: aynı anda işlenen istek sayısı ve bekleme kuyruğunun uzunluğu; bir darboğazın erken habercisidir. Yeniden deneme (retry) oranı: geçici hatalar nedeniyle tekrarlanan istekler; hem performans hem maliyet sinyalidir. Performans sinyallerinin çoğu ucuzdur ve her istek için toplanabilir; bu yüzden onları tam çözünürlükte izlemek en doğru yaklaşımdır. Ama tek başlarına yeterli değildirler: bir sistem hızlı ve hatasız çalışırken kalitesi çökmüş olabilir. İşte bu yüzden performans, kalite ve maliyet sinyalleri aynı panoda, yan yana izlenmelidir. Üçünü birlikte gördüğünüzde, bir değişikliğin bir boyutu iyileştirip diğerini bozup bozmadığını — örneğin daha küçük bir modelin gecikmeyi düşürürken kaliteyi de düşürüp düşürmediğini — anında görürsünüz. ## Trace ve Span: Çok Adımlı İsteğin Uçtan Uca İzi Modern bir LLM uygulaması nadiren tek bir model çağrısından ibarettir. Tipik bir RAG veya ajan isteği; soru yeniden yazma, embedding hesaplama, vektör arama, reranking, model çağrısı ve bazen bir veya birkaç araç kullanımı gibi birbirini izleyen adımlardan oluşur. Bir yanıt yavaş veya bozuk geldiğinde "hangi adımda" sorusuna cevap veremezseniz, kök nedeni karanlıkta ararsınız. İşte trace ve span kavramları bu sorunu çözer ve LLM izlemenin kök neden analizi omurgasını oluşturur. Trace, tek bir kullanıcı isteğinin sistemdeki uçtan uca yolculuğunun tamamını temsil eder. Span ise bu yolculuktaki tek bir adımı — örneğin yalnızca vektör aramayı veya yalnızca model çağrısını — temsil eder ve kendi başlangıç zamanını, süresini, girdisini ve çıktısını taşır. Bir trace, iç içe ve ardışık span'lerden oluşan bir ağaçtır. Bu yapı sayesinde, bir istek üç saniye sürdüğünde trace'i açar ve sürenin nereye gittiğini görürsünüz: belki vektör arama 200 ms, model çağrısı 2.6 saniye, reranking 200 ms sürmüştür — darboğaz nettir. Aynı biçimde bir yanıt yanlış geldiğinde, hangi span'in yanlış belgeyi getirdiğini izleyebilirsiniz. Trace ve span olmadan çok adımlı bir sistemi izlemek, yalnızca giriş ve çıkışı görüp aradaki kutuyu kör kabul etmektir. Toplam süreyi görürsünüz ama içindeki hangi adımın yavaşladığını göremezsiniz; nihai yanıtı görürsünüz ama hangi ara adımın onu bozduğunu bilemezsiniz. Bu yüzden olgun bir LLM izleme kurulumu, en baştan her isteği trace/span yapısıyla enstrümante eder — yani kodun içine, her önemli adımın başını ve sonunu işaretleyen ölçüm noktaları yerleştirir. Bu enstrümantasyonu taşınabilir ve araç-bağımsız kılan şey açık standartlardır. OpenTelemetry, dağıtık sistemlerde trace/span toplamanın yaygın standardıdır ve son dönemde üretken yapay zeka çağrıları için özel anlambilim sözleşmeleri (semantic conventions) kazanmıştır; bu, farklı araçların aynı formatta konuşmasını sağlar. Bu standardın LLM izlemeye uygulanışını OpenTelemetry ile GenAI gözlemlenebilirliği yazısında ele alıyoruz. Standarda dayanmanın pratik faydası, izleme aracınızı değiştirdiğinizde kodunuzu baştan enstrümante etmek zorunda kalmamanızdır — sağlıklı bir üretim izleme mimarisinin temel bir özelliği. Bir kullanıcı "yanıt yanlıştı" veya "çok yavaştı" dediğinde, elinizde o isteğin trace'i varsa sorunu dakikalar içinde çözersiniz: hangi belgeler getirildi, model neye dayanarak yazdı, hangi adım ne kadar sürdü — hepsi görünür. Trace yoksa, aynı sorunu üretmeye çalışıp tahminle ilerlersiniz. Bu fark, bir olayı saatlerce değil dakikalarca yaşamanın farkıdır. Bu yüzden trace/span enstrümantasyonu, LLM izlemenin sonradan eklenen değil, baştan kurulan bir katmanıdır. ## Gözlemlenebilirlik Araçları: Ne Aramalı, Ürün Yerine Kategoriyi Seçmek LLM izleme için bir araç seçerken düşülen ilk hata, "hangi ürünü alayım" sorusuyla başlamaktır. Araç adları hızla değişir; bugün popüler olan yarın yerini bir başkasına bırakabilir. Bu yüzden dayanıklı yaklaşım, ürün değil kategori düzeyinde düşünmek ve bir aracın karşılaması gereken yetenekleri tanımlamaktır. Güncel araç manzarasını LLM gözlemlenebilirlik araçları yazısında ele alıyoruz; burada seçim kriterlerine odaklanıyoruz. İyi bir LLM gözlemlenebilirlik aracının karşılaması gereken temel yetenekler şunlardır. Trace/span görselleştirme: çok adımlı bir isteği ağaç yapısında gösterebilmeli. Prompt/yanıt kaydı ve arama: logları maskeleme desteğiyle saklayıp içinde arayabilmeli. Metrik panoları: gecikme, token, maliyet ve kalite sinyallerini zaman serisi olarak sunabilmeli. Değerlendirme entegrasyonu: otomatik değerlendirme (LLM-as-a-judge) ve geri bildirim toplamayı destekleyebilmeli. Alarm: eşik ve eğilim tabanlı uyarılar kurabilmeli. Standart uyumu: OpenTelemetry gibi açık bir standardı desteklemeli ki bağımlılık (lock-in) oluşmasın. Bir başka önemli kriter dağıtım modelidir: aracı bulutta hazır bir hizmet olarak mı, yoksa kendi altyapınızda (self-hosted) mı çalıştıracaksınız? Bu karar hem maliyeti hem de KVKK/veri egemenliği uyumunu doğrudan etkiler; çünkü izleme araçları, tanımı gereği prompt ve yanıt gibi hassas veriyi görür. Kişisel veri içeren logların yurt dışı bir hizmete akması, uyum açısından ayrı bir değerlendirme gerektirir. Bu yüzden araç seçimi yalnızca teknik değil, aynı zamanda bir yönetişim kararıdır. Pratik bir ilke, izlemeyi uygulamadan gevşek bağlı tutmaktır. Enstrümantasyonunuzu açık bir standarda dayandırırsanız, izleme aracını değiştirmek kodunuzu yeniden yazmak anlamına gelmez. Ayrıca birçok ekip başlangıçta abartılı bir araç yerine, temel metrikleri toplayan basit bir kurulumla başlar ve ihtiyaç kanıtlandıkça derinleşir. LLMOps olgunluk yolculuğunun bir parçası olarak izlemeyi LLMOps rehberi ve üretimde AI sistemlerini ayakta tutmanın genel çerçevesini model izleme, drift ve geri bildirim döngüsü yazısında ele alıyoruz. ## Alarm Eşiği Tasarımı: Gürültü ile Sağırlık Arasında Loglama görünürlük verir; alarm ise o görünürlüğü eyleme çevirir. İyi bir alarm kurulumu, bir bozulmayı siz uyurken veya başka bir işle meşgulken yakalar ve doğru kişiyi uyarır. Ama alarm tasarımı ince bir dengedir: çok hassas alarmlar sürekli çalar ve ekip onları görmezden gelmeye başlar (alarm yorgunluğu); çok gevşek alarmlar ise gerçek sorunları kaçırır. Amaç, gürültü ile sağırlık arasında doğru noktayı bulmaktır. İlk ilke, alarmı statik bir sayıya değil, temel çizgiye (baseline) ve eğilime bağlamaktır. "Gecikme 5 saniyeyi aşarsa uyar" gibi sabit bir eşik, sistemin normal davranışı zamanla değiştikçe ya çok sık çalar ya hiç çalmaz. Bunun yerine "gecikme, son bir haftanın normalinin belirgin üstüne çıktığında uyar" gibi göreli bir eşik, sistemin kendi bağlamına uyum sağlar. Aynı biçimde bir metriğin ani sıçraması (spike) kadar, yavaş ama sürekli tırmanışı (trend) da izlenmelidir; sessiz bozulmanın çoğu ani değil, kademelidir. İkinci ilke, gürültüyü azaltmak için pencere ve süre kullanmaktır. Tek bir anlık sapma çoğu zaman gürültüdür; asıl önemli olan bir sapmanın belirli bir süre boyunca sürmesidir. "p95 gecikme, beş dakika boyunca eşiğin üstünde kalırsa uyar" gibi bir kural, geçici dalgalanmaları eler ve yalnızca kalıcı bir soruna alarm verir. Üçüncü ilke önem seviyelendirmesidir: her alarm aynı aciliyette değildir. Bir kalite çöküşü veya bütçe kaçağı derhal müdahale gerektirirken (kritik), hafif bir gecikme artışı yalnızca bir bilgilendirme olabilir. Kritik alarmlar insanı uyandırır; düşük öncelikliler bir panoda birikip haftalık incelemede ele alınır. Dördüncü ve en çok atlanan ilke şudur: her alarmın bir sahibi ve bir eylem planı olmalıdır. Kimsenin ne yapacağını bilmediği bir alarm, gürültüden başka bir şey değildir. İyi bir alarm kurulumu, uyarıyla birlikte "bu alarm çaldığında şuraya bak, şu adımı at" bilgisini de taşır. Bu olmadan, alarmlar zamanla arka planda uğuldayan ama kimsenin dinlemediği bir sese dönüşür. Güvenlik tarafında, prompt injection ve guardrail tetiklenmeleri özellikle kritik alarm adaylarıdır; bu tehditleri prompt injection nedir ve koruyucu katmanları guardrail nedir yazılarında ele alıyoruz. Bir alarm kurmadan önce şu soruyu sorun: bu alarm gece yarısı çalsa, birini yataktan kaldırmaya değer mi? Cevap 'hayır' ise, o alarm kritik değil bir panelde birikmeli. Cevap 'evet' ise, net bir eylem planıyla gelmeli. Bu basit test, alarm yorgunluğunu önlemenin en pratik yoludur: kritik alarmları az ve anlamlı tutun, gerisini incelemeye bırakın. ## İnceleme Rutini: İzlemeyi Yaşayan Bir Sürece Dönüştürmek Panolar ve alarmlar kurulduğunda iş bitmez; asıl değer, bu araçların düzenli bir insan incelemesiyle beslenmesinde ortaya çıkar. Alarmlar yalnızca ani ve eşik aşan sorunları yakalar; oysa bir LLM sisteminin en sinsi bozulmaları eşiği aşmadan, yavaş ve kademeli ilerler. İşte bu kademeli kaymayı yakalayan şey, düzenli bir inceleme rutinidir. İzleme, bir kez kurulup unutulan bir altyapı değil, yaşayan bir süreçtir. Sağlıklı bir inceleme rutini birkaç katmandan oluşur. Günlük hızlı bakış: sabahları temel panoya beş dakikalık bir göz atış — gecikme, maliyet, hata ve geri bildirim eğilimleri normal mi? Haftalık derin inceleme: kalite sinyallerinin trendine bakmak, olumsuz geri bildirim alan gerçek örnekleri okumak, öne çıkan hata desenlerini incelemek ve bir örneklem üzerinde çıktı kalitesini elle denetlemek. Aylık gözden geçirme: değerlendirme setini güncellemek, temel çizgileri (baseline) gözden geçirmek, alarm eşiklerini ayarlamak ve biriken düşük öncelikli sinyalleri ele almak. İnceleme rutininin kalbinde örneklem denetimi vardır: her hafta, üretim trafiğinden rastgele veya hedefli seçilmiş bir avuç isteği açıp prompt, getirilen bağlam ve yanıtı bir insan gözüyle okumak. Bu, hiçbir otomatik metriğin tam yakalayamadığı incelikleri — tonun bozulması, incelikli bir yanlışlık, bir kenar durumun kötü ele alınması — ortaya çıkarır. Otomatik sinyaller "nerede sorun olabilir" der; insan denetimi "sorun tam olarak ne" sorusuna cevap verir. İkisi birbirini tamamlar. Bu rutinin ürettiği en değerli çıktı, değerlendirme setinin sürekli zenginleşmesidir. Üretimde karşılaşılan her yeni hata türü, gerçek bir kullanıcı sorusu ve bozuk bir yanıt, değerlendirme setine eklenecek bir örnektir. Böylece bir sonraki değişiklik öncesinde, geçmişte yaşanan hataların tekrar edip etmediğini test edebilirsiniz — tıpkı yazılımdaki regresyon testleri gibi. Bu döngü, izlemeyi geçmişi seyretmekten çıkarıp geleceği koruyan bir mekanizmaya dönüştürür. Değerlendirme disiplininin genelini LLM değerlendirme nedir yazısında ele alıyoruz. ## Kalite, Maliyet ve Performansı Tek Panoda Birleştirmek: Korelasyon Görünürlüğü LLM izlemenin en sık atlanan ama en değerli yeteneği, üç sinyal kategorisini — kalite, maliyet ve performans — ayrı ayrı değil, aynı zaman ekseninde yan yana görebilmektir. Çünkü bu üç boyut birbirinden bağımsız değildir; biri değiştiğinde çoğu zaman diğerini de etkiler. Bir sinyali tek başına izlemek, filin yalnızca bir bacağına dokunmaktır; korelasyon görünürlüğü ise resmin tamamını verir. Bunun neden kritik olduğunu bir örnek netleştirir. Diyelim ki maliyeti düşürmek için daha küçük ve ucuz bir modele geçtiniz. Maliyet panosu hemen düşüşü gösterir ve karar başarılı görünür. Ama aynı anda kalite panosuna bakmıyorsanız, o küçük modelin olumsuz geri bildirim oranını yükselttiğini ve yeniden sorma sıklığını artırdığını göremezsiniz. Tek panoda bakıldığında ise tablo nettir: maliyet düştü ama kalite de düştü — ve belki kullanıcıların iki kez sorması yüzünden toplam maliyet aslında beklenenden az düştü. İşte bu ödünleşimi ancak üç sinyali birlikte gördüğünüzde yönetebilirsiniz. Aynı korelasyon performans tarafında da geçerlidir. Gecikmeyi düşürmek için bağlamı kısaltmak, hem maliyeti azaltır hem de bazen kaliteyi düşürür — çünkü modele daha az bilgi verirsiniz. Bu üç yönlü ilişki, LLM izlemeyi bir "metrik toplama" işinden bir "karar destek" aracına dönüştürür. İyi tasarlanmış bir üretim izleme panosu, her önemli değişikliği (model, prompt sürümü, bağlam stratejisi) zaman ekseninde işaretler; böylece "bu değişiklikten sonra hangi metrik nasıl kımıldadı" sorusuna bakışta cevap verirsiniz. LLM izlemede en tehlikeli şey, tek bir sayıya bakıp karar vermektir. Gecikme mükemmel ama kalite çökmüş olabilir; maliyet düşük ama kullanıcı memnuniyetsiz olabilir. Kalite, maliyet ve performansı aynı panoda, aynı zaman ekseninde görmek, bir boyutu iyileştirirken diğerini bozmayı önler. Olgun bir izleme kültürünün işareti, bu üç metriği asla birbirinden ayrı okumamaktır. ## RAG ve Ajan Sistemlerinde İzlemenin Özel Zorlukları Tek bir model çağrısını izlemek görece basittir; ama üretimdeki çoğu ciddi LLM uygulaması artık ya bir RAG boru hattı ya da çok adımlı bir ajan sistemidir. Bu mimariler, LLM izlemeye kendine özgü ve daha zorlu gereksinimler getirir; çünkü hata, tek bir çağrıda değil, adımlar arasındaki bir yerde ortaya çıkabilir. Bu yüzden burada trace ve span yalnızca faydalı değil, zorunlu hâle gelir. RAG sistemlerinde izlemenin özel odağı getirme katmanıdır. Bir RAG yanıtı yanlış olduğunda iki temel olasılık vardır: ya yanlış belge getirildi (getirme hatası), ya da doğru belge getirildi ama model onu yanlış kullandı (üretme hatası). Bu ikisini ayırt edemezseniz, yanlış yeri onarmaya çalışırsınız. Bu yüzden RAG izlemesinde her isteğin getirilen belge kimliklerini, benzerlik skorlarını ve reranking sonrası sıralamayı loglamak gerekir. Böylece bir hata geldiğinde "doğru belge aday kümesinde var mıydı, varsa neden seçilmedi" sorusunu yanıtlayabilirsiniz. Kaynak sadakati sinyalinin bu bağlamdaki rolünü RAG değerlendirme yöntemi yazısında derinleştiriyoruz. Ajan sistemlerinde ise zorluk katmanlanır. Bir ajan; planlama yapar, araç çağırır, ara sonuçları değerlendirir ve döngüye girer. Burada izlenmesi gereken ek sinyaller vardır: kaç adımda çözdü (adım sayısı), hangi araçları çağırdı ve her araç çağrısı başarılı mıydı, döngüye girip girmediği (aynı adımı tekrar tekrar denemesi), ve toplam token/maliyetin adımlara dağılımı. Bir ajan sessizce on beş adımda çözdüğü bir görevi, bir prompt değişikliğinden sonra kırk adımda çözmeye başlayabilir — maliyeti ve gecikmeyi katlayarak. Bu ancak adım düzeyinde izleme ile görünür. Bu mimarilerde ortak ders şudur: ne kadar çok adım varsa, uçtan uca izlemeye o kadar çok ihtiyaç duyulur. Tek çağrılık bir sistemde giriş-çıkış izlemek yetebilir; ama çok adımlı bir sistemde her adımın ayrı görünür olması, kök neden analizini mümkün kılan tek şeydir. Üretimde AI sistemlerini ayakta tutmanın genel çerçevesini model izleme ve drift yazısında ele alıyoruz. ## Dağılım Kayması ve Model Sürüm Değişikliklerini Yakalamak Bir LLM sisteminin sessiz bozulmasının en sinsi iki nedeni, kullanıcı davranışının zamanla değişmesi (dağılım kayması) ve bağlı olunan modelin arka planda güncellenmesidir. İkisi de bir hata fırlatmaz; ikisi de yalnızca çıktının kalitesini kaydırır. LLM izlemenin görevi, bu iki sessiz kaymayı bir sinyale dönüştürüp görünür kılmaktır. Dağılım kayması (distribution shift), sistemin gördüğü giriş verisinin zamanla, tasarlandığı andaki dağılımdan uzaklaşmasıdır. Kullanıcılar başta beklenen türde sorular sorarken, zamanla yeni konular, yeni diller, daha uzun veya daha kısa girdiler getirmeye başlar. Sistem bu yeni dağılım için ayarlanmadığından, kalite fark edilmeden düşer. Bunu yakalamak için giriş verisinin özelliklerini izlemek gerekir: soru uzunluğu dağılımı, konu/niyet dağılımı, dil dağılımı ve bilinmeyen/kapsam dışı soru oranı. Bu dağılımlar temel çizgiden belirgin biçimde saptığında, bu bir uyarıdır — "kullanıcılar artık farklı sorular soruyor, sistem hâlâ eskisine göre mi tasarlı?" Model sürüm değişikliği ise dışarıdan gelen bir kaymadır. Bir dış sağlayıcının modelini kullanıyorsanız, o model arka planda güncellenebilir ve promptlarınız yeni sürümde farklı davranabilir — bazen daha iyi, bazen sizin özel senaryonuzda daha kötü. Bu yüzden her isteğe kullanılan model adını ve sürümünü loglamak (minimum alan setinde belirttiğimiz gibi) kritiktir: bir kalite düşüşünü "hangi model sürümünden sonra başladı" diye ilişkilendirebilmenin tek yolu budur. Aynı disiplin kendi promptlarınızın sürümleri için de geçerlidir; bir prompt değişikliğinin etkisini, değişiklik zaman çizelgesinde işaretlenmişse anında görürsünüz. LLM sistemlerinin sinsi bir gerçeği şudur: siz hiçbir şeyi değiştirmeseniz bile sistem bozulabilir. Model sağlayıcısı bir güncelleme yapar, kullanıcı davranışı kayar, bilgi tabanı eskir — ve sizin kodunuz aynı kalırken çıktı kötüleşir. Bu yüzden LLM izleme, yalnızca "ben ne değiştirdim" değil, "dışarıda ne değişti" sorusunu da yanıtlayacak sinyalleri toplamalıdır. Değişmeyen bir sistemi izlemeyi bırakmak, en tehlikeli varsayımdır. Bu iki kaymayı erken yakalamanın pratik yolu, düzenli bir karşılaştırmadır: değerlendirme setinizi her yeni model sürümünde ve belirli aralıklarla yeniden çalıştırıp skorları geçmişle karşılaştırmak. Bir regresyon gibi çalışan bu karşılaştırma, hem sizin değişikliklerinizin hem de dışarıdaki kaymaların etkisini sayıya döker. Değerlendirme setinin bu rolünü LLM değerlendirme nedir yazısında ayrıntılandırıyoruz. ## Güvenlik ve Kötüye Kullanımı İzlemek LLM izleme yalnızca kalite, maliyet ve performansla ilgili değildir; bir güvenlik katmanı da içerir. Üretimdeki bir dil modeli, kötü niyetli girdilere ve beklenmedik kötüye kullanıma açıktır; bunları görünür kılmak, izlemenin ihmal edilen ama giderek kritikleşen bir boyutudur. Güvenlik olayları, tam da kayıt tutulmadığı için en tehlikeli olanlardır — olan biteni sonradan anlayamazsınız. İzlenmesi gereken başlıca güvenlik sinyalleri şunlardır. Prompt injection işaretleri: kullanıcının modeli sistem talimatlarını yok saymaya veya gizli bilgiyi sızdırmaya kandırmaya çalıştığı girdiler; bu tehdidi prompt injection nedir yazısında ele alıyoruz. Guardrail tetiklenmeleri: güvenlik filtresinin veya koruyucu katmanın devreye girme sıklığı ve türü; ani bir artış, ya bir saldırı ya da bir sistem sorunu işaretidir. Koruyucu katmanların rolünü guardrail nedir yazısında bulabilirsiniz. Kişisel veri sızıntısı: modelin yanıtında maskelenmemiş kişisel veri veya bir başka kullanıcının bilgisinin görünmesi. Anormal kullanım desenleri: tek bir kullanıcıdan olağandışı hacimde istek, otomatik kötüye kullanım veya maliyet istismarı işareti. Bu sinyaller, güvenlik açısından iki amaca hizmet eder. Birincisi tespit: bir saldırı veya kötüye kullanım gerçekleştiğinde onu erkenden yakalamak. İkincisi kanıt ve denetim: bir olay olduğunda ne olduğunu geriye dönük inceleyebilmek. İkinci amaç için denetim kaydı (audit trail) kritiktir — kim, ne zaman, hangi isteği yaptı ve sistem nasıl yanıt verdi; bu kaydın rolünü audit trail yazısında ele alıyoruz. Güvenlik loglarının kendisi de hassas olduğundan, aynı KVKK dengesi (maskeleme, erişim kısıtı, saklama süresi) burada da geçerlidir. Güvenlik izlemesinin en kritik alarmları, ani sıçramalara kurulur: guardrail tetiklenme sıklığında bir zıplama, injection işareti taşıyan isteklerde bir artış veya tek kaynaktan gelen anormal trafik, çoğu zaman derhal insan müdahalesi gerektirir. Bu yüzden güvenlik alarmları genellikle "kritik" seviyesindedir ve net bir eylem planıyla gelmelidir. Güvenlik, LLM izlemenin kalite ve maliyet kadar ihmal edilmemesi gereken üçüncü ayağıdır. ## Geri Bildirim Döngüsü: İzlemeden İyileştirmeye İzlemenin nihai amacı, geçmişi seyretmek değil, geleceği iyileştirmektir. Topladığınız tüm sinyaller — geri bildirim, hata örnekleri, kalite skorları, dağılım kaymaları — ancak bir iyileştirme döngüsünü besliyorsa değer üretir. Aksi halde güzel panolar biriktirir ama sistem gerçekte iyileşmez. Bu döngü, LLM izlemeyi pasif bir gözlemden aktif bir mühendislik pratiğine dönüştürür. Geri bildirim döngüsü şöyle işler. Önce izleme, bir sorunu görünür kılar: olumsuz geri bildirim oranı yükseldi, belirli bir soru türü sürekli başarısız oluyor veya bir kalite skoru düştü. Ardından bu sinyal bir teşhise dönüşür: örneklem denetimiyle gerçek örnekler okunur ve kök neden bulunur — belki chunking bozuk, belki bir prompt yetersiz, belki model bir kenar durumu kötü ele alıyor. Sonra bir iyileştirme yapılır: prompt düzeltilir, getirme ayarlanır, bir kenar durum ele alınır. Ve kritik biçimde, o hata örneği değerlendirme setine eklenir — böylece bir daha geri dönmediğinden emin olunur. En son, iyileştirmenin gerçekten işe yaradığı yine izleme ile doğrulanır. Bu döngünün kalbinde, üretimden gelen gerçek verinin değerlendirme setini sürekli zenginleştirmesi vardır. Laboratuvarda hayal edilen test soruları asla gerçek kullanıcıların sorduğu tuhaf, beklenmedik ve kenar durumları kadar öğretici değildir. Bu yüzden olgun ekipler, üretim loglarını değerlendirme setinin en değerli kaynağı olarak görür: her gerçek hata, gelecekteki bir regresyonu önleyen bir test vakasıdır. Bu yaklaşımın MLOps'taki karşılığını MLOps nedir ve LLM'e özgü operasyonel çerçevesini LLMOps nedir yazılarında ele alıyoruz. Güzel panolar kurmak kolaydır; asıl zor olan, o panoların gösterdiği sinyalleri düzenli olarak eyleme çevirmektir. Bir izleme kurulumunun olgunluğu, kaç metrik topladığıyla değil, bu metriklerin kaç iyileştirmeyi tetiklediğiyle ölçülür. Sinyal → teşhis → iyileştirme → doğrulama döngüsü işlemiyorsa, izleme yalnızca dekoratif bir gösterge tablosudur. İzlemenin değeri, kapattığı döngüdedir. ## İzlemenin İş Değeri ve Ekip Sahipliği Teknik olarak sağlam bir LLM izleme kurmak yeterli değildir; bu izlemenin iş açısından neden değerli olduğunu ve kimin sahiplendiğini de netleştirmek gerekir. Aksi halde izleme, "güzel ama lüks" damgası yer ve ilk bütçe kısıtlamasında elenir. Oysa iyi kurulmuş bir izleme, doğrudan ölçülebilir bir iş değeri üretir. İzlemenin iş değeri birkaç kanaldan gelir. Maliyet tasarrufu: token israfını, yanlış model seçimini ve gereksiz uzun promptları görünür kılarak doğrudan faturayı düşürür; çoğu zaman izlemenin kendi maliyetinden fazlasını geri kazandırır. Risk azaltma: sessiz kalite bozulmasını, kişisel veri sızıntısını ve güvenlik olaylarını kullanıcı veya düzenleyici fark etmeden yakalayarak itibar ve uyum riskini düşürür. Hız: bir olay olduğunda kök nedeni saatler yerine dakikalar içinde bularak çözüm süresini kısaltır. Güven: kaliteyi ölçülebilir kıldığı için, sistemi genişletme kararlarını tahmine değil kanıta dayandırır. Bu değeri savunulabilir kılmak için bir temel çizgi (baseline) şarttır: izleme öncesi maliyet, hata oranı ve çözüm süresi ölçülmeden, izleme sonrası iyileşme iddiası havada kalır. Değer kadar önemli olan sahipliktir. İzleme, "herkesin işi olduğu için hiç kimsenin işi olmayan" bir alana düşmeye en yatkın konudur. Panolar kurulur, sonra kimse düzenli bakmaz; değerlendirme seti kurulur, sonra kimse güncellemez. Bunu önlemenin tek yolu, açık bir sahiplik atamasıdır: kim günlük bakışı yapıyor, kim haftalık örneklem denetimini yürütüyor, bir alarm çaldığında kim müdahale ediyor, değerlendirme setini kim güncelliyor? Bu sorulara net bir cevap yoksa, izleme zamanla ölü bir altyapıya döner. Küçük bir ekipte bu sorumluluklar tek bir kişide birleşebilir; büyük bir kurumda ayrı roller olabilir. Önemli olan rol sayısı değil, her sorumluluğun bilinçli olarak birine atanmasıdır. Bu yetkinliği kurumsal olarak kazanmak, çoğu zaman eğitim ve süreç tasarımı gerektirir; ekiplerinize yönelik eğitim programları ve bir izleme kültürünü ve mimarisini uçtan uca kurmak için danışmanlık desteğinden yararlanabilir, tüm kavramları öğrenme merkezinde derinleştirebilirsiniz. ## LLM İzleme ile LLM Değerlendirme Arasındaki Fark İki kavram sık karıştırılır: LLM izleme (monitoring) ve LLM değerlendirme (evaluation). İkisi de kaliteyle ilgilenir ama farklı zamanlarda, farklı sorulara cevap verir; ve olgun bir ekip ikisini birlikte kullanır. Bu ayrımı netleştirmek, hangi aracı ne zaman kullanacağınızı bilmenizi sağlar. Değerlendirme, çoğunlukla çevrimdışı (offline) ve önceden yapılır: bir değişikliği üretime çıkarmadan önce, etiketli bir test seti üzerinde sistemin kalitesini ölçersiniz. "Bu yeni prompt sürümü, eski değerlendirme setinde daha iyi mi çalışıyor?" sorusu bir değerlendirme sorusudur ve kontrollü bir ortamda cevaplanır. Değerlendirmenin metodolojisini LLM değerlendirme nedir yazısında ele alıyoruz. İzleme ise çevrimiçi (online) ve süreklidir: sistem üretimde, gerçek kullanıcıların önünde çalışırken davranışını gerçek zamanlı olarak takip eder. "Sistem şu anda, gerçek trafikte nasıl davranıyor?" sorusu bir izleme sorusudur. Bu ikisi birbirinin yerine geçmez; birbirini tamamlar. Değerlendirme, bir değişikliğin üretime çıkmadan önce güvenli olduğunu doğrular — bir kalite kapısı gibi çalışır. İzleme ise değerlendirmenin öngöremediğini yakalar: gerçek kullanıcıların değerlendirme setinde hiç olmayan tuhaf soruları, dağılım kayması ve dış model güncellemeleri. Değerlendirme "değişikliğim güvenli mi" der; izleme "üretimde gerçekte ne oluyor" der. En güçlü döngü, ikisini birleştirendir: izleme üretimden yeni hata örnekleri toplar, bu örnekler değerlendirme setini zenginleştirir, zenginleşen set bir sonraki değişikliği daha iyi korur. Pratik sonuç şudur: yalnızca değerlendirme yapıp izlemeyi atlarsanız, üretime çıktıktan sonra sistemin sessizce bozulmasını göremezsiniz. Yalnızca izleme yapıp değerlendirmeyi atlarsanız, her değişikliği doğrudan üretimde test edersiniz ve kullanıcıları denek yaparsınız. Sağlam bir yaklaşım ikisini bir hat üzerinde birleştirir: değerlendirme çıkıştan önce korur, izleme çıkıştan sonra korur, ve geri bildirim döngüsü ikisini besler. ## Örnek Bir İzleme Panosu Neye Benzer Soyut ilkeleri somuta indirmenin en iyi yolu, iyi tasarlanmış bir LLM izleme panosunun neye benzediğini hayal etmektir. Böyle bir pano, üç sinyal kategorisini tek bakışta okunabilir kılacak biçimde katmanlanır; üstte özet, altında kırılım, en altta ise ham izler bulunur. En üstte, sistemin genel sağlığını veren özet kartları yer alır: son bir saatteki istek sayısı, p95 gecikme, hata oranı, saatlik maliyet ve olumsuz geri bildirim oranı. Bu beş sayı, "her şey yolunda mı" sorusuna beş saniyede cevap verir; günlük hızlı bakışın hedefi tam olarak burasıdır. Her kartın yanında, o metriğin temel çizgiye (baseline) göre yukarı mı aşağı mı gittiğini gösteren bir eğilim oku bulunur — çünkü mutlak sayı kadar, yönü de önemlidir. Ortada, zaman serisi grafikleri gelir. Gecikme, token maliyeti ve kalite skoru aynı zaman ekseninde, üst üste çizilir; böylece korelasyonu gözle görürsünüz. Bir dikey çizgi, önemli bir değişikliğin (yeni model sürümü, prompt güncellemesi, bir dağıtım) tam olarak ne zaman yapıldığını işaretler. Bir kalite düşüşü bu çizgiyle çakışıyorsa, kök nedeni bulmuşsunuz demektir. Bu bölümün altında kırılımlar bulunur: özellik başına maliyet, model başına gecikme, hata türüne göre dağılım — hangi akışın sorunlu olduğunu buradan görürsünüz. En altta ise arama yapılabilir ham izler durur: her isteğin trace'i, maskelenmiş prompt/yanıtı ve tüm meta verisi. Bir alarm çaldığında veya bir kullanıcı şikayet ettiğinde, buradan ilgili isteği bulur ve trace'ini açarak adım adım incelersiniz. İyi bir pano, üstteki özetten alttaki tek isteğe kadar tek bir tıklamayla inmenizi sağlar — özet bir anormallik gösterir, tıklarsınız, kırılım daralır, ve nihayet sorunlu ham isteğe ulaşırsınız. Bu "üstten alta iniş" yeteneği, bir izleme panosunu dekoratif bir göstergeden gerçek bir teşhis aracına dönüştürür. Güncel araçların bu yetenekleri nasıl sunduğunu LLM gözlemlenebilirlik araçları yazısında ele alıyoruz. ## Küçük Ekipler ve KOBİ'ler İçin Pragmatik İzleme İzlemenin tüm katmanlarını anlatınca, küçük bir ekip veya sınırlı bütçeli bir KOBİ haklı olarak "bunların hepsini kurmaya ne zamanım ne kaynağım var" diye düşünebilir. İyi haber şu: LLM izleme, hepsi ya da hiç değildir. En yüksek getirili yüzde yirmilik kısım, doğru kurulduğunda değerin büyük çoğunluğunu verir; gerisi olgunlaştıkça eklenir. Küçük bir ekip için pragmatik asgari şudur. Her istek için dört sayıyı loglayın: gecikme, token sayısı, maliyet ve hata durumu. Bunlar ucuzdur, mahremiyet riski taşımaz ve bir tablolama aracında bile izlenebilir. Yanıtların yanına basit bir geri bildirim düğmesi koyun; en dürüst kalite sinyali budur ve kurulumu neredeyse bedavadır. Hata durumlarının ve olumsuz geri bildirim alan isteklerin tam (maskeli) kaydını tutun — hepsini değil, yalnızca sorunluları. Ve haftada bir, on beş dakikanızı ayırıp bu sorunlu örnekleri okuyun. Bu kadarı bile, hiç izlemeyen bir ekibe kıyasla devasa bir fark yaratır. Bu asgari kurulumun püf noktası, disiplinin araçtan önce gelmesidir. Pahalı bir gözlemlenebilirlik platformu almadan önce, hangi dört sayıyı toplayacağınıza ve bunlara kimin bakacağına karar verin. Birçok küçük ekip, gösterişli bir araca yatırım yapıp sonra kimse düzenli bakmadığı için hiçbir değer üretemez; oysa basit bir loglama artı haftalık bir inceleme rutini, çok daha azıyla çok daha fazlasını başarır. Araç seçimini erteleyip disiplini önce kurmak, KOBİ'ler için en akıllı yoldur. İzlemenin en büyük düşmanı karmaşıklık değil, ertelemedir. "Tam bir izleme altyapısı kuracak zamanımız yok" diyen ekipler çoğu zaman hiçbir şey kurmaz ve tamamen kör uçar. Oysa dört sayı ve bir geri bildirim düğmesi bile, hiç yoktan sonsuz kez daha iyidir. Mükemmel izleme kurulumunu beklerken hiç izlememek yerine, bugün asgari bir kurulumla başlayın; olgunlaştırmak için her zaman vakit olur, ama kaçırdığınız ilk haftaların sessiz bozulmasını geri getiremezsiniz. Büyüdükçe bu asgari kurulum kademeli derinleşir: trace/span eklenir, otomatik değerlendirme devreye girer, alarmlar temel çizgiye bağlanır. Ama yolculuk her zaman aynı yerden başlar — birkaç temel sayıyı loglamak ve onlara düzenli bakmak. Bu pragmatik yaklaşım, LLM izlemeyi büyük kurumların lüksü olmaktan çıkarıp her ölçekten ekibin erişebileceği bir disipline dönüştürür. Kurumunuzun ölçeğine uygun bir izleme yol haritası için danışmanlık desteğinden yararlanabilirsiniz. ## Bir Alarm Çaldığında: Olaya Müdahale Akışı İzlemenin gerçek sınavı, bir alarm çaldığı anda başlar. İyi kurulmuş bir üretim izleme sistemi, yalnızca sorunu haber vermez; onu hızla teşhis edip çözmenizi sağlayacak izleri de elinize verir. Bir alarm çaldığında izlenecek net bir akış, panik ile kontrollü müdahale arasındaki farktır. Bu akışı önceden tanımlamak, gece yarısı bir olayla uğraşırken doğaçlama yapmaktan çok daha güvenlidir. Tipik bir müdahale akışı şöyle işler. Önce doğrulama: alarm gerçek bir sorunu mu, yoksa geçici bir gürültüyü mü işaret ediyor? Panoya bakıp sapmanın sürüp sürmediğini ve kaç kullanıcıyı etkilediğini görürsünüz. Sonra sınıflandırma: bu bir performans sorunu mu (gecikme, hata), bir maliyet kaçağı mı, bir kalite düşüşü mü, yoksa bir güvenlik olayı mı? Alarmın hangi sinyal kategorisinden geldiği, bakılacak ilk yeri belirler. Ardından daraltma: zaman ekseninde sorunun ne zaman başladığını bulur ve o ana denk gelen bir değişikliği (yeni model sürümü, prompt güncellemesi, dağıtım) ararsınız. Çoğu üretim olayının kökü, sorunun başladığı anda yapılan bir değişikliktir. Daraltmadan sonra kök nedene inersiniz. Bir performans alarmında, yavaşlayan isteğin trace'ini açıp hangi span'in zamanı yediğini görürsünüz — vektör arama mı, model mi, bir dış araç mı? Bir kalite alarmında, olumsuz geri bildirim alan gerçek isteklerin maskeli prompt ve yanıtlarını okur, ortak deseni ararsınız. Bir maliyet kaçağında, hangi özellik veya kullanıcının token tükettiğini kırılımdan bulursunuz. Trace ve ham loglar burada altın değerindedir: onlar olmadan kök neden aramak tahmine döner, onlarla birlikte dakikalar sürer. Olgun ekipler, kritik alarmların her biri için kısa bir müdahale rehberi (runbook) tutar: bu alarm çaldığında önce şuraya bak, şu trace'i aç, sorun buysa şu adımı at, değilse şuraya yönlendir. Bu rehber, olay anında düşünmeyi azaltır ve deneyimi ekibe yayar. Bir alarmı kurup ona bir eylem planı yazmamak, yarı yapılmış bir iştir; alarmın değeri, tetiklediği net müdahalede saklıdır. Olay çözüldükten sonra iş bitmez; bir de öğrenme adımı vardır. Ne oldu, neden fark edilmesi bu kadar sürdü (veya bu kadar hızlı fark edildi), ve tekrarını önlemek için ne yapılmalı? Çoğu zaman cevap, o hata örneğini değerlendirme setine eklemek ve gerekiyorsa yeni bir alarm kurmaktır. Böylece her olay, sistemi bir sonraki sefere karşı biraz daha dayanıklı kılar. Bu döngü, izlemeyi tepkisel bir yangın söndürmeden, sistematik olarak güçlenen bir dayanıklılık pratiğine dönüştürür. ## Kurulum Sırası: LLM İzlemeyi Aşama Aşama Hayata Geçirmek LLM izlemeyi tek seferde, tüm katmanlarıyla kurmaya çalışmak yaygın ve pahalı bir hatadır; ekip, henüz değer üretmeden aylarca altyapıyla boğuşur. Doğru yaklaşım, izlemeyi değer sırasına göre aşamalı kurmaktır: en ucuz ve en yüksek getirili katmandan başlayıp ihtiyaç kanıtlandıkça derinleşmek. Aşağıdaki sıra, bir LLM izleme kurulumunu sağlam bir temelden olgun bir sisteme taşır. Bu sıradaki mantık, her adımın bir öncekinin üstüne değer katmasıdır. Temel metrikler tek başına bile "sistem hızlı mı ve pahalı mı" sorusunu yanıtlar ve en ucuz katmandır. Trace/span, bir sorun çıktığında onu teşhis edilebilir kılar. Maskeli prompt loglama, kalite denetiminin ham maddesini güvenli biçimde sağlar. Kalite sinyalleri, sessiz bozulmayı görünür kılar. Alarmlar, görünürlüğü eyleme çevirir. İnceleme rutini ise tüm bunları zamanla ayakta tutar. Her adımı, bir öncekinin değerini kanıtladıktan sonra eklemek, hem riski hem de gereksiz karmaşıklığı düşürür. Dikkat edilecek nokta, bu adımların hiçbirinin "bir kez yapıp bitirilecek" olmamasıdır. Sistem, model ve kullanıcılar değiştikçe izleme de evrilir. Bu yüzden LLM izleme, bir proje değil bir yetkinliktir — ekibin, üretimde bir dil modeli sistemini sağlıklı tutabilme kas hafızasıdır. Bu yetkinliği kurumsal olarak kazanmak için ekiplerinize yönelik eğitim programları ve bir izleme mimarisini uçtan uca tasarlamak için danışmanlık desteğinden yararlanabilirsiniz. ## LLM İzlemede Sık Yapılan Hatalar Teoride LLM izlemeyi anlamak kolaydır; üretimde işleyen sağlam bir kurulum yapmak ise deneyim ister. Tecrübeli bir gözle bakıldığında, izleme kurulumları benzer hatalarla aksar. En yaygın olanları şunlardır: - **Yalnızca altyapıyı izlemek:** Gecikme ve hata izlenir ama çıktı kalitesi izlenmez. Sistem "yeşil" görünürken kullanıcı kötü yanıtlar alır. LLM izlemenin özü, altyapının ötesine geçip kaliteyi de ölçmektir. - **Ham, maskesiz prompt loglamak:** Hata ayıklamayı kolaylaştırmak için tüm metni ham saklamak, doğrudan bir KVKK yükü ve sızıntı riski yaratır. Maskeleme baştan kurulmalıdır. - **Tek bir kalite sinyaline güvenmek:** Yalnızca kullanıcı geri bildirimine (seyrek) veya yalnızca otomatik değerlendirmeye (maliyetli, kusurlu) dayanmak yanıltır. Gözetim sinyalleri birleştirilmelidir. - **Statik alarm eşikleri:** Sabit sayılara bağlı alarmlar ya sürekli çalar ya hiç çalmaz. Eşikler temel çizgiye ve eğilime dayanmalıdır. - **Alarm yorgunluğu:** Çok fazla ve önemsiz alarm, ekibin hepsini görmezden gelmesine yol açar; gerçek kriz geldiğinde kimse bakmaz. Kritik alarmlar az ve anlamlı olmalıdır. - **Trace/span'i atlamak:** Çok adımlı bir sistemi yalnızca giriş-çıkışla izlemek, kök neden analizini imkânsızlaştırır. Enstrümantasyon baştan kurulmalıdır. - **İzlemeyi bir kez kurup unutmak:** Panolar kurulur ama kimse düzenli bakmaz; değerlendirme seti güncellenmez. İnceleme rutini olmadan izleme ölü bir altyapıdır. - **Maliyeti göz ardı etmek:** Token ve harcama izlenmeyince, bir kaçak yalnızca ay sonu faturasında fark edilir. Maliyet gerçek zamanlı bir sinyal olmalıdır. Bu hataların çoğu tek bir kök nedene dayanır: izlemeyi üretime çıkıştan sonraya bırakmak. Gözlemlenebilirlik altyapısı sonradan eklendiğinde, ilk haftaların sessiz bozulması geriye dönük teşhis edilemez ve mahremiyet ile enstrümantasyon kararları aceleyle, yanlış verilir. Doğru zamanlama, izlemeyi ilk kullanıcıdan önce kurmaktır — çünkü göremediğiniz bir sistemi yönetemezsiniz. Bu hatalardan kaçınmanın en pratik yolu, izlemeyi dar bir kapsamda ama baştan kurmaktır: tüm sistemi aynı anda mükemmel izlemeye çalışmak yerine, temel metriklerle başlayıp kademeli derinleşmek. Küçük ama sağlam bir izleme kurulumu, büyük ama hiç hayata geçmeyen bir izleme planından her zaman değerlidir. ## Kısaca: LLM İzleme Kısaca özetlemek gerekirse, LLM izleme, üretimdeki bir dil modeli uygulamasının kalitesini, maliyetini ve performansını loglama, trace/span ve alarm ile sürekli görünür kılan gözlemlenebilirlik disiplinidir. Klasik uygulama izlemesinden farkı, çıktının olasılıksal ve öznel olması nedeniyle yalnızca altyapıyı değil çıktının anlamsal kalitesini de ölçmesidir. Her istekten bir minimum alan seti loglanır; mahremiyet KVKK dengesiyle korunur; kalite, maliyet ve performans sinyalleri ayrı ayrı izlenir; alarmlar temel çizgiye dayanır; ve bir inceleme rutini tüm bunları yaşayan bir süreç hâline getirir. Bu disiplin, bir dil modeli uygulamasını demoda etkileyici ama üretimde kırılgan olmaktan çıkarıp, aylar boyunca güvenilir, öngörülebilir ve maliyeti kontrol altında çalışan bir sisteme dönüştürür; ve tüm bunu, sistemi gören ama görülmeyen sessiz bir gözlemci gibi yapar. En önemli mesaj şudur: bir LLM sistemi sessizce bozulur ve ölçmediğiniz şeyi yönetemezsiniz. Loglanmayan bir sistem kör uçar; tek bir metriğe bakan bir sistem yanıltılır; alarmı olmayan bir sistem sorunu kullanıcıdan öğrenir. İyi kurulmuş bir üretim izleme yaklaşımı — doğru loglama stratejisi, birleşik gözetim sinyalleri, disiplinli alarm kurulumu ve düzenli inceleme — bir dil modeli uygulamasını demodan üretime taşıyan köprüdür. Temel kavramlar için LLM nedir, LLM gözlemlenebilirliği nedir ve LLMOps nedir yazılarına bakabilir; kurumunuza özel bir izleme mimarisi ve ekip yetkinliği için danışmanlık ile eğitim programları seçeneklerini değerlendirebilir, tüm kavramları öğrenme merkezinde derinleştirebilirsiniz.