I use that aswell since it can be used and expose a posix filesystem. This is helpful when we want to add s3 to existing storage like a nas. (Well we had some problems with it in the past tough)
Sadly most new projects do not offer posix anymore.
Generate multiple solutions- they do not to work 100% correctly.
And than I check which I would prefer. Which is more to our applications taste.
And than I would take the vibe output as a kind of a ‚plan‘ which I use to implement but not follow 100% and at the end I take my solution and review it.
I gain speed with that because I often can quickly see the pros and cons of a solution way better than when I would manually do it and hang on a major roadblock and also I even see such roadblocks in the vibe output - it’s mostly the part with an unnecessary amount of new code that looks nonsensical.
The challenge is not the functionality, it’s doing it cheaply at scale. Google Cloud storage has raised prices a few times, and added various quotas and limits when they realized they couldn’t sustain the service as is.
Which gui? I’m on Mac and somehow I could never really be happy with gui‘s for git. Gitkraken is the last I tried and I found it too much cluttering. Paid choices weren’t that great aswell either (yet)
So normally if you overcommit it might be undefined behavior if you not have enough memory. However if everything is fine pods can preempt based on prio to new nodes.
With the right settings only the faulty app might fail. Without it it can be a real pain to find the rouges
Tbf even with tesseract you already get shit ton of accuracy and you can probably do these 1000 pages for way less than 3.5€. For 3.5€ you can spin up a cloud instance with 8vCPU+32gb on gcloud for 11 hours (or 11 instances for an hour) which can do way more than 1000 pages per hour on tesseract. It takes you around 6 second per page +-4 seconds start/stop depending on what you are doing on that instance size without too much optimization (you can probably even run multiple processes on a single node)
Google documentai costs 1.5$ per 1000 which is probably better in quality and speed.
Tesseract is not a substitute for these models, which understand complex layouts and also extract bounding boxes for things like tables and pictures. They are also much better at making sense of cursive scripts.
I’ve been there, implementing a way to linearise text from a document with pages with 1, 2 or 3 columns, some of them in landscape is a nightmare. And that’s not even considering equations.
In the end it’s way easier to use a specialised model, trained by other people to do exactly what I need.
What was not so fun was to make it work reliably. I ended up with piles of ugly code to handle edge cases, and issues kept piling up. So in the end I was happy to use someone else’s solution.
It‘s also cheaper than the murican ones from Google, Amazon, …. And tesseract was an example. Heck you can go xberg and use paddleocr. Most often layout is less of a problem for ocr. Most often you need high accuracy, which tools like these are often worse in the 95 percentile.
Anecdotal as I haven't had time for a full benchmark, but I have a dense tabular handwritten form that is pretty challenging: LLMs with vision don't do well because the content isn't English words. Textract did poorly because it was just too dense for their model (although I haven't tried recently) Whereas I tried this model and it was a champ: Reasonable Markdown format with accurate content.
faced something similar with Azure, try upscaling the page (2x or more) before sending to the OCR, it increased the accuracy a lot for tiny tables on landscape pages.
reply