Samedi 18 avril, j'ai participé à un hackathon qui invite les ingénieurs en apprentissage automatique, les ingénieurs de données et les chercheurs à Paris pour une étude approfondie de l'évaluation des petits modèles de langage (SLM).

Ce hackathon, organisé par AI Tinkerers Paris, s’inscrit dans une problématique très concrète :

tester la capacité réelle des modèles de langage à produire du code exécutable en production.

Le thème - "Benchmarking Small Language Models in the Real World" - pose un cadre clair : sortir des démos impressionnantes pour confronter les modèles à des contraintes réelles (exécution, performance, ressources).

Le défi consiste à générer automatiquement des requêtes Polars à partir de langage naturel, avec une exigence forte :

• produire du code correct

• garantir qu’il est exécutable

• optimiser temps d’exécution et consommation mémoire

Le scoring reflète cette réalité :

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

👉 Autrement dit : la précision seule ne suffit pas - l’efficacité système devient une contrainte centrale.

Chaque équipe travaille dans un environnement standardisé :

• exécution sous Docker

• usage de Polars pour le traitement de données

• contraintes GPU / mémoire

• dataset d’évaluation fourni

L’objectif n’est pas de faire "le meilleur prompt", mais de construire un système capable de :

• résister à des données réelles

• produire du code robuste

• passer un benchmark automatisé

Ce hackathon se distingue par son approche :

• pas de démo marketing

• pas de génération "impressionnante mais fragile"

• focus sur ce qui fonctionne vraiment

👉 C’est un environnement qui expose directement les limites actuelles des LLM :

• hallucinations

• erreurs de syntaxe

• incompréhension du schéma de données

Et oblige à construire autour :

• prompt engineering structuré

• validation systématique

• boucle d’itération rapide

On n’est pas ici dans un hackathon "créatif", mais dans un benchmark d’ingénierie.

Le livrable final n’est pas une idée, mais :

un système mesurable, reproductible, et comparable.

La matinée est dédiée à la mise en place du cadre technique et organisationnel :

• formation des équipes via le portail de l’événement

• présentation du problème par les organisateurs et mentors

• clarification des attentes (génération de code Polars exécutable + scoring)

• setup initial de l’environnement de travail

L’équipe Darkwood se constitue autour de :

• Mathieu Ledru

• Victor-eliejah Garnier

• Mirza Marotsaha

Objectif de cette phase : réduire l’incertitude et aligner tout le monde sur un pipeline exécutable dès les premières heures.

• déjeuner fourni sur place

• échanges informels entre équipes

• consultation du message center (questions globales, clarifications du jury)

👉 Phase courte, sans véritable découplage : le projet reste en cours d’itération.

L’après-midi est entièrement orienté production :

• implémentation du benchmark (polars-bench)

• intégration du modèle via ai-harness

• expérimentation sur les prompts (structure, format, contraintes)

• ajustement du comportement du modèle via dataset et prompt engineering

• validation progressive via exécution réelle

Les itérations se concentrent sur trois axes :

• réduction des hallucinations (schema-aware prompting)

• amélioration du taux de code exécutable

• optimisation du score (temps / mémoire / exactitude)

👉 La logique n’est pas d’ajouter des features, mais de resserrer le système autour de contraintes réelles.

Le système s’appuie sur une séparation claire des responsabilités :

• ai-harness → couche d’orchestration des modèles

• polars-bench → moteur d’exécution et d’évaluation

Cette découpe permet d’isoler la génération (LLM) de la réalité d’exécution (runtime), ce qui est précisément l’objectif du benchmark.

Ce hackathon est rendu possible grâce à un écosystème d’acteurs complémentaires : sponsors, mentors et organisateurs, chacun jouant un rôle clé dans l’expérience globale.

L’événement est orchestré par la communauté AI Tinkerers Paris, un collectif actif autour de l’expérimentation et du partage sur les technologies IA.

• 🌐 Site officiel : https://paris.aitinkerers.org

• 📅 Page du hackathon : https://paris.aitinkerers.org/hackathons/h_sj1ca_J4Hdk

• 👥 Organizers : https://paris.aitinkerers.org/hackathons/h_sj1ca_J4Hdk/organizers

Leur positionnement est clair : favoriser des expérimentations concrètes autour des modèles IA, avec un focus sur l’ingénierie réelle plutôt que la démonstration.

Les sponsors soutiennent l’événement en apportant :

• ressources techniques (GPU, infra, outils)

• financement

• visibilité

👉 Leur rôle est critique pour permettre un environnement réaliste (contraintes de compute, exécution Docker, etc.).

• Mistral

  • Sponsor page: Hackathon Sponsors

  • Representative: Matthieu Dinot — AI Scientist at Mistral

• Alpic

  • Sponsor page: Hackathon Sponsors

  • Representative: Nikolay Rodionov — COO at Alpic

  • Other links:

    • X / Twitter

    • GitHub

