Le flux d'exécution en 5 étapes

Comment Grok décide d’utiliser un outil

Quand vous activez un ou plusieurs outils dans votre requête API, le modèle ne les utilise pas systématiquement. Il suit un processus de décision structuré en cinq étapes pour déterminer si un outil est nécessaire, lequel utiliser, et comment intégrer les résultats dans sa réponse.

Comprendre ce flux vous permet de mieux anticiper le comportement du modèle et d’optimiser vos prompts pour obtenir des résultats précis.

Les 5 étapes du flux

Étape 1 : Analyse de la requête

Le modèle commence par analyser le message de l’utilisateur pour identifier ce qui est demandé. Il évalue la nature de la question : s’agit-il d’une demande factuelle nécessitant des données récentes ? D’un calcul complexe ? D’une question d’opinion qui ne requiert aucun outil ?

Cette analyse est déterminante. Si le modèle dispose déjà de l’information dans ses données d’entraînement et qu’aucune donnée en temps réel n’est requise, il peut choisir de répondre directement sans activer d’outil.

Étape 2 : Décision d’appel

Sur la base de son analyse, le modèle décide d’appeler un outil ou de répondre directement, et cette décision croise trois facteurs. La nature de la question d’abord : une interrogation sur l’actualité pousse naturellement vers Web Search, une question sur ce qui se dit en ce moment sur un sujet oriente vers X Search. Le périmètre que vous avez défini ensuite : le modèle ne choisit que parmi les outils activés dans votre tableau tools — un outil absent n’existe simplement pas pour lui. Sa propre confiance enfin : s’il estime pouvoir répondre correctement de mémoire, il économise l’appel, ce qui est le comportement souhaitable la plupart du temps.

Vous gardez la main sur cette décision via le prompt : « Recherche les dernières informations sur… » oriente clairement vers Web Search, quand une formulation neutre laisse le modèle arbitrer seul.

Étape 3 : Exécution

Le traitement diffère selon la catégorie d’outil :

• Outil intégré : l’exécution est automatique et transparente. Le serveur xAI effectue la recherche ou l’exécution de code, et le résultat est directement transmis au modèle. Vous ne voyez pas cette étape dans la réponse API
• Function Calling : le modèle retourne un objet décrivant la fonction à appeler et ses arguments. C’est à votre code d’exécuter la fonction et de renvoyer le résultat via une nouvelle requête

Étape 4 : Traitement des résultats

Une fois les résultats obtenus, le modèle les évalue avant de répondre — et c’est là que le flux devient réellement agentique. Si les résultats suffisent, il passe directement à la formulation de la réponse finale. S’ils sont insuffisants — recherche trop étroite, résultats hors sujet — il peut relancer un appel avec des paramètres ajustés, en élargissant ou en précisant sa requête, sans que vous ayez à intervenir. Et pour une question réellement complexe, il enchaîne plusieurs outils : une recherche web pour collecter les chiffres, puis Code Execution pour les analyser, par exemple.

Ce comportement itératif est précieux pour la qualité des réponses, mais il a une conséquence directe sur la facture : chaque appel d’outil est facturé séparément, et une question qui déclenche trois recherches coûte trois invocations. Gardez cette mécanique en tête au moment d’estimer vos coûts.

Étape 5 : Réponse finale

Le modèle formule sa réponse en intégrant les informations collectées. Si des sources web ou X ont été consultées, la réponse inclut automatiquement des citations avec les URLs d’origine. Ces citations sont accessibles dans le champ citations de l’objet réponse.

Implications pratiques

Coûts cumulatifs

Le modèle peut effectuer plusieurs appels d’outils pour une seule requête utilisateur. Chaque appel est facturé indépendamment en plus de la consommation de tokens. Un prompt ambigu peut générer des appels inutiles et augmenter vos coûts.

Contrôle via le prompt

Vous ne pouvez pas forcer le modèle à utiliser un outil spécifique, mais vous pouvez fortement l’orienter via votre prompt système ou le message utilisateur. Des instructions claires réduisent les appels inutiles.

Comportement non déterministe

Le choix d’utiliser ou non un outil peut varier entre deux appels identiques, surtout avec des températures élevées. Pour des résultats reproductibles, utilisez une température basse (0.0 à 0.3).

Points clés à retenir

• Le modèle suit un flux en 5 étapes : analyse, décision, exécution, traitement, réponse
• Il ne sollicite un outil que s’il le juge nécessaire — ce n’est pas automatique
• Les appels multiples sont possibles et augmentent les coûts
• Un prompt précis réduit les appels inutiles et améliore la pertinence
• Les citations sont automatiquement incluses quand des sources ont été consultées