Skip to content
All case studies
GenAIIn build2025

Document Intelligence & Natural-Language Search

Operations teams in logistics and trade run on documents — purchase orders, delivery notes, certificates, invoices, contracts — and spend a meaningful part of every day retyping fields out of them or hunting for the one clause that matters. This is the layer that stops both.

Client
Logistics & Trade Operations
Region
India / UAE
Discipline
GenAI Solutions
docs.internal / extract
Source · page 2
VIN
Low conf.
Extracted fields
Document type98%
Export Certificate
Chassis / VIN94%
JTMH****9K51****
Consignee91%
Redacted Trading FZE
Demurrage rate62%
USD 45 / day
Grounded answer
What demurrage rate was agreed with this counterparty?
USD 45 per day after 7 free days.
export-cert-0418.pdf · p2Flagged for review

Interface recreated from the delivered system. Client data is illustrative and non-identifying.

The problem

The paperwork arrives as scans, PDFs and photos taken on a phone. The information inside it is needed in a database. The gap between those two facts is filled by a person retyping, and that person is both slow and occasionally wrong.

The second half of the problem is retrieval. Once documents are filed, answering "what was the agreed demurrage rate with this counterparty?" means someone opening files until they find it — knowledge that exists but is not reachable.

  • Field-level data entry from scanned documents is manual, repetitive and error-prone.
  • Document quality varies wildly — clean digital PDFs and skewed phone photos land in the same inbox.
  • Filed documents are searchable by filename at best, not by what they say.
  • A naive LLM over this data hallucinates confidently, which in a trade context is worse than no answer.

The approach

The guiding constraint is that the system is allowed to be unsure, and must say so. Every extracted field carries a confidence score, and anything below threshold routes to a human rather than being written silently. That single decision is what makes the output trustworthy enough to connect to an operational database.

For retrieval, the answer is never allowed to be free-floating. Every response cites the source document and page, so the operator can verify in one click — which is what turns a demo into something people actually use.

  • Built the ingestion pipeline before the model layer — normalisation, OCR fallback for scans, layout-aware chunking.
  • Chose embedding and chunking strategy against a labelled retrieval set rather than by intuition.
  • Constrained generation to retrieved context with mandatory citation, so an unanswerable question returns "not found" instead of an invention.
  • Put an evaluation harness and a token/latency budget in from the start, so quality and cost are measured per change rather than assessed by vibe.

What we built

A document pipeline and retrieval service that sits beside the operational system rather than replacing it.

  • Ingestion pipeline handling PDFs, scans and phone photos, with OCR fallback and deskew/normalisation for poor captures.
  • Layout-aware chunking that keeps tables and field blocks intact instead of splitting them mid-row.
  • Embedding and vector storage in pgvector, keeping retrieval in the same PostgreSQL instance as the business data.
  • Hybrid retrieval — dense vector search combined with keyword matching, then reranked before it reaches the model.
  • Structured field extraction against a per-document-type schema, with a confidence score on every field.
  • Human-in-the-loop review queue: low-confidence fields surface for correction, and corrections feed back as evaluation data.
  • Grounded question answering with mandatory citation to source document and page.
  • Provider abstraction across OpenAI and Gemini so model choice is a config decision, plus caching and token accounting per request.
  • Evaluation harness covering retrieval hit rate, extraction accuracy and answer groundedness, run on every prompt or model change.

Tech stack

AI

OpenAI APIGoogle Gemini APIEmbeddings + rerankingStructured output schemas

Backend

PythonFastAPIAsync ingestion workers

Data

PostgreSQLpgvectorHybrid dense + keyword retrieval

Ops

Evaluation harnessPrompt versioningToken & latency budgets

Where it stands

The pipeline, retrieval layer and evaluation harness are built and running against real document sets. Integration into the operational systems is in progress.

Published as in-build. Extraction accuracy and retrieval figures will be added here once they are measured on a full production corpus rather than an evaluation sample.

Building something like this?

Most of these started as one module solving one painful process. Tell us which process is yours.

We reply within 24 hours, Mon–Sat.