• Cloudfare

  • Sponsor page: Hackathon Sponsors

  • Representative: Nans Cyril Bouissou — Account executive at Cloudfare

• Replit

  • Sponsor page: Hackathon Sponsors

  • Representative: Raouf Chebri — Developer Relations Engineer at Replit

• Microsoft

  • Sponsor page: Hackathon Sponsors

  • Representative: Julien Bichon — Developer Experience | GTM Manager at Microsoft

• ESGI (venue partner mentioned alongside sponsors)

  • Sponsor / venue page: Hackathon Sponsors

  • Representative: Astrid Beaucourt — Chargée de communication at ESGI

  • School links:

    • LinkedIn

    • X / Twitter

Les mentors accompagnent les participants tout au long du hackathon :

• aide à la structuration des approches

• feedback sur les modèles et prompts

• conseils sur la performance et l’optimisation

👉 Ils permettent d’éviter les impasses classiques :

• sur-optimisation du prompt

• manque de validation

• erreurs d’interprétation des données

• Arthur Mensch

  • Mentor page: Hackathon Mentors

  • Role: Co-founder and CEO of Mistral AI

  • Public profile link: not visible in the provided data

• Léo Arsenin

  • Mentor page: Hackathon Mentors

  • LinkedIn: Léo Arsenin

  • Role: Solutions engineer at Cloudfare

• Matthieu Dinot

  • Mentor page: Hackathon Mentors

  • LinkedIn: Matthieu Dinot

  • Role: AI Scientist at Mistral

• Preetham Kaukuntla

  • Mentor page: Hackathon Mentors

  • LinkedIn: Preetham Kaukuntla

  • Role: Staff Data Scientist at Glassdoor

• Mentors Message Board

  • Mentors Message Board

• Darkwood

  • Statut : 1st Place

  • Entry : /hackathons/h_sj1ca_J4Hdk/entries/ht_qFVxlREukLQ

  • Team : /hackathons/h_sj1ca_J4Hdk/teams/ht_qFVxlREukLQ

  • Demo video : YouTube

  • Membres :

    • Mathieu Ledru

    • Mirza Marotsaha

    • Victor-eliejah GARNIER

• bluebull

  • Statut : Best Startup

  • Entry : /hackathons/h_sj1ca_J4Hdk/entries/ht_-p8xvdGl-oA

  • Team : /hackathons/h_sj1ca_J4Hdk/teams/ht_-p8xvdGl-oA

  • Membres :

    • Vasiliki Doropoulou

• Muon

  • Statut : 10x Data Scientist

  • Entry : /hackathons/h_sj1ca_J4Hdk/entries/ht_ub4tDzlrft0

  • Team : /hackathons/h_sj1ca_J4Hdk/teams/ht_ub4tDzlrft0

  • Membres :

    • Imane Momayiz

• Polaris

  • Statut : Finalist

  • Entry : /hackathons/h_sj1ca_J4Hdk/entries/ht_y4_Yz6P5BZE

  • Team : /hackathons/h_sj1ca_J4Hdk/teams/ht_y4_Yz6P5BZE

  • Membres :

    • Hippolyte Dupont

    • Ghaith ABDESSALEM

    • Jacques Dumora

• Training Expert

  • Statut : Finalist

  • Entry : /hackathons/h_sj1ca_J4Hdk/entries/ht_njEtwEBAmUE

  • Team : /hackathons/h_sj1ca_J4Hdk/teams/ht_njEtwEBAmUE

  • Membres :

    • Eva Useros Marugan

    • Paul-Louis Fouesnant

• CodeMind

  • Statut : Submitted

  • Entry : /hackathons/h_sj1ca_J4Hdk/entries/ht_wRj-nEG24zE

  • Team : /hackathons/h_sj1ca_J4Hdk/teams/ht_wRj-nEG24zE

  • Membres :

    • Amelie Smith

    • Damien Frechou

    • Anis Kaci

    • Choutri Adel Djalil

• Coffe is life

  • Statut : Submitted

  • Entry : /hackathons/h_sj1ca_J4Hdk/entries/ht_RFBTGYYwbm4

  • Team : /hackathons/h_sj1ca_J4Hdk/teams/ht_RFBTGYYwbm4

  • Membres :

    • Pierre Lepagnol

    • Filipp Trigub

• PiLLM

  • Statut : Submitted

  • Entry : /hackathons/h_sj1ca_J4Hdk/entries/ht_Gc4SneBV2D4

  • Team : /hackathons/h_sj1ca_J4Hdk/teams/ht_Gc4SneBV2D4

  • Membres :

    • Din Sokheng

    • Ahmed Abdelaziz Mokeddem

• 🏠 Home : https://paris.aitinkerers.org/hackathons/h_sj1ca_J4Hdk

• 👥 Teams : https://paris.aitinkerers.org/hackathons/h_sj1ca_J4Hdk/teams

