AgentOps Değil: İzleme Yığınınızda Neler Bozuluyor?
Uzun yıllardır, bir modeli üretimde sağlıklı tutmak, gönderdiğiniz modele yakın kalmak anlamına geliyordu. Modelin kaymasını referans penceresiyle karşılaştırırdınız. Gecikmeyi hizmet düzeyi anlaşması (SLA) ile takip ederdiniz. Doğruluğu ayrı bir veri kümesiyle kontrol ederdiniz. Bir sayı değiştiğinde, modeli yeniden eğitirdiniz.
Ancak bu durum, modeller araçlar çağırmaya başladığında işlevsiz hale geldi.
Sektörün tepkisi hızlı oldu. Gartner, 2027’nin sonunda ajan tabanlı yapay zeka projelerinin %40’ından fazlasının iptal edileceğini tahmin ediyor; bunun nedeni artan maliyetler, belirsiz değer ve yetersiz risk kontrolleri. Her izleme sağlayıcısı artık ajan takibi özelliğini sunuyor.
Ancak çoğu ekip bu geçişin nasıl yapıldığını yeterince incelemedi. Çoğu, yeni bir katman ekledi: mevcut yığına yeni takip verileri eklendi; hiçbir şey kaldırılmadı. Miras alınan sinyaller hala çalışıyor ve bazıları, aslında başarısız olan çalıştırmalar hakkında sağlıklı olduğunu bildiriyor.
Bunu, çok aşamalı bir inceleme hattından öğrendim; bu hat, paralel model inceleyicilere ayrılıyor ve kararlarını bir uygulama veri deposuna yazıyor. İlk kötü karar, tamamen yeşil bir takip verisine sahipken verildi: her adım başarılıydı, gecikmeler normaldi, çıktı yanlıştı.
Eklenenler gerçek ilerlemeyi temsil ediyor. OpenTelemetry’nin GenAI semantik tanımları artık ajan adımlarını tanımlıyor: `create_agent`, `invoke_agent`, `execute_tool` ve `plan`. Bu tanım hala “Geliştirme” aşamasında, bu nedenle standartlaştırma yapmadan önce dikkatli olmak önemlidir.
Langfuse, LangSmith, Arize Phoenix, W&B Weave ve AgentOps gibi araçlar, çalıştırmanın akışını gösteren çeşitli versiyonları sunuyor: hangi aracın çağrıldığı, ne döndürdüğü ve bunun maliyeti.
Ancak yeterince incelenmeyen kısım, bunların altındaki her şeydir. Kayma izleyicileri çalışmaya devam etti. Yeniden eğitim tetikleyicileri eski eşikleriyle kaldı. Ve uyarılar tek bir sınıra bağlı kaldı. Bu bileşenler, statsız bir puanlama hizmeti için geçerli olan varsayımları kodluyor ve bu varsayımların artık döngüsel bir sistemde geçerli olmadığı durumlarda sorunlara yol açıyor.
Beş temel varsayım en büyük etkiye sahip:
1. Çıktılar, çalıştırmalar arasında karşılaştırılabilir. Aynı girdi, yaklaşık olarak aynı çıktı anlamına gelir; bu nedenle bir fark bir şeyin göstergesi olabilir.
2. İnferans statsızdır. İstek, işlenen birimdir; hiçbir şey taşınmaz.
3. Tek bir istek, tek bir karar sınırını geçer. Bir eşik ayarlamak için tek bir yer vardır.
4. Doğru etiketler sonunda gelir. Bir modelin çıktısını puanlamak için bir etikete ihtiyaç vardır.
5. Model ile sonuç arasında bir insan bulunur. Model önerir; bir kişi hareket eder.
Bu beş varsayımın her biri, döngüsel bir sistemde farklı şekillerde bozulur ve bu durumlar, onları yakalamak için tasarlanmış sinyaller tarafından genellikle fark edilmez.
Aynı destek biletini iki kez çalıştırın. Pazartesi günü müşteri desteklenir ve kapatılır; Perşembe günü sipariş numarasıyla ilgili bir döngüye girilir ve müşteri zaten sağladığı bilgiyi tekrar sağlamak zorunda kalır.
Tau-bench, `pass^k` metriği ile bu durumu ölçer: tüm k denemelerinin başarılı olma olasılığı. Tek bir gpt-4o çalıştırması yaklaşık %61’lik perakende görev başarısı sağlar, ancak aynı görevi 8 kez çalıştırırsanız, tüm 8 çalıştırmanın başarılı olma olasılığı %25’in altına düşer. Ajanınızı tek bir girdi için çalıştırarak değerlendirin ve gösterge tablolarınız aslında kullanıcılarınızın gördüğü güvenilirliğin 2,4 katı olduğunu bildirir.
Bir kurye, ilk durakta sokağın adını yanlış duyar. Bundan sonraki her dönüş mükemmeldir, ancak hepsi yanlıştır.
Ajan sistemleri de aynı şekilde başarısız olabilir. Anthropic’in kendi çoklu ajan araştırması sistemi bu kalıbı doğrudan gösterdi: “Tek bir adımın başarısız olması, ajanların tamamen farklı yörüngeleri keşfetmesine neden olabilir.” Her adımın çıktısı bir sonraki adıma beslenir, bu nedenle erken bir hata düzeltilmez; bunun yerine artar.
Bu, nadir bir durum değildir. MAST taksonomisi, 1600’den fazla çalıştırmayı 14 başarısızlık moduna ayırdı ve en büyük kategori “sistem tasarımı” idi: adımların çıktısında değil, adımlar arasındaki bağlantılarda bulunan hatalar. Yeniden eğitim bir modeli düzeltebilir; çünkü hata modelde değil, yolda bulunuyordu.
Tek bir eşik, tek bir yer varsayar. Ancak 10 adım içeren bir çalıştırma yalnızca her adım başarılı olduğunda başarılı olur ve olasılıklar çarpılır. Her adımın %85 başarı oranı ile sağlıklı bir gösterge tablosu olsa bile, 10 adımı çalıştırdığınızda, %20’lik bir başarı oranı elde edersiniz. Tek bir temiz çalıştırma beş tanesinden biriyle sonuçlanır.
Adım başına izleme, her adımın başarısını değil, tüm çalıştırmanın başarısını raporlar.
Ajanınız bir bilet oluşturur, CRM kaydını günceller ve bir yanıt taslağı hazırlar. Bir insan bu yanıtı Perşembe günü okur; CRM kaydı okunmamış kalır.
Geleneksel izleme, modelin çıktısını doğru etikete karşı karşılaştırarak doğru olup olmadığını kontrol eder, ancak bu etiketin nereden geldiği önemlidir. Çıktı bir tahmin olduğunda, bir insan onu hızlı bir şekilde etiketleyebilir. Ancak çıktı bir eylem olduğunda, tek gerçek yargıç, sonucu birkaç gün sonra veya hiç okumayan bir insandır.
Bu nedenle ekipler, daha ucuz otomatik bir doğrulayıcı kullanır: çıktıyı kontrol eden bir betik, ancak bu kişi tarafından okunup doğrulanmaz. MAST, “birçok mevcut doğrulayıcının yalnızca yüzeysel kontroller gerçekleştirdiğini” buldu; örneğin, kodun derlenip derlenmediğini kontrol ederken, doğru olup olmadığını kontrol etmez. ChatDev tarafından oluşturulmuş bir satranç programı, bu kontrollerden hepsini geçti, ancak yine de çalışma zamanı hatalarına sahipti ve ProgramDev ölçütünde yalnızca %25 başarı elde etti.
Bu varsayım en pahalı olanıdır; çünkü ajan sadece tahmin etmekle kalmaz, aynı zamanda eyleme geçer. İnsanı kaldırın ve iz (ajanın yaptığı şeyin kaydı), eylemin doğru olup olmadığını gösteren tek kanıtınız olur.
Ancak bir iz sahte olabilir, hatta yanlışlıkla. Bir CrewAI sorunu, ajanların sahte ama ikna edici bir dizi yazıp yazdığını belgeledi: “aracı çağırdım, işte ne döndürdü”, ancak araç aslında çağrılmamıştı. Model sadece gerçek bir araç çağrısı ve sonucu gibi görünen metin oluşturdu. Yerel araç çağrısı (sistemin, modelin değil) eylemi gerçekleştirdiği durumlarda bu özel hata önlenir. Ancak daha derin sorun devam eder: hattınız tamamen yeşil olsa bile, yine de yanlış olan bir şey hakkında bilgi veriyordu.
Bir sinyali durdurmak, yeni bir sinyal eklemekten daha zordur. Aşağıdaki eşlemeyi kullanabilirsiniz:
| İzlenen şey | Bu izlemenin yakalayamadığı durum | Bunun yerine neyi izleyin |
| ——————————————— | ——————————————————————— | ——————————————————————————————– |
| Çıktılar karşılaştırılabilir | Çalıştırmalar arasında tutarsızlık | Tekrarlanan denemelerde `pass^k` metriği |
| İnferans statsızdır | Yoldaki bir hata, ancak temiz bir çıktı | Adım başına durumla yeniden oynatma |
| Tek karar sınırı | Her adımın başarılı olması gereken çok adımlı bir çalıştırma | Tüm yolda başarısızlık oranı |
| Etiketler gelir | İnsan tarafından doğrulanmayan eylemler | Eylem öncesi kapılar (her yan etki için) |
| Model ile sonuç arasında insan var | Yanlış bir çıktı, ancak gösterge tablosu hala “sağlıklı” diyor | Tek adımda başarısızlıkların sayısı (5’ten fazla tekrar varsa durdurun) |
Çıktılar karşılaştırılabilir: Adım başına doğruluk, tek bir örnekte. Tekrarlanan denemelerde tutarsızlık.
İnferans statsızdır: İstek düzeyinde başarı ve gecikme. Yoldaki bir hata, ancak temiz bir çıktı. Trajectory replay ile adım başına durum.
Tek karar sınırı: Adım başına başarı oranı. Çok adımlı bir çalıştırmada başarısızlık. Trajectory completion rate.
Drift karşı referans penceresi: Bir politika değişikliği, ancak veri değişimi yok. Sürüm kontrollü ajan yapılandırması, her çalıştırma için farklı.
İnsan model ile sonuç arasında var: Tek eşik uyarı. Yanlış bir çıktı, ancak gösterge tablosu hala “sağlıklı” diyor. Eylem öncesi kapılar (her yan etki için).
En uç durumlar hariç tutulmalıdır. Ajanınız yalnızca okuma yapıyorsa ve her çıktıyı bir insan okuyorsa, mevcut yığın ve adım düzeyinde izleme yeterlidir. Aksi takdirde, tam bir çalıştırmayı izlemelisiniz.
Çoğu durumda şu iki soru karar verir:
1. Sistem, eylemden önce bir insan tarafından mı doğrulanıyor? Bir kişi her çıktıyı okursa, risk sınırlıdır ve çıktı düzeyinde izleme çoğu sorunu çözer.
2. Kararları dış etkilere neden oluyor mu? CRM kaydına yazma, ödeme yapma, mesaj gönderme veya dağıtım tetikleme gibi. Eylemler bir kalite sorununu bir olaya dönüştürür.
Bu iki durumdan herhangi biri geçerliyse, daha temkinli olanı seçin. Tam bir çalıştırmayı izlemek, depolama maliyetine neden olurken, çıktı düzeyinde izleme, müşterinin gösterge tablonuz tarafından rapor edilmeden önce meydana gelen bir olaya neden olabilir.
Tüm ajanları aynı anda değil, aşamalı olarak uygulayın. İlk olarak, yazma yetkisine sahip tek ajanı seçin, tam çalıştırmasını izleyin, yineleme sınırını ayarlayın ve yan etkilerini engelleyin. Diğer ajanlar için mevcut olanı kullanmaya devam edin.
İzlenen kısım bu geçişin ucuz kısmıydı. Pahalı kısım, hangi miras sinyallerine güvenmeyi bırakmanız gerektiğini ve bir ajanın eylem gerçekleştirmesinden önce bunu yapmanız gerektiğini anlamaktır.
Sierra: `tau-bench` (tutarlılık ölçümü).
UC Berkeley: Çoklu Ajan LLM Sistemleri Neden Başarısız Olur? (Çoklu ajan başarısızlık taksonomisi).
Anthropic: Çoklu ajan araştırma sistemimizi nasıl oluşturduk (durum, birikimli hatalar ve belirteç katlaması).
OpenTelemetry: GenAI ajan adımları (bir ajanı satıcıdan bağımsız olarak izleme).
NVIDIA: NeMo Ajan Araç Kiti (iş akışlarını ajan düzeyinden token’a kadar profilleme).
Gartner: 2027’nin sonunda, yapay zeka projelerinin %40’ından fazlası iptal edilecek (her yönetim kurulu sunumunda alıntılanan tahmin).
Okuduğunuz için teşekkürler. Ben Mostafa Ibrahim, Codecontent’in kurucusuyum; bu, geliştirici odaklı bir teknik içerik ajansıdır. Ajan tabanlı sistemler, RAG ve üretim yapay zekası hakkında yazıyorum. İletişimde kalmak veya bu makaledeki fikirleri tartışmak isterseniz, LinkedIn’de benimle iletişime geçebilirsiniz.
Claude Code’u sürekli öğrenmeyle nasıl geliştirirsiniz?
R programlama dili için pratik bir rehber.
Ve neden alan uzmanlığının yapay zeka algoritmalarında önemli olduğunu…
Kodlama ajanlarıyla MVP oluşturarak ürün fikirlerini etkili bir şekilde nasıl sunarsınız?
Bu Gelişmeyi Toplulukta Değerlendirin
Haber hakkındaki düşüncelerinizi, donanım deneyimlerinizi ve teknik sorularınızı topluluk üyeleriyle anlık olarak tartışın.
Bir yanıt yazın