C # oder Java? TypeScript oder JavaScript? Die Klassifizierung von Programmiersprachen basierend auf maschinellem Lernen

GitHub verfügt über mehr als 300 Programmiersprachen, von bekannten Sprachen wie Python, Java und Javascript bis zu esoterischen Sprachen wie Befunge , die nur kleinen Gruppen von Menschen bekannt sind.

Top 10 GitHub gehostete Programmiersprachen nach Anzahl der Repositorys

Eines der Probleme, mit denen GitHub konfrontiert ist, ist die Erkennung verschiedener Programmiersprachen. Wenn Code in das Repository gestellt wird, ist die Erkennung seines Typs sehr wichtig. Dies ist aus Gründen der Suche, der Sicherheitsanfälligkeitswarnungen, der Hervorhebung der Syntax sowie der strukturellen Darstellung des Repository-Inhalts für Benutzer erforderlich.

Auf den ersten Blick ist die Spracherkennung eine einfache Aufgabe, aber nicht so. Linguist ist das Tool, mit dem wir derzeit eine Programmiersprache auf GitHub definieren. Linguist ist eine Ruby-Anwendung, die eine Vielzahl von Spracherkennungsstrategien verwendet, einschließlich Namensinformationen und Dateierweiterungen. Darüber hinaus werden Vim- oder Emacs-Modelle sowie der Inhalt oben in der Datei (shebang) berücksichtigt. Der Linguist verarbeitet die sprachliche Mehrdeutigkeit heuristisch und verwendet, falls dies nicht funktioniert, einen naiven Bayes'schen Klassifikator, der auf einer kleinen Datenstichprobe trainiert wird.

Obwohl Linguist auf Dateiebene recht gute Vorhersagen macht (84% Genauigkeit), bricht alles zusammen, wenn Dateien seltsam benannt werden, und noch mehr, wenn Dateien keine Erweiterungen haben. Dies macht Linguist für Inhalte wie GitHub Gists oder Codefragmente in README, Fehler und Pull-Anfragen unbrauchbar.

Um die Sprachdefinition langfristig klarer zu gestalten, haben wir einen Klassifikator für maschinelles Lernen namens OctoLingua entwickelt. Es basiert auf der ANN-Architektur (Artificial Neural Network), die Sprachvorhersagen in nicht trivialen Szenarien verarbeiten kann. Die aktuelle Version des Modells kann Vorhersagen für die 50 besten Programmiersprachen auf GitHub treffen und übertrifft die Genauigkeit von Linguist.

Weitere Details zu OctoLingua

OctoLingua wurde in Python, Keras mit dem TensorFlow-Backend von Grund auf neu geschrieben - es wurde erstellt, um genau, zuverlässig und einfach zu warten zu sein. In diesem Teil werden wir über unsere Datenquellen, Modellarchitektur und OctoLingua-Leistungstests sprechen. Wir werden auch über den Prozess des Hinzufügens der Fähigkeit sprechen, eine neue Sprache zu erkennen.

Datenquellen

Die aktuelle Version von OctoLingua wurde auf Dateien trainiert, die aus Rosetta Code und einer Reihe interner Crowdsource-Repositories stammen. Wir haben unsere Sprachen auf die 50 beliebtesten auf GitHub beschränkt.

Rosetta Code war ein ausgezeichneter Startdatensatz, da er Quellcode enthielt, der für dieselbe Aufgabe geschrieben wurde, jedoch in verschiedenen Programmiersprachen. Beispielsweise wurde der Code zum Generieren von Fibonacci-Zahlen in C, C ++, CoffeeScript, D, Java, Julia und anderen dargestellt. Die Abdeckung der Sprachen war jedoch heterogen: Für einige Programmiersprachen gab es nur wenige Dateien mit Code, für andere enthielten die Dateien einfach zu wenig Code. Daher war es notwendig, unseren Trainingsdatensatz um einige zusätzliche Quellen zu ergänzen und dadurch die Abdeckung der Sprachen und die Wirksamkeit des endgültigen Modells erheblich zu verbessern.