• 📩 Message Center : https://paris.aitinkerers.org/message_center?board_key=meetup_mu_eZJ5tCXlA2A

• 🏆 Submissions : https://paris.aitinkerers.org/hackathons/h_sj1ca_J4Hdk/entries

• 📊 Results : https://paris.aitinkerers.org/hackathons/h_sj1ca_J4Hdk/results

L’architecture est volontairement simple, mais contrainte par des conditions réelles :

• Python pour l’exécution

• Polars comme moteur de requêtes

• Quinn 2.5 comme modèle de génération

• FastAPI pour l’interface

• Sandbox locale (CPU) avec contraintes mémoire

Le cœur du système est une API qui transforme une requête naturelle en code Polars directement exécutable.

Le benchmark impose une chaîne complète, sans raccourci :

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

👉 Le modèle n’est pas évalué sur ce qu’il "dit", mais sur ce que son code produit réellement.

Le choix structurant est simple :

❌ entraîner le modèle ✅ contraindre son comportement

Plutôt que du fine-tuning lourd, le système repose sur :

• un prompt structuré

• un dataset d’exemples ciblés

System: - règles Polars - contraintes strictes User: - schéma - requête Assistant: - code uniquement

👉 Le modèle apprend un pattern d’exécution, pas une connaissance générale.

Le dataset n’est pas massif, il est intentionnel :

• 15 à 500 exemples

• centrés sur les patterns critiques

Couverts :

• sélection

• filtres

• agrégations

• joins

• window functions

• nulls

• edge cases

👉 La couverture est plus importante que le volume.

Le modèle ne devine rien. Le schéma est injecté systématiquement :

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

Effets directs :

• moins d’hallucinations

• requêtes valides dès le premier essai

• dépendance forte au contexte fourni

👉 Sans schéma, le système s’effondre.

• modèle ~6GB

• CPU uniquement

• latence élevée

Conséquence :

• chaque appel compte

• les retries coûtent cher

• le prompt doit être précis dès le départ

👉 Le coût d’erreur est intégré dans le score.

Le benchmark valide un comportement complet, pas une sortie brute.

1. Code valide

2. Exécution réussie

3. Résultat correct

4. Performance acceptable

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

👉 On mesure un système contraint, pas un modèle abstrait.

Trois options :

• fine-tuning → trop lourd

• multi-modèles → trop complexe

• prompt + dataset → choisi

👉 Décision : encoder le comportement dans les données

L’API expose un flux simple :

• input :

  • requête

  • metadata

• output :

  • code Polars

Le service :

• construit le prompt

• appelle le modèle

• retourne le code

👉 Simplicité volontaire : toute la difficulté est ailleurs.

Le projet n’est pas présenté comme un wrapper LLM, mais comme :

un copilot analytique sécurisé pour données tabulaires

Avec :

• prompts guidés

• contexte structuré

• exécution vérifiée

👉 Le produit est défini par ses contraintes, pas par le modèle.

Ce benchmark montre une chose :

la performance d’un small model est une propriété du système, pas du modèle seul

Les leviers réels :

• structure du prompt

• dataset

• injection du contexte

• validation runtime

👉 On passe d’un problème de ML à un problème d’ingénierie.

• abstraction des modèles

• normalisation des inputs / outputs

• exécution isolée

• capture des erreurs

• métriques runtime

• validité

• performance

• stabilité

• Exécution → est-ce que ça tourne

• Correction → est-ce que c’est juste

• Qualité Polars → usage correct du moteur

• Performance → coût réel

Input :

"Find the top 10 most frequent cards with mana cost ≤ 3"

Attendu :

• filtre correct

• agrégation correcte

• tri + limite

Observé :

• code valide mais faux

• fallback Python

• erreurs silencieuses

👉 Le benchmark révèle l’écart entre génération et exécution.

Un LLM génère du code plausible, pas du code fiable

Donc en production :

• sandbox obligatoire

• validation systématique

• retries contrôlés

• monitoring

👉 Sans ça, le système est instable par défaut.

Ce benchmark introduit :

• un pipeline exécutable end-to-end

• une évaluation multi-critères

• une approche reproductible

• un environnement proche production

Repos :

• ai-harness → orchestration

• polars-bench → évaluation

👉 Ce n’est plus un test de modèle, c’est un test de système complet.

Vidéo de soumission :

• Code benchmark complet

• Jeu de tests

• Pipeline reproductible

• Résultats comparatifs

Exemple de structure fournie :

• submission_example

• main benchmark code

• datasets

• logs

Ce hackathon ne cherche pas à montrer que les LLMs fonctionnent.

Il montre où ils cassent.

Et surtout :

Un benchmark utile ne mesure pas la génération. Il mesure l’exécution.

Ce type de benchmark s’intègre directement dans une vision plus large :

• orchestration de pipelines IA

• validation systématique

• séparation génération / exécution

• observabilité

👉 Ce n’est pas un outil de démo. C’est une brique pour construire des systèmes fiables.