nhirschfeld

Hi HN!

I'm the maintainer of Kreuzberg, an open-source document intelligence library (https://github.com/kreuzberg-dev/kreuzberg). Some of you may have used it for RAG ingestion.

We're launching Kreuzberg Cloud, a SAAS API and a self-hosted system. It's in public beta, and I would like to invite you all to give it a try.

What out MVP offers: we offer very fast CPU optimized document and code intelligence. You can extract content from more than 90 document file formats and 300 code file formats into Markdown (or plaintext/djot), with additional features (same pricing tier) including chunking, embeddings, keyword extraction - and various types of intelligence.

The OSS library is used as the base engine of the cloud system. Our initial offering is $0.008/page, and you get the first 10K pages free, no card required.

We also offer our entire system for self-hosting - using helm charts. We are looking for design partners, so if thats relevant - shoot me a line.

You'll need to use a different OCR engine. Look at easy ocr

Yes, there have already been several suggestions here for other backend etc.

You should try using a different PSM to see if you get better results.

If it's scientific texts specifically, look at grobid

You still need to write it to file to process it via pandoc/tesseract etc.

There are alternative options to tesseract ofc.

thats why Kreuzberg also exposes a sync API for you to consume.

didnt know this!

I haven't, testing it out is on my todo list for sure

I google this for a while...

I'm actually considering another library with optional API called `Kreuzköln` - probably without the Umlaut!

Retrieval Augmented Generation. Its a class of techniques for generating content using LLMs. I'd recommend Googling this.

Thanks for asking!

It's both. The OCR part is ofc CPU bound, but the entire text extraction involves reading files, or writing and then reading files.

Without async, these simply block.

As for efficiency - if you're working in an async application context you have to "asyncify" these operations or suffer the consequences.

Amazing, would be interested in reading your experience

Sorry to hear...

Yup, easy OCR is good.

My reasons for using Tesseract - easy OCR is larger, and it has a significant cold start.

It benchmarks better for many OCR tasks though, so I'm thinking of adding it as an alternative backend.

interesting!

lol ;).

But seriously, in 13 years living here, only one guy tried to pick pocket me.

Thanks, I'll check these links.

In my tests I found tesseract quite good for regular text documents. For other kinds of texts it's not great.

As for using models - there are some good small language models as well, and of course LLMs.

I sorta feel though that if one needs complex OCR, or a vision model for layout, one should opt for either a commercial solution that abstracts the deployment and GPU management, or bake ones own system.

For most use cases involving text documents though, my subjective opinion is that tesseract is sufficient.

That's my neighborhood in Berlin, which I love

So, for PDF we need to distinguish between two types of text extraction-

1. Text extraction from a searchable PDF.

2. OCR.

For 1. Kreuzberg uses pypdfium2, which is a python binding for pdfium - the chromium PDF engine. In this regard Kreuzberg has top notch performance. Much faster than miner.six, PDFplumber etc.

Note PyMuPDF has top notch performance but also an AGPL license, and is almost unusable because of this without paying.

For 2. Kreuzberg uses Tesseract, which is very solid. Performance is good, and Kreuzberg utilizes async worker processes to optimize concurrency.

OCR though is a complex world. If what you need is to extract text from standard text documents (broadly speaking), Tesseract and hence Kreuzberg are a good choice.

If what you need is things like layout extraction, hand writing recognition, complete bonding box metadata etc. than you need to use an alternative - commercial one probably.

We're working very hard on shipping it

Seems that urls are not embedded in text fields, maybe the do in comments?

Repo: https://github.com/Goldziher/starlite

Docs: https://goldziher.github.io/starlite/

Article: https://itnext.io/introducing-starlite-3928adaa19ae