Décrire un outil

Ce que vous saurez faire

Permettez à l’assistant de demander l’état réel d’une commande, sans donner au modèle accès à la base de données de LarkfieldTermeLarkfieldUne boutique en ligne d’articles pour la maison. Ce n’est pas une vraie entreprise. Tous les cours Nextia utilisent son service d’assistance et ses données comme exemple.En savoir plus L'IA dans les produits de tous les joursBases d'une carrière en IA : rôles, compétences et feuilles de route. Vous décrivez un outil en lecture seule, get_order, et observez la première vraie demande du modèle pour l’utiliser.

Avant de commencerCe qu’il faut savoir et avoir sous la mainEnviron 50 minutes

Ce que vous devez savoir

• La requête, ses messages et leurs rôles, vus dans Les éléments d’une requête.
• Un schéma JSON et une sortie structurée, vus dans Définir un schéma.
• Les deux barrières, le schéma et les règles d’affaires, vues dans Valider le sens.
• Ce qu’est un modèle de raisonnement, vu dans Raisonnement et multimodalité, dans le cours sur les modèles de langage.

Ce qu’il vous faut sur votre ordinateur

• Le projet ticket-assistant à la fin du module 3, avec son environnement virtuel actif. python -m pytest affiche 42 passed, 1 deselected (42 tests réussis, 1 exclu).
• Si votre projet manque ou ne fonctionne plus, copiez l’instantané end-of-m03 selon les étapes de Réinitialiser le projet.
• Le dépôt des laboratoires à côté de votre projet, comme dans Définir un schéma. Vous copiez les appels d’outils enregistrés depuis son instantané end-of-m04.
• Aucun compte ni aucune clé. Le fournisseur simulé rejoue de vraies réponses enregistrées.

Les modèles et les API changent vite. Les réponses, les erreurs et les prix de ce module sont un instantané. La méthode, elle, reste.

Un formulaire à la réception

Imaginez un client d’hôtel à la réception. Il demande : « Mon colis est-il arrivé? » La réceptionniste ne peut pas ouvrir la réserve. Elle remplit donc un formulaire de demande : « Vérifier les colis pour la chambre 214. » Un employé à l’arrière lit le formulaire. Il décide s’il doit donner suite, vérifie dans la réserve et écrit la réponse sur le formulaire. La réceptionniste transmet ensuite la réponse au client.

La réceptionniste sait parler aux clients. L’employé détient les clés. Personne ne donne les clés à la réceptionniste, car elle doit seulement écrire une demande claire.

Le problème : le modèle ne voit pas les commandes

Le billet de soutien T-80008 dit : « Bonjour, où est ma commande LK-581106? Le courriel de confirmation disait que la remise de jardin avait été expédiée lundi, mais je n’ai pas encore de date de livraison. »

À la fin du module 3, l’assistant envoie ce billet à chat-smallTermechat-smallLe nom que le code de Larkfield donne à un petit modèle hébergé peu coûteux : gpt-6-luna sur Azure. Le code utilise ce nom, donc le modèle peut changer sans modifier le code.En savoir plus Ce qu'est une API de LLMCréer des applications fiables avec les API de LLM et vérifie la réponse. Voici la vraie réponse (gpt-6-luna sur Azure), abrégée :

"order": {"order_id": "LK-581106", "status": null},
"reply": "I’m sorry you haven’t received a delivery date for your garden shed. Our delivery team can help check the shipment and tracking information for your order."

Le modèle a bien agi : il a mis l’état à null, parce qu’il ne peut pas le connaître. Mais la réponse n’aide personne. L’état de la commande se trouve dans la base de données de Larkfield, orders.sqlite. Le modèle n’a jamais vu cette base de données et ne doit jamais y accéder directement.

Un modèle qui devine fait pire. Dans le module 3, vous avez vu un modèle inventer le dernier chiffre d’un identifiant de commande. Un état deviné, comme « livrée », serait un mensonge présenté avec assurance à un client. La règle d’affaires status_not_from_lookup dans validate.py rejette déjà tout état que l’application n’a pas vérifié elle-même.

Le modèle a donc besoin d’un moyen de demander l’état. L’application a besoin d’un moyen de dire oui ou non.

L’idée : le modèle écrit une demande, votre code agit

