La plupart des tutoriels RAG s'arrêtent au niveau du notebook. Ils chargent quelques PDF bien présentés, découpent le texte tous les mille caractères, injectent les fragments dans une base de données vectorielle, et appellent cela une architecture. Un vendredi après-midi, cette démo fonctionne parfaitement. En production, ce même pipeline devient discrètement un fardeau.

Le véritable goulot d'étranglement d'un système de récupération est rarement le modèle ou le prompt. C'est l'ingestion. Un pipeline RAG ne peut récupérer que ce qu'on lui a fourni, et si le flux est bruité, obsolète ou incomplet, le modèle produira des absurdités avec assurance. Lorsque les utilisateurs se plaignent que le bot a halluciné, la faute incombe souvent, bien en amont, à un pipeline de données que personne ne surveille de près.

Le piège du tableau blanc

Les schémas d'architecture présentent l'ingestion comme une simple flèche étiquetée « Documents → Vector DB ». La réalité est bien plus complexe. Les systèmes sources changent sans préavis. Les mises en page HTML sont redessinées. Les URL redirigent vers des pages d'accueil génériques. Les frameworks JavaScript remplacent le contenu après la réponse HTTP initiale. Traiter l'ingestion comme une tâche de configuration unique est la première erreur. C'est un problème d'ingénierie des données continu qui mérite la même rigueur que n'importe quel pipeline ETL.

Pourquoi les échecs du RAG sont généralement des échecs de flux de données

Imaginez la situation suivante : un utilisateur interroge votre assistant interne sur la politique de remboursement actuelle. Le modèle extrait le premier fragment de la base vectorielle et indique un délai de 30 jours. En réalité, la politique est passée à 60 jours le trimestre dernier. L'LLM n'a pas inventé la mauvaise réponse. Il a fait confiance à une donnée erronée. La couche de récupération a servi une ancienne page et, comme l'embedding semblait sémantiquement assez proche, le modèle l'a traitée comme une vérité terrain.

Ce schéma se répète constamment. Les équipes passent des heures à ajuster la température et le top-k alors que leur corpus est rempli de pieds de page de navigation, de communiqués de presse en double et de fragments qui coupent des tableaux en deux. Avant d'optimiser la génération, auditez ce que votre système est autorisé à savoir.

Sept pièges qui détruisent l'ingestion

1. Le premier passage est un mensonge

Une coche verte lors de votre premier crawl ne signifie presque rien. Les données de production sont vivantes. Les pages de documentation sont refactorisées, les permaliens de blogs se brisent et les sitemaps suppriment discrètement des sections. Si vous vous contentez de valider que le pipeline s'est terminé sans erreur, vous naviguez à vue. Vous devez valider la sortie. Vérifiez que les documents attendus sont présents, que leur structure est toujours exploitable et que le volume total de texte ne s'est pas effondré parce qu'une source a décidé de paginer les résultats différemment.

2. Le crawling n'est pas l'ingestion

Récupérer le HTML est la partie facile. Un crawl brut capture tout : bannières de cookies, barres latérales d'« Articles connexes », blocs publicitaires et mentions de copyright en pied de page. Si vous découpez ce HTML brut de manière naïve, chaque fragment de texte entraînera avec lui des morceaux du menu de navigation. Lorsqu'un utilisateur pose une question sur les limites de débit de l'API, le récupérateur pourrait faire remonter un fragment composé à 40 % de liens de la barre latérale. L'extraction propre est cruciale. Vous devez identifier la zone de contenu principal, supprimer le boilerplate et retirer les éléments qui se répètent sur chaque page. Sinon, vous ne construisez pas une base de connaissances. Vous construisez un moteur de recherche pour l'interface du site.

3. Le découpage (chunking) brise le sens

Le découpage par taille fixe est la norme dans presque tous les guides de démarrage rapide, et c'est dangereux. Découpez un document uniquement par nombre de caractères et vous trancherez des tableaux en plein milieu, séparerez les étapes 4 et 5 d'une procédure numérotée et isolerez des listes à puces de leurs titres. Un fragment contenant uniquement la seconde moitié d'un tableau de prix est sémantiquement inutile. Un découpage intelligent respecte le format d'origine. Analysez la hiérarchie des titres. Gardez les tableaux intacts dans la mesure du possible. Découpez aux limites des paragraphes sous le même H2 ou H3. Préservez les listes à l'intérieur d'un seul fragment si elles sont assez courtes. L'objectif n'est pas d'obtenir des blocs de taille égale. L'objectif est d'obtenir des unités de sens cohérentes.

