Comment loqy évalue les modèles IA locaux pour le travail réel

Un modèle peut obtenir un excellent score de raisonnement et rester pénible à utiliser. Il peut rédiger une réponse impressionnante, puis inventer une source. Il peut comprendre un document de vingt pages, mais perdre une contrainte au troisième appel d’outil. Il peut fonctionner vite sur une machine de laboratoire et saturer la mémoire d’un Mac utilisé pour travailler.

Le mot système est important. Le modèle n’est qu’un élément parmi l’artefact exact téléchargé, sa quantification, son moteur d’inférence, le gabarit de conversation, le contexte disponible, les outils exposés, la mémoire du Mac et les contrôles appliqués au résultat. La carte d’exécution de loqy situe chacun de ces composants.

Le test commence par un travail réel

Prenons un cas de qualification concret. Le dossier contient une note budgétaire de douze pages, un export CSV de 240 lignes et une note de cadrage en français. Trois anomalies y ont été introduites : une dépense dupliquée, un taux appliqué à la mauvaise base et une hypothèse devenue périmée. La mission demande de les retrouver, de refaire les calculs, de vérifier deux informations publiques dans un environnement simulé, puis de livrer une note de décision et un tableau corrigé.

Le dossier inclut aussi un incident volontaire. Un premier chemin de fichier n’existe pas. Le modèle doit lire l’erreur, retrouver le bon fichier dans le périmètre autorisé et poursuivre sans inventer le contenu manquant. Cette étape paraît secondaire. Elle révèle pourtant mieux la solidité d’une boucle agentique qu’une réponse parfaite à une question isolée.

Pour réussir, le modèle doit enchaîner plusieurs capacités :

• comprendre une demande formulée dans un langage professionnel ;
• conserver les contraintes au fil d’une exécution longue ;
• choisir l’outil adapté sans en inventer un autre ;
• produire des arguments valides pour cet outil ;
• utiliser le résultat sans le déformer ;
• distinguer un fait, une hypothèse et une donnée manquante ;
• citer l’origine d’une affirmation importante ;
• préparer un fichier que la personne peut relire et réutiliser.

Les benchmarks de connaissances et de code mesurent certaines de ces capacités. Le scénario produit observe leur enchaînement dans une boucle complète.

La qualification loqy part de scénarios de travail versionnés. Les mêmes entrées, contraintes et critères sont présentés à chaque configuration. Les effets extérieurs sont simulés. Les sorties sont évaluées sur des critères observables.

Pour ce cas, la grille est fixée avant l’exécution :

Les vérifications déterministes traitent les fichiers, les calculs, les schémas d’outils et les citations connues. Une appréciation humaine calibrée intervient pour le registre, la clarté et la pertinence de la synthèse. La configuration doit réussir ces deux niveaux.

Une évaluation à plusieurs portes

loqy traite la qualification comme une série de portes obligatoires. Chaque porte produit soit une preuve admise, soit un motif de rejet exploitable : entrée non figée, artefact non conforme, boucle d’outils invalide, livrable défectueux ou enveloppe matérielle instable.

1. Identité et provenance

La configuration fixe le dépôt, la révision, le fichier, la taille, l’empreinte cryptographique, la licence, la quantification et, pour la vision, le projecteur associé. Un fichier différent peut modifier la qualité, la mémoire nécessaire ou même le protocole attendu.

Dans loqy, un résultat appartient à un couple précis entre artefact et moteur. Une nouvelle conversion reçoit sa propre qualification.

2. Travail bilingue et ancrage dans les sources

Les scénarios utilisent le français, l’anglais et des documents mixtes. Ils contiennent des dates, des montants, des tableaux, des formulations ambiguës et du vocabulaire professionnel. La qualité couvre le sens, le registre, les nombres et les réserves, en plus de la grammaire.

L’ancrage est une porte séparée. Les éléments importants d’une réponse doivent être retrouvables. Pour un rapport ou une revue documentaire, une citation correcte compte davantage que l’assurance du ton.

3. Boucle d’outils

Un agent a besoin d’un modèle capable de choisir parmi un ensemble fermé d’outils, de respecter leur schéma et de réagir à un résultat borné. Face à « fichier introuvable », une boucle robuste interprète l’erreur, répare le chemin et s’arrête lorsque l’autorité ou l’information manque.

