OCR pipeline

When a file is attached to an assistant, Intric doesn’t just pull the text out and cut it into pieces. It works through the document in several stages, so that by the time anyone asks a question, the assistant knows what the file is about, can find a passage by exact wording or by meaning, and can move through the document page by page. This article describes those stages at a technical level. For what this means when you’re using an assistant, see How Intric searches your documents.

Why not a simple pipeline

Many retrieval systems work the same way: extract the raw text, cut it into fixed-length pieces, turn each piece into a vector, and paste the closest few pieces into the prompt. That works for short questions about short documents. It breaks down on the material organizations actually use:

• A scanned page has no text to extract, so it silently contributes nothing.
• A chart, flowchart or infographic is dropped, even when it holds the answer.
• A table cut in half loses the link between its header and its rows.
• A question about a whole chapter gets back a handful of disconnected fragments.
• With dozens of files attached, every search runs against everything, and weak matches from irrelevant files crowd out the right one.

Each stage below exists to deal with one of these problems.

The pipeline at a glance

Processing starts as soon as a file is attached and runs in the background, as a set of jobs that depend on each other:

1. Extraction — the document is read page by page. Pages that need it go through OCR, and figures go to a vision model.
2. Summarization — a short summary of the whole file is written.
3. Chunking and indexing — the text is split into small passages, each tagged with its position in the document, and indexed for both keyword and semantic search.

Summarization and indexing both start once extraction has finished, and they run side by side. Large PDFs are split into sections that are extracted in parallel and put back together in order.

Stage 1: Extraction

Deciding which pages need OCR

OCR is slower and less exact than reading a text layer that is already there, so Intric doesn’t apply it to everything. Each page is examined on its own, and a page goes to OCR only when its text layer can’t be trusted to be complete. For example, when:

• the page has no text layer, as with a scanned document
• the embedded text is garbled or covers only part of what is on the page
• the page carries images large enough to contain content of their own
• the page contains annotations, or a table without visible borders

Pages with a clean text layer are read directly. A document that is partly born-digital and partly scanned is therefore handled correctly page by page, rather than being treated as one or the other.

Keeping the structure

Extraction keeps the parts of a page that carry meaning through their position:

• Tables are detected and rebuilt as structured tables, so each value stays attached to its column header.
• Form fields — ticked checkboxes and filled-in text fields — are merged into the text, so a completed form reads as completed.
• Page boundaries are kept exactly, which is what later makes page-level references possible.

Describing figures and diagrams

Where a page holds a figure — a diagram, a chart, a photographed table, an infographic — the figure region is cropped out and passed to a vision language model. The model writes a text description of what the figure shows:

• text inside the image is transcribed
• diagrams are described in terms of their parts and how they connect
• tables in images are converted into structured data
• charts are described by their axes and data points
• photos, drawings such as floor plans, and font samples are described by what they show, rather than reduced to their caption

The description is inserted at the figure’s position on the page, so it reads in context and is indexed like any other text. A question whose answer lives only in a flowchart can then be answered, and cited, from that page.

Figure description is optional. On an installation where no vision model is configured, extraction still works but stays text-only.

File types

Type	How it’s read
PDF	The full pipeline above, including OCR and figure description
Word, PowerPoint	Text and structure extracted directly
Plain text, Markdown, HTML, RTF, JSON and similar formats	Read as text
Excel, CSV	A separate route — see Spreadsheets

Stage 2: Summarization

A short summary of each file is written from a representative excerpt of its content.

The summaries are what let an assistant choose which file to look in before searching. With a small number of files, all summaries are given to the model up front. With many files, the model can browse the list of files and run a discovery search across all of them to find candidates. Either way it narrows the field first, rather than searching fifty documents at once and sorting through weak matches from all of them. That reduces false hits and keeps the working context small.

Stage 3: Chunking and indexing

How text is split

The extracted text is split into chunks of up to roughly 300 tokens. A split falls at the most natural boundary available: between paragraphs first, then between lines, then between sentences, and only as a last resort between words. In a PDF, a chunk never crosses a page boundary, and a table or other extracted element is kept whole where it fits.

No overlap, explicit position instead

Many systems repeat 10–20% of each chunk at the start of the next, so that a sentence cut at a boundary survives in at least one piece. That makes the index larger and fills the prompt with the same text twice.

Intric’s chunks don’t overlap. Instead, every chunk records where it sits:

• page number — the page of the original document the chunk came from
• chunk index — its position in the document’s sequence of chunks

Because the position is explicit, the assistant can ask for “the next chunk” or “everything on page 66” directly. Continuity is something it can reach when it needs it, rather than something paid for in every chunk.

Indexing

Each chunk is indexed twice: for keyword search, and as a vector embedding for semantic search. The embedding model is configured per installation, and each knowledge index is tied to the embedding model that created it.

Spreadsheets

