Limites entre flux de travail et agent

Ce que vous saurez faire

Voyez la différence entre un flux de travail et un agent dans un vrai billet de soutien. Qui décide de chaque étape, le code ou le modèle? Configurez ensuite le projet du cours pour pouvoir exécuter vous-même chaque conception.

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

Ce que vous devez savoir

• Comment une application offre un outil à un modèle et exécute elle-même l’appel. Voir Exécuter dans le code de l’application dans Créer des applications fiables avec les API de LLM.
• Pourquoi une boucle avec un modèle a besoin de limites. Voir Limiter la boucle.
• Ce qu’est un jeu d’évaluation. Voir Choisir des cas représentatifs dans Évaluer et tester les systèmes d’IA. La leçon 3 de ce module en utilise un.

Ce qu’il vous faut sur votre ordinateur

• Python 3.12 ou une version plus récente, et un terminal. Isoler les dépendances explique le fonctionnement d’un environnement virtuel.
• Un éditeur comme VS Code et une connexion Internet pour télécharger le projet et ses paquets (environ 70 Mo avec l’environnement).
• Git est facultatif : un fichier ZIP convient aussi.

Vous n’avez besoin d’aucun compte, d’aucune clé d’API et d’aucun paiement. Chaque décision du modèle dans ce cours correspond à une vraie réponse enregistrée, que le projet rejoue.

Testé avec Python 3.12.13 sur macOS (Apple silicon), avec openai 3.27.0, pydantic 2.14.0 et pytest 9.1.1. Les commandes Windows et Linux suivent le cours de Python; elles n’ont pas été exécutées pour cette leçon.

Les modèles et les cadriciels d’agents changent vite. Les chiffres de ce cours représentent donc un moment précis. La méthode reste utile plus longtemps que les chiffres.

Une recette et un cuisinier

Vous pouvez préparer le souper de deux façons. Avec une recette, chaque étape est écrite avant de commencer : coupez l’oignon, faites-le frire cinq minutes, ajoutez le riz. Vous suivez les étapes dans l’ordre. Si le magasin n’avait pas d’oignons, la recette ne vous dit pas quoi faire.

Vous pouvez aussi demander à un cuisinier de préparer quelque chose avec le contenu du réfrigérateur. Il regarde, décide quoi préparer et choisit chaque prochaine étape selon ce qu’il trouve. Un bon cuisinier sait composer avec l’oignon manquant. Mais vous ne pouvez pas connaître les étapes à l’avance. Le même réfrigérateur peut donner deux soupers différents, deux soirs de suite.

La plupart des cuisines utilisent les deux. Le menu du restaurant est un ensemble de recettes. Le cuisinier décide seulement là où la recette ne peut pas le faire.

Le problème : qui décide de la prochaine étape?

Dans Créer des applications fiables avec les API de LLM, l’assistant de Larkfield lisait un billet, consultait la commande et rédigeait une réponse. Une personne faisait le reste. Grace, la responsable du soutien, en veut maintenant plus. Pour les cas courants, comme une livraison en retard ou un article endommagé, le système doit résoudre le billet. Il consulte les faits, applique sa politique et propose une action, comme une étiquette de retour ou un remboursement.

Pour résoudre un billet, il faut prendre cinq décisions. Que demande le billet? De quelle commande s’agit-il? Quels faits faut-il lire? Que devrait-il se passer? Et que dit la réponse?

Tomás, un ingénieur en IA, a une réponse rapide : « Faisons-en un agent et laissons le modèle tout décider. » Grace a une autre préoccupation : « Montrez-moi exactement ce que vous allez faire avant de le faire. » Les deux ont raison sur un point. Mais aucun ne dit qui devrait prendre chacune des cinq décisions. C’est la question de ce module.

L’idée : un flux de travail, un agent et la limite entre les deux

Un flux de travail est une tâche dont les étapes sont fixées dans le code, comme une recette. Le code décide de la suite. Un modèle peut quand même faire un travail dans une étape, par exemple rédiger la réponse.

