We replaced part of our document extraction pipeline and learned that OCR was not the only problem.

We work on summary-level extraction for clinical research PDFs. The goal sounds simple: extract structured data and show exactly where each value came from in the original document.

But clinical PDFs are messy.

A value may be inside a table, linked to a footnote, split across lines, or surrounded by layout cues that are hard to preserve once the document is converted into plain text.

Our earlier setup used a LangChain + OCR-based pipeline. It worked, but we kept running into a few painful issues:

Table values were extracted, but the source highlight was missing
Symbols and spacing were sometimes distorted during OCR
Multi-column layouts affected reading order
Correct extracted values still needed manual re-validation because traceability was unreliable

So we tested a different approach: sending the PDF directly to Anthropic’s native LLM API and reducing the OCR-heavy preprocessing layer.

The result was not “AI magic.” There were trade-offs.

What improved:

Better traceability back to the source PDF
Fewer OCR-related extraction issues
Lower latency in our benchmark
Simpler architecture with fewer moving parts

What became harder:

Higher token usage
Higher per-document cost
More care needed around chunking and prompt design

The biggest takeaway for us was this:

For document intelligence products, extraction accuracy is only part of the problem. The bigger product question is whether users can verify and trust the result quickly.

We wrote a longer breakdown of the architecture change, benchmark results, and lessons learned here: https://capestart.com/resources/blog/langchain-to-anthropics-native/

Curious how others are handling this. If you are building with PDFs, are you still relying on OCR pipelines, or have you started moving toward direct PDF inference?