gemini-4-carbon en pratique : 5 cas d'usage à forte valeur pour les modèles de texte et points clés d'intégration

Pourquoi évaluer un modèle de texte par scénarios plutôt que par classements

L'erreur la plus fréquente en matière de sélection de modèle consiste à prendre un classement pour une conclusion. Le score global d'un classement reflète la performance moyenne sur un ensemble d'évaluations, alors que votre activité ne se soucie que d'une seule forme de tâche : extraire des champs structurés à partir d'e-mails de support, ou classer des retours utilisateurs en cinq catégories. Ces deux tâches imposent des exigences totalement différentes au modèle : la première exige un strict respect du format de sortie sans champ manquant, la seconde une stabilité de la décision d'étiquetage et une absence d'oscillation sur les échantillons limites. Un modèle au score global élevé peut tout à fait être moins bon qu'un modèle de milieu de tableau sur votre tâche spécifique.

Une approche plus concrète consiste à décomposer d'abord la forme de la tâche, puis à juger si le modèle correspond. Les besoins de type texte peuvent globalement se répartir en quelques catégories : extraction structurée (extraire des champs d'un texte libre), classification et routage (étiqueter, décider de la destination), compression de textes longs (résumés et points clés), questions-réponses et réécriture à partir de documents, ainsi que revue et contrôle qualité (juger de la conformité et en donner la raison). Chaque catégorie a un contrat d'entrée/sortie différent, une sensibilité différente au prompt, et un coût de correction différent en cas d'erreur.

Le processus d'évaluation devrait donc être : déterminer d'abord à quelle forme appartient la tâche, rédiger 20 à 50 échantillons réels, définir clairement ce que signifie « avoir réussi », puis faire tourner les modèles candidats et comparer manuellement les résultats. gemini-4-carbon est le modèle le plus puissant de la série Gemini 4, destiné aux tâches multi-étapes et de longue durée les plus complexes ; il convient également d'être validé de cette manière, plutôt que de croire a priori à ses arguments marketing.

La suite développe 5 scénarios à forte valeur, chacun avec les conventions d'entrée/sortie, les points clés de conception du prompt et les principes de maîtrise des coûts ; vous pouvez directement les comparer à vos besoins pour choisir.

Scénario 1 : du texte non structuré aux données structurées

C'est la catégorie de tâches où les modèles de texte génèrent le plus facilement une valeur métier directe : l'entrée est le corps d'un ticket, un e-mail client, un extrait de contrat, un compte rendu de réunion ; la sortie est un JSON à champs fixes. Les champs typiques incluent le type de problème, le produit concerné, le degré d'urgence, les entités clés, le résumé de la demande de l'utilisateur, etc.

Le contrat d'entrée/sortie doit être figé au préalable

Avant la mise en production, écrivez clairement le schéma : noms de champs, types, énumérations de valeurs autorisées, autorisation ou non de null. Une fois le schéma déterminé, le modèle doit le respecter strictement au niveau de la sortie. Pour ce faire, donnez directement dans le prompt la définition des champs et un exemple complet, plutôt que de simplement décrire « veuillez extraire les informations clés ». Les exemples sont plus efficaces que les descriptions, surtout lorsque la sémantique des champs est ambiguë.

Trois niveaux de contrainte sur le format de sortie

Le premier niveau est le prompt : précisez « ne produisez que du JSON, sans explication, sans texte en dehors des marqueurs de bloc de code markdown ». Le deuxième niveau est la validation structurelle : dès réception de la réponse, effectuez immédiatement l'analyse et la validation des champs ; une valeur d'énumération hors plage, un champ obligatoire manquant ou un type incorrect sont considérés comme un échec. Le troisième niveau est la nouvelle tentative : en cas d'échec de validation, renvoyez une requête en incluant le message d'erreur de validation comme instruction supplémentaire ; le taux de succès est généralement bien meilleur qu'une nouvelle tentative à l'identique.

Ne comptez pas sur une réussite parfaite du premier coup. Pour les textes longs, le modèle peut omettre des informations situées plus loin ; pour les schémas à nombreux champs, il peut inverser deux champs proches. Tout cela doit être rattrapé au niveau de la validation, et non en multipliant les points d'exclamation dans le prompt.

Maîtrise des coûts

