Bir cevap, net ve kibar olabilir, ancak tam da önemli olan noktada yanlış olabilir. Bir destek asistanı, doğru ürün açıklamasını alıntıladıktan sonra, kaynağın hiçbir zaman vermediği bir teslimat vaadini ekleyebilir.
Oluşturma ve doğrulama işlemlerini ayrı sorumluluklar olarak ele alıyorum. Model bir yanıt önerir. Uygulama ise bu yanıtın, sunum için gerekli olan kanıt ve ürün kurallarını karşılayıp karşılamadığını belirler.
Risk oluşturan iddiaları belirleyin
Her cümle aynı şekilde ele alınmak zorunda değildir. Bir selamlama cümlesi, pek az somut bilgi içerir. Bir fiyat, ürün kodu, garanti koşulu veya bağlantı ise müşterinin kararını doğrudan etkileyebilir.
Öncelikle bu somut iddiaları belirliyorum. Ardından doğrulayıcı, bunları elde edilen kaynaklarla veya güvenilir yapılandırılmış verilerle karşılaştırır. Bu süreçte ilişkiler korunmalıdır: Bir kaynakta 49 rakamını bulmak, seçilen ürünün fiyatının 49 avro olduğunu doğrulamak için yeterli değildir.
Para birimi, varyant, miktar, tarih ve pazar, bir değerin anlamını değiştirebilir. Yararlı bir kontrol, iddianın tamamının ilgili bağlamda desteklenip desteklenmediğini sorgulamaktır.
Bağlantıları güvenilir kaynak kayıtlarına bağlı tutun
Bir model, gerçekte var olmayan ancak inandırıcı görünen bir URL oluşturabilir. Ayrıca, yanlış bir ürüne yönlendiren gerçek bir URL de oluşturabilir. Ben, oluşturulan metinden derlenen yollar yerine, doğrulanmış kaynak kayıtlarından seçilen bağlantıları tercih ederim.
Bağlantı denetimi için açık bir normalleştirme politikası gereklidir. Yalnızca alan adlarını karşılaştırmak, birçok hatalı hedefi kabul etmeye yol açabilir. Geçerli biçimlendirme farklılıklarını dikkate almadan ham dizeleri karşılaştırmak ise geçerli bağlantıları reddedebilir.
Uygulama, doğrulama amacıyla oluşturulmuş bir URL’yi alırsa, bu alma işlemi kendi güvenlik sınırını oluşturur. Çoğu durumda, kontrollü bir kaynak kataloğuyla karşılaştırma yapmak, doğrulayıcıdan gelen rastgele ağ isteklerine izin vermekten daha basittir.
Etki alanı izin verdiği durumlarda deterministik denetimler kullanın
Yapılandırılmış ürün tanımlayıcıları ve bilinen fiyatlar, deterministik doğrulama için uygun adaylardır. Açık uçlu poliçe açıklamaları ise daha zordur: Anahtar kelimelerin eşleşmesi, bir cümlenin orijinal koşulları koruduğunu kanıtlayamaz.
Model tabanlı bir doğrulama aracı, anlamsal iddiaları incelemede yardımcı olabilir, ancak bu, hataya açık başka bir bileşen daha ekler. Ben olsam, bu aracı insan tarafından incelenmiş örnekler temelinde kalibre eder ve yüksek etkiye sahip kuralları açık bir şekilde belirtirdim. Aynı üreteç modeline bunun doğru olup olmadığını sormak, tek başına zayıf bir kanıt niteliğindedir.
Olası bir sonuç yapısı şöyledir:
{
"decision": "needs_revision",
"unsupported_claims": ["delivery_by_requested_date"],
"allowed_source_ids": ["shipping-policy-v3"],
"next_action": "ask_for_postcode"
}Bu örnek niteliğinde bir sözleşmedir. Önemli olan nokta, başarısızlığın, sonraki kodların göz ardı edebileceği genel bir Boole değeri yerine, işlem yapılabilir bir durum oluşturmasıdır.
Doğrulama başarısız olduğunda ne olacağını planlayın
Uygulama, daha sınırlı kanıtlara dayanarak süreci yeniden başlatabilir, dayanağı olmayan bir iddiayı kaldırabilir, eksik bilgileri isteyebilir veya görüşmeyi bir kişiye devredebilir. Bu seçim, başarısızlığın nedenine bağlı olmalıdır.
Yeniden denemeler için bir sınır konulmalıdır. Bir yanıt alınana kadar tekrar tekrar deneme yapmak, maliyeti artırabilir ve aynı zamanda doğrulayıcıdaki zayıf noktaları ortaya çıkarabilir. Her deneme, isteğin zaman ve harcama bütçesi sınırları içinde kalmalıdır.
Akış teknolojisi, tasarımı da değiştirir. Müşteriye halihazırda gösterilmiş olan metinler gizlenemez. Ürün, teslimattan önce doğrulama vaat ediyorsa, etkileyici iddiaların yayınlanmadan önce tamponlanmaları veya onaylanmış yapılandırılmış alanlardan oluşturulması gerekir.
Kanıt doğrulamasını, talimatlara duyulan güvenden ayrı tutun
Elde edilen bir belge, yararlı bilgiler ve kötü niyetli talimatlar içerebilir. Kanıt kontrolünden geçmek, o belgeye araç izinlerini veya sistem davranışını değiştirme yetkisi vermez. OWASP’ın komut satırı enjeksiyonu kılavuzu, bu ayrı güven sınırı için yararlı bir referans niteliğindedir.
Doğrulama hatalarının değerlendirme örnekleri haline gelmesini istiyorum. Desteklenmeyen her bir taahhüt veya hatalı bağlantı, sistemin bir dahaki sefere tanıması gereken somut bir davranışı ve ekibin iş akışını değiştirmeden önce çalıştırabileceği bir regresyon kontrolünü ifade eder.
25 Eylül 2026 tarihinde güncellenmiştir.