4. Le problème de la fraîcheur

A static snapshot of an internal wiki is simple mode. Continuously ingesting from the live web is hard. You need to know when a page was last gathered, whether it has changed since then, and how long the information remains valid. Stale data does not always mean a visibly old date. Sometimes a page updates its text but keeps the same URL, so your system never notices without content hashing. Build clear refresh rules based on source volatility. A financial data feed might need hourly checks. A company about page might need quarterly checks. Record timestamps and set time-to-live boundaries, especially if your domain involves regulated or safety-critical guidance where old facts can cause real harm.

5. Duplicate Pollution

Websites are full of repetition. The same product description appears on the category page, the product page, and a promotional landing page. The same press release lives under /news/, /press/, and /blog/. Vector search does not deduplicate automatically. If ten nearly identical chunks sit in your database, they can crowd out diverse, relevant results in your top-k retrieval. You need canonical tracking or content deduplication before embedding. If two chunks say the same thing, keep the authoritative source and drop the copies. Your retriever has limited slots. Do not let them go to waste.

6. Missing Metadata

A vector database without metadata is just a dense text search engine with no memory of context. Smart retrieval depends on filtering and ranking signals that raw embeddings cannot provide. Store the source URL, the capture date, the document category, and the version number. If you ingest API documentation, versioning is essential. Without it, a query might blend v1 and v2 specs into the same answer. If you ingest HR policies, tagging by region or department lets you filter results before they ever reach the model. Metadata turns a text dump into a curated knowledge system.

7. JavaScript Gaps

Modern sites do not ship their content in the first HTML payload. They send a skeleton and hydrate it with JavaScript calls. A basic HTTP request might see nothing but a loading spinner and a layout shell. If your pipeline cannot execute JavaScript, you will ingest blank pages or partial fragments and never realize anything is wrong. Using a headless browser solves the rendering problem but introduces new ones: heavier memory use, slower throughput, and bot detection walls. Choose your trade-offs deliberately, but do not pretend a simple curl equivalent is enough for every source.

A Practical Ingestion Checklist

If you are building or reviewing a RAG feed, start here:

  • Validate source coverage and pagination. A sitemap might list only the first ten articles in a category. Crawl deep and verify that paginated or dynamically loaded content is actually captured.
  • Remove boilerplate before chunking. Strip navigation, ads, footers, and repeated legal disclaimers. If a phrase appears on every page, it is noise.
  • Use structure-aware chunking. Respect headings, bullet lists, and tables. Split on semantic boundaries, not character counts.
  • Attach rich metadata. Include URL, capture date, content category, and version. Make these fields filterable in your retrieval queries.
  • Set refresh frequencies based on data volatility. High-change sources need frequent re-crawls. Static archives do not.
  • Monitor the corpus, not just the job status. A pipeline can exit with code zero while producing garbage. Audit samples of stored chunks regularly for drift and quality.
  • Define rules for versioning and deletions. When a source page is removed, delete its chunks. When it updates, overwrite or version them. Orphaned data is a silent killer.

The Hard Truth About Embeddings

No embedding model, no matter how advanced, can repair a missing document. It cannot guess that a page was updated last week if your feed still holds last year's copy. It cannot infer the context of a table row that got separated from its header by a bad chunk boundary. Embeddings compress meaning, but they do not create meaning where the ingestion layer failed to preserve it.

Retrieval quality starts at the ingestion layer. That layer decides whether your RAG system is a useful tool or just a confident liar with a vector database behind it.

The Real Takeaway

Ne vous contentez pas de mesurer la santé de l'ingestion avec les seuls tableaux de bord de vos pipelines. Des jobs réussis et des logs impeccables ne garantissent pas un corpus de qualité. Ouvrez la base de données et lisez les segments réels que vos utilisateurs vont récupérer. Si le texte est truffé d'avis de droit d'auteur, de tableaux fragmentés et de pages de politiques obsolètes, votre problème ne vient pas de l'LLM. Corrigez d'abord le flux de données. Tout le reste n'est que de l'optimisation appliquée à des déchets.