De nouveaux modèles d’IA, plus performants et moins coûteux, ne cessent d’arriver. Le modèle qui était pertinent au moment de la publication de votre application peut ne plus être le meilleur choix quelques semaines plus tard. Mais si l’identifiant de ce modèle est intégré dans une application iOS publiée ou un serveur déployé, chaque mise à niveau devient une nouvelle version à publier. Comment maintenir l’application à jour alors que les utilisateurs disposent encore d’anciennes versions ? Haimaker vous permet de mettre à jour les modèles utilisés par votre application sans la redéployer. Envoyez haimaker/auto comme identifiant de modèle, puis modifiez le modèle par défaut ou les règles spécifiques aux prompts dans le tableau de bord.
Ce problème se répète à chaque sortie de modèle. Les développeurs doivent tester la qualité, le coût et les capacités par rapport à leur charge de travail. Garder le choix du modèle en dehors du code déployé leur permet d’exploiter ces résultats sans planifier une nouvelle release applicative ou serveur.
Un identifiant de modèle fixe devient obsolète après la publication
Un identifiant de modèle fixe fait dépendre chaque mise à niveau de modèle du processus de release de l’application. Cela reste gérable pendant le développement de la première version. Après le lancement, chaque nouveau modèle prometteur ou changement de tarif peut impliquer de modifier le code, exécuter des tests, déployer des serveurs ou soumettre une mise à jour mobile. De nouveaux modèles peuvent arriver entre deux versions de l’application.
Pour une application iOS, un identifiant de modèle intégré dans le client ne peut pas changer pour les utilisateurs qui n’ont pas installé de mise à jour. Apple examine les mises à jour avant distribution, et les utilisateurs peuvent conserver d’anciennes versions bien après la disponibilité d’un nouveau build. Déplacer l’appel API vers votre backend évite d’exposer une clé fournisseur dans l’app, mais un identifiant de modèle codé en dur sur ce backend nécessite tout de même un changement de configuration ou un déploiement.
Une simple passerelle (gateway) ne résout pas le problème. Si une requête nomme un modèle fixe, l’appelant reste lié à ce choix. OpenRouter, par exemple, prend en charge les modèles nommés ainsi que son propre routeur openrouter/auto. Un auto-routeur permet de garder le choix du modèle sous-jacent en dehors du code déployé. Haimaker vous permet d’ajuster la politique de routage pour vos propres classes de prompts après la publication de l’application.
Comment une application déployée peut-elle suivre les nouveaux modèles ?
Envoyez un identifiant de modèle stable depuis l’application et conservez la politique de sélection dans Haimaker. Un routeur possède un modèle par défaut pour les requêtes sans correspondance et des règles qui redirigent certains types de prompts vers d’autres modèles. Le routeur est assigné à une clé API. Lorsque vous modifiez ses cibles, les requêtes suivantes peuvent atteindre différents modèles même si l’appelant déployé continue d’envoyer haimaker/auto.
Pour un produit mobile, l’application doit appeler votre backend, et le backend doit appeler Haimaker. Ainsi, la clé API reste hors des appareils des utilisateurs. Une application serveur peut utiliser le même schéma directement : son code de requête reste en place tandis qu’un opérateur ajuste le routeur. La documentation de configuration montre comment créer un routeur, choisir un modèle par défaut, assigner une clé API et tester les requêtes.
import OpenAI from "openai";
// Run this on your backend; do not bundle the API key in a mobile app.
const client = new OpenAI({
baseURL: "https://api.haimaker.ai/v1",
apiKey: process.env.HAIMAKER_API_KEY,
});
const response = await client.chat.completions.create({
model: "haimaker/auto",
messages: [{ role: "user", content: prompt }],
});
Le code ci-dessus n’a pas besoin d’un nouveau nom de modèle lorsque le modèle par défaut change. Haimaker met en cache les configurations de routeur pendant jusqu’à 60 secondes, prévoyez donc une minute pour qu’une modification du tableau de bord atteigne toutes les requêtes suivantes.
Mettez à jour le modèle par défaut, puis routez les tâches moins coûteuses séparément
Changer le modèle par défaut met à niveau l’ensemble de la charge de travail. Les règles vous permettent d’effectuer des modifications plus ciblées lorsqu’un nouveau modèle est moins cher ou meilleur pour une tâche précise. Cette distinction est importante : une application peut avoir besoin d’un modèle par défaut performant pour l’édition de textes longs tout en envoyant les suggestions de titres courts vers un modèle à moindre coût. Les deux décisions peuvent changer après la publication sans modifier l’identifiant de modèle de l’appelant.
Imaginez une application d’écriture dont le backend envoie chaque requête IA via le même routeur. Un modèle récemment publié produit de meilleures éditions de textes longs ; l’équipe le teste donc et modifie le modèle par défaut du routeur. Plus tard, un modèle moins cher gère suffisamment bien les suggestions de titres. L’équipe ajoute une règle avec des exemples tels que « Suggère cinq titres courts pour cette note » et « Donne un titre concis à ce brouillon », puis dirige cette règle vers le modèle moins cher. Les utilisateurs sur d’anciennes versions de l’app bénéficient des deux modifications via le backend existant.
Pour les règles basées sur des exemples, utilisez 3 à 10 prompts représentatifs par tâche. En cas de correspondance, la requête est redirigée vers la cible de la règle ; les requêtes sans correspondance utilisent le modèle par défaut. Les vérifications de capacité empêchent une règle d’envoyer une requête de vision, d’utilisation d’outils ou de sortie structurée vers un modèle qui ne peut pas la traiter. Les journaux de routage affichent le modèle résolu et la règle qui l’a sélectionné. Pour les mécanismes de correspondance et de repli, consultez notre guide détaillé du routage et notre guide de routage par coût.
Qu’est-ce que cela change pour une équipe après le lancement ?
Le principal avantage est que la sélection du modèle peut suivre la charge de travail plutôt que le calendrier des releases. Une équipe peut adopter un nouveau modèle par défaut, déplacer une classe de prompts répétitifs vers un modèle moins cher, ou restaurer une cible précédente si les résultats se dégradent. Le code serveur et les clients mobiles installés continuent d’effectuer la même requête API. L’effort se concentre dès lors sur le test et l’examen de la décision de routage.
| Changement après le lancement | Avec un modèle fixe dans le code | Avec haimaker/auto |
|---|---|---|
| Un meilleur modèle général arrive | Modifier l’identifiant de modèle et publier le code ou la config | Le tester, puis changer le modèle par défaut du routeur |
| Un modèle moins cher convient à une classe de prompts | Ajouter une logique de routage applicative et la déployer | Ajouter ou modifier une règle pour cette classe de prompts |
| Un changement de modèle dégrade la qualité | Annuler le changement de code ou de config | Restaurer la cible précédente du routeur |
| Les utilisateurs utilisent encore un ancien build mobile | L’identifiant de modèle intégré reste ancien | Le backend peut utiliser la politique de routage actuelle |
Cela aide également lorsque des releases serveur ont d’autres travaux en attente, sans lien avec le modèle. Une décision de modèle n’a pas à attendre cette fenêtre de déploiement. Des charges de travail séparées peuvent utiliser des routeurs distincts en les assignant à différentes clés API ; Haimaker prend en charge un routeur par clé.
Les changements de routage nécessitent tout de même le même jugement que les changements de code. Le bac à sable du tableau de bord montre quel modèle un prompt sélectionnerait, mais il ne prouve pas que la réponse est bonne. Exécutez des prompts représentatifs sur le modèle proposé, inspectez la sortie réelle, surveillez les journaux de modèle résolu, et revenez à la cible précédente si la qualité baisse. Haimaker change la sélection du modèle ; modifier les prompts, les schémas d’outils ou le comportement applicatif nécessite toujours une intervention côté application.
Préparez le choix du modèle pour la prochaine release
Créez un routeur, choisissez un modèle par défaut et assignez-le à la clé API utilisée par votre backend. Envoyez haimaker/auto dans la requête, puis testez quelques prompts représentatifs de la charge de travail. Lorsqu’un nouveau modèle arrive, évaluez-le sur ces prompts avant de changer le modèle par défaut ou une règle ciblée. La documentation Haimaker couvre la configuration du routeur, le bac à sable de test et l’historique de routage.
De nouveaux modèles peuvent arriver avant votre prochaine release d’application. Garder le choix du modèle dans Haimaker permet à l’application de rester à jour pendant que les développeurs consacrent leurs cycles de release aux changements qui nécessitent du nouveau code, plutôt qu’à la sélection du modèle.
Questions fréquemment posées
Comment puis-je changer le modèle d’IA dans une application mobile publiée ?
Faites en sorte que l’application appelle votre backend et que celui-ci envoie model: ‘haimaker/auto’ à Haimaker. Vous pouvez ensuite modifier le modèle par défaut du routeur ou les règles de prompts dans le tableau de bord sans soumettre un nouveau build mobile. Les modifications du routeur peuvent prendre jusqu’à 60 secondes avant de prendre effet.
Le changement de modèle via Haimaker nécessite-t-il un déploiement serveur ?
Non. Si le serveur déployé envoie déjà model: ‘haimaker/auto’ avec une clé API assignée à un routeur, vous pouvez modifier les cibles de modèles du routeur dans le tableau de bord. Les modifications des prompts applicatifs, des formats de requête ou du code nécessitent toujours le déploiement habituel.
Puis-je rediriger uniquement les prompts simples vers un modèle moins cher ?
Oui. Ajoutez une règle avec 3 à 10 prompts d’exemple pour une tâche simple et sélectionnez un modèle cible moins cher. Haimaker vérifie que la cible prend en charge la requête, tandis que les prompts qui ne correspondent à aucune règle utilisent le modèle par défaut du routeur.