LLM Sağlayıcı Değiştirmeden Önce Neden Smoke Test Şart
Tek bir prompt göndermek LLM sağlayıcısını değiştirmek için yeterli değil. Timeout, streaming, rate limit ve tool-call davranışlarını test eden 10 dakikalık smoke test rehberi.
Yazar, LLM sağlayıcı geçişlerinde uzun süre yalnızca base URL'yi değiştirip tek bir sıradan prompt gönderme şeklinde basit bir test kullandığını, ancak bunun üretim ortamındaki gerçek sorunları göstermediğini fark ediyor. Normal bir istek; timeout davranışı, retry güvenliği, streaming'in düzgün bitip bitmediği, rate limit yanıtının şekli, usage metadata'sı ve tool-call işleme gibi kritik noktaları test etmiyor.
Bunun yerine, üretime almadan önce beş küçük ama hedefli kontrolden oluşan 10 dakikalık bir smoke test uyguluyor: normal bir isteğin response ID, finish reason ve usage bilgisini loglamak; agresif bir timeout tetikleyip hatanın sınıflandırılabilir olup olmadığını görmek; streaming yanıtın net bir finish reason ile bitip bitmediğini kontrol etmek; rate limit ve token limit hatalarını ayrı ayrı sınıflandırmak; ve son olarak side-effect riski taşıyan (e-posta gönderme, ödeme tetikleme gibi) tool-call senaryolarında retry politikasının güvenli davranıp davranmadığını test etmek.
Buradaki amaç bir sağlayıcının diğerinden "daha iyi" olduğunu kanıtlamak değil, uygulamanın olan biteni doğru anlayıp anlamadığını doğrulamak. Özellikle agent ve workflow tabanlı sistemlerde, tamamlanmamış bir stream'i tamamlanmış sanmak veya token limiti aşımında context'i sessizce kırpmak, gizli ama ciddi hatalara yol açabiliyor. Mühendisler için çıkarım net: sağlayıcı değiştirmeden önce mutlu yol testinin ötesine geçip hata sınıflandırma ve retry mantığını doğrulamak gerekiyor.