Expertise · Modèles IA personnalisés
Le travail comporte quatre parties : nous mesurons les modèles candidats sur vos données, nous choisissons entre configuration, recherche dans les documents et réglage fin, nous vérifions les droits d’utilisation des données, puis nous plaçons la consommation sous un budget par clé. Nous n’avons encore entraîné aucun modèle en production et nous le disons avant que vous ne posiez la question.
Déjà construitLa partie de mesure et d’exploitation est construite et exécutée, avec des résultats conservés : un banc d’essai propre qui a comparé huit systèmes de reconnaissance vocale sur les mêmes 200 énoncés roumains, avec intervalle de confiance et différences par paires, plus une décomposition de la latence vocale en six segments qui s’additionnent au total avec un écart inférieur à une milliseconde. La partie d’exploitation est une passerelle propre avec 44 modèles configurés, des clés par projet avec liste blanche de modèles et budget, et une consolidation quotidienne de la consommation par utilisateur × clé × modèle. La partie que nous N’AVONS PAS faite — l’ajustement fin proprement dit — est écrite comme telle : le pipeline est préparé et chiffré, mais il n’a jamais tourné sur GPU. Le service reste « livré » parce que le travail que nous vendons est le choix informé et l’exploitation, pas l’entraînement.
La plupart des projets de « modèle personnalisé » n’ont pas besoin d’un modèle entraîné. Ils ont besoin du bon modèle, avec la bonne instruction, sur les bonnes données, avec un coût par appel que quelqu’un suit. Le travail commence par la question que peu de gens posent : à quoi ressemble le succès, mesuré comment, sur quel ensemble de cas ? Sans cette réponse, toute comparaison de modèles n’est qu’une discussion de goûts.
Nous mesurons nous-mêmes, nous ne reprenons pas les chiffres des fournisseurs. Quand nous avons eu besoin de savoir ce qui reconnaît le mieux le roumain parlé, nous avons exécuté huit systèmes sur les mêmes 200 énoncés, avec le même normalisateur, avec un intervalle de confiance par bootstrap et des différences calculées par paires. Les résultats étaient gênants : le système que nous utilisions en production avait un taux d’erreur mot à mot de 26,26 %, et un petit modèle de 110 millions de paramètres, exécuté sur processeur, avait 6,83 %. Nous avons aussi publié la partie désagréable — en exactitude sur le roumain, nous perdons largement face aux fournisseurs commerciaux.
La deuxième partie du travail est le choix entre trois voies souvent confondues : la configuration du modèle (instruction, outils, paramètres), la recherche dans vos documents, et le réglage fin. L’ordre dans lequel nous les essayons n’est pas une préférence, c’est une économie : les deux premières sont réversibles en un après-midi, la troisième exige des données, des droits, un GPU et une mesure avant et après. Nous recommandons le réglage fin seulement lorsque nous avons la preuve que les deux premières ne suffisent pas.
La troisième partie, celle qui reste après le lancement : le coût par appel. Les modèles passent par une passerelle propre, où chaque clé a une liste blanche de modèles, un budget et une période. La consommation est consolidée quotidiennement par utilisateur, clé et modèle, ce qui signifie que la question « pourquoi la facture a-t-elle augmenté ce mois-ci » a une réponse ligne par ligne, pas par suppositions.
Ce que cela comprend
Un ensemble de cas tirés de votre réalité, un critère numérique et une méthode de normalisation fixés par écrit. Pour la parole, nous utilisons le taux d’erreur mot à mot avec un normalisateur propre ; pour les réponses textuelles, la conformité au schéma plus une vérification de bon sens plus la similarité avec une réponse de référence. Sans cette étape, le reste du travail ne peut être vérifié par personne.
Les mêmes énoncés, la même machine, un seul modèle chargé à la fois, chacun dans son propre processus. Nous rapportons un intervalle de confiance par bootstrap et des différences par paires, pas seulement la moyenne — parce que deux modèles peuvent avoir des moyennes différentes et pourtant être à égalité statistique. Nous avons eu exactement ce cas : deux systèmes à 66 sur 66 comparaisons par paires, donc à égalité, alors que le tableau des moyennes suggérait un gagnant.
Dans un parcours vocal, nous avons mesuré séparément six segments — la décision de tour, la reconnaissance vocale, la gate, le temps jusqu’au premier texte du modèle, le premier bloc de synthèse, la file d’attente et le transport. La vérification qui compte : la somme des six donne le temps total jusqu’au premier son avec un écart inférieur à une milliseconde sur chaque tour valide. À partir de là, on voit où se trouve le problème : dans le cas mesuré, 68,7 % du temps était l’attente du premier texte du modèle, pas la reconnaissance vocale, qui prenait 2,9 %.
La recherche dans les documents est implémentée et fonctionne : recherche hybride, 70 % sémantique et 30 % correspondance de mots, seuil de similarité 0,70, cinq fragments par question, avec journal par requête qui conserve les scores et les temps. Nous ne proposons le réglage fin qu’avec la preuve que les deux premières voies ne suffisent pas — et avec le budget et les droits sur la table avant, pas après.
Ce n’est pas une formalité, c’est ce qui bloque des projets. Un corpus de 1.746 heures de roumain que nous avions envisagé s’est révélé licencié pour un usage non commercial — donc inutilisable pour un modèle commercial. Un ensemble de 270.946 exemples avait le code sous une licence permissive, mais les données sans aucune licence déclarée. Et la politique d’utilisation d’un fournisseur de voix interdit explicitement d’entraîner un modèle sur sa sortie. Chaque source est vérifiée sur sa propre page, pas sur ce qu’un article écrit.
Gateway propre avec 44 modèles configurés, chacun avec un coût par token et une limite de contexte dans la configuration. La clé de projet a une liste blanche de modèles, un budget et une période, et elle peut être renouvelée en conservant l’historique. La consommation est consolidée chaque jour par utilisateur × clé × modèle. Le routage utilise la stratégie « le moins occupé », deux nouvelles tentatives et un temps maximum de 120 secondes.
Les modèles de type raisonnement produisent des étapes internes que la plateforme de suivi des coûts ne voit pas, mais que le fournisseur facture. Conséquence pratique : le budget brut défini par clé doit être inférieur au plafond souhaité, divisé par un facteur de raisonnement. Si vous ne faites pas cette correction, la clé semble dans le budget et la facture ne l’est pas.
Nous avons une chaîne locale fonctionnelle : reconnaissance vocale avec un modèle de 0,6 milliard de paramètres sur processeur et synthèse vocale avec un modèle de 99 millions de paramètres, également en local. Dans un produit de surveillance radio, la transcription se fait localement, et la variante via gateway existe en parallèle — donc la comparaison entre local et hébergé est faite, pas supposée. Ce qui quitte la machine, c’est du texte, pas de l’audio.
Un banc de régression hebdomadaire sur des cas fixes, qui compare la conformité au schéma, passe un test de bon sens et mesure la similarité avec les réponses de référence. Un modèle qui change sous vous — et il change — se voit dans le tableau, pas dans les réclamations des clients.
À quoi cela ressemble
Les cas viennent de votre réalité, pas d’un jeu de test général. Le critère numérique, la méthode de normalisation et le seuil à partir duquel le résultat est acceptable sont fixés. Nous livrons : le jeu de cas, le critère écrit et le script qui le calcule.
Les modèles candidats s’exécutent sur des données identiques, avec intervalle de confiance. Nous livrons : le tableau avec tous les systèmes testés, y compris ceux rejetés et la raison, plus la commande exacte de reproduction. Un modèle que nous avons rejeté pour le roumain avait un taux d’erreur de 99,69 % parce qu’il glissait vers l’italien — le roumain ne figurait pas parmi ses langues déclarées. Ce résultat est dans le tableau.
Configuration, recherche dans les documents ou réglage fin — avec la raison, le coût et ce qui est perdu en choisissant. Nous livrons : la décision argumentée, plus la mesure qui la soutient. Si la recommandation est « nous n’entraînons rien », nous l’écrivons aussi explicitement.
La clé du projet est émise avec un budget, une période et une liste de modèles autorisés, avec la correction pour les tokens de raisonnement appliquée. Nous livrons : la clé, le tableau de consommation et le seuil à partir duquel quelqu’un reçoit une alerte.
Les mêmes cas, le même critère, sur le modèle en production. Nous livrons : la comparaison avant/après et la liste des modifications avec le motif de chacune. Un banc de régression récurrent détecte les changements de comportement du modèle du fournisseur.
Les données
Les questions que pose toute personne ayant un délégué à la protection des données — posées ici avant qu'il ne les pose.
Un cas
La situation
Nous avions un système de reconnaissance vocale en fonctionnement pour le roumain et une question ouverte : est-ce le meilleur disponible ou seulement le premier que nous avons intégré ? Il n’existait aucune mesure propre, seulement des chiffres publiés par les fournisseurs, mesurés sur d’autres langues et d’autres jeux.
Ce que nous avons construit
Nous avons construit un banc : 200 énoncés roumains issus d’un jeu public, la même graine pour la sélection, 35,1 minutes d’audio, le même normalisateur pour tous les systèmes, intervalle de confiance par bootstrap, différences calculées par paires. Huit systèmes, chacun chargé seul, dans son propre processus, sur la même machine. Nous avons écrit dans le rapport la configuration de la machine et la commande exacte de reproduction.
Ce qui en est sorti
Le système en production affichait un taux d’erreur par mot de 26,26 %. Un modèle de 110 millions de paramètres, exécuté sur processeur avec un modèle de langue à côté, affichait 6,83 %. Un modèle très encensé est sorti à 99,69 %, parce qu’il glissait vers l’italien — le roumain ne figurait pas parmi ses langues déclarées. Et deux systèmes qui semblaient différents d’après la moyenne se sont retrouvés à égalité statistique sur la comparaison par paires. Nous avons publié tout le tableau, y compris la ligne qui contredisait notre choix.
Ce que le cas ne dit pas
La mesure a été faite sur un jeu public de lecture, pas sur de vraies conversations téléphoniques, avec du bruit et des chevauchements. Un bon résultat sur ce jeu ne garantit pas le même résultat au téléphone. C’est pourquoi, pour un client, le banc est reconstruit sur ses enregistrements — sinon nous mesurons autre chose que ce qui l’intéresse.
Questions
Non. Aucun modèle affiné ou entraîné par nous n’est en production et il n’existe aucun point de contrôle enregistré dans nos dépôts. Ce que nous avons : la chaîne d’entraînement écrite jusqu’à la commande exacte de démarrage de la machine GPU, le budget calculé selon trois scénarios, les données préparées et les licences vérifiées — ainsi qu’une liste écrite de ce qui doit être décidé avant la première exécution. Nous préférons dire cela plutôt que de vendre une compétence que nous n’avons pas exercée.
Parce que le travail qui apporte le résultat, dans la plupart des cas, ce n’est pas l’entraînement. C’est savoir quel modèle fait le travail sur vos données, avec quelle latence et à quel coût par appel — et cela exige une mesure que presque personne ne fait. Un exemple de notre travail : une seule valeur par défaut erronée dans une configuration de modèle (une pénalisation de répétition réglée à 1,2 au lieu de 1,0) a coûté 4,3 points de pourcentage d’erreur. Il n’a pas fallu entraîner, mais mesurer.
Commencez presque toujours par la recherche dans les documents. Elle est réversible, se met à jour en modifiant un fichier et peut indiquer la source de la réponse. Le réglage fin change le comportement du modèle de façons que vous ne pouvez pas inspecter, exige des données étiquetées, des droits d’utilisation et une mesure avant et après. Nous recommandons le réglage fin lorsque nous avons la preuve que la première variante ne suffit pas — par exemple, lorsque nous avons montré qu’un modèle hors ligne ne devient pas un modèle en flux uniquement par configuration : en rétrécissant la fenêtre d’attention sans réentraînement, l’erreur est passée de 8,81 % à 22,26 %, puis à 48,95 %.
Non, et aucun fournisseur honnête ne le peut, car la précision dépend de vos données. Ce que nous garantissons, c’est la méthode : nous mesurons sur vos cas, montrons l’intervalle de confiance et disons quand la différence entre deux options n’est pas statistiquement significative. Nous avons eu un cas où un résultat publié par les auteurs d’un modèle ne s’est pas reproduit chez nous — ils rapportaient 20,70 %, nous avons mesuré 26,68 % sur le même modèle. Nous avons écrit que nous ne savions pas pourquoi, au lieu de choisir le chiffre commode.
Cela dépend du chemin choisi et c’est une décision, pas un accident. Via le gateway, la requête arrive au fournisseur du modèle. Si cela n’est pas acceptable, nous avons une chaîne locale fonctionnelle : la reconnaissance vocale et la synthèse vocale exécutées sur votre machine, où seule du texte quitte la machine, jamais l’audio. Dans un produit de surveillance radio, la transcription locale et celle via gateway sont toutes deux implémentées, donc le compromis entre elles peut être montré par des chiffres.
Cela arrive. C’est pourquoi le travail inclut un banc de régression sur des cas fixes, exécuté périodiquement, qui compare la conformité au schéma, passe un test de bon sens et mesure la similarité avec les réponses de référence. Et c’est pourquoi l’intégration passe par le gateway : le modèle change dans un champ, pas par réécriture du code.
La clé du projet a une liste blanche de modèles, un budget et une période, et elle peut être tournée en conservant l’historique. La consommation est consolidée quotidiennement par utilisateur, clé et modèle. Un piège que nous corrigeons dès le départ : les modèles de raisonnement produisent des étapes internes que le système de suivi ne voit pas, mais que le fournisseur facture — donc le budget brut de la clé est fixé plus bas que le plafond souhaité, divisé par un facteur de raisonnement. Qui ne fait pas cette correction voit la clé dans le budget et la facture au-delà.
Parce que « public » et « utilisable commercialement » sont des choses différentes, et la différence se découvre tard et à grands frais. Trois exemples tirés de nos vérifications : un grand corpus de roumain, sous licence non commerciale, donc exclu pour un produit commercial ; un ensemble de centaines de milliers d’exemples avec du code sous licence permissive mais des données sans aucune licence déclarée ; et la politique d’utilisation d’un fournisseur de voix, qui interdit explicitement l’entraînement d’un modèle sur sa sortie. La vérification se fait sur la page de la source, pas sur ce qu’un article répète.
Il n’entraîne pas aujourd’hui de modèles fondamentaux et ne promet pas de modèle propre en production. Il ne garantit pas de pourcentages d’amélioration. Il ne compare pas un modèle à la concurrence sur la base des chiffres publiés par la concurrence — si nous n’avons pas nous-mêmes réalisé la comparaison, nous disons qu’il s’agit d’un chiffre déclaré par eux, pas d’un chiffre mesuré par nous.
26 d'entre elles sont du code et des fichiers de nos dépôts. Nous n'en publions ni le nom ni la ligne : réunies sur une seule page, elles décriraient trop précisément comment sont construits des systèmes qui ne sont pas seulement les nôtres. Nous les parcourons avec vous, dans le dépôt, sur demande — la vérification reste possible, elle se fait simplement lors d'un échange.
Racontez-nous votre processus. Ensemble, nous décidons ce qui vaut la peine d'être construit, ce que nous pouvons connecter et comment nous vérifions le résultat.