Bu sayfada
Yüz adımlık örnek bir tarayıcı görevi düşünün. Her adımın diğerlerinden bağımsız olarak %99 olasılıkla başarılı olduğunu varsayalım. Bütün adımların başarılı olma olasılığı 0.99^100, yani yaklaşık %36,6’dır.
Yüzde doksan dokuz kulağa mükemmel gelir. Yüzde otuz altı gelmez.
İşlemsel tarayıcı çalışmasına ilişkin kaynak tartışması bu hesabı dar bir noktayı göstermek için kullanır: müşteri, görev tamamlandığında değer elde eder; maliyet ve hata riski ise her adımda birikir. Bu, bir varsayım altında yapılan aritmetiktir; herhangi bir tarayıcı ajanı veya Tajo senkronizasyonu için yayımlanmış başarı oranı değildir. Gerçek hatalar birbirine bağlı olabilir. Süresi dolan tek bir oturum, sonraki birkaç işlemi birlikte bozabilir.
Dolayısıyla yararlı soru “Modelin son tıklaması ne kadar doğruydu?” değil, “Kullanıcının istediği durum oluştu mu?” sorusudur.
Önemli birim işlemin tamamıdır
Bir ajanın sigorta portalını açtığını, bir belge bulduğunu, indirdiğini ve belgenin doğru hesaba ait olduğunu doğruladığını hayal edin. Doksan dokuz ekranı doğru geçip yüzüncü ekranda yanlış dosyayı indirebilir. Başarılı tıklamalarla dolu çağrı kaydı, sonucu düzeltmez.
Aynı ayrım entegrasyonda da geçerlidir. Bir ajan API bulabilir, alan eşlemesi önerebilir ve taslak kaydedebilir. Bunların hiçbiri hedef sistemdeki kişinin artık amaçlanan iletişim izni durumuna sahip olduğu anlamına gelmez. İş ancak onaylanan işlem yürütülüp ilgili son koşul kontrol edildiğinde tamamlanır.
Bu, etkinlik ile tamamlanma arasındaki farktır. Etkinliği saymak kolaydır. Tamamlanmayı tanımlamak gerekir.
Dosya indirmede tanım, hesap numarası istekle eşleşen bir çıktı olabilir. Kişi senkronizasyonunda doğru tanımlayıcıyı, alanları ve izin verilen mesajlaşma durumunu taşıyan bir hedef kayıt olabilir. Denetim, kullanıcının önemsediği şeyi incelemelidir. Önceki çağrıdan gelen yeşil yanıt, çağrının yanıt verdiğini gösterir. Hedef sistemin amaçlandığı gibi değiştiğini göstermeyebilir.
Tajo’nun iş araçlarını bağlama kılavuzu iş akışı ve her veri nesnesinin doğruluk kaynağıyla başlar. Bu seçimler son denetime anlam kazandırır. İki sistem de aynı alanın sahibi olduğunu iddia ediyorsa kusursuz yürütülen bir yazma bile uzun vadede yanlış duruma yol açabilir.
Bir karar daha vermenin maliyeti
Aynı varsayımsal %99 oranıyla, birbirinden bağımsız on karar tüm zincirde yaklaşık %90,4 başarı verir. Elli karar yaklaşık %60,5, yüz karar yaklaşık %36,6 verir.
Tüm zincirin başarı olasılığı (%)
Bağımsız adım sayısı
- Adım başına varsayımsal %99 başarı
Hesaplanan değerleri okuyun
| Adımlar | Tüm zincirin başarısı (%) |
|---|---|
| 0 | 100,0 |
| 10 | 90,4 |
| 25 | 77,8 |
| 50 | 60,5 |
| 75 | 47,1 |
| 100 | 36,6 |
Eğri sert biçimde düşer; çarpma işlemi iyi bir ortalamaya ayrıcalık tanımaz. Her ek karar yerini hak etmelidir.
Bu, her API çağrısını dev bir işleme sıkıştırmak gerektiği anlamına gelmez. Bazı çağrılar deterministiktir: bilinen imleçle sayfa getirmek, tanımlayıcı karşılaştırmak veya onaylanmış eşlemeye göre alan yazmak. Modelin bunları her kayıt için yeniden kararlaştırmasına gerek yoktur. Diğer çağrılar gerçek belirsizlik taşır: yeni bir sağlayıcı alanı, değişen hata mesajı veya sahibi belirsiz istek. Bunlar muhakeme gerektirebilir.
Pratik ayrım, muhakemeyi bir kuralı tasarlamak veya onarmak için kullanıp istikrarlı kuralı sıradan kodla uygulamaktır. Reverse ETL tekrarlanan veri hareketine iyi bir örnektir: her rutin satır işlemini sohbet değil, veri hattı yapmalıdır. Ajan yine de hattın ne yapması gerektiğini belirlemeye yardımcı olabilir.
Bu bir sınırdır, slogan değil. Sağlayıcı bir alanın anlamını değiştirirse deterministik kural yanlış işlemi kusursuzca tekrarlayabilir. Sistem, varsayımlarının değiştiğini algılayıp vakayı incelemeye geri gönderebilmelidir.
Tek ve büyük bir araç çözüm değildir
Haklı bir itiraz şu olabilir: “Uzun zincirler bozuluyorsa bütün görevi tek araç çağrısına koyun.” Araç, sonucu denetlenebilir ve iyi tanımlanmış bir işlemse bu işe yarar. Yalnızca uzun ve belirsiz süreci gizliyorsa yaramaz.
syncCustomer() işlevinin güncelleme gönderdikten sonra success: true döndürdüğünü varsayalım. Hedef sistem güncellemeleri daha sonra işliyorsa çağrı son kişi durumunu henüz kanıtlayamaz. Araç, görünen adımları azalttı; belirsizliği azaltmadı.
Daha iyi bir arayüz önemli durumları gösterir: kabul edildi, uygulandı, kontrol edildi veya başarısız oldu. Bu sözcükler kanıta karşılık gelmelidir. Kabul edilmiş bir yazma, etkisi sınırlı bir önizleme için yeterli olabilir. Kampanya kitlesi veya iletişim izni değişikliği ise tamamlandı denmeden önce hedef sistem denetimini hak eder.
Bu önerilen Tajo görünümünde kabul edilen istek ve uygulanan güncelleme, doğrulanmış hedef durumundan ayrılır. Son kontrol hâlâ bekliyor. Sonraki iş bellidir: hedefin ne sakladığını incelemek. Bir başarılı araç çağrısı daha saymak ilk soruyu yanıtlamaz.
Tamamlanan yazma da kanıt gerektirir
Müşteri senkronizasyonu bitti mi?
Yazma uygulandı. Doğrulama bekliyor.
Hedefteki durum henüz kontrol edilmedi.
Senkronizasyon etkinliği
- İstek kabul edildi
- Güncelleme uygulandı
- Hedef kontrolü bekliyor
Örnek çalıştırma · 14:32 UTC
Bildiklerimiz
- Sağlayıcı yanıtı
- Kabul edildi
- Yazma sonucu
- Uygulandı
- Hedeften yeniden okuma
- Bekliyor
Başarılı çağrı son durumu kanıtlamaz.
Tajo etkinlik akışından esinlenen önerilen düzen. Bu çizim doğrulama durumu ekler; hedeften yeniden okumanın mevcut olduğunu iddia etmez.
Bu, ölçülecek şeyi de değiştirir. Maliyeti teşhis etmeye yardım ediyorsa deneme sayısını kaydedin. Bozuk adımı gösteriyorsa ara hataları kaydedin. Ancak iş akışını, yanında doğrulama yöntemi yazan doğrulanmış tamamlanmış işlemlerle değerlendirin. “Çağrıların %99’u başarılıydı” diyen ekip, müşterilerin işini bitirip bitiremediğini yanıtlamamıştır.
MCP sunucusu açıklaması araçların asistana başka bir sistemi nasıl çağırttığını gösterir. Araç erişimi yalnızca ilk adımdır. Asıl sözleşme, geride bırakılan durumdur.
Yüz başarılı tıklama yine de sonuçsuz kalabilir. Sonucu sayın.
Sık Sorulan Sorular
Adımları genellikle doğru olan uzun bir iş akışı neden başarısız olur?
Her adım birbirinden bağımsız olarak p olasılığıyla başarılıysa n adımlı zincirin başarı olasılığı p üzeri n'dir. Adım başına varsayımsal %99 başarıyla yüz adımlı zincir yaklaşık %36,6 olasılıkla tamamlanır. Gerçek hatalar birbiriyle ilişkili olabilir; bu hesap ölçülmüş bir ajan oranı değil, örnektir.
Araç çağrılarını azaltmak güvenilirliği garanti eder mi?
Hayır. Daha az çağrı ancak birleşik işlem doğru denetimleri ve kurtarma noktalarını koruyorsa yardımcı olur. Tek bir opak çağrı, uzun bir zincirin izini kaybetmesi kadar kolay biçimde başarısız bir yazmayı gizleyebilir.
Ekip bir ajan iş akışında neyi ölçmeli?
Yalnızca başarılı model çağrılarını değil, kullanıcının işleminin doğrulanmış tamamlanmasını ölçün. İşin bittiğini kanıtlayan çıktıyı veya hedef sistem durumunu tanımlayın; ardından bunun tüm iş akışından sonra ne sıklıkla ortaya çıktığını kaydedin.