Surprisingly effective workflow for cleaning up messy OCR text with Claude

I finally cracked a bottleneck in my document processing pipeline that has been eating up my DevOps time for weeks. We ingest thousands of legacy insurance PDFs daily, and the OCR output is a nightmare of broken sentences, extra whitespace, and inconsistent date formats. Previously, I was using a complex regex chain in Python which was brittle and required constant maintenance whenever a new scanner driver introduced a quirk. I switched the cleaning phase to a simple API call to Claude 3.5 Sonnet with a very strict system prompt. The key was not asking it to 'clean the text' but to act as a 'data normalizer' with specific field mappings. I gave it three examples of bad input to fixed JSON output in the few-shot examples. The accuracy on our test set jumped from 82% to 96% overnight. The hallucination rate is essentially zero because the prompt explicitly instructs it to return null for missing fields rather than guessing. The cost is the main hesitation. At our volume, the API costs are non-trivial, but they are significantly lower than the engineering hours saved. I am currently running a cost-benefit analysis to see if batching requests or using a smaller local model like Llama 3 for simple whitespace fixes and only hitting Claude for the complex semantic corrections makes financial sense. Has anyone else implemented a hybrid approach like this? Specifically, are you seeing performance degradation if you try to route the initial tokenization through a lighter model before the main LLM pass, or does the latency overhead make it pointless? I’m open to hearing about alternative vector database approaches if there’s a way to dedupe the repetitive header/footer noise before the LLM even sees the data.