Başarılı Bir İstek Yine de Başarısız Olduğunda
Haftalardır aynı karakterle konuştuğunuzu düşünün. Sesi tanıdık, dili tutarlı, yanıtları keskin ve canlıdır.
Sonra karakteri ya da modeli değiştirmediğiniz hâlde bir şeyler aniden yanlış gelmeye başlar.
Bir sonraki yanıtın başlaması on saniye sürer. Structured output kullanan bir özellik birden çalışmaz. Karakter saçmalamaya, başka dillerden parçalar eklemeye veya çok daha zayıf bir modelden geliyormuş gibi yanıt vermeye başlar.
Sunucu açısından hiçbir şey başarısız olmamıştır. API 200 OK döndürmüş, tokenlar gelmiş ve istek ücretlendirilmiştir.
Kullanıcı açısından ise model az önce kötüleşmiştir.
Reverie için sağlayıcı canary probe ve routing karantina sistemi geliştirmemizin nedeni bu farktır.
Tek Model Adı, Birçok Inference Ortamı
OpenRouter bizim ana model gateway’imizdir. Güçlü yanlarından biri, tek bir modelin birden fazla bağımsız inference sağlayıcısı tarafından sunulabilmesidir. Bir sağlayıcı kullanılamıyorsa başka biri isteği alabilir. Böylece tek bir endpoint’e bağımlı kalmaya kıyasla daha fazla kapasite, rekabetçi fiyat ve daha yüksek dayanıklılık elde ederiz.
Ancak bu durum görünmeyen bir değişken de yaratır.
Model adı aynı kalırken modeli çalıştıran altyapı istekten isteğe değişebilir. Her sağlayıcı farklı bir inference engine, donanım yapılandırması, quantization düzeyi, parser, chat template, kuyruk veya ek policy katmanı kullanabilir.
OpenRouter’ın sağlayıcı routing dokümantasyonu, varsayılan routing’in yakın zamandaki kullanılabilirliği ve fiyatı dikkate aldığını, diğer sağlayıcıları fallback olarak tuttuğunu açıklar. Bunlar önemli sinyallerdir; ancak bir endpoint çevrimiçi ve ucuz olup belirli bir ürün için kabul edilemez sonuçlar üretebilir.
OpenRouter ayrıca aynı modeli sunan sağlayıcılar arasındaki ölçülebilir farklılıklar hakkında kamuya açık biçimde yazmıştır. Teoride aynı hassasiyetteki aynı weights benzer davranmalıdır. Üretimde büyük bir modeli çalıştırmak karmaşıktır ve farklılıklar ortaya çıkar.
“Model Bozulması” ile Ne Kastediyoruz?
“Model bozulması” tek ve standart bir tanı değildir. Bir sağlayıcının modeli kasıtlı olarak daha küçüğüyle değiştirdiği anlamına da otomatik olarak gelmez.
Terimi operasyonel olarak kullanıyoruz: Bir inference endpoint’i, temsili promptlarda istenen modelden beklediğimiz davranışı, yetenekleri veya etkileşim performansını artık koruyamıyorsa, istek teknik olarak başarılı olsa bile bozulmuştur.
Reverie için en belirgin biçimler şunlardır:
- Gecikme bozulması: Bağlantı kurulur ancak ilk token süresi canlı konuşma hissini bozacak kadar uzundur.
- Yetenek bozulması: Structured output desteklemesi beklenen endpoint bozuk metin döndürür veya schema’yı karşılamayı bırakır.
- Davranış bozulması: Yanıtlar bozulur, tutarsızlaşır, beklenmedik biçimde tekrarlanır ya da belirgin olarak başka bir dile kayar.
- Policy uyumsuzluğu: Upstream host kendi filtre katmanını ekler ve Reverie’nin desteklediği bir sahneyi ret, boş yanıt veya kesilmiş metne dönüştürür.
Birçok olası neden vardır. Daha düşük hassasiyetli quantization zor promptları etkileyebilir; hem OpenRouter dokümantasyonu hem de yayımlanmış quantization araştırmaları bunu belirtir. Fakat quantization evrensel açıklama değildir: inference engine veya tool parser hataları, tokenizer ya da chat-template sorunları, aşırı yüklü kuyruklar ve sağlayıcı middleware’i de aynı ölçüde önemli olabilir. OpenRouter, tool çağrılarında parser uygulamalarının çoğu zaman hassasiyetten daha fazla sağlayıcı farkı yarattığını gözlemlemiştir.
Önemli soru “Hangi neden daha şüpheli geliyor?” değil, “Endpoint’i izole edip hatayı yeniden üretebiliyor muyuz?” sorusudur.
Sorunu Somutlaştıran İki Vaka
Bu bizim için teorik bir endişe değildi.
Sağlayıcılara sabitlenmiş bir karşılaştırmada bir sağlayıcı, 20 yanıtın 19’unun başına noktalama işareti veya ilgisiz bir token parçası ekleyerek metni bozdu. Aynı modeli sunan diğer on dört hostta sorun 49 yanıtın 0’ında görüldü. Roleplay yanıtlarında ilk karakter çoğu zaman Markdown vurgu işareti olduğu için tek bir yabancı byte bile tüm yanıtın biçimini bozabiliyordu.
Başka bir testte tek bir endpoint, 3 üretimin 3’ünde yoğun Portekizce-İspanyolca karışımı oluşturdu. Aynı prompt modelin resmî hostunda ve aynı hassasiyet sınıfındaki diğer test hostlarında Portekizce kaldı. “Model zaten tutarsız” açıklaması artık yeterli değildi; kusur endpoint’i takip ediyordu.
Bu hatalar her zaman exception üretmediği için görünmezdir. Geleneksel uptime izleme sağlıklı bir API görür. Kullanıcı ise aniden düzgün konuşamayan bir karakter görür.
Yanıtımız: Yalnızca Modeli Değil, Her Rotayı Test Etmek
Canary sistemimiz her otuz dakikada bir Reverie’nin varsayılan sohbet modelini sunan aktif sağlayıcıları bulur. Ardından her birine, yalnızca o sağlayıcıya sabitlenmiş ve fallback’leri kapatılmış küçük bir sentetik istek grubu gönderir.
Sabitleme çok önemlidir. Probe’un fallback kullanmasına izin verilirse ikinci bir sağlıklı sağlayıcı birincinin hatasını gizleyebilir. Sonucu tam olarak hangi inference ortamının ürettiğini bilmeliyiz.
Sistem, kodla değerlendirilebilen dört dar kapsamlı sözleşmeyi test eder.
1. İlk Token’a Kadar Geçen Süre
Streaming bir konuşmada throughput deneyimin yalnızca yarısıdır. İlk token, kullanıcının yükleme göstergesine ne kadar bakacağını belirler.
Bunu doğrudan stream üzerinden ölçeriz. On saniye içinde metin üretmeyen sağlayıcı gecikme probe’unda başarısız olur. Eşik kasıtlı olarak geniştir ve tek bir yavaş tur hostu çıkarmaya yetmez; geçici kuyruk baskısı yaşanabilir.
2. Filtreleme ve Sessiz Retler
Reverie’nin desteklediği trafiği temsil eden sabit bir roleplay devam isteği göndeririz. Probe bitiş nedenini, yüksek güvenli ret kalıplarını ve boş output’u denetler.
Ayrıca filtre uyguladığı bilinen hostları pozitif kontrol olarak test ederiz. Bir kontrol beklenmedik biçimde geçerse diğer sağlayıcıları sağlıklı ilan etmeyiz; probe’un kendisini zayıf olarak işaretleriz. Bilinen hatasını artık tespit edemeyen bir test sağlık kanıtı değildir.
3. Structured Output
Sabit schema’ya sahip küçük bir object ister ve sonucu doğrularız. Transport error ile bozuk output farklı değerlendirilir: Kopuk bağlantı sağlayıcıya ulaşılamadığını gösterirken tamamlanmış üretimin schema’yı karşılayamaması yetenek gerilemesine işarettir.
“Endpoint parametreyi desteklediğini söylüyor” ve “endpoint parametreyi güvenilir biçimde yerine getiriyor” aynı söz değildir.
4. Dil Bütünlüğü
Reverie 17 arayüz dilini destekler. Bu nedenle yalnızca İngilizce bir smoke test, kullanıcılarımızın gerçekten yaşadığı bazı hataları kaçırır.
Canary, sentetik roleplay promptlarıyla desteklenen diller arasında dönüşümlü test yapar. Yerel ve deterministic bir dil algılayıcı, tüm yanıtın güvenli biçimde başka dile geçmesini, sürekli dil karışımını ve belirgin encoding bozulmasını arar. Gerçek konuşmalar kullanılmaz ve başka bir modelden öznel değerlendirme istenmez.
Belirsiz veya çok kısa output başarısız değil, sonuçsuz sayılır. Dil anomalisi bulunursa canary hemen iki doğrulama denemesi daha çalıştırır ve çoğunluk ister. Aynı dil sonraki turda yeniden sınanır; böylece sağlayıcı sırf rotasyon ilerledi diye ardışık tur kuralından kaçamaz.
Sistemi Kendi Sonuçlarından Şüphe Edecek Şekilde Tasarladık
Inference kapasitesini otomatik kaldırmak yararlıdır, fakat false positive asıl kusurdan daha büyük bir kesinti yaratabilir. Bu nedenle canary’nin çeşitli frenleri vardır:
- Transport hataları kalite hatası sayılmaz. Timeout, rate limit ve 5xx yanıtları suspension serisini ilerletmek yerine skoru dondurur.
- Tek bir kötü tur yeterli değildir. Sağlayıcı, yarım saatte bir yapılan iki ardışık turda başarısız olmalıdır.
- Gözlem ve uygulama ayrıdır. Sistemi observe mode’da çalıştırabilir, hangi hostların askıya alınacağını kaydedebilir, yöneticileri bilgilendirebilir ve otomatik eylemi açmadan false positive oranını ölçebiliriz.
- Kapasitenin alt sınırı vardır. Bir sağlayıcıyı askıya almak üretimde ikiden az host bırakacaksa canary bunu yapmaz, bunun yerine yöneticiyi uyarır.
- İyileşme de test edilir. Askıya alınan sağlayıcılara probe gönderilmeye devam edilir. Art arda iki temiz tur hostu erken geri getirir.
- Tekrarlanan hatalar kademeli artar. İlk suspension bir gün, sonraki üç gün ve daha sonrakiler yedi gün sürer. Yeni suspension olmadan on dört gün geçince geçmişin etkisi silinir ve basamak baştan başlar.
Amaç sağlayıcıları cezalandırmak değildir. Amaç, kullanıcı trafiğini tekrarlanabilir biçimde sağlıksız bir rotadan uzaklaştırmak ve sorun giderildiğinde açık bir geri dönüş yolu bırakmaktır.
Üç Koruma Katmanı
Nihai routing kararı üç tür dışlamayı bir araya getirir:
- İncelenmiş yerleşik dışlamalar: Ölçtüğümüz ve yanlışlıkla geri getirmek istemediğimiz kusur ya da policy uyumsuzlukları için.
- Runtime olay dışlamaları: Bir yöneticinin deployment beklemeden hemen ekleyebileceği girdiler.
- Süreli canary suspension’ları: Otomatik hata eşiğini aşan sağlayıcılar için.
Reverie bir istek oluştururken bu listeler OpenRouter’ın provider.ignore tercihinde birleştirilir. Kullanıcının şans eseri daha iyi bir sağlayıcı seçilene kadar yeniden denemesi gerekmez; sağlıksız rota adaylar arasından çıkarılır.
Her otomatik karar kaydedilir, önemli durum değişikliklerinde yöneticilere bildirim gider ve gerektiğinde suspension elle kaldırılabilir.
Bu Sistem Neyi Garanti Eder, Neyi Etmez?
Canary kasıtlı olarak dar kapsamlıdır. Kod gecikmeyi, schema geçerliliğini, yüksek güvenli filtrelemeyi, dil ve encoding bütünlüğünü değerlendirebilir. Bir karakterin yeterince komik, duygusal olarak yeterince duyarlı veya karmaşık kişiliğine tamamen sadık olup olmadığını puanlıyor gibi davranmaz.
Bu daha geniş sorular temsili promptlarla değerlendirme, insan incelemesi, production telemetry ve en önemlisi kullanıcı raporları gerektirir.
Sistem ayrıca her garip yanıtın bozulmayı kanıtladığı anlamına gelmez. Generative modeller olasılıksaldır. Uzun bir konuşmada çelişkili bağlam birikebilir ve karakter tanımı birbiriyle yarışan talimatlar içerebilir. Bazen garip bir yanıt yalnızca garip bir yanıttır.
Değişen şey, “aynı model” ifadesinin artık incelememizi bitirmemesidir. Servis rotasını izole edebilir, nesnel hataları yeniden üretebilir ve sonraki trafiği ondan uzak tutabiliriz.
Güvenilirlik, Deneyimi Korumaktır
Çok sağlayıcılı routing değerini koruyor. Tekil endpointler devre dışı kaldığında bile Reverie’ye konuşmaları erişilebilir tutacak kapasite ve dayanıklılık sağlıyor.
Ancak dayanıklılık yalnızca HTTP yanıtı almak değildir. Çok geç başlayan, gerekli yapısını kaybeden, desteklenen içeriği reddeden veya aniden dil değiştiren bir yanıt, faturada başarılı yazdığı için sağlıklı olmaz.
Bir AI karakter ürünü için güvenilirlik daha insani bir anlama gelir: Hangi makine onun adına konuşursa konuşsun, karakter yine aynı karakter gibi hissettirmelidir.
Yeni routing korumalarımızın savunmak için tasarlandığı standart budur.
Yanıt kalitesinde veya dilinde ani bir değişiklik fark ederseniz model adını ve yaklaşık zamanı içeren bir rapor gönderin. Bu bilgiler, gördüğünüz deneyimi onu sunan kesin rotayla eşleştirmemize yardımcı olur.