AI ajanı boş alanı güncelleme mi, silme mi saymalı?

Verilmeyen not ile null not farklı işler isteyebilir

Ajan bir kayıt başlığını değiştirecek. Kullanıcı not alanından söz etmediği için model bu alanı boş kabul edip isteğe null olarak ekliyor. Bazı güncelleme sözleşmelerinde bu, “nota dokunma” değil “notu kaldır” anlamına gelir. Gönderilen JSON biçim bakımından geçerli olabilir; buna rağmen kullanıcı istemediği bir veri değişikliği oluşabilir. Alanın değeri kadar, istekte bulunup bulunmaması da niyeti taşır.

Bu yazı yalnızca JSON Merge Patch sözleşmesini ele alır. Bütün HTTP PATCH uçları veya bütün JSON araçları aynı davranmaz. Gerçek entegrasyonda uygulamanın bu biçimi ve application/merge-patch+json içerik türünü desteklediği doğrulanmalıdır. Buradaki kayıt ve yamalar sentetiktir; herhangi bir API’ye yazma veya gerçek veri silme işlemi yapılmamıştır. Görev, gönderim öncesinde değişikliği önizlemektir.

{"baslik":"Hafta notu","not":"Taslak","ayarlar":{"dil":"tr","goster":true},"etiketler":["A","B"]}

Altı yamanın her biri bu aynı başlangıç kaydına bağımsız olarak uygulanacak. P2’de not kaldırıldıktan sonra P3’ü o sonuca uygulamıyoruz. Bağımsız başlangıç kullanmak, tek bir alan varlığı kararının etkisini karşılaştırmayı sağlar. Kayıt kimliği bu örnekte dış bağlamda sabit kabul edilir; modelin yeni bir kimlik üretmesi veya başka kaydı seçmesi istenmez.

Eksik alan korunur, null kaldırır, boş metin kalır

RFC 7396, JSON Merge Patch içinde null değerine mevcut üyeyi kaldırma anlamı verir; yamada bulunmayan üyeler korunur. Nesneler iç içe işlenirken dizinin yalnızca bir öğesi bu biçimle yamalanmaz; dizi değeri bütün olarak değiştirilir. Bu kuralların seçilmiş uygulama sözleşmesi olduğunu açık tutun. Null değerini gerçek iş verisi olarak saklamak isteyen başka bir API farklı bir biçim kullanabilir.Kaynak: RFC Editor — RFC 7396 JSON Merge Patch

P2 ile P3’ün ekranda benzer görünmesi mümkündür; ikisinde de görünen not boş olabilir. Fakat veri yapısı aynı değildir. P2’de not üyesi yoktur, P3’te vardır ve değeri boş dizgedir. Daha sonra varsayılan değer, filtre veya dışa aktarım yapan bir işlem bu iki durumu farklı yorumlayabilir. Kontrolünüz yalnızca ekranda boş görünmesine dayanmamalıdır.

Verilen başlangıç kaydına P1–P6 yamalarını ayrı ayrı JSON Merge Patch kurallarıyla uygularmış gibi beklenen sonuçları hesapla. Gerçek araca çağrı yapma. İstekte olmayan alanları null ile tamamlama. Her yamada değişen, kaldırılan ve korunan alanları yaz. P2 ile P3’te not üyesinin varlığını ayrı kontrol et. P5’te dil alanını koru. P6’nın dizi değiştirme olduğunu belirt. Kullanıcının niyeti belirsizse silme kararı uydurma.

Alt alanın silinmesi bütün ayarları silmez

P5, ayarlar nesnesindeki goster alanını kaldırır. dil alanı aynı nesnede bulunduğu halde yamada belirtilmediği için korunur. Modelin bu sonucu boş ayarlar nesnesi olarak göstermesi, iç içe güncellemenin kapsamını fazla genişlettiğini gösterir. Aynı şekilde P4 yalnızca başlığı değiştirirken notu veya etiketleri yeniden yazmak gereksiz ve bu örnekte istenmeyen bir değişikliktir.

