Leanstral 1.5 et le banc de test pour un raisonnement vérifiable

De nombreux lancements de modèles sont jugés selon un rituel familier : parcourir le tableau de référence, comparer le classement, décider si le lancement est important. Leanstral 1.5 mérite un test différent.

Mistral présente Leanstral 1.5 comme un modèle conçu pour le raisonnement et le travail de preuve orienté Lean, avec des références à l'appui dans l'annonce de Mistral, l'aperçu du modèle et la fiche modèle Hugging Face. Cela ne signifie pas que les opérateurs doivent le considérer comme prêt pour la production pour chaque tâche sensible. Cela signifie que la question d’évaluation change. La question utile n’est pas seulement : « Le modèle a-t-il répondu correctement ? » La question la plus pointue est : « Le modèle peut-il produire un artefact qu'un autre système peut rejeter, vérifier, réparer ou approuver ? »

Les classements comptent toujours. Ils donnent un signal approximatif et un profil de référence faible devrait ralentir toute conversation de déploiement. Mais les scores de référence sont un indicateur limité des flux de travail où la réponse dépend d'une dérivation, d'une structure de preuve, d'un test reproductible ou d'une règle qui doit survivre à un audit. Pour ces flux de travail, une explication convaincante ne suffit pas. Vous voulez une réponse, un artefact vérifiable, un vérificateur indépendant et une règle claire sur ce qui se passe lorsque le vérificateur dit non.

Les sources utilisées pour ce cadrage incluent la publication Leanstral 1.5 de Mistral sur https://mistral.ai/news/leanstral-1-5/, L'aperçu du modèle de Mistral sur https://docs.mistral.ai/models/overview, la carte modèle Hugging Face sur https://huggingface.co/mistralai/Leanstral-1.5-119B-A6B, Stanford HELM sur https://crfm.stanford.edu/helm/latest/, Hugging Face Evaluate sur https://huggingface.co/docs/evaluate/index, OpenAI Evals sur https://github.com/openai/evals, Recherche visible sur la pensée étendue d'Anthropic à https://www.anthropic.com/research/visible-extended-thinking, et Lean 4 à https://github.com/leanprover/lean4.

Le raisonnement du vérificateur dans la boucle en termes simples

Le raisonnement par vérificateur dans la boucle est un flux de travail dans lequel un modèle propose une réponse plus quelque chose d'inspectable : une preuve, une dérivation, un chemin de code, une trace structurée, un objet rempli de schéma ou un plan contraint. Un vérificateur distinct évalue ensuite l'artefact par rapport aux règles définies. Le vérificateur peut être Lean 4, une suite de tests unitaires, un vérificateur de type, un analyseur statique, un solveur symbolique, un moteur de politique, un validateur de données ou un outil de révision spécifique à un domaine.

Les traces de raisonnement en langage naturel sont utiles, mais elles ne sont pas la même chose que la vérité. Les travaux d'Anthropic sur la pensée étendue visible rappellent que l'exposition du raisonnement nécessite de la prudence. Une trace peut faciliter l’inspection, le débogage et l’évaluation, mais elle peut néanmoins être incomplète, post-hoc ou trompeuse. La règle opérationnelle est simple : faire davantage confiance au résultat du vérificateur qu'à l'explication du modèle, et ne faire confiance à aucun des deux sans un ensemble d'évaluation spécifique à la tâche.

Une façon pratique de visualiser les modèles de raisonnement consiste à les juger moins comme des écrivains que comme des analystes débutants travaillant sous des tests. Si le travail ne peut pas être vérifié, le modèle génère surtout de la confiance. Si le travail peut être vérifié, le système peut rejeter les mauvais résultats, mesurer les modèles de défaillance et décider si les tentatives de réparation sont utiles.

Le banc de test de raisonnement Optijara Verifier-in-the-Loop

Utilisez un petit banc de test reproductible avant d'ajouter Leanstral 1.5, ou tout autre modèle orienté vers la preuve, à une pile d'IA privée ou locale. Le banc de test doit forcer trois sorties à chaque exécution : la réponse finale, le raisonnement ou l'artefact de preuve et le résultat du vérificateur. Si l’un d’eux manque, vous ne testez pas le raisonnement du vérificateur dans la boucle. Vous testez la persuasion du modèle.sirène organigramme TD A[Tâche utilisateur] --> B[Le modèle propose une réponse] B --> C[Artefact structuré] C --> D[Vérificateur indépendant]

F --> C

L'étape 1 est la génération de candidats. Donnez au modèle une tâche précise et demandez une réponse ainsi qu'une preuve, une dérivation, un changement de code testable ou un artefact de décision structurée. Ne commencez pas par des invites stratégiques générales. Choisissez un travail où l’échec est visible.