Les tâches d'extraction ont souvent des entrées longues et des sorties courtes ; le coût se concentre du côté de l'entrée. Les historiques de conversation, signatures d'e-mail et paragraphes de clause de non-responsabilité qui peuvent être supprimés doivent l'être avant l'envoi au modèle. Ne conservez que les paragraphes liés aux champs : cela réduit le coût et améliore la précision.

Scénario 2 : classification de contenu et routage

La forme de la tâche de classification est : un texte en entrée, une ou plusieurs étiquettes en sortie ; l'étiquette détermine le processus ultérieur — à quelle équipe l'affecter, dans quelle file la placer, quel type de réponse automatique déclencher.

La conception des étiquettes compte plus que le choix du modèle

Vérifiez d'abord si le jeu d'étiquettes est mutuellement exclusif et exhaustif. S'il existe une catégorie de repli comme « autre », précisez ses critères de décision. Le nombre d'étiquettes ne doit pas être trop élevé au départ ; au-delà d'une dizaine, la confusion du modèle sur les échantillons limites augmente nettement. Il est conseillé de fusionner d'abord les catégories proches, puis de les affiner une fois le système rodé. Chaque étiquette gagne à être accompagnée d'une phrase de critère de décision et d'un exemple positif, intégrés au prompt.

Confiance et repli

Vous pouvez demander au modèle, dans le prompt, de fournir une brève justification de sa décision et l'utiliser comme base de routage : une justification claire et cohérente est routée directement ; une justification vague ou contradictoire part en file manuelle. Attention toutefois : la confiance auto-déclarée par le modèle n'est pas toujours bien calibrée ; vérifiez impérativement sur des échantillons réels si elle permet réellement de distinguer les échantillons « faciles » des « difficiles ». Une approche plus sûre consiste à examiner la distribution des étiquettes candidates, ou à faire juger par une couche de règles si la justification fournie par le modèle est suffisante.

Il doit également exister une branche de repli obligatoire : échec d'analyse, étiquette hors énumération, conflit entre plusieurs étiquettes — tout passe en file manuelle ou par défaut. Le routage est un maillon à fort impact : mieux vaut multiplier les passages manuels que d'affecter automatiquement de manière erronée.

Maîtrise des coûts

Les tâches de classification ont une longueur d'entrée moyenne et une sortie très courte ; la consommation de tokens dépend principalement de l'entrée. Vous pouvez n'envoyer au modèle que le titre, le paragraphe d'introduction et les phrases clés plutôt que le document entier ; pour les contenus très longs, tronquez avant de classifier : dans la plupart des cas, la perte de qualité reste limitée.

Scénario 3 : résumé de textes longs et extraction des points clés

La difficulté du résumé de textes longs ne réside pas dans « écrire un paragraphe de synthèse », mais dans « ne pas perdre d'information clé, ne pas répéter la synthèse, ne pas inventer ». Lorsqu'un appel unique traite un texte très long, le modèle perd facilement le contenu du milieu et réécrit souvent le début de manière répétée.

Résumé par segments puis fusion

La pratique courante consiste à découper le texte long en blocs par paragraphes ou chapitres, à générer des points clés bloc par bloc, puis à fusionner ces points en un résumé final. Lors du découpage, respectez autant que possible les frontières sémantiques plutôt qu'une découpe rigide par nombre de caractères fixes ; sinon, une phrase coupée en deux introduit du bruit. Lors de la fusion, demandez au modèle de compresser uniquement à partir des points clés déjà produits, sans revenir au texte original : cela réduit significativement les redondances et les digressions.

Préciser le public cible et la granularité du résumé

Indiquez clairement dans le prompt : à qui s'adresse le résumé, quelle longueur, quels éléments conserver (chiffres, conclusions, tâches à faire). Sans précision, le modèle produira des généralités moyennes. Une autre contrainte efficace est « sortie par items », une phrase par item, pour éviter que des transitions superflues ne s'insèrent dans de longs paragraphes continus.

Validation qualité

Les sorties de type résumé n'ont pas de réponse unique correcte, mais plusieurs vérifications peu coûteuses sont possibles : la longueur est-elle dans la plage, les éléments clés demandés sont-ils présents, des chiffres ou entités absents de l'original apparaissent-ils. Ce dernier point est particulièrement important : lors de la compression, le modèle « complète » parfois un chiffre qui semble raisonnable, ce qui est une faute grave dans un document métier.

