Concevoir Artie, un assistant de documentation IA
Consultez l'article de blog associé pour plus de contexte : Ce que la création d'un assistant de documentation IA m'a appris sur la rédaction technique. Il explore la génération augmentée par récupération et la manière dont ce projet s'intègre dans la rédaction technique.
Cette étude de cas présente les choix de conception qui ont présidé à la création d’Artie, un assistant de documentation IA conçu avec Algolia et intégré à ce site de documentation. Artie est un assistant de génération augmentée par récupération (RAG) qui répond uniquement à partir du contenu publié ici. Son prompt système maintient les demandes d'information sur la documentation ancrées dans ce contenu plutôt que dans des connaissances générales issues de l'entraînement. Cette restriction limite les hallucinations et empêche l'invention de fonctionnalités.
La création d’un assistant de documentation semble simple jusqu’à ce que l’on prenne en compte les cas limites : que se passe-t-il lorsque quelqu’un pose une question qui n’est pas traitée dans la documentation ? Que faire si deux publics distincts utilisent la même interface ? Comment doter une IA d’une personnalité sans qu’elle divague ? Et comment empêcher quelqu'un de détourner complètement le prompt ?
Cette page explique comment cette conception résout chacun de ces problèmes.
Acheminement des publics
Artie s’adresse à deux publics via une seule interface conversationnelle :
- Développeurs et utilisateurs finaux à la recherche d'instructions de configuration, de références d'API ou d'explications sur les exemples de documentation
- Recruteurs et responsables du recrutement évaluant ce portfolio qui peuvent poser des questions sur les qualifications, l'expérience ou le processus de rédaction
Plutôt que de créer des flux distincts ou de demander aux utilisateurs de s’identifier eux-mêmes, le prompt oriente les requêtes en fonction de l’intention. Les questions techniques reçoivent des réponses étape par étape fondées sur l’index de la documentation. Les questions relatives au portfolio reçoivent des réponses qui synthétisent le contexte du CV avec les exemples de rédaction présents sur le site. Si le contexte du CV n’est pas disponible dans l’index, Artie redirige les visiteurs vers la page « À propos de moi » au lieu de tenter de générer une réponse.
L’interface offre aux deux publics un seul chat sans menus, et chacun obtient une réponse pertinente.
Ancrage et extraction des connaissances
La contrainte la plus importante dans la conception d’Artie est qu’il répond exclusivement à partir de l’index de documentation propulsé par Algolia. C’est le principe fondamental de la génération augmentée par récupération. Les réponses du modèle s’ancrent dans un ensemble spécifique de contenus plutôt que de puiser dans des données d’entraînement générales.
- Aucun contenu inventé signifie que l'assistant n'invente jamais de fonctionnalités et ne crée pas de liens de téléchargement, et qu'il ne décrit que les étapes présentes dans la documentation.
- Liens vers les sources signifie que l'assistant fournit des URL ou des références de fichiers issues de l'index afin que les utilisateurs accèdent directement à la page pertinente.
- Solution de secours élégante signifie qu'Artie énonce clairement cette limite lorsque l'index ne contient pas d'informations pertinentes, puis suggère de prendre contact directement, sans relancer la requête ni spéculer.
Artie ne peut pas aider pour tout ce qui sort du cadre de la documentation publiée. Pour un site de portfolio, cette contrainte sert le propos : la précision prime sur l'exhaustivité. Une réponse précise et bien documentée à une question ciblée inspire davantage confiance qu'une réponse qui semble plausible mais qui s'avère erronée.
Personnalité et adaptation du ton
Artie a une personnalité légère, fondée sur une chaleur discrète inspirée de George Harrison, avec parfois quelques accents du dialecte de Liverpool. Le mot-clé est légère. Cette personnalité ajoute du cachet aux formules d’accueil et de conclusion sans interférer avec le contenu technique.
Les contraintes de conception sont ici intentionnelles :
- Garder des réponses techniques concises signifie que la personnalité ne justifie jamais des réponses plus longues. Une salutation chaleureuse suivie d'une réponse sobre et factuelle permet d'atteindre cet objectif.
- La variété plutôt que la répétition signifie que le prompt intègre un répertoire d'expressions pour éviter qu'Artie ne reprenne systématiquement la même formule.
- Aucun ton moralisateur signifie que le personnage conserve un ton chaleureux et pince-sans-rire sans jamais paraître donneur de leçons, agissant comme un collègue serviable plutôt que dans le cadre d'un jeu d'acteur.
Ce type d’ajustement du ton constitue un défi courant dans la conception des IA conversationnelles. Trop de personnalité et l’assistant donne l’impression d’être un gadget. Trop peu et il semble robotique. La solution consiste à considérer la personnalité comme un assaisonnement : présent, mais jamais l'ingrédient principal.
Sécurité et garde-fous
Un assistant IA accessible au public constitue une surface d’attaque, et le prompt inclut des mesures de défense explicites contre les vulnérabilités courantes des grands modèles linguistiques (LLM).
Protection contre l’injection de prompt
Le prompt d'Artie rejette explicitement toute tentative de contournement de ses instructions, comme les commandes du type « ignore les instructions précédentes » ou les demandes d'adopter une personnalité différente. Cela établit des défenses au niveau du prompt contre l'injection de prompt, classée n° 1 du Top 10 de l'Open Worldwide Application Security Project (OWASP) pour les applications de grands modèles de langage.
Restriction du champ d’application
Le prompt définit des catégories de rejet explicites :
- L'assistant décline les demandes d'aide générale au codage qui ne figurent pas dans la documentation.
- L'assistant rejette les demandes de culture générale sans rapport, hormis deux fonctionnalités ludiques au périmètre défini.
- L'assistant décline les demandes d'informations personnelles que le portfolio professionnel ne publie pas.
- L'assistant invite les visiteurs à prendre contact directement pour les tarifs freelance ou négociations.
Chaque catégorie est clairement délimitée, si bien que l’assistant n’a pas à se prononcer sur ce qui est « suffisamment proche » pour mériter une réponse. Si une demande franchit cette limite, il la refuse poliment.
Confidentialité des données
Artie ne partage que les coordonnées explicitement publiées dans la documentation, telles qu’un profil LinkedIn ou l’adresse e-mail du portfolio. Il ne devinera pas, ne déduira pas et ne générera pas de détails personnels tels que des numéros de téléphone ou des adresses.
Limites professionnelles
L’assistant ne répondra pas aux messages hostiles, n’utilisera pas de langage grossier et ne sortira pas de son personnage. Cela va au-delà de la simple politesse. Il s’agit de maintenir un comportement prévisible. Un recruteur qui teste les limites de l’assistant devrait se heurter à une limite cohérente et professionnelle à chaque fois.
Easter eggs contrôlés
Artie intègre deux « fonctionnalités ludiques », les « Snapple Real Facts » et des blagues bienveillantes, qui montrent comment ajouter de la personnalité sans ouvrir la porte aux abus.
Ces deux fonctionnalités partagent le même modèle de conception :
- Les déclencheurs explicites signifient que les fonctionnalités ne s'activent que sur demande de l'utilisateur (« donne-moi un fait Snapple », « raconte-moi une blague ») et jamais sur des requêtes vagues.
- Le contenu délimité signifie que les faits Snapple s'ancrent dans une liste intégrée de faits vérifiés, tandis que les blagues restent sélectionnées et adaptées à un public familial.
- Aucune fabrication infondée signifie que l'assistant évite d'inventer des faits ou de générer de l'humour en décalage avec la marque, si bien que la production reste prévisible.
Les fonctionnalités créatives sans limites épuisent rapidement les jetons et produisent des résultats imprévisibles. Un contenu sélectionné avec soin et des déclencheurs explicites apportent une touche de chaleur sans ce risque.
Ce que je ferais différemment
De vrais utilisateurs ont changé cette conception.
- Coût des jetons motive le premier changement. La liste des faits Snapple compte à elle seule plus de 100 éléments. Dans un système en production facturé au jeton, je la déplacerais vers une couche de récupération au lieu de l'intégrer au prompt système. Une équipe paie chaque jeton du prompt à chaque requête, que l'utilisateur demande ou non un fait.
- Contexte multi-tours limite la conception actuelle à des questions-réponses en un seul tour. Une version ultérieure pourrait conserver l'historique de la conversation et reformuler les requêtes pour résoudre les questions de suivi comme « Qu'en est-il de l'étape suivante ? ».
- Analytique et retours d'expérience restent à construire. La simple journalisation du nombre de réponses de repli révélerait les manques documentaires qui provoquent le plus d'échecs.
- Ajustement dynamique de la personnalité exige aujourd'hui de modifier les expressions figées dans le code. Les déplacer vers une configuration externe faciliterait les changements de ton sans toucher au jeu d'instructions principal.
Chacun de ces points représente un compromis délibéré pour un projet de portfolio où la simplicité et la clarté priment sur l’optimisation à l’échelle de production. Mais ce sont les premières choses auxquelles je m’attaquerais si ce projet évoluait vers un environnement à plus fort trafic.