Les appels d’outils offrent ce moyen. Votre application décrit une fonction au modèle : son nom, ce qu’elle fait et ses arguments. Le modèle peut alors répondre de deux façons. Il écrit sa réponse habituelle ou une demande d’appel de la fonction. Votre code lit cette demande, décide, exécute la fonction et renvoie le résultat. Le modèle écrit ensuite sa réponse avec les vraies données.

Cette description s’appelle un outil, parce que le modèle peut demander à l’utiliser. La demande du modèle est un appel d’outil. Certains fournisseurs et documents plus anciens appellent la même chose « appel de fonction ».

Le modèle est la réceptionniste et votre application est l’employé. Le modèle n’exécute jamais rien. Il écrit seulement du texte dans un format fixe. Lisez le schéma de haut en bas.

Une boucle d'outil. Le modèle propose; l'application vérifie, lit et renvoie. Champs réels enregistrés pour T-80008.

Description textuelle du diagramme

Trois participants : l’assistant, qui est le code de l’application; le modèle, chat-small; et la base de données des commandes, en lecture seule.

1. Appel 1 : l’assistant envoie les instructions, la politique, le billet T-80008 et la liste des outils, avec un seul outil, get_order.
2. Le modèle répond avec finish_reason « tool_calls » et un appel d’outil : get_order avec les arguments {"order_id":"LK-581106"}.
3. Une note : c’est une proposition, pas une action. L’application la vérifie d’abord.
4. Si toutes les vérifications réussissent : l’assistant demande LK-581106 à la base de données et obtient « expédiée le 5 octobre 2026, client C-81265 ». L’appel 2 envoie les deux premiers messages, la proposition et un message d’outil : ok true et la commande.
5. Si une vérification échoue, l’appel 2 envoie un message d’outil avec ok false et une erreur. Le billet T-80001 demande la commande LK-615204 du voisin. Son erreur est donc « Aucune commande LK-615204 n’est disponible pour ce client. »
6. Le modèle répond avec finish_reason « stop » et la réponse JSON. Les deux barrières la vérifient.

Deux éléments de ce schéma comptent pour tout le module. D’abord, la base de données reste uniquement du côté de l’application. Ensuite, il y a deux appels au modèle pour un seul billet. Le modèle ne se souvient de rien entre les appels. L’appel 2 renvoie donc toute la conversation.

Un appel d’outil n’est que du JSON

Voici la vraie première réponse pour T-80008, avec seulement les champs importants :

{
  "choices": [{
    "finish_reason": "tool_calls",
    "message": {
      "content": null,
      "tool_calls": [{
        "id": "call_sJRbZ1CKs3JGicYe0aKTAN38",
        "type": "function",
        "function": {"name": "get_order", "arguments": "{\"order_id\":\"LK-581106\"}"}
      }]
    }
  }],
  "usage": {"prompt_tokens": 2043, "completion_tokens": 21}
}

Lisez-la champ par champ :

• finish_reason (raison de l’arrêt) vaut "tool_calls" (appels d’outils), et non "stop" (arrêt). Le modèle s’est arrêté parce qu’il veut un outil, pas parce qu’il a terminé.
• content (contenu) vaut null : il n’y a pas encore de texte de réponse.
• id identifie cet appel. Votre réponse doit reprendre cet identifiant pour que le modèle sache quel résultat correspond à quel appel.
• arguments est une chaîne contenant du JSON, écrite par le modèle. Rien ne l’a vérifiée. Elle peut être incorrecte, inventée ou malveillante.

La proposition a coûté 21 jetons (tokens) de sortie. Le modèle a choisi l’identifiant de commande en lisant le billet. Ce choix est le sujet de la prochaine leçon.

Décrire un outil en quatre parties

Le modèle connaît get_order uniquement par sa description. Cette description doit donc répondre à quatre questions, comme un bon formulaire de demande :

1. But : que fait l’outil et quand est-il utile?
2. Arguments : que doit fournir l’appelant et sous quelle forme?
3. Retour : que reçoit-il en retour?
4. Limites : que ne fait-il jamais?

Voici la description du projet. C’est un dictionnaire Python qui devient du JSON dans la requête :

assistant/tools.py (part)

GET_ORDER = {
    "type": "function",
    "function": {
        "name": "get_order",
        "description": ("Look up one of this customer's Larkfield orders by its order ID. Read-only. Returns the "
                        "status, the dates, the items and the total. Orders of other customers are not available."),
        "strict": True,
        "parameters": {
            "type": "object",
            "properties": {"order_id": {"type": "string", "description": "The order ID, LK- and 6 digits."}},
            "required": ["order_id"],
            "additionalProperties": False,
        },
    },
}
TOOLS = [GET_ORDER]

