Agentic Yapay Zekâda İz Sürmek: Monitor Et, Ölç, Kurtul

Geçen ay, İstanbul Maslak’taki bir ürün toplantısında şu cümleyi duydum: “Ajan çalışıyor ama neden bazen saçmalıyor?” İşte bu soru. Artık klasik yazılım dünyasının değil, yapay zekâ uygulamalarının en can sıkıcı sorusu haline geldi — ve açık konuşayım, cevabı da o kadar kolay değil. Sunucu ayakta mı? Evet. API cevap veriyor mu? Evet. Peki modelin verdiği yanıt güvenli mi, işe yarıyor mu, tutarlı mı? İşte asıl mesele tam da orada başlıyor — valla güzel iş çıkarmışlar —

Eskiden izleme dediğimiz şey çoğunlukla uptime, CPU ve hata kodlarıydı. Basitti. Şimdi iş değişti; bir LLM ya da agent tabanlı sistemde sadece “çalışıyor” demek yetmiyor. Çıktı anlamlı mı, yanlış yönlendiriyor mu, maliyeti şişiriyor mu, kullanıcıyı sinirlendiriyor mu… bunların hepsini görmek gerekiyor. Yani dürüst olmak gerekirse, yeni nesil gözlemleme biraz dedektiflik gibi. Hatta dedektiflikten de zor bazen.

Bakın, burayı atlarsanız yazının kalanı anlamsız kalır.

Neden klasik monitoring artık yetmiyor?

Klasik uygulamalarda problem genelde nettir. İstek gelir, servis işler, cevap döner. Ama agent tarafında araya — en azından ben öyle düşünüyorum — planlama girer, araç çağrıları girer, retrieval katmanı girer, prompt zinciri girer… derken iş öyle bir çorbaya dönüyor ki insan nereden başlayacağını şaşırıyor (eh, fena değil). Hatta geçen sene Ankara’da bir SaaS ekibinin demosuna bakarken bunu birebir gördüm; aynı prompt iki farklı saatte iki farklı sonuç verdi ve ekip “bu nasıl oldu?” diye birbirine bakakaldı. Oldu işte. Model böyle bir şey — istersen kabul et, istersen kabul etme.

Bu yüzden modern AI gözlemi yalnızca teknik metriklere bakmaz; davranışı da okur. Modelin ne söylediğini değil sadece, neden öyle söylediğini de izlemek gerekiyor (ciddiyim). Bu ayrım önemli. Çünkü kullanıcıya zararlı bir öneri veren sistem ile yavaş çalışan ama doğru öneri veren sistem arasında koca bir uçurum var — ve bu uçurumu uptime grafiğinden göremezsiniz.

Evet, doğru duydunuz.

Bak şimdi, Bir de şu var: AI uygulamalarında hata her zaman crash olarak gelmiyor. Bazen sessizce geliyor… yanlış bilgi üretiyor, gereksiz token harcıyor ya da tool çağrısını yanlış sırada yapıyor. Kötü haber şu ki bunu siz fark etmezseniz müşteri ilk fark eder. Ve o an pek hoş olmuyor.

Monitoring tarafında neye bakmalı?

Lafı gevelemeden söyleyeyim: iyi bir monitoring sistemi ajanların içini gösterebilmeli. Sadece son çıktıyı değil; prompt’u, bağlamı, kullanılan dokümanları, tool çağrılarını. Ara adımların tamamını tek bir timeline içinde görmek gerekiyor. Bunu bir otobüsün GPS’i gibi düşünebilirsiniz — sadece varış noktasını görmek yetmez, hangi duraktan geçtiğini de bilmeniz lazım, hatta bir durakta ne kadar beklediğini de.

Bunu biraz açayım.

