# Why does parsing scientific papers for RAG still break on equations and tables? > Source: > Published: 2026-07-29 16:47:14+00:00 If you've tried building RAG over scientific papers, you've probably hit this: the PDF looks fine, the text extracts fine, and then a table with merged cells turns into three columns of garbage, or an equation comes out as ?123? where the integral sign should be, the figures and diagrams were taken as images when I needed them in LaTex notation and stuff like that This post is about what I found trying to fix it, happy to hear if others have run into the same wall. **Why is scientific PDF parsing harder than other documents?** Most document parsing tools are tuned for business documents: invoices, contracts, forms. Papers are a different beast: **What happens when a VLM-based parser gets it wrong?** I ran a batch of papers through a few different extraction pipelines MinerU, Docling, Maker and accuracy was generally good but the failure mode is the part that worries me more than the failure rate. It doesn't fail loudly. It doesn't throw an error. It just quietly gets a number wrong in a table, or restructures an equation in a way that looks plausible but isn't what's in the source. If you're feeding this into a RAG pipeline that a user queries later, that's a hallucinated fact with no warning label on it. **So what did I try?** I ended up building a small verification pass instead of trusting the first extraction: Extract as usual (layout analysis → equations → tables) Cross-check the extracted content against the source page, not regenerating, just verifying: does this table match what's actually in the image? Flag anything below a confidence threshold instead of silently passing it through On a sample of 500 papers with 120 formulas on them, this caught 80 cases where the first-pass extraction had a mismatch between what the model output and what the source page actually showed. Some specifics from that run: MinerU had the strongest raw extraction, around 80% success on formula extraction. Docling handled simple equations fine but struggled a lot with rarer notation. And even with the best-performing pipeline, a verification layer was still necessary — the kind of error that slips through isn't a wildly wrong answer, it's the small stuff: a 2 extracted where the source actually had \mathbb{2}, which looks identical unless you're specifically checking for it. **Is this solved already?** Not really, as far as I can tell. Most parsers report an overall accuracy number but don't expose which parts of a specific document to trust and which to double check. That's the gap I think matters most for anyone building on top of scientific literature with an LLM in the loop, the average is not what breaks your pipeline, the untagged outlier is. From what I've seen: Datalab's offering comes with an enterprise sales cycle that's a lot to take on as a solo developer just trying to ship. LlamaParse does a solid job on general extraction, but confidence/ verification at the section level — knowing exactly what to double-check — isn't really the part it's built around. **Where I landed** None of this means the tools are bad — MinerU in particular is genuinely strong at raw extraction, and I'd rather build on top of that than reinvent it. But "mostly accurate" isn't the same thing as "safe to feed into a pipeline unsupervised," especially when the failure mode is quiet instead of loud. A wrong number that looks right is worse than an error message, because nothing downstream knows to question it. That's the part I ended up caring about more than raw accuracy: not just "how often is this right," but "when it's wrong, do I find out before my users do." If you're working on something similar — RAG over papers, research agents, anything ingesting scientific PDFs at any real volume — I'd genuinely like to compare notes on where your pipeline breaks. The failure cases are the useful part; the happy path is rarely where the interesting problems are. *Side note: I ended up turning this into a small tool since I needed it for my own work anyway — sciparse.com . Still early, mostly interested in hearing where it breaks on other people's papers.*