Un agent est un modèle qui choisit sa prochaine étape, comme le cuisinier. Il fonctionne en boucle : il demande un outil, voit le résultat, puis décide à nouveau. Cet outil est une fonction que l’application exécute, comme get_order. Il s’arrête quand il pense avoir terminé la tâche. Le nom indique la nouveauté : le modèle agit pour accomplir la tâche, comme un agent agit pour un client. Il fait plus que rédiger du texte.

Entre les deux se trouve le routeur. Le modèle prend une seule décision : quel chemin le billet suit. Le code fait tout le reste. Le routage consiste à envoyer chaque élément vers le bon chemin, comme un bureau de poste trie les lettres.

L’orchestration désigne tout le travail d’organisation des étapes : lesquelles s’exécutent, dans quel ordre et qui décide. Ce cours porte sur l’orchestration. L’image montre la limite entre le code et le modèle dans les trois conceptions. Chaque case représente une des cinq décisions.

Qui prend chacune des cinq décisions dans les trois conceptions du projet. Cases vertes : le code. Cases bleues avec une bordure épaisse : le modèle.

Description textuelle du diagramme

Trois conceptions, chacune avec les mêmes cinq décisions. De haut en bas : la demande du billet, la commande, les faits à lire, la proposition et les mots de la réponse.

1. Flux de travail fixe : le code prend les quatre premières décisions. Des listes de mots-clés trouvent la demande du billet. Une expression régulière trouve l’identifiant de la commande. Le code lit toujours la commande. Le fichier rules.py décide de la proposition. Le modèle rédige seulement la réponse, en un appel.
2. Routeur : le modèle décide de la demande du billet et de la commande, en une réponse : le chemin. Ensuite, le code décide des lectures et de la proposition, avec le même fichier rules.py. Le modèle rédige la réponse.
3. Agent : le modèle prend les cinq décisions. Son premier appel d’outil montre sa compréhension de la demande du billet et de la commande concernée. Il choisit chaque prochaine lecture. Son dernier appel, finish, contient la proposition et la réponse.

Lisez l’image de gauche à droite : les cases bleues deviennent plus nombreuses. Chaque case bleue représente un endroit où le résultat peut changer d’une exécution à l’autre. La formulation d’un nouveau billet y compte aussi. Chaque case verte donne toujours la même réponse pour la même entrée. La leçon 3 de ce module mesure le coût de chacune.

Configurer le projet

Le projet de ce cours est resolution-workflow. Il se trouve dans le dépôt de laboratoires de Nextia Learning, sous forme d’instantanés. Ce sont des copies du projet au début et à la fin de chaque module. Vous commencez avec start (début).

Les billets, les commandes et les paiements sont inventés pour ce cours. Aucun vrai client ne les a écrits. Chaque écriture va dans une base de données locale d’exercice : un fichier SQLite dans le dossier du projet. Rien n’atteint un vrai système. Jusqu’au module 4, rien n’est écrit : chaque conception fait seulement une proposition.

Obtenir les fichiers

1. Ouvrez un terminal et allez dans votre dossier de projets. S’il n’existe pas, créez-le d’abord avec mkdir ~/projects.

   cd ~/projects

2. Si vous avez Git, clonez le dépôt de laboratoires :

   git clone https://github.com/Nextia-Intelligence/nextia-learning-labs.git

   Si vous n’avez pas Git, téléchargez le fichier ZIP du dépôt. Décompressez-le dans ~/projects. Son dossier s’appelle nextia-learning-labs-main : utilisez ce nom à la prochaine étape.

3. Copiez l’instantané start dans un nouveau dossier, resolution-workflow :

   macOS

   cp -R nextia-learning-labs/C10/snapshots/start resolution-workflow

   Windows

   Copy-Item -Recurse nextia-learning-labs\C10\snapshots\start resolution-workflow

   Linux

   cp -R nextia-learning-labs/C10/snapshots/start resolution-workflow

