AI ajanı her adımda süre sınırına uyuyor; bütün iş neden gecikiyor?

Her çağrı zamanında dönse de iş geç bitebilir

Ajanın üç araç çağrısına dörder saniye izin veriliyor. Her çağrı kendi sınırını aşmadan bitiyor; kullanıcıya verilen on saniyelik toplam süre sözü yine tutulamıyor. Sorun tek bir yavaş araç olmayabilir. Her adımda tam sürenin yeniden başlatılması, bütün iş için ortak bir bitiş sınırı olmadığı anlamına gelir. Temizlik ve sonuç hazırlama da süre kullanıyorsa fark daha büyür.

gRPC’nin deadline açıklaması, bir çağrının hangi ana kadar tamamlanması gerektiğiyle süre sınırını ilişkilendirir; başka çağrılara aktarımda geçen sürenin hesaba katılmasını ele alır. Bu yazıda aynı bütçe ilkesini üç adımlı sentetik bir ajan akışına uygulayacağız. gRPC kullanan gerçek bir servis çalıştırmıyoruz; sayılar hesap ve karar sınaması için seçilmiştir.Kaynak: gRPC — Deadlines

Çıktı yalnız yeni bir timeout değeri olmayacak. Her adımın başlangıcı, kalan çalışma süresi, izin verilen süre ve sonuç durumu ayrı kaydedilecek. Böylece “zamanında bitti” cümlesinin başarılı tamamlanmayı mı, yoksa zamanında durdurulmuş bir işi mi anlattığı anlaşılacak.

On saniyeyi baştan paylaştırın

İlk denemede aktarım ve çizelgeleme ek yükünü sıfır kabul ediyoruz. Bu iyimser varsayım bile üç adımın başarıyla tamamlanmasına yetmez: çalışma toplamı 12, temizlikle birlikte 13 saniyedir. Gerçek ek yükler eklenirse bütçe daha da daralır. Bu nedenle tabloyu ölçülmüş servis performansı gibi kullanmayın; kendi ölçümünüzde bütün geçen süreyi sayın.

Her adım başlarken izin verilen süreyi min(adım üst sınırı, toplam bitiş−şimdi−temizlik payı) ile hesaplayın. Buradaki bütün zamanlar tek bir başlangıçtan ölçülen aynı saat alanındadır. Kalan süre sıfır veya negatifse yeni iş başlatılmaz. Pozitif kalması da görevin kesin tamamlanacağını göstermez; yalnızca kullanılabilecek üst sınırı verir.

Üçüncü adıma dört saniye kalmıyor

C’nin dört saniyeye ihtiyacı var, fakat kendisine yalnız bir saniye veriliyor. Bu örnek, iptal edilebilen salt okunur bir denemenin kalan süre içinde başlatılmasına izin verir. Bir saniye sonunda başarı üretmiş gibi davranılmaz. Sonuç, deadline_exceeded durumuyla kapatılmış eksik iştir. Zaman sınırına uymakla bütün adımları tamamlamak farklı kabul ölçütleridir.

Bazı işler için en az dört saniye kalmadan başlamama kuralı seçilebilir. O politikada C hiç başlatılmaz; kalan zaman sonuç hazırlamaya ayrılır. Bu da geçerli bir tasarım olabilir, fakat başlatıp iptal etme politikasıyla aynı yürütme izi değildir. İşin iptal maliyeti, en az çalışma süresi ve yan etkisi bu seçimi etkiler.

Başarılı adımlar: A, B.
C: 1 saniyelik denemeden sonra süre doldu; tamamlanmış sayılmadı.
Toplam geçen süre: varsayımlar altında 10 saniye.
İş durumu: eksik, deadline_exceeded.
Bağımsız dört saniye sınırlarıyla tam yürütme: 12+1=13 saniye; toplam sözleşmeyi aşar.

Bu kayıt, eksik çıktının başarı yanıtına karışmasını önler. Örneğin A veri topladı, B taslak hazırladı, C doğrulama yapacaksa C tamamlanmadığında taslak doğrulanmış sayılamaz. Önceki adımların bitmiş olması son kalite kapısını otomatik olarak geçirmez. Kullanıcıya sunulacak sonuç durumu bu bağımlılığı korumalıdır.

