Avant de commencer
Définir d'abord la limite d'exécution.
- Accès à au moins trois utilisateurs représentatifs ou exemples de tâches réalistes.
- Un seul constructeur responsable capable de terminer le chemin complet d'entrée à sortie.
- Un délai et une limite de dépense fixes pour l'expérience de sept séances.
- Données de test non sensibles et une liste écrite des modes d'échec inacceptables.
Étape par étape
Passer d'une portée à un artefact vérifié.
Session 1 — choisir une décision utilisateur
Nommez un utilisateur, une tâche récurrente, le travail actuel, et la décision ou l'action que votre produit devrait rendre plus facile. Écrivez le signal de succès le plus petit observable et les conditions qui rendraient l'idée non digne d'être développée.
- Point de vérification
- Le problème peut être testé avec des exemples réels et ne dépend pas de servir tout le monde.
- Artifact
- Brève présentation d'un problème et d'une règle d'arrêt en une page
Session 2 — définir un flux complet
Cartographier le chemin minimum depuis l'entrée jusqu'à la sortie utile, y compris les états vides, en chargement, d'erreur, de refus et de réessai. Séparer le flux de travail requis des fonctionnalités pouvant attendre. Identifier où un humain doit examiner ou approuver les résultats.
- Point de vérification
- La première version a un seul résultat complet et aucune liste de fonctionnalités orphelines.
- Artifact
- Carte de flux et liste de vérification d'acceptation
Session 3 — préparer le paquet de tâche
Collectez des entrées représentatives, la structure de sortie attendue, les besoins en preuves, les contraintes de vie privée et les exemples d'échec. Versionnez les prompts, les identifiants de modèle, les paramètres, les outils et les fichiers contextuels afin que le comportement observé puisse être expliqué plus tard.
- Point de vérification
- Le constructeur peut distinguer une erreur de modèle d'une tâche peu claire ou d'un contexte manquant.
- Artifact
- Paquet de tâche et d'évaluation versionné
Session 4 — choisir la plus petite pile d'exécution
Sélectionnez les outils, l'accès aux modèles, le stockage, l'hébergement et l'analyse selon les contraintes du flux. Privilégiez les choix réversibles et les infrastructures existantes. Enregistrez pourquoi chaque composant est présent, ce qu'il coûte, les données qu'il reçoit et quand il doit être remplacé.
- Point de vérification
- Chaque composant soutient le premier flux plutôt qu'une plateforme hypothétique future.
- Artifact
- Enregistrement de décision d'empilement
Session 5 — construire et vérifier le chemin utilisable
Mettez en œuvre le flux complet et testez-le avec le paquet de tâches. Vérifiez la sécurité du contenu, l'autorisation, le traitement des données, les délais d'attente, les pannes du modèle, les limites de débit, l'accessibilité et le comportement sur mobile proportionnellement au risque de mise en production.
- Point de vérification
- Le chemin produit un résultat utile ou un échec sûr clair pour chaque exemple représentatif.
- Artifact
- Version bêta testée et liste de bogues
Session 6 — lancer à un public limité
Déployer une version traçable, vérifier le chemin public et inviter le plus petit groupe utile. Informez les utilisateurs de ce que le produit fait, ce qu'il ne fait pas, comment vos données sont traitées et où l'jugement humain reste nécessaire.
- Point de vérification
- La version peut être identifiée, surveillée et annulée sans supposition.
- Artifact
- Enregistrement de version et script de test utilisateur
Session 7 — décider à partir du travail observé
Examiner les tâches terminées, les schémas d'échec, l'abandon, les questions de support, les coûts et les retours qualitatifs. Décider s'il faut améliorer le flux, le conditionner pour une utilisation répétée, lancer une nouvelle expérience ou arrêter. Conserver les preuves et la raison de la décision.
- Point de vérification
- La prochaine action suit le comportement observé et les contraintes prédéfinies, et non l'enthousiasme du jour du lancement.
- Artifact
- Enregistrement des décisions et prochaine expérience
Livraisons
Gardez le travail réutilisable et inspectable.
- Briefing du problème et règles d'arrêt explicites
- Flux complet et liste de vérification d'acceptation
- Paquet de tâche et d'évaluation versionné
- Enregistrement de décision d'empilement
- Candidat à la version vérifiée
- Enregistrement de la version de production et des tests utilisateurs
- Décision suivante basée sur les preuves
Limites des décisions
Ce que ce tutoriel ne prouve pas.
- Sept sessions limitent l'expérience ; elles ne garantissent pas le bon marché, les revenus ou un système de production.
- Les décisions à haut impact nécessitent une revue qualifiée, une évaluation plus forte et une gouvernance en dehors de ce cycle de lancement.
- Ne pas collecter de données personnelles ou confidentielles simplement pour rendre le prototype réaliste.
- L'intérêt précoce des utilisateurs est une preuve directionnelle, pas une preuve qu'un marché plus large ou un business répétitif existe.
Registre des sources
Vérifier la guidance actuelle.
- NIST AI 600-1 : Profil d'IA générative
Référence de gestion des risques pour définir le périmètre, les contrôles, la responsabilité et l'évaluation selon le contexte.
- RichBay : Comment évaluer une réponse d'IA
La méthode de revue utilisée pour séparer l'adéquation de la tâche, les preuves, l'incertitude et l'usabilité.
- RichBay : Comparaison des sorties révisées
La méthode reproductible pour le versioning des tâches, la capture des sorties et la publication d'un registre de décision bornée.