4. Allez dans le projet et ouvrez-le dans votre éditeur :

   cd resolution-workflow
   code .

   Si code est introuvable, ouvrez le dossier à partir du menu File (fichier) de l’éditeur.

Vous travaillez dans votre copie. Le dossier de laboratoires reste intact. Vous pouvez donc recopier un instantané à tout moment.

Créer l’environnement

1. Créez et activez un environnement virtuel :

   macOS

   python3 -m venv .venv
   source .venv/bin/activate

   Windows

   python -m venv .venv
   .venv\Scripts\Activate.ps1

   Linux

   python3 -m venv .venv
   source .venv/bin/activate

   L’invite commence maintenant par (.venv). À partir d’ici, tapez python sur tous les systèmes.

2. Installez les paquets :

   python -m pip install -r requirements.txt

   La dernière ligne de la sortie :

   Successfully installed annotated-types-0.8.0 anyio-4.15.1 h11-0.16.0 httpcore2-2.13.1 httpx2-2.13.1 idna-3.20 iniconfig-2.3.1 jiter-0.17.0 openai-3.27.0 packaging-26.3 pluggy-1.6.0 pydantic-2.14.0 pydantic-core-2.50.0 pygments-2.21.0 pytest-9.1.1 sniffio-1.3.1 truststore-0.10.4 typing-extensions-4.16.0 typing-inspection-0.4.4

   Vous pouvez ignorer sans risque l’avis concernant une nouvelle version de pip.

requirements.txt demande trois paquets : openai, pydantic et pytest. Les autres sont nécessaires à ces trois paquets. Le projet n’utilise aucun cadriciel d’agents : du Python simple montre chaque étape. Le module 4 compare un cadriciel à cette approche.

La première exécution au résultat connu

1. Exécutez les tests :

   python -m pytest

   La fin de la sortie :

   tests/test_config.py ..                                                  [ 14%]
   tests/test_first_run.py ..                                               [ 28%]
   tests/test_replay.py ....                                                [ 57%]
   tests/test_tools.py ......                                               [100%]
   
   ============================== 14 passed in 0.64s ==============================

2. Exécutez le premier billet du cours, T-80008 :

   python -m resolver run T-80008

   La sortie :

   Run T-80008-agent-chat-small | single agent with tool calling: the model chooses every step | chat-small
   Outcome: reply_only (rule W1) | 2 model call(s), 1 tool call(s) | 4580 tokens in, 117 out | US$0.00052
   Reply draft: Your garden shed order LK-581106 shipped on Monday, October 5. Its expected delivery date is Tuesday, October 13. It is currently in transit, and there is no delivery date showing yet.

Votre sortie doit être identique, caractère par caractère, sauf pour la durée des tests. Le fournisseur simulé rejoue les réponses enregistrées d’un vrai modèle, gpt-6-luna sous le nom chat-small sur Azure. Rien n’est donc aléatoire. US$0.00052 est le coût des appels enregistrés; votre exécution n’a rien coûté. La première exécution a aussi créé work/larkfield.sqlite, votre base de données d’exercice : une copie de data/larkfield.sqlite.

La vérification de la configuration. Les 14 tests réussis et la ligne au résultat connu pour T-80008 indiquent que vous êtes prêt.

Description textuelle du diagramme

Exécutez d’abord python -m pytest. Si vous ne voyez pas « 14 passed » (14 tests réussis), vérifiez que l’invite commence par (.venv). Réinstallez les dépendances et relancez les tests. Quand vous voyez « 14 passed », exécutez python -m resolver run T-80008. Si la ligne Outcome (résultat) se termine par « 4580 tokens in, 117 out » (4 580 jetons en entrée, 117 en sortie), la configuration fonctionne. Sinon, réinitialisez : recopiez l’instantané start dans un nouveau dossier, créez un nouvel environnement .venv et recommencez les vérifications.

