Skip to content
VDAI with VD

Self-Built Project

Document Extraction Pipeline: Scaling AI Workloads with FastAPI and Celery

An async-first extraction service: FastAPI accepts uploads, Celery workers run OCR and LLM extraction, and typed schemas turn invoices, legal documents and ESG reports into JSON.

Document processing, back-office automationDemonstratedAI-Assisted Custom Software DevelopmentMLOpsDocument Intelligence

Demonstrated capabilities

These are implemented capabilities and supported schemas; no comparative speed or accuracy benchmark is claimed.

Async

Queued worker processing keeps uploads responsive

Typed JSON

Schema-validated output for supported templates

3 schemas

Invoice, legal and ESG, plus custom templates

Local or cloud

Ollama or OpenAI with zero code changes

At a Glance

FieldDetail
Work typeSelf-built product
SectorDocument automation: invoices, legal documents, ESG reports
EngagementDesign and build a production-grade extraction service
PlatformFastAPI, Celery, Redis, PostgreSQL, MinIO, MinerU OCR, OpenAI / Ollama
FocusAsync-first architecture that keeps the API fast while AI does slow work
OutcomeAsync processing, typed extraction, and local or cloud model support implemented; no comparative benchmark claimed

The Product

Businesses drown in documents that carry structured data trapped in unstructured formats: invoices, contracts, ESG reports. Manual data entry is slow, error-prone, and expensive, and most extraction tools fail the moment a layout changes.

This pipeline turns PDFs and images into clean, structured JSON. Upload a document, get back typed fields matching a schema. OCR handles the reading, an LLM handles the understanding, and the architecture handles the part most AI demos skip: doing this reliably, concurrently, and securely in production.

The engagement centered on four objectives:

  • Extract structured data from PDFs and images across multiple document types.
  • Keep the API responsive while OCR and LLM inference run for seconds or minutes per document.
  • Support both cloud LLMs and fully local inference for cost and privacy flexibility.
  • Ship production concerns complete: authentication, rate limiting, storage, and job tracking.

The Challenge

The core tension of this project was heavy AI inference inside a responsive API. OCR and LLM extraction take seconds to minutes per document, and an API that blocks on them collapses under its second concurrent user.

  1. Slow work behind a fast interface. A single document can take longer to process than any sane HTTP timeout. The architecture had to accept work instantly and deliver results asynchronously, without losing jobs in between.

  2. Layout chaos. Invoices, legal documents, and ESG reports share nothing structurally. Tables, multi-column layouts, scanned images, and mixed quality inputs all had to resolve into the same clean schemas.

  3. The cost and privacy fork. Some workloads justify a cloud LLM; others demand data never leaves the machine. One codebase had to serve both without branching into two products.

  4. Production is a feature. Authentication, per-user rate limiting, object storage, retry behavior, and job status tracking are where prototypes go to die. They were in scope from the first commit.

My Approach

I built the system async-first, with a clean separation between the API that accepts work and the workers that do it.

FastAPI at the front, Celery at the back. The API validates uploads, persists files to MinIO object storage, enqueues a Celery job through Redis, and returns a job ID immediately. Clients poll for results while workers process in the background. Throughput scales by adding workers, not by making users wait.

A two-stage extraction pipeline. MinerU, running its vlm-auto-engine, converts documents into structured Markdown that preserves tables and layout, the context an LLM needs to extract fields correctly. The LLM stage then maps that Markdown into typed schemas, with pre-built templates for Invoice, Legal, and ESG document types and support for custom extraction templates.

Provider-agnostic LLM layer. The extraction stage runs against OpenAI GPT-4o-mini for managed inference or a local Ollama model for fully private, zero-API-cost processing. Switching is configuration, not code.

Production hardening throughout. JWT authentication with per-user rate limiting, PostgreSQL with JSONB for flexible result storage, Redis doubling as broker and cache, MinIO for S3-compatible storage, and the whole stack containerized with Docker for reproducible deployment.

Engineering Highlights

  • Async job architecture. Upload returns a job ID in milliseconds; Celery workers absorb the heavy lifting, and the API never blocks on inference.
  • MinerU OCR front end. Layout-aware conversion to structured Markdown, preserving tables that naive OCR flattens into noise.
  • Schema-driven LLM extraction. Pre-built Invoice, Legal, and ESG schemas with customizable templates, returning typed JSON instead of free text.
  • Cloud or local inference. OpenAI and Ollama behind one interface, letting cost and privacy requirements pick the backend per deployment.
  • JSONB result storage. PostgreSQL stores heterogeneous extraction results queryably without schema migrations per document type.
  • JWT auth and rate limiting. Per-user access control and request budgets built in, not bolted on.
  • S3-compatible object storage. MinIO handles originals and artifacts, keeping the database lean and the files durable.
  • Fully containerized. Docker Compose brings up the entire stack, API, workers, Redis, Postgres, and MinIO, in one command.

Implemented Capabilities

CapabilityImplemented behavior
API behaviorUpload returns a job ID while workers process the document asynchronously
Output contractSupported templates return schema-validated structured JSON
Document types3 pre-built schemas (Invoice, Legal, ESG) plus custom templates
DeploymentCloud LLM or fully local via Ollama, zero code changes

Tech Stack and Deliverables

  • Platform: FastAPI, Celery, Redis, PostgreSQL (JSONB), MinIO, Docker
  • AI layer: MinerU (vlm-auto-engine) OCR, OpenAI GPT-4o-mini, Ollama for local inference
  • Deliverables: Async extraction API, worker pipeline, three document schemas with template system, JWT auth and rate limiting, containerized deployment

Work

Related project

Document Extraction Pipeline

Turn Documents into Structured Data with AI

Self-Built ProjectDemonstrated

A production-ready FastAPI service that extracts structured data from PDFs and images using OCR and LLM technology. Features async processing, JWT authentication, and support for multiple document types including invoices, legal documents, and ESG reports.

FastAPICeleryPostgreSQL

More

More case studies

Independent Product R&D

TargetTarget Reference Architecture

Designing Secure Agent Transaction Infrastructure

A protocol-neutral reference design for giving AI agents bounded authority, exact approvals, isolated credentials, safe outcome handling and auditable transaction evidence.

Design outputs

The counts below describe elements in this target reference design and its public documentation; they are not observed production results or performance measurements.

7 controls

Risks, enforcement points and validation methods mapped

4 identities

Human, agent, workload and downstream credential kept distinct

Read case study

hypREspace

Measured

hypREspace: Cutting Token Costs 90% While Raising Tool-Calling Accuracy to 95%

Dynamic prompt injection, a gold evaluation set and Amazon Nova fine-tuning cut a live agent's token spend by 90% and lifted tool-calling accuracy from 75.8% to 95%.

Measured outcomes

Measured with before-and-after per-query token counts and tool-call accuracy scored against the gold evaluation set.

90%

Token cost reduction, measured per query

75.8% to 95%

Tool-calling accuracy on the gold eval set

Read case study

hypREspace

Production

hypREspace: Rearchitecting NL-to-SQL into an Agentic Analytics Engine

A brittle multi-hop prompt chain became one observable LangGraph ReAct agent with a custom MCP layer over the existing FastAPI backend and Claude on Bedrock.

Production outcomes

Production status reflects the deployed client workflow and its live traceability; no comparative performance figure is claimed.

One agent

Replaced a multi-hop prompt chain end to end

Every step traced

Failures diagnosed from the exact step trace

Read case study

Have a problem that looks like this?

Tell me about it. I reply within one working day with a first take and no sales pitch.