Unser Prozess des Hinzufügens einer neuen Sprache ist nicht vollständig automatisiert. Wir kompilieren programmgesteuert Quellcode aus öffentlichen Repositories auf GitHub. Wir wählen nur diejenigen Repositorys aus, die die Mindestqualifizierungskriterien erfüllen, z. B. die Mindestanzahl von Gabeln, die die Zielsprache und bestimmte Dateierweiterungen abdecken. In dieser Phase der Datenerfassung definieren wir die Hauptsprache des Repositorys anhand der Klassifizierung von Linguist.

Symptome: Basierend auf Vorkenntnissen

Traditionell werden speicherbasierte Architekturen wie Recurrent Neural Networks (RNN) und Long Short Term Memory Networks (LSTM) verwendet, um Textklassifizierungsprobleme mithilfe neuronaler Netze zu lösen. Unterschiede in den Programmiersprachen im Wortschatz, in den Dateierweiterungen, in der Struktur, im Stil des Imports von Bibliotheken und in anderen Details haben uns jedoch dazu gezwungen, einen anderen Ansatz zu entwickeln, bei dem all diese Informationen verwendet werden und einige Zeichen in tabellarischer Form für das Training unseres Klassifikators extrahiert werden. Attribute werden wie folgt abgerufen:

1. Top 5 Sonderzeichen in einer Datei
2. Top 20 Zeichen in einer Datei
3. Dateierweiterung
4. Das Vorhandensein bestimmter Sonderzeichen, die im Quellcode von Dateien verwendet werden, z. B. Doppelpunkt, geschweifte Klammern, Semikolons

Model Artificial Neural Network (ANN)

Wir verwenden die oben genannten Faktoren als Eingabe für ein zweischichtiges neuronales Netzwerk, das mit Keras und einem Tensorflow-Backend erstellt wurde.

Das folgende Diagramm zeigt, dass der Merkmalsextraktionsschritt einen n-dimensionalen Tabelleneintrag für unseren Klassifizierer erstellt. Während sich die Informationen durch die Schichten unseres Netzwerks bewegen, werden sie durch Abbruch sortiert. Das Ergebnis ist eine 51-dimensionale Ausgabe, die die Wahrscheinlichkeit darstellt, dass dieser Code in jeder der 50 besten Sprachen auf GitHub geschrieben ist. Es zeigt auch die Wahrscheinlichkeit, dass der Code nicht in einer der 50 Sprachen geschrieben ist.


ANN-Struktur des Quellmodells (50 Sprachen + 1 für „andere“)

Wir haben 90% unserer Quellendatenbank für Schulungen verwendet. Außerdem wurde im Trainingsschritt des Modells ein Teil der Dateierweiterungen entfernt, damit das Modell genau aus dem Vokabular der Dateien lernen konnte und nicht aus ihren Erweiterungen, die die Programmiersprache so gut vorhersagen.

Leistungstest

OctoLingua gegen Linguist

In der folgenden Tabelle zeigen wir den F1-Score (harmonisches Mittel zwischen Genauigkeit und Vollständigkeit) für OctoLingua und Linguist, berechnet mit demselben Testsatz (10% des Volumens unserer ursprünglichen Datenquelle).

