LLM·3 dk okuma·

4.768 LLM Çalıştırması, Sıfır Kayıp Deneme: Zaman Aşımı, Kilitlenme ve Maliyete Karşı Test Koşucusunu Güçlendirmek

Paylaş
4.768 LLM Çalıştırması, Sıfır Kayıp Deneme: Zaman Aşımı, Kilitlenme ve Maliyete Karşı Test Koşucusunu Güçlendirmek

Büyük Ölçekli LLM Testlerinde Görünmeyen Hata

Açık kaynaklı bir sidecar aracı olan CauterRule (v0.3.0), tekrarlanan yapay zeka ajan hatalarından kalıcı kurallar çıkarmayı amaçlar. 40 veri kümesi ve 2 bulut modeli üzerinde koşturulan 4.768 yörüngelik (trajectory) saha testinde karşılaşılan asıl zorluk modeller değil, test altyapısının (test harness) kendisi oldu. Bir saat süren testin ardından model sağlayıcısından dönmeyen tek bir istek, iş parçacığını sonsuz kilitlenmeye sokarak tüm çalıştırma kümesini (sweep) ve harcanan API bütçesini çöpe atabilir.

Ölçek Büyüdüğünde Çöken 3 Hatalı Varsayım

Orijinal test koşucusunun dayandığı ve küçük ölçekte sorunsuz çalışan ancak 4.768 çalıştırmada çöken 3 temel varsayım şunlardır:

  • Varsayım 1 (Sağlayıcı her zaman yanıt verir): Gerçek dünyada sağlayıcılar bazen hiçbir hata veya zaman aşımı üretmeden sessizce kilitlenir ve çalışanı sonsuza dek bloke eder.
  • Varsayım 2 (Zaman aşımı geçici bir hatadır, tekrar denenmelidir): Zaten yanıt vermeyen ölü bir isteği yeniden denemek yalnızca boşa harcanan API maliyetini iki katına çıkarır.
  • Varsayım 3 (Başarısız yörünge başarıya ulaşana kadar tekrarlanmalıdır): Kötü yapılandırılmış bir girdi, test koşucusunu sınırsız bir yeniden deneme döngüsüne hapseder.

Çözüm: Test Koşucusunu Koruyan 5 Güvenlik Kalkanı (Guard)

Sistemi güvenilir kılmak adına test koşucusuna eklenen 5 koruma mekanizması:

  • 1. Yörünge Başına Zaman Aşımı (Per-trajectory timeout): future.result(timeout=120) ve istemci tarafında timeout=30 kullanılarak kilitlenen çağrıların çalışanları bloke etmesi önlenir.
  • 2. Yeniden Denenemez Zaman Aşımları (Non-retryable timeouts): Zaman aşımı kalıcı (terminal) hata olarak sınıflandırılarak ölü isteklerin tekrarlanması ve maliyet çarpanı engellenir.
  • 3. Belirteç Sınırı (Token cap): max_tokens=4096 limitiyle kontrolden çıkan üretimlerin aşırı gecikme ve maliyet patlaması yaratmasının önüne geçilir.
  • 4. Karantina Mekanizması (Quarantine): CAUTERULE_QUARANTINE_IDS ile bilinen hatalı kimlikler yeniden denenmek yerine doğrudan atlanır.
  • 5. Kapatmada İptal Etme (Cancel on shutdown): executor.shutdown(wait=False, cancel_futures=True) ile takılı kalan iş parçacıklarının tüm test sürecini durdurması engellenir.

Eşzamanlılık (Concurrency) Mimarisi ve Temel İlke

Standart with ThreadPoolExecutor bloğunun __exit__ metodu shutdown(wait=True) çalıştırdığı için tek bir kilitli thread tüm test kümesini askıda bırakır. Bunun yerine as_completed ve nesneye özel result(timeout=120) bekçisi uygulanmalıdır. Temel prensip nettir: "Hatalı tek bir istek tüm test kümesine değil, yalnızca ait olduğu tek yörüngeye mâl olmalıdır."

Yazılım Geliştirme ve Öğrenme Çıkarımları

  • Hata Sınıflandırması: Her API hatası geçici değildir; ağ zaman aşımlarını kalıcı kabul etmek maliyet tasarrufu sağlar.
  • Eşzamanlılık Güvenliği: Thread havuzlarında with bloklarına körü körüne güvenmek yerine katı iptal (cancel_futures) ve gözetim mekanizmaları kurulmalıdır.
  • İzolasyon ve Karantina: Hatalı veri noktalarını izole ederek test süitinin kesintisiz çalışması sağlanmalıdır.

Orijinal kaynağa buradan ulaşabilirsiniz.


Bu konuyu derinlemesine öğrenmek isterseniz: Production'da Agent Güvenilirliği modülüne göz atın.

Paylaş

Bu konuyu daha derinlemesine öğrenmek ister misin?

Edumints'teki ücretsiz kursları incele ve bugün başla.

Kurslara Göz At →