@nowayModel çıktısını JSON'a zorlamak: şema doğrulama, yeniden deneme ve maliyet üzerine pratik notlar
Yapay zekayı bir arayüzün değil bir hattın parçası yapınca ilk sorun şu oluyor: çıktıyı programın okuyabilmesi gerekiyor. Serbest metin işe yaramıyor. Bir yıldır üretimde çalışan bir hattımız var, günde yaklaşık 40 bin çağrı yapıyor ve çıktının tamamı yapılandırılmış. Öğrendiklerimi sıralayayım.
Birincisi, şemayı modelden isteyin ama doğrulamayı siz yapın. Çoğu sağlayıcı artık belirli bir şemaya uygun çıktı üretmeyi destekliyor ve bu oranı ciddi biçimde yükseltiyor. Yine de her çıktıyı kendi tarafınızda doğrulayın. Bizde doğrulamadan geçmeme oranı binde iki civarında ve bu, günde seksen hatalı kayıt demek.
İkincisi, şemayı sade tutun. Derin iç içe yapılar hata oranını artırıyor. Biz üç seviyeli bir yapıyı ikiye indirdik, hata oranı belirgin biçimde düştü. Alan adlarını da anlamlı seçin; kısaltma yerine açık isim kullanmak doğruluğu artırıyor çünkü model alanın ne olduğunu isimden anlıyor.
Üçüncüsü, boş değer politikası yazın. En sık karşılaştığımız sorun, modelin bilmediği alanı boş bırakmak yerine uydurması. Şemaya her alan için "bulunamazsa null" talimatını açıkça koyduk ve istem içinde bunu örnekle gösterdik. Uydurma oranı belirgin biçimde azaldı.
Dördüncüsü, yeniden deneme stratejisi. Doğrulama başarısızsa aynı isteği aynen tekrarlamak genelde aynı sonucu veriyor. Bizim yöntemimiz, ikinci denemede hata mesajını da isteme eklemek: "önceki çıktın şu sebeple geçersizdi, düzelt". Bu yöntemle başarısızlıkların yüzde 80'i ikinci denemede düzeliyor. Üçüncü deneme yapmıyoruz, onun yerine kaydı insan kuyruğuna atıyoruz.
Beşincisi, maliyet. Yeniden denemeler faturaya biniyor ama asıl maliyet kalemi şema değil, çıktı uzunluğu. Gereksiz alan istemeyin. Biz başta her kayıt için bir açıklama alanı istiyorduk, kimse kullanmıyordu, kaldırınca çıktı jetonları ciddi oranda düştü.
Altıncısı, sürüm uyumu. Şemayı değiştirdiğinizde eski kayıtlarla yeni kayıtlar farklı yapıda oluyor. Her kayda şema sürümü yazın. Bunu yapmadığımız dönemde geriye dönük bir raporu üretmek için iki ayrı okuyucu yazmak zorunda kaldık.
Yedincisi, sıcaklık ve kararlılık. Yapılandırılmış çıktıda yaratıcılığa ihtiyacınız yok, sıcaklığı düşük tutun. Aynı girdiye farklı zamanlarda farklı cevap gelmesi, hata ayıklamayı imkansız hale getiriyor. Biz ayrıca her çağrının girdisini ve çıktısını saklıyoruz, bir müşteri itiraz ettiğinde o anki tam kaydı gösterebiliyoruz.
Bir de küçük bir numara: çıktının içinde modelin kendi güven derecesini de isteyin, sonra bu alana göre düşük güvenli kayıtları insan kontrolüne yönlendirin. Mükemmel değil ama kaba bir filtre olarak işe yarıyor.
Benzer hatlar kuran var mı, yeniden deneme politikanız nasıl?
Birincisi, şemayı modelden isteyin ama doğrulamayı siz yapın. Çoğu sağlayıcı artık belirli bir şemaya uygun çıktı üretmeyi destekliyor ve bu oranı ciddi biçimde yükseltiyor. Yine de her çıktıyı kendi tarafınızda doğrulayın. Bizde doğrulamadan geçmeme oranı binde iki civarında ve bu, günde seksen hatalı kayıt demek.
İkincisi, şemayı sade tutun. Derin iç içe yapılar hata oranını artırıyor. Biz üç seviyeli bir yapıyı ikiye indirdik, hata oranı belirgin biçimde düştü. Alan adlarını da anlamlı seçin; kısaltma yerine açık isim kullanmak doğruluğu artırıyor çünkü model alanın ne olduğunu isimden anlıyor.
Üçüncüsü, boş değer politikası yazın. En sık karşılaştığımız sorun, modelin bilmediği alanı boş bırakmak yerine uydurması. Şemaya her alan için "bulunamazsa null" talimatını açıkça koyduk ve istem içinde bunu örnekle gösterdik. Uydurma oranı belirgin biçimde azaldı.
Dördüncüsü, yeniden deneme stratejisi. Doğrulama başarısızsa aynı isteği aynen tekrarlamak genelde aynı sonucu veriyor. Bizim yöntemimiz, ikinci denemede hata mesajını da isteme eklemek: "önceki çıktın şu sebeple geçersizdi, düzelt". Bu yöntemle başarısızlıkların yüzde 80'i ikinci denemede düzeliyor. Üçüncü deneme yapmıyoruz, onun yerine kaydı insan kuyruğuna atıyoruz.
Beşincisi, maliyet. Yeniden denemeler faturaya biniyor ama asıl maliyet kalemi şema değil, çıktı uzunluğu. Gereksiz alan istemeyin. Biz başta her kayıt için bir açıklama alanı istiyorduk, kimse kullanmıyordu, kaldırınca çıktı jetonları ciddi oranda düştü.
Altıncısı, sürüm uyumu. Şemayı değiştirdiğinizde eski kayıtlarla yeni kayıtlar farklı yapıda oluyor. Her kayda şema sürümü yazın. Bunu yapmadığımız dönemde geriye dönük bir raporu üretmek için iki ayrı okuyucu yazmak zorunda kaldık.
Yedincisi, sıcaklık ve kararlılık. Yapılandırılmış çıktıda yaratıcılığa ihtiyacınız yok, sıcaklığı düşük tutun. Aynı girdiye farklı zamanlarda farklı cevap gelmesi, hata ayıklamayı imkansız hale getiriyor. Biz ayrıca her çağrının girdisini ve çıktısını saklıyoruz, bir müşteri itiraz ettiğinde o anki tam kaydı gösterebiliyoruz.
Bir de küçük bir numara: çıktının içinde modelin kendi güven derecesini de isteyin, sonra bu alana göre düşük güvenli kayıtları insan kontrolüne yönlendirin. Mükemmel değil ama kaba bir filtre olarak işe yarıyor.
Benzer hatlar kuran var mı, yeniden deneme politikanız nasıl?
6 1 yorum