{"baslik":"Hafta notu","not":"Taslak","ayarlar":{"dil":"tr"},"etiketler":["A","B"]}

P6’da A etiketi son dizide yoktur, çünkü yeni dizi yalnızca B içerir. Bu, “B’yi mevcut listeye ekle” komutu değildir. Kullanıcı ekleme istemişse modelin gereken bütün son diziyi doğru hazırlaması veya aracın desteklediği ayrı ekleme işlemini kullanması gerekir. Mevcut listeyi okumadan tek öğeli dizi göndermek, başka etiketlerin kaybolmasına neden olabilir.

• Yama biçimi ve içerik türü gerçek araç sözleşmesiyle doğrulanmış mı?
• Verilmeyen alanlar model tarafından null ile doldurulmuş mu?
• Kaldırılacak alanın kullanıcı niyeti açık mı?
• İç içe nesnede belirtilmeyen komşu alanlar korunmuş mu?
• Dizi değişimi ile öğe ekleme/çıkarma niyeti ayrılmış mı?
• Önizlemede alan varlığı ve değer ayrı kontrol edilmiş mi?

Önizleme doğru olsa bile gerçek yazma için güncel kayıt ve yetki kontrolü gerekir. Başka bir işlem arada kaydı değiştirmişse eski görüntüden hazırlanmış bir dizi yeni veriyi ezebilir. Bu yazı eşzamanlı yazma sorununu çözmüş sayılmaz; burada güncelleme belgesinin anlamını sabit bir başlangıç üzerinde sınadık. Araç sözleşmesinin sürüm veya koşullu yazma mekanizması varsa ayrıca uygulanmalıdır.

Modelden beklenen çıktı, yalnızca son JSON değildir. Değişiklik özeti de olmalıdır: hangi üye kaldırılacak, hangi değer boş kalacak ve hangi alan korunacak? Bu özet, kullanıcının görünürde küçük olan bir düzenlemenin etkisini görmesine yardımcı olur. Ancak özet ile gerçek yama çelişirse güvenilir olanı tahmin etmeyin; iki çıktıyı aynı başlangıç üzerinde tekrar karşılaştırın.

Boş ayarlar nesnesi ile null ayarlar aynı mı?

Alıştırmada iki bağımsız yama hazırlayın: birincisi {"ayarlar":{}}, ikincisi {"ayarlar":null}. Her birini başlangıç kaydına uyguladığınızda ne kalacağını yazın. Başlık, not ve etiketlerin değişmediğini de kontrol edin. Boş nesne ile null değerini yalnızca görsel benzerliklerine göre aynı karar olarak ele almayın.

{"ayarlar":{}}: mevcut dil ve goster alanları korunur; iç nesnede değişiklik istenmemiştir. {"ayarlar":null}: ayarlar üyesi bütünüyle kaldırılır. Her iki durumda da baslik, not ve etiketler başlangıçtaki değerlerini korur.

Kendi araç denemenizde gerçek bir kaydı değiştirmeden önce bu küçük bağımsız örnekleri kullanın. Kaynak görüntüyü, yama belgesini ve beklenen farkı aynı test kaydında tutun. Teslim edeceğiniz kontrol, JSON’un geçerli olduğunu söylemekle kalmasın; kullanıcı niyetinin hangi alanlarda hangi etkiye dönüştüğünü de açıkça göstersin.

Bu çalışma bir üretim uç noktasını kullanıma açmaz. Uygulamada yazma yapılacaksa desteklenmeyen alanlar, boyut sınırları ve iş kuralları da denetlenmelidir. Modelin burada doğru null yorumu yapması, bütün güncelleme taleplerinin otomatik kabul edileceği anlamına gelmez. Her kontrolün hangi soruyu yanıtladığını ayrı tutmak, test sonucunun kapsamını korur.