Préparation du contenu RAG
Préparer le contenu pour la récupération RAG : les titres du site
Préparez le contenu d’un site à la récupération RAG avec des titres clairs, des sections autonomes et un test à requêtes fixes sans surinterpréter les résultats.
11 min de lecture

La préparation du contenu pour la récupération RAG commence par des titres qui nomment clairement le sujet, puis par des sections qui contiennent assez de contexte pour être comprises seules. Les éditeurs peuvent rendre leurs pages sources plus claires et plus faciles à tester. Ils ne peuvent ni garantir un résultat de récupération, ni contrôler la chaîne d’ingestion d’un fournisseur.
En pratique, concentrez-vous sur trois points :
- nommez dans chaque titre l’entité, la tâche, la règle ou la condition ;
- gardez ensemble la réponse directe, le contexte essentiel et les exceptions ;
- figez un jeu de requêtes et comparez séparément la récupération, le soutien par les citations et l’exhaustivité de la réponse.
Qui, comment et pourquoi. Ce guide s’adresse aux responsables de documentation et de contenu web. Il combine l’examen de l’implémentation actuelle d’exploration et de réponses sourcées d’Achla, des documents primaires datés et un protocole de test contrôlé par l’éditeur. Le protocole n’a pas encore été exécuté : tous les résultats restent inconnus. L’objectif est d’aider les éditeurs à tester les changements qu’ils contrôlent, pas de laisser entendre que les titres garantissent de meilleures réponses.
Qu’est-ce qui facilite la récupération du contenu d’un site dans un RAG ?
La génération augmentée par récupération, ou RAG, utilise des sources récupérées pour ancrer une réponse générée. Un système peut évaluer un passage indépendamment du reste de la page. La documentation Azure AI Search de Microsoft décrit, par exemple, le découpage de grands documents afin que des portions puissent être appariées séparément. Il s’agit d’une description du système de Microsoft, pas d’une formule universelle pour les titres.
Pour un éditeur, un contenu prêt pour la récupération est donc un contenu dont les sections importantes restent intelligibles avec peu de contexte environnant. Une section utile indique son sujet, répond à une question cohérente, nomme les conditions pertinentes et garde les exceptions essentielles à proximité. Une structure claire rend la source plus facile à examiner et l’expérience plus reproductible ; son effet sur un résultat RAG précis doit encore être mesuré.
Que pouvez-vous modifier, et qu’est-ce qui reste dans la pile de récupération ?
Le point de départ le plus sûr consiste à séparer strictement la page source du backend du fournisseur.
| Contenu contrôlé par l’éditeur | Ingestion et récupération contrôlées par le fournisseur |
|---|---|
| Titres visibles et hiérarchie | Analyse et limites des fragments |
| Sujet et portée de la section | Taille et chevauchement des fragments |
| Réponses directes, prérequis et exceptions | Embeddings et champs d’embedding |
| Listes, libellés et texte significatif pour les faits visuels | Métadonnées et formats d’indexation |
| Exactitude, version et liens internes de la page | Pipelines de récupération, reranking et seuils |
Que peut changer l’éditeur d’un site ?
Vous pouvez réécrire des libellés vagues, séparer des sujets mélangés, rapprocher une réponse de son titre, nommer le produit ou le public concerné et ajouter un texte visible aux informations essentielles présentes uniquement dans une image. Vous pouvez aussi conserver une hiérarchie logique : un sujet par page, des H2 pour les grandes sections et des H3 qui précisent leur section parente.
Pour le cas d’usage commercial plutôt que la méthode de rédaction, consultez la recherche IA pour la documentation.
Que contrôle le fournisseur de récupération ?
Les fournisseurs décident comment leurs systèmes analysent, découpent, représentent, indexent, récupèrent et classent le contenu. OpenSearch documente par exemple le découpage du texte comme une étape du pipeline d’ingestion qui divise les longs textes en passages ciblés selon les contraintes du modèle. Cette implémentation OpenSearch éclaire la frontière ; elle ne montre pas qu’Achla expose des réglages de taille de fragment ou d’embedding.
Ce guide ne traite pas non plus de l’installation ou de l’architecture backend. Consultez comment ajouter une recherche IA sans construire de backend pour cette tâche distincte.
Comment auditer les titres et les sections avant de réécrire ?
Examinez la page comme si chaque section pouvait apparaître sans les paragraphes précédents. Il ne s’agit pas de rendre chaque paragraphe répétitif, mais de repérer les passages dont le sens dépend d’un contexte caché.
| Symptôme | Élément possiblement manquant | Action de l’éditeur |
|---|---|---|
| Le titre dit « Vue d’ensemble », « Notes » ou « Exceptions » | Le sujet réel | Nommer l’entité, la tâche ou la règle |
| Une section couvre plusieurs produits ou rôles | Une portée cohérente | Séparer selon la décision ou le public |
| Le paragraphe commence par « il », « ceci » ou « ils » | Un référent explicite | Renommer naturellement le sujet |
| Une règle est éloignée de son exception | La condition qui change la réponse | Garder l’exception avec la règle |
| Des faits importants sont uniquement dans une image | Un texte visible et explorable | Ajouter un texte proche ou une alternative adaptée |
Quels titres masquent le sujet ?
Cherchez les libellés génériques qui ne fonctionnent que si le lecteur se souvient du titre précédent. Le titre synthétique faible « Limites » devient plus utile sous la forme « Limites des exports de rapports hors ligne ». La reformulation nomme le sujet et le type d’information sans imposer un modèle à toutes les pages.
Quelles sections mélangent les décisions ou dépendent d’un contexte manquant ?
Demandez-vous si la section change à mi-parcours de produit, de rôle, de région, d’offre, de version ou de procédure. Distinguez aussi un problème de vocabulaire d’un problème structurel : si les visiteurs utilisent d’autres termes, appliquez les idées d’évaluation sur les recherches formulées différemment. Si les bons mots sont présents mais dispersés entre des décisions sans rapport, améliorez le contexte de la section.
Quels faits restent enfermés dans des images, tableaux ou libellés ?
Les faits essentiels doivent exister dans un texte visible porteur de sens. AWS recommande des titres clairs, des documents ciblés, un contexte de section et des descriptions textuelles pour les illustrations dans ses pratiques de documentation RAG. Ce sont des recommandations AWS, pas la preuve d’un résultat pour votre site. Les tableaux restent utiles aux lecteurs ; ajoutez du texte à proximité lorsqu’une règle clé serait sinon ambiguë.
Comment les titres doivent-ils préserver le sujet et la portée ?
Rédigez les titres comme des panneaux destinés à une personne pressée : assez précis pour annoncer la section, assez courts pour être parcourus rapidement, et imbriqués selon l’organisation réelle de la page.
| Formulation synthétique faible | Formulation plus forte contrôlée par l’éditeur | Élément rendu explicite |
|---|---|---|
| « Configuration » | « Configurer le SSO pour les comptes de prestataires » | Tâche et public |
| « Exceptions » | « Exceptions de remboursement pour les offres annuelles » | Règle et offre |
| « Europe » | « Durées de conservation des données pour les espaces de travail de l’UE » | Sujet et région |
| « Dépannage » | « Pourquoi les exports CSV omettent les enregistrements archivés » | Problème et objet |
Comment garder une hiérarchie descriptive plutôt que décorative ?
Utilisez un H1 pour le sujet principal, des H2 pour les grandes questions et des H3 pour les questions plus étroites de chaque section. Le W3C explique que les titres communiquent l’organisation du contenu et que les titres de niveau inférieur forment des sous-sections. Suivez cette hiérarchie sémantique pour la structure et la navigation, pas parce que le W3C prétend démontrer un gain RAG.
Où placer la réponse directe ?
Placez la réponse dans la première phrase ou le premier paragraphe court sous le titre concerné. Ajoutez ensuite prérequis, détails, exemples, puis exceptions. Une section intitulée « Exceptions de remboursement pour les offres annuelles » ne devrait pas commencer par l’histoire de l’entreprise et révéler l’exception quatre paragraphes plus tard.
Où placer les conditions et les exceptions ?
Gardez la portée à côté de l’énoncé qu’elle modifie. Nommez l’offre, le rôle, le produit, la région, la version ou la date d’effet dans le titre ou la phrase d’ouverture lorsque cela change matériellement la réponse. Ne cachez pas une réserve décisive dans une section générique « Notes » en bas de page.
Comment rendre chaque section compréhensible de manière autonome ?
Une section autonome contient le contexte minimal nécessaire pour interpréter son affirmation. C’est d’abord une unité de preuve cohérente pour les lecteurs, pas un fragment backend prescrit.
Quels éléments vont ensemble dans une section ?
Gardez ensemble un sujet, une décision ou une procédure, y compris ses prérequis et exceptions essentielles. Séparez les sujets sans rapport. Sur une page de politique synthétique, le délai d’annulation et l’exception pour les comptes réglementés vont ensemble ; les instructions de mise à niveau vont ailleurs.
Quelle quantité de contexte faut-il répéter ?
Ne répétez que ce qui lève une ambiguïté. Remplacez « Il est disponible après 30 jours » par « L’export du journal d’audit est disponible après 30 jours » si le sujet disparaîtrait autrement. Évitez de répéter le nom complet du produit à chaque phrase ou de remplir la section de variantes de mots-clés.
Comment rédiger les listes et les tableaux ?
Utilisez des listes pour les étapes ordonnées ou les éléments comparables, avec des libellés qui conservent le sens. Utilisez les tableaux lorsque les lignes et colonnes clarifient réellement une comparaison. Si une cellule contient une règle essentielle, résumez-la dans le texte voisin. La compréhension du lecteur reste prioritaire ; aucun format ne possède un avantage universel en matière de récupération.
Comment exécuter un test de récupération avant/après avec des requêtes fixes ?
Utilisez une expérience versionnée, respectueuse de la confidentialité, qui ne modifie que le contenu contrôlé par l’éditeur. Cette évaluation de récupération de contenu sépare la modification de la page source du comportement du backend. L’implémentation actuelle d’Achla explore les pages publiques autorisées d’un même site, et son parcours principal de réponse sourcée exige du texte accompagné de citations, sinon il renvoie une absence/réponse de repli. Ces comportements limités rendent récupération et citation observables ; ils ne promettent aucun gain lié à la restructuration.
Comment figer les questions et les sources attendues ?
Choisissez un site connecté et autorisé. Créez des identifiants de requête, conservez la formulation exacte et nommez la source canonique attendue. Incluez des paraphrases réalistes et des cas honnêtes sans réponse. N’utilisez aucune donnée personnelle, confidentielle, de compte ou secrète.
| ID de requête | Requête fixe | Source attendue | Preuve attendue |
|---|---|---|---|
| SYN-01 | « Quand les prestataires peuvent-ils utiliser le SSO ? » | /help/contractor-access | Règle d’éligibilité |
| SYN-02 | « Le site indique-t-il un SLA d’assistance téléphonique ? » | aucune | Cas honnête sans réponse |
Que doit enregistrer séparément la mesure de référence ?
Pour chaque requête, notez si la source attendue apparaît, si la citation étaye réellement la réponse et si la réponse est complète. Traitez cela comme un test des sources citées et ne fusionnez pas ces champs en un score unique de « précision ». Pour un processus plus approfondi, vérifiez si les citations étayent la réponse.
Que peut-on modifier pendant le test ?
Modifiez uniquement les titres, limites de sections, sujets explicites, réponses voisines, conditions, exceptions et alternatives textuelles. Conservez la version du contenu et le diff. Ne modifiez pas le découpage, les champs de schéma, les formats d’embedding ou d’indexation, les pipelines de récupération, le reranking ou les seuils, et ne laissez pas entendre qu’Achla expose ces contrôles.
Comment relancer les mêmes questions ?
Laissez le parcours ordinaire d’exploration et d’indexation du site connecté traiter la modification approuvée. Consignez l’heure d’observation réelle au lieu de promettre un délai d’actualisation. Pour diagnostiquer l’accès du robot, consultez les détails d’exploration d’AISearchBot. Relancez ensuite la version identique de la requête et relevez les mêmes champs.
| Champ | Avant | Après |
|---|---|---|
| Source attendue visible | inconnu | inconnu |
| Citation étayant la réponse | inconnu | inconnu |
| Exhaustivité de la réponse | inconnu | inconnu |
| Version du contenu | inconnue | inconnue |
| Heure d’observation | inconnue | inconnue |
| État du résultat | inconnu | inconnu |
Comment interpréter les résultats positifs, nuls, négatifs ou mixtes ?
Consignez chaque résultat, y compris l’absence de changement et les régressions. Une bonne source peut apparaître sans citation valable ; une citation valable peut accompagner une réponse incomplète. La structure n’est qu’une variable : limitez le résultat au site, aux versions, au jeu de requêtes et aux heures observées.
Que faire si la bonne source est absente ?
Vérifiez qu’elle contient le fait attendu dans un texte visible et qu’elle était accessible à l’exploration normale. La cause peut relever de l’exhaustivité du contenu, de l’état d’exploration/indexation ou de la récupération. Ne diagnostiquez pas de paramètres fournisseurs cachés sans preuve.
Que faire si la source apparaît, mais que la citation ou la réponse est faible ?
Vérifiez si le passage cité étaye l’affirmation et si la réponse omet une condition ou une exception. Vous distinguez ainsi récupération, correction des citations et génération de réponse. Une modification de titre ne prouve pas que la génération s’améliorera.
Que faire en cas d’absence de changement, de régression ou de résultat mixte ?
Conservez-le. Un résultat nul peut indiquer que la structure initiale suffisait ou n’était pas la variable limitante. Une régression peut justifier un retour du diff. Un résultat mixte peut soutenir une révision plus étroite. Rapportez toujours l’observation sans sélectionner uniquement les requêtes favorables.
Que doit contenir la checklist de préparation RAG de l’éditeur ?
- Gardez claire l’intention RAG-et-titres de la page.
- Donnez à la page un H1 descriptif.
- Utilisez les H2 pour les grandes questions et les H3 pour une portée plus étroite.
- Placez une réponse directe près de chaque titre.
- Gardez ensemble un sujet, une décision ou une procédure cohérents.
- Nommez produits, rôles, régions, versions et exceptions lorsqu’ils s’appliquent.
- Ajoutez un texte visible aux faits essentiels uniquement présents dans les images.
- Séparez les modifications de l’éditeur de l’ingestion contrôlée par le fournisseur.
- Figez les requêtes et sources attendues avant la restructuration du contenu.
- Consignez séparément récupération, soutien par les citations et exhaustivité, y compris les résultats négatifs.
Quelles sont les limites et la prochaine étape ?
Les titres descriptifs et les sections autonomes sont des variables testables du contenu source, pas des garanties de récupération, citations, qualité des réponses, classement, vitesse, trafic ou conversion. Aucun résultat avant/après n’existe pour ce guide.
Pour exécuter le protocole sur un site public autorisé via le parcours normal du produit, connectez votre site. Pour des lectures connexes, parcourez les guides éditoriaux Achla sur la recherche IA.


