Politique RH adaptée à la production avec RAG, LangChain et LangGraph
Ingestion, MMR, réécriture tenant compte du contexte historique, réponses fondées sur des données concrètes, mécanismes de contrôle, évaluation, citations et orchestration de graphes pour un assistant à la politique RH.
Un guide complet couvrant l’ingestion des données, la récupération de documents via MMR, les requêtes tenant compte du contexte historique, les vérifications de sécurité, les points d’ancrage pour l’évaluation, ainsi que l’expérience utilisateur dans les conversations à plusieurs tours.
Introduction
Des réponses génératives fluides ne suffisent pas pour les ressources humaines d’entreprise. Un assistant dédié aux politiques ne doit pas inventer des règles de congés à partir de l’entraînement préalable ; il doit plutôt récupérer les documents approuvés et fonder chaque demande sur ces sources. C’est là la fonction de la génération augmentée par la récupération de données (RAG).
Une pile de questions-réponses pour les politiques RH, modulaire et conçue pour la production, peut combiner Python, LangChain, LangGraph, un modèle de chat compatible avec OpenAI, ChromaDB, Streamlit, des embeddings, une récupération par MMR, un réécriture de requêtes tenant compte de l’historique, une conception de prompts, une modération des entrées, des vérifications contre les injections de prompts, une évaluation de la récupération, une mémoire conversationnelle, un résumé et une exportation en PDF. L’objectif n’est pas de créer un chatbot démonstratif — il s’agit d’un système RAG qui prend au sérieux la qualité de la récupération des informations, le contexte de la conversation, la sécurité, l’évaluation et l’ergonomie.
1. Le problème
Lorsqu’on demande « Combien de jours de congé maladie sont autorisés ? », un LLM classique peut inventer une réponse. Un assistant RH, quant à lui, devrait :
- Comprendre la question
- Rechercher dans les documents RH de l’organisation
- Récupérer les sections les plus pertinentes
- Transmettre ces sections au modèle
- Générer une réponse basée sur elles
Flux global : documents RH → ingestion → segmentation en chunks + métadonnées → vecteurs d’incorporation → ChromaDB → outil de récupération → requête tenant compte de l’historique → documents pertinents → prompt ciblé → réponse → citations.
2. Ingestion des documents
Les politiques brutes sont transformées en chunks pouvant être recherchés. Les documents complets sont trop volumineux pour être intégrés dans chaque prompt et risquent de dépasser les limites de contexte. Les chunks contiennent des métadonnées telles que le nom du fichier, le chemin, le dossier, le type de document et les étiquettes de source — utiles par la suite pour les citations, le débogage et l’analyse des résultats de récupération.
3. Vecteurs d’incorporation et stockage vectoriel
Chaque chunk devient un vecteur d’incorporation :
"Employees receive annual leave..."
↓
Embedding Model
↓
[0.12, -0.43, 0.87, ...]
Les vecteurs et les métadonnées sont stockés dans ChromaDB. Les questions des utilisateurs sont également incorporées de la même manière, ce qui permet à des politiques sémantiquement proches d’apparaître même en cas de formulation différente (“congé pour maladie” vs “droit au congé de maladie”).
4. Recherche avec MMR
La similarité naïve top-k peut retourner quatre fragments de politique de congé presque identiques :
Chunk 1 → Leave policy
Chunk 2 → Leave policy
Chunk 3 → Leave policy
Chunk 4 → Leave policy
La rélevance marginale maximale équilibre la pertinence et la diversité. Un ensemble de candidats plus grand fetch_k, suivi d’une sélection MMR des k éléments finaux, réduit la redondance :
10,000 chunks
↓
Similarity search
↓
20 candidate chunks
↓
MMR
↓
4 diverse + relevant chunks
↓
LLM
5. Recherche tenant compte de l’historique
Des questions comme « Et les managers ? » après une réponse concernant les congés annuels sont ambiguës seules. Une étape prenant en compte l’historique réécrit la requête à l’aide de l’historique de conversation avant la recherche :
Conversation History
+
Current Question
↓
LLM
↓
Standalone Search Query
Cela sépare la contextualisation de la requête (que voulait dire l’utilisateur ?) de la génération de réponse (que doit dire la réponse compte tenu des documents ?).
6. Génération de réponses ancrées dans le contexte
Les fragments récupérés alimentent une instruction qui demande au modèle d’utiliser uniquement des documents RH, d’éviter d’inventer des politiques, de mettre en évidence les exclusions, de rester concis et d’admettre les lacunes. Architecture : question → contextualisation → outil de récupération → documents → instruction de vérification → LLM → réponse fondée. Le modèle rédige le texte ; le corpus fournit les faits.
7. Pourquoi LangGraph
Au fur et à mesure que les étapes se multiplient — validation, modération, détection des injections, traitement des requêtes, récupération, génération, mémoire, résumé — une chaîne linéaire devient fragile. LangGraph modélise le flux de travail sous forme d’états et de nœuds :
User Input
↓
Validation
↓
Guardrails
↙ ↘
Safe Unsafe
↓ ↓
RAG Workflow Reject
↓
Final Response
↓
Conversation
Management
Le graphe reste plus facile à étendre qu’une seule fonction massive.
8. Garde-fous
Les entrées en production nécessitent des vérifications avant l’application de RAG :
- Modération — bloquer rapidement le contenu en violation des politiques
- Détection des injections d’instructions — refuser les attaques du type « ignorer les instructions précédentes… »
L’ordre est crucial : entrée de l’utilisateur → vérifications de sécurité → RAG, et non entrée de l’utilisateur → LLM brut.
9. Mémoire conversationnelle et résumé
Les assistants à plusieurs échanges ont besoin d’un historique, mais les transcriptions illimitées consomment beaucoup de tokens. Résumer les échanges anciens permet de conserver l’essentiel tout en limitant le contexte actif — un équilibre entre préservation et coût.
10. Évaluation de la récupération
11. Citations des sources
12. Export de la conversation en PDF
exporter une conversation en PDF permet aux employés de conserver un enregistrement pour plus tard. Il s’agit d’un détail d’utilisabilité qui montre que le système est conçu pour un travail réel, et non pour un simple widget de chat temporaire.
Fermeture
un assistant RAG RH adapté à un environnement de production repose sur une chaîne d’opérations comprenant l’ingestion des données, la stratégie de récupération, la réécriture conversationnelle, le contextualisation, l’orchestration des graphes, les contraintes, l’évaluation et les citations. LangChain et LangGraph aident à mettre en place ces étapes ; Chroma et MMR déterminent ce que le modèle est autorisé à voir. La règle absolue du produit reste la suivante : les réponses issues des politiques proviennent de documents approuvés, et non de la mémoire du modèle concernant Internet.
Choix de conception importants en pratique
La taille des blocs et leur chevauchement ne sont pas des détails esthétiques. Des blocs trop grands affaiblissent le signal d’incorporation ; des blocs trop petits perdent les contraintes de politique environnantes. Le chevauchement est utile lorsque une règle dépasse une frontière. Les métadonnées ne sont pas une décoration optionnelle — sans nom de fichier et indications de section, les citations deviennent vagues et les ensembles d’évaluation difficiles à évaluer.
Les paramètres MMR (fetch_k, k, lambda de diversité) doivent être ajustés en fonction d’un ensemble de questions étiquetées, et non sur intuition. Un pool de candidats trop petit ne permet jamais d’obtenir des passages variés ; un pool trop grand gaspille du temps de traitement.
La réécriture tenant compte de l’historique ne doit pas inventer de faits. L’étape de réécriture ne devrait que développer les pronoms et les suites incomplètes en requêtes de recherche indépendantes. Si le modèle de réécriture tend à répondre directement, la récupération ne reçoit jamais une requête propre.
Les mécanismes de protection doivent être en place avant la récupération des données. La modération et la détection d’injections effectuées après que le modèle a déjà pris connaissance du texte de la politique privée sont trop tardives. Il faut bloquer immédiatement en cas de suspicion d’injection ; ne pas autoriser de traitement que si la politique du produit permet explicitement des blocages temporaires accompagnés d’enregistrement des événements.
L’évaluation doit prendre en compte à la fois la récupération des données (taux de rappel@k des IDs de documents attendus) et la génération du texte (fidélité au texte récupéré). Une réponse présentable mais basée sur une clause incorrecte constitue néanmoins un échec. Il convient de conserver des traces : la requête réécrite, les IDs récupérés, la réponse finale et la liste des citations.
Streamlit (ou tout autre interface légère) doit afficher clairement les citations ainsi que les états « inconnus ». Les employés font plus confiance aux systèmes qui admettent leurs limites qu’aux systèmes qui inventent des politiques de congés excessives.
L’export vers PDF est une fonctionnalité de conservation : les utilisateurs collent les réponses issues des politiques dans leurs tickets. Le texte exporté doit être considéré comme potentiellement sensible, et les mêmes contrôles d’accès que pour la session de chat doivent être appliqués.
Finalement, assurez-vous que le parcours principal du graphique soit évident. Les nouveaux ingénieurs doivent pouvoir relier validation → réécriture → récupération → génération → réponse sans devoir explorer des branches optionnelles. Les branches optionnelles (résumé, export) sont rattachées à des nœuds clairs plutôt que d’être imbriquées au sein du processus de génération.
Cette discipline permet de transformer une démonstration RAG du week-end en quelque chose que l’équipe RH peut tester sans craindre d’hallucinations liées aux politiques définies.
Organiser les éléments dans un calendrier
HR DOCUMENTS
│
▼
DOCUMENT INGESTION
│
Chunking + Metadata
│
▼
EMBEDDINGS
│
▼
CHROMADB
│
▼
RETRIEVER
(MMR Search)
│
│
USER ──→ GUARDRAILS ─────┤
│
▼
HISTORY-AWARE QUERY
CONTEXTUALIZATION
│
▼
RETRIEVAL
│
▼
RELEVANT DOCUMENTS
│
▼
QA PROMPT + LLM
│
▼
GROUNDED ANSWER
│
┌────┴────┐
↓ ↓
Citations Memory
│
▼
Summarization
│
▼
PDF Export
La première journée se limite souvent à l’incorporation de PDF et aux conversations. C’est à partir des jours deux jusqu’à dix que les aspects réels du système apparaissent : schémas de métadonnées, ajustement des MMR, suggestions de réécriture, mécanismes de modération, classificateurs d’injection, feuilles de calcul d’évaluation, formatage des citations et résumé des conversations. Omettre ces étapes conduit à un système qui fonctionne bien avec des questions simples mais échoue dès la deuxième interaction, face à des prompts adversariaux ou lors de la récupération de contenus presque identiques.
LangChain aide à relier les modèles et les outils de récupération d’informations ; LangGraph permet de rendre le flux de contrôle facilement inspectable. Aucun des deux ne remplace une décision stratégique concernant les dossiers RH considérés comme fiables, les personnes autorisées à poser des questions sur certaines politiques, ainsi que l’apparence des éléments « inconnus » dans l’interface utilisateur. Ces décisions doivent figurer dans les documents de conception à côté du diagramme du graphe.
Lorsqu’un problème survient en production, la méthode de débogage la plus rapide consiste généralement à examiner la requête réécrite, à lister les identifiants des blocs récupérés, à lire ces blocs, puis à lire le prompt correspondant. Si cette séquence fait défaut dans les journaux, il faut améliorer la capacité d’observation avant d’ajouter un autre modèle.