AI ajanının NaN sonucu JSON’da null olursa hata nerede kaybolur?

Aynı boşluk, farklı nedenler

Ajanın hazırladığı tabloda bir oran boş görünüyor. Kaynak kayıtta değer hiç girilmemiş olabilir; hesapta payda sıfır çıkmış da olabilir. Bu iki durum aynı işlem kuyruğuna gönderilirse eksik veri toplamak isteyen ekip hesap hatasını bekletir, hesap düzeltmek isteyen ekip ise hiç gelmemiş değeri arar. Sorun, boş hücrenin görünümünden önce aktarım sırasında hangi bilginin korunduğudur.

Bu uygulamada JavaScript Number değerlerinden JSON metni üreten küçük bir aktarımı inceleyeceksiniz. JSON sayı dilbilgisi NaN ve Infinity gibi değerleri kabul etmez. ECMAScript’in JSON serileştirme kuralı ise sonlu olmayan Number değerlerini null olarak yazar. Dolayısıyla geçerli JSON elde edilmesi, hesap sonucunun anlamını koruduğunuzu tek başına göstermez. Bu davranışı bütün programlama dillerine genellememek gerekir.Kaynak: IETF — RFC 8259, bölüm 6Kaynak: TC39 — SerializeJSONProperty

Örnekteki kayıtlar sentetiktir. Hesaplar JavaScript davranışını göstermek için seçilmiştir; gerçek müşteri verisi veya çalışan bir ajanın ölçümü değildir. Çalışmanın çıktısı yeni bir üretim API’si değil, serileştirmeden önce uygulanabilecek açık bir kontrol sözleşmesidir. Kullandığınız araç başka dildeyse bölme ve serileştirme davranışını ayrıca sınayın.

Beş kaydı metne çevirin

Beş farklı kaynak durumundan dördü aynı JSON değeriyle görünür. J1 için belirsiz bölüm, J2 ve J3 için sıfıra bölme, J4 için bilinçli boşluk bilgisi ham sonucun yanında tutulmazsa daha sonra geri getirilemez. Özellikle null değerinden geriye bakıp “bu kayıt sıfıra bölünmüş” diyemezsiniz. Aynı aktarım çok sayıda farklı başlangıç durumuyla uyumludur.

Tablodaki nedenleri biliyoruz, çünkü işlem girdileri verilmiş. Tek başına NaN görmek nedenin mutlaka 0 / 0 olduğunu kanıtlamaz; başarısız bir sayı dönüşümü de NaN üretebilir. Benzer biçimde Infinity çok büyük sayıların taşmasından gelebilir. Durum etiketi, yalnızca gerçekten gözlenen girdi ve işlem kanıtına dayanmalıdır. Kanıt yoksa daha genel bir “sonlu olmayan sonuç” etiketi kullanın.

Değeri ve durumunu birlikte taşıyın

Önce beklenen türü, sonra sonluluğu kontrol edin. Bu örnekte geçerli sonuç yalnızca Number türünde ve Number.isFinite ile doğrulanan değerdir. Bilinçli null ayrı bir daldır. Sayıya zorlayarak kontrol yapmak bu ayrımı bozabilir: JavaScript’te Number(null) sıfır verir. Dolayısıyla önce dönüştürüp sonra sıfırı geçerli saymak, eksikliği ölçülmüş sıfır gibi kaydedebilir.

Etiketler örneğe özel tasarlanmıştır; JSON standardının zorunlu alanları değildir. Başarılı olmayan satırda value alanının null olması artık tek başına yorumlanmaz, status ile birlikte okunur. Alıcı sistem yalnız value alanını tüketiyorsa bilgi kaybı yine sürer. Bu yüzden tasarımın ikinci yarısı, alıcının ok dışındaki durumları sayısal toplam ve ortalamaya katmamasıdır.

Aktarım öncesinde her kimliğin tam bir çıktısı bulunmalı, toplam kayıt sayısı beş kalmalıdır. Üç hesap sorunu, bir bilinçli boş ve bir geçerli sonuç vardır. Hatalı kayıtları sessizce düşürmek, bu kez satır kapsamını kaybettirir. İnceleme kuyruğu oluşturulabilir; fakat kullanıcıya gösterilen tamamlanma bilgisi bu kuyruğun varlığını da içermelidir.