L'étape 2 est la normalisation. Convertissez l'artefact dans le format que le vérificateur comprend réellement. Pour le travail de style Lean, cela peut signifier une déclaration formelle et une tentative de preuve. Pour le code, cela peut signifier un correctif, des tests et une exécution reproductible. Pour la logique métier, cela peut signifier un objet JSON qui peut être validé par rapport à un schéma et à des règles de politique.

L'étape 3 est une vérification indépendante. Le modèle ne doit pas s’auto-évaluer. Exécutez le vérificateur externe et enregistrez le résultat brut. Si le vérificateur a une couverture partielle, enregistrez-le également. La réussite de tests restreints ne prouve pas que la réponse est globalement correcte.

L'étape 4 est la mesure de la réparation. Un modèle qui échoue une fois mais qui est réparé avec précision après les commentaires du vérificateur peut toujours être utile pour les flux de travail assistés. Un modèle qui continue de produire des preuves invalides et sûres est un candidat à plus haut risque, même si la prose semble soignée.

L'étape 5 est le placement. Décidez si le flux de travail peut être automatisé, assisté ou arrêté. L'automatisation nécessite une couverture élevée des vérificateurs, une faible gravité des pannes, une latence stable et un chemin de restauration. L'utilisation assistée peut tolérer davantage d'échecs si l'examen humain est réaliste. Certaines tâches devraient rester hors de portée.

Suivez le taux de réussite, le taux d'artefacts invalides, le taux de réussite des réparations, la latence, le coût, la reproductibilité, la charge de révision humaine, l'ajustement de la confidentialité et la gravité des échecs. Ces mesures comptent plus qu’un seul chiffre de référence public.

Là où la vérification est utile

La vérification est plus solide lorsque le résultat peut être vérifié par un processus externe fiable. Les mathématiques formelles et semi-formelles en sont l’exemple le plus clair. Lean 4 peut valider un artefact de preuve formelle, mais il ne peut pas garantir que la question originale du monde réel a été traduite en la bonne déclaration formelle. Cette étape de traduction nécessite un examen humain.

Le code est souvent plus pratique. Un modèle orienté preuve ou lourd de raisonnement peut proposer une implémentation, puis les tests, les vérifications de type, l'analyse statique, les scanners de sécurité et l'exécution reproductible peuvent la repousser. Le résultat n’est pas une qualité automatique. C'est une meilleure boucle de rétroaction que de lire une explication confiante et d'espérer que le code fonctionne.

La planification scientifique et technique peut également en bénéficier, mais seulement lorsque le vérificateur est clair. Les contrôles de contraintes, la validation des équations, la validation des citations, la révision assistée par simulation et les contrôles de cohérence des unités peuvent détecter certaines erreurs. Ils n’établissent pas un jugement scientifique ouvert.

Les flux de travail métier peuvent utiliser le même modèle lorsque les règles sont explicites. Exemples hypothétiques : approbations de factures vérifiées par rapport aux règles de bon de commande, décisions d'éligibilité vérifiées par rapport à la logique politique, importations de données vérifiées par rapport à des schémas ou extraction de clauses contractuelles vérifiées par rapport à une taxonomie contrôlée. Ce ne sont pas des réclamations de clients. Ce sont des exemples du type de flux de travail dans lequel les commentaires du vérificateur ont quelque chose de concret à inspecter.

Là où la vérification induit en erreurLe vérificateur peut vérifier la mauvaise chose. C'est le mode de défaillance le plus courant. Une preuve formellement valable peut ne pas être pertinente si la question commerciale n'a pas été formalisée de manière incorrecte. Une suite de tests peut réussir sans franchir le chemin qui interrompt la production. Un vérificateur de stratégie peut approuver une sortie car la stratégie elle-même est obsolète.

Les travaux d'évaluation publique tels que Stanford HELM, Hugging Face Evaluate et OpenAI Evals pointent vers la même leçon : l'évaluation doit être spécifique à une tâche et multidimensionnelle. La précision ne suffit pas. Vous devez inspecter la fiabilité, l'étalonnage, la latence, le coût, le comportement de refus, les biais, la sécurité et la maintenabilité dans le contexte dans lequel le modèle sera exécuté.

Surveillez Goodharting contre les tests, la formalisation fragile, les problèmes cachés de qualité des données, le contexte obsolète, les tentatives de contournement du vérificateur et l'excès de confiance résultant de la réussite de contrôles étroits. Les traces de raisonnement ajoutent une observabilité partielle. Ils n’exposent pas un enregistrement causal complet des raisons pour lesquelles le modèle a produit une réponse.