Le contenu du projet

Chemin	Ce qu’il contient
data/	Les 70 tâches (tasks.jsonl), la base de données d’exercice, la politique de Grace et 24 passages de cette politique. dataset.md les décrit.
recordings/	Les décisions enregistrées du modèle, un fichier par conception et par modèle.
resolver/workflow.py	Le flux de travail fixe et le routeur.
resolver/agent.py, resolver/loop.py	L’agent et la boucle qui l’entoure.
resolver/rules.py	Les règles W1 à W8 de Grace, écrites sous forme de code.
resolver/tools.py	Les outils de lecture : get_order, get_customer_orders, get_payments, search_policy.
tests/	Les 14 tests que vous avez exécutés.

Réinitialiser le projet

Pour recommencer, désactivez l’environnement et renommez votre dossier. Utilisez par exemple mv resolution-workflow resolution-workflow-old, ou Rename-Item sur Windows. Puis recopiez l’instantané. Pour réinitialiser seulement la base de données d’exercice, supprimez le dossier work. La prochaine commande crée une nouvelle copie.

Un billet, trois conceptions

Passons maintenant à l’essentiel. T-90103 est un billet simple que chaque conception résout correctement. Vous pouvez donc comparer comment elles réussissent, et non si elles réussissent.

1. Affichez le billet et ce que la politique de Grace prévoit :

   python -m resolver show T-90103 --expected

   T-90103 | customer C-50533 | slice simple
   Attachments: IMG_3381.jpg
   My cedar planter (order LK-640436) came with one side panel cracked right through. It must have happened in transit, the box was crushed. I've attached a photo. I'd like a replacement please.
   Expected: resolve (rule W5) [{'order_id': 'LK-640436', 'quantity': 1, 'sku': 'PLANTER', 'tool': 'reship_item'}, {'order_id': 'LK-640436', 'reason': 'damaged', 'sku': 'PLANTER', 'tool': 'create_return_label'}]
   Why: Delivered 5 October, photo, 89 dollars: reship and a free return label for the damaged planter.

2. Exécutez le flux de travail fixe, avec sa trace :

   python -m resolver run T-90103 --variant fixed --trace

3. Exécutez le routeur et l’agent de la même façon, avec --variant router et --variant agent.

La ligne Expected (attendu) est l’étiquette de la tâche : le résultat et les actions exactes prévues par la politique. L’auteur du cours a écrit les résultats attendus en appliquant la politique écrite de Grace. Un script les a vérifiés. C’est l’interprétation d’une personne; une autre pourrait trancher certains cas limites différemment.

La règle W5 de la politique de Grace couvre un article endommagé. Dans les 14 jours, avec une photo, envoyez-en un nouveau s’il est en stock. Les articles de 50 dollars ou plus reçoivent aussi une étiquette de retour gratuite. Les trois conceptions proposent exactement cela. Les traces montrent qui l’a décidé. Une trace est la chronologie d’une exécution. Elle contient une ligne par événement, comme un appel au modèle, un appel d’outil ou la proposition. Voici la trace du flux de travail fixe :

  0  note      keywords {"rule": null, "request_kind": "damaged"}
  0  tool      get_order({"order_id": "LK-640436"}) -> ok
  1  model     chat-small: fixed  (352 in, 28 out, 1.057 s)
  1  proposal  resolve (W5): reship_item LK-640436, create_return_label LK-640436
  1  stop      finished

