👨‍💻 Benchmarking kleiner Sprachmodelle in der realen Welt

der 21. April 2026

Am Samstag, dem 18. April, nahm ich an einem Hackathon teil, der Machine-Learning-Ingenieure, Dateningenieure und Forscher nach Paris einlud, um die Evaluierung kleiner Sprachmodelle (SLM) eingehend zu untersuchen.

Dieser Hackathon, organisiert von AI Tinkerers Paris, befasst sich mit einem sehr konkreten Problem:

Testen der tatsächlichen Fähigkeit von Sprachmodellen, produktionsreifen ausführbaren Code zu erzeugen.

Das Thema – „Benchmarking kleiner Sprachmodelle in der realen Welt“ – gibt einen klaren Rahmen vor: Es geht über beeindruckende Demos hinaus und konfrontiert Modelle mit realen Einschränkungen (Ausführung, Leistung, Ressourcen).

🎯 Zielsetzung

Die Herausforderung besteht darin, Polars-Abfragen automatisch aus natürlicher Sprache zu generieren, wobei eine starke Anforderung gilt:

  • korrekten Code erzeugen
  • sicherstellen, dass es ausführbar ist
  • Optimierung der Ausführungszeit und des Speicherverbrauchs

Die Wertung spiegelt diese Realität wider:

Score = N / (T × VRAM^0,1 × RAM^0,01)

👉 Anders ausgedrückt: Genauigkeit allein genügt nicht – die Systemeffizienz wird zu einer zentralen Einschränkung.

⚙️ Technischer Kontext

Jedes Team arbeitet in einer standardisierten Umgebung:

  • Ausführung unter Docker
  • Verwendung von Polaren zur Datenverarbeitung
  • GPU-/Speicherbeschränkungen
  • Evaluierungsdatensatz bereitgestellt

Ziel ist es nicht, „die beste Eingabeaufforderung“ zu entwickeln, sondern ein System zu schaffen, das Folgendes ermöglicht:

  • halten realen Daten stand
  • robusten Code erzeugen
  • einen automatisierten Benchmark ausführen

🧩 Positionierung

Dieser Hackathon zeichnet sich durch seinen Ansatz aus:

  • keine Marketingdemo
  • keine „beeindruckende, aber zerbrechliche“ Generation
  • Fokus auf das, was wirklich funktioniert

👉 Dies ist ein Umfeld, das die aktuellen Grenzen des LLM direkt aufzeigt:

  • Halluzinationen
  • Syntaxfehler
  • Missverständnis des Datenschemas

Und es zwingt einen dazu, darum herum zu bauen.

  • prompte strukturierte Entwicklung
  • systematische Validierung
  • schnelle Iterationsschleife

📊 Lesen

Dies ist kein "kreativer" Hackathon, sondern ein Ingenieur-Benchmark.

Das Endergebnis ist keine Idee, sondern:

ein messbares, reproduzierbares und vergleichbares System.

🏗️ Tagesorganisation

Morgen - Rahmung und Initialisierung

Der Vormittag ist der Einrichtung des technischen und organisatorischen Rahmens gewidmet:

  • Teambildung über das Veranstaltungsportal
  • Vorstellung des Problems durch die Organisatoren und Mentoren
  • Klärung der Erwartungen (Generierung von ausführbarem Polars-Code + Bewertung)
  • Ersteinrichtung der Arbeitsumgebung

Das Darkwood-Team setzt sich wie folgt zusammen:

Ziel dieser Phase ist es, Unsicherheiten zu reduzieren und alle Beteiligten von den ersten Stunden an auf einen umsetzbaren Prozess auszurichten.

Mittagspause

  • Mittagessen wird vor Ort bereitgestellt
  • informeller Austausch zwischen den Teams
  • Konsultation des Nachrichtencenters (allgemeine Fragen, Klärungen der Jury)

👉 Kurze Phase ohne wirkliche Entkopplung: Das Projekt bleibt in der Iteration.

Nachmittag – Implementierung und Iterationen

Der Nachmittag ist vollständig produktionsorientiert:

  • Implementierung des Benchmarks (polars-bench)
  • Integration des Modells über ai-harness
  • Experimente mit Aufgabenstellungen (Struktur, Format, Einschränkungen)
  • Anpassung des Modellverhaltens durch Datensatz- und Prompt-Engineering
  • progressive Validierung durch tatsächliche Ausführung

Die Iterationen konzentrieren sich auf drei Bereiche:

  • Reduzierung von Halluzinationen (schemabasierte Eingabeaufforderung)
  • Verbesserte Ausführbarkeitsrate
  • Punktzahloptimierung (Zeit / Speicher / Genauigkeit)

👉 Die Logik besteht nicht darin, Funktionen hinzuzufügen, sondern das System an realen Einschränkungen auszurichten.

