Bullshit Benchmark propose une manière d’examiner les affirmations et les résultats de projets logiciels

Ce que mesure le benchmark : bullshit-benchmark

Bullshit Benchmark propose une manière d’examiner les affirmations et les résultats de projets logiciels.

BullshitBench est un projet Python créé par Peter Gostev qui teste si les modèles d'IA détectent les absurdités dans une invite, les signalent clairement et évitent de continuer avec des hypothèses invalides. Le README définit trois catégories de résultats : Clear Pushback, où le modèle rejette la prémisse erronée ; Partial Challenge, où le modèle signale des problèmes mais continue d'interagir avec la mauvaise prémisse ; et Accepted Nonsense, où le modèle traite l'absurdité comme valide. Le benchmark ne porte pas sur la qualité des réponses au sens habituel, mais sur le fait que le modèle conteste ou non une prémisse absurde.

La bonne lecture de ce dépôt commence par sa promesse précise, puis par les contraintes que le README expose. Les noms de commandes, les chemins et les formats ne sont pas des détails décoratifs : ils déterminent ce qui peut être reproduit et ce qui reste une affirmation du projet. Pour une équipe, le point important est de relier chaque capacité à son environnement réel, à ses dépendances et à la surface de maintenance. Cette distinction évite de transformer une liste de fonctions en garantie générale. Les résultats annoncés appartiennent au contexte décrit par les auteurs ; ils demandent donc une comparaison avec les entrées, les versions et les plateformes réellement utilisées. Le dépôt reste utile quand cette limite est acceptée, car il donne un point de départ concret et des traces consultables. Repère 1 pour bullshit-benchmark.

L'ensemble de questions v2 et l'évaluation : bullshit-benchmark

L'ensemble v2 contient 100 invites absurdes réparties en cinq domaines : logiciel (40), finance (15), droit (15), médical (15) et physique (15). Le README mentionne 13 techniques d'absurdité, avec des exemples comme plausible_nonexistent_framework, misapplied_mechanism, nested_nonsense et specificity_trap, mais il n'en liste pas les 13. Chaque ligne est évaluée par un panel fixe de trois juges : anthropic/claude-sonnet-4.6, openai/gpt-5.2 et google/gemini-3.1-pro-preview, en mode panel complet avec agrégation par moyenne. Le classement v2 publié comprend actuellement 192 lignes modèle/raisonnement.

La bonne lecture de ce dépôt commence par sa promesse précise, puis par les contraintes que le README expose. Les noms de commandes, les chemins et les formats ne sont pas des détails décoratifs : ils déterminent ce qui peut être reproduit et ce qui reste une affirmation du projet. Pour une équipe, le point important est de relier chaque capacité à son environnement réel, à ses dépendances et à la surface de maintenance. Cette distinction évite de transformer une liste de fonctions en garantie générale. Les résultats annoncés appartiennent au contexte décrit par les auteurs ; ils demandent donc une comparaison avec les entrées, les versions et les plateformes réellement utilisées. Le dépôt reste utile quand cette limite est acceptée, car il donne un point de départ concret et des traces consultables. Repère 2 pour bullshit-benchmark.

Le visualiseur interactif : bullshit-benchmark

Le projet inclut un visualiseur public à l'adresse https://petergpt.github.io/bullshit-benchmark/viewer/index.v2.html. Le README décrit six visualisations : un classement principal montrant la répartition vert/ambre/rouge de chaque modèle selon le taux de détection, un paysage par domaine comparant la détection globale aux résultats par domaine, une évolution du taux de détection dans le temps, un nuage de points date de sortie versus taux vert, un nuage de points raisonnement avec un bouton bascule tokens/coût, et une vue taille du modèle traçant les paramètres totaux et actifs pour les modèles ayant des métadonnées publiques. Le visualiseur propose aussi un menu déroulant Version du benchmark pour passer d'un ensemble publié à l'autre, par exemple v1 et v2.

La bonne lecture de ce dépôt commence par sa promesse précise, puis par les contraintes que le README expose. Les noms de commandes, les chemins et les formats ne sont pas des détails décoratifs : ils déterminent ce qui peut être reproduit et ce qui reste une affirmation du projet. Pour une équipe, le point important est de relier chaque capacité à son environnement réel, à ses dépendances et à la surface de maintenance. Cette distinction évite de transformer une liste de fonctions en garantie générale. Les résultats annoncés appartiennent au contexte décrit par les auteurs ; ils demandent donc une comparaison avec les entrées, les versions et les plateformes réellement utilisées. Le dépôt reste utile quand cette limite est acceptée, car il donne un point de départ concret et des traces consultables. Repère 3 pour bullshit-benchmark.

Exécuter le pipeline : bullshit-benchmark

