Live data from Hacker News

Ingesting PDFs and why Gemini 2.0 changes everything

sergey.fyi

351–360 of 456 posts

Re: Ingesting PDFs and why Gemini 2.0 changes everything

#351
I’ve been very reluctant to use closed source LLMs. This might actually convince me to use one. I’ve done so many attempts at pdf parsing over the years. It’s awful to deal with. 2 column format omg. Most don’t realize that pdfs contain instructions for displaying the document and the content is buried in there. It’s just always been a problematic format.

So if it works, I’d be a fool not to use it.

Re: Ingesting PDFs and why Gemini 2.0 changes everything

#352

This is using exactly the wrong tools at every stage of the OCR pipeline, and the cost is astronomical as a result. You don't use multimodal models to extract a wall of text from an image. They hallucinate constantly the second you get past perfect 100% high-fidelity images. You use an object detection model trained on documents to find the bounding boxes of each document section as _images_; each bounding box comes…

I feel compelled to reply. You've made a bunch of assumptions, and presented your success (likely with a limited set of table formats) as the one true way to parse PDFs. There's no such thing.

In real world usage, many tables are badly misaligned. Headers are off. Lines are missing between rows. Some columns and rows are separated by colors. Cells are merged. Some are imported from Excel. There are dotted sub sections, tables inside cells etc. Claude (and now Gemini) can parse complex tables and convert that to meaningful data. Your solution will likely fail, because rules are fuzzy in the same way written language is fuzzy.

Recently someone posted this on HN, it's a good read: https://lukaspetersson.com/blog/2025/bitter-vertical/

> You don't use multimodal models to extract a wall of text from an image. They hallucinate constantly the second you get past perfect 100% high-fidelity images.

No, not like that, but often as nested Json or Xml. For financial documents, our accuracy was above 99%. There are many ways to do error checking to figure out which ones are likely to have errors.

> This is using exactly the wrong tools at every stage of the OCR pipeline, and the cost is astronomical as a result.

One should refrain making statements about cost without knowing how and where it'll be used. When processing millions of PDFs, it could be a problem. When processing 1000, one might prefer Gemini/other over spending engineering time. There are many apps where processing a single doc is say $10 in revenue. You don't care about OCR costs.

> I've build a system that read 500k pages _per day_ using the above completely locally on a machine that cost $20k.

The author presented techniques which worked for them. It may not work for you, because there's no one-size-fits-all for these kinds of problems.

Re: Ingesting PDFs and why Gemini 2.0 changes everything

#353
post #230

Earlier quoted context omitted.

You‘re describing yesterdays world. With the advancement of AI, there is no need for any of these many steps and stages of OCR anymore. There is no need for XML in your pipeline because Markdown is now equally suited for machine consumption by AI models.

Just commenting here so that I can find back to this comment later. You perfectly captured the AI hype in one small paragraph.

For future reference if you click on the timestamp of a comment that will bring you to a screen that has a “favorite” link. Click that to add the comment to your favorite comments list, which you can find on your profile page.

Re: Ingesting PDFs and why Gemini 2.0 changes everything

#354

Earlier quoted context omitted.

>Not sure what service you're basing your calculation on but with Gemmini The table of costs in the blog post. At 500,000 pages per day the hardware fixed cost overcomes the software variable cost at day 240 and from then on you're paying an extra ~$100 per day to keep it running in the cloud. The machine also had to use extremely beefy GPUs to fit all the models it needed to. Compute utilization was between 5 to 10%…

That assumes that you're able to find a model that can match Gemini's performance - I haven't come across anything that comes close (although hopefully that changes).

Nice article, mirrors my experience. Last year (around when multimodal 3.5 Sonnet launched), I had run a sizeable number of PDFs through it. Accuracy was remarkably high (99%-ish), whereas GPT was just unusable for this purpose.

Re: Ingesting PDFs and why Gemini 2.0 changes everything

#355

Earlier quoted context omitted.

If temperature is zero, and weights are weights, where is the non-deterministic behavior coming from?

Temperature changes the distribution that is sampled, not if a distribution is sampled. Temperature changes the softmax equation[1], not weather or not you are sampling from the softmax result or choosing the highest probability. IBM's documentation corroborates this, saying you need to set do_sample to True in order for the temperature to have any effect, e.g., T changes how we sample, not if we sample [2]. A simila…

Your response is correct. However, you can choose to not sample from the distribution. You can have a rule to always choose the token with the highest probability generated by the softmax layer.

This approach should make the LLM deterministic regardless of the temperature chosen.