Ben kendi testlerimde özellikle üç şeye takılıyorum: zincir izleri (trace), maliyet ve gecikme. Çünkü bunlar size çok hızlı sinyal veriyor. Mesela 20 istekte 19’u iyi çıkıyorsa ama biri aşırı token tüketiyorsa orada gizli bir problem vardır; belki prompt şişmiştir, belki retrieval fazla veri çekiyordur. O bir tane outlier’ı görmezden gelmeyin.

İzlenecek Alan	Neden Önemli?	Pratikte Ne Söyler?
Prompt ve bağlam	Ajanın neye göre karar verdiğini gösterir	Yanlış talimat mı verilmiş hemen anlaşılır
Tool çağrıları	Dış servislerin etkisini görünür kılar	Sorun modelde mi yoksa araçta mı belli olur
Token tüketimi	Maliyet kontrolü sağlar	Bütçe niye patladı sorusunun cevabı çıkar
Latency	Kullanıcı deneyimini doğrudan etkiler	Neden yavaşladığını tespit edersiniz

Şunu unutmayın: LLM uygulamalarında log’un güzel olması yetmez; okunabilir olması gerekiyor. Yani geliştirici masasında açıp bakınca “ha tamam, şurası bu” dedirtmeli. Yoksa log çöplüğü oluşur ve o çöplükten kimse ipucu çıkaramaz — ben de çıkaramam, siz de.

Bunu biraz açayım.

Zinciri görünür yapmak neden kritik?

Ajanın aldığı girdiyi, kullandığı sistem komutlarını ve dış araçlardan gelen çıktıları birlikte görmezseniz kök nedeni bulmak gerçekten zorlaşıyor. Hele bir de de RAG kullanan yapılarda sorun çoğu zaman modelde değildir; yanlış belge getirilmiştir ya da getirilen belge güncel değildir. Bu fark büyük.

Bir startup’ta çalışırken bunu acı şekilde yaşamıştık. Berlin merkezli küçük bir ekipti; destek botu eski politika dökümanını çekip kullanıcılara yanlış iade süresi söylüyordu. Model suçlu sanıldı ama aslında retrieval katmanı tarih filtresini atlıyordu… yani mesele bayağı daha aşağıdaymış. Günler harcandı o soruna.

Metrikler tek başına yeter mi?

Kısmen evet. Ama tek başına? Hayır. Token sayısı düşmüş olabilir ama kalite de düşmüş olabilir — işte tam burada değerlendirme devreye giriyor. Kimi ekip sadece maliyet düşüşüne seviniyor, sonra kullanıcı şikâyetleri patlıyor. Tanıdık geldi mi?

Eğer kurumsal ölçekteyseniz dashboard’da birkaç ekstra sayı daha istemeniz gerekiyor: başarı oranı, geri dönüş süresi, tool başarısızlığı oranı ve aynı isteğin farklı koşullardaki varyansı gibi şeyler. Küçük takımda bu kadar detay bazen ağır gelebilir, anlıyorum — ama enterprise tarafta bu veriler gerçekten altın değerinde oluyor. Bu konuyla ilgili PDF Dünyasında Bir Nefes: Ücretsiz ve Limitsiz Araçlar yazımıza da göz atmanızı tavsiye ederim.

Evaluation olmadan güven olmaz

Size bir şey söyleyeyim, Neyse uzatmayalım: monitoring size “ne oldu”yu söyler; evaluation ise “iyi miydi?” sorusunu cevaplar. Bu ayrımı sık kaçırıyoruz ama çok kritik. Çünkü AI çıktısı teknik olarak doğru olsa bile pratikte kötü olabilir — fazla uzun olabilir, kaba olabilir ya da kullanıcı niyetini büyük ölçüde kaçırabilir. Ve o zaman ne uptime ne de latency grafiği sizi kurtarır.

Açıkçası, Benim favori yaklaşımım iki katmanlı değerlendirme yapmak: biri otomatik skorlar için, diğeri insan gözü için. Otomatik taraf size hız veriyor; insan taraf ise ince ayarı sağlıyor (hani o garip ama önemli nüanslar var ya, onları yakalıyor). En çok da de de müşteri yüzüne çıkan ürünlerde bu ikili yapı bayağı iş görüyor.