Le README documente un démarrage rapide qui commence par définir les clés API : OPENROUTER_API_KEY, plus OPENAI_API_KEY pour les modèles routés vers OpenAI, et les variables optionnelles OPENAI_PROJECT et OPENAI_ORGANIZATION. Le routage des fournisseurs est configuré par modèle via collect.model_providers et grade.model_providers, avec OpenRouter par défaut. L'exécution de bout en bout v2 est ./scripts/run_end_to_end.sh --config config.v2.json --viewer-output-dir data/v2/latest --with-additional-judges, et le même script peut servir le visualiseur localement avec --serve --port 8877. Le README n'explique pas les détails internes du script ni comment l'exécuter sur des systèmes non Unix.

La bonne lecture de ce dépôt commence par sa promesse précise, puis par les contraintes que le README expose. Les noms de commandes, les chemins et les formats ne sont pas des détails décoratifs : ils déterminent ce qui peut être reproduit et ce qui reste une affirmation du projet. Pour une équipe, le point important est de relier chaque capacité à son environnement réel, à ses dépendances et à la surface de maintenance. Cette distinction évite de transformer une liste de fonctions en garantie générale. Les résultats annoncés appartiennent au contexte décrit par les auteurs ; ils demandent donc une comparaison avec les entrées, les versions et les plateformes réellement utilisées. Le dépôt reste utile quand cette limite est acceptée, car il donne un point de départ concret et des traces consultables. Repère 4 pour bullshit-benchmark.

Ensembles de données et documentation : bullshit-benchmark

L'ensemble v1 reste dans data/latest, tandis que v2 est publié dans data/v2/latest. L'ensemble de questions v2 provient de drafts/new-questions.md via scripts/build_questions_v2_from_draft.py. L'évaluation canonique est fixée à exactement trois juges par ligne avec agrégation par moyenne ; l'ancien mode de départage des désaccords est retiré du pipeline principal. La documentation comprend docs/TECHNICAL.md pour les opérations du pipeline et l'organisation du dépôt, CHANGELOG.md pour les notes de version, questions.json et questions.v2.json pour les ensembles de questions, et config.json et config.v2.json pour les réglages des modèles et du pipeline. Le README précise qu'il est volontairement destiné au public, le contenu technique étant réservé au guide technique.

La bonne lecture de ce dépôt commence par sa promesse précise, puis par les contraintes que le README expose. Les noms de commandes, les chemins et les formats ne sont pas des détails décoratifs : ils déterminent ce qui peut être reproduit et ce qui reste une affirmation du projet. Pour une équipe, le point important est de relier chaque capacité à son environnement réel, à ses dépendances et à la surface de maintenance. Cette distinction évite de transformer une liste de fonctions en garantie générale. Les résultats annoncés appartiennent au contexte décrit par les auteurs ; ils demandent donc une comparaison avec les entrées, les versions et les plateformes réellement utilisées. Le dépôt reste utile quand cette limite est acceptée, car il donne un point de départ concret et des traces consultables. Repère 5 pour bullshit-benchmark.

Licence : bullshit-benchmark

Le projet est publié sous licence MIT, copyright 2026 Peter Gostev. La licence autorise l'utilisation, la copie, la modification, la fusion, la publication, la distribution, la sous-licence et la vente de copies du logiciel, à condition que l'avis de droit d'auteur et l'avis de permission soient inclus. Le logiciel est fourni « tel quel », sans garantie d'aucune sorte, y compris la qualité marchande, l'adéquation à un usage particulier et la non-contrefaçon. La licence ne dit rien sur la posture de sécurité, le support ou les engagements de maintenance, et le README non plus.

La bonne lecture de ce dépôt commence par sa promesse précise, puis par les contraintes que le README expose. Les noms de commandes, les chemins et les formats ne sont pas des détails décoratifs : ils déterminent ce qui peut être reproduit et ce qui reste une affirmation du projet. Pour une équipe, le point important est de relier chaque capacité à son environnement réel, à ses dépendances et à la surface de maintenance. Cette distinction évite de transformer une liste de fonctions en garantie générale. Les résultats annoncés appartiennent au contexte décrit par les auteurs ; ils demandent donc une comparaison avec les entrées, les versions et les plateformes réellement utilisées. Le dépôt reste utile quand cette limite est acceptée, car il donne un point de départ concret et des traces consultables. Repère 6 pour bullshit-benchmark.

Conclusion éditoriale

Le dépôt sert surtout à structurer une lecture critique des performances annoncées, en séparant les mesures, leur protocole et les conclusions possibles. La première vérification doit porter sur les éléments propres à bullshit-benchmark, notamment les commandes, fichiers et limites cités par son README.

Sources officielles

1. Official documentation
2. Official README
3. Project repository