Les tests observent donc la validité des appels, la récupération après erreur, le nombre de réparations, l’absence d’outil imaginaire et la capacité à s’arrêter lorsque l’autorité ou l’information manque. Un appel bien formé n’est pas encore une bonne décision. Le modèle peut proposer une action, mais la politique et les permissions restent appliquées en dehors de lui.

4. Livrable et preuve

Le résultat associe la réponse dans la conversation au rapport, à la feuille de calcul ou à la modification de code. Le fichier doit être valide dans son format, conserver ses entrées et rendre ses transformations inspectables. loqy vérifie directement le fichier produit.

5. Matériel et expérience

Enfin, une configuration doit fonctionner sur un vrai Mac pris en charge. Le temps avant le premier jeton, le débit de génération, la mémoire résidente, la pression mémoire, la température, la consommation et la réactivité du reste de l’application font partie de la qualité.

Une amélioration produit exige à la fois un meilleur résultat et un Mac qui reste utilisable.

Le catalogue couvre plusieurs enveloppes

Le catalogue V1 décrit quatre profils locaux exacts pour des enveloppes de mémoire différentes. Chaque résultat reste attaché au fichier réellement livré.

Les tailles sont celles des artefacts du manifeste, en gigaoctets décimaux. L’espace de téléchargement présenté à l’utilisateur additionne les poids et le projecteur, soit environ 3,41, 6,62, 15,44 et 24,41 Go. La révision source, le nombre d’octets et l’empreinte SHA-256 complètent l’identité de chaque fichier.

L’accès aux images est activé lorsque l’exécution possède un bail de modèle qui l’autorise, un projecteur qualifié et une source validée.

Qwen 3.5 4B est le profil placé en premier dans le catalogue et recommandé au démarrage sur les Mac compatibles. Les modèles plus grands restent sélectionnables par l’utilisateur lorsque la mémoire du Mac rend leur profil éligible.

Le profil de lancement réserve la capacité technique du moteur pour un modèle et un palier de mémoire précis. Le contexte réellement confié à une exécution est de 16 384 jetons en mode Standard, 32 768 en mode Étendu et jusqu’à 65 536 en mode Profond lorsque le modèle, le profil et le Mac le permettent.

Cette marge absorbe les sorties, la boucle d’outils, les résumés et les réserves de sécurité. Un contexte de 256K annoncé par un modèle ou inscrit dans un profil de lancement ne devient donc pas automatiquement une invite de 256K. Le moteur, le cache, les outils et le reste de l’application doivent encore tenir ensemble.

Le matériel fait partie de la configuration

Les mesures utiles couvrent le démarrage, le premier jeton, le débit stabilisé et le scénario complet. Elles observent aussi la mémoire, la température et la libération des ressources.

La méthode de loqy sépare donc plusieurs temps :

• le chargement à froid du modèle ;
• le temps avant le premier jeton ;
• le débit une fois la génération commencée ;
• le temps total pour terminer le scénario ;
• la mémoire de pointe et l’état thermique ;
• la capacité à libérer proprement les ressources après usage.

Les candidats de réglage sont testés après échauffement avec au moins trois répétitions. La médiane évite qu’un passage exceptionnel domine la décision. Une variation trop forte invalide la mesure. Une optimisation n’est promue que si le résultat reste correct, les appels d’outils restent valides, la mémoire conserve une réserve et l’état thermique ne se dégrade pas.

Le débit exprimé en jetons par seconde compte lorsque l’ensemble du travail devient plus rapide et reste fiable.

La configuration testée est plus grande que le modèle

Deux installations du même modèle peuvent se comporter différemment. La quantification modifie la taille et parfois la fidélité. Un gabarit de conversation mal adapté peut casser les appels d’outils. Un moteur différent peut interpréter autrement le cache ou la vision. Un budget de contexte trop ambitieux peut provoquer une pression mémoire que le benchmark d’origine n’a jamais rencontrée.

loqy fixe donc l’unité de qualification comme une chaîne :

artefact exact + projecteur + moteur + paramètres + contrat de contexte + schémas d’outils + classe de matériel