⚙️ Benchmark-Architektur

Das System beruht auf einer klaren Trennung der Verantwortlichkeiten:

  • ai-harness → Musterorchestrierungsschicht
  • polars-bench → Ausführungs- und Auswertungs-Engine

Diese Aufschlüsselung ermöglicht es uns, die Generierung (LLM) von der Ausführungsrealität (Laufzeit) zu isolieren, was genau das Ziel des Benchmarks ist.

🤝 Sponsoren, Mentoren & Organisatoren, Teams

Dieser Hackathon wird durch ein Ökosystem sich ergänzender Akteure ermöglicht: Sponsoren, Mentoren und Organisatoren, die jeweils eine Schlüsselrolle für das Gesamterlebnis spielen.

🏢 Organisatoren

Die Veranstaltung wird von der AI ​​Tinkerers Paris Community organisiert, einem Kollektiv, das sich aktiv mit dem Experimentieren und dem Austausch von KI-Technologien beschäftigt.

Ihre Positionierung ist klar: die Förderung konkreter Experimente mit KI-Modellen, wobei der Schwerpunkt auf realer Entwicklung und nicht auf Demonstrationen liegt.

💼 Sponsoren

Sponsoren unterstützen die Veranstaltung durch folgende Leistungen:

  • technische Ressourcen (GPU, Infrastruktur, Tools)
  • Finanzierung
  • Sichtbarkeit

👉 Ihre Rolle ist entscheidend für die Schaffung einer realistischen Umgebung (Rechenbeschränkungen, Docker-Ausführung usw.).

🧑‍🏫 Mentoren

Mentoren unterstützen die Teilnehmer während des gesamten Hackathons:

  • Unterstützung bei der Strukturierung von Vorgehensweisen
  • Feedback zu Vorlagen und Eingabeaufforderungen
  • Tipps zu Leistung und Optimierung

👉 Sie helfen, häufige Sackgassen zu vermeiden:

  • Überoptimierung der Eingabeaufforderung
  • fehlende Validierung
  • Fehler bei der Dateninterpretation

👥 Teams

🔗 Nützliche Links

🧱 Technischer Stack

Die Architektur ist bewusst einfach gehalten, aber durch reale Gegebenheiten eingeschränkt:

  • Python zur Ausführung
  • Polars als Suchmaschine
  • Quinn 2.5 als Generationsmodell
  • FastAPI für die Schnittstelle
  • Lokale Sandbox (CPU) mit Speicherbeschränkungen

Kern des Systems ist eine API, die eine natürliche Anfrage in direkt ausführbaren Polars-Code umwandelt.

🔄 Ausführungspipeline

Der Benchmark erfordert eine vollständige Kette ohne Abkürzungen:

User Query (NL)
    ↓
Prompt enrichi (schema + règles)
    ↓
LLM
    ↓
Code Polars généré
    ↓
Exécution réelle
    ↓
Validation
    ↓
Scoring

👉 Das Modell wird nicht danach bewertet, was es "aussagt", sondern danach, was sein Code tatsächlich produziert.

🧠 Generationsstrategie

Die entscheidende Wahl ist einfach:

❌ Modell trainieren ✅ das eigene Verhalten einschränken

Statt aufwendiger Feinabstimmung basiert das System auf Folgendem:

  • eine strukturierte Aufforderung
  • ein Datensatz gezielter Beispiele

Erforderliches Format

System:
- règles Polars
- contraintes strictes

User:
- schéma
- requête

Assistant:
- code uniquement

👉 Das Modell lernt ein Ausführungsmuster, kein allgemeines Wissen.

🗂️ Datensatz

Der Datensatz ist nicht riesig, das ist absichtlich:

  • 15 bis 500 Beispiele
  • konzentriert sich auf kritische Muster

Besteck:

  • Auswahl
  • Filter
  • Aggregationen
  • tritt bei
  • Fensterfunktionen
  • Nullwerte
  • Sonderfälle

👉 Die Abdeckung ist wichtiger als die Menge.

📊 Schema-Injektion

Das Modell trifft keine Vorhersagen. Das Schema wird systematisch eingespielt:

{
  "columns": ["card_name", "mana_cost", "frequency"]
}

Direkte Auswirkungen:

  • weniger Halluzinationen
  • Gültige Abfragen beim ersten Versuch
  • starke Abhängigkeit vom bereitgestellten Kontext

👉 Ohne ein Diagramm bricht das System zusammen.

⚡ Inferenzbeschränkungen

  • ~6GB Modell
  • Nur CPU
  • hohe Latenz

Folge:

Jeder Anruf zählt.

  • Das Umsortieren ist teuer
  • Die Aufgabenstellung muss von Anfang an präzise sein.

👉 Die Kosten eines Fehlers sind in der Punktzahl enthalten.

