🤖 AI

Industry Classification of GitHub Repositories Using the North American Industry Classification System (NAICS)

Dieses Paper stellt NAICS-GH vor, einen hochpräzisen, öffentlich zugänglichen Korpus aus 6.588 GitHub-Repositories, die unter Verwendung einer Retrieve-and-Verify-Pipeline, welche BAAI/bge-large-en-Embeddings und GPT-4.1 kombiniert, mit NAICS-2022-Branchensektoren etikettiert wurden, was eine durch Menschen validierte Präzision von 96,98 % erreicht und als Benchmark für die Branchenklassifizierung in der Open-Source-Innovationsforschung dient.

Ursprüngliche Autoren: Kevin Xu, Alexander Quispe

Veröffentlicht 2026-07-08

📖 4 Min. Lesezeit☕ Kaffeepausen-Lektüre

CC BY 4.0

Ursprüngliche Autoren: Kevin Xu, Alexander Quispe

Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen

Stellen Sie sich GitHub als eine riesige, chaotische Bibliothek vor, die hunderte Millionen von Büchern (Code-Repositories) enthält. Das Problem ist, dass die Bibliothek zwar den Titel jedes Buches kennt, aber kein „Dewey-Dezimalsystem“ besitzt, um Ihnen zu sagen, für welche Art von Geschäft oder Industrie dieses Buch eigentlich gedacht ist. Ist dieser Code für eine Bank? Einen Bauernhof? Ein Videospielstudio? Ohne dieses Etikett ist es für Ökonomen, politische Entscheidungsträger oder Unternehmen schwierig zu verstehen, wie verschiedene Branchen Open-Source-Software nutzen.

Dieses Paper stellt NAICS-GH vor, ein neues System, das wie ein superschlauer Bibliothekar fungiert, um diese Bücher in das North American Industry Classification System (NAICS) zu sortieren – das Standard-Klassifizierungssystem, das von Regierungen in den USA, Kanada und Mexiko verwendet wird.

So haben sie es aufgebaut, einfach erklärt:

1. Das „Fischernetz“ (Retrieval)

Zuerst konnte das Team nicht jedes einzelne Buch in der Bibliothek lesen (es gibt über 1,3 Millionen Kandidaten). Also verwendeten sie ein digitales Fischernetz namens BGE Embeddings und FAISS.

Die Metapher: Stellen Sie sich vor, Sie haben eine Liste von 1.000 spezifischen Schlüsselwörtern (wie „Ernteertrag“, „Bankensicherheit“ oder „Krankenhausplanung“). Sie werfen diese Schlüsselwörter in die Bibliothek, und das Netz fängt sofort die 20 Bücher ab, die diesen Schlüsselwörtern am ähnlichsten klingen.
Das Ergebnis: Dieses Netz fing etwa 31.000 potenzielle Treffer ab. Es wurde weit ausgeworfen, um sicherzustellen, dass nichts übersehen wird, aber es hat auch einige „Beifänge“ mitgebracht (Bücher, die ähnlich klangen, aber nicht ganz passten).

2. Der „Expertenrichter“ (Verification)

Das Netz war zu grobmaschig, also brauchten sie einen strengen Richter, um die Fänge zu verifizieren. Sie engagierten GPT-4.1 (eine sehr fortschrittliche KI), um als Domänenexperte zu fungieren.

Die Metapher: Denken Sie an GPT-4.1 als einen erfahrenen Inspektor. Für jedes Buch, das das Netz gefangen hat, liest der Inspektor den Einband, die Zusammenfassung und die ersten Seiten (die Repository-Beschreibung und die README).
Das Regelwerk: Der Inspektor rät nicht einfach; er verwendet eine strikte Checkliste (ein „Rubric“). Er fragt: „Löst dieser Code tatsächlich ein Problem für diese spezifische Branche?“
- Wenn die Antwort ein klares „Ja“ ist, gibt der Inspektor eine Punktzahl von 9 oder 10.
- Wenn es ein „Vielleicht“ ist, ist die Punktzahl niedriger.
- Wenn es ein generisches Werkzeug ist, das von jedem genutzt wird (wie ein einfacher Taschenrechner), erhält es eine niedrige Punktzahl.
Die Grenze: Sie behielten nur die Bücher, die eine Punktzahl von 8 oder höher erhielten. Dies stellte sicher, dass sie nur Treffer mit hoher Konfidenz behielten.

