Google: Gemini 3.8 Flash (batch)

Gemini 3.8 Flash est le modèle à sortie textuelle de Google pour le génie logiciel soutenu, les agents à plusieurs étapes et les flux de travail complexes sur les connaissances. Il s’appuie sur Gemini 3.7 Flash, avec des améliorations en génie logiciel et dans le travail sur les connaissances effectué par des agents. Il accepte le texte, les images, l’audio, la vidéo et les PDF, de sorte qu’une tâche peut combiner un objectif écrit avec les éléments réels nécessaires pour la résoudre. Le résultat utile est une modification de code, une analyse expliquée, une réponse écrite ou un enregistrement structuré.

Pour une tâche de programmation, fournissez l’exigence, les fichiers pertinents, le comportement observé et les contraintes à préserver. Une capture d’écran peut établir l’interface souhaitée, tandis que des journaux ou un exemple reproductible montrent la défaillance. Pour une tâche de débogage, demandez au modèle de retracer un écart entre l’état visible d’un formulaire et sa valeur enregistrée, d’identifier le chemin de code responsable et de proposer une correction ciblée. Gardez le livrable final souhaité clair afin qu’une séquence d’investigation et d’utilisation d’outils plus longue conserve une condition de fin précise.

Pour les travaux de longue durée, utilisez des étapes de raisonnement plus petites, des appels d’outils itératifs et des vérifications des résultats intermédiaires. Les niveaux de réflexion faible, moyen et élevé contrôlent la quantité de raisonnement; le niveau moyen est la valeur par défaut documentée. Le niveau faible convient à une ébauche rapide ou à une analyse délimitée, tandis que le niveau élevé vise les mathématiques difficiles, la programmation ou les tâches à plusieurs étapes. Gemini 3.8 Flash ne prend pas en charge le niveau de réflexion minimal. Une tâche de débogage soutenue et une simple extraction de champs demandent donc des choix de raisonnement différents plutôt que le même réglage pour toutes les requêtes.

Les outils documentés comprennent les appels de fonctions, l’exécution de code, la recherche de fichiers, l’ancrage par recherche, l’ancrage avec Google Maps et le contexte URL, Computer Use étant présenté comme une capacité en préversion. Les sorties structurées définissent un résultat lisible par machine. Les fonctions doivent avoir une finalité claire et des paramètres définis : le modèle peut demander une fonction, tandis que l’application connectée réalise l’opération et renvoie son résultat. Préservez l’identité des fonctions et les éléments réellement renvoyés d’un tour à l’autre. Une réponse finale utile explique quelles données probantes appuient la correction proposée ou la valeur extraite.

Le guide de migration 3.8 utilise des contrôles de niveau de réflexion à la place de l’ancienne configuration du budget de raisonnement et conseille de retirer les paramètres d’échantillonnage obsolètes et les tours de modèle préremplis. Il exige aussi de préserver les signatures de pensée dans le flux sans état pertinent et de faire correspondre les réponses de fonctions à leurs appels par identité et nom. Ces détails comptent lorsqu’on poursuit une tâche à plusieurs étapes : le tour suivant a besoin du contexte réel antérieur plutôt que d’un récit réécrit qui perd le résultat d’outil ou la signature. Gardez la question et la sortie demandée explicites dans le nouveau tour utilisateur.

Pour le travail multimodal sur les connaissances, identifiez les pages de document, le graphique, l’intervalle audio ou l’événement vidéo pertinents et indiquez comment ils doivent contribuer à la réponse. Une comparaison de documents peut demander un tableau des différences avec des passages sources; une question sur un graphique peut demander les valeurs visibles et la conclusion qu’elles appuient. Une analyse vidéo peut demander une description des événements qui justifient un constat. Le modèle renvoie du texte à partir de ces entrées. Les images générées, la parole et les interactions audio en direct relèvent de profils de modèles distincts.

Ses limites Gemini API sont de 1 048 576 jetons d’entrée et de 65 536 jetons de sortie, ce qui correspond au contexte natif allant jusqu’à 1M et à la sortie textuelle de 64K du modèle. Les instructions, l’historique de conversation et les médias fournis consomment le contexte d’entrée, et le raisonnement ou un long livrable final doivent respecter la capacité de sortie documentée. Google indique aussi la mise en cache, le traitement par lots, Flex et Priority pour ce profil du producteur. Pour des éléments indépendants, conservez un identifiant stable et un format de sortie explicite afin que chaque résultat reste lié à sa source.

Les limites possibles comprennent des hallucinations, des lenteurs ou des dépassements de délai occasionnels et une consommation plus élevée de jetons avec un effort accru. Ses connaissances s’arrêtent en mars 2026, certains domaines restant limités à janvier 2025. Fournissez des données actuelles ou utilisez les outils d’ancrage documentés lorsque la tâche dépend d’informations plus récentes. Vérifiez les citations de sources, les calculs et le code proposé à partir des entrées réelles et des résultats d’exécution. Le livrable final utile doit distinguer un constat appuyé d’une question non résolue, sans supposer qu’une réponse fluide établit le résultat demandé.