Le RAG est-il le bon choix pour un catalogue d'implants?

Je dois gérer un gros catalogue d'implants pour une webapp agentique.

PDF salissants. Notes de préférence. Tableaux qui refusent de s'aligner. FAQ à côté des listes de stock. Le RAG est déjà sur ma shortlist.

La question à laquelle je réponds : le RAG est-il la bonne solution ici ?

Les chemins que j'ai écartés

J'ai testé les autres options dans ma tête :

• Une base pure pour tout s'écroule quand la moitié du corpus est de la prose.
• Tout coller dans une seule fenêtre de contexte devient bruyant dès que le catalogue grossit.
• Du RAG naïf sur des fichiers bruts, c'est pire. Vous récupérez des déchets parce que l'extraction était des déchets.

Donc je dis oui au RAG, avec une clôture.

La clôture

Les tailles d'implants en stock vont dans une table. Les notes de préférence et les FAQ sont découpées en chunks pour la retrieval. Inventaire et prose ne partagent pas le même tuyau.

Ensuite : quel outil met les fichiers dans cette forme ?

Pourquoi Xberg pour le parse

Je standardise sur Xberg pour l'étape de parse. Xberg est une plateforme self-hostable de document intelligence et de RAG.

Elle couvre 98+ formats en une passe : PDF, Office, scans, tableaux. OCR quand il n'y a pas de couche texte. De la structure en sortie, pas une bouillie de mots. Un chunking qui garde les titres pour que la retrieval sache encore où elle est. Library, CLI ou API sur le même cœur, donc je ne suis pas enfermé dans un runtime.

C'est le choix que je fais.

Ce qui est vraiment dur

Le gros du travail jusqu'ici, c'est de décider si le RAG a sa place, puis quel parseur rend la retrieval honnête. L'UI chatbot n'est pas le vrai sujet.

Design que je branche : l'app lit les tailles en stock depuis des lignes. Elle tire les réponses de préférence et de FAQ depuis des chunks. Le chat ne démarre qu'après un parse propre des documents.