N'utilisez pas de modèles orientés preuves comme système de décision principal pour le jugement subjectif, la négociation à contexte élevé, les conseils médicaux non vérifiés, les conseils juridiques, les conseils financiers, les décisions stratégiques ambiguës ou toute tâche pour laquelle aucun vérificateur fiable n'existe et les erreurs ne peuvent pas être examinées en toute sécurité. Dans ces cas-là, la boucle de vérification peut créer un faux sentiment de contrôle.

Matrice de décision pour le placement de pile privée

Il existe trois options de placement sensées. Tout d’abord, exécutez localement un modèle ouvert orienté vers la preuve pour des tâches sensibles restreintes avec des contrôles de réussite ou d’échec clairs. Deuxièmement, utilisez-le comme spécialiste du raisonnement en plus d’un modèle général, dans lequel il rédige des artefacts que les vérificateurs et les humains inspectent. Troisièmement, conservez le modèle général et améliorez les contrôleurs externes sans encore ajouter de nouveau modèle.

Le déploiement privé ou local peut être intéressant pour les charges de travail sensibles, mais il ne supprime pas les contrôles de sécurité, la vérification des accès, la surveillance, les tests ou l'évaluation par l'équipe rouge. Les modèles locaux peuvent toujours fuir via des journaux, des autorisations faibles, une injection rapide, une mauvaise gestion des données ou de mauvaises habitudes opérationnelles.

json { "model_category": "proof_oriented_reasoning_model", "candidate_model": "Leanstral 1.5", "best_initial_use_cases": ["assistance à la preuve formelle", "code avec tests", "règles métier vérifiées par le schéma"], "verifier_types": ["Lean 4", "unit_tests", "type_checks", "static_analysis", "policy_rules", "data_validators"], "risk_level": "medium_until_task_special_evaluation_passes", "go_no_go_criteria": ["la couverture du vérificateur est connue", "le comportement de réparation est mesuré", "le seuil d'examen humain est défini", "un chemin de repli existe"] }## Liste de contrôle de mise en œuvre et plan de mesure

Commencez petit. Définissez une limite de tâche, un vérificateur et un ensemble d'évaluation avant de discuter d'un déploiement à grande échelle. Préparez des invites représentatives, les résultats attendus et des exemples d’échec. Enregistrez la réponse, l'artefact, le résultat du vérificateur, les tentatives de réparation, la latence et les notes d'examen humain.

Exécutez un LLM général de base, un modèle local plus petit si nécessaire et un flux de travail réservé aux vérificateurs lorsque cela est possible. Testez ensuite Leanstral 1.5 avec le même ensemble. Comparez la qualité du premier passage et la qualité de sortie réparée. Un modèle qui nécessite trois boucles de réparation pour les cas faciles peut être trop coûteux à exploiter, même s'il finit par réussir.

Incluez des invites contradictoires et de cas extrêmes : entrées mal formées, instructions ambiguës, contexte manquant, tentatives de contournement du vérificateur et cas où la réponse correcte est de refuser ou de faire remonter la situation. Enregistrez la gravité des échecs, et pas seulement le nombre d’échecs. Une preuve invalide grave peut avoir plus d’importance que plusieurs erreurs de formatage inoffensives.

La surveillance de la production doit suivre le taux d'échec des vérificateurs, la dérive dans la répartition des tâches, les boucles de réparation répétées, les taux d'expiration, les raisons de remplacement humain, l'obsolescence du cache et les résultats de l'examen des incidents. Définissez des règles de restauration avant le lancement. Si le vérificateur échoue à plusieurs reprises, le système ne devrait pas se contenter de faire confiance au modèle.

Pour les équipes évaluant cette catégorie, le rôle d'Optijara est d'aider à concevoir des plates-formes d'évaluation pratiques, des boucles de vérification et des plans de déploiement privés autour de contraintes réelles. Cela signifie choisir la tâche, définir le vérificateur, comparer les lignes de base, mesurer le comportement de réparation et décider où l'examen humain reste dans la boucle.

Erreurs courantes

La première erreur consiste à traiter les traces de raisonnement comme une vérité terrain. Corrigez-le en exigeant des artefacts vérifiables et une validation externe.

La seconde consiste à tester uniquement les tâches du classement. Corrigez-le en créant un ensemble interne à partir du travail que le système verra réellement.

La troisième consiste à ignorer l’examen de la formalisation. Corrigez-le en demandant à un propriétaire de domaine de vérifier si l'instruction formelle, le schéma, le test ou la règle correspond au problème d'origine.

La quatrième consiste à laisser les tentatives masquer un raisonnement faible. Corrigez-le en mesurant le nombre de réparations, les modèles de défaillances répétées et la charge totale de révision.

La cinquième consiste à déployer avant que les chemins de secours ne soient définis. Corrigez-le en décidant à l'avance quand le système réessaiera, escaladera, changera de modèle ou s'arrêtera.