Travail final

Après les études de cas
environ 5 h

Ce que vous saurez faire

Appliquez chaque module du cours à un changement qu’une vraie équipe pourrait demander. Vous ajoutez une règle de politique et un outil à l’assistant. Vous prouvez, avec des tests et des mesures, qu’il reste fiable, sûr et abordable.

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

Vous avez terminé les modules 1 à 6. Chaque partie ci-dessous nomme les leçons qu’elle utilise.
Vous n’avez pas besoin des études de cas pour ce travail. Le certificat exige au moins une étude de cas.
Partez de votre propre ticket-assistant à la fin du module 6. Vous pouvez aussi copier l’instantané end-of-m06 du cours depuis le dépôt des exercices, comme dans Tester et empaqueter. Exécutez d’abord python -m pytest : tous les tests doivent réussir avant tout changement.
La partie 3 exige des appels à un modèle en direct, car les réponses enregistrées ne peuvent pas répondre à une nouvelle requête. Utilisez un modèle local gratuit avec Ollama, comme dans Tester et empaqueter, ou votre propre clé. Aucun paiement n’est nécessaire : un modèle local suffit pour réussir.
Testé avec Python 3.12 et les versions de requirements.txt, sur macOS.

Le changement : les rétrofacturations et « mes commandes »

Grace a deux nouvelles demandes.

La première est une nouvelle règle. Certains clients écrivent qu’ils demanderont à leur banque d’annuler un paiement, une rétrofacturation, ou qu’ils ont déjà ouvert une contestation. Ces billets de soutien nécessitent l’intervention d’une personne de l’équipe des paiements. Le remboursement est peut-être déjà en cours, et une mauvaise réponse peut coûter deux fois le montant à la boutique. Grace ajoute la règle H6 à la politique : Un billet qui mentionne une rétrofacturation, une contestation de paiement auprès de la banque ou un paiement par carte annulé va à l’équipe des paiements. Une personne doit le traiter.

La deuxième est un nouvel outil. Les agents demandent souvent : « Qu’est-ce que ce client a commandé d’autre? » Amira veut un outil en lecture seule, list_my_orders, qui renvoie les commandes récentes du client actuel. Tomás propose un outil list_orders(customer_id), « pour que le modèle puisse consulter les commandes de n’importe qui ». Priya rappelle ce que vous avez appris dans Exécuter dans le code de l’application : l’argument le plus sûr est celui que le modèle ne choisit jamais.

Omar pose la question qui détermine si le changement sera livré : « L’assistant dirige-t-il toujours aussi bien les billets? Et combien coûte-t-il maintenant par 1 000 billets? »

Les billets et les commandes sont synthétiques. Aucun vrai client.

Partie 1 : écrire la règle et les billets de test

Utilise Préciser la tâche et Comparer des requêtes.

Écrivez H6 dans vos propres mots, avec autant de précision que les règles H1 à H5 dans assistant/prompts/policy.md. Gardez-la dans une note pour l’instant : la partie 3 l’ajoute à la requête v3. Ne modifiez pas policy.md lui-même. Chaque version de requête envoie ce fichier. Un seul caractère modifié change donc chaque requête enregistrée, et les tests ne retrouvent plus leurs enregistrements. C’est le FailureCase de Tester et empaqueter.
Écrivez 8 nouveaux billets dans un fichier data/h6_tickets.csv, avec les mêmes colonnes que data/tickets.csv. Incluez au moins 3 billets couverts par H6, dont un en français. Ajoutez 2 cas proches que H6 ne couvre pas. Par exemple : « Je ne veux pas lancer une rétrofacturation, je veux simplement mon remboursement », ou une contestation de date de livraison. Ajoutez 1 billet combinant une rétrofacturation et un problème de sécurité, puis 2 billets ordinaires. Donnez à chacun les valeurs attendues de team (équipe) et de needs_human (intervention humaine nécessaire).
Décidez comment H6 traite un cas proche. Écrivez cette décision en une phrase à côté de la règle, puis étiquetez les cas proches selon cette décision. Il n’y a pas une seule bonne réponse; il faut une réponse claire.

Partie 2 : rendre la règle difficile à contourner

Utilise Définir un schéma et Valider le sens.