Partie	Où elle se trouve	Ce qu’elle dit
But	name, première phrase de description	Chercher une commande de ce client par son identifiant.
Arguments	parameters, un schéma JSON	Une chaîne, order_id, sous la forme LK- suivie de 6 chiffres. Aucune autre clé.
Retour	description	L’état, les dates, les articles et le total.
Limites	description, additionalProperties	Lecture seule. Les commandes des autres clients ne sont pas disponibles.

strict: true demande au fournisseur de faire respecter le schéma par les arguments, comme la sortie structuréeTermeSortie structuréeUne requête qui envoie au fournisseur le schéma de la réponse, pour que le modèle ne puisse écrire qu’une réponse de cette forme. Elle contrôle la forme, pas la vérité : l’application vérifie toujours chaque réponse.En savoir plus Définir un schémaCréer des applications fiables avec les API de LLM stricte du module 3. Cela aide, mais c’est une demande au fournisseur, pas une vérification dans votre code.

Remarquez ce qui n’est pas un argument : l’identifiant du client. L’application de soutien sait qui a envoyé le billet. Si customer_id était un argument, le modèle le choisirait. Un billet pourrait alors lui demander de choisir quelqu’un d’autre. Ne laissez jamais le modèle choisir l’identité de l’appelant.

L’outil est aussi en lecture seule : il peut consulter, jamais modifier. La règle 8 de la politique de GraceTermeGraceLa responsable du service d’assistance de Larkfield. Elle écrit la politique de support et décide ce qu’est une bonne réponse à un client. dit que l’assistant rédige seulement des brouillons. Il ne rembourse ni ne modifie jamais une commande. Un outil en lecture seule tient cette promesse dans le code, pas seulement dans la requête (prompt).

Ajouter l’outil au projet

La requête a besoin d’un champ de plus, tools. Certains modèles de raisonnementTermeModèle de raisonnementUn modèle qui écrit des jetons de raisonnement cachés avant sa réponse. chat-small en est un. Un tel modèle accepte souvent seulement sa température par défaut, et ses jetons cachés comptent dans la limite de sortie.En savoir plus Raisonnement et multimodalitéLes LLM : comment ils fonctionnent et comment en choisir un ont aussi besoin de reasoning_effort, comme le montre une section plus loin. Le projet l’envoie seulement s’il est défini.

