Restons en contact

Social

ConcluantEXP-05iones lab

RAG & Hermes : chercher dans 1 200 documents internes sans halluciner

La questionPeut-on donner à nos équipes une réponse fiable et sourcée sur n’importe quel projet, en moins de trois secondes, à partir de notre documentation existante ?

Verdict

Oui, à condition d’imposer la citation des sources et de refuser de répondre quand aucun passage ne soutient la réponse. Le reclassement fait la différence, pas le modèle.

DécisionAdopté. Intégré à Jarvis et utilisé quotidiennement par l’équipe.

Statut
Concluant
Durée
4 semaines
Équipe
2 développeurs, 1 architecte
Stack
  • Hermes
  • pgvector
  • BM25
  • Cohere Rerank
  • Claude
  • MCP
0,84précision à 5 résultatscontre 0,61 sans reclassement
2 %réponses avec hallucinationcontre 11 % au départ
2,1 slatence médianede la question à la réponse complète
1 200documents indexés38 000 passages

Contexte

Quinze ans de projets, ça fait beaucoup de documentation : spécifications, comptes rendus, procédures de déploiement, décisions d’architecture, tickets. Tout existe, mais retrouver « pourquoi on a choisi cette règle de calcul de TVA sur le projet X en 2023 » prend souvent plus de temps que de redemander au collègue qui s’en souvient. Et il n’est pas toujours là.
Un premier prototype de recherche par similarité, monté en deux jours, donnait des réponses convaincantes. Trop convaincantes : en relisant une centaine de réponses, nous en avons trouvé onze qui inventaient un détail, avec un aplomb parfait. Le lab a donc pris le sujet avec un objectif clair : mesurer, puis réduire ce taux jusqu’à un niveau acceptable pour un usage quotidien.

Ce qu’on a testé

Nous avons constitué un corpus de 1 200 documents issus de six projets terminés, découpés en 38 000 passages, et un jeu de 180 questions rédigées par les chefs de projet avec la réponse attendue et le document source. Chaque variante du pipeline a été évaluée sur ce même jeu.
  • V1 : recherche vectorielle seule (embeddings, pgvector), 5 passages envoyés au modèle.
  • V2 : recherche hybride, vecteurs + BM25 fusionnés, pour rattraper les termes exacts (noms de tables, codes d’erreur, références de tickets).
  • V3 : V2 plus reclassement des 30 premiers passages par un modèle de rerank, 5 conservés.
  • V4 : V3 plus consigne stricte : chaque affirmation doit citer un passage, et le modèle doit répondre « je ne trouve pas » si aucun passage ne soutient la réponse.
  • Skills Hermes : des compétences spécialisées par type de question (procédure, décision, chiffre) qui adaptent la requête et le format de réponse.

Résultats

0,61

précision@5 en vectoriel seul (V1)

0,72

précision@5 en hybride (V2)

0,84

précision@5 avec rerank (V3)

2 %

hallucinations avec citations obligatoires (V4)

Le reclassement est le levier le plus rentable. Passer de V2 à V3 coûte 180 ms de latence et améliore la précision de 12 points. Changer de modèle d’embeddings, en revanche, n’a déplacé la mesure que de 2 points. Nous avons cessé de comparer les modèles et concentré l’effort sur la chaîne de recherche.
La règle de refus divise le taux d’hallucination par cinq. Avec la consigne de citation obligatoire, le modèle répond « je ne trouve pas dans la documentation » sur 9 % des questions. C’est frustrant, mais neuf fois sur dix la réponse n’existait effectivement pas dans le corpus. Les 2 % d’hallucinations restantes sont des raccourcis entre deux passages proches, sur des projets aux règles métier similaires.
  • La recherche hybride règle presque tous les échecs sur les identifiants exacts : un code d’erreur ou un nom de table ne se retrouve pas par similarité sémantique.
  • Les skills Hermes améliorent surtout la forme : une procédure rendue en étapes numérotées, une décision avec ses alternatives écartées. Gain de précision faible, gain d’usage réel.
  • La latence médiane de 2,1 s est tirée par la génération, pas par la recherche (280 ms tout compris).
  • Découpage des passages : 400 tokens avec chevauchement de 80 a donné les meilleurs résultats. Plus court perd le contexte, plus long dilue la réponse.

Ce qu’on en conclut

Un RAG fiable est d’abord un moteur de recherche fiable. Le modèle de langage ne fait que reformuler ce qu’on lui donne ; si la recherche ramène le bon passage, la réponse est bonne. Nous avons passé 80 % du temps du lab sur l’indexation, la fusion et le reclassement, et c’est là qu’étaient les gains.
La contrainte de citation change le rapport de confiance. Une réponse sourcée peut être vérifiée en un clic, une réponse non sourcée doit être crue sur parole. Nous n’exposerons jamais à un client un assistant qui ne cite pas ses sources.
Le jour où l’outil a répondu « je ne trouve pas » à une question dont j’étais sûr de connaître la réponse, j’ai vérifié : la doc n’existait pas. On l’a écrite.
Chef de projet, équipe BUILD

Et maintenant

  • Le pipeline V4 est intégré à Jarvis et indexe désormais la documentation de tous nos projets actifs, avec réindexation chaque nuit.
  • Les questions « je ne trouve pas » sont remontées chaque semaine aux chefs de projet : c’est devenu notre meilleur détecteur de documentation manquante.
  • Prochaine étape : évaluer le même pipeline sur la documentation d’un client, avec cloisonnement strict par projet.