Implement document classification for extraction method routing — lab audio overview

Host: Welcome back to GenAI Data Pipelines. Today we're zooming in on a very specific lab from our Document Ingestion with VLMs chapter — lab one of three in the "Build a routing system selecting the optimal extraction method" objective. The lab is titled "Implement document classification for extraction method routing." Expert, set the stage for us. Expert: Happy to. This is the foundational lab of the three-lab routing sequence, and it's intentionally the first one because you can't route a document intelligently until you can describe it. In this lab, the student builds a document classifier that inspects PDF files and produces what we're calling a DocumentProfile. That profile captures three signals: whether the PDF has a real text layer, how complex the layout is, and whether any pages are actually scanned images masquerading as PDFs. Host: And that DocumentProfile is what lab two and lab three will consume, right? Expert: Exactly. Lab two layers cost-aware routing on top — weighing quality against API spend per document — and lab three adds fallback chains when the primary extractor fails. But none of that works if the profile is wrong. Garbage in, garbage out. So this lab is all about the inspection step: opening the PDF, probing its structure, and emitting a structured verdict that downstream code can trust. Host: Let's get concrete. What is the student actually building? Expert: The core deliverable is a DocumentClassifier class with a classify method that takes a PDF path and returns a DocumentProfile dataclass. Inside, they'll use a library like pypdf or pdfplumber to walk the pages. For each page, they check for extractable text — if the text layer is empty or nearly empty, that's a strong signal the page is scanned. They'll also look at bounding boxes to estimate layout complexity. A simple heuristic: count distinct text blocks, detect multi-column layouts, flag tables by looking at aligned whitespace patterns. Then they aggregate per-page findings into a document-level profile with fields like has_text_layer, is_scanned, layout_complexity as an enum of simple, moderate, or complex, and page_count. Host: What are the key patterns the student should focus on? Expert: Three things. First, the strategy pattern is lurking here — the DocumentProfile is effectively the input to a strategy selector downstream, so the fields need to be meaningful discriminators, not arbitrary metadata. Second, defensive parsing. PDFs are notoriously malformed in the wild, so their classifier needs to handle encrypted PDFs, corrupted xref tables, and zero-byte files without crashing the pipeline. Third, performance awareness — they should sample pages rather than exhaustively parse a 500-page document just to classify it. A common pattern is inspecting the first five pages, the last two, and a random middle sample. Host: Let's talk production relevance. Who actually builds this in the real world? Expert: This is daily work for data engineers and ML engineers at any company ingesting mixed-format documents at scale — think legal tech firms processing contracts, insurance companies handling claims, healthcare startups parsing medical records, or financial services firms ingesting filings. Picture a team at a mid-sized legaltech company processing fifty thousand documents a night. Some are clean digital PDFs from modern court systems. Others are scans of faxes of photocopies from 1987. You cannot route all of those to the same extractor. Host: What happens in production if this classifier doesn't exist or is wrong? Expert: Two failure modes, both ugly. First, if you route everything through a vision language model because "VLMs can handle anything" — your API bill explodes. You're paying premium per-page costs to extract text from documents that had a perfectly usable text layer all along. I've seen teams burn through twenty thousand dollars in a weekend this way. The data engineer on call gets paged when finance flags the spend anomaly. Second, if you route everything through a cheap text extractor, scanned documents come out as empty strings or garbled OCR artifacts. Downstream retrieval systems silently return nothing for those documents, and the issue only surfaces weeks later when a user complains that a specific contract is missing from search results. That's a much worse failure because the blast radius is "quiet data loss" — the hardest kind to detect. Host: So the classifier is the gatekeeper that prevents both overspending and silent corruption. Expert: Precisely. And the SRE or platform engineer maintaining the ingestion pipeline uses the DocumentProfile output in dashboards and alerting — they'll track the distribution of classifications over time and alert when, say, the scanned-document ratio suddenly jumps, which usually means a new upstream source started feeding in bad data. Host: What trade-offs will the student wrestle with in this specific lab? Expert: The big one is precision versus inspection cost. You can classify a PDF very accurately by running full OCR on every page and comparing against the text layer — but that defeats the purpose because classification should be cheap and extraction should be expensive. So the student has to decide: how many pages do I sample? What threshold of extractable characters counts as "has a text layer" — is it fifty characters per page, or five hundred? How do I handle hybrid documents where page one is digital but page forty is a scanned appendix? There's no single right answer, and the lab invites them to defend their choices. Host: Any other design decision worth flagging? Expert: Yes — how strict to make the layout_complexity signal. If you classify everything as "complex" you'll over-route to expensive VLMs. If you classify everything as "simple" you'll under-serve tables and multi-column academic papers. The student should test their classifier against a small corpus with known ground truth and tune the thresholds. That tuning mindset is what separates a toy classifier from something you'd actually deploy. Host: Great framing. Any final advice for students starting this lab? Expert: Don't skip the edge cases. Encrypted PDFs, password-protected files, PDFs that are really just one giant embedded image — these are the ten percent of inputs that cause ninety percent of production incidents. Write tests for them first. And remember: the DocumentProfile you design here becomes the contract that labs two and three depend on. Design it like an API, because that's what it is. Host: Perfect place to end. Good luck with lab one — we'll see you in lab two for cost-aware routing.