Önemli noktalar
- Context windows combine prompt and completion, so long histories drain limits faster than expected.
- Streaming, bozuk JSON veya kayıp tokenlar oluşmasını önlemek için SSE olaylarının dikkatli bir şekilde yönetilmesini gerektirir.
- JSON mode demands strict schema adherence; malformed responses cause silent parsing failures.
- Ön ödemeli kripto faturalandırma, hataların ücretsiz olduğu anlamına gelir; ancak sürprizlerin önüne geçmek için token sayımının doğru yapılması gerekir.
API anahtarınızın neden reddedilebileceği
İstemci hatalı başlıklar gönderdiğinde veya istek gövdesi sınırlarını aştığında API anahtarları reddedilir. Sunucu, herhangi bir mantığı işlemeye başlamadan önce kimlik doğrulama başlığını doğrular. Başlık eksikse veya ekstra boşluk içeriyorsa, istek hemen başarısız olur.
Başka bir yaygın neden, 8 MB gövde boyutu sınırını aşan bir payload göndermektir. Birçok mesaj içeren büyük bağlam pencereleri bu eşiği kolayca aşabilir. Göndermeden önce mesaj dizisi uzunluğunu ve token sayısını kontrol edin.
- Authorization başlığının 'Bearer' önekini doğru şekilde kullandığından emin olun.
- Verify the request body size stays under 8 MB.
- API anahtarının aktif ve süresi dolmamış olduğunu kontrol edin.
Bağlam penceresi sınırlarını anlama
Bağlam penceresi hem girdi istemini hem de oluşturulan tamamlamayı içerir. API'miz 100,000 tokenlik bir pencere destekler, ancak her iki tarafı da hesaba katmanız gerekir. 80,000 bağlam tokeni gönderirseniz, yanıt için yalnızca 20,000 tokeniniz kalır.
Çoğu model, max_tokens belirtmezseniz küçük bir çıktı sınırı varsayılan olarak ayarlanır. Bu, uzun yanılgıların beklenmedik şekilde kesilmesine neden olabilir. Sadece bir sınır koymak istiyorsanız max_tokens'u istediğiniz uzunlukta ayarlayın. Sınırın sadece prompt'a değil, toplam isteğe uygulandığını unutmayın.
Akış kesintilerini doğru şekilde yönetme
Sunucu Tarafından Gönderilen Etkinlikler (SSE) üzerinden akış, sağlam hata yönetimi gerektirir. Bağlantı koparsa, son token veya kullanım meta verilerini kaybedebilirsiniz. Gelen parçaları her zaman arabelleğe alın ve tam yanıtı istemci tarafında yeniden oluşturun.
Token kullanım verileri genellikle akışın son parçasında gönderilir. Bağlantıyı erken kapatırsanız, kesin token sayısını kaçırabilirsiniz. Bu durum, ön ödemeli sistemlerde faturalandırma doğruluğunu etkiler. Geçici ağ sorunlarını yönetmek için üstel geri çekilme ile bir yeniden deneme mekanizması uygulayın.
SSE ayrışmasını otomatik olarak işleyen özel bir akış istemcisi kullanın. Bu, ayrıştırma hataları riskini azaltır ve tüm verileri yakaladığınızdan emin olmanızı sağlar.
JSON modu ayrıştırma hataları
response_format: {"type": "json_object"} kullanılırken model geçerli bir JSON döndürmelidir. Herhangi bir sapma, uygulamanızda ayrıştırma hatalarına neden olur. Prompt'unuzun modeli yalnızca JSON çıktısı vermeye açıkça yönlendirdiğinden emin olun.
Bazen model, JSON'un etrafına markdown kod blokları ekler; bu da katı ayrıştırıcıları bozar. Ayrıştırma işleminden önce sarmalayıcılarını kaldırın. Ayrıca, veriyi kullanmadan önce JSON yapısını istemci tarafında doğrulayın.
Hataları erken yakalamak için bir şema doğrulama kütüphanesi kullanın. Bu, model beklenmedik anahtarlar veya türler döndürdüğünde çökmeleri önler.
Token sayma ve faturalandırma sürprizleri
Ön ödemeli faturalandırma yalnızca gerçek token kullanımına göre ücretlendirme yapar. Hatalar ve reddetmeler ücretsizdir; bu, abonelik modellerine kıyasla önemli bir avantajdır. Ancak, tüm bağlamı dikkate almazsanız token sayımı karmaşık hale gelebilir.
Sohbet geçmişindeki her mesaj, giriş belirteci sınırına dahil edilir. Uzun sohbetler, bekleyebileceğinizden daha hızlı bir şekilde ön ödemeli bakiyenizi tüketir. Oturum sırasında bakiyenizin bitmemesi için kullanımınızı düzenli olarak izleyin.
Düşük kredi bakiyeleri için uyarı kurulumu yapın. Bu, istekleriniz başarısız olmadan önce kredi yüklemenizi sağlar. Kredilerin süresinin dolmadığını unutmayın, bu nedenle istediğiniz zaman kredi yükleyebilirsiniz.
NSFW istemlerinde yumuşak reddetmelerden kaçınma
Yumuşak reddetmeler, modelin doğrudan bir yanıt vermek yerine tereddüt etmesi veya kısmi bir yanıt vermesi durumunda ortaya çıkar. Bu durum genellikle tartışmalı veya yetişkinlik temalı konularda yaşanır. Sansürsüz bir modelde bile belirli tetikleyiciler tereddüde yol açabilir.
temperature parametresini ayarlayarak rastgeleliği azaltın. Daha düşük bir sıcaklık, modeli daha belirleyici hale getirir ve temkinli olma olasılığını azaltır. Ayrıca, prompt'unuzun net ve doğrudan olduğundan emin olun. Modeli kafa karıştırabilecek belirsiz ifadelerden kaçının.
Sık sık yumuşak reddetme durumlarıyla karşılaşırsanız, promptu biraz yeniden ifade etmeyi deneyin. Kelime seçimlerindeki küçük değişiklikler genellikle tereddüdü aşmaya ve doğrudan bir yanıt almaya yardımcı olabilir.
Hız sınırı artışları ve geri çekilme stratejileri
API, dakikada 300 istek ve anahtar başına 8 eşzamanlı isteklere izin verir. Trafikteki artışlar bu limitlere hızla ulaşabilir. Oran limit hatalarını zarifçe yönetmek için üstel geri çekilme (exponential backoff) uygulayın.
429 durum kodunu aldığınızda, yeniden denemeden önce bekleyin. Kısa bir gecikmeyle başlayın ve her yeniden denemede bu süreyi artırın. Bu, yoğun zamanlarda sunucunun aşırı yüklenmesini önler.
İstek hızınızı izleyin ve buna göre eşzamanlılık düzeylerinizi ayarlayın. Çok sayıda eşzamanlı istek yapıyorsanız, bunları zaman içinde yaymayı düşünün. Bu, limitlere takılmadan istikrarlı bir verimlilik sağlar.
Fonksiyon çağırma payload yapıları
Fonksiyon çağırma, özel bir payload yapısı gerektirir. Fonksiyonlarınızı tools parametresinde tanımlayın ve tool_choice'u belirtin. Model, bunun uygun bir yanıt olduğunu belirlerse bir fonksiyon çağrısı döndürür.
Fonksiyon tanımlamalarınızın doğru ve eksiksiz olduğundan emin olun. Eksik parametreler veya yanlış türler, modelin geçersiz çağrılar oluşturmasına neden olabilir. Her zaman fonksiyon çağrısı argümanlarını yürütmeden önce doğrulayın.
tool_choice parametresini kullanarak modelin işlevleri ne zaman çağıracağını kontrol edin. Bir işlev çağrısını zorlayabilir, modelin karar vermesine izin verebilir veya işlev çağırma özelliğini tamamen devre dışı bırakabilirsiniz. Bu, modelin davranışı üzerinde ince ayarlı bir kontrol sağlar.
400 ile 500 hatalarında hata ayıklama
400 hataları, geçersiz JSON veya eksik parametreler gibi istemci tarafı sorunlarını gösterir. 500 hataları, iç hatalar veya zaman aşımıları gibi sunucu tarafı sorunlarını ima eder. Bu iki hata türünü ayırt etmek, hata ayıklama sürecinizi hızlandırır.
400 hataları için, yanıtta sağlanan hata mesajını kontrol edin. Bu mesaj genellikle sorunun kaynağını doğrudan gösterir. 500 hataları için, kısa bir bekleme süresi sonrasında isteği tekrar deneyin. Hata devam ederse, istek kimliği ile destek birimine başvurun.
Her hata için istek ve yanıt ayrıntılarını günlüğe kaydedin. Bu, kalıpları ve tekrarlayan sorunları belirlemeye yardımcı olur. API entegrasyonunuzu geliştirmek için hataları zaman içinde izlemek amacıyla bir günlük servisi kullanın.