3. Die finale Sammlung (The Dataset)

Nachdem der KI-Richter die schwachen Treffer herausgefiltert hatte, blieben 6.588 hochwertige Repositories übrig.

Diese verteilen sich auf 19 verschiedene Branchen (wie Landwirtschaft, Fertigung, Gesundheitswesen und Finanzen).
Sie ließen absichtlich eine Kategorie aus („Management von Unternehmen“), da es nicht genügend klare Beispiele gab, um eine zuverlässige Gruppe zu bilden.
Entscheidend: Sie entfernten die Namen der Besitzer, um die Privatsphäre zu schützen, und behielten nur den Code-Inhalt und das Branchenetikett.

4. Hat es funktioniert? (Validation)

Um sicherzustellen, dass der KI-Richter nicht halluziniert, engagierte das Team menschliche Forschungsassistenten, die zufällig 2.421 dieser etikettierten Bücher überprüften.

Das Ergebnis: Die menschlichen Richter stimmten in 96,98 % der Fälle mit der KI überein.
Die Nuance: Die KI war fast perfekt bei eindeutigen Branchen wie „Öffentliche Verwaltung“ oder „Kunst & Unterhaltung“. Sie hatte jedoch etwas mehr Schwierigkeiten mit „Fertigung“ und „Großhandel“, wo Software manchmal generisch wirken kann. Das Paper stellt fest, dass die Genauigkeit in diesen kniffligen Branchen noch weiter steigt, wenn man die Anforderung für die Punktzahl auf 9 oder 10 erhöht.

5. Das „Lehrwerkzeug“ (Benchmark)

Schließlich nutzte das Team diese neue, etikettierte Bibliothek, um sechs verschiedene KI-Modelle darin zu unterrichten, Code eigenständig zu klassifizieren.

Sie testeten Modelle wie RoBERTa, ModernBERT und DeBERTa.
Der Gewinner: Ein Modell namens RoBERTa-large lernte am besten und erreichte eine Genauigkeit von 86,45 % auf einem Testdatensatz, den es zuvor noch nie gesehen hatte.
Die Erkenntnis: Dies beweist, dass man, sobald man eine gute „etikettierte Bibliothek“ besitzt, kleinere, schnellere KI-Modelle trainieren kann, um die Klassifizierungsarbeit in Zukunft automatisch zu übernehmen.

Zusammenfassung

Das Paper präsentiert einen öffentlich verfügbaren Datensatz, der GitHub-Code Branchen zuordnet. Er wurde erstellt durch:

Ein weites Netz auszuwerfen, um potenzielle Treffer zu finden.
Einen strengen KI-Richter einzusetzen, um diese gegen eine detaillierte Checkliste zu verifizieren.
Menschen zur Doppelprüfung einzusetzen, um eine Genauigkeit von 97 % zu gewährleisten.
Die Daten und den Code freizugeben, damit jeder untersuchen kann, wie verschiedene Branchen Open-Source-Software nutzen.

Die Autoren geben explizit an, dass dies ein nordamerikanisches Klassifizierungssystem ist, das global angewendet wird, und warnen, dass die Etiketten zwar hochgradig genau, aber nicht für jede einzelne Branche (insbesondere Fertigung und Großhandel) perfekt sind. Sie merken zudem an, dass das System derzeit am besten mit englischsprachigen Code-Beschreibungen funktioniert.