Ajandan kayıpsız karar izi isteyin

JavaScript Number değerlerini JSON’a aktaracak bir kontrol tasarla. J1=0/0, J2=1/0, J3=-1/0, J4=bilinçli null, J5=0/5. Önce ham değer ile JSON.stringify sonrasını karşılaştır. Tür dönüşümüyle null değerini sıfır yapma. Sonlu değer, bilinçli boş ve hesap sorunu için ayrı status üret. Neden etiketi yalnız verilen girdilerden çıkarılabiliyorsa ayrıntılı olsun. Beş kimliği de koru; başarısız kayıtları toplama katma. Standart kuralı ile örneğe özel alan tasarımını ayır.

J1 → {"status":"undefined_ratio","value":null}
J2 → {"status":"division_by_zero","value":null}
J3 → {"status":"division_by_zero","value":null}
J4 → {"status":"missing","value":null}
J5 → {"status":"ok","value":0}
Kapsam: 5 giriş, 5 durum kaydı; yalnız 1 kullanılabilir sayısal sonuç.

Bu çıktı gerçek bir model yanıtı değildir. Ajanın yanıtını değerlendirmek için hazırlanmış cevap anahtarıdır. Yanıtın JSON olarak ayrıştırılabilmesi ilk kontroldür; J4 ile J5’in ayrı kalması ikinci kontroldür. Üçüncü kontrolde ham sonuçtan kanıtlanamayan hata nedenlerinin uydurulmadığını inceleyin. Geçerli sözdizimi, bu üç kontrolün yalnızca ilkini karşılar.

Sonlu olmak yeterli bir iş kuralı değildir

Number.isFinite, sonucun matematiksel olarak beklenen aralıkta olduğunu söylemez. Eksi üç dakika sonlu bir sayıdır; süreç süresi alanında yine geçersiz olabilir. Benzer biçimde yüzde alanında 125 değerinin kabulü iş tanımına bağlıdır. Tür ve sonluluk kapısını alan aralığı, birim ve kapsam kontrolünden ayrı tutmak hangi nedenle reddedildiğini anlaşılır kılar.

Kontrolü metne dönüşümden sonra yapmak gecikmiş olur. Sonlu olmayan değer null haline geldikten sonra aynı ham durumu yeniden kuramazsınız. Gerekli tanıyı hesap adımında üretip aktarımda koruyun. Hata incelemesi için tüm kullanıcı metnini kopyalamak yerine kimlik, işlem türü ve gerekli sayısal kanıt gibi sınırlı alanların yeterli olup olmadığını değerlendirin.

Bir taşma kaydı ekleyin

J6 için JavaScript’te 1e308 * 1e308 hesaplandığını ve J7 için kaynakta 0 sayısının geldiğini varsayın. JSON metninde hangi değerleri görürsünüz? J6’yı otomatik olarak sıfıra bölme diye etiketlemek doğru mudur? Yanıtı önce kendiniz yazın; ardından kayıt sayısı ve kullanılabilir sonuç sayısını yeniden hesaplayın.

J6 ham sonuç Infinity, JSON değeri null olur. Verilen çarpma girdileri taşmayı açıklayabildiği için örnek sözleşmede overflow etiketi kullanılabilir; division_by_zero uygun değildir. J7 sayısal 0 olarak kalır ve ok olur. Toplam 7 kayıt, 2 geçerli sayısal sonuç, 1 bilinçli boş, 4 hesap sorunu bulunur.

Kendi aktarımınızda ilk deneyi yalnızca başarı satırıyla yapmayın. Bilinçli boş, geçerli sıfır ve hesaplanamayan sonuç birlikte sınandığında bilgi kaybı görünür hale gelir. Kabul ölçütünüz, alıcının bu üç duruma farklı ve önceden tanımlı işlem uygulayabilmesi olsun.