NEAR BOS Component Categorization

Heterogene JavaScript-Komponenten im NEAR BOS kategorisieren

Entropiereduktion, stufenweise Inferenz und die Grenzen von LLMs in offenen Ökosystemen

---

Zusammenfassung

Dieser Artikel beschreibt einen pragmatischen Versuch, etwa 15.000 JavaScript-Komponenten im NEAR Blockchain Operating System (BOS) zu kategorisieren. Das System war mit extremer Heterogenität in Codestruktur, Metadatenqualität und semantischer Absicht konfrontiert. Naive LLM-basierte Klassifikationsansätze scheiterten früh an Rauschen, unvollständigem Kontext und Framework-spezifischen Abstraktionen.

Stattdessen behandelten wir Kategorisierung als ein Problem fortschreitender Signalkompression, indem wir stufenweise Entropiereduktion, verlustbehaftete strukturelle Normalisierung, schwache LLM-Inferenz und Signalauswahl mit menschlicher Beteiligung anwandten. Das Ergebnis war keine perfekte Taxonomie, sondern eine wesentlich verbesserte Such- und Empfehlungserfahrung für Entwickler.

Obwohl BOS inzwischen eingestellt wurde, bleiben die zugrunde liegenden Erkenntnisse für offene, dezentrale Softwareökosysteme relevant.

---

1. Systemrealität: Warum BOS-Komponenten schwer zu kategorisieren waren

Auf den ersten Blick erschien das Problem einfach: ein großer Bestand an JavaScript-Komponenten, alle für dieselbe Plattform entwickelt, alle öffentlich zugänglich.

In der Praxis zeigte der Bestand extreme Unterschiede entlang mehrerer Achsen:

• Komponentengröße reichte von „Hello World“-Schnipseln (<50 Codezeilen) bis zu tief verschachtelten UI-Systemen mit Zustandsverwaltung, Listen, Spielen und Anwendungslogik.
• Semantische Absicht war selten ausdrücklich benannt. Viele Komponenten dienten als Verbindungsschichten, RPC-Wrapper oder UI-Fragmente, deren Zweck erst zur Laufzeit sichtbar wurde.
• Metadaten waren verrauscht und uneinheitlich:
  • Tags wie devcon, denver, test, oder veranstaltungsspezifische Bezeichnungen waren verbreitet.
  • Funktionale Bezeichnungen wie game, wallet, oder recommender waren selten, mehrdeutig oder fehlten vollständig.
• BOS-spezifische Abstraktionen verschleierten das Verhalten:
  • RPC-Aufrufe an undurchsichtige Endpunkte
  • Indirekter Datenzugriff über URLs ohne semantisches Signal
  • Nicht ausführbare oder unvollständige Codefragmente

Statische Codeanalyse allein reichte nicht aus. Metadaten allein waren irreführend. Und rohen Code an LLMs zu senden lieferte selbstsichere, aber unzuverlässige Ergebnisse.

---

2. Warum naive LLM-Ansätze scheitern

Frühe Experimente folgten dem naheliegenden Weg: Komponenten in Abschnitte teilen, an große Sprachmodelle senden, Bezeichnungen erfragen.

Dies scheiterte aus vorhersehbaren Gründen:

• Kontextfragmentierung: Bedeutungsvolles Verhalten war oft auf mehrere Abschnitte verteilt.
• Halluzinierte Absicht: LLMs erschlossen anhand oberflächlicher Hinweise, was eine Komponente tun sollte, nicht, was sie tatsächlich tat.
• Framework-Diskrepanz: BOS-Abstraktionen lagen weitgehend außerhalb der Trainingsverteilung.
• Tokendruck: Große Komponenten erforderten starke Kürzungen, bei denen genau das für die Klassifikation benötigte Signal verloren ging.

Das Kernproblem war nicht die Leistungsfähigkeit des Modells. Es war die Dichte semantischen Rauschens.

Dadurch stellte sich das Problem neu dar: Kategorisierung war keine Klassifikationsaufgabe, sondern eine Aufgabe der Signalextraktion und Kompression unter Unsicherheit.

---

3. Leitprinzip: Kategorisierung als fortschreitende Kompression

Statt eine durchgängige Klassifikation zu versuchen, verwendeten wir eine stufenweise, verlustbehaftete Verfeinerungspipeline.

Jede Stufe entfernte bewusst Informationen, um die Signalqualität in nachfolgenden Schritten zu erhöhen.

Der Prozess funktionierte wie ein Handhobel: Jeder Durchgang trug Rauschen ab, nicht um Perfektion zu erreichen, sondern um sich einer akzeptablen und nützlichen Kategorisierung anzunähern.

---

4. Stufe 1: Entropiebasierte Bereinigung der Metadaten

Tags wurden als schwache Vorannahmen behandelt, nicht als gesicherte Wahrheit.

Wir analysierten die Verteilungen der Bezeichnungen über den Bestand und entfernten oder verringerten das Gewicht von Bezeichnungen mit:

• extrem hoher globaler Häufigkeit (geringer Unterscheidungskraft) oder
• hoher bedingter Entropie über Komponenten hinweg (semantischer Mehrdeutigkeit)

Dieser Schritt opferte bewusst Vollständigkeit zugunsten der Trennbarkeit.

Das Ziel war nicht Korrektheit, sondern Fehler weniger vielfältig zu machen.