Technische Zusammenfassung: Branchenklassifizierung von GitHub-Repositories mittels NAICS

Problemstellung
GitHub hostet hunderte Millionen öffentlicher Repositories, verfügt jedoch über keinen nativen Mechanismus, um diese Repositories standardisierten Industriesektoren zuzuordnen. Das Fehlen dieser strukturierten Industriedaten schränkt die empirische Forschung zur Geografie der Innovation, zur industriellen Zusammensetzung der Open-Source-Produktion und zur Diffusion von Technologien über Wirtschaftssektoren hinweg ein. Bestehende Klassifizierungsbemühungen stützten sich auf benutzerdefinierte Topic-Tags oder Software-Anwendungsbereiche, doch keiner hat eine standardisierte Wirtschaftstaxonomie wie das North American Industry Classification System (NAICS) über mehrere Gerichtsbarkeiten hinweg implementiert.

Methodik: Die NAICS-GH-Pipeline
Die Autoren präsentieren NAICS-GH, einen Korpus von 6.588 GitHub-Repositories, die mit 2-stelligen NAICS-Codes (NAICS 2022) etikettiert wurden. Der Datensatz wurde unter Verwendung einer reproduzierbaren, zweistufigen „Retrieve-and-Verify“-Pipeline erstellt, die auf Quellpools aus den USA, der EU und Australien angewendet wurde.

Extraktion des Quellpools:
- Daten: 1.372.489 öffentliche Nicht-Fork-Repositories wurden aus dem internen Data Warehouse von GitHub extrahiert.
- Einschlusskriterien: Repositories müssen öffentlich sein, mindestens einen Star besitzen, eine README von $\ge$ 750 Bytes enthalten, $>6$ Commits aufweisen und $\ge 2$ unterschiedliche Mitwirkende involvieren.
- Jurisdiktionen: Der Pool wird nach dem Land des Inhaber-Accounts aufgeteilt: USA (510.380), EU-27 (530.898) und Australien (331.211).
Stufe 1: Semantische Abfrage (Kandidatengenerierung):
- Embedding: Repository-READMEs (die ersten 1.000 Zeichen) werden mittels BAAI/bge-large-en Embeddings kodiert.
- Abfragekonstruktion: Die Pipeline verwendet eine Taxonomie von 1.029 distinkten 6-stelligen NAICS-Subindustrie-Phrasen. Für jede Phrase wird die Abfrage „Repositories about {subindustry}“ generiert.
- Retrieval: Unter Verwendung von FAISS (IndexFlatIP) für die exakte Inner-Product-Suche extrahiert das System die top- $k$ semantisch ähnlichsten Repositories. Der $k$ -Wert ist adaptiv: $k=20$ für Sektoren mit vielen Subindustrien, und erhöht ( $k \approx 24\text{--}29$ ) für Sektoren mit wenigen Subindustrien, um etwa 400 Kandidaten pro Sektor sicherzustellen.
- Ausgabe: Dieser Schritt liefert 31.178 eindeutige (Repository, Sektor)-Kandidatenpaare.
Stufe 2: LLM-Verifizierung (Filterung):
- Modell: GPT-4.1 (Snapshot gpt-4.1-2025-04-14) wird als Verifizierer eingesetzt.
- Input: Das Modell erhält einen strukturierten Prompt, der die Beschreibung des Repositories, die Topic-Tags und die bereinigte README (konkateniert) sowie die Ziel-NAICS-Sektordefinition enthält.
- Rubrik: Das Modell bewertet den Match auf einer Skala von 1 bis 10 basierend auf vier Kriterien: branchenspezifische Software, sektorspezifische Funktionalität, branchenspezifische Anwendungsbereiche sowie sektorspezifische Daten/Forschung.
- Schwellenwertbildung: Kandidaten mit einem Score $\ge 8$ werden beibehalten. Ein Filter für die Mindestgröße der Klasse ( $n \ge 80$ ) entfernt den Sektor 55 („Management of Companies and Enterprises“), der nur 13 erfolgreiche Kandidaten aufwies.

