--- title: "Bölüm 2: Yapay Zeka Ajanı Vakalarımızın Kök Nedenlerini Çözdük: Adım Bazlı Model Yönlendirmesi Gecikmeyi %86 Azalttı" url: https://blog.edumints.com/bolum-2-yapay-zeka-ajani-vakalarimizin-kok-nedenlerini-cozduk-adim category: "LLM" date: 2026-10-24T09:05:31.486Z publisher: Edumints Blog lang: tr-TR source_name: "dev.to" source_url: https://dev.to/aiwithsamarth/part-2-we-fixed-the-root-causes-of-our-ai-agent-incident-routing-models-by-step-cut-latency-86-30b3 --- # Bölüm 2: Yapay Zeka Ajanı Vakalarımızın Kök Nedenlerini Çözdük: Adım Bazlı Model Yönlendirmesi Gecikmeyi %86 Azalttı *Not: Bu senaryo, ajan sistemlerinde sıkça karşılaşılan gerçek üretim (production) hata kalıplarından derlenmiş temsili bir çalışmadır. Destek talebi numaraları (Ticket ID), tutarlar, gecikme süreleri ve olasılıklar örnekleme amaçlıdır.* İlk bölümde, faturalandırma ajanımızın bir insana yönlendirmesi gereken 48.000 dolarlık bir iadeyi kendi başına onaylamasını ele almıştık. Ajanı beş kez yeniden çalıştırmanın hiçbir şeyi kanıtlamadığını göstermiş, ardından kesme noktası (cut-point) tekrarı ve deterministik bir kontrol kapısı (gate) kullanarak çözümü doğrulamıştık. Bu kapı kanamayı durdurdu ancak ajanın en başta neden yanlış sonuca vardığını açıklamadı. Bu yazıda ise hatanın kaynağındaki üst akış (upstream) nedenlerine ve `TICKET-8841` iz kaydının ikinci yarısına odaklanıyoruz: Altı adımlı bir destek talebi neden 42,6 saniye sürdü ve 0,184 dolara mal oldu? ## Perde III: Üst Akıştaki Kök Nedeni Çözmek Kontrol kapımız 5. Sınırda (Boundary 5) yer alıyor. Ancak ajan o noktaya 2. ve 3. Sınırlarda yaşananlar yüzünden geldi. Olay sonrası değerlendirme (post-mortem) toplantımızda bir ekip üyesi hemen şu soruyu sordu: *"Neden hâlâ bir RAG (Retrieval-Augmented Generation) hattı yönetiyoruz? Güncel öncü modellerin artık 1 milyon token'lık bağlam pencereleri var. 350 sayfalık Finans ve Sözleşme El Kitabı'nın tamamını doğrudan isteme (prompt) gömelim."* Haklı bir soruydu, biz de test ettik. ## "El Kitabını Doğrudan İsteme Gömelim" Yaklaşımı Neden Kazanamadı? Modern yazılım geliştirmede geniş bağlam pencereleri her derde deva gibi görünse de üretim ortamında üç temel engele takıldı: - **Maliyet (Cost):** 350 sayfalık bir el kitabı 1 milyon değil, yaklaşık 175.000 token tutar. Milyon girdi token'ı başına temsili 3,00 dolar üzerinden hesapladığımızda: - Önbelleksiz (uncached), talep başına tek çağrı: `175.000 token × 3,00 $ / 1M = çağrı başına 0,525 $ × ayda 45.000 talep ≈ 23.600 $/ay` - ~%90 istem önbellekleme (prompt-cache) indirimiyle: `≈ 2.400 $/ay` Bizim RAG erişim hattımız ise ayda yaklaşık 600 dolara mal oluyordu. Önbellekleme ile maliyet farkı dramatik olmasa da el kitabını taşıyan her ekstra ajan adımı bu rakamları katlamaktadır. - **Geri Çağırma / Hatırlama (Recall):** Uzun bağlam performansı artık iyi olsa da kusursuz değil. Anthropic'in Opus 4.6 için 8 iğneli, 1M token'lık MRCR v2 testindeki lansman verileri %76 civarındaydı. Sentetik bir kıyaslama bizim belgelerimiz hakkında kesin konuşmasa da şunu netleştirir: *"Model ilgili maddeyi nasıl olsa bulur"* iddiası mutlaka ölçülmelidir; finansal bir sözleşmede gözden kaçacak tek bir maddenin bedeli çok ağırdır. - **İzlenebilirlik (Traceability):** Bizim için en belirleyici argüman buydu. RAG kullanıldığında, isteme giren tam metin parçaları (chunks) küçük, kayıt altına alınabilir (loggable) ve yeniden oynatılabilir birer yapı taşıdır. 175 bin token'lık bir metin yığınında ise modelin hangi sözleşme maddesine dayandığını bilemezsiniz ve el kitabındaki her düzenleme tüm isteminizi değiştirir. Bu yüzden RAG mimarisini koruduk. Asıl sorunumuz, 2026 yılında hâlâ 2023 döneminden kalma bir "RAG v1" çalıştırıyor olmamızdı. ## Hata 1: Sabit Boyutlu Parçalama (Fixed-Size Chunking) Koşulu Formülden Kopardı Veri işleme betiğimiz PDF'leri her 512 token'da bir bölüyordu. Gece 02:14'te vektör veritabanında şu iki parça duruyordu: - **chunk_041 (512. token'da bitti):** *"...Kurumsal Yıllık planlar için koltuk sayısı azaltma talepleri, yenileme tarihinden en az 30 takvim günü önce yazılı olarak iletilmelidir. Dönem ortası veya geç yapılan azaltmalar iade edilemez ve yalnızca bir sonraki yenileme döneminde geçerli olur."* - **chunk_042 (513. token'da başladı):** *"Tablo 4.2 — Koltuk Azaltma Kıstelyevm (Pro-Rata) İade Formülü: credit_usd = (önceki_koltuk - yeni_koltuk) * yıllık_koltuk_fiyatı * (kalan_gün / 365) ..."* Müşterinin mesajında geçen *"40 koltuk düşürdük"* ve *"faturalandırıldı"* ifadeleri formül tablosuyla güçlü bir eşleşme sağladı. `chunk_042`, **0,86** kosinüs benzerliği (cosine similarity) skoru alırken; formülü geçersiz kılan asıl koşulu barındıran `chunk_041` ise **0,71** skorda kalarak dışarıda kaldı. **Geliştiriciler İçin Pratik Çıkarım:** Üretim ortamındaki RAG sistemlerinde belgeleri körü körüne sabit token sayılarına göre bölmek, anlamsal bütünlüğü parçalar. Bir iş kuralının istisnası ile hesaplama formülü iki ayrı parçaya düştüğünde, ajan yalnızca formülü çekip felaketle sonuçlanan kararlar alabilir. Doküman yapısına duyarlı (semantic/document-aware) parçalama ve üstveri (metadata) kullanımı, ajan güvenilirliği için kritik bir zorunluluktur. --- Bu konuyu derinlemesine öğrenmek isterseniz: [Production'da Agent Güvenilirliği](https://edumints.com/kesfet/production-agent-orchestration-crewai-ve-autogen-i-u3cu) modülüne göz atın. --- **Kaynak:** dev.to (https://dev.to/aiwithsamarth/part-2-we-fixed-the-root-causes-of-our-ai-agent-incident-routing-models-by-step-cut-latency-86-30b3) **Yayıncı:** [Edumints Blog](https://blog.edumints.com) · Alıntılarken bu URL'ye bağlantı verin: https://blog.edumints.com/bolum-2-yapay-zeka-ajani-vakalarimizin-kok-nedenlerini-cozduk-adim