AI sistemlerinde asıl risk çoğu zaman çökme değil; sessizce kötüleşme yaşanmasıdır.

Peki neyi ölçmelisiniz? Doğruluk elbette önemli ama yeterli değil — Güvenlik var mı? — Halüsinasyon üretiyor mu? — Aynı girdiye benzer cevap veriyor mu? — Kullanıcının beklentisine uyuyor mu? Bunların hepsi ayrı sinyal. Birbirinin yerine geçmiyor.

Tutarlılık testi neden iş görüyor?

Düşünün: aynı soruyu beş kere sorup beş farklı cevap alıyorsunuz (en azından benim deneyimim böyle). Orada problem var. Bazen model yaratıcı davranır ve bu hoş görünür; bazen de tutarsızlık yüzünden ürünü mahveder. Fark ince ama sonuçları çok farklı. Ben bunu özellikle içerik özetleme araçlarında gördüm — tek seferde gayet iyi çalışan sistem ertesi gün bambaşka bir karaktere bürünebiliyor. Şaşırtıcı derecede sinir bozucu! Butterfly CSS: 2026’da Dikkat Çeken Hafif Bir Seçenek yazımızda bu konuya da değinmiştik.

Küçük startup ile enterprise aynı şeyi ölçmemeli

Küçük ekipler için öncelik hızdır. Basit trace’ler, temel latency takibi ve birkaç kalite metriği yeterli olabilir — fazlasına gerek yok başlangıçta. Siz ne dersiniz? Enterprise tarafta ise iş büyüyor; rol bazlı erişim gerekiyor, denetim izi gerekiyor, versiyonlanan prompt arşivi gerekiyor ve model sürümü değişince hangi metriklerin oynadığı net görünmeli (bizzat test ettim)

Burada tavsiyem şu olurdu: önce minimum seti kurun, sonra genişletin. Her şeyi aynı anda ölçmeye kalkarsanız kimse panodan fayda sağlayamaz. Aksine herkes boğulur — ve boğulan ekip sonunda hiçbir şeye bakmaz. Daha fazla bilgi için NZXT Flex Davasında 3,45 Milyon Dolarlık Uzlaşma: Ne Değişiyor? yazımıza bakabilirsiniz. Bu konuyla ilgili Avrupa Verisini Claude’a Taşımak: Ücretsiz MCP Hamlesi yazımıza da göz atmanızı tavsiye ederim.

Peki debug nasıl yapılmalı?

Klasik debugger mantığını birebir kopyalamak burada yetmiyor ama benzetme yine de faydalı. Ajan akışını adım adım ilerletebilmek büyük bir rahatlık veriyor. Hot reload gibi düşünebilirsiniz; prompt’u değiştiriyorsunuz, state’i düzeltiyorsunuz, workflow’u yeniden çalıştırıyorsunuz… ve sonucu hemen görüyorsunuz. Bu döngü hızlandıkça iş de hızlanıyor. Bu konuyla ilgili Bilgiyi Kendi Makinenizde Toplamak: Yerel RAG Rehberi yazımıza da göz atmanızı tavsiye ederim.

{
"trace_id": "abc-123",
"prompt_version": "v14",
"tools": ["retriever", "calendar_api", "email_sender"],
"metrics": {
"latency_ms": 1840,
"input_tokens": 1220,
"output_tokens": 410
},
"flags": [
"retrieval_hit_low_confidence",
"tool_retry_detected"
]
}

Editör masasında bu tarz trace’leri incelerken en çok sevdiğim şey şu oluyor: hata artık soyut kalmıyor. Somutlaşıyor. Neden yanlış yanıt vermiş, hemen görüyorsunuz. Mesela İstanbul’daki bir e-ticaret ekibiyle yaptığım kısa testte ödeme linkinin yanlış gönderilmesinin sebebi model değildi; eski şablon kullanılmıştı. Basit gibi duruyor ama prod ortamda insanın başına ciddi bela oluyor — ve trace olmasa saatler kaybolurdu o soruna.