Ajoutez une vérification de règle d’affaires à check_rules dans assistant/validate.py. Quand un billet correspond à H6, la réponse doit indiquer l’équipe des paiements dans team et vrai dans needs_human. Sinon, elle est rejetée avec le code de problème chargeback_needs_human.
Écrivez le motif de détection pour que les cas proches suivent votre phrase de politique. Montrez avec des tests qu’il détecte tous vos billets H6 et traite chaque cas proche selon votre décision.
Ajoutez des tests avec des réponses construites (sans modèle), comme dans l’exercice du module de Valider le sens. Une réponse conforme au schéma qui dirige une rétrofacturation vers l’équipe de livraison doit être rejetée. Une réponse correcte doit réussir. Prouvez ensuite qu’une réponse rejetée ne peut pas être enregistrée : ResultStore.save() doit lever InvalidResult, comme dans cet exercice.
Exécutez toute la suite de tests. Si votre motif correspond à un des 69 anciens billets, une réponse enregistrée auparavant acceptée pourrait maintenant être rejetée. Examinez chacun de ces billets et décidez si la règle ou l’étiquette est correcte.

Partie 3 : comparer équitablement la requête v3

Utilise Préciser la tâche, Fournir le contexte en toute sécurité et Comparer des requêtes.

Copiez assistant/prompts/v2.md dans v3.md. Ajoutez H6 et ce dont le modèle a besoin pour l’appliquer. Remplacez « H1 to H5 » (H1 à H5) par « H1 to H6 » (H1 à H6). Gardez le texte du billet marqué comme non fiable, comme dans v2.
Deux petits changements dans assistant/__main__.py préparent eval : ajoutez "v3" aux choix de --prompt. Ajoutez aussi une option comme --tickets PATH, qui transmet un autre fichier CSV à load_tickets(). Sans ces changements, --prompt v3 est refusé et eval lit seulement data/tickets.csv.
Exécutez python -m assistant eval --prompt v2 et --prompt v3 avec votre modèle en direct. Utilisez les 69 billets du jeu d’évaluation et vos 8 nouveaux billets. Exécutez chaque version trois fois.
Présentez, pour chaque version et chaque exécution : l’exactitude de l’équipe, l’accord sur needs_human et le nombre de réponses rejetées par chaque barrière. Présentez aussi vos 8 billets un par un.
Répondez en trois à cinq phrases : sur les anciens billets, v3 est-elle meilleure, pire ou équivalente? Comment savez-vous qu’une différence n’est pas du bruit? Nommez chaque billet dont le résultat a changé entre les exécutions.

Partie 4 : ajouter le nouvel outil en toute sécurité

Utilise Décrire un outil, Exécuter dans le code de l’application et Limiter la boucle.

Ajoutez list_my_orders à assistant/tools.py : aucun argument venant du modèle. L’application transmet le customer_id du billet, comme pour get_order. L’outil renvoie au plus les 5 commandes les plus récentes : identifiant, date, état et total, et rien d’autre.
Décrivez-le au modèle (but, type de retour, limites) et permettez à la boucle de l’exécuter. run_tool refuse tout nom sauf get_order. Étendez-le donc et ajoutez une requête en lecture seule à OrderBook. Gardez toutes les limites de la boucle. Ne modifiez pas TOOLS : les tests enregistrés l’envoient, et le simulateur n’a aucun enregistrement pour une requête contenant deux outils. Placez les deux outils dans une deuxième liste. Envoyez-la seulement quand une option comme --my-orders est activée.
Écrivez des tests : l’outil ne renvoie jamais les commandes d’un autre client. Un appel avec un argument venant du modèle est rejeté. Un appel répété arrête la boucle. Utilisez un modèle à réponses prédéfinies pour la boucle, comme dans la vérification du module de Limiter la boucle.
Répondez à Tomás en trois phrases : pourquoi list_orders(customer_id) avec un identifiant choisi par le modèle est-il dangereux? Même si la requête dit « seulement pour ce client »?

Partie 5 : fiabilité et coût

Utilise Gérer les limites du fournisseur et Mesurer l’utilisation et le coût.

