Bir AI API relay’ini canary ile test etmek: kendiniz çalıştırabileceğiniz bir yöntem

Bir canary testi tek bir soruyu cevaplar: bir relay’den bir model istediğinizde, cevabı o model mi veriyor? Relay’in yönlendirme tablosunu okuyamazsınız ve pazarlama sayfası kanıt değildir; öğrenmenin tek yolu, cevabı isteği kimin karşıladığına göre değişen bir istek göndermektir. Yöntem burada, beş dakikada çalıştırabileceğiniz bir betikle.

Önemlidir çünkü tespit ettiği başarısızlık yaygındır. 28 relay üzerinde yapılan bir çalışmada uçların %45,83’ü istenenden farklı bir model döndürdü. İkame normal kullanımda görünmez — cevap akıcıdır, biçim doğrudur, fatura daha düşüktür — ve yalnızca aramaya gittiğinizde ortaya çıkar.

Neden modele doğrudan soramazsınız

Akla gelen test “hangi modelsin?” diye sormaktır ve neredeyse değersizdir. Üç sebep:

• Modeller kendi kimlikleri konusunda güvenilmez anlatıcılardır. Kendileri var olmadan önce yazılmış eğitim verisinden cevap verirler ve çoğu zaman kendinden emin biçimde yanılırlar.
• Relay bir sistem istemi enjekte edebilir. O sorunun cevabı para ediyorsa, işletmecinin istediği şeyi söyletmek mümkündür.
• İkame edilmiş bir model genelde pahalı olan gibi davranmak üzere ayarlanmış veya yönlendirilmiştir; ikamenin bütün amacı zaten budur.

Kullanışlı bir canary, modelden kendini tarif etmesini istemez. Doğru davranışın, hakkında bir iddia değil, modelin bir özelliği olduğu bir şey sorar.

İyi bir canary istemini ne yapar

Dört özellik; biri eksik olan istem, üzerine karar veremeyeceğiniz sonuçlar üretir.

1. 01Belirlenimci. Aynı istem, sıcaklık 0’da, aynı modelden aynı cevabı verir. Cevap gezliyorsa kimlik değil örnekleme gürültüsü ölçüyorsunuzdur.
2. 02Ayırt edici. Farklı modeller ölçülebilir biçimde farklı cevap verir. Her modelin aynı cevapladığı bir soru hiçbir şey söylemez.
3. 03Ucuz. Birkaç token girer, birkaç token çıkar. Bunu çok kez çalıştıracaksınız.
4. 04Önemsediğiniz sürüm boyunca kararlı. Cevap modele bağlı olmalı; tarihe, havaya veya modelin yapabileceği bir web aramasına değil.

İşe yarayan istem aileleri

Yöntem

Beş adım. Her şey ikinci adıma bağlı ve insanların atladığı kısım da o.

1. 01Üç ila beş canary istemi seçin ve sabitleyin. Yazın; her çalıştırmada doğaçlama yapmayın.
2. 02Cevap anahtarını istemleri doğrudan sağlayıcıya göndererek oluşturun — sıcaklık 0, sistem istemi yok. Referansınız budur. Bu olmadan relay’i gerçekle değil beklentinizle karşılaştırırsınız.
3. 03Aynı istemleri relay’e gönderin: aynı model adı, aynı sıcaklık, yine sistem istemi yok.
4. 04Karşılaştırın. Kısa belirlenimci cevaplarda tam eşleşme; uzun olanlarda tüm dizeyi değil yapıyı ve ayırt edici ayrıntıyı karşılaştırın.
5. 05Birkaç istek boyunca ve mümkünse gün içine yayarak tekrarlayın. Yönlendirme istek başınadır, yani tek çalıştırma yalnızca tek bir rota hakkında bilgi verir.

Bir betik

Bu betik aynı istemi iki temel URL’e gönderip iki cevabı yan yana yazdırır. Kabuk ve curl dışında bağımlılığı yoktur.

#!/usr/bin/env bash
# Kullanim: MODEL=gpt-5.6-sol ./canary.sh
# Iki anahtari da once ortam degiskenine koyun. Anahtari asla dosyaya yazmayin.
set -euo pipefail

MODEL="${MODEL:?MODEL degiskenini ayarlayin}"
PROMPT='Sadece "strawberry-jam-2026" dizesindeki karakter sayisini yaz. Kelime yok.'

ask() {  # ask <base-url> <api-key>
  curl -sS "$1/chat/completions" \
    -H "Authorization: Bearer $2" \
    -H "Content-Type: application/json" \
    -d "{\"model\":\"$MODEL\",\"temperature\":0,
         \"messages\":[{\"role\":\"user\",\"content\":\"$PROMPT\"}]}" \
  | python3 -c 'import sys,json; d=json.load(sys.stdin); \
      print(d["choices"][0]["message"]["content"].strip(), "|", \
            d.get("usage",{}).get("completion_tokens"), "token")'
}

echo "saglayici: $(ask "$PROVIDER_BASE" "$PROVIDER_KEY")"
for i in 1 2 3 4 5; do
  echo "relay $i  : $(ask "$RELAY_BASE" "$RELAY_KEY")"
