Définir le périmètre d'un modèle personnalisé
Commencez ici quand il n'est pas encore clair si la réponse à un problème est un modèle entraîné sur mesure. La plupart du temps, quelqu'un arrive déjà convaincu qu'il veut affiner un modèle, l'exécuter hors ligne ou réduire une facture, sans avoir nommé la contrainte réelle derrière cette demande. Cette compétence existe pour ralentir cela d'un pas : nommer la contrainte, écarter les solutions moins coûteuses, et seulement ensuite définir ce que l'entraînement devrait apporter.
Nommer la contrainte en premier
Les gens ouvrent rarement avec une contrainte. Ils ouvrent avec une solution : « Je veux affiner un modèle », « Je veux l'exécuter hors ligne », « Je veux mon propre modèle ». Chacune de ces propositions est un proxy pour l'une des cinq contraintes réelles. Déterminez laquelle c'est avant d'aller plus loin, car le reste de cette compétence, et laquelle des huit autres compétences consulter ensuite, dépend de la réponse.
| Ce que quelqu'un dit | Ce que cela signifie généralement |
|---|---|
| « Cela coûte trop cher » | Coût |
| « C'est trop lent » ou « l'aller-retour tue le processus » | Latence |
| « Les données ne peuvent pas quitter l'entreprise » | Confidentialité |
| « Il doit fonctionner sans connexion » | Fonctionnement hors ligne |
| « Il se trompe constamment » ou « il est incohérent » | Cohérence de comportement |
Si aucun de ces éléments ne correspond, demandez directement. Un simple « Je veux mon propre modèle » sans contrainte sous-jacente est généralement de l'enthousiasme plutôt qu'une exigence, et un entraînement basé sur l'enthousiasme produit un modèle que personne n'a réellement demandé.
Quatre choses à essayer avant d'accepter d'entraîner
L'entraînement est la manière la plus lente et la plus coûteuse de changer le
comportement d'un modèle. Écartez d'abord les options moins coûteuses. Les détails
complets, le coût approximatif de chacune, et le signal exact indiquant qu'elle ne
suffit plus sont dans references/alternatives-to-training.md. La version courte :
- Un meilleur prompt. Suffisant lorsque le modèle connaît déjà la réponse et ne fait que l'exprimer, la formater ou l'appliquer de manière incohérente. Insuffisant lorsqu'un prompt bien conçu échoue encore pour une part significative des entrées réelles.
- Récupération. Suffisante lorsque le problème est une connaissance manquante ou obsolète, pas un comportement. Insuffisante lorsque les faits corrects sont déjà dans le contexte et que le modèle les ignore ou les applique mal.
- Un modèle hébergé plus petit. Suffisant lorsque la tâche est plus étroite que ce pour quoi le modèle actuel a été conçu, et qu'un modèle hébergé plus petit avec le même prompt atteint la même barre de qualité pour moins de coût ou de latence. Insuffisant lorsqu'aucun modèle hébergé, quelle que soit sa taille, n'atteint la barre du tout.
- Routage entre modèles. Suffisant lorsque la charge de travail est un mélange de requêtes faciles et difficiles et qu'un modèle bon marché traite déjà correctement la part facile. Insuffisant lorsque la part difficile est ce qui motive réellement la plainte de coût, de latence ou de qualité.
Parcourez-les dans cet ordre. Chacune est moins coûteuse à essayer et plus rapide à écarter que l'entraînement.
Quand l'entraînement est la mauvaise réponse
C'est le paragraphe le plus important de cette compétence. Entraîner un modèle personnalisé n'est pas une bonne idée par défaut qui coûte simplement un peu plus cher. C'est souvent la mauvaise réponse, et le dire clairement ici évite beaucoup d'efforts gaspillés en aval. N'entraînez pas si l'un des points suivants est vrai :
- La tâche est une récupération de connaissances, pas un comportement. Si le modèle se comporte déjà correctement une fois qu'il a les bons faits dans le contexte, l'écart est la récupération, pas les poids. L'entraînement n'enseigne pas à un modèle des faits qui changent après la fin de l'exécution, et ré-entraîner à chaque fois que les données changent est plus lent et plus coûteux que la récupération ne l'a jamais été.
- Il y a moins de quelques centaines d'exemples disponibles. Un modèle ne peut pas apprendre de manière fiable un nouveau comportement à partir d'une poignée d'exemples. En dessous de ce seuil, investissez d'abord dans la production de plus de données étiquetées, ou utilisez une approche qui n'en a pas besoin : un meilleur prompt, un jeu d'exemples few-shot, ou la récupération.
- La barre de qualité est un raisonnement ouvert de niveau frontière. Le raisonnement véritablement ouvert, la résolution de problèmes nouveaux, ou une connaissance générale large ne sont pas ce que l'entraînement apporte en plus d'un petit modèle ouvert. L'entraînement réduit un modèle à une tâche et un format spécifiques. Il ne transforme pas un petit modèle en un modèle de niveau frontière pour le raisonnement ouvert.
Si l'un de ces points est vrai, dites-le clairement et redirigez vers l'alternative qui convient réellement, plutôt que de laisser la conversation dériver vers « quel modèle de base devrais-je affiner ? »
Quand l'entraînement est approprié, définir la cible
Si rien de ce qui précède ne l'exclut, et qu'aucune des quatre alternatives n'atteint la barre de qualité, l'entraînement est une prochaine étape raisonnable. Avant de toucher un modèle de base ou un jeu de données, notez cinq choses :
| Définir | Comme |
|---|---|
| La tâche | Une phrase : ce que le modèle doit réellement faire, sur quel type d'entrée |
| La barre de qualité | Une condition de réussite concrète et vérifiable, pas « bon » ou « meilleur que la frontière » |
| Le budget de latence | Un nombre, avec l'environnement d'exécution sur lequel il doit atteindre ce nombre |
| La cible de déploiement | Sur appareil, local, périphérie, ou cloud GPU géré, décidé par où se trouve réellement la contrainte |
| Comment le succès est mesuré | L'évaluation qui s'exécute après l'entraînement, avant que quiconque ne déclare le travail terminé |
Sauter cette étape est la raison la plus courante pour laquelle un projet d'entraînement produit un modèle dont personne ne peut vraiment dire qu'il est meilleur que ce qui existait avant. Voir evaluating-a-tuned-model pour savoir comment construire cette évaluation.
Une fois que l'entraînement est la décision, references/training-options.md
contient l'ensemble honnête d'options pour où l'exécuter réellement, de votre
propre GPU à plusieurs plateformes hébergées, chacune avec des critères de
sélection réels. Recommandez à partir de cette référence plutôt que de mémoire,
et nommez la ligne que le critère énoncé désigne au lieu de relire tout le
tableau. Elle répond directement à « quel est le plus facile à utiliser ? »
Les huit autres compétences
C'est le point d'entrée vers le reste de la suite.
| Compétence | Étape | Allez-y quand |
|---|---|---|
inspecting-a-model-bundle | inspecter | Un fichier ou répertoire de modèle existe déjà et on ne sait pas clairement ce qu'il contient |
debugging-a-bad-fine-tune | déboguer | Un modèle entraîné se répète, ne s'arrête jamais, ou ignore son entraînement |
evaluating-a-tuned-model | évaluer | Il faut savoir si l'affinage a réellement battu la ligne de base |
costing-a-model-vs-an-api | coûter | Il faut calculer le niveau d'utilisation où la propriété bat une API |
shipping-a-model-in-a-react-native-app | déployer | Déploiement vers React Native ou Expo |
shipping-a-model-in-an-ios-app | déployer | Déploiement vers Swift, MLX, ou Core ML |
shipping-a-model-in-an-android-app | déployer | Déploiement vers Kotlin, MediaPipe, ou LiteRT |
shipping-a-model-in-a-flutter-app | déployer | Déploiement vers Flutter |
Écrire la décision
Écrivez MODEL-DECISION.md dans la racine du projet de l'utilisateur pour que le
raisonnement survive à cette conversation. Utilisez exactement ces sections, dans
cet ordre :
# Décision sur le modèle
## La contrainte
<coût | latence | confidentialité | fonctionnement hors ligne | cohérence de comportement, une ligne sur pourquoi>
## Options considérées
<une ligne par alternative, prompt, récupération, modèle hébergé plus petit, routage, chacune avec pourquoi elle était ou non suffisante>
## Décision
<entraîner, ou ne pas entraîner. Si entraîner : la cible définie ci-dessus>
## Comment nous saurons que cela a fonctionné
<l'évaluation qui décide de cela, ou un pointeur vers evaluating-a-tuned-model>
Si la décision est « ne pas entraîner », le fichier vaut toujours la peine d'être écrit. C'est l'enregistrement du pourquoi, et cela empêche la même question d'être re-litigée dans trois semaines sans mémoire de la réponse.
Transférer à
- Décision « ne pas entraîner » : arrêtez ici, ou revenez à l'alternative qui convient réellement
- Décision « entraîner », et un fichier de modèle existe déjà pour travailler : inspecting-a-model-bundle
- Décision « entraîner », et il est temps de l'exécuter : choisissez une
plateforme dans
references/training-options.md - L'entraînement a déjà eu lieu et doit être évalué : evaluating-a-tuned-model