JSON’unuz doğru olabilir, ama verileriniz hatalı mı? LLM’lerin yakalayamayacağı 5 yaygın hata

Başlık: JSON Verilerinizin Geçerli Olmasına Rağmen Yanlış Olabilir: LLM Yapılandırılmış Çıktılarının Yakalayamayacağı Beş Başarısızlık Modu

İçerik:

Constrained decoding, gerçek bir sorunu çözdü. Outlines ve SGLang gibi gramer tabanlı yöntemlerden önce, bir dil modelinden geçerli JSON almak, sürekli bir deneme yanılma döngüsü gerektiriyordu. İstek gönderiyordunuz, ayrıştırıyordunuz, sondaki virgülü düzeltiyor, tekrar istek gönderiyordunuz. Constrained decoding bunu sonlandırdı: token seçimini sınırlı bir durum makinesi aracılığıyla zorlayarak her çıktı geçerli hale geldi.

Takımlar bunu hızla benimsemişti. Şema uyumluluğu neredeyse %100’e yükseldi. Ve sonra, üretim kod tabanlarında sessiz bir varsayım ortaya çıktı: JSON şemaya uygunsa, veriler doğrudur.

BAML’nin ölçümleri başka bir şey söylüyor. Fonksiyon çağırma görevlerinde, post-hoc ayrıştırmayla sınırlı olmayan üretime göre %93,63 doğruluk oranı elde edilirken, aynı model üzerinde constrained decoding ile %91,37 oranına düşülmüştür. Her zaman geçerli olan JSON, bazen bozuk olan JSON’dan daha az doğruydu.

Ben bunu, oluşturduğum sınıflandırma hattının yaklaşık on iki çalışmadan birinde, doğrulanabilir ancak uydurulmuş değerler döndürmeye başladığını fark ettikten sonra takip etmeye başladım. JSON her zaman geçerliydi. Pydantic hiçbir zaman şikayet etmedi. Sorunun farkına varmak haftalar sürdü, çünkü tüm sonraki kontroller yapısaldaydı.

Sürekli olarak ortaya çıkan beş başarısızlık modu var. Bunlar hepsi, şema tarafından geçerli çıktılar üretir ve hattınızı sessizce bozurlar:

Enum halüsinasyonu: geçerli bir enum değeri, ancak yanlış anlam
Kendinden emin uydurma: ücretsiz metin alanlarında olası değerler
Alanlar arası tutarsızlık: her alan için geçerli, ancak birlikte imkansız
Dağılım çöküşü: güvenli varsayılanlara doğru yakınsama
Dizi halüsinasyonu: boş diziler yerine uydurulmuş girişler

Yapılandırılmış çıktı, modelin nasıl davranacağını ummak anlamına geliyordu. Constrained decoding bu sorunu çözmek için geliştirildi ve bunu yaptı, ancak tüm sorunu değil.

İlk dürtü, daha fazla doğrulama kuralı yazmaktır. Bilinen kalıplar için bu işe yarar. Bir Pydantic model_validator, start_date > end_date durumunu yakalar. Özel bir kontrol, alanlar arası tutarsızlıkları tespit eder. Her gördüğünüz başarısızlık için bir doğrulama kuralı yazabilirsiniz.

Sorun, henüz görmediğiniz başarısızlıklar. Yapısal doğruluk kapalıdır: verilen her şema için geçerli JSON şeklini sayabilirsiniz. Anlamsal doğruluk ise sonsuzdur. Henüz karşılaşmadığınız yanlış bir cevap için bir kural yazamazsınız. Üretimde, model yeni yollarla yanlış cevaplar üretir ve yazdığınız her doğrulama kuralı sadece son hatayı çözer.

Constrained decoding’in parse güvenilirliği için varsayılan olarak kullanılması, semantik kontrollerin de üzerine inşa edilmesi gereken bir çözüm sunar.

Katman 1: Şema ve yapısal doğrulama. Zaten sahip olduğunuz şey bu: Pydantic, JSON Schema, Zod. Bu, tür hatalarını, eksik alanları ve sözdizimsel olarak geçersiz enum değerlerini yakalar. Bunu koruyun. Bu, sözdizimi sorununu iyi çözer.

Katman 2: Anlamsal doğrulayıcılar. Alanlar arası tutarsızlıkları tespit eden iş mantığını kodlayan alanlar arası kısıtlama fonksiyonları. Değerlerin zaman içindeki dağılımını izleyen dağılım monitörleri. Dağılım bir eşiğin altına düştüğünde, dağılımsal çöküşü, sonraki ölçümlerin kaymasına yol açmadan önce tespit edebilirsiniz.

Ambigü veya uç durum girdilerinden oluşan periyodik örnek kontrolleri, kendinden emin uydurma hatalarını yakalar. Bu katman, alan bilgisi gerektirir ve sürekli bakım ister, ancak çoğu başarısızlık modunu kapsar, çünkü anlamı değil, şekli kontrol eder.

Katman 3: Belirsizliği ortaya çıkarma. Modelin bilmediğini ifade edebilmesi için her çıkarılan değere eşlik eden isteğe bağlı bir güven düzeyi alanı ekleyin. Cleanlab’ın CONSTRUCT ölçümü, GPT-5 ve Gemini’den yapılandırılmış çıktıların hata oranlarını, istem düzeyindeki güven tahminlerinden daha yüksek hassasiyetle tespit eder.

Yüksek maliyetli alanlar için, LLM-as-judge doğrulaması: çıkarılan değerin girdiyi destekleyip desteklemediğini değerlendiren ikinci bir model çağrısı. Bu, gecikme anlamına gelir. Karşılığında, hataların hattınıza ulaşmadan önce yakalanmasını sağlar.

Çoğu ekip yalnızca 1. katmana sahip. 2. katman, sessiz başarısızlıkların çoğunu yakalar. 3. katman, yanlış bir cevabın maliyetinin ek gecikmeden daha yüksek olduğu alanlar içindir.

Bu hataları tek tek çıktılar inceleyerek yakalayamazsınız. Sinyaller istatistikseldir.

Değerlerin entropisi düşüyor. Değerin zaman içinde değişmesi gereken bir alanda, değerler tek veya iki değere yakınsama eğilimindeyse, model güvenli varsayılanlara doğru ilerliyordur. Değer dağılımlarını haftalık olarak çizin.

Hiçbir çıktı boş değil. Bir dizinin bazen boş olması gereken bir alanın hiçbir zaman [], döndürmemesi durumunda, model girişler uyduruyordur. Boş dizi oranını beklenen temel orana göre izleyin.

Sonraki ölçümler değişiyor, ancak model sürümü, istem ve şema değişmiyor. Modelin anlamsal doğruluğu bozulmuş olabilirken yapısal uyumluluk mükemmel kalmış olabilir. Bu, en zor tespit edilebilir sinyaldir ve genellikle ilk görülen sinyaldir.

Parse güvenilirliği için constrained decoding’i varsayılan olarak kullanın. Onun tasarlanmadığı semantik kontrolleri üzerine inşa edin.

Şema doğrulaması, verilerin doğru olduğunu asla söylemez. Verilerin doğru bir şekilde biçimlendirilmiş olduğunu söyler. Bu iki iddia arasındaki boşluk, bu başarısızlık modlarının bulunduğu yerdir.