İyi observability’nin pratik faydası ne?

E tabi bunun sonunda üç büyük kazanım çıkıyor: daha az maliyet, daha iyi kalite ve daha kontrollü yayın süreci (en azından benim deneyimim böyle). Maliyet kısmı bariz; gereksiz token tüketimini erken yakalarsınız. Kalite kısmında ise kötü prompt’ları veya zayıf retrieval kaynaklarını düzeltirsiniz. Kontrol kısmı da ayrı önemli; çünkü deneme-yanılma yerine kanıtla ilerlersiniz. Tahmin eder misiniz? Bu fark kurumsal ortamlarda çok daha belirgin hissediliyor.

• Daha hızlı kök neden analizi
• Daha düşük operasyon maliyeti
• Daha güvenilir kullanıcı deneyimi
• Daha temiz prompt iterasyonu

Bence en güzel tarafı şu: ekip içinde tartışma azalıyor. “Model bozuk” yerine “bak burada tool retry artmış, şuradan bakayım” diyebiliyorsunuz. İnanın bu küçük cümle farkı bile toplantıyı kurtarıyor — hatta bazen neredeyse tüm geceyi.

Beni şaşırtan eksik taraflar da vardı

Açık konuşayım: observability araçlarının bazıları hâlâ ham. Arayüzler güzel, ama derinlik eksik olabiliyor. Trace’i görüyorsunuz fakat bağlam penceresinin neresinde kırıldığını anlamak zorlaşıyor — bu sinir bozucu, gerçekten. Bir başka hayal kırıklığı da değerlendirme setlerinin çabuk bayatlaması; ürün büyüdükçe test senaryolarınızı yenilemeniz şart, yoksa ölçtüğünüz şey artık gerçeği yansıtmıyor.

Yani mesele sadece teknoloji seçmek değil, operasyon disiplini kurmak. Bu disiplin yoksa en iyi panel bile duvar süsüne döner. Ve o noktaya gelince, başa dönmüş olursunuz — “ajan çalışıyor ama neden saçmalıyor?” sorusuyla.

Sıkça Sorulan Sorular

Agentic yapay zekâda observability tam olarak nedir?

Ajanın hangi girdiyi aldığını,hangi araçları çağırdığını,hangi çıktıyı ürettiğini. Bunun ne kadar iyi olduğunu birlikte izleme pratiğidir. Sadece uptime bakmak yetmez; davranışı da görmek gerekir.

Monitoring ile evaluation arasındaki fark nedir?

Monitoring operasyonel görüntü sağlar: ne oldu,nerede yavaşladı,hangi araç patladı. Evaluation ise kaliteyi ölçer: çıktı doğru muydu,güvenli miydi,tutarlı mıydı.

Küçük ekipler nereden başlamalı?

Önce temel trace kaydı,token takibi. Latency metriğiyle başlayın. Sonra örnek senaryolar için küçük bir evaluation seti kurun. Her şeyi aynı anda yapmak genelde işleri karıştırır.

Ana risk nedir?

Ana risk sessiz hata üretimidir. Sistem çalışır görünür ama yanlış öneriler verir,fazla maliyet çıkarır ya da tutarsız davranır. En tehlikelisi de budur çünkü geç fark edilir.

Kaynaklar ve İleri Okuma

Bi saniye — Orijinal İngilizce Makale (inanın bana)

Araya gireyim: LangSmith Dokümantasyonu

TruLens Resmi Sitesi ve Dokümantasyon (buna dikkat edin)

{“anchor”:”Bilgiyi Kendi Makinenizde Toplamak”,”url”:”https://www.netmerkezi.com/bilgiyi-kendi-makinenizde-toplamak-yerel-rag-rehberi/”}