OpenAI, JSON modunda "kaçış" yapmanıza izin vermeyecek

é gibi aksanlı karakterler JSON'da \u00e9 olarak çıkarılabilir. OpenAI'nin ve Azure OpenAI'in uç noktalarının bunları JSON modunda doğru şekilde yaymadığını gördük: \u00 önekinden sonra kod çözücü yalnızca kontrol karakteri tamamlamalarına izin verir (\u0000–\u001f). Çıktı geçerli JSON olarak kalır ancak yanlış baytları tutar; genellikle NUL artı değişmez e9. Bu kontrol baytları ayrıştırıldıktan sonra bazı sistemleri bozabilir ve beklenmeyen hatalara yol açabilir. Bu bir JSON sınırlaması değil, belgelenmemiş bir uç nokta kısıtlamasıdır. Arıza modunu tanımlıyoruz, deneysel olarak yeniden üretiyoruz ve pratik azaltımlar sunuyoruz. é gibi aksanlı karakterler JSON'da \u00e9 olarak çıkarılabilir. OpenAI ve Azure OpenAI uç noktalarının JSON modunda bunları doğru şekilde yaymadığını gördük: \u00 önekinden sonra kod çözücü yalnızca kontrol karakteri tamamlamalarına ( \u0000 - \u001f ) izin verir. Yani oluşamıyorum. Çıktı geçerli JSON olarak kalır ancak yanlış baytları tutar - genellikle NUL artı sabit değer e9 ( \u0000e9 ). Bu kontrol baytları ayrıştırıldıktan sonra üretim sistemlerini bozabilir: örneğin, PostgreSQL metindeki NUL'u reddeder, günlükler ve dizinler sessizce bozulur. Bu bir JSON sınırlaması değildir; RFC 8259 herhangi bir \uXXXX kaçışına izin verir.

Bu, OpenAI ve Azure OpenAI'den belgelenmemiş bir uç nokta kısıtlamasıdır. Bu yalnızca aksanlı karakterler için değil, aynı zamanda CJK, Hintçe, Kiril vb. dahil olmak üzere JSON'da \uXXXX çıkışlı dizisinde modellerin oluşturmak istediği tüm UTF-8 karakterleri için de geçerlidir. Kısıtlama, modelin neyi ifade edebileceğini sınırlamaz: JSON, ham UTF-8'i kabul edebilir, dolayısıyla é veya diğer UTF-8 karakterlerinin mutlaka kaçılması gerekmez. Sorun, istem örnekleri \uXXXX kaçışlarını (Python'da varsayılan!) kullandığında başlar: model bunları taklit eder, kaçış girişiminde bulunur ve engellenen yola ulaşır.