Maîtrise des coûts

C'est le scénario qui consomme le plus de tokens en entrée. Le résumé par segments signifie qu'un même document est lu plusieurs fois, et le coût croît approximativement de façon linéaire avec la longueur. Il est conseillé de fixer une limite de longueur pour les documents très longs et de définir une stratégie de dégradation explicite : par exemple, résumer finement seulement les premiers chapitres et grossièrement le reste.

Scénario 4 : questions-réponses et réécriture à partir de vos propres documents

La forme de ce scénario est : l'utilisateur pose une question, le système récupère d'abord des paragraphes candidats dans vos propres documents, les assemble dans le contexte, et demande au modèle de répondre ou de réécrire à partir de ces paragraphes. Sa différence avec les questions-réponses générales est que la réponse doit rester dans les documents fournis.

Assemblage du contexte

Les paragraphes récupérés doivent d'abord être triés puis tronqués, en plaçant les plus pertinents près de l'instruction. Chaque extrait de document porte un identifiant de source, ce qui facilite la citation dans la réponse et le diagnostic d'erreur. Si les résultats de récupération se contredisent, le prompt doit explicitement demander au modèle de signaler le conflit plutôt que d'en choisir un lui-même.

Refuser de répondre a plus de valeur que répondre à tout prix

Le prompt doit stipuler : si les documents ne suffisent pas pour répondre, indiquez directement que l'information n'est pas présente dans les documents, sans compléter par des connaissances générales. Cette contrainte réduit significativement le taux d'hallucination, mais à condition de préparer spécifiquement dans le jeu d'évaluation une série de questions « dont la réponse n'est réellement pas dans les documents » ; sinon, le problème n'apparaîtra pas au test.

Contraintes supplémentaires pour la réécriture

Pour des besoins du type « réécrire le document en un paragraphe compréhensible par l'utilisateur », en plus de l'exactitude du contenu, il faut contraindre le style : longueur, ton, autorisation ou non d'utiliser des listes, obligation ou non de conserver les termes originaux. La lisibilité de la sortie de réécriture dépend fortement de ces points ; s'il en manque un, vous obtiendrez un résultat au style décalé.

Maîtrise des coûts

Le coût est presque entièrement déterminé par la longueur des documents assemblés dans le contexte. Récupérer davantage puis tronquer au stade de la recherche est souvent plus économique que d'augmenter le Top-K ; les questions répétées dans une même session peuvent avoir leur réponse mise en cache ; pour les tâches de réécriture, limiter explicitement la longueur de sortie réduit à la fois le coût et améliore la cohérence stylistique.

Scénario 5 : assistance à la revue et au contrôle qualité

La forme des tâches de revue est : étant donné un contenu (texte marketing, commentaire de code, réponse au support, description produit) et un ensemble de critères, produire un résultat conforme ou non conforme, ainsi que les raisons de la non-conformité. Elle ne recherche pas la créativité, mais la cohérence des décisions.

Rédiger les critères de revue sous forme d'items décidables

Des critères comme « le ton est-il amical » ne peuvent pas être appliqués de manière stable. Il faut les décomposer en items décidables : présence ou non de mots interdits, présence ou non d'engagements, longueur dans l'intervalle ou non, présence ou non des informations requises. Chaque critère correspond à une décision booléenne et à une brève justification, la structure de sortie étant fixée comme un résultat par item plus une conclusion globale.

Distinguer validation stricte et suggestions souples

Les vérifications réalisables par du code de règles (regex, longueur, lexique) ne doivent pas être confiées au modèle : c'est lent et instable. Le modèle convient aux parties que les règles ne couvrent pas : le sens est-il contradictoire, la formulation peut-elle prêter à confusion, s'écarte-t-on des critères donnés. En séparant ces deux types de résultats, le coût de la revue manuelle est bien plus faible.

Conception de la sortie

Demandez au modèle de produire pour chaque critère trois états — « conforme / non conforme / impossible à juger » — plutôt que deux. L'ajout de « impossible à juger » réduit nettement les décisions forcées du modèle en cas d'information insuffisante et vous fournit une file explicite de traitement manuel. Le champ de justification est limité à une phrase, ce qui économise des tokens et facilite l'agrégation statistique.

Maîtrise des coûts

