Plenty of projects fail because someone reached for a sledgehammer to crack a nut. Last week a colleague described exactly that: a team of engineers had spent weeks opening 4,700 engineering drawings to read off revision numbers. The instinct when you need a Document Extraction System is to point the newest LLM at the pile and hope. Fourteen years in, I can tell you pure AI is rarely the most efficient answer at production scale.
On paper the problem was simple. In practice the PDFs were a mess: some were modern CAD exports, others were raster scans from the 1990s. Doing it by hand meant 160 person-hours, roughly £8,000 in labor. We needed something faster and cheaper that we could still trust, which pointed at a hybrid architecture.
Why pure AI is the wrong default
Send every document to GPT-4 Vision and you get a large API bill and a long wait. At roughly $0.01 per image, 4,700 files come to nearly $50 and over 100 minutes of inference time. You are also paying a model to reason about documents that a few lines of deterministic code would settle.
The whole point of a Document Extraction System is to make as few expensive calls as possible. If a PDF already has a text layer, there is no reason to involve a model at all. So the pipeline runs in two stages: PyMuPDF does the deterministic extraction, and GPT-4 Vision only sees the legacy scans that come back unreadable. That got the full batch done in 45 minutes for under $15.
Stage 1: deterministic extraction
For most files you can aim straight at the title block. On engineering drawings the revision number is almost always in the bottom-right quadrant. Filtering by position kills the false positives that come from the revision history table and the grid references along the borders. If you want more on tightening up workflows like this, I wrote about building a Python development workflow.
def bbioon_extract_native(pdf_path):
import fitz # PyMuPDF
doc = fitz.open(pdf_path)
page = doc[0]
# Define the title block area (bottom right)
rect = fitz.Rect(page.rect.width * 0.7, page.rect.height * 0.7, page.rect.width, page.rect.height)
text = page.get_text("blocks", clip=rect)
# Simple pattern matching for "REV"
for b in text:
if "REV" in b[4]:
return b[4].split(":")[-1].strip()
return NoneStage 2: the AI fallback
When PyMuPDF comes back with nothing, usually because the PDF is a flat image, we fall back to GPT-4 Vision. The page gets rendered to a 150 DPI PNG first. That keeps the payload small, and the higher-resolution version did not read any better. We ran it through the Azure OpenAI Service, mostly for the stability and the low latency.
Rotation is the thing that catches people out. Engineering drawings are notoriously stored in landscape but encoded as portrait, and if your Document Extraction System mishandles the rotation metadata the model struggles to read the text at all. Our heuristic: fewer than ten text blocks in the native pass means the orientation is suspect, so we correct it before the file goes to the API.
Wiring it into WordPress
The heavy lifting happens in Python, but the people using it needed to upload files and read results without opening a terminal. So we wrapped the pipeline in a small internal tool and pushed the results into custom post types through the WordPress REST API. That pattern shows up any time a messy backend job needs a usable front end. If you are planning a similar data move, my WordPress migration checklist covers the parts that usually go wrong.
<?php
/**
* Ingest extracted data into WordPress
*/
function bbioon_update_drawing_revision( $drawing_id, $rev_value ) {
if ( empty( $rev_value ) ) {
return;
}
update_post_meta( $drawing_id, '_current_rev', sanitize_text_field( $rev_value ) );
// Log the engine used for audit trails
update_post_meta( $drawing_id, '_extraction_engine', 'hybrid_pipeline_v1' );
}
If this Document Extraction System stuff is eating your dev hours, hand it to me. I have been wrestling with WordPress since the 4.x days.
What I would do again
The right accuracy target is not always the highest one available. This hybrid Document Extraction System landed at 96%. Running GPT-4 on every file would have got us to 98%, but for a one-off migration the extra cost and time were not worth two points. Cost and maintainability count as much as raw performance here. A well-placed regular expression or a library like PyMuPDF will beat an all-AI pipeline more often than the hype suggests.
