đŸ‘šâ€đŸ’» Évaluation comparative de petits modĂšles de langage dans le monde rĂ©el

le 21 avril 2026

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).

🎯 Objectif

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.

⚙ Contexte technique

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Ă©

đŸ§© Positionnement

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

📊 Lecture

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.

đŸ—ïž Organisation de la journĂ©e

Matin - cadrage et initialisation

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 :

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

Midi - pause contrainte

  • 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.

AprÚs-midi - implémentation et itérations

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.

⚙ Architecture du benchmark

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.

đŸ€ Sponsors, Mentors & Organizers, Equipes

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.

🏱 Organizers

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.

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.

đŸ’Œ Sponsors

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.).

đŸ§‘â€đŸ« Mentors

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

đŸ‘„ Équipes

🔗 Liens utiles

đŸ§± Stack technique

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.

🔄 Pipeline d’exĂ©cution

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.

🧠 StratĂ©gie de gĂ©nĂ©ration

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

Format imposé

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.

đŸ—‚ïž Dataset

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.

📊 Injection du schĂ©ma

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.

⚡ Contraintes d’infĂ©rence

  • 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.

đŸ§Ș Validation & scoring

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

Niveaux

  1. Code valide
  2. Exécution réussie
  3. RĂ©sultat correct
  4. Performance acceptable

Score

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

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

🔁 Choix d’architecture

Trois options :

  • fine-tuning → trop lourd
  • multi-modĂšles → trop complexe
  • prompt + dataset → choisi

👉 DĂ©cision : encoder le comportement dans les donnĂ©es

đŸ§© ImplĂ©mentation

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.

📩 Positionnement

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.

🧭 Lecture systùme

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.

đŸ§± Composants

Harness

  • abstraction des modĂšles
  • normalisation des inputs / outputs

Executor

  • exĂ©cution isolĂ©e
  • capture des erreurs
  • mĂ©triques runtime

Scoring

  • validitĂ©
  • performance
  • stabilitĂ©

📊 Ce qui est mesurĂ©

  • 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

🔍 Cas 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.

⚠ Enjeux rĂ©els

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.

🧠 Apport du projet

Ce benchmark introduit :

  • un pipeline exĂ©cutable end-to-end
  • une Ă©valuation multi-critĂšres
  • une approche reproductible
  • un environnement proche production

Repos :

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

đŸ“č DĂ©mo

Vidéo de soumission :

📩 Livrables du hackathon

  • Code benchmark complet
  • Jeu de tests
  • Pipeline reproductible
  • RĂ©sultats comparatifs

Exemple de structure fournie :

🧭 Conclusion

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.

🔼 Perspective Darkwood

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.

Site

Network

Social

Darkwood 2026, tous droits réservés