Yapay zekânın uçuş kaydediciye ihtiyacı var ve sen bunu ilk günden inşa ediyorsun.
Sizin herhangi bir yapay zeka çıktısını aylar sonra açıklayabildiğiniz ve müşteriden önce kalite sapmasını tespit edebildiğiniz birkaç kayıt.
Neden Bir Yapay Zeka Sistemi Üretime Girdiğinde İlk Zor Soru "Neden" Olur?
Bir yapay zeka (YZ) sisteminin üretime girmesi sırasında ilk zor soru, sistemin nasıl çalıştığı değil, neden belirli bir şekilde yanıt verdiği olur. Müşteriler alıntıları tartışabilir, denetçiler karar verme sürecini sorgulayabilir, takım üyeleriniz bu ay özetlerin kötüleştiğini fark edebilir ve başlangıç tarihini belirleyemeyebilirsiniz.
O an ya kayıtları tutuyorsunuz ya da tutmuyorsunuz; daha sonra yeniden inşa etmek mümkün değil. Bugünün aynı sorusunu bugün için aynı modele, bugün için aynı istek ve bugün için aynı verilerle tekrar çalıştırmak size bugünün yanıtını verir, ancak bu bir kanıt değildir.
Altı Yanıt Üreten Şey
Bir YZ yanıtı, benzersiz bir dizi girdinin sonucudur. Her çağrıda aşağıdaki tüm girdileri yakalayın:
- İstek: Tek benzersiz kimlik, zaman damgası, istek gönderen kişi veya sistem ve sunulan tam metin veya veriler.
- Bağlam: Sistem tarafından alınan ve modele sunulan her belge, kayıt veya satır, bireysel olarak tanımlanabilir ve her birinin sürümü.
- Talimatlar: İstek şablonu artı çalışma zamanında oluşturulan herhangi bir şey ve şablonun sürümü.
- Model: Belirli model tanımlayıcısı (aile adı yerine), kullanılan ayarlar: sıcaklık, belirteç sınırları, çağırabileceği araçlar dahil.
- Çıkış: Temizlenmeden önce ham yanıt ve işlenmiş sürüm arasındaki fark.
- Sonuç: Sonraki adımlar: bir kullanıcıya gösterilen, bir müşteriye e-posta olarak gönderilen, bir talebi onaylamak için kullanılan veya bir kişinin kabul edip düzenleyip reddetmesi.
Bağlamı ve talimatları bırakırsanız, yarım bir sohbet kalırsınız. Sistem neden o yanıtı verdiğini asla tam olarak belirleyemezsiniz.
Sürümler Herkes Tarafından Atlanıyor
Üç şey, kimsenin bir değişiklik isteği açmadan YZ sisteminde alt yapı düzeyinde değişir: biri istek şablonunu Salı öğleden sonra düzenler; satıcı modeli aynı API adı altında günceller; bilgi tabanı yeniden dizine alınır ve sistem aynı soruya farklı belgeler döndürmeye başlar.
Her biri kaliteyi etkileyebilir ve hiçbirinin çıktıda görünmediği bir günlük vardır. Her çağrıda istek, model ve veri dizini sürüm tanımlayıcılarını kaydedin ve "iyi hafta ile kötü hafta arasında ne değişti?" sorusuna dakikalar içinde cevap verin. Onlar olmadan, bir hafta tahminle uğraşmak ve genellikle üst düzey birinin beklemesi gerekir.
İnsan Düzeltmeleri En İyi Sinyalinizdir
Bir kişi YZ taslağını düzenlemeden göndermeden önce, tam olarak neyin yanlış olduğunu en spesifik terimlerle size bildirir. Orijinali ve düzenlenmiş sürümü saklayın.
Bunu yaparsanız iki sonuç doğar: Düzenleme oranı kalite ölçümü olarak izlenebilir ve her hafta kaydedilebilir, bu şikayetler gelmeden önce. Ve düzeltmeler bir dizi örneğe toplanır, kendi işinizin geliştirilmesinden kaynaklanır, satın alınmamış veya icat edilmemiş.
Kayma Bir Uyarı Değil, Karşılaştırmadır
Çıktıların kötüleştiğini gösteren hiçbir uyarı yoktur. Bozulma kademeli ve her tek tek yanıt mantıklı görünür.
Pratik yöntem, gerçek isteklerden oluşan sabit bir küme tutmak ve her ay tekrar çalıştırmaktır (asgari 100, gerçek trafikten ve zor durumlarınızı kapsayan). Yeni yanıtları saklananlarla karşılaştırın. Herhangi bir farklılıkta, bir kişi her ikisini de okur ve hangisinin daha iyi olduğunu belirler. Bu sadece girdileri kaydettiğinizden emin olmanız durumunda çalışır.
Bunu da mevcut rakamlarınızla birleştirin: düzenleme oranı, reddetme oranı, bir insana iletme, sistemin ilgili belgeleri bulamadığı yanıtların yüzdesi. Sonuncusundaki artış genellikle verilerinizin güncel olmadığını gösterir, modelin bozulmasıyla karıştırılmamalıdır.
Depolama ve Redaksiyonu İlk Belirleyin
Bu günlükler, müşterilerinizin girdiği her şeyi içerir, bu nedenle kişisel veriler hakkında aynı yükümlülükleri taşır. Yazıldığı şekilde alanları sınıflandırın, okunması gerekmeyenleri maskeleyin veya belirteçleştirin ve uygulamaları ayrı olarak depolarak bir hata durumunda kayıtların kaybolmamasını sağlayın.
Depolama süresini bilinçli olarak belirleyin. Kararların yasal veya düzenleyici ağırlığı varsa, risk süresi boyunca saklayın ve yalnızca ekstra erişim için ekstra katmanlar ekleyen bir "sadece ekleme" deposu olarak ayarlayın. Rutin trafik için daha kısa ve daha ucuzdur. Bir kişi politikayı belirlesin.
Depolama ucuzdur. Zorlu kısım, bu kayıtları canlı sisteme entegre etmeye çalışırken ortaya çıkar; çünkü açıklayamayacağınız bir çıktıyı açıklamanız gerektiğinde. Onları baştan inşa ediyoruz, çünkü YZ sistemini güvenilirden kanıtlanabilir hale getirir.