TensorFlow 2.0'ın sembolik API'sinin ve zorunlu API'sinin ayrıntılı açıklaması
Leifeng.com AI Teknolojisi Yorumu: Birkaç gün önce Josh Gordon, TensorFlow resmi web sitesinde sembolik API (sembolik API) ve zorunlu API'yi (zorunlu API) ayrıntılarıyla anlatan ve iki stilin avantajlarını ayrıntılı olarak açıklayan bir blog yayınladı. Ve sınırlamalar ve her birinin hangi senaryolar için geçerli olduğu. Leifeng.com AI Technology Review aşağıdaki gibi derlenmiştir.
TensorFlow 2.0'daki favorilerimden biri, projeniz için en uygun seviyeyi seçmenize olanak tanıyan çoklu soyutlama seviyeleri sağlamasıdır. Bu yazıda, sinir ağı oluşturmanın iki tarzının nasıl tartılacağını açıklayacağım:
-
İlki semboliktir, yani bir hiyerarşi diyagramı çalıştırarak bir model yaratırsınız;
-
İkincisi, bir sınıfı genişleterek bir model oluşturduğunuz bir zorunluluktur.
Bu iki stili tanıtmanın yanı sıra, dikkat edilmesi gereken önemli tasarım ve uygulanabilirlik noktalarını da paylaşacağım ve makalenin sonunda size doğru stili seçmenize yardımcı olacak bazı öneriler vereceğim.
Sembolik API
Bildirimsel API olarak da bilinen Sembolik API.
Bir sinir ağını düşündüğümüzde, genellikle zihinsel modeli aşağıdaki şekilde gösterildiği gibi bir "hiyerarşik diyagram" olarak kullanırız:
Bir sinir ağını düşündüğümüzde, zihinsel modeli temsil etmek için genellikle bir "seviye grafiği" kullanırız (görüntü, Inception-ResNet'in şemasıdır)
Grafik, solda gösterildiği gibi yönlendirilmiş çevrimsiz bir grafik (DAG) olabilir; ayrıca sağda gösterildiği gibi bir yığın grafiği (yığın) olabilir. Bir model oluşturmak için sembolleri kullandığımızda, onu diyagramın mimarisini tanımlayarak oluştururuz. Bu işlem kulağa teknik gelse de, Keras'ı daha önce kullandıysanız, zaten ilgili deneyime sahip olduğunuzu görünce şaşıracaksınız. İşte bir model oluşturmak için sembollerin kullanımına ilişkin basit bir örnek Bu örnekte, Keras'ın Sıralı API'si kullanılmıştır.
Sinir ağlarını sembolik olarak oluşturmak için Keras'ın Sıralı API'sini kullanın. Bu örneği çalıştırmak için buraya tıklayabilirsiniz.
Yukarıdaki örnekte, bir katman yığını tanımlıyoruz ve ardından onu eğitmek için yerleşik eğitim döngüsünü (model.fit) kullanıyoruz.
Bir model oluşturmak için Keras'ı kullanmak, "Lego bloklarını bir araya getirmek" kadar basittir. Neden öyle diyorsun? Zihinsel modelin eşleştirilmesine ek olarak, daha sonra tanıtılacak teknik nedenlerle, çerçeve detaylı hatalar sağlayabildiğinden, bir model oluşturmak için bu yöntemi kullanarak kolayca sorun giderebilir.
Bu şekil, yukarıdaki kodla oluşturulan modeli göstermektedir (plot_model kullanılarak oluşturulmuştur, bu kod parçacığını bu makalenin bir sonraki örneğinde yeniden kullanabilirsiniz)
TensorFlow 2.0 ayrıca başka bir sembolik API sağlar: Keras Functional. Sıralı, yığın grafikler için bir API'dir ve İşlevsel, düşündüğünüz gibi, DAG için bir API'dir.
Birden çok girdi / birden çok çıktı modeli oluşturmak için İşlevsel API'yi kullanın.
İşlevsel API, doğrusal olmayan topolojileri, paylaşılan katman modellerini ve birden çok giriş veya çıkışa sahip modelleri işleyebilen daha esnek modeller oluşturmanın bir yoludur. Genel olarak, Functional API, bu hiyerarşik grafikleri oluşturmak için bir araç setidir. Şimdi, size bu API'leri nasıl kullanacağınızı öğretmek için bazı yeni eğitimler hazırlıyoruz.
Ek olarak, kullanmış olabileceğiniz başka sembolik API'ler de vardır. Örneğin, TensorFlow v1 (ve Theano) çok daha düşük düzeyde bir API sağlar. Derlerken ve çalıştırırken, bir operasyon diyagramı tasarlayarak bir model oluşturabilirsiniz. Bazen, bu API'yi kullanmak, doğrudan bir derleyici ile etkileşimde olduğunuzu hissetmenize neden olabilir. Birçok kişi için (yazarlar dahil) API'nin kullanımı daha zordur.
Buna karşılık, Keras'ın İşlevsel API'sini kullanarak, soyutlama seviyesi zihinsel modelle eşleşebilir: Lego bulmacaları gibi dikiş hiyerarşileri. Bu API, kullanımı daha doğal hissettiriyor ve aynı zamanda TensorFlow 2.0'da standart hale getirdiğimiz model oluşturma yöntemlerinden biridir. Ardından, başka bir API stili tanıtacağım (aynı zamanda bu stili kullanmış olabilirsiniz veya bu API'yi yakında deneyebilirsiniz).
Zorunlu API
Model Alt Sınıflandırma API'si olarak da bilinen zorunlu API.
Zorunlu API'de modeli NumPy gibi yazarsınız. Bu API ile modeller oluşturmak, nesne yönelimli Python geliştirmek gibi hissediyor. Aşağıda bir alt sınıflandırma modelinin basit bir örneği verilmiştir:
Metin içeren bir görüntünün modelini oluşturmak için zorunlu API'yi kullanın (not: bu örnek şu anda güncellenmektedir).
Bir geliştiricinin bakış açısından, çalışma şekli çerçeve tarafından tanımlanan model kategorilerini genişletmek, modeldeki katmanları örneklemek ve ardından zorunlu olarak modelin ileri geçişini ve geri geçişi yazmaktır. pass) otomatik olarak oluşturulur.
TensorFlow 2.0, modeller oluşturmak için mevcut Keras alt sınıflandırma API'lerinin kullanımını destekler. Sıralı API ve Fonksiyonel API gibi, TensorFlow 2.0 ile modeller oluştururken önerilen yöntemlerden biridir.
Bu yöntem TensorFlow'da nispeten yeni olsa da, Chainer'ın onu 2015 gibi erken bir zamanda tanıttığını görünce şaşıracaksınız (zaman uçuyor!) O zamandan beri, birçok çerçeve Gluon dahil benzer yöntemler benimsemiştir. PyTorch ve TensorFlow (ve Keras Alt Sınıflandırma). Şaşırtıcı bir şekilde, bu stil kullanılarak farklı çerçevelerde yazılan kod çok benzer görünüyor ve araştırmacıların hangi kodun hangi çerçeveden olduğunu ayırt etmeleri zor olabilir!
Bu tarz, geliştiricilere büyük bir esneklik getirebilir, ancak aynı zamanda bazı belirsiz uygulanabilirlik ve bakım maliyetleri de getirir. Bunu daha sonra daha ayrıntılı olarak tartışacağız.
Lloop Eğitimi
Özel bir model, Sıralı API, Fonksiyonel API veya alt sınıflandırma stilini kullanıp kullanmadığına bakılmaksızın iki şekilde eğitilebilir:
-
Birincisi, yerleşik eğitim yolunu ve kayıp işlevini kullanmaktır (ilk örnekte belirtildiği gibi, model.fit ve model.compile kullandık);
-
Diğeri, daha karmaşık bir eğitim döngüsünü (örneğin, gradyan kırpma kodunu kendiniz yazmak istediğinizde) veya kayıp işlevini özelleştirmektir, aşağıdaki gibi kolayca uygulayabilirsiniz:
Pix2Pix için özel eğitim döngüsü ve kayıp işlevi örneği
Bu yöntemleri dış dünyaya açmak çok önemlidir ve kod karmaşıklığını ve bakım maliyetlerini azaltmak için kullanılması çok uygundur. Genel olarak konuşursak, karmaşıklığı artırmak yardımcı oluyorsa, onu artırabilir ve kullanabilirsiniz; gerekli değilse, sadece yerleşik yöntemi kullanın ve araştırma veya projenize daha fazla zaman ayırın. .
Artık hem sembolik API hem de zorunlu API hakkında bir anlayış oluşturduğumuza göre, her birinin avantajlarına ve dezavantajlarına bakalım.
Sembolik API'lerin avantajları ve sınırlamaları
Avantaj
Sembolik API kullanılarak oluşturulan model, grafik benzeri bir veri yapısıdır; bu, modelinizin izlenebileceği veya bir araya getirilebileceği anlamına gelir.
-
Modeli, bir grafik çizmek için bir görüntü olarak kullanabilirsiniz (keras.utils.plot_model kullanarak) veya katmanların, ağırlıkların ve şekillerin açıklamasını sunmak için model.summary'yi kullanabilirsiniz.
Benzer şekilde, katmanları birbirine dikerken, geliştirme kitaplığının tasarımcısı bir genişletilmiş katman uyumluluk kontrolü çalıştırabilir (model oluşturulduğunda ve model çalıştırılmadan önce).
-
Bu, derleyicideki tür kontrolüne benzer ve geliştirici hatalarını büyük ölçüde azaltabilir.
-
Çoğu sorun giderme, yürütme sırasında değil, model özelleştirme sırasında yapılır. Derlenen tüm modellerin normal şekilde çalışabileceğini garanti edebilirsiniz, bu da yinelemeyi hızlandırır ve sorun gidermeyi kolaylaştırır.
Sembolik modeller, bu modellerin yeniden kullanılmasını ve paylaşılmasını kolaylaştıran tutarlı bir API sağlar. Örneğin, transfer öğrenmede, orta katmandaki nöronlara erişerek mevcut nöronlardan yeni modeller oluşturabilirsiniz, örneğin:
Sembolik model, doğal olarak kopyalanabilen ve klonlanabilen bir veri yapısı ile tanımlanır.
-
Örneğin, Sıralı API ve Fonksiyonel API model.get_config, model.to_json, model.save, clone_model (model) sağlayabilir ve aynı zamanda aynı modeli yalnızca veri mimarisine güvenerek (tanım ve eğitim modeline erişim olmadan) yeniden oluşturabilir. Orijinal kod).
İyi tasarlanmış bir API, sinir ağının zihinsel modeline uygun olsa da, programcılar olarak tüm zihinsel modellerimizi eşleştirmek de aynı derecede önemlidir. Çoğumuz için bu zihinsel model, zorunlu bir programlama tarzıdır. Sembolik API'de, grafikler oluşturmak için "bildirim temelli tensörleri" (bu tensörlerin değeri yoktur) işlersiniz. Keras'ın Sıralı API'si ve Fonksiyonel API'si "zorunlu" gibi geliyor, geliştiriciler modeli sembollerle tanımladıklarının farkına varmadan tasarlandılar.
sınırlama
Mevcut sembolik API'ler nesli, en pratik uygulamaların ihtiyaçlarını karşılayabilen yönlendirilmiş döngüsel olmayan grafik modellerinin oluşturulması için çok uygun olabilir.Ancak, ağaç şekilleri gibi bu kısa soyutlamaya uymayan bazı özel durumlar vardır. Tekrarlayan sinir ağları ve tekrarlayan sinir ağları gibi dinamik ağlar.
Bu nedenle TensorFlow ayrıca zorunlu bir model oluşturma API stili (yukarıda belirtilen alt sınıflandırma API'si) sağlar. Sıralı API veya Fonksiyonel API kullanıyor olsanız da, tüm tanıdık katmanları, başlatıcıları ve optimize edicileri kullanacaksınız. Aynı zamanda, iki API türü tamamen birlikte çalışabilir, böylece ikisini karıştırıp eşleştirebilirsiniz (örneğin, bir modeli diğerine yerleştirmek). Sembolik bir modeli alıp alt sınıflandırma modelinde bir katman olarak kullanabilirsiniz veya bunun tersi de geçerlidir.
Zorunlu API'lerin avantajları ve sınırlamaları
Avantaj
İleri geçiş, zorunlu bir şekilde yazılır; bu, geliştirme kitaplığı tarafından uygulanan parçaları (bir katman, bir nöron ve bir kayıp işlevi gibi) kendi uygulamanızla değiştirmeyi kolaylaştırır. Bu şekilde programlama da çok doğaldır ve derin öğrenmenin temelleri hakkında fikir edinmenin iyi bir yoludur.
-
Bu aynı zamanda yeni fikirleri çabucak denemenizi kolaylaştırır (derin öğrenme geliştirme iş akışı nesne yönelimli Python ile aynı olacaktır) ve özellikle araştırmacılar için faydalıdır.
-
Modelin ileri geçişinde herhangi bir kontrol akışını belirtmek için Python'u kullanmak da kolaydır.
Zorunlu API'ler size maksimum esneklik sağlar, ancak aynı zamanda bir bedeli vardır. Bu tarzda kod yazmayı seviyorum, ancak yine de sınırlamalarını vurgulamak için biraz vakit ayırmak istiyorum (bu yöntemin avantajlarını ve sınırlamalarını tartmanın iyi olduğunu fark ederek).
sınırlama
Zorunlu API'yi kullanırken, model belirli bir kategori yöntemi ile tanımlanır. Bu durumda, model artık net bir veri yapısı değil, opak bir bayt kodudur. Bu API stilinin kazandığı esneklik, kullanılabilirlik ve yeniden kullanılabilirlik karşılığında gelir.
Sorun giderme, model tanımlandığında değil, yürütme sırasında gerçekleşir.
-
Bu API stilini kullanırken, neredeyse hiçbir girdi veya katmanlar arası uyumluluk kontrol edilmediğinden, çerçeveden geliştiriciye çok fazla sorun giderme baskısı aktarılır.
Zorunlu modelin yeniden kullanılması zordur. Örneğin, orta katmana veya nöronlara erişmek için tutarlı bir API kullanamazsınız.
-
Aksine, nöronları çıkarmanın yöntemi, yeni bir kategori yazmak için yeni bir çağrı (veya ilerletme) yöntemi kullanmaktır. İlk başta, bu işlemi ilginç ve basit bulabilirsin, ancak standart yoksa teknik borç (teknoloji borcu) haline gelecektir.
Zorunlu modellerin algılanması, kopyalanması ve klonlanması da zordur.
-
Örneğin, model.save, model.get_config ve clone_model'in alt sınıflı modeller üzerinde hiçbir etkisi yoktur ve model.summary size yalnızca bir katman listesi verebilir (ve nasıl bağlandıklarına ilişkin herhangi bir bilgi sağlamaz. Çünkü bu bilgiye ulaşılamıyor).
Makine öğrenimi sistemindeki teknik borç (Teknik borç)
Unutmayın: model oluşturma, makine öğreniminin pratik uygulamasının yalnızca küçük bir parçasıdır. Bu konuda çok sevdiğim bir açıklama var: modelin kendisi (belirtilen katmanın kod kısmı, eğitim döngüsü vb.) Makine öğreniminin merkezinde küçük bir kutudur.
Gerçekte, yukarıdaki şeklin ortasındaki küçük blokta gösterildiği gibi, bir makine öğrenimi sisteminin yalnızca küçük bir kısmı makine öğrenimi kodundan oluşur. Kaynak: Makine Öğrenimi Sistemlerinde Gizli Teknik Borç
Sembolik olarak tanımlanan modellerin yeniden kullanılabilirlik, sorun giderme ve test etme açısından avantajları vardır Örneğin, öğretim süresi boyunca, öğrenciler Sıralı API'yi kullanırsa sorunu hemen giderebilirim; alt sınıflı bir model kullanırlarsa (çerçeveden bağımsız olarak), sorunu gidermek daha uzun sürecektir (sorun daha fazla olacaktır. Tespiti kolay değildir ve daha fazla türü vardır).
sonuç olarak
TensorFlow 2.0, doğrudan sembolik API ve zorunlu API'yi destekler, böylece projenize en uygun soyutlama düzeyini (karmaşıklık) seçebilirsiniz.
Amacınız kullanım kolaylığı, düşük bütçe ise ve modeli bir hiyerarşi diyagramı olarak düşünme eğilimindeyseniz , Ardından Keras'ın Sıralı API'sini veya İşlevsel API'sini (Lego bloklarını birleştirmek gibi) ve yerleşik eğitim döngüsünü kullanın. Bu yöntem çoğu sorun için uygundur.
Modeli, modelin esnekliğini ve hacklenebilirliğini göz önünde bulundurarak nesne yönelimli bir Python / Numpy geliştiricisi olarak düşünmeyi tercih ediyorsanız , Keras'ın Alt Sınıfı gibi API'ler sizin için daha uygun olacaktır.
Umarım bu özet yazı herkese yardımcı olur, okuduğunuz için teşekkürler! TensorFlow 2.0 yığını ve diğer model oluşturma API'leri hakkında daha fazla bilgi edinmek isterseniz bu makaleyi okuyabilirsiniz. TensorFlow ve Keras arasındaki ilişki hakkında daha fazla bilgi edinmek isterseniz buraya gidebilirsiniz.
aracılığıyla: https://medium.com/tensorflow/what-are-symbolic-and-imperative-apis-in-tensorflow-2-0-dfccecb01021 Lei Feng.com, AI Technology Review tarafından derlenmiştir.