Le contrôle qualité est souvent une tâche par lots : coût unitaire faible mais volume total élevé. Les leviers sont la standardisation du modèle de prompt, la compression du contenu à examiner (n'envoyer que les parties à vérifier), et le filtrage préalable par règles des échantillons manifestement conformes, pour n'envoyer au modèle que les cas douteux.

Mise en œuvre de l'intégration : interface, paramètres et contraintes de sortie

Les 5 scénarios ci-dessus partagent de nombreux points communs au niveau de l'intégration, qui peuvent être abstraits en un processus générique : modèle de prompt → appel du modèle → validation de la sortie → nouvelle tentative en cas d'échec. L'appel du modèle passe par l'interface compatible Chat Completions https://api.hiapi.ai/v1/chat/completions, avec le base_url du SDK https://api.hiapi.ai/v1, et prend en charge la sortie en streaming.

Nom du modèle et lignes d'accès

Un même modèle propose deux lignes d'accès : le nom du modèle de la ligne standard n'a pas de suffixe, la ligne Vertex ajoute @vertex après le nom du modèle, par exemple gemini-4-carbon@vertex. Changer de ligne ne modifie que le champ model, le reste de la requête reste inchangé ; les capacités du modèle sont identiques sur les deux lignes, les prix diffèrent, voir le tableau des prix ci-après.

Entrée et limite de longueur

L'entrée ne prend en charge que le texte et les images ; l'audio, la vidéo et le PDF ne sont pas pris en charge. La longueur de contexte est de 1 048 576 tokens, la sortie maximale par appel de 65 536 tokens, ce qui laisse une marge importante pour des scénarios comme le résumé de textes longs, mais le traitement par segments reste un moyen efficace de maîtriser le coût et la stabilité.

Intensité de raisonnement

L'intensité de raisonnement est spécifiée via reasoning_effort, avec les valeurs low, medium, high. Le choix du niveau doit être déterminé par l'évaluation sur la tâche réelle : faites tourner chaque niveau sur des échantillons réels, comparez la précision, la durée et la consommation de tokens avant de fixer la valeur par défaut. Plus l'intensité de raisonnement est élevée, plus la durée et les tokens de sortie augmentent ; il faut arbitrer selon le scénario.

Capacités actuellement non prises en charge

Cette interface ne prend actuellement pas en charge l'appel d'outils / function calling, la recherche web, le computer use, la sortie structurée / le mode JSON. Les contraintes de format de sortie doivent donc être assurées au niveau du prompt et de la couche de validation du code : le prompt fournit la définition des champs et un exemple complet, le code analyse la réponse et valide chaque élément, sans s'appuyer sur un schéma imposé côté interface.

Exemple de requête

curl https://api.hiapi.ai/v1/chat/completions \
  -H "Authorization: Bearer $HIAPI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gemini-4-carbon",
    "reasoning_effort": "medium",
    "stream": true,
    "messages": [
      {"role": "user", "content": "把下面的工单抽取为固定字段的 JSON：..."}
    ]
  }'

Structure du modèle de prompt

Il est recommandé de la fixer en quatre parties : rôle et description de la tâche, données d'entrée, définition du format de sortie et exemple, limites et interdictions. Les données d'entrée sont encadrées par des délimiteurs explicites, pour éviter la confusion avec les instructions. L'exemple doit être complet et analysable ; n'écrivez pas « un JSON du genre » en donnant un fragment incomplet.

La validation de la sortie est indispensable, pas optionnelle

Dès réception de la réponse, commencez par l'analyse : le JSON est-il analysable, les champs obligatoires sont-ils tous présents, les valeurs d'énumération sont-elles valides, les valeurs numériques sont-elles dans une plage raisonnable. En cas d'échec de validation, ne dégradez pas silencieusement vers un résultat vide : enregistrez l'échec, car le taux d'échec est lui-même un indicateur important de la qualité du modèle.

Stratégie de nouvelle tentative

Il est conseillé de réessayer au maximum une à deux fois, et lors de la nouvelle tentative, de communiquer au modèle l'erreur de validation comme information supplémentaire, par exemple en indiquant quel champ est manquant ou quelle valeur d'énumération est illégale. Le gain d'une nouvelle tentative à l'identique est généralement très faible. Fixez également un délai d'expiration et une limite de concurrence, pour éviter qu'une seule anomalie ne fasse échouer tout le lot.