Le Core conserve cette identité dans un bail immuable pour chaque exécution. Changer de modèle au milieu d’une génération rendrait l’attribution et la reprise ambiguës. Le changement prend effet sur une nouvelle exécution, avec un contexte reconstruit pour le nouveau moteur.

Cette règle facilite aussi les comparaisons. Si une sortie régresse, il devient possible de savoir si le modèle, le moteur d’inférence, le contexte ou le réglage a changé et de reproduire la configuration.

Les benchmarks publics restent utiles

Les benchmarks cartographient les forces et servent à sélectionner les tests produit à mener. Un bon résultat sur Terminal-Bench indique une capacité agentique intéressante. LongBench ou MRCR donnent un signal sur le contexte. Une évaluation multilingue révèle une faiblesse probable.

Un benchmark public est une observation située. Il dépend de la consigne, du protocole d’évaluation, du niveau de raisonnement, du nombre d’essais et parfois d’un modèle utilisé comme juge. La comparaison des coûts locaux et hébergés applique le même périmètre explicite aux prix, vitesses et scores publiés.

loqy combine donc trois niveaux :

1. signaux publics, pour comprendre le paysage et repérer les candidats ;
2. suites produit, pour tester les tâches, langues et outils réellement utilisés ;
3. qualification intégrée, pour vérifier le comportement dans l’application et sur le matériel cible.

La qualification exige la réussite aux trois niveaux.

Adapter un modèle seulement pour répondre à un écart mesuré

La V1 livre le catalogue actuel. Cette partie décrit une méthode pour une éventuelle recherche ultérieure sur l’adaptation de modèles.

Un modèle adapté à loqy pourrait mieux respecter un schéma d’outil, citer plus régulièrement ses sources ou rédiger un français professionnel plus stable. Ces objectifs se prêtent à une mesure précise, surtout pour un modèle de 3 à 4 milliards de paramètres.

Une telle étude commencerait par une comparaison entre trois bras : le modèle de base, le meilleur système de contexte et d’instructions sans entraînement, puis le modèle adapté. Les mêmes scénarios et graines seraient utilisés. L’adaptation ne serait retenue que si elle améliorait les axes visés de manière mesurable sans dégrader les capacités générales, la sécurité ou la transparence.

Les données d’entraînement devraient avoir une provenance explicite. Les contenus synthétiques, ouverts ou autorisés seraient séparés des données privées. Les conversations, documents clients, diagnostics et mémoires ne deviendraient pas un corpus d’entraînement par défaut. Une sortie d’un modèle enseignant ne serait utilisable que si ses conditions le permettaient.

L’entraînement serait retenu uniquement si les gains mesurés dépassaient son coût et sa maintenance. Une meilleure structure de contexte ou un outil plus clair resterait préférable lorsqu’il résout l’écart.

Ce que l’utilisateur doit pouvoir comprendre

Cette infrastructure produit des choix simples : quels modèles sont disponibles sur ce Mac, quelle place ils occupent, ce qu’ils savent traiter, lequel est sélectionné et pourquoi une configuration est indisponible.

L’utilisateur peut choisir un autre modèle éligible. Le catalogue réduit l’espace des options à des configurations connues et reproductibles, puis laisse la personne arbitrer entre vitesse, capacité et consommation.

C’est la différence entre intégrer un modèle et livrer une fonction. Le premier peut répondre à une requête. La seconde doit rester fiable lorsque le document est long, que l’outil échoue, que la langue change et que le Mac fait autre chose en même temps.

loqy évalue les modèles locaux à ce niveau-là : dans la boucle entière du travail, jusqu’au livrable et à ses preuves. La chaîne de preuves explique ensuite ce qui doit rester attaché au résultat.

Sources et méthode

• loqy, architecture d’inférence locale et catalogue exact
• loqy, planification du contexte et modes réellement accordés
• loqy, étude d’adaptation d’un petit modèle
• loqy, architecture de l’Evaluation Lab
• Qwen 3.5 4B, modèle source
• Ornith 1.0 9B, paquet GGUF sélectionné
• Gemma 4 26B-A4B, paquet GGUF sélectionné
• Ornith 1.0 35B, paquet GGUF sélectionné
• Stanford CRFM, HELM et l’évaluation holistique des modèles