Modèles

Modèles dans la console. Rien ne fonctionne dans le produit tant que cette page est vide.

Deux couches : les fournisseurs (un compte quelque part, avec un identifiant) et les modèles (ce que ce fournisseur vous propose).

Si vous partez de zéro, l'ordre qui marche est : ajouter un fournisseur, ajouter un modèle de chat et le placer en tête de la chaîne de chat, ajouter un modèle d'embedding, puis revenir pour le reste.

Ajouter un fournisseur

Ajouter un fournisseur, choisissez-en un, donnez-lui un identifiant. Les clés sont chiffrées au repos.

La plupart des fournisseurs veulent une clé API. Deux sortent du lot :

Google Vertex accepte soit un JSON de compte de service, soit les identifiants de l'environnement lui-même, plus un ID de projet GCP et une région.

Custom désigne n'importe quel point d'accès compatible OpenAI : un modèle auto-hébergé, une passerelle, quelque chose sur votre propre infrastructure. Vous lui donnez une URL.

Testez la connexion avant d'enregistrer. C'est plus rapide que de découvrir que la clé est fausse au moment où un utilisateur le fait pour vous.

Supprimer un fournisseur supprime aussi ses modèles.

Ajouter un modèle

Sous un fournisseur, Ajouter un modèle. Les champs qui comptent :

ID du modèle est l'identifiant propre au fournisseur. Quittez le champ et la tarification, la fenêtre de contexte et le nom se remplissent automatiquement depuis un catalogue public, en ne complétant que ce qui est vide. Vérifiez avant d'enregistrer : le catalogue est bon, pas faisant foi, et un prix faux fausse silencieusement chacun des chiffres de coût sur lesquels vous vous appuierez ensuite.

Fenêtre de contexte pilote la compaction automatique des conversations. Réglez-la correctement, sinon les longues conversations se compactent au mauvais moment.

Mode réflexion : Désactivé (non pris en charge), Optionnel (les utilisateurs ont le bouton), Toujours (le modèle raisonne à chaque requête). C'est ce qui met l'icône de cerveau dans la zone de saisie.

Recherche web intégrée signale un modèle qui sait chercher tout seul, ce qui va de pair avec le réglage « préférer la recherche native du modèle » dans Organisation.

Masqué du sélecteur de chat garde un modèle hors du menu déroulant visible par les utilisateurs. Servez-vous-en pour tout ce qui n'est pas destiné à la conversation.

La tarification est obligatoire. Sans elle, un modèle tourne quand même, et chaque chiffre d'utilisation et de coût qu'il touche est faux par omission.

Les modèles de chat et la chaîne

Les modèles de chat ne se choisissent pas un par un. Vous les ordonnez en une chaîne de trois au maximum, et cet ordre décide de tout :

Le modèle en tête est le modèle par défaut de votre organisation. C'est celui sur lequel démarrent les nouvelles conversations, et c'est celui qu'obtient une requête API qui omet model : les applications qui ne nomment aucun modèle suivent donc ce qui se trouve en première position ici. Voir Le mode passerelle. Il n'y a pas d'interrupteur séparé « définir par défaut » : promouvoir un modèle en tête de chaîne, c'est cet interrupteur.

Sur les crédits, la chaîne se lit de la même façon que partout ailleurs. Chaque modèle porte une étiquette d'usage plutôt qu'un prix, Économique et rapide, Bon rapport prix/performance ou Intelligence maximale, si bien qu'un choix ne dépend jamais d'une grille tarifaire. Vos membres voient une forme plus courte de la même étiquette dans leur propre sélecteur. Le modèle avec lequel votre organisation a été provisionnée est signalé comme le modèle recommandé, pour que vous voyiez toujours de quoi vous vous êtes écarté.

Les modèles en dessous forment le repli. Quand le modèle du dessus échoue, le suivant est essayé, et l'utilisateur apprend quel modèle a réellement répondu au lieu d'être laissé dans le doute.

La chaîne couvre les conversations dans l'application. Les appelants de l'API y souscrivent requête par requête avec enable_fallback, si bien qu'une application qui ne le demande pas voit l'échec. C'est délibéré : un appelant peut préférer une erreur propre à une réponse venue d'un modèle qu'il n'a pas choisi.

Chaque modèle est testé quand vous enregistrez, donc une chaîne incapable de servir est refusée à ce moment-là plutôt qu'au message suivant de quelqu'un.

Cela vaut la peine d'ordonner la chaîne avant d'en avoir besoin : une panne chez un fournisseur devient une dégradation au lieu d'une panne. Placez un modèle d'un fournisseur différent sous celui du dessus, sinon une panne emporte toute la chaîne.

Sur les crédits, cela fonctionne autrement, et mieux. Vos modèles sont joints via une passerelle qui route déjà chacun d'eux sur plusieurs fournisseurs en amont, si bien qu'un fournisseur qui tombe est absorbé avant même que votre chaîne soit consultée. Ce que votre chaîne ajoute par-dessus, c'est une couverture pour le modèle lui-même : mettez une famille de modèles différente en dessous, Gemini sous GPT par exemple, et une mauvaise version ou une panne touchant tout un modèle a quand même où aller.

Trois autres choses à savoir :

Vos utilisateurs sont prévenus quand cela arrive. Une bannière apparaît au-dessus de la zone de saisie, nommant le modèle indisponible et celui qui a répondu à sa place, et ils peuvent la fermer. Un repli est donc une dégradation visible plutôt que silencieuse, et il se peut très bien que quelqu'un vous en parle avant que vous l'ayez remarqué.