1. Récupérez les appels d’outils enregistrés de ce module. Le fournisseur simulé en a besoin. Ils se trouvent dans l’instantané end-of-m04. Exécutez d’abord git -C ../nextia-learning-labs pull (ou téléchargez de nouveau le fichier ZIP), puis copiez les fichiers :

   macOS / Linux

   cp ../nextia-learning-labs/C08/snapshots/end-of-m04/recordings/*.jsonl recordings/

   Windows (PowerShell)

   Copy-Item ..\nextia-learning-labs\C08\snapshots\end-of-m04\recordings\*.jsonl recordings\

   recordings/ contient maintenant neuf fichiers. Les trois nouveaux fichiers contiennent les boucles d’outils de chat-small, les deux erreurs HTTP 400 de chat-strongTermechat-strongLe nom que le code de Larkfield donne à un modèle hébergé plus grand : gpt-6.1-sol sur Azure. Il est souvent plus exact que chat-small et coûte environ 14 à 18 fois plus par appel.En savoir plus Les éléments d'une requêteCréer des applications fiables avec les API de LLM et quelques réponses supplémentaires du modèle local.

2. Créez un fichier assistant/tools.py. Commencez par cette chaîne de documentation, puis collez GET_ORDER et TOOLS présentés plus haut :

   assistant/tools.py

   """The one tool the model may ask for: a read-only order lookup.
   
   The model only proposes a call. This code decides: it checks the argument, checks that the order
   belongs to the ticket's customer, and only then reads the database. The customer ID never comes
   from the model: the help-desk app knows who sent the ticket.
   """

3. Ouvrez assistant/context.py. Remplacez build_request par cette version :

   assistant/context.py (build_request)

   def build_request(ticket: Ticket, model: str, version: str = "v2", response_format: dict | None = None,
                     tools: list[dict] | None = None, reasoning_effort: str = "") -> dict:
       """The body of one Chat Completions request. Only the fields that are set are sent."""
       request = {"model": model, "messages": build_messages(ticket, version), "max_completion_tokens": MAX_TOKENS}
       if response_format:
           request["response_format"] = response_format
       if tools:
           request["tools"] = tools
       if reasoning_effort:
           request["reasoning_effort"] = reasoning_effort
       return request

4. Créez un fichier check_tool.py dans le dossier du projet. Il construit la requête et demande la réponse enregistrée au fournisseur simulé :

   check_tool.py

   from assistant.context import build_request
   from assistant.data import load_ticket
   from assistant.providers import MockProvider
   from assistant.schema import response_format
   from assistant.tools import TOOLS
   
   ticket = load_ticket("T-80008")
   request = build_request(ticket, "chat-small", "v2", response_format(), TOOLS)
   print(sorted(request))
   completion = MockProvider().complete(request)
   print(completion.finish_reason)
   print(completion.text)
   print(completion.tool_calls)
   print(completion.input_tokens, completion.output_tokens)

5. Exécutez-le :

   python check_tool.py

6. Exécutez python -m pytest. Il doit encore afficher 42 passed, 1 deselected : rien n’utilise encore l’outil.

La sortie de l’étape 5 :

['max_completion_tokens', 'messages', 'model', 'response_format', 'tools']
tool_calls
None
[ToolCall(id='call_sJRbZ1CKs3JGicYe0aKTAN38', name='get_order', arguments='{"order_id":"LK-581106"}')]
2043 21

La requête contient maintenant cinq champs. Le fournisseur simulé a trouvé un enregistrement correspondant, car la description de l’outil est exactement celle du projet. Si vous changez un caractère de la description, il répond No recording for this request (aucun enregistrement pour cette requête). L’enregistrement a été fait avec reasoning_effort: "none". Mais ce champ ne fait pas partie de la clé du fournisseur simulé. Votre requête sans ce champ correspond donc quand même.

Le ToolCall du projet contient les trois champs nécessaires à votre code : id, name et la chaîne arguments. Vous pouvez maintenant supprimer check_tool.py.

Tous les modèles ne peuvent pas utiliser des outils

OmarTermeOmarLe gestionnaire de produit de Larkfield. Il pose les questions d’affaires : ce qu’un changement coûte et ce qu’il apporte à la boutique. pose la question évidente : « chat-strong est notre meilleur modèle. Peut-il aussi chercher les commandes? » AmiraTermeAmiraLa développeuse de Larkfield. Elle écrit le code des outils du service d’assistance dans les cours. a envoyé la même requête à chaque route du cours. Le schéma montre les réponses reçues.

La même requête avec un outil, envoyée à chaque route du cours. Une seule route l'a acceptée.

Description textuelle du diagramme

Une requête : le billet T-80008 et l’outil get_order. Elle a été envoyée à quatre routes.

• chat-small (gpt-6-luna) avec reasoning_effort « none » : HTTP 200 et un appel d’outil.
• chat-small sans reasoning_effort : HTTP 400, « Les outils de fonction avec reasoning_effort ne sont pas pris en charge… réglez reasoning_effort sur ‘none’ ».
• chat-strong (gpt-6.1-sol), avec ou sans « none » : HTTP 400 dans les deux cas. Il ne peut pas utiliser d’outils dans Chat Completions.
• gemma3:4b dans Ollama 0.40.1 sur un portable : HTTP 400, « ne prend pas en charge les outils ».

Voici les deux vraies erreurs de chat-strong, mot pour mot :

Function tools with reasoning_effort are not supported for chat-strong in /v1/chat/completions.
To use function tools, use /v1/responses or set reasoning_effort to 'none'.

Unsupported value: 'reasoning_effort' does not support 'none' with this model.
Supported values are: 'low', 'medium', 'high', and 'xhigh'.

La première erreur suggère « none ». La deuxième dit que ce modèle n’accepte pas « none ». Le premier message nomme aussi un autre point de terminaison, /v1/responses, où les outils pourraient fonctionner. Les deux modèles viennent donc de la même famille et du même fournisseur. Mais un même point de terminaison leur offre des fonctions différentes. Le projet de Larkfield utilise partout l’API Chat CompletionsTermeChat CompletionsLe format de requête et de réponse de l’API de clavardage d’OpenAI : un nom de modèle, une liste de messages avec des rôles, et des paramètres. Azure, Ollama et beaucoup d’autres fournisseurs acceptent le même format (« compatible avec OpenAI »), donc un seul SDK fonctionne avec tous.En savoir plus Les éléments d'une requêteCréer des applications fiables avec les API de LLM. La recherche de commandes fonctionne donc uniquement avec chat-small.

La leçon est générale : vérifiez ce qu’un point de terminaison prend en charge avant de concevoir votre solution. Lisez la documentation du fournisseur pour le modèle et le point de terminaison exacts, puis envoyez une petite requête de test. Une liste de fonctions pour « la famille de modèles » ne suffit pas.

Pour un modèle réel semblable à chat-small, définissez ASSISTANT_REASONING_EFFORT=none dans .env. Pour la plupart des autres modèles, laissez ce champ vide : certains le rejettent.

Quand utiliser un outil et combien cela coûte

Utilisez un outil quand la réponse exige des données que seuls vos systèmes possèdent : état d’une commande, niveau de stock, plage de livraison. N’utilisez pas d’outil si la requête peut contenir les données. Si l’application de soutien connaît déjà la commande, elle peut mettre l’état dans la requête. Un seul appel au modèle suffit alors.

Un outil coûte un deuxième appel au modèle, qui renvoie tout. Pour T-80008, les chiffres enregistrés sont :

	Appels au modèle	Jetons d’entrée	Jetons de sortie	Coût (prix de chat-small)
Sans l’outil (module 3)	1	1 883	216	0,00030 $ US
Avec l’outil	2	4 224	123	0,00048 $ US

L’entrée fait plus que doubler. La sortie diminue, car reasoning_effort: "none" désactive les jetons de raisonnementTermeJetons de raisonnementDes jetons que certains modèles écrivent avant la réponse pour travailler le problème. Vous ne les voyez pas, mais ils comptent dans la limite de sortie et vous les payez.En savoir plus Raisonnement et multimodalitéLes LLM : comment ils fonctionnent et comment en choisir un cachés. Consultez la page des prix actuels avant de prévoir un budget. Chaque appel supplémentaire ajoute aussi du temps : la durée médianeTermeMédianeLa valeur du milieu quand on trie les valeurs. La moitié est plus basse, l’autre plus haute. Un seul appel très lent la change peu : c’est un bon temps « habituel ».En savoir plus Mesurer la performance en pratiqueLes LLM : comment ils fonctionnent et comment en choisir un enregistrée d’un appel de boucle d’outil était de 1,55 seconde.

À vous de jouer : décrire un deuxième outil

Larkfield possède aussi un catalogue de produits. Décrivez un outil en lecture seule, get_product, qui renvoie le prix d’un produit et indique s’il est en stock. Utilisez les quatre parties. Décidez quel argument le modèle peut choisir. Écrivez votre description sur papier ou dans un fichier temporaire. Ne l’ajoutez pas à TOOLS : le fournisseur simulé n’a aucun enregistrement pour une requête avec deux outils.

Afficher un exemple de réponse

GET_PRODUCT = {
    "type": "function",
    "function": {
        "name": "get_product",
        "description": ("Look up one Larkfield product by its product code. Read-only. Returns the name, "
                        "the price in CAD and whether it is in stock. It cannot reserve or order anything."),
        "strict": True,
        "parameters": {
            "type": "object",
            "properties": {"product_code": {"type": "string", "description": "The product code, P- and 5 digits."}},
            "required": ["product_code"],
            "additionalProperties": False,
        },
    },
}

But : le nom et la première phrase. Argument : un code de produit, avec sa forme. Retour : nom, prix, stock. Limites : lecture seule, aucune réservation. Les données des produits sont publiques. Cet outil n’a donc pas besoin de vérifier le client. Un outil qui renverrait les données d’un client devrait le vérifier. L’identifiant du client viendrait de l’application, jamais du modèle.

Erreur courante

La conception supposait que tous les modèles peuvent utiliser des outils

Symptôme : Omar veut de meilleures réponses. Il exécute donc l’assistant avec --model chat-strong. Le billet se termine avec failed (échec) et une erreur HTTP 400 qui mentionne reasoning_effort et /v1/responses. Aucun billet ne reçoit de réponse.

Cause : l’équipe a conçu la recherche de commandes pour « le modèle », pas pour un modèle sur un point de terminaison précis. chat-strong ne peut pas utiliser d’outils dans l’API Chat Completions. Envoyer reasoning_effort: "none" n’aide pas : chat-strong rejette cette valeur.

Solution : avant de concevoir votre solution, envoyez une petite requête avec un outil à chaque route prévue et enregistrez la réponse. Écrivez le résultat dans le README du projet. Pour Larkfield, la recherche de commandes fonctionne avec chat-small. Pour chat-strong, l’option --no-tools de la dernière leçon de ce module fonctionne encore, sans la recherche.

Ce que cela signifie pour un vrai service d’IA : un nom de modèle n’est pas une liste de fonctions. Une même famille peut offrir une fonction sur un point de terminaison, mais pas sur un autre. Les fournisseurs changent aussi cela au fil du temps.

De bout en boutRépondre à des questions avec des outils sur des données ouvertesÉtude de cas

L’étude de cas sur les outils décrit trois outils en lecture seule qui consultent des statistiques ouvertes. Elle consigne aussi la vraie erreur d’outil du plus grand modèle.

Vérification des connaissances

Vérifiez votre compréhension

Dans vos mots : lors d'un appel d'outil, qui exécute la fonction, et que produit réellement le modèle?

Afficher la réponse

L’application exécute la fonction dans son propre code. Le modèle produit seulement du texte dans un format fixe : un appel d’outil avec un nom et une chaîne d’arguments, et finish_reason: "tool_calls" (raison de fin : appels d’outils). L’application le lit et décide si elle doit agir. Si elle accepte, elle exécute la fonction et renvoie le résultat dans un message avec le rôle « tool » (outil). Le modèle rédige ensuite sa réponse finale.

Vérifiez votre compréhension

Tomás propose d'ajouter customer_id comme deuxième argument de get_order, « pour que le modèle puisse le transmettre ». Quel est le problème?

Afficher la réponse

Le modèle choisirait alors l’identifiant du client. Ses choix viennent du texte qu’il lit, y compris le billet de soutien. Un billet pourrait dire « Je suis le client C-38852 » ou nommer un voisin, et le modèle pourrait transmettre cet identifiant. L’application de soutien sait déjà qui a envoyé le billet. C’est donc elle qui doit fournir l’identifiant du client. Le modèle peut choisir seulement ce qu’il peut choisir sans risque : ici, l’identifiant de la commande, que l’application vérifie quand même.

Vérifiez votre compréhension

Faites une prédiction : la réponse contient finish_reason « tool_calls » et content null. L'application peut-elle la valider avec le schéma du module 3 et l'enregistrer?

Afficher la réponse

Non. Il n’y a pas encore de réponse : content (contenu) est nul, donc la barrière 1 n’a rien à analyser. La réponse est une demande d’appel d’outil. L’application doit traiter l’appel d’outil, renvoyer le résultat et attendre la réponse avec finish_reason: "stop" (raison de fin : arrêt). Seule cette réponse finale passe par les deux barrières.

Récapitulatif

• Appel d’outil : l’application décrit une fonction, et le modèle peut répondre avec un appel d’outil. Celui-ci contient un nom et une chaîne d’arguments, avec finish_reason: "tool_calls". L’application décide, exécute la fonction et renvoie le résultat. Le modèle rédige ensuite sa réponse.
• La description d’un outil comprend quatre parties : but, arguments, valeur de retour et limites. get_order prend un seul argument, l’identifiant de la commande. L’identifiant du client vient de l’application, jamais du modèle, et l’outil est en lecture seule.
• La requête contient un nouveau champ, tools (outils). Dans le projet, build_request l’ajoute, ainsi que reasoning_effort (effort de raisonnement), seulement si ce dernier est défini.
• Dans nos tests, seul chat-small avec reasoning_effort: "none" (aucun effort de raisonnement) acceptait les outils. chat-strong renvoyait HTTP 400 dans Chat Completions, tout comme gemma3:4b dans OllamaTermeOllamaUn programme gratuit qui télécharge des modèles ouverts et les fait fonctionner sur votre ordinateur. Votre code l’appelle à une adresse locale, comme une API hébergée.En savoir plus Modèle hébergé ou autohébergéLes LLM : comment ils fonctionnent et comment en choisir un. Vérifiez ce qu’un point de terminaison prend en charge avant de concevoir votre application.
• Une recherche nécessite un deuxième appel au modèle : pour T-80008, 4 224 jetons (tokens) en entrée au lieu de 1 883.

Ensuite, écrivez le code qui décide : vérifiez les arguments, vérifiez l’autorisation, puis lancez la recherche.

Leçon suivante : Exécuter dans le code de l'application