Production de bout en bout : vérification, surveillance et éthique

Gains :

Peut concevoir l'architecture de bout en bout qui fait passer une fonctionnalité LLM de l'idée à la production
Établit des niveaux d'application de la vérification, d'approbation humaine et de suivi (journalisation/métriques)
Les limites traduisent les principes d’éthique et de confidentialité dans les décisions de production

Dans les dix unités précédentes, nous avons appris les parties une par une : structure des requêtes, économie des jetons, flux, invite système, sélection du modèle, cache, lot, gestion des erreurs, clé sécurisée et automatisation. Dans cette dernière unité, nous combinons les parties et établissons l'architecture holistique qui porte une fonctionnalité LLM de l'idée à la production. La production est différente d’une « démonstration de travail » : la vérification est obligatoire, le résultat doit être surveillé, les limites et les principes éthiques doivent être intégrés dans les décisions. Cette unité est la colonne porteuse du module ; Tous les précédents sont réunis ici.

Couches d'architecture de production

Une solide qualification LLM comprend environ cinq niveaux :

Couche d'entrée : Collectez les données, nettoyez-les, masquez les zones sensibles, ne transmettez que ce qui est nécessaire.
Couche modèle : sélectionnez le modèle correct (unité 5), définissez l'invite et les paramètres du système (unité 4), le cache (unité 6).
Couche de validation : vérifiez la sortie par rapport au schéma/règle, à la source et à l'approbation humaine si nécessaire.
Couche d'action : effectuer une action avec une sortie validée ; Capturez les actions à fort impact.
Couche de surveillance : enregistrez et mesurez chaque appel, coût, erreur et qualité.

Ces couches constituent un pipeline ; chacun vérifie la sortie du précédent.

Pourquoi la vérification est-elle requise ?

Les LLM peuvent produire des résultats fluides mais parfois inexacts. C’est ce qu’on appelle une hallucination : le modèle peut fabriquer des informations qui semblent vraies mais qui ne le sont pas. Dans un jeu de chat, cela est tolérable ; ne peut être tolérée dans un système de production (facture, santé, juridique, finance). Il s'est donc avéré aveuglément peu fiable ; est confirmé.

Couches de vérification (augmentant par impact) :

Validation du format/schéma : la sortie est-elle conforme au schéma JSON attendu ? (La sortie structurée le garantit en grande partie.)
Vérification des règles/logiques : les valeurs sont-elles raisonnables ? (Le montant est-il négatif, la date est-elle dans le futur, la catégorie est-elle valide ?)
Vérification à la source : la réclamation est-elle basée sur la documentation fournie ? Le modèle dit-il quelque chose qui ne figure pas dans le document ?
Approbation humaine : un expert examine les décisions à fort impact ou ambiguës.

Attention : « Le modèle est si bon qu'aucune vérification supplémentaire n'est nécessaire » est l'erreur de production la plus dangereuse. Quelle que soit la qualité du modèle, la couche de vérification constitue un filet de sécurité pour les décisions à fort impact. Même une mauvaise décision automatique peut faire perdre tout le temps gagné.

Humain dans la boucle

Toutes les décisions ne doivent pas nécessairement être entièrement automatiques. Dans l’approche human-in-the-loop, le modèle accélère le travail et l’humain l’approuve. Le juste équilibre dépend de l’impact de la décision et de la fiabilité du modèle sur cette tâche.

Impact de la décision

Approche