Den Raum möglicher Bezeichnungen früh zu verkleinern erwies sich als wertvoller, als später verrauschte Bezeichnungen korrigieren zu wollen.

---

5. Stufe 2: Strukturelle Kompression vor der Inferenz

Vor dem Einsatz von LLMs wurden Komponenten in verlustbehaftete strukturelle Darstellungen umgewandelt.

Statt den vollständigen Code zu bewahren, extrahierten wir Signale auf Musterebene, etwa:

• Vorhandensein von RPC-Aufrufen
• zustandsbehaftetes gegenüber zustandslosem Verhalten
• UI-Darstellung gegenüber Datentransport
• Listeniteration, spielschleifenähnliche Konstrukte
• Verschachtelungstiefe und Abhängigkeitsstruktur

Dieser Schritt erkannte mehrere Realitäten an:

• Ein großer Teil des Codes war nicht ausführbar.
• BOS-Abstraktionen verschleierten die Ausführungssemantik.
• Mustererkennung war wichtiger als syntaktische Vollständigkeit.

Das Ergebnis war eine komprimierte Darstellung, die Tokenumfang und Varianz erheblich verringerte und zugleich grobe semantische Hinweise bewahrte.

---

6. Stufe 3: Schwache LLM-Inferenz unter strikten Beschränkungen

Erst nach Bereinigung und Kompression wurden Komponenten an LLMs übergeben.

Wesentliche Beschränkungen prägten diese Stufe:

• starke Aufteilung in Abschnitte aufgrund von Tokenlimits
• unvollständiger semantischer Kontext je Abschnitt
• hohes Risiko übermäßiger Verallgemeinerung

Gegenmaßnahmen umfassten:

• Beschränkung der Ausgaben auf kurze, nach Rang geordnete Vorschläge für Bezeichnungen
• Abwertung generischer Bezeichnungen
• Behandlung sämtlicher LLM-Ausgaben als probabilistische Hinweise, niemals als gesicherte Wahrheit

Diese Stufe zeigte klar die Grenzen von LLMs in diesem Umfeld: Sie verstärkten vorhandene Signale, eigneten sich aber schlecht als primäre Filter.

---

7. Stufe 4: Menschliche Beteiligung als Signalauswahl

Menschliche Eingaben dienten nicht dazu, LLM-Fehler zu „reparieren“.

Stattdessen wurden Menschen gebeten, die semantische Nützlichkeit zu bewerten:

• Welche Bezeichnungen unterschieden Komponenten sinnvoll?
• Welche Bezeichnungen warfen unterschiedliche Verhaltensweisen zusammen?
• Welche Bezeichnungen verbesserten die nachfolgende Suche und Empfehlung?

Damit wurde menschliche Annotation als Optimierung des Informationsgewinns verstanden, nicht als Durchsetzung von Korrektheit.

Menschen definierten, was Signal in der Praxis bedeutete.

---

8. Stufe 5: Iterative Projektion und Akzeptanz von Unvollkommenheit

Nach jedem Verfeinerungszyklus:

• wurden Komponenten in Vektoren eingebettet
• mittels PCA und t-SNE projiziert
• wurde die Trennbarkeit der Cluster visuell geprüft
• wurde die Entropie der Bezeichnungen neu bewertet

Diese Projektionen dienten der Fehlersuche und der Entwicklung von Intuition, nicht als objektive Messgrößen.

Wir akzeptierten ausdrücklich:

• unscharfe Kategoriegrenzen
• teilweise Fehlklassifikation
• nicht erschöpfende Kennzeichnung

solange sich Auffindbarkeit und Empfehlungsqualität verbesserten.

Ontologische Reinheit war nie das Ziel.

---

9. Ergebnisse

Das entstandene System verbesserte:

• die Präzision der semantischen Suche
• die Stabilität von Komponentenempfehlungen
• die allgemeine Auffindbarkeit für Entwickler auf near.org/applications

Es erzeugte keine perfekte Taxonomie. Es beseitigte Mehrdeutigkeit nicht. Es automatisierte die Kategorisierung nicht vollständig.

Was es bereitstellte, war eine pragmatisch nützliche Struktur in einem grundlegend verrauschten, offenen Ökosystem.

---

10. Rückblick: Was wir heute anders machen würden

Im Rückblick treten mehrere Schlussfolgerungen hervor:

• Große LLMs waren für das Kernproblem überdimensioniert.
• Der Hauptengpass war semantisches Rauschen, nicht die Tiefe des Schlussfolgerns.
• Kleinere, feinabgestimmte Open-Source-Modelle würden unsere ursprüngliche Konfiguration heute wahrscheinlich übertreffen.
• Das System selbst war weniger wichtig als die Erkenntnisse, die es offenlegte.

Am wichtigsten:

In offenen, dezentralen Ökosystemen ist Kategorisierung kein Klassifikationsproblem. Sie ist ein Kompressionsproblem unter Unsicherheit.

Obwohl BOS inzwischen eingestellt wurde, lassen sich diese Erkenntnisse auf viele reale Systeme übertragen, in denen sich Struktur, Absicht und Metadaten über die Zeit fortwährend verschieben.

---

Dieser Artikel ist ein Praxisbericht, keine Produktankündigung. Das beschriebene System war unvollkommen, vorübergehend und durch seinen Kontext eingeschränkt – doch die Erkenntnisse bleiben beständig.