What is document intelligence?
Document intelligence is a system that reads your documents and builds a knowledge graph in which every fact has dates and a source. Ask who held a role in a given month, and you get the answer that was true then, with the file and page behind it. Newer documents replace older facts instead of sitting beside them.
The challenge
Business documents contradict each other all the time, and most of the time they are right to. A person’s title changes. A headcount grows. A proposal quotes one figure for a result and a chart in another file quotes another. Search finds every mention and leaves the reader to work out which one is current.
The sample set we built against was designed to make this hard on purpose:
- A single person’s title changes across four documents, from 2020 to 2026.
- A headcount is stated as an exact number in one document and as “more than” a larger number in another.
- A chart shows one percentage and a report gives a different one for the same result.
- Names are misspelled, and some paragraphs are pasted in from other documents.
We also set a product constraint early. This had to work as software that customers use, with no hand work per customer. Cost and speed had to suit a real product.
How did we approach it?
We put a fast, cheap path first and a language model second. A small decision model answers the parts of a question that are really choices, such as which entity is meant, which relation to follow and whether a new fact ends an old one. A language model writes only when the question asks how or why, or when the graph is unsure.
We also chose a graph over a flat list of chunks. A graph can hold a title that was true from one date to another, and it can answer “at that time” without guessing.
What did we build?
Ingest. Docling converts each PDF into structured text with layout, reading order and tables kept as tables. Scanned or image-only pages are transcribed page by page by a vision model, and charts and diagrams are described by it. Documents are processed oldest first. Each is profiled for title, type, author, date and status, then cut into structure-aware chunks of about 600 tokens and embedded into a vector index.
Facts. A language model extracts typed facts per chunk, with details such as role, value, unit and period, and valid-from and valid-to dates. Entity and relation types come from one schema file, so the same engine can fit other documents.
Resolution. Entities are merged in order of cost: case and typo variants first, then a decision model over candidates with a short profile of each. Titles are never merged by meaning. The most used spelling becomes the name and the rest are kept as aliases. If a fact is stated again it becomes an extra source, not a duplicate. If a fact ends an older one, the older one is closed, and fields such as a title or a metric’s value are marked to replace earlier values.
Ask. A clear question goes down the decision-model path with no language model call, in about 3 to 5 seconds. If the question asks for a description, finds nothing or has low confidence, one language model call writes a cited answer from the graph’s facts and the six closest chunks. That route takes roughly 10 to 13 seconds. Every answer shows the relation that reached it, with its role, value and period.
What came out of it?
| Measure | Result |
|---|---|
| Sample PDFs ingested end to end | 6, in about 2.5 minutes with conversions cached |
| Time to answer a clear question | about 3 to 5 seconds |
| Time when a language model writes the answer | about 10 to 13 seconds |
| Unit tests | 58 passing |
Worked questions on the sample set returned the verified answers, for example the title of an engagement lead in a given month, and the people who worked on two engagements at once. Known weak spots are on record too: the same engagement stored under several names, a few relations extracted backwards, and loosely worded questions read too literally.
What is the stack?
Python, with Neo4j holding documents, chunks, entities and dated facts, and a vector index over both chunks and entities. Docling and a vision model for conversion, and DSPy for profiling and extraction. The project runs in Docker for the database.
What is next?
The open items are all about turning a working engine into a product. We want a proposed schema from a sample of each customer’s chunks, reviewed by the customer. We want a database choice that supports one graph per customer, and a clear multi-tenant model. See how this fits document intelligence for business or AI agents, or talk to us.
Timeline
| When | What |
|---|---|
| September 2026 | Working pipeline, query paths and hand-off notes |