Faible (suggestion d'étiquette, brouillon)

Automatisation complète ; l'erreur est bon marché et réversible

Moyen (routage, priorisation)

Automatisation + contrôle d'échantillonnage

Élevé (argent, contrat, santé, suppression)

Le consentement humain est obligatoire ; le modèle suggère seulement

Surveillance : vous ne pouvez pas gérer ce que vous ne voyez pas

En production, vous devez surveiller chaque appel. Sans surveillance, vous ne pouvez pas améliorer les coûts, la qualité ou détecter un problème rapidement. Indicateurs clés à enregistrer :

Utilisation/coût : par demande et nombre total de jetons, distribution du modèle, dépenses quotidiennes.
Latence : temps de réponse moyen et dans le pire des cas.
Taux d'erreur : taux de 429/500, tentatives, abandons.
Qualité : taux de sortie rejeté au niveau de la couche de vérification, taux de correction à l'approbation humaine, commentaires des utilisateurs.

Astuce : N'écrivez pas de données sensibles (informations personnelles, clés) dans les journaux de surveillance. Considérez les journaux dans le cadre de la confidentialité ; enregistrer en masquant si nécessaire (unité 9).

Éthique et limites

La responsabilité éthique fait autant partie de la décision de production que la précision technique :

Transparence : L'utilisateur doit savoir s'il s'adresse à une intelligence artificielle ou à un humain.
Équité et biais : le modèle peut comporter des biais de la part des données sur lesquelles il est formé ; Surveiller les conséquences discriminatoires dans les décisions à fort impact (embauche, crédit).
Responsabilité : si une décision automatisée cause un préjudice, vous en êtes responsable ; « Le modèle l’a dit » n’est pas une défense.
Acceptation des limites : le modèle ne peut pas effectuer certaines tâches de manière fiable ; ne pas les automatiser est également une décision de conception.

Modèles copiables

# Liste de contrôle de validation (après génération du résultat)1) Le schéma est-il valide ? (validation de sortie structurée)2) Les valeurs ont-elles un sens ? (vérification des règles : plage, date, énumération)3) La réclamation est-elle basée sur la source ? (rejeter si ce n'est pas dans le document)4) L'impact est-il élevé ? → envoyer pour approbation humaine5) Si tout est réussi → autoriser l'action, enregistrer

# Invite système qui oblige à s'appuyer sur sourceRely uniquement sur les informations contenues dans le document fourni. N'ajoutez rien qui ne soit pas dans le document. Si une information ne figure pas dans le document, écrivez « Introuvable dans le document ». Ne devinez jamais et n’inventez jamais des choses.

# Seuil d'approbation humaine (règle de décision) SI type_décision dans [argent, contrat, suppression, santé] → approbation humaine obligatoire SI model_trust < seuil OU validation "incertain" → soumettre à l'approbation humaine AUTRE → application automatique + contrôle d'échantillonnage

# Modèle de journal de trace (écriture de données sensibles){ "time": "...", "model": "...", "input_token":..., "output_token":..., "delay_ms":..., "stop_reason": "...", "authentication": "passed|rejected|human", "cost_usd":... } // les données personnelles et la clé ne sont JAMAIS écrites

Invite faible/invite forte (fiabilité de la production)

# FAIBLE (aucune vérification, aucune source, s'applique automatiquement) Évaluez cette demande, prenez une décision de remboursement et postulez.

# FORT (basé sur la source, génère une recommandation, laisse à l'approbation humaine)Évaluez cette demande de retour sur la base du document de politique de retour uniquement. Recommander la décision avec justification mais ne pas la mettre en œuvre : {"recommendation": "approve|reject", "reason": "...", "policy_clause": "..."}. S'il n'y a pas de base claire dans le document de politique, indiquez "peu clair". Un représentant approuvera la décision finale.

Version puissante ; Il attribue la décision à la source, positionne le modèle comme un « suggérateur » plutôt que comme un « exécutant » et place l’étape à fort impact derrière l’approbation humaine. C’est l’essence même de la fiabilité de la production.

Trois mini-étuis

Cas 1 — Le jour où la couche de vérification a été enregistrée. Une fintech demandait au modèle de classer les descriptions de transactions et de créer des enregistrements comptables automatiques. Ils ont ajouté une règle de validation : une fois que le modèle a affiché un montant incorrect (12 500 au lieu de 1 250 dans le document), la règle « le montant ne correspond pas au document » a rejeté la sortie et l'enregistrement est tombé entre les mains de l'humain. S’il n’y avait aucune vérification, l’enregistrement incorrect entrerait silencieusement dans le système.

Cas 2 — Fugitif arrêté par surveillance. Une équipe SaaS avait mis en place un panel de surveillance ; Un matin, le coût journalier a triplé. Il ressort des journaux qu'un client est entré dans une boucle et a envoyé la même demande des milliers de fois. Ils ont ajouté le quota et la déduplication ; Le problème a été résolu en quelques heures. Sans suivi, la facture serait une surprise à la fin du mois.

Cas 3 — Accepter la limite. Une startup du secteur de la santé envisageait de formuler une recommandation de diagnostic de manière entièrement automatique et de la montrer au patient. Lors d'un examen d'éthique et de responsabilité, ils ont décidé que cela était interdit : le modèle ne fournit qu'un résumé et des points possibles au médecin, le médecin pose le diagnostic. Ne pas automatiser un travail est également une décision de conception mûrement réfléchie.

Erreurs courantes

Sauter la validation : appliquer aveuglément le résultat en disant "le modèle est bon".
Automatisation des décisions à fort impact : l'approbation humaine est essentielle en matière d'argent, de santé et de droit.
Pas de suivi : les problèmes de coût et de qualité sont découverts tardivement.
Écriture de données sensibles dans les journaux : violation de la confidentialité ; Enregistrez-le en le masquant.
Ne pas essayer de se fier à la source : le modèle peut inventer ce qui ne figure pas dans le document.
Ignorer les limites : ne pas automatiser certaines tâches est la bonne décision ; La transparence et la responsabilité sont les vôtres.

Plus approfondi : gestion des versions, restauration et déploiement incrémentiel

Mettre une fonctionnalité LLM en production ne consiste pas à la configurer et à l'oublier ; est de modifier en toute sécurité un système actif au fil du temps. Il comporte trois piliers.

Gestion des versions. L'invite de votre système, la sélection du modèle et les règles de vérification changent au fil du temps. Versionnez chaque changement important et enregistrez quelle version est en ligne. Si un jour la qualité baisse, "qu'est-ce qu'on a changé ?" Vous devriez être en mesure de répondre à la question en quelques minutes. Dans un système sans version, trouver la cause première d’une régression prend des jours.

Restauration. Si une nouvelle invite ou un nouveau modèle se comporte moins bien que prévu en direct, vous devriez pouvoir revenir rapidement à la version précédente et bien connue. Un changement sans plan de restauration revient à accepter aveuglément un risque réel. "J'ai changé quelque chose, ça s'est détérioré, je ne peux pas revenir en arrière" est le scénario de production le plus coûteux.

Déploiement progressif. Au lieu d'appliquer une modification à tout le trafic en même temps, vous la déployez d'abord sur un petit pourcentage (par exemple 5 %) et surveillez les métriques (qualité, coût, erreurs). Si c'est bon, vous augmentez le pourcentage ; Si c'est mauvais, vous le récupérerez avec seulement une petite section affectée. Cela limite grandement le risque.

Ces trois pratiques combinent les techniques de toutes les unités précédentes : l'évaluation (unité 5) mesure les changements à l'avance, la surveillance (cette unité) donne une alerte précoce pendant la propagation, la couche de vérification détecte les sorties erronées avant qu'elles ne deviennent exploitables. La production n’est pas une seule configuration correcte ; Il s’agit d’une discipline continue qui mesure, surveille et peut évoluer en toute confiance. L'ensemble du module est destiné à vous permettre d'établir cette discipline.

En résumé

La production est plus qu'une démonstration fonctionnelle : c'est un pipeline de couches d'entrée, de modèle, de vérification, d'action et de surveillance. La sortie n'est pas fiable sans vérification ; les décisions à fort impact sont liées à l’approbation humaine ; Chaque appel est surveillé pour le coût, les erreurs et la qualité. L'éthique, la transparence, le contrôle des préjugés, la responsabilité et l'acceptation des limites font partie intégrante des décisions techniques. Chaque élément appris dans ce module est réuni dans cette conception holistique.

Tâche de candidature

Concevoir une fonctionnalité LLM de bout en bout. (1) Remplissez les cinq niveaux (entrée, modèle, vérification, action, suivi) pour votre tâche spécifique. (2) Marquez par impact quelles décisions nécessiteront l’approbation humaine. (3) Rédigez au moins trois contrôles de validation (schéma, règle, source). (4) Déterminez les mesures clés que vous suivrez et celles que vous n'enregistrerez pas. (5) Écrivez une limite et un principe éthique que vous acceptez dans cette fonctionnalité.

liste de contrôle

[ ] Je peux concevoir cinq couches du pipeline de production.
[ ] Je peux valider la sortie par rapport au schéma, à la règle et à la source.
[ ] Je peux définir un seuil d'approbation humaine en fonction de l'impact de la décision.
[ ] Je surveille les coûts, les erreurs et la qualité et je m'entraîne à ne pas écrire de données sensibles dans les journaux.
[ ] Je peux transformer l'éthique, la responsabilité et les limites en décisions de production.

Examen de module

1. Que fait le rôle « système » dans une API de chat LLM ?

A) Donne au modèle des instructions permanentes et des règles de comportement qui s'appliquent tout au long de la conversation ✔
B) Conserve la dernière question écrite par l'utilisateur
C) Stocke la réponse produite par le modèle
D) Chiffre la clé API