Wesentliche Beiträge

Datensatz (NAICS-GH): Ein öffentlich zugänglicher Korpus von 6.588 Repositories, die mit 2-stelligen NAICS-Codes etikettiert sind und 19 der 20 NAICS-Sektoren abdecken. Der Datensatz enthält Repository-Metadaten, bereinigten Text sowie den Konfidenzscore und die Begründung des LLMs.
Reproduzierbare Pipeline: Eine vollständige Open-Source-Pipeline (MIT-Lizenz), die dichte Abfrage (BGE + FAISS) mit LLM-Verifizierung (GPT-4.1) kombiniert. Die Pipeline ist so konzipiert, dass sie an andere Industrietaxonomien angepasst werden kann.
Validierung: Eine manuell verifizierte „Gold“-Teilmenge von 2.421 Repositories bestätigt die Präzision der Pipeline.
Benchmarks: Ein direkter Vergleich von sechs vortrainierten Encodern (RoBERTa, ModernBERT, DeBERTa-v3), die auf dem Korpus feinjustiert wurden.

Ergebnisse und Validierung

Präzision: Auf der menschlich validierten Gold-Stichprobe erreicht die Pipeline eine Präzision von 96,98 % (95 % Wilson CI: [96,23 %, 9%7,59 %]).
Score-Korrelation: Die Präzision korreliert monoton mit dem GPT-4.1-Score: 90,76 % bei Score 8, 97,81 % bei Score 9 und 99,30 % bei Score 10.
Sektor-Varianz: Sechs Sektoren (darunter öffentliche Verwaltung, Information und Bergbau) erreichten eine Präzision von 100 % in der Gold-Stichprobe. Jedoch zeigten Fertigung (31–33) und Großhandel (42) eine geringere Präzision (73,0 %) am Schwellenwert von $\ge 8$ , was darauf hindeutet, dass diese Sektoren schwerer von generischen Supply-Chain-Tools zu unterscheiden sind.
Reproduzierbarkeit: Ein erneutes Durchlaufen der Pipeline auf unterschiedlicher Hardware reproduziert den Kandidatensatz innerhalb einer Abweichung von 0,03 % der ursprünglichen Größe.
Benchmark-Leistung: Unter sechs feinjustierten Encodern erzielte RoBERTa-large die höchste Testleistung mit 86,45 % F1 und 86,35 % Genauigkeit. Bemerkenswerterweise verbesserten höhere Parameterzahlen die Leistung nicht einheitlich (z. B. unterperformte ModernBERT-large gegenüber ModernBERT-base), was darauf hindeutet, dass für diese Korpusgröße ( $\approx 4,6\text{k}$ Trainingsbeispiele) die Pretraining-Ziele wichtiger sind als die Skalierung.

Bedeutung und Ansprüche
Das Paper beansprucht, den ersten öffentlich verfügbaren, multijurisdiktionalen Korpus bereitzustellen, der GitHub-Repositories dem NAICS-Standard zuordnet. Diese Ressource schließt eine kritische Lücke für Ökonomen, politische Entscheidungsträger und Forscher, die den Sektor der Arbeits- und Kapitalallokation in der Softwareindustrie untersuchen. Die Autoren positionieren den Datensatz nicht als perfekte Grundwahrheit (sie räumen Rauschen in spezifischen Sektoren sowie die Englisch-Beschränkung des Retrieval-Modells ein), sondern als eine hochkonfidente Ressource, die empirische Arbeiten über die industrielle Zusammensetzung von Open Source ermöglicht. Die Veröffentlichung umfasst den Datensatz, feinjustierte Checkpoints und den vollständigen Pipeline-Code, um nachgelagerte Forschung und Replikation zu erleichtern.