done

Relay’e karşı beş kez, sağlayıcıya karşı bir kez çalıştırın. Altısında da aynı cevap, o model, o istem ve o an için geçer nottur. Ayrışma tek başına ikame kanıtı değildir — token sayılarını da kontrol edin, çünkü farklı bir tokenizer genelde metinden önce orada görünür.

Sonucu dürüstçe okumak

Canary testi kanıt değil delildir ve ne gösterdiğini abartmak yanlış sonuca varmanın en hızlı yoludur.

En yaygın yanlış pozitif, göndermediğiniz bir sistem istemidir. Bazı relay’ler güvenlik veya marka için bir tane enjekte eder; bu, modeli değiştirmeden biçimi ve reddetme davranışını değiştirir. Her şey üslupça farklı ama ayırt edici olgular eşleşiyorsa, ikameden önce istem enjeksiyonundan şüphelenin.

Bize karşı çalıştırın

Kendi canary sonuçlarımızı yayınlamadık ve bunları bağımsız kanıt diye sunmayacağız — kendi ödevini kendi notlandıran bir relay’in değeri tahmin ettiğiniz kadardır. Yapabileceğimiz şey testi kolaylaştırmak ve ne beklemeniz gerektiğini söylemek.

Temel URL https://proxystation.co/v1, OpenAI uyumlu ve GET /v1/models anahtarınızın erişebildiklerini listeler. Model adları, token başına fiyatlar ve rota sayıları hesap açmadan genel katalogda duruyor. Bize karşı yapılan bir canary çalıştırması sağlayıcıdan ayrışıyorsa bunu bilmek isteriz — bu bir yönlendirme hatasıdır ve bir okuyucudan duymayı hiç duymamaya tercih ederiz.

Bu şekilde değerlendirdiğiniz her relay, bizimki dahil, pazarlama sayfasının izin verdiğinden daha iyi anladığınız bir relay olur. Bunu yapmanın bütün gerekçesi budur.

Bir canary başarısız olduğunda ne yapmalı

Ayrışma bir başlangıçtır, hüküm değil. Şu sırayla ilerleyin, çünkü ucuz açıklamalar aynı zamanda yaygın olanlardır.

1. 01Sıcaklık 0’da tekrar çalıştırın. Cevap sağlayıcıya karşı da çalıştırmalar arasında geziyorsa istem belirlenimci değildir ve sonuç gürültüdür. İstemi değiştirin.
2. 02Enjekte edilmiş sistem istemi arayın. Kasten tuhaf bir biçim isteyin — hep küçük harf, noktalama yok. Sağlayıcı uyarken relay eziyorsa, bağlamınıza bir şey ekleniyordur.
3. 03Token sayılarını karşılaştırın. Metin aynı, completion_tokens farklıysa bu farklı bir sunum yığınına işaret eder; metin farklı sayı aynıysa örneklemeye.
4. 04Modeli değiştirin. Relay’deki her model aynı biçimde ayrışıyorsa relay’in ara katmanından şüphelenin. Tek model ayrışıyorsa o modelin yönlendirmesinden.
5. 05İşletmeciye sorun. Üst akış kanalını adlandırıp farkı açıklayabilen bir relay iyi davranıyordur. Açıklayamayan da size bir şey söylemiştir.

İkame ancak bu dörtten sonra en iyi açıklama hâline gelir — ve o zaman bile birkaç saat sonra tekrarlamaya değer, çünkü yanlış davranan rota genelde birkaç rotadan biridir, modelin tamamı değil.

Sürekli bir kontrole dönüştürmek

Canary çalıştırması en çok sıkıcı olduğunda işe yarar: aynı istemler, bir takvimle, cevaplar kaydedilerek. Tek seferlik test size bir an hakkında bilgi verir; bir seri, bir şeyin değişip değişmediğini söyler.

Faydalı olan en küçük sürüm, betiği günlük çalıştıran, cevabı ve token sayısını bir dosyaya ekleyen ve bir satır bir öncekinden farklı olduğunda uyaran bir cron işidir. Üç şey bunu emeğe değer kılar:

• Yönlendirme değişiklikleri başka türlü görünmez. İşletmeciler üst akış kanallarını rutin olarak ekler ve çıkarır, ve bunu hiçbir şey duyurmaz.
• Kanıtınızı tarihlendirir. “2026-08-30’da eşleşti” bir olgudur; “iyi görünüyordu” değildir.
• Neredeyse hiçbir maliyeti yoktur — asıl satın aldığınız şeyi kontrol etmek için günde birkaç token.

Bu yöntem, relay’lerin nasıl çalıştığı ve nasıl denetleneceği rehberindeki dört kontrolden biridir. Tamamlayıcı yazı, tek geçen çalıştırmanın neden yetmediğini anlatıyor: bir model adının birden çok rotası olabilir. Ve bir çalıştırma olguda değil üslupta ayrışıyorsa muhtemel sebep enjekte edilmiş bir sistem istemidir — OpenAI uyumluluğunun ne demek zorunda olduğu bunu ele alıyor.