Spreadsheets and CSV files are deliberately not chunked or embedded. Cutting a table into text fragments and comparing them as vectors destroys what makes it a table: an average or a filtered count can’t be computed from a few similar-looking rows.

Instead, the assistant is given the structure of each sheet — its column headers, a few sample rows, and the row count — and answers questions by writing and running code against the actual data in an isolated sandbox. A question such as “how many cases were closed in March” is answered by computing it, not by guessing from fragments. Spreadsheets still receive a summary, so they can be chosen among other files.

Retrieval: how the index is used

At question time, the assistant doesn’t run one fixed search. It has a set of retrieval tools and decides which to use, and in what order, based on the question.

Tool	What it does
Hybrid search	Searches one file by keyword and by meaning at once. The model sets the balance for each search, from pure keyword matching to pure semantic matching.
Navigational reading	Fetches chunks by their exact page number or chunk index, so the model can read forward or backward from a point it has found.
Full read	Reads a file in full, for tasks that need the whole document.
Discovery	Searches across all of an assistant’s files to find which ones are relevant.

Weighting keyword against meaning

The hybrid search takes a weight between 0 and 1. At 0 it is pure keyword matching (BM25), at 1 pure semantic similarity, and anything in between blends the two. The model picks the weight for each search:

• a case number, an article reference or a person’s name calls for a low weight, so the exact string wins
• a conceptual question calls for a high weight, so “health effects of irregular schedules” can match a question about night shifts
• most questions fall somewhere in between

Following a document

Navigational reading is what lets an assistant handle a request such as “summarize chapter 8”:

1. A hybrid search for “Chapter 8” finds the chunk where the chapter starts, on page 65.
2. The model reads the page number from that chunk’s position.
3. It fetches the following pages in order — 66, 67, 68 — until it reaches the heading of chapter 9.
4. It summarizes the whole chapter, with references to the pages it read.

A single search would have returned the chapter’s opening paragraph and a few scattered passages. Reading forward gets everything in between.

The limit on full reads

Reading a file in full is useful for short documents and tasks like comparing two agreements, but a very large file would flood the context. For indexed files, a full read is limited to 60,000 characters. When a file is larger, the tool refuses and tells the model to use hybrid search or navigational reading instead, so it has to narrow down rather than read everything.

Why not just use a large context window

Models with very large context windows can in principle take in a whole document collection at once. In practice, attention thins out over hundreds of thousands of tokens: passages in the middle get overlooked, and constraints stated early are forgotten. Retrieving a small amount of highly relevant text, and widening it deliberately when needed, keeps what the model is working with short and dense. It also keeps every piece traceable to where it came from.

References

Every chunk the assistant retrieves carries its file and page number, and the assistant is required to cite the sources it used. In the answer, each reference is a numbered citation. For a PDF, the citation opens the original document in a viewer beside the conversation, at the cited page. Other file types open in a preview.

References point at the page, not a highlighted passage, and they point into the file you uploaded — which is why uploading the original document, not an exported or converted copy, gives the most useful references.

Attachments and files in a conversation

Files attached to an assistant and files uploaded directly into a conversation take different paths.

	Attached to the assistant	Uploaded in a conversation
Extraction	Full pipeline, including OCR	Full pipeline for PDFs, including OCR; other files read as text
Summarized and indexed	Yes	No
How it’s used	Searched with the retrieval tools	The extracted text is given to the model directly
Lasts	As long as it’s attached	For that conversation
Scale	Large libraries, many files	Limited by the model’s context window
Best for	Handbooks, policy libraries, archives	One-off reviews and comparisons

The retrieval tools only work on attached files. A file uploaded in a conversation is read whole, so it’s subject to the context window of the model in use. See Attachments.

Processing status

While a file is being processed, it shows its state in the assistant’s knowledge settings: Waiting…, then Analysing… with a progress bar, then Done. Status updates arrive live, without reloading. If processing fails, the file shows Failed and a Try again button that reruns its processing.

The pipeline retries failures on its own before reporting one, and attempts to repair corrupted PDFs before giving up on them. A file that hasn’t finished processing is still visible to the assistant, but only as a short excerpt, and it can’t be searched until indexing is done.

Limit	Value
File attached to an assistant	100 MB
PDF processed with OCR	3,000 pages
File uploaded in a conversation	25 MB
Files per question in a conversation	20

A PDF over the page limit is refused when it is uploaded, with an error that gives its page count and the limit.

Where the processing happens

Every stage runs inside the Intric platform or on a model endpoint that the installation chooses:

• OCR and layout analysis run within the platform itself, with no external service involved.
• Figure description, summarization and embedding each call a model endpoint that is configured separately per installation.

On an on-premise installation, each of those can point at a model running on your own infrastructure, so a document can be processed from upload to index without leaving your environment. The pipeline depends on a job queue and a search index that are part of current installations; an older on-premise installation that doesn’t run them yet uses the earlier knowledge processing until it is upgraded. For how document data moves between Intric and the embedding model on the cloud service, see Knowledge data flows.