I've had really good luck recently running OCR over a corpus of images using gpt-4o. The most important thing I realized was that non-fancy data prep is still important, even with fancy LLMs. Cropping my images to just the text (excluding any borders) and increasing the contrast of the image helped enormously. (I wrote about this in 2015 and this post still holds up well with GPT: https://www.danvk.org/2015/01/07/finding-blocks-of-text-in-a...).
I also found that giving GPT at most a few paragraphs at a time worked better than giving it whole pages. Shorter text = less chance to hallucinate.
Have you tried doing a verification pass: so giving gpt-4o the output of the first pass, and the image, and asking if they can correct the text (or if they match, or...)?
Just curious whether repetition increases accuracy or of it hurt increases the opportunities for hallucinations?
The parameter is immutable so if you pass a pointer, the pointer is immutable, but the pointed value isn't..
If the pointer alias another 'immutable' parameter, this parameter may not be immutable anymore..
Thanks for the pointer, I hadn't run across ts-runtime-checks before. It does do something similar to what I propose in the post. The difference is that ts-runtime-checks is opt-in. If you want a type validated at runtime, you have to write `Assert<T>`. What I'm proposing is that _all_ types be validated at runtime.
opt-in makes sense if you want these checks in production. The appeal of a "check everything" debug mode is that you wouldn't have to modify your TS at all to use it.
Yes, the error is much clearer when you realize where the mistake is :)
There's an interesting point here, though: while comptime lets Zig unify function calls and generic type instantiation, this also creates the possibility of confusing the two and getting confusing error messages.
I also found that giving GPT at most a few paragraphs at a time worked better than giving it whole pages. Shorter text = less chance to hallucinate.
reply