Bir uygulamanın müşteri mesajlarından konu ve öncelik bilgisi çıkardığını düşünün. Modelin uzun bir paragraf yerine konu ve öncelik alanları döndürmesi, sonucun uygulama içinde kullanılmasını kolaylaştırır. Fakat çıktı JSON biçimindeyse işin bittiğini düşünmek yanıltıcıdır: biçimsel olarak geçerli veri de eksik, yanlış veya yetkisiz bir işlem için kullanılabilecek değerler içerebilir.

Önce beklenen sözleşmeyi tanımlayın

Çıktının hangi alanları içerdiğini, her alanın türünü ve izin verilen değerleri belirleyin. Örneğin öncelik dusuk, normal veya yuksek olabilir. Belirsiz bir konuda modelin zorla değer uydurması yerine null ya da ayrı bir inceleme durumu kullanmak uygun olabilir. Alan adları ve seçenekler varsayımsal uygulamanızın ihtiyaçlarına göre belirlenmelidir.

JSON
{
  "konu": "teslimat",
  "oncelik": "normal",
  "insan_incelemesi_gerekli": false
}

Bu örnek beklenen biçimi anlatır; değerin doğru sınıflandırıldığını kanıtlamaz. Kullanıcının “ürünüm gelmedi” mesajının teslimatla ilgili olup olmadığını test verisiyle ölçmeniz gerekir. Modelin insan_incelemesi_gerekli alanına verdiği değer de tek güvenlik kontrolünüz olmamalıdır.

Şema uyumu ile anlam doğruluğunu ayırın

Bazı model sağlayıcıları JSON Schema benzeri bir tanımla yapılandırılmış çıktı isteyebilmenizi sağlar. Desteklenen şema özellikleri, model seçenekleri ve ret davranışları sağlayıcıya göre değişir. Resmî belgeleri kontrol edin ve şema desteğini düz metinde “lütfen JSON yaz” demekle aynı şey saymayın.

Uygulama tarafında yanıtı yine ayrıştırın ve kendi doğrulamanızı yapın. Alanlar beklenen türde mi? Beklenmeyen alanlar kabul edilecek mi? Metin alanlarının uzunluğu sınırlı mı? İşleme izin verilen kategori listesinde mi? Bir alan geçersizse sessizce varsayılan değer atamak bazı hataları gizleyebilir; uygun hata kaydı, yeniden deneme veya insan incelemesi belirleyin.

Eksik yanıtları da tasarlayın

İstek zaman aşımına uğrayabilir, model isteği reddedebilir veya yanıt çeşitli nedenlerle eksik kalabilir. Sağlayıcının SDK’sındaki durumları kendi akışınıza uygun şekilde ele alın. Tüm yanıtları otomatik olarak tekrar istemek maliyeti ve gecikmeyi artırabilir. Yeniden deneme yaparken önce hatanın geçici olup olmadığını ve işlemin tekrar edilmesinin güvenli olup olmadığını değerlendirin.

Çıktı, veritabanı sorgusu veya HTML içinde kullanılacaksa ilgili katmanın güvenlik kuralları da geçerlidir. Kullanıcı tarafından görülmüş bir model yanıtını HTML olarak güvenmeden göstermek XSS riskine; çıktıdan SQL üretip doğrudan çalıştırmak ise çok daha ciddi sonuçlara yol açabilir. Değerleri izin verilen seçeneklerle sınırlandırın, SQL parametrelerini bağlayın ve çıktıyı bağlama uygun kodlayın.

Küçük bir değerlendirme kümesi hazırlayın

Gerçek verilere erişim ve paylaşım koşullarını gözeterek normal, belirsiz ve sınırda örnekler içeren bir test kümesi oluşturun. Beklenen önceliği önceden tanımlayın; sonra geçerli şema oranı, doğru sınıflandırma ve insan incelemesine düşmesi gereken örnekler gibi ölçütleri ayrı inceleyin. Şemaya uyan tüm yanıtları otomatik olarak doğru saymayın.

Bir modeli, istemi veya şemayı değiştirdiğinizde aynı testleri yeniden çalıştırın. Hataları yalnızca ortalama başarı oranıyla özetlemek yerine hangi örneklerde ortaya çıktığını inceleyin. Özellikle ücret, teslimat taahhüdü veya hesap işlemi gibi sonuç doğuran alanlarda uygulamanın kuralları modelin tahmininden önce gelmelidir.

Kaynak: OpenAI yapılandırılmış çıktılar.