EMNLP 2017 Stuttgart Üniversitesi: İşlev Asistanı: NL sorgu API'si aracı
[Özet] Bu makalede, doğal dili kullanarak kaynak kod kitaplıklarını sorgulamak ve keşfetmek için hafif Python tabanlı bir araç seti olan bir işlev yardımcısını açıklıyoruz. Araç seti, hedef API'nin son kullanıcılarının yüksek seviyeli doğal dil sorgusu ve açıklaması aracılığıyla işlevler hakkında hızla bilgi bulmasına yardımcı olmak için tasarlanmıştır. Araç, belirli bir metin sorgusu ve arka plan API'si için, Richardson ve Kuhn'un (2017) anlamsal analiz yöntemini kullanarak, metinden API'deki bilinen bir temsile çeviri yaparak aday işlevleri bulur. Örnek API'de, çeviri otomatik olarak örnek metin kodu çiftinden öğrenecektir. Araç seti, herhangi bir kaynak kodu projesi için çeviri ardışık düzenleri ve sorgu motorları oluşturmak için özellikler içerir. Bu ikinci özelliği keşfetmek için Github'da barındırılan 27 tanınmış Python projesi üzerinde yeni deneyler yaptık.
Yazılım geliştiricileri, yeni uygulamalar geliştirirken genellikle farklı üçüncü taraf yazılım kitaplıklarına veya API'lere geçiş yapar. Geliştirme süresinin çoğu, bu API'lerin yapısını anlamaya, hedef işlevlerin yerini bulmaya ve bu yazılımların yapısal özelliklerinin veya adlandırma kurallarının nasıl çalıştığını anlamaya ayrılmıştır. Hedef API büyük olduğunda, gerekli işlevselliği bulmak zor ve zaman alan bir görev olabilir. Genellikle geliştiriciler, sorulara yanıt bulmak için (genellikle dolaylı) Google veya StackOverflow gibi kaynakları kullanır.
Bu sorunları açıklamak için Şekil 1'deki ünlü NLTK araç setinde iki örnek işlev kullanıyoruz. Her işlev, kısa bir belge dizesiyle, yani her işlevin altında yazılım kullanıcıları için işlevsel bir açıklama sağlayan bir referans açıklamasıyla eşleştirilir. Belgeleri ve kodu anlamak, analiz ve grafik konusunda teknik bilgi gerektirse de, bu bilgiyle bile, işlev adlandırma kuralları oldukça gelişigüzeldir. Add_arc işlevi ayrıca create_arc olabilir. Başka bir adlandırma kuralı bekleyen son kullanıcılar, bu özelliği ararken yoldan çıkabilir. Benzer şekilde, mevcut açıklama, son kullanıcı tarafından açıklanan işlevden farklı olabilir.
Aksine, remove_by_address işlevinin anlaşılması, kullanılan belirli DependencyGraph uygulamasının ayrıntılarının anlaşılmasını gerektirir. Bununla birlikte, bu işlev, bağımlılık grafiğinden düğümleri kaldırmanın standart işlemine karşılık gelir. Burada, belirli bir adrese özgü silme işleminin nasıl yapılacağına ilişkin teknik ayrıntılar, özelliğin genel amacını karıştırarak bulmayı veya anlamayı zorlaştırabilir.
İlk yaklaşımda, belirli bir API'de gezinmenin, metin açıklaması ile kaynak kodu temsili arasındaki uygunluğu bilmesi gerekir. Örneğin, Şekil 1'deki İngilizce ifadenin bir yay eklediğini bilerek, add_arc çevrilebilir (biraz isteğe bağlı olarak) veya belirli bir adres adres adresine çevrilebilir. Ayrıca, belirli hedef varlıkların veya eylemlerin tanımını nasıl tespit edeceğinizi de bilmelisiniz, örneğin bir yay eklemek, bu durumda bir yay oluşturmak anlamına gelir. Adres ve hedef bağımlılık grafiği uygulaması arasındaki ilişki gibi diğer teknik yazışmaları öğrenmek gerekir.
Önceki çalışmamızda (Richardson ve Kuhn (2017), bundan sonra RK olarak anılacaktır), bu tür yazışmaları, çeşitli programlama dillerinde ve kaynak kodu doğal dillerinde bir örnek API koleksiyonundan öğreneceğiz. Verilen her API'yi (metin ve işlev temsil çiftleri dahil) basit bir anlamsal analiz modeli eğitmek için paralel bir bütün olarak kullanırız. Yukarıda belirtilen çeviri yazışmaları türlerini öğrenmenin yanı sıra, diğer teknik konuşmaları öğrenmeye yardımcı olan belge düzeyinde özellikler ekleyerek de geliştirdik.
Bu makalede, modelimizi API koleksiyonlarını sorgulamak için bir araç olarak kullanmaya odaklanacağız. Bir hedef API verildiğinde, modelimiz, metni API'de kod gösterimine çevirmek için MT'ye dayalı bir anlamsal ayrıştırıcı öğrenir. Son kullanıcılar, arka uç API için doğal dil sorgularını formüle edebilir ve modelimiz aday işlev temsillerine dönüştürülecektir. Amaç, gerekli işlevleri bulmaktır. Function Assistant adlı aracımız iki şekilde kullanılabilir: herhangi bir API koleksiyonundan doğrudan modeller oluşturmak için kullanılan bir kara kutu ardışık düzeni olarak. Ayrıca, aracın esnek dahili Python API'sini kullanarak diğer harici bileşenler veya modellerle özelleştirilebilir ve entegre edilebilir.
Bu yazıda, aracımızın ilk kullanımına odaklanıyoruz. Yeni API koleksiyonunun yapım modelini keşfetmek için, tanınmış Awesome Python projeleri listesinden 27 açık kaynaklı Python projesini (github.com/vinta/awesome-python) çalıştırdık. Önceki çalışmamızda olduğu gibi, modellerimizi ölçen, görünmez API açıklamaları için işlevsel temsiller oluşturan ve kullanıcı sorgularını taklit eden bu veri kümeleri üzerinde kapsamlı deneyler yaptık.
API doğal dil sorgusu, yazılım mühendisliğinde her zaman bir hedef olmuştur ve yazılımın yeniden kullanımı genel problemini içerir (Krueger, 1992). Şimdiye kadar, bu alanda bazı endüstriyel ölçekli ürünler var (örneğin, www.krugle.com, www.searchcode.com). Bildiğimiz kadarıyla çoğu uygulama, daha geleneksel NLP bileşenlerini ve tekniklerini kullanan yaklaşımımızdan farklı olan sığ terim eşleştirme ve / veya bilgi çıkarma tekniklerini (Lv ve diğerleri, 2015) kullanır. Bu makalede ve RK'da gösterdiğimiz gibi, terminoloji eşleştirme ve ilgili teknolojiler bazen rekabetçi temeller olarak kullanılabilir, ancak neredeyse her zaman çeviri yöntemlerimizden üstündürler.
Son zamanlarda insanlar, özellikle GitHub veya StackOverflow gibi kaynakları kullanarak, API öğrenme kod gösteriminin makine öğrenimine gittikçe daha fazla önem veriyorlar. Bununla birlikte, bu çalışma genellikle birçok API koleksiyonundan öğrenir (Gu ve diğerleri, 2016), bu tür sistemleri değerlendirmeyi ve belirli API'leri sorgulamak için uygulamayı zorlaştırır. Diğer çalışmalar, doğal dil programlama kaynak kodu yorumlarından (Allamanis ve diğerleri, 2015) daha uzun kod üretmeyi öğrenmeye odaklanır ve genellikle dar bir şekilde belirli bir programlama diline (Java gibi) veya bir dizi API'ye odaklanır. Bildiğimiz kadarıyla, bu yöntemlerin hiçbiri belirli API'ler ve sorgular için özelleştirilmiş ardışık düzenler oluşturmaya yardımcı olan yardımcı yazılımlar içermez.
Teknik olarak konuşursak, yöntemimiz, doğal dil anlama uygulamalarının metin girdisinden biçimsel temsiller, özellikle soru ve cevap üreten semantik analiz çalışmasıyla ilgilidir. Mevcut birçok MT (Wong ve Mooney, 2006) ve ayrıştırma (Zettlemoyer ve Collins, 2009) yöntemlerinden doğrudan ilham alınmıştır. Daha fazla tartışma ve ilgili iş teması için lütfen RK'ya başvurun.
Bu makalede, kaynak kod koleksiyonundan veya API'deki metin açıklamasından bir işlev gösteriminin nasıl oluşturulacağını öğrenmeye odaklanıyoruz. Bu amaç fonksiyonlarını API bileşenleri olarak ifade ediyoruz. Her bileşen bir işlev adı, parametre listesi ve ad alanı gibi diğer isteğe bağlı bilgileri belirtir. Örnek bir metin bileşeni çifti için örnek bir API verildiğinde,
Amaç, her x metni için doğru, iyi yapılandırılmış bir zC bileşeninin nasıl üretileceğini öğrenmektir. Anlamsal analiz problemi olarak görüldüğünde, her z'yi hedef mantıksal forma benzer olarak ele alabiliriz. Bu makalede, Python kaynak kodu projesine ve Python işlevi z'ye odaklanacağız, ancak yöntemimiz, RK tarafından gösterildiği gibi, girdinin doğal dili ve çıktının programlama dilinden bağımsızdır.
Sorgular için kullanıldığında, modelimiz bir metin girdisini kabul edecek ve gerekli işlevsel gösterimi oluşturmaya çalışacaktır. Teknik olarak konuşursak, yaklaşımımız önceki çalışmamızı takip eder ve iki bileşeni vardır: basit ve hafif bir kelime tabanlı çeviri modeli, aday API bileşenleri oluşturma ve ek ifadeler ve belge seviyesi kullanan bir farklılaştırma modeli Fonksiyon sıralama çeviri modeli çıktı sonuçları. Tüm bu modeller araçlarımızda yerel olarak uygulanır ve her bir parçayı sırayla açıklarız.
3.1 Çeviri moduBir giriş metni (veya sorgu) dizisi verildiğinde x = w1,, w | x |, amaç, bir koşullu dağılımı öğrenmeyi içeren bir çıktı API bileşeni z = ui,, u | z | oluşturmaktır p (z | x), izlediğimiz gürültü kanalı yöntemi,
Bu nedenle, çıktı bileşenlerinde tutarlı bir ön p (z) varsayımıyla, model şu şekilde ifade edilebilen p (x | z) hesaplamasını içerir: kelime tabanlı çeviri modeli altında:
Bunların arasında, toplama aralığı, çoktan bire (kelime) hizalama kümesi a'nın x z aralığındadır.
Kelime modellerine dayalı birçok farklı ifade olmasına rağmen, daha önce en basit kelime çeviri modelinin veya IBM Model 1'in (Brown ve diğerleri, 1993) konumsal parametrelerle yüksek dereceli hizalama modellerinden daha üstün olduğunu bulmuştuk. Model, tüm rotaları doğru bir şekilde hesaplamak için aşağıdaki formülü kullanır:
onların arasında,
Tüm kelimeleri tanımlar
Verilen bileşen
Çok terimli dağılım.
Kelime tabanlı modelleri eğitmek için birçok parametre tahmin stratejisi bulunmasına rağmen, en basit EM programının Brown ve diğerleri (1993) en iyi sonucu verdiğini de bulduk. RK'da, bu makalede kullandığımız doğrusal zamanlı kod çözme stratejisinin (yani girdiden bileşenler oluşturmak için kullanılan) C sayısını açıklıyoruz. Araçlarımız ayrıca, büyük API'ler ve daha karmaşık anlamsal diller için daha uygun olan geleneksel MT kod çözme stratejilerimizi uygular.
3.2 Ayrımcı sıralamasıÇoğu anlambilimsel analiz yöntemini takiben (Zettlemoyer ve Collins, 2009), temel çeviri modelinden üretilen bileşenleri yeniden düzenlemek için farklılaştırılmış bir log-doğrusal model kullanıyoruz. Böyle bir model bir koşullu dağılımı tanımlar: bir parametre vektörü için
Ve bir dizi karakteristik fonksiyon
,
.
Aracımız birkaç farklı eğitim ve optimizasyon yöntemi uygular. Bu makalenin amacı doğrultusunda, modelimizi eğitmek için maksimum koşullu log-olabilirlik hedefi altında bir çevrimiçi stokastik gradyan yükselme algoritması kullanıyoruz.
3.2.1 Özellikler
Belirli bir metin girişi x ve çıktı bileşeni z için,
Bu iki öğe arasında bir dizi özellik tanımlayın. Varsayılan olarak, ardışık düzen uygulamamız, RK'da kullanılan aynı işlev kümesi olan üç tür işlev kullanır. İlk kategori, kelime / bileşen eşleştirme, örtüşme, bileşen gramer bilgisi vb. Gibi ek kelime düzeyi işlevleri içerir. İkinci kategori, simetrik kelime düzeyinde hizalama buluşsal yöntemlerinden çıkarılan metin ve öğe adayları arasındaki tümcecikleri ve hiyerarşik ifade özelliklerini içerir.
Başka bir işlev türü, belge düzeyinde işlevleri içerir. Bu, temel API sınıf hiyerarşisi ve bu hiyerarşideki kelimeler / ifadeler ve soyut sınıflar arasındaki ilişki hakkında bilgileri içerir. Ek olarak, bu açıklamalarda çakışan kelime bileşeni aday çiftleri olup olmadığını belirtmek için belgedeki parametrelerin ek metinsel açıklamalarını kullanırız.
Yukarıdaki tüm işlevler, işlev yardımcısı araç setinde uygulanır. Bu araç, önceki çalışmamız Zubr'ın yardımcı yazılım sürümünün bir parçasıdır. Verimliliği artırmak için, temel işlevler Cython ( ile yazılmıştır. Cython, Python dilinin derlenmiş bir üst kümesidir ve yerel C / C ++ entegrasyonuna yardımcı olur.
Araç, iki şekilde kullanılmak üzere tasarlanmıştır: birincisi, özel bir çeviri ardışık düzeni ve API sorgu motoru oluşturmak için bir kara kutu olarak. Araç, Cython ve Python API'mizi kullanarak diğer bileşenlerle de entegre edilebilir. İlk işleve odaklanıyoruz.
4.1 Kitaplık tasarımı ve boru hattıKitaplığımız bağımlılık enjeksiyonu OOP tasarım ilkelerini kullanır. Tüm temel bileşenler, tamamen bağımsız sınıflar olarak uygulanır ve her sınıfın birçok ilgili yapılandırma değeri vardır. Bu bileşenler, kullanıcı tanımlı çeşitli bileşenleri ve bağımlılıkları birbirine yapıştıran ve bu bileşenlerden global bir konfigürasyon oluşturan Pipeline adlı bir sınıf aracılığıyla etkileşime girer. Nesnelerin sonraki somutlaştırılması ve paylaşımı, tüm ardışık düzen boyunca dinamik olarak değiştirilebilen bu global yapılandırma ayarları tarafından belirlenir veya enjekte edilir.
Şekil 2'de gösterildiği gibi, ardışık düzen betikleri yazarak ardışık düzenler oluşturun. Dosya, iki gerekli değişkeni olan normal bir Python dosyasıdır. İlk parametre değişkeni, ardışık düzen ile ilgili çeşitli gelişmiş yapılandırma parametrelerini belirtir. Bu durumda, temel deneyini çalıştırmak için tetiklenebilecek ve sonraki işleme hattını etkileyecek bir ayar temeli vardır.
İkinci ve en önemli değişken, yürütülmesi gereken alt işlemlerin sırasını belirten görevler olarak adlandırılır. Bu listedeki alanlar, temeldeki Zubr araç setindeki (her biri zubr önekine sahip) temel yardımcı programlara yönelik işaretçiler veya kullanıcı tanımlı işlevlerdir. Bu özel ardışık düzen, DocExtractor kullanarak kullanıcı tanımlı bir kaynak kodu havuzundan bir veri kümesi oluşturmak ve ardından simetrik bir dönüşüm modeli SymmetricAlignment, bir özellik çıkarıcı FeatureExtractor ve bir diskriminant sıralayıcı Optimizer oluşturmak için çeşitli ara adımlar aracılığıyla başlar. Bir sorgu arabirimi ve sorgu sunucusu QueryInterface ve QueryServer oluşturarak tamamlanır ve ardından giriş API'sini sorgulamak için kullanabilirsiniz.
Daha önce bahsedildiği gibi, her bir alt sürecin, Pipeline örneği aracılığıyla genel yapılandırma nesnesine eklenen birçok ilgili yapılandırma ayarı vardır. Çeviri modeli için ayarlar, örneğin kullanılacak çeviri modelinin türünü, modeli eğitirken kullanılacak yineleme sayısını vb. İçerir. Bu ayarların tümü terminalde veya ayrı bir konfigürasyon dosyasında belirtilebilir. Benzer şekilde, kullanıcılar, varsayılan işleme hattını değiştirmek veya yeni makine öğrenimi işlevlerini uygulamak için kullanılabilen işlem verileri veya sınıflar gibi özel işlevleri serbestçe tanımlayabilir.
4.2 Web sunucusuBu ardışık düzendeki son adım, girdi API'sini sorgulamak için kullanılabilecek bir HTTP web sunucusu oluşturmaktır. Dahili olarak, sunucu, kullanıcı sorgularını kabul eden ve bunları API işlevi temsillerine çevirmeye çalışan eğitimli çeviri modeline ve ayırt edici yeniden düzenleyiciye iter. Bu aday çeviriler daha sonra potansiyel sorgu yanıtları olarak kullanıcıya döndürülür. Sonuca göre hedef fonksiyon bulunamazsa kullanıcı problemini değiştirebilir veya fonksiyonun kaynak koduna bağlanarak uygulamayı görüntüleyebilir.
Sorgu sunucusunun örnek bir ekran görüntüsü Şekil 3'te gösterilmektedir. Burada, arka plan API'si NLTK araç setidir ve sorgu, eğitim dizisi işaretleyici modelidir. Açıkça belirtilmemesine rağmen, model Gizli Markov Model Etiketleyici HiddenMarkovModelTagger'ın eğitim işlevini döndürür. Şeklin sağ tarafı, eğitim işlevinin Github'daki orijinal kaynağının köprü yolunu gösterir.
Mevcut DocExtractor uygulamamız, orijinal Python kaynak kodu koleksiyonundan paralel veri kümelerinin oluşturulmasını desteklemektedir. Araç, dahili olarak kaynak kodunu okumak ve işlev ve açıklama çiftlerinden oluşan bir koleksiyon çıkarmak için Python standart kitaplığındaki soyut sözdizimi ağacı yardımcı programını kullanır. Araç ayrıca sınıf açıklamalarını, parametre ve dönüş değeri açıklamalarını ve API'nin dahili sınıf hiyerarşisini de çıkarır. Ardından, belge düzeyinde işlevleri tanımlamak için bu son bilgi türünü kullanın.
Bu özelliği denemek için boru hatları kurduk ve 27 popüler Python projesi için deneyler yaptık. Bu deneylerin amacı, ayıklayıcımızın sağlamlığını test etmek ve modelimizin bu kaynaklar için görünmeyen sorguları yanıtlamak için önceki deneysel ayarlarımızı nasıl kullandığını görmektir.
5.1 Veri setiÖrnek projeler Tablo 1'de gösterilmektedir. Her bir veri seti, bileşen çıktı dilindeki # çifte veya paralel fonksiyonel bileşenlerin sayısına, # sembollerine, # (NL) kelimelerine ve kelime boyutlarına göre nicelendirilir.
5.2 Deneysel kurulumHer veri seti rastgele eğitim, test ve geliştirme koleksiyonlarına bölünür. Ayar,% 70 -% 30 (veya% 15 /% 15) bölme kullanır. Eklenti koleksiyonunu, kullanıcıların sorabileceği modeli taklit eden bir sorgu olarak düşünebiliriz. Genel olarak konuşursak, tüm modeller eğitim seti üzerinde eğitilir ve hiperparametreler geliştirme setine göre ayarlanır.
Test sırasında görünmeyen metin girdileri için model, aday bileşen çıktılarının bir listesini oluşturur. Çıktı, altın işlev gösterimiyle tam olarak eşleşirse, çıktının doğru olduğu kabul edilir. Daha önce olduğu gibi, doğruluğu 1 olarak ölçüyoruz, doğruluk ilk onda (doğruluk @ 10) ve MRR'de.
Önceki çalışmamızda olduğu gibi, üç ek temel kullanıldı. İlki, kelime çiftlerini özellik olarak kullanan basit bir kelime çantası (BoW) modelidir. İkincisi, adayları giriş sözcüğü ile bileşen sözcük arasındaki eşleşmelerin sayısına göre sıralayan terim eşleştirme taban çizgisidir. Ayrıca, çeviri sonuçlarını (modelleri) Reranker modelini kullanmadan da karşılaştırıyoruz.
Test sonuçları, temelde önceki bulgularımızla uyumlu olarak Tablo 2'de gösterilmektedir. BoW ve terim eşleme taban çizgisinin performansı diğer tüm modellerden daha iyidir, bu da API sorgusunun basit kelime bileşeni eşleşmesinden daha karmaşık olduğunu göstermektedir. Yalnızca çeviri modelinin kullanılmasıyla karşılaştırıldığında, Reranker modeli, tüm veri setlerinin iyileştirilmesine yol açar, bu da belge seviyesi ve kelime öbeği işlevlerinin veri setinin iyileştirilmesine yardımcı olabileceğini gösterir.
Bu deneylerin sentetik olduğunu, çünkü bu örneklerin gerçek kullanıcı sorgularına benzer olup olmadığı net olmadığı için not ediyoruz. Bununla birlikte, her eklenti setinin gerçek kullanıcılar tarafından talep edilen sorguların temsili bir örneği olduğunu varsayarsak, sonuçları modelimize sorgulara nasıl yanıt vereceğini bildirmek olarak yorumlayabiliriz. Bu örneklerin gerçek şüpheleri yansıtıp yansıtmadığına bakılmaksızın, yine de model oluşturma için iyi bir kriter sağladıklarına inanıyoruz. Tüm kodlar ve veriler, daha ileri deneyler ve uygulama inşası için yayınlanacaktır. Gelecekteki çalışmalar, daha doğal sorgular (örneğin StackOverflow aracılığıyla) ortaya çıkarmaya ve kalıcı Web Demosu aracılığıyla kullanım araştırması yapmaya odaklanacak.
Sınırsız doğal dil kullanarak API koleksiyonlarını sorgulamak için hafif bir araç olan Function Assistant'ı tanıttık. Kullanıcılar, araçlarımız için hedef kaynak kodu projeleri sağlayabilir ve sıfırdan özel çeviriler veya işleme ardışık düzenleri ve sorgu sunucuları oluşturabilir. Bu araca ek olarak, 27 popüler Github projesinden oluşturulmuş veri kümeleri biçiminde API sorgularını öğrenmek için yeni kaynaklar da oluşturduk. Yöntemimiz basit bileşenler kullansa da, araçlarımızın ve kaynaklarımızın bu alandaki gelecekteki çalışmalar için referans noktası olacağını ve nihayetinde günlük yazılım arama ve yeniden kullanılabilirlik sorunlarını çözmeye yardımcı olacağını umuyoruz.