Journalisation et observabilité

Pour chaque appel, enregistrez au minimum : l'identifiant du scénario, la consommation de tokens en entrée et en sortie, le résultat de validation, la durée. Ces données servent à la fois à l'analyse des coûts et de référence de comparaison lors d'un futur changement de modèle ou de prompt. Sans cette couche d'enregistrement, toute optimisation ne repose que sur l'intuition.

Maîtrise des coûts à la tarification au token et recommandations de mise en production

gemini-4-carbon est facturé au token, ce qui signifie que le coût est déterminé conjointement par la longueur d'entrée et la longueur de sortie, et que la structure des coûts varie fortement selon les scénarios. Les scénarios d'extraction et de questions-réponses sont dominés par l'entrée, le scénario de résumé est lourd en entrée comme en sortie, la classification et le contrôle qualité sont lourds en entrée et très légers en sortie. Identifiez d'abord de quel côté votre scénario dépense l'argent, pour que l'optimisation ait une direction.

Prix et référence de sélection

Le tableau ci-dessous est exprimé en dollars / million de tokens ; les trois colonnes sont, dans l'ordre, l'entrée, l'entrée en cache et la sortie.

Les trois modèles ont des positionnements différents : gemini-4-carbon est le modèle le plus puissant de la série Gemini 4, destiné aux tâches multi-étapes et de longue durée les plus complexes ; gemini-4-argon convient à la plupart des travaux d'ingénierie logicielle et de travail intellectuel, avec un équilibre entre capacité et coût ; gemini-3.8-flash est rapide et bon marché, adapté aux tâches à forte concurrence et faible latence. Pour une même tâche, vous pouvez d'abord valider avec Argon ou Flash, puis juger s'il vaut la peine de passer à Carbon.

La ligne et l'intensité de raisonnement sont aussi des variables de coût : le prix unitaire de la ligne standard est inférieur à celui de la ligne @vertex. Le niveau d'intensité de raisonnement doit être choisi par évaluation sur la tâche réelle ; comparez la précision et la consommation de tokens de chaque niveau sur des échantillons réels avant de fixer la valeur par défaut.

Compresser l'entrée

Le gaspillage le plus courant consiste à envoyer le document entier tel quel au modèle. Ce que vous pouvez faire : supprimer les en-têtes, pieds de page et clauses de non-responsabilité standardisés, ne conserver que les dernières tours de l'historique de conversation, tronquer les résultats de recherche par pertinence, n'envoyer que les chapitres nécessaires pour les textes longs. Ces modifications ne font généralement pas perdre de précision et réduisent directement les tokens d'entrée.

Limiter la sortie

Le contrôle côté sortie est plus simple : précisez une longueur maximale, demandez une sortie par items plutôt que de longs paragraphes, interdisez la reformulation de l'entrée. Beaucoup de prompts contiennent « veuillez détailler » ; dans un modèle facturé au token, c'est un amplificateur de coût, sauf si l'activité a réellement besoin de détails.

Évaluer à petite échelle avant de passer à grande échelle

Ne remplacez pas votre propre validation par les descriptions officielles. L'approche recommandée est : préparer quelques dizaines d'échantillons réels pour chaque scénario, définir des critères de réussite décidables, faire un premier passage pour observer la précision et les modes d'échec, puis décider d'étendre ou non le périmètre. Le jeu d'évaluation doit être conservé comme référence de régression ultérieure.

Mettre en place un processus d'évaluation et de régression réutilisable

Changer de modèle, modifier le prompt, ajuster la longueur de contexte affectent tous les résultats. Disposer d'un script d'évaluation et d'indicateurs fixes permet de juger en quelques minutes après une modification si les choses s'améliorent ou se dégradent. C'est l'infrastructure de base pour utiliser un modèle de texte sur le long terme, plus importante que n'importe quel réglage ponctuel.

Choisissez d'abord un scénario, quelques dizaines d'échantillons et un ensemble de critères de réussite explicites ; une fois le système rodé, parlez d'extension. Vous pouvez consulter la description de l'interface et les modalités de facturation de gemini-4-carbon sur la page modèle de HiAPI.ai ; établir le budget à partir de la consommation réelle de tokens en entrée et en sortie est plus précis.