I’ve seen plenty of projects fail because someone decided to use a sledgehammer to crack a nut. Last week, a colleague mentioned a manual nightmare: a team of engineers spent weeks opening 4,700 engineering drawings to extract revision numbers. When you’re building a Document Extraction System, the instinct is often to throw the latest LLM at it and hope for the best. However, as I’ve learned over 14 years in the trenches, pure AI is rarely the most efficient answer for production-scale tasks.
The problem was simple on paper but messy in practice. These PDFs weren’t just text; they were a mix of modern CAD exports and 1990s-era raster scans. Manual extraction would have taken 160 person-hours—roughly £8,000 in labor. We needed a system that was faster, cheaper, and accurate enough to trust. Specifically, we needed a hybrid architecture.
The Bottleneck: Why Pure AI Fails
If you send every document to GPT-4 Vision, you’re looking at a massive API bill and significant latency. At roughly $0.01 per image, processing 4,700 files costs nearly $50 and takes over 100 minutes of inference time. More importantly, you’re paying for “reasoning” on documents that could be solved with a few lines of deterministic code.
In a professional Document Extraction System, the goal is to minimize expensive calls. If a PDF has a text layer, why involve a model? We built a two-stage pipeline: Stage 1 handles deterministic extraction using PyMuPDF, and Stage 2 handles the “unreadable” legacy scans using GPT-4 Vision. furthermore, this approach allowed us to process the entire batch in 45 minutes for less than $15.
Stage 1: Deterministic Extraction
For most files, we can target the title block directly. Engineering drawings almost always have the revision number in the bottom-right quadrant. By filtering spatially, we eliminate false positives from the revision history table or grid references along the borders. For more on optimizing these types of workflows, check out my guide on 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 for Your Document Extraction System
When PyMuPDF returns nothing (usually because the PDF is a flat image), we fall back to GPT-4 Vision. To keep costs down, we convert the page to a 150 DPI PNG. Consequently, we avoid sending high-resolution blobs that bloat the payload without improving accuracy. We used the Azure OpenAI Service for its enterprise-grade stability and low latency.
The “gotcha” here is rotation. Engineering drawings are notorious for being stored in landscape but encoded as portrait. If your Document Extraction System doesn’t handle rotation metadata correctly, the LLM will struggle to read the text. We implemented a heuristic: if we can’t find more than ten text blocks in the native extraction, we assume the orientation is suspect and apply a correction before sending it to the API.
Integrating with WordPress for UI
While the heavy lifting happens in Python, the end-users needed a way to upload files and view results without touching a terminal. We wrapped the pipeline in a lightweight internal tool and used the WordPress REST API to store the results as custom post types. This is a common pattern when you need a robust UI for complex backend tasks. If you’re planning a similar data move, take a look at my WordPress migration checklist to avoid common pitfalls.
<?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' );
}
Look, if this Document Extraction System stuff is eating up your dev hours, let me handle it. I’ve been wrestling with WordPress since the 4.x days.
Final Takeaway
The “right” accuracy target isn’t always the highest one possible. We hit 96% accuracy with this hybrid Document Extraction System. While we could have hit 98% by running GPT-4 on every file, the trade-off in cost and time wasn’t worth it for this specific migration. In production engineering, the best solution is the one that balances performance, cost, and maintainability. Don’t let the hype of “all-AI” solutions blind you to the power of a well-placed regular expression or a library like PyMuPDF.