Hier werden drei Tests gezeigt. Im ersten Test wurde der Datensatz überhaupt nicht berührt; im zweiten wurden Dateierweiterungen gelöscht; Im dritten Fall wurden die Dateierweiterungen gemischt, um den Klassifizierer zu verwirren (z. B. könnte eine Java-Datei die Erweiterung ".txt" und eine Python-Datei die Erweiterung ".java" haben.

Die Intuition hinter dem Mischen oder Löschen von Dateierweiterungen in unserer Testsuite besteht darin, die Zuverlässigkeit von OctoLingua bei der Klassifizierung von Dateien zu bewerten, wenn ein Schlüssel-Tag gelöscht oder irreführend ist. Ein Klassifizierer, der nicht sehr von der Erweiterung abhängig ist, ist äußerst nützlich für die Klassifizierung von Protokollen und Codefragmenten, da in diesen Fällen normalerweise keine genauen Informationen über die Erweiterung bereitgestellt werden (z. B. haben viele codebezogene Protokolle die Erweiterung txt).

Die folgende Tabelle zeigt, wie OctoLingua unter verschiedenen Bedingungen eine gute Leistung erbringt, wenn wir davon ausgehen, dass das Modell hauptsächlich aus dem Vokabular des Codes und nicht aus Metainformationen (z. B. der Dateierweiterung) lernt. Gleichzeitig ermittelt Linguist die Sprache fälschlicherweise, sobald Informationen zur richtigen Dateierweiterung fehlen.

Leistung von OctoLingua vs. Linguist in derselben Testsuite

Der Effekt des Entfernens von Dateierweiterungen beim Trainieren eines Modells

Wie bereits erwähnt, haben wir während des Trainings einen bestimmten Prozentsatz der Dateierweiterungen aus den Daten entfernt, damit das Modell aus dem Vokabular der Dateien lernen kann. Die folgende Tabelle zeigt die Leistung unseres Modells mit verschiedenen Anteilen von Dateierweiterungen, die während des Trainings gelöscht wurden.


OctoLingua-Leistung mit unterschiedlichem Prozentsatz gelöschter Dateierweiterungen

Bitte beachten Sie, dass ein Modell, das für Dateien mit Erweiterungen trainiert wurde, für Testdateien ohne Erweiterungen oder mit gemischten Erweiterungen erheblich weniger effektiv ist als für reguläre Testdaten. Wenn andererseits ein Modell auf einen Datensatz trainiert wird, in dem ein Teil der Dateierweiterungen entfernt wird, nimmt die Leistung des Modells auf dem modifizierten Testsatz nicht wesentlich ab. Dies bestätigt, dass das Entfernen von Erweiterungen aus einem Teil der Dateien während des Trainings unseren Klassifizierer dazu veranlasst, mehr aus dem Codevokabular zu lernen. Es zeigt auch, dass die Dateierweiterung dazu neigte, die Gewichtung des vorgestellten Inhalts zu dominieren und zu verhindern.

Neue Sprachunterstützung

Das Hinzufügen einer neuen Sprache zu OctoLingua ist ein ziemlich einfacher Vorgang. Es beginnt mit der Suche und dem Abrufen einer großen Anzahl von Dateien in einer neuen Sprache (wir können dies programmgesteuert tun, wie im Abschnitt „Datenquellen“ beschrieben). Diese Dateien sind in Schulungs- und Testsuiten unterteilt und durchlaufen dann unseren Präprozessor und Feature-Extraktor. Ein neuer Datensatz wird dem vorhandenen Pool hinzugefügt. Mit dem Testkit können wir sicherstellen, dass die Genauigkeit unseres Modells akzeptabel bleibt.


Hinzufügen einer neuen Sprache zu OctoLingua

Unsere Pläne

OctoLingua befindet sich derzeit in einem „fortgeschrittenen Prototyping-Stadium“. Unser Sprachklassifizierungsmechanismus ist bereits zuverlässig, unterstützt jedoch noch nicht alle auf GitHub verfügbaren Programmiersprachen. Zusätzlich zur Erweiterung der Sprachunterstützung, die nicht so schwierig ist, bemühen wir uns, die Spracherkennung mit verschiedenen Ebenen von Codedetails bereitzustellen. Unsere aktuelle Implementierung ermöglicht es uns bereits, mit einer geringfügigen Änderung unseres Mechanismus für maschinelles Lernen Codefragmente zu klassifizieren. Es scheint auch nicht schwierig zu sein, das Modell in ein Stadium zu bringen, in dem es eingebettete Sprachen zuverlässig erkennen und klassifizieren kann.

Wir erwägen auch, den Quellcode für unser Modell zu veröffentlichen, benötigen jedoch eine Anfrage der Community.

Fazit

Unser Ziel bei der Entwicklung von OctoLingua ist es, einen Dienst zu schaffen, der eine zuverlässige Definition der Sprache durch den Quellcode auf verschiedenen Detailebenen ermöglicht: von der Ebene der Dateien oder Codefragmente bis zur möglichen Definition und Klassifizierung der Sprache auf Zeilenebene. Alle unsere Arbeiten an diesem Service zielen darauf ab, Entwickler bei ihrer täglichen Entwicklungsarbeit zu unterstützen und Bedingungen für das Schreiben von qualitativ hochwertigem Code zu schaffen.

Wenn Sie daran interessiert sind, zu unserer Arbeit beizutragen, können Sie uns gerne auf Twitter @github kontaktieren !