Description : le rôle système donne au modèle des instructions, une personnalité et des règles persistantes qui s'appliquent tout au long de la conversation ; Il s'agit d'une redirection de haut niveau, distincte des messages utilisateur.

2. Pourquoi l'historique des conversations (messages précédents) est-il renvoyé à chaque fois dans une requête API ?

A) Il est nécessaire de sauvegarder car le serveur supprime l'historique
B) Les appels API sont sans état ; ✔ Le contexte est renvoyé à chaque requête car le modèle ne se souvient pas de l'historique
C) Obligatoire uniquement pour la facturation, n'a aucun effet sur le modèle
D) L'envoi de l'historique est obligatoire pour éviter de ralentir la réponse

Explication : Les appels d'API LLM sont sans état ; Le modèle ne se souvient pas des tours précédents, donc tout l'historique pertinent est renvoyé à chaque demande afin de préserver le contexte.

3. Qu'est-ce qu'un « jeton » dans la tarification LLM ?

A) Mot de passe à usage unique utilisé pour se connecter à l'API
B) Une redevance forfaitaire versée à chaque demande
C) La plus petite unité dans laquelle le modèle traite le texte ; correspond généralement à la partie du mot ✔
D) Une unité qui mesure uniquement la longueur de la sortie

Description : le jeton est la plus petite unité dans laquelle le modèle traite le texte ; Cela correspond généralement à un fragment de mot, et l'entrée et la sortie sont facturées en fonction du nombre de jetons.

