Choisir un sujet, aller au bout, écrire clairement

Dans la première partie de ce cours, nous avons construit ensemble RepoBot : un assistant qui répond aux questions sur httpx, mené du programme de conversation en ligne de commande de la v1 jusqu'au service web de la v4, avec recherche, agent, évaluation et garde-fous.

Le projet de fin de parcours vous fait refaire ce chemin seul, à ceci près que le sujet, c'est vous qui le choisissez. Cette leçon n'enseigne aucune technique nouvelle : elle parle de la façon de mener un projet vraiment jusqu'au bout.

Choisir un sujet

Un bon sujet de projet de fin de parcours remplit ces conditions :

• Vous-même ou quelqu'un de votre entourage l'utiliserez vraiment. Avec de vrais utilisateurs, vous savez si c'est utilisable, et vous avez la motivation d'aller au bout.
• Le juste et le faux sont clairs. Que la réponse soit exacte, que le classement soit correct, que les champs extraits soient complets : cela se vérifie. Un sujet comme « écrire un beau poème » s'évalue très difficilement et ne convient pas.
• Une première version utilisable tient en deux à quatre semaines. Mieux vaut faire petit et finir.
• Les données, vous pouvez les obtenir et vous avez le droit de les utiliser. Documentation publique, vos propres notes, jeux de données libres : tout convient. Pour des données internes à une entreprise, vérifiez d'abord si vous pouvez les utiliser et les envoyer à une API.

Quelques pistes, chacune correspondant à certains modules du cours :

题目                                    主要用到
给你常用的一个开源库做答疑助手          RAG（04）、评估（06）
读懂一个代码仓库、回答"这个函数在哪里   智能体和工具（05）、MCP（05 第 7 课）
被调用"的助手
从简历、合同、发票里抽取固定字段        提示词和 JSON 输出（02）、评估（06）
把客服工单自动分类，并给出建议回复      提示词（02）、模型评委（06），可能用到微调（10）
在某个领域的文字上训练一个小模型        第 09 模块，外加第 08 模块第 6 课的过拟合检查
（比如宋词、对联、自己的聊天记录）

Évitez un sujet du genre « faire un assistant IA généraliste ». Il n'a pas de limites, ne sera jamais terminé, et ne peut pas être évalué.

Première étape : écrire ce que veut dire « terminé »

Avant de commencer, rédigez un GOAL.md qui répond à trois questions seulement :

1. Pour qui, et pour résoudre quoi. Une phrase.
2. À quoi ressemble « terminé ». Écrivez-le sous la forme de quelques points vérifiables, comme les « critères de réussite » en tête de chaque module de ce cours. Par exemple : « répond aux questions d'utilisation présentes dans la documentation de httpx, au moins 16 bonnes réponses sur 20 questions d'évaluation, chaque réponse accompagnée de sa source » ; « le coût moyen par question ne dépasse pas 0,01 yuan ».
3. Ce que vous ne ferez pas, explicitement. Par exemple « pas d'envoi d'images », « chinois uniquement ».

Ce fichier décide du moment où votre projet est achevé. Sans lui, un projet grossit facilement sans fin et rien n'est jamais terminé. La leçon 3 du module 07 disait la même chose : fixer les critères de recette, puis se mettre au travail.

Deuxième étape : faire le jeu d'évaluation d'abord

Avant d'écrire la moindre ligne de code fonctionnel, préparez 20 à 50 questions d'évaluation.

Cela paraît à l'envers, mais c'est l'étape la plus importante de tout le projet (leçon 1 du module 06) :

• Écrire les questions vous oblige à comprendre précisément ce que les utilisateurs demanderont et ce qui fait une bonne réponse.
• Avec un jeu d'évaluation, chaque modification se juge en une commande : effet meilleur ou moins bon.
• Au moment d'écrire le README, vous avez de vrais chiffres à donner, et non un « ça marche bien ».

Les questions doivent couvrir les cas normaux, mais aussi les cas limites, les questions auxquelles il faut refuser de répondre, et les entrées susceptibles d'être détournées (leçon 5 du module 06).

Troisième étape : produire la version utilisable la plus simple

Faites d'abord une version par la méthode la plus simple, et passez-lui le jeu d'évaluation.

Si la v1 de RepoBot ne consultait volontairement aucun document, c'était pour voir jusqu'où va « la méthode la plus simple » et où elle échoue. Ces échecs vous disent ce qu'il faut faire ensuite : s'il se trompe faute de connaître les documents, ajoutez du RAG ; s'il se trompe parce qu'il faut chercher en plusieurs étapes, envisagez un agent ; si seul le format est instable, commencez par modifier le prompt.

Ne mettez pas d'emblée en œuvre toutes les techniques apprises. La leçon 1 du module 05 le disait : quand un simple enchaînement suffit, n'utilisez pas d'agent. Chaque ajout doit s'appuyer sur un résultat d'évaluation qui prouve qu'il améliore vraiment les choses.

Quatrième étape : améliorer à petits pas

Ensuite, chaque pas se déroule ainsi :

1. Regardez dans les résultats d'évaluation les questions ratées, et repérez le type d'échec le plus fréquent.
2. Faites une modification visant ce type d'échec.
3. Repassez le jeu d'évaluation et notez le résultat.
4. Faites un commit git, en indiquant dans le message l'évolution du résultat d'évaluation.

