Assistant IA pour docs : notre recette pour un agent fiable

Assistant IA pour docs : notre recette pour un agent fiable

Temps de lecture : 4 min

Points clés à retenir

  • Validation : Une approche data-driven avec métriques LLM et déterministes est indispensable pour éviter les hallucinations.
  • Architecture : Un proxy interne offre contrôle, observabilité et résilience sans réinventer la roue.
  • Prompting : L’ingénierie de prompts stratifiée (identification produit, validation des chunks) est la clé de la précision.

Pourquoi un agent IA plutôt qu’une simple API de complétion ?

Je vois souvent des équipes sauter directement sur une API de complétion LLM pour automatiser leur support. Concrètement, c’est souvent une erreur. Pour un assistant de documentation, vous avez besoin de comportements orientés tâche : ancrage dans une base de connaissances, gestion de session pour les questions de suivi, et un flux orchestré qui va au-delà d’un simple appel « prompt-réponse ».

Dans notre cas, l’agent nous a apporté des défauts gérés que nous n’avons pas eu à construire. Les chunks récupérés sont reclassés par pertinence avant d’être envoyés au modèle. L’agent maintient le contexte de la conversation. Lors de l’indexation, la plateforme a géré le nettoyage et le chunking automatiquement. Plus précisément, cela nous a évité des semaines de travail d’ingénierie sur un système de RAG custom.

Deux interfaces, deux problèmes résolus

Nous avons déployé l’agent via deux canaux, une leçon d’architecture que j’applique aussi chez WebNyxt.

  • Embedding direct : Un snippet JavaScript intégré directement au site de documentation. Solution low-cost pour un déploiement rapide et une première validation utilisateur. Simple, mais limité en observabilité.
  • Proxy API interne : Une passerelle API qui route les requêtes vers un service proxy, lui-même connecté à l’agent. L’authentification repose sur la session existante de l’utilisateur. La complexité ajoutée ici est rentable.
A Lire :  Prompt Caching : Réduire les coûts LLM de 70% en production

Le proxy nous a donné ce que le snippet JS ne pouvait pas offrir : la capacité de mesurer le TTFT (Time To First Token) au niveau du proxy, un logging unifié, du rate limiting réutilisé, et une couche de traduction entre le frontend et l’API de l’agent. Nous déployons plusieurs instances de proxy avec leurs agents dédiés, provisionnés via Terraform pour éviter la dérive de configuration. Aucun point de défaillance unique.

L’approche data-driven : mesurer pour améliorer

En développement IA, déployer sans mesurer, c’est naviguer à l’aveugle. Changer un prompt sans évaluer son impact est une perte de temps. Nous avons défini un mix de métriques, certaines utilisant un LLM comme juge, d’autres déterministes et rapides.

  • Exactitude (Correctness) : Un juge LLM évalue si la réponse est factuellement exacte. Elle attrape les hallucinations en domaine ouvert.
  • Adhérence à la vérité terrain (Ground Truth Adherence) : Mesure si la réponse est sémantiquement équivalente à une réponse de référence connue. Une réponse peut être factuellement vraie mais manquer la cible de la question.
  • Temps jusqu’au premier token (TTFT) : Métrique déterministe cruciale. La latence, l’utilisateur la perçoit avant tout.
  • Exactitude des URLs : Nous extrayons tous les liens de la réponse via regex et vérifions qu’ils résolvent avec une requête HTTP. Un lien mort sape immédiatement la confiance.

Notre barre de release était de 80% d’adhérence à la vérité terrain et 95% d’exactitude. Atteindre ces chiffres a nécessité des itérations constantes.

L’ingénierie de prompts en couches

L’exactitude ne vient pas d’un prompt magique, mais d’une ingénierie stratifiée. Voici ce qui a fait bouger nos métriques :

  • Identification du produit : Des mappings de mots-clés dans le prompt pour router la question vers le bon contexte produit (ex: Kubernetes vs App Platform).
  • Validation des chunks : Un garde-fou explicite interdit le « cross-product blending » – répondre à une question sur un produit avec la doc d’un autre, même si les chunks sont sémantiquement proches.
  • Conscience des échecs de retrieval : Le prompt contient une heuristique sophistiquée pour distinguer « la doc ne couvre pas ce sujet » de « le retrieval a simplement échoué ». Cela empêche l’agent de nier l’existence de fonctionnalités qui existent.
A Lire :  Générateur d'emails IA : comment les PME gagnent du temps sur leurs campagnes

Nous avons aussi ajusté des paramètres techniques : température à 0.1, réduction du paramètre de retrieval k de 10 à 5 pour améliorer le TTFT, et ajout de contraintes strictes dans la réponse : pas de listes exhaustives, langage direct, liens vers la page tarifaire officielle pour les questions de prix.

Le dataset d’or et l’évaluation continue

Le cœur du système, c’est le « golden dataset » – une collection de paires question/réponse que nous considérons comme parfaites. Chaque entrée a des métadonnées : domaine produit, niveau de difficulté (« light » vs « heavy »), source de la question. Comme pour GymLog, où nous itérons sur les routines d’entraînement, nous avons retravaillé ce dataset en corrigeant des réponses inexactes et en réduisant l’ambiguïté des questions.

Les évaluations tournent sur la plateforme, utilisant une approche LLM-as-a-Judge avec plusieurs juges GPT-4o et un raisonnement en chaîne (Chain-of-Thought). Les scores (entre 0 et 1) et les métadonnées sont envoyés via OTLP vers notre cluster d’observabilité pour un suivi continu.

Concrètement, construire un assistant IA fiable, c’est 20% d’architecture et 80% de rigueur sur la validation et l’optimisation des prompts. C’est un travail de fond, moins glamour que le dernier modèle à la mode, mais c’est ce qui sépare un prototype d’un produit que vous pouvez shipper en confiance.