Montrez avec des tests, utilisant le fournisseur simulé, que l’assistant réessaie après une limite de débit avec un délai d’attente croissant. Il doit respecter Retry-After, s’arrêter après le nombre maximal de tentatives et ne pas réessayer après une erreur HTTP 400.
Exécutez python -m assistant usage sur vos exécutions de la partie 3. Cette commande additionne chaque ligne de logs/usage.jsonl. Supprimez donc logs/ avant les exécutions de chaque version, ou regroupez les lignes selon leur champ prompt. Présentez les jetons par billet (médiane, d’après les lignes du journal) et le temps par billet (médiane et p95). Présentez aussi le coût estimé par 1 000 billets pour v2 et v3 aux tarifs de chat-small, même avec un modèle local. cost_usd("chat-small", tokens_in, tokens_out) dans assistant/usage.py donne cette estimation à partir du tableau de prix daté. Dites quels nombres sont mesurés et lesquels sont estimés.
Vérifiez une ligne de journal à la main : aucune clé, aucun numéro de carte complet, aucune adresse courriel de client.

Partie 6 : remettre le projet

Utilise Tester et empaqueter.

Mettez à jour le README : les changements, les nouvelles commandes et les nouveaux tests, ainsi que la configuration facultative du modèle en direct.
Sur une nouvelle copie du projet, dans un nouvel environnement virtuel, exécutez python -m pytest sans clé ni modèle local. Chaque test doit réussir, et les tests en direct doivent être ignorés.
Écrivez REPORT.md avec les sections ci-dessous.

Ce qu’il faut remettre

Votre dossier ticket-assistant (sans .env, logs/ ni l’environnement virtuel), avec REPORT.md :

# Ticket assistant: H6 and list_my_orders
## Policy and test tickets      (Part 1: H6, the near-miss decision, the 8 tickets)
## Validation                   (Part 2: the check, its tests, one ticket the pattern gets wrong)
## Prompt comparison            (Part 3: v2 vs v3, three runs each, what changed and why it is not noise)
## Tool                         (Part 4: list_my_orders, its tests, the answer to Tomás)
## Reliability                  (Part 5: the retry tests)
## Usage and cost               (Part 5: measured and estimated numbers, with dates and model names)
## Limits                       (synthetic data, phrase rules, one local model, what you did not test)

Vérifiez votre travail

Une personne chargée de la révision note chaque élément démontré, partiellement démontré ou pas encore démontré, avec une justification. Pour terminer le cours, vous devez démontrer les quatre éléments obligatoires.

Un schéma de sortie validé (obligatoire) : le schéma et les vérifications de règles d’affaires, dont H6, valident les réponses. Un test prouve qu’une réponse rejetée ne peut pas être enregistrée.
Des comparaisons de requêtes reproductibles (obligatoire) : v2 et v3 utilisent les mêmes billets, avec trois exécutions chacune. Le modèle, la date et les paramètres sont consignés, et la conclusion tient compte du bruit.
Des limites de tentatives et d’appels d’outils (obligatoire) : list_my_orders ne prend aucun identifiant choisi par le modèle. Les tests prouvent le contrôle des permissions, l’arrêt sur appel répété et les limites de nouvelles tentatives.
Une journalisation de l’utilisation et des tests des cas d’échec (obligatoire) : les chiffres d’utilisation distinguent les valeurs mesurées et estimées. Toute la suite de tests réussit sur une nouvelle copie sans clé.

Il n’y a pas de chiffres de corrigé à comparer : les réponses de votre modèle en direct vous sont propres. Les exécutions du cours (chat-small, requête v2, sortie structurée) donnent une référence pour les anciens billets. Vous la trouverez dans Comparer des requêtes et Mesurer l’utilisation et le coût.

Récapitulatif

Vous avez modifié une application d’IA fonctionnelle comme le ferait une équipe. Vous avez écrit une règle précise et des tests qui la rendent difficile à contourner. Vous avez fait une comparaison équitable qui tient compte du bruit. Vous avez ajouté un outil dont le modèle ne peut pas mal utiliser les arguments, et des chiffres sur son coût. Si vous n’avez pas encore fait d’étude de cas, choisissez-en une pour le certificat : Extraire des rappels de produits en données structurées, Répondre à des questions avec des outils sur des données ouvertes ou Classer des demandes bancaires avec un LLM.