Consignez le résultat de chaque étape dans un tableau. Au moment d'écrire le README, ce tableau sera le contenu le plus convaincant : il montre que chaque décision de conception avait une raison.

版本    改动                          答对      平均花费/题   平均耗时
v1      直接问模型                    7/20      0.002 元      2.1 秒
v2      加上 RAG（向量检索）          13/20     0.004 元      3.0 秒
v3      改成混合检索 + 重排           16/20     0.004 元      3.4 秒

(Le tableau ci-dessus est un exemple de format, non de vraies données. Le vôtre doit contenir les chiffres que vous avez obtenus.)

Cinquième étape : la vérification avant mise en ligne

Si votre projet doit servir à d'autres, reprenez le module 06 point par point :

• Aucune clé écrite dans le code ni envoyée dans git.
• Une limite de longueur des entrées et une limite de fréquence d'appel, pour que personne ne vide votre compte.
• Des journaux qui montrent pour chaque requête les étapes, la durée et le coût, sans enregistrer d'informations sensibles sur les utilisateurs.
• Des garde-fous en entrée et en sortie, dont le jeu d'évaluation confirme qu'ils ne bloquent pas les questions normales.
• Si vous utilisez un agent, les droits de ses outils sont réduits au minimum (leçon 8 du module 05).

Sixième étape : écrire le README

Un projet a beau être excellent, si personne ne le comprend ni n'arrive à l'exécuter, c'est comme s'il n'existait pas. Le README doit au moins contenir :

• Une phrase de présentation : ce que c'est, pour qui.
• Les résultats : un ou deux exemples d'utilisation réels (des sorties réellement obtenues, rien d'inventé), plus le tableau des résultats d'évaluation.
• Comment l'exécuter : toutes les étapes, du clonage du code jusqu'au résultat affiché, telles qu'un autre les suive et obtienne le même résultat. Précisez les variables d'environnement nécessaires et le coût approximatif.
• Comment c'est conçu : la structure d'ensemble, les quelques décisions clés et leurs raisons (pourquoi du RAG plutôt qu'un fine-tuning, pourquoi ce modèle).
• Ce qu'il fait mal : de quel type sont les questions encore ratées dans le jeu d'évaluation, et les limites connues.

Ce dernier point est le plus souvent omis, et c'est celui qui montre le mieux votre niveau. Savoir dire clairement où votre système se trompe prouve que vous l'avez vraiment compris. Le README de RepoBot v4, au module 06, énumère justement « ce qui manque encore avant une mise en ligne ».

Une fois le README écrit, demandez à un ami qui n'a jamais vu le projet de le faire tourner en ne lisant que le README. Chaque endroit où il bloque est un endroit à corriger.

Le raconter à quelqu'un

Enfin, essayez de présenter votre projet à quelqu'un en cinq minutes. Vous pouvez emprunter, pour vous organiser, la série de questions du cours Start AI Engineering (les leçons de projet des modules 03 à 06 s'y terminaient aussi) :

1. Quel problème résout-il ? Qui l'utilise ?
2. Quelles sont les entrées, quelles sont les sorties ?
3. Pourquoi cette solution plutôt qu'une plus simple ou une plus complexe ?
4. Comment savez-vous s'il est bon ? Quels sont les chiffres ?
5. Combien coûte et combien dure chaque appel ?
6. Où se trompe-t-il ? Et quand il se trompe, que se passe-t-il ?

Si vous répondez clairement à ces six questions, vous ne vous contentez plus « d'appeler un grand modèle » : vous savez construire seul une application d'IA fiable. C'est aussi là que ce cours voulait vous emmener depuis sa toute première leçon.

Exercices

1. Notez trois sujets candidats, donnez à chacun une note sur les quatre conditions de la section « Choisir un sujet », et retenez-en un.
2. Pour le sujet retenu, écrivez GOAL.md et au moins 20 questions d'évaluation, avant de commencer à écrire du code.
3. Une fois le projet terminé, confiez le README à quelqu'un qui n'a jamais vu le projet, notez les endroits où il bloque, et corrigez le README.

Auto-test

1. Pourquoi préparer le jeu d'évaluation avant d'écrire le code fonctionnel ?

Écrire les questions d'évaluation oblige à comprendre précisément ce que demanderont les utilisateurs et ce qui fait une bonne réponse ; une fois le jeu prêt, chaque modification se juge en une commande ; et au moment du README, on dispose de vrais chiffres. Sans jeu d'évaluation, on ne juge qu'à l'impression laissée par quelques exemples, ce qui trompe facilement.

2. Pourquoi commencer par la version la plus simple, au lieu d'employer d'emblée RAG, agents et le reste ?

La version la plus simple vous dit où est vraiment le problème : documents manquants, opérations en plusieurs étapes nécessaires, ou simple instabilité du format. On choisit ensuite la technique selon la cause des échecs, et chaque ajout est justifié par un résultat d'évaluation, ce qui évite de rendre le système inutilement complexe.

3. Pourquoi écrire dans le README « ce qu'il fait mal » ?

Cela indique aux utilisateurs les cas où ils ne peuvent pas se fier au système, et évite les mauvais usages ; cela montre aussi que l'auteur comprend vraiment son système et sait où il se trompe. Un README qui ne dit que les qualités inspire au contraire moins confiance.