Yapay Zekâdan JSON Almak: Yapı Doğruluğu ile İş Doğruluğu Farklıdır

Çıktı sözleşmesini mümkün olduğunca dar tutun

İlk adım hangi alanların gerçekten gerektiğini belirlemektir. Alan adı, türü, zorunluluğu ve izin verilen değerleri yazın. Modelden serbest bir metin nesnesi isteyip sonra bütün alanları güvenilir kabul etmek yerine açık şema kullanın. İhtiyaç olmayan alanlar gereksiz hata yüzeyi oluşturur.

JSON Schema, nesne özellikleri ve ek alanlar gibi kuralları tanımlayabilir. [1] Ancak şema tek başına veri kaynağındaki gerçeği bilmez. Bu nedenle yapı kontrolü, uygulamanın iş doğrulamasından önce gelen bir katman olarak düşünülmelidir.

Kimlik ve değeri kaynak sistemle karşılaştırın

Model ürün adından bir kimlik tahmin edebilir. Kimliğin biçimi doğru olsa bile katalogda bulunmayabilir veya başka müşteriye ait olabilir. Gerçek kayıt eşleştirmesi uygulama tarafından yapılmalıdır. Kullanıcının yetkisi ve etkin şirket bağlamı bu sorguya dahil edilmelidir.

Tarih, miktar ve para birimi için de aynı ayrım geçerlidir. Geçerli tarih biçimi, teslimatın o tarihte yapılabileceğini göstermez. Negatif olmayan bir miktar, stokta o kadar ürün bulunduğu anlamına gelmez. Her iş alanının kendi doğrulama kuralı olmalıdır.

Örnek: müşteri mesajından sipariş taslağı

Varsayımsal müşteri iki ürün istiyor ve birinin rengini belirsiz bırakıyor. Model eksik rengi kendiliğinden doldurursa şema geçebilir ama sipariş yanlış olur. Doğru tasarım, belirsiz alanı açıkça işaretlemek ve gerekli netleştirmeyi istemektir. Tahminin sipariş kararı haline gelmesine izin verilmemelidir.

Bu tablo, çıktıyı doğrudan komut olarak çalıştırmak yerine doğrulama katmanlarından geçirmek için önerilen çerçevedir.

Model metnini yürütülebilir içeriğe dönüştürmeyin

OWASP improper output handling rehberi, model çıktılarının yeterince doğrulanmadan veya temizlenmeden diğer sistemlere aktarılması riskini ele alır. [2] JSON içinde metin bulunması o metnin HTML, sorgu veya komut olarak güvenle kullanılabileceğini göstermez.

Uygulama, izin verilen işlemleri kendi koduyla seçmeli ve parametreleri uygun biçimde işlemelidir. Kullanıcıya gösterilen metin ile sunucuda yürütülen işlem ayrı yollar olmalıdır. Çıktı doğrulaması yalnızca model katmanında değil, hedef sistem sınırında da sürdürülmelidir.

Yeniden üretimi sınırsız döngüye çevirmeyin

Şema hatasında modeli tekrar çağırmak yardımcı olabilir, fakat sonsuz tekrar maliyet ve gecikme yaratır. Deneme sayısı, hata nedeni ve son kullanıcı davranışı tanımlansın. Aynı eksik bilgi modelde yoksa yeniden istemek gerçeği kendiliğinden oluşturmaz.

Önerilen yaklaşımda biçimsel hata yeniden üretime, belirsiz kullanıcı bilgisi netleştirmeye, yetki veya iş kuralı reddi ise uygun açıklamaya yönlenir. Her hata için “tekrar dene” düğmesi koymak yerine nedeni sınıflandırın.

Şema sürümünü uygulama sürümüyle birlikte yönetin

Yeni alan eklendiğinde eski tüketicinin davranışı test edilmelidir. İzin verilen durum listesine yeni değer gelmesi, istemci kodunda eksik dala neden olabilir. Model, şema ve iş kuralı sürümleri kayıtlı olursa hangi değişikliğin hataya yol açtığı araştırılabilir.

Kabul testinde boş alan, ek alan, yanlış kimlik, belirsiz renk, geçersiz tarih ve yinelenen işlem senaryolarını kullanın. Başarı ölçütü yalnızca geçerli JSON oranı değil, doğru ve uygun iş taslağının üretilmesi olmalıdır.

Sık sorulan sorular

### Yapılandırılmış çıktı kullanınca halüsinasyon biter mi? Hayır. Yapı kısıtı, içerikteki iddianın doğru olduğunu garanti etmez. Kaynak ve iş kuralı doğrulaması yine gereklidir.

Eksik alanı varsayılan değerle doldurmak uygun mu?

Ancak işletmenin açık ve güvenli bir varsayılan kuralı varsa. Müşteri tercihi veya kritik işlem bilgisini tahminle doldurmak yerine belirsizliği görünür kılın.