🧪 Validierung & Bewertung

Der Benchmark validiert ein vollständiges Verhalten, nicht nur eine Rohausgabe.

Level

  1. Gültiger Code
  2. Erfolgreiche Durchführung
  3. Korrektes Ergebnis
  4. Akzeptable Leistung

Punktzahl

Score = N / (T * VRAM^0.1 * RAM^0.01)

👉 Wir messen ein eingeschränktes System, kein abstraktes Modell.

🔁 Architektonische Entscheidungen

Drei Optionen:

  • Feinabstimmung → zu schwer
  • Multi-Modelle → zu komplex
  • Eingabeaufforderung + Datensatz → ausgewählt

👉 Entscheidung: Das Verhalten in den Daten kodieren

🧩 Implementierung

Die API stellt einen einfachen Datenstrom bereit:

  • Eingabe:

    • Anfrage
    • Metadaten

  • Ausgabe:

    • Polars-Code

Der Service:

  • erstellt die Eingabeaufforderung
  • ruft das Modell auf
  • gibt den Code zurück

👉 Freiwillige Einfachheit: Die eigentliche Schwierigkeit liegt woanders.

📦 Positionierung

Das Projekt wird nicht als LLM-Wrapper präsentiert, sondern als:

Ein sicherer analytischer Copilot für tabellarische Daten

Mit :

  • geführte Eingabeaufforderungen
  • strukturierter Kontext
  • Ausführung verifiziert

👉 Das Produkt wird durch seine Einschränkungen definiert, nicht durch das Modell.

🧭 Systemlesung

Dieser Vergleich zeigt eines:

Die Leistungsfähigkeit eines kleinen Modells ist eine Eigenschaft des Systems, nicht des Modells allein.

Die eigentlichen Hebel:

  • Struktur der Aufgabenstellung
  • Datensatz
  • Kontextinjektion
  • Laufzeitvalidierung

👉 Wir gehen von einem Problem des maschinellen Lernens zu einem ingenieurwissenschaftlichen Problem über.

🧱 Komponenten

Geschirr

  • Abstraktion von Modellen
  • Standardisierung der Ein- und Ausgaben

Ausführender

  • isolierte Ausführung
  • Fehlererfassung
  • Laufzeitmetriken

Punktevergabe

  • Gültigkeit
  • Leistung
  • Stabilität

📊 Was wird gemessen?

  • Ausführung → Läuft es?
  • Korrektur → Ist das korrekt?
  • Polars Qualität → korrekte Verwendung des Motors
  • Leistung → tatsächliche Kosten

🔍 Fallbeispiel aus dem echten Leben

Eingang:

„Finde die 10 häufigsten Karten mit Manakosten ≤ 3“

Erwartet :

  • Filter korrekt
  • korrekte Aggregation
  • Sortierung + Limit

Beobachtet:

  • gültiger, aber fehlerhafter Code
  • Python-Fallback
  • stille Fehler

👉 Der Benchmark verdeutlicht die Diskrepanz zwischen Generierung und Ausführung.

⚠️ Es geht um echtes Geld

Ein LLM generiert plausiblen Code, keinen zuverlässigen Code.

Also, in Produktion:

  • Sandbox erforderlich
  • systematische Validierung
  • kontrollierte Abrufe
  • Überwachung

👉 Ohne dies ist das System standardmäßig instabil.

🧠 Projektbeitrag

Dieser Benchmark führt Folgendes ein:

  • eine durchgängige ausführbare Pipeline
  • eine Multikriterienbewertung
  • ein reproduzierbarer Ansatz
  • eine produktionsfreundliche Umgebung

Ausruhen :

👉 Dies ist kein Modelltest mehr, sondern ein vollständiger Systemtest.

📹 Demo

Einreichungsvideo:

📦 Ergebnisse des Hackathons

  • Vollständiger Benchmark-Code
  • Testset
  • Reproduzierbare Pipeline
  • Vergleichsergebnisse

Beispiel einer bereitgestellten Struktur:

🧭 Schlussfolgerung

Dieser Hackathon soll nicht beweisen, dass LLMs funktionieren.

Es zeigt wo sie brechen.

Und vor allem:

Ein sinnvoller Vergleichsmaßstab misst nicht die Generation. Es misst die Leistung.

🔮 Darkwood-Perspektive

Diese Art von Benchmark fügt sich direkt in eine umfassendere Vision ein:

  • Orchestrierung von KI-Pipelines
  • systematische Validierung
  • Trennung von Generierung und Ausführung
  • Beobachtbarkeit

👉 Dies ist kein Demo-Tool. Es ist ein Grundbaustein für den Aufbau zuverlässiger Systeme.

Site

Network

Social

Darkwood 2026, alle Rechte vorbehalten