P.S. Choosing lower and lower temperatures will make the LLM more deterministic but it will never be totally deterministic because there will always be some probability in other tokens. Also it is not possible to use temperature as exactly 0 due to exp(1/T) blowup. Like I mentioned above, you could avoid fiddling with temperature and just decide to always choose token with highest probability for full determinism.

There are probably other more subtle things that might make the LLM non-deterministic from run to run though. It could be due to some non-deterministism in the GPU/CPU hardware. Floating point is very sensitive to ordering.

TL;DR for as much determinism as possible just choose token with highest probability (i.e. dont sample the distribution).

Re: Ingesting PDFs and why Gemini 2.0 changes everything

#356

I work in fintech and we replaced an OCR vendor with Gemini at work for ingesting some PDFs. After trial and error with different models Gemini won because it was so darn easy to use and it worked with minimal effort. I think one shouldn't underestimate that multi-modal, large context window model in terms of ease-of-use. Ironically this vendor is the best known and most successful vendor for OCR'ing this specific ty…

> After trial and error with different models As a mere occasional customer I've been scanning 4 to 5 pages of the same document layout every week in gemini for half a year, and every single week the results were slightly different. To note the docs are bilingual so it could affect the results, but what stroke me is the lack of consistency, and even with the same model, running it two or three times in a row gives di…

That’s why you have azure openAI APIs which give a lot more consistency

Re: Ingesting PDFs and why Gemini 2.0 changes everything

#357
post #154

Earlier quoted context omitted.

Very cool! How are you storing it to a database - vectors? What do you do with the extracted data (in terms of being able to pull it up via some query system)?

In this use-case the customer just wanted data not currently in the warehouse inventory management system capatured, so here we converted a JSON response to a classic table row schema (where 1 row = 1 document) and now boom, shipping data! However we do very much recommend storing the raw model responses for audit and then at least as vector embeddings to orient the expectation that the data will need to be utilized…

> Kind of like "while we're here why don't we do what you're going to want to do at some point, even if it's not your use-case now..."

wow, this is so bad. why do it now and introduce complexity and debt if you can do it later when you actually need it? you are just riding the hype wave and trying to get most out of it but that's fine.

Re: Ingesting PDFs and why Gemini 2.0 changes everything

#358
post #93
post #83

Orthogonal to this post, but this just highlights the need for a more machine readable PDF alternative. I get the inertia of the whole world being on PDF. And perhaps we can just eat the cost and let LLMs suffer the burden going forwards. But why not use that LLM coding brain power to create a better overall format? I mean, do we really see printing things out onto paper something we need to worry about for the next…

PDF does support incorporating information about the logical document structure, aka Tagged PDF. It’s optional, but recommended for accessibility (e.g. PDF/UA). See chapters 14.7–14.8 in [1]. Processing PDF files as rendered images, as suggested elsewhere in this thread, can actually dramatically lose information present in the PDF. Alternatively, XML document formats and the like do exist. Indeed, HTML was supposed…

Fixed link: https://opensource.adobe.com/dc-acrobat-sdk-docs/pdfstandard...

Re: Ingesting PDFs and why Gemini 2.0 changes everything

#359

Earlier quoted context omitted.

> The problem then shifts from "can we extract this data from the PDF" to "how do we teach an LLM to extract the data we need, validate its performance, and deploy it with confidence into prod?" A smart vendor will shift into that space - they'll use that LLM themselves, and figure out some combination of finetunes, multiple LLMs, classical methods and human verification of random samples, that lets them not only "va…

Software is dead, if it isn't a prompt now, it will be a prompt in 6 months. Most of what we think software is today, will just be a UI. But UIs are also dead.

I wonder about these takes. Have you never worked in a complex system in a large org before?

OK, sure, we can parse a PDF reliably now, but now we need to act on that data. We need to store it, make sure it ends up with the right people who need to be notified that the data is available for their review. They then need to make decisions upon that data, possible requiring input from multiple stakeholders.

All that back and forth needs to be recorded and stored, along with the eventual decision and the all supporting documents and that whole bundle needs to be made available across multiple systems, which requires a bunch of ETLs and governance.

An LLM with a prompt doesn't replace all that.

Re: Ingesting PDFs and why Gemini 2.0 changes everything

#360

We are driving full speed into a xerox 2.0 moment and this time we are doing so knowingly. At least with xerox, the errors were out of place and easy to detect by a human. I wonder how many innocent people will lose their lives or be falsely incarcerated because of this. I wonder if we will adapt our systems and procedures to account for hallucinations and "85%" accuracy. And no, outlawing use the use of AI or increa…

Meh, just maintain an audit log and an escalation subsystem. No need to be luddites when the problems are process, not tech stack.
Post reply on HN