Kalan süreyi aktarın; yeni tam bütçe açmayın

Ajan başka bir servise çağrı yaparken başlangıçtaki on saniyeyi yeniden verirse alt servis toplam işin gerçekte ne kadar zamanı kaldığını bilmez. Kalan bütçe aktarılmalı ve alt iş de kendi alt çağrılarına geçen süreyi düşerek devam etmelidir. gRPC belgeleri bu aktarımın saat farkı sorunlarını azaltacak biçimde kalan süre üzerinden ele alınmasını açıklar.Kaynak: gRPC — Deadlines

Farklı süreçlerin monoton saat okumalarını doğrudan birbirinden çıkarmayın; aynı sıfır noktasını paylaşmaları gerekmez. Yerel geçen süre için monoton saat kullanmak, süreçler arası bütçe sözleşmesini kendiliğinden kurmaz. Protokolün sağladığı deadline aktarımını veya açık kalan süre alanını kullanırken ağda ve kuyrukta geçen süreyi de hesaba katın.

Sentetik sıralı iş: toplam bütçe 10 saniye, temizlik rezervi 1 saniye, adım üst sınırı 4 saniye. A/B/C süre ihtiyaçları 4/4/4. Aynı başlangıca göre her adımda kalan çalışma süresini yeniden hesapla. Bu denemede iptal edilebilir salt okunur adım, pozitif süre varsa başlatılabilir. C’nin sonucunu başarı sayma. Tam bütçeyi her çağrıda yeniden açan yöntemle toplam süreyi karşılaştır. Başka sürecin monoton saat değerini yerel saatten doğrudan çıkarma.

Ajanın yanıtında C için dört saniye görünüyorsa ortak bütçe uygulanmamıştır. C için bir saniye yazıp yine tamamlandı deniyorsa görev ihtiyacı göz ardı edilmiştir. Temizlik satırı yoksa toplam süre eksik hesaplanmıştır. Üç kontrolü birlikte yapmak, yalnız min formülünün metinde bulunmasından daha güçlü bir doğrulamadır.

Süre dolması yan etkinin olmadığını kanıtlamaz

İstemci beklemeyi bıraktığında uzak servis çalışmayı sürdürebilir. gRPC rehberi de iptal sonrasında uygulamanın kendi işlerini durdurma sorumluluğunu belirtir. İptal işaretinin görülmesi, yapılan bütün işlemlerin kendiliğinden geri alındığını göstermez. Bu nedenle salt okunur deneme ile yazma işlemini aynı yeniden deneme kuralına bağlamayın.Kaynak: gRPC — Deadlines

Bir kayıt oluşturma çağrısı zaman aşımına uğradıysa sonuç belirsiz olabilir: kayıt oluşmuş, fakat yanıt yetişmemiş olabilir. Yeniden göndermeden önce mevcut işlem kimliğiyle durumu sorgulamak veya sistemin tekrar güvenliği sözleşmesini kullanmak gerekir. Bu yazının süre tablosu, böyle bir yan etkinin güvenli tekrarını tek başına çözmez.

İlk iki adım hızlanırsa

A’nın iki, B’nin üç, C’nin dört saniye sürdüğü yeni bir deneme kurun. Aynı toplam bütçe ve temizlik rezervini koruyun. C başladığında kaç saniye kalır? B’den sonra ayrıca yarım saniye aktarım gecikmesi eklenirse sonuç nasıl değişir? Başarı ve zamanında kapatma kararlarını ayrı yazın.

Ek yük yokken A t=2, B t=5 biter; C için 4 saniye kalır ve t=9 tamamlanır. Temizlik t=10 biter; iş başarılıdır. Araya 0,5 saniye eklenirse C t=5,5 başlar, yalnız 3,5 saniye alır; dört saniyelik ihtiyacını tamamlayamaz. t=10 kapatma yine mümkündür, fakat başarı değildir.

Kendi pilotunuzda süre sınırını yalnız araç çağrıları için değil, uçtan uca iş için tanımlayın. Adım sonuçlarını, geçen süreyi ve belirsiz yan etkileri aynı deneme kaydında tuttuğunuzda, gecikmenin hangi bütçe kararından doğduğunu ve hangi işlerin gerçekten tamamlandığını görebilirsiniz.