Le code a trouvé le mot « cracked » (fissuré) dans une liste de mots-clés. Il a classé la demande comme damaged (endommagé). Le code a lu la commande, et rules.py a produit la proposition. Le modèle a été appelé une fois, à l’étape 1, seulement pour rédiger la réponse. La trace du routeur commence plutôt par un appel au modèle :

  1  model     chat-small: router  (1799 in, 41 out, 1.098 s)
  1  note      route {"path": "damaged", "rule": null, "order_id": "LK-640436", "product": "cedar planter", "item_used":…
  1  tool      get_order({"order_id": "LK-640436"}) -> ok
  2  model     chat-small: router_draft  (352 in, 28 out, 1.057 s)
  2  proposal  resolve (W5): reship_item LK-640436, create_return_label LK-640436

Le modèle a lu le billet et choisi le chemin damaged, avec la commande et le produit. Ensuite, le même code que celui du flux de travail fixe a pris le relais. Dans la trace de l’agent, les deux appels au modèle sont des décisions :

  1  model     chat-small: get_order({"order_id":"LK-640436"})  (2185 in, 21 out, 1.099 s)
  1  tool      get_order({"order_id": "LK-640436"}) -> ok
  2  model     chat-small: finish({"outcome":"resolve","rule":"W5","actio…)  (2433 in, 199 out, 2.295 s)
  2  proposal  resolve (W5): reship_item LK-640436, create_return_label LK-640436

Le modèle a choisi de lire la commande, puis a lui-même rédigé toute la résolution dans un appel à finish (terminer). Le code a quand même exécuté la lecture et vérifié la résolution, mais il n’a décidé ni de l’une ni de l’autre. Les lignes de coût indiquent le prix de cette liberté. Le flux de travail fixe a utilisé 352 jetons en entrée, le routeur 2 151 et l’agent 4 618.

Parcourez les trois exécutions dans l’explorateur. Regardez les pastilles en haut : elles montrent qui est responsable de chacune des cinq décisions.

Explorer

Un billet dans un flux de travail fixe, un routeur et un agent

T-90103, client C-50533 : “My cedar planter (order LK-640436) came with one side panel cracked right through. It must have happened in transit, the box was crushed. I've attached a photo. I'd like a replacement please.” Pièce jointe : IMG_3381.jpg.

La politique de Grace prévoit resolve (règle W5). Enregistrements réels : gpt-6-luna comme chat-small sur Azure, rejoués par le code du projet.

Qui décide (flux de travail fixe)

• Code Que demande le billet?
• Code Quelle commande?
• Code Quels faits lire?
• Code Que proposer?
• Modèle Les mots de la réponse

Appels au modèle

1

Jetons jusqu’ici

352 en entrée, 28 en sortie

Décisions jusqu’ici

4 par le code, 1 par le modèle

Résultat

resolve (W5)

Flux de travail fixe, étape 6 sur 6. 1 appel(s) au modèle, 352 jetons en entrée, 0,00005 $ US. C’est ce que la politique de Grace prévoit : resolve (règle W5).

1. 1 Code Listes de mots-clés : le type est damaged décide : ce que demande le billet

   Le billet contient « cracked », donc le type est damaged. Aucun mot-clé H1-H5 ne correspond.

2. 2 Code Une expression régulière trouve LK-640436 décide : dans quel ordre

   Le motif LK- suivi de six chiffres trouve le numéro de commande dans le texte du billet.

3. 3 Code Lit get_order(LK-640436) décide : quels faits lire

   Pour ce type, le code lit toujours la commande. Résultat : LK-640436: delivered 2026-10-05, 4 days ago; cedar planter 89.00 dollars (in stock).

4. 4 Code Décide dans le code : resolve (règle W5) décide : quoi proposer

   rules.py applique la règle W5 : delivered 4 days ago; in stock: True. Proposition : reship_item LK-640436 PLANTER x1; create_return_label LK-640436 PLANTER (damaged).

5. 5 Modèle Le modèle rédige la réponse à partir de la décision décide : les mots de la réponse

   We’ll arrange a replacement cedar planter and provide a return label for the damaged one once a team member has checked your ticket.

   352 jetons en entrée, 28 en sortie, 1,06 s

6. 6 Code Proposition : resolve (règle W5), en attente de l’approbation d’une personne

   Rien n’est écrit. Chaque conception ne fait que proposer; l’approbation d’une personne vient au module 4.

T-90103, de vrais enregistrements de gpt-6-luna sous le nom chat-small sur Azure, rejoués par le code du projet. Vert : le code décide. Bleu : le modèle décide.

Description textuelle de l’explorateur

L’explorateur montre le billet T-90103, la jardinière en cèdre fissurée, et une conception à la fois. Cinq pastilles montrent les points de décision : la demande du billet, la commande, les faits à lire, la proposition et les mots de la réponse. Chaque pastille indique Code (code) ou Model (modèle).

Flux de travail fixe, 6 étapes. 1, code : les listes de mots-clés trouvent « cracked », donc le type est damaged (endommagé). 2, code : une expression régulière trouve LK-640436. 3, code : il lit get_order; la jardinière a été livrée le 5 octobre, il y a 4 jours, coûte 89,00 dollars et est en stock. 4, code : rules.py applique W5 et propose reship_item (renvoyer l’article) et create_return_label (créer une étiquette de retour). 5, modèle : il rédige la réponse (352 jetons en entrée, 28 en sortie). 6 : la proposition attend l’approbation d’une personne; rien n’est écrit. Quatre décisions prises par le code, une par le modèle.

Routeur, 5 étapes. 1, modèle : il choisit le chemin damaged, avec la commande LK-640436 (1 799 jetons en entrée, 41 en sortie). 2, code : il lit la commande. 3, code : rules.py applique W5. 4, modèle : il rédige la réponse. 5 : la proposition. Deux décisions prises par le code, trois par le modèle.

Agent, 5 étapes. 1, modèle : il demande get_order avec LK-640436 (2 185 jetons en entrée, 21 en sortie). 2, code : il vérifie que la commande appartient à ce client et exécute la lecture. 3, modèle : il écrit la résolution avec finish (2 433 jetons en entrée, 199 en sortie). 4, code : il vérifie la résolution et l’accepte. 5 : la proposition. Aucune décision prise par le code, cinq par le modèle; le code exécute et vérifie seulement.

Dans l’agent, le code ne prend aucune des cinq décisions. Il a quand même un rôle : exécuter la lecture, vérifier que la commande appartient à ce client et vérifier la structure de la résolution. Cette limite entre décider et vérifier revient dans chaque module.

Exercice guidé : la commande du voisin

T-80001 porte sur la commande d’un autre client. Tom écrit pour sa voisine, Mrs Okafor. La règle H4 dit : une personne s’en occupe. Prédisez, pour chaque conception, si elle lit la commande avant de décider.

1. Affichez le billet : python -m resolver show T-80001 --expected. Le résultat attendu est hand_to_person (rule H4) (confier à une personne, règle H4).

2. Exécutez les trois conceptions :

   python -m resolver run T-80001 --variant fixed
   python -m resolver run T-80001 --variant router
   python -m resolver run T-80001 --variant agent

3. Vérifiez la deuxième ligne de chaque sortie. Les trois se terminent par hand_to_person (rule H4).

Afficher les trois lignes de résultat et leur signification

Outcome: hand_to_person (rule H4) | 1 model call(s), 0 tool call(s) | 299 tokens in, 18 out | US$0.00004
Outcome: hand_to_person (rule H4) | 2 model call(s), 0 tool call(s) | 2111 tokens in, 57 out | US$0.00024
Outcome: hand_to_person (rule H4) | 1 model call(s), 0 tool call(s) | 2192 tokens in, 99 out | US$0.00027

Aucune conception n’a lu la commande : 0 tool call(s) (0 appel d’outil) partout. Le flux de travail fixe a trouvé « my neighbour » (mon voisin) dans sa liste de mots-clés H4. Le routeur a choisi le chemin hand_to_person (confier à une personne) avec la règle H4. L’agent a fait un seul appel : il est allé directement à finish. Cela montre une deuxième liberté de l’agent. Il choisit non seulement les étapes à suivre, mais aussi leur nombre. Ici, il a suivi moins d’étapes que le routeur.

À vous de jouer : deux commandes de chaises de jardin

T-90207 dit : « Une des chaises de jardin achetées chez vous est arrivée avec une patte cassée. Photo jointe. » Le client a deux commandes contenant chacune deux chaises de jardin, et ne donne aucun identifiant de commande. La politique de Grace prévoit ask_customer (demander au client) : demander de quelle commande il s’agit. Avant toute exécution, prédisez quelles conceptions posent la question et laquelle propose un changement. Exécutez ensuite les trois conceptions avec --trace.

Afficher la réponse

Le flux de travail fixe et le routeur demandent l’identifiant de commande : ask_customer. Leur code a dressé la liste des commandes du client, trouvé plusieurs correspondances pour « chaise », puis s’est arrêté. L’agent a lu la liste, puis les deux commandes, et proposé reship_item LK-641654 (réexpédier l’article LK-641654). Il propose une nouvelle chaise pour une des deux commandes, choisie par le modèle.

  2  model     chat-small: get_order({"order_id": "LK-641654"}), get_order({"order_id": "LK-641543"})  (2281 in, 55 out, 1.218 s)
  3  proposal  resolve (W5): reship_item LK-641654

L’agent a vu les mêmes faits que le code, puis a deviné. Rien dans sa sortie ne dit qu’il a deviné. Si une personne approuvait cette proposition sans la lire, une chaise serait envoyée pour une commande peut-être incorrecte. Le module 4 met en place l’approbation qui empêche cela.

Erreur courante

Arrêt : no_recording

Symptôme : Tomás veut utiliser le modèle plus puissant comme agent et exécute :

python -m resolver run T-90103 --variant agent --model chat-strong

La sortie ne contient aucune proposition :

Run T-90103-agent-chat-strong | single agent with tool calling: the model chooses every step | chat-strong
Stopped: no_recording. No proposal: the ticket goes to a person.

Cause : le fournisseur simulé rejoue seulement les décisions enregistrées. chat-strong ne peut pas faire d’appels d’outils dans Chat Completions; Décrire un outil a montré son erreur HTTP 400 réelle. Le cours a donc enregistré chat-strong avec --variant agent_structured : la même boucle, avec une étape JSON par appel. Aucun enregistrement n’existe pour chat-strong avec --variant agent.

Solution : exécutez python -m resolver run T-90103 --variant agent_structured --model chat-strong. Il propose la même réexpédition et la même étiquette.

Ce que cela signifie : une exécution qui ne peut pas obtenir de décision s’arrête et confie le billet à une personne. Elle ne plante pas et ne devine pas. Le module 2 donne un nom à chaque arrêt de ce genre.

Quelle conception utiliser

Les trois conceptions ont bien traité le cas de la jardinière. Elles diffèrent par leur coût et les erreurs qu’elles peuvent faire. Le flux de travail fixe coûte peu et fonctionne toujours de la même façon. Mais il connaît seulement les mots de ses listes. Le routeur laisse le modèle lire le billet une fois et garde le reste dans le code. L’agent peut traiter un billet que personne n’avait prévu. Mais il prend plus de décisions et peut donc se tromper à plus d’endroits, comme l’a montré T-90207.

La prochaine leçon nomme cinq modèles courants qui se situent entre ces conceptions. La leçon 3 mesure ensuite les trois conceptions sur les 70 tâches et donne à Tomás une réponse chiffrée.

Vérification des connaissances

Vérifiez votre compréhension

Dans vos mots : quelle est la différence entre un flux de travail et un agent? Utilisez les cinq décisions d'un billet de soutien dans votre réponse.

Afficher la réponse

Dans un flux de travail, le code décide des étapes. Pour un billet, le code détermine la demande et la commande concernée. Il décide aussi quels faits lire et quoi proposer. Un modèle peut accomplir une tâche dans une étape, comme rédiger la réponse. Dans un agent, le modèle choisit sa prochaine étape dans une boucle. Il décide quels outils appeler, dans quel ordre, combien en appeler et quoi proposer. Le code exécute toujours chaque outil et vérifie chaque proposition, mais il ne les choisit pas.

Vérifiez votre compréhension

Prédisez : un client écrit un nouveau billet avec des mots absents des listes de mots-clés. Quelle conception risque le plus de mal le comprendre, et pourquoi?

Afficher la réponse

Le flux de travail fixe. Son code détermine la demande du billet en cherchant des mots dans des listes fixes. Les mots absents des listes ne correspondent à rien, et le code suit alors un chemin par défaut. Le routeur et l’agent demandent au modèle de lire le billet. Un modèle peut comprendre des mots que personne n’a mis dans une liste. La leçon 3 mesure cela sur huit billets rédigés avec de nouveaux mots.

Vérifiez votre compréhension

Vérification pratique : exécutez T-90207 avec l'agent et avec le routeur. Que propose chacun? Quelle proposition modifierait la base de données d'exercice si une personne l'approuvait sans la lire?

Afficher la réponse

Le routeur propose ask_customer : il demande de quelle commande il s’agit, car le client a deux commandes de chaises de jardin. L’agent propose resolve (résoudre) avec reship_item LK-641654, une nouvelle chaise pour une commande choisie par le modèle. Seule la proposition de l’agent contient une action. Elle seule modifierait donc la base de données si elle était approuvée. La politique prévoit ask_customer.

Études de cas de ce cours

À la fin du cours, vous appliquez ce que vous avez appris à un projet réaliste, des données jusqu’à la recommandation. Terminez-en au moins une pour obtenir le certificat; les autres sont facultatives.

• Évaluer un agent de service à la clientèle sur un banc d'essai publicExécuter un agent sur des tâches publiques de service à la clientèle, avec des outils simulés et une politique écrite, puis mesurer la réussite des tâches, les violations de la politique et les effets de bord sur plusieurs exécutions.
• Tester un agent contre les instructions cachées dans les résultats d'outilsMesurer combien de fois des instructions cachées dans les résultats d'outils prennent le contrôle d'un agent, avec et sans défenses, et combien de fois l'agent termine quand même sa tâche.
• Flux de travail ou agent? Automatiser un processus à partir de données ouvertesAutomatiser deux fois un processus de service public à partir de données ouvertes, d'abord en flux de travail fixe, puis avec un agent, et comparer les erreurs, le coût et le temps sur les mêmes tâches.

Récapitulatif

• Un flux de travail fixe les étapes dans le code. Un agent est un modèle qui choisit sa prochaine étape dans une boucle, avec des outils exécutés par l’application. Un routeur laisse le modèle choisir un chemin, puis le code fait le reste.
• L’orchestration organise les étapes : lesquelles exécuter, dans quel ordre et qui décide. Pour un billet de soutien, il y a cinq décisions.
• Pour T-90103, les trois conceptions ont proposé la même résolution. Le flux de travail fixe a pris quatre décisions dans le code et utilisé 352 jetons d’entrée. L’agent a pris les cinq décisions avec le modèle et utilisé 4 618 jetons d’entrée.
• Plus le modèle prend de décisions, plus une nouvelle formulation ou une supposition peut changer le résultat à différents endroits. La chaise proposée par l’agent pour T-90207 l’a montré.
• La première exécution dont on connaît le bon résultat : python -m pytest donne 14 passed (14 tests réussis). Puis python -m resolver run T-80008 se termine par 4580 tokens in, 117 out | US$0.00052 (4 580 jetons d’entrée, 117 de sortie | 0,00052 $ US). Chaque conception propose seulement; rien n’est écrit avant le module 4.

Vous découvrirez ensuite cinq modèles qui combinent ces conceptions, chacun avec un billet de Larkfield.

Leçon suivante : Modèles courants