Is RAG right for a messy implant catalog?
Stock sizes in tables. Preference notes and FAQs in chunks. Do not put inventory and prose in one pipe. Then pick a parser that keeps structure honest — we standardise on Xberg.
I need to manage a large implant catalog for an Agentic Webapp.
Messy PDFs. Preference notes. Tables that refuse to line up. FAQ copy sitting next to stock lists. RAG is already on my shortlist.
The question I am answering: is RAG the right solution here?
The paths I ruled out
I tested the other paths in my head:
- Pure database for everything falls apart when half the corpus is prose.
- Dumping the whole pile into one context window gets noisy once the catalog gets big.
- Naive RAG over raw files is worse. You retrieve garbage because the extract was garbage.
So I am saying yes to RAG, with a fence.
The fence
Stocked implant sizes go into a table. Preference notes and FAQs get cut into chunks for retrieval. Inventory and prose do not share one pipe.
Then: which tool gets the files into that shape?
Why Xberg for the parse step
I am standardising on Xberg for the parse step. Xberg is a self-hostable document intelligence and RAG platform.
It covers 98+ formats in one pass: PDF, Office, scans, tables. OCR when there is no text layer. Structure out, not a mush of words. Chunking that keeps headings so retrieval still knows where it is. Library, CLI, or API on the same core, so I am not locked to one runtime.
That is the call I am making.
What is actually hard
Most of the work so far is deciding whether RAG belongs, then which parser makes the retrieval honest. Chatbot UI is not the hard part.
Design I am wiring: the app reads stocked sizes from rows. It pulls preference and FAQ answers from retrieved chunks. Chat only starts after the documents parse cleanly.