Regardez la tendance, pas l'incident. Une bannière, c'est la chaîne qui fait son travail. Une chaîne sollicitée à répétition signifie que le modèle en tête va mal, et cela ressort dans l'alerte du Tableau de bord et dans la répartition des replis dans Utilisation, tous deux méritant un coup d'œil hebdomadaire.

L'embedding et le reclassement ne peuvent pas avoir de chaîne, et ce n'est pas une fonctionnalité manquante. Voir ci-dessous.

Choisir les modèles que votre équipe voit

Chaque modèle a un interrupteur : Proposer ce modèle aux utilisateurs. Désactivé, le modèle reste configuré et disparaît du sélecteur de tout le monde.

Sur les crédits, c'est ainsi que vous façonnez la liste. Votre organisation est provisionnée avec le catalogue entier, et les modèles recommandés sont déjà activés. En activer quelques-uns de plus, ou en désactiver quelques-uns, est la façon normale de décider ce qui est proposé à votre équipe sans rien configurer.

Les modèles de tâches

Trois emplacements, pour les tâches de fond plutôt que pour la conversation. Chacun se choisit séparément, et chacun a sa propre raison d'exister.

Embeddings

Transforme vos documents en vecteurs pour qu'une collection puisse être cherchée par le sens plutôt que par mot-clé. Cela tourne à l'ajout d'un document, et à nouveau pour chaque question posée à une collection.

Sans lui, les collections ne peuvent pas être indexées du tout. Les utilisateurs reçoivent « Modèle d'embedding non configuré », sur quoi ils ne peuvent rien. Configurez-le avant que quiconque essaie de créer une collection.

Trois contraintes, et la première fera échouer votre première tentative si vous la sautez :

La taille de lot est le nombre de textes envoyés dans un même appel API, et chaque fournisseur la plafonne différemment (Voyage autorise 1000, Cohere 96). Réglez-la sur ce que votre fournisseur documente.

Si vous ne connaissez pas le plafond, soyez prudent : 100 ou moins. Trop haut et le fournisseur rejette des lots entiers, ce qui se manifeste par une indexation qui échoue sur les gros documents et marche sur les petits. Trop bas ne coûte qu'un peu de débit, et l'indexation est une tâche de fond.

Pas de chaîne de repli, et il ne pourrait pas y en avoir. Une collection est interrogée avec le modèle qui l'a indexée, donc se replier sur un autre modèle reviendrait à interroger un index avec les vecteurs d'un autre : des absurdités énoncées avec assurance plutôt qu'une erreur.

Reclassement

Prend les candidats trouvés par la recherche et les réordonne selon leur capacité réelle à répondre à la question. Optionnel, et il gagne sa place sur les grandes collections, là où le premier passage ramène beaucoup de matière plausible.

Il a sa propre taille de lot, avec le même conseil : alignez-vous sur le plafond documenté par le fournisseur, et restez à 100 ou en dessous si vous ne le connaissez pas.

Pas de chaîne de repli, pour la même raison que les embeddings.

Génération d'images

Utilisé quand quelqu'un demande une image. Optionnel : sans lui, cette demande n'est tout simplement pas disponible.

Ce doit être un modèle qui génère des images, pas un modèle qui sait seulement les lire. Un modèle de chat capable de vision sait décrire une image et ne sait pas en produire. Ce qu'il vous faut ici, c'est un modèle d'image : les modèles d'image de Google (ceux commercialisés sous le nom Nano Banana) ou les modèles d'image d'OpenAI.

Le coût par image est optionnel et mérite d'être renseigné, parce que les modèles d'image sont tarifés à l'image plutôt qu'au token : le laisser vide fait que la génération d'images ne contribue à aucun de vos chiffres de coût.

Ce qui n'est pas sur cette page

Deux tâches pour lesquelles on s'attend à trouver un emplacement, et il n'y en a aucun à régler :

Rédiger les documents et les présentations de l'Atelier tourne sur le modèle de chat de la conversation qui l'a demandé. Si un membre veut un document rédigé par un modèle plus fort, il change de modèle dans la conversation avant de demander.

Rédiger un workflow à partir d'une description tourne sur votre modèle de chat par défaut, et suit sa chaîne si ce modèle est indisponible.

Les deux suivent le modèle de chat délibérément : la personne qui demande a déjà choisi un modèle pour la conversation, et répondre discrètement sur un autre ferait diverger le coût et le style d'écriture de ce qu'elle a choisi.

Changer le modèle d'embedding

Le seul changement de cette page qui ait de vraies conséquences, et la console s'explique bien quand vous vous y essayez.

En changer réindexe tout ce qui est déjà indexé : les fragments de documents, les entités du graphe de connaissances, les résumés de conversation. On vous montre les décomptes et une durée estimée avant de valider.

La conception est soignée, et vous pouvez lui faire confiance :

• Les nouveaux vecteurs sont construits à côté des anciens et ne sont activés qu'une fois tout le corpus prêt.
• La recherche reste disponible pendant toute l'opération. L'index actuel continue de répondre.
• Vous pouvez annuler à tout moment, sans rien perdre de ce qui est indexé.
• En cas d'échec, vos vecteurs existants ne sont pas touchés et vous restez sur le modèle précédent.

Vous ne pouvez pas changer le modèle d'embedding pendant qu'une bascule est en cours.

Faites-le délibérément : sur un gros corpus, c'est plusieurs heures de travail, et la raison de le faire est un modèle réellement meilleur, pas la curiosité.

Une configuration qui marche, de bout en bout

Pour une organisation qui part de rien :