4. Pourquoi les jetons de sortie sont-ils plus chers que les jetons d'entrée chez la plupart des fournisseurs LLM ?

A) Les jetons de sortie sont toujours plus longs que les jetons d'entrée
B) Les jetons d'entrée sont gratuits
C) Les jetons de sortie sont envoyés deux fois sur Internet
D) Le coût unitaire est plus élevé car la génération de sortie nécessite des calculs supplémentaires pour chaque jeton ✔

Description : chacun des jetons de sortie nécessite que le modèle effectue une génération (calcul) étape par étape ; Ce coût de production est plus élevé que le traitement simultané des intrants, de sorte que le prix unitaire de la production est généralement plus élevé.

5. Dans quelle situation l’utilisation du streaming est-elle la plus bénéfique ?

A) Dans les réponses longues ; Réduit le retard perçu et évite les délais d'attente ✔
B) Uniquement dans les réponses très courtes d'un seul mot
C) Réduire le coût à zéro
D) Pour masquer la clé API

Description : dans les réponses longues, le streaming réduit la latence perçue en faisant apparaître immédiatement les premiers mots et empêche les délais d'attente HTTP pour des valeurs max_tokens élevées.

6. Qu'est-ce que l'augmentation du paramètre « effort » dans les modèles modernes affecte généralement ?

A) Raccourcissez toujours la réponse
B) Fait pivoter automatiquement la clé API
C) Cela réduit uniquement le prix du jeton d'entrée
D) Augmente la profondeur de réflexion et les dépenses symboliques ; Cela peut améliorer la qualité, mais cela augmente également la latence et le coût ✔

Description : le paramètre d'effort ajuste la profondeur avec laquelle le modèle réfléchira à une tâche et le nombre de jetons qu'il dépensera ; La mise à niveau peut améliorer la qualité, mais elle augmente également la latence et le coût. Pour des tâches simples, un faible effort suffit.

7. Quelle est généralement l’approche la plus rentable pour une tâche de classification simple et à volume élevé ?

A) Utilisez toujours le modèle le plus cher et le plus puissant
B) Appel de tous les modèles en même temps pour chaque demande
C) Sélectionner le modèle le plus léger/le moins cher qui accomplit la tâche en le vérifiant avec une petite évaluation ✔
D) garder la valeur max_tokens inutilement trop élevée

Explication : Si la tâche n'est pas complexe, choisir un modèle plus rapide et moins cher qui accomplit facilement la tâche (par exemple la classe Haiku) au lieu d'utiliser le modèle le plus cher et le plus puissant réduira considérablement le coût.

8. Dans quel scénario la mise en cache des invites réduit-elle le plus le coût ?

A) Lorsqu'un contexte vaste et fixe est utilisé de manière répétée sur de nombreuses requêtes ✔
B) Lorsqu'un texte complètement différent est envoyé à chaque demande
C) Lorsqu'une seule demande est faite
D) Pour réduire les jetons de sortie

Description : la mise en cache est une correspondance de préfixe ; Dans les cas où un contexte volumineux et immuable (invite système, documents) est réutilisé dans de nombreuses requêtes, la lecture à partir du cache ne représente qu'une petite fraction (~ 0,1x) du prix total.

9. Comment dois-je modifier l'invite pour que le cache d'invite soit activé ?

A) Mettre du contenu variable au début et du contenu fixe à la fin
B) Intégrer la date et l'heure actuelles dans l'invite du système pour chaque demande
C) Mettre le contenu fixe (invite système, documents) au début et le contenu variable à la fin ✔
D) Modification de l'ordre de la liste des outils à chaque demande

Explication : Étant donné que le cache correspond à une correspondance de préfixe, le contenu fixe/inchangé (invite système, documents) est initialisé ; le contenu variable (date, question de l'utilisateur, ID de la demande) est mis à la fin. Même un seul octet modifié au début invalidera le cache.

10. Pour quel type de charge de travail le traitement par lots est-il le mieux adapté ?

A) Chat en direct où l'utilisateur attend une réponse instantanée à l'écran
B) Juste une petite question
C) Génération de la clé API
D) Travaux tolérants aux retards, volumineux et ne nécessitant pas de résultats immédiats ✔

Description : Le traitement par lots convient aux gros volumes de tâches qui ne nécessitent pas de réponse immédiate et tolèrent les retards ; les résultats sont livrés après un certain temps, mais le coût unitaire est généralement inférieur.

11. Qu'est-ce qui est utilisé pour faire correspondre en toute confiance à quelle requête appartiennent les résultats dans un lot ?

A) Ordre d'envoi (position) des demandes
B) Longueur des réponses
C) Les 4 derniers chiffres de la clé API
D) Un custom_id unique donné à chaque requête ✔

Remarque : Les résultats groupés peuvent être renvoyés dans un ordre différent de celui de soumission ; il est donc nécessaire de faire correspondre les résultats par ID, et non par emplacement, avec un custom_id unique attribué à chaque requête.

12. Quel est le comportement recommandé lorsque vous recevez une erreur 429 (limite de débit) de l'API ?

A) Forcer en envoyant beaucoup plus de requêtes en même temps
B) Réessayer avec un recul exponentiel, en suivant le titre réessayer après ✔
C) Annulez complètement la demande et affichez l'erreur comme un crash à l'utilisateur
D) Modification de la clé API

Explication : 429 est une erreur pouvant être réessayée ; L'approche correcte consiste à réessayer avec un intervalle exponentiel, en respectant l'en-tête retry-after. La plupart des SDK officiels le font automatiquement.

13. Parmi les codes d'erreur HTTP suivants, lesquels sont généralement considérés comme réessayables ?

A) 400 (demande invalide)
B) 401 (erreur d'authentification)
C) 529 (serveur surchargé) ✔
D) 404 (introuvable)

Explication : 429 (limite de vitesse), 500 (erreur du serveur) et 529 (surcharge) sont des erreurs temporaires et peuvent être réessayées en reculant. Les erreurs telles que 400 et 401 sont des problèmes de demande/identité ; Réessayer ne résoudra pas le problème.

14. Parmi les propositions suivantes, laquelle constitue le moyen sécurisé de gérer les clés API ?

A) Stocker dans l'environnement la variable/gestionnaire caché, sans l'intégrer dans le code et en tournant régulièrement ✔
B) Écrivez la clé directement dans le code source et envoyez-la au référentiel
C) Mettre la clé dans le JavaScript côté client (navigateur)
D) Partager une clé unique avec toute l'équipe par e-mail

Description : les clés ne sont jamais écrites dans le code source ou le référentiel ; Il est stocké dans une variable d'environnement ou un outil de gestion caché, accordé avec des privilèges minimaux et alterné régulièrement.

15. Quelle est la meilleure approche d'intégration LLM avec un outil d'automatisation (n8n, Zapier, Make) en termes de confidentialité ?

A) Envoi de toutes les données brutes au modèle, même si cela n'est pas nécessaire
B) Écriture de la clé API en texte brut à l'intérieur de l'étape de flux
C) Minimiser et masquer les données sensibles et stocker la clé en tant qu'informations d'identification secrètes ✔
D) Conserver les données personnelles en permanence dans l'historique des flux

Description : à mesure que l'automatisation de la saisie des données passe par des systèmes et des modèles tiers, les données sensibles/personnelles doivent être minimisées, masquées et seuls les champs obligatoires doivent être envoyés ; La clé API est également stockée sous forme d'informations d'identification secrètes dans l'outil.

16. Pourquoi la validation des résultats est-elle obligatoire dans une fonctionnalité de production basée sur LLM ?

A) Seul le formatage est requis car le modèle ne fait jamais d'erreurs
B) Parce que le modèle peut produire de manière fluide mais parfois incorrecte ; Le schéma/règle doit être audité avec l’approbation des ressources et de l’humain ✔
C) La validation doit être évitée car elle ne fait qu'augmenter les coûts
D) La vérification sert uniquement à réduire le nombre de jetons

La description : Les LLM peuvent produire un résultat fluide mais parfois inexact (hallucinatoire) ; cela s'est donc traduit par des décisions à fort impact ; Il doit être audité par vérification des schémas/règles, validation des sources et approbation humaine si nécessaire.