The hidden budget line

When a company discusses RAG, it often compares model cost per answer. Yet the knowledge base is not static: instructions, contracts, price lists, and policies change. Every document must be fetched, converted to text, OCR-processed if it is a scan, structured, split into chunks, embedded, and written to an index. The team must then check that the correct version is visible to the right people.

This work can be more noticeable than answer generation, particularly when documents are large, scanned, and frequently revised. Our tiny robot intern is eager to reprocess the whole archive every night. Its diligence is admirable; the bill for duplicated work is less so.

Docling's documentation exposes separate controls for OCR, table-structure extraction, and page ranges. Qdrant's FAQ explicitly says that upserting a point with identical content still marks the old version as deleted and inserts a new one. This does not mean “Qdrant is expensive”; it means the application should avoid resubmitting unchanged data without a reason.

Classify documents first

One processing chain for every file is rarely sensible. A digital PDF with selectable text, a scanned contract, and a price table require different operations. Routing should identify format and whether usable text already exists. Disabling OCR for every PDF is unsafe because scans would lose their content. Yet running an expensive recognition path on documents with good text is also worth measuring.

A low-cost starting point is a source manifest. Store a stable document identifier, content checksum, retrieval date, version, and owner. If the checksum has not changed, skip parsing and embedding. If a file changed, process that file rather than the entire library. For a small folder this need not begin with complex orchestration: a schedule, file list, and state log can already provide measurable value.

A checksum is not a semantic quality score. If the parser version, chunking method, or embedding model changes, even unchanged sources may need reprocessing because the index follows new rules. Keep those component versions beside the source hash; otherwise the system silently mixes incompatible text representations.

A model calculation, not a market quote

Assume a company has 1,000 documents averaging eight pages each: 8,000 pages. In a month, 10% of files change and their average length is the same. A full rebuild processes 8,000 pages in one cycle; processing only changed files touches 800 pages. Under the stated assumptions, that is one tenth as many pages in the parsing stage, with fewer embedding jobs if chunk count is roughly proportional to pages.

This is only a model. Its assumptions are evenly distributed changes, no parser or embedding-model change, whole-document reprocessing for every changed file, and roughly proportional chunk counts. Real scans, tables, and file-length differences break the simplification. A 90% reduction in pages processed is not a proven 90% reduction in total RAG cost: the server, storage, backups, answer generation, quality review, and maintenance remain.

For an actual budget, measure CPU or machine hours separately for digital and scanned page parsing, OCR time, chunk counts, embedding time, index writes, and staff time fixing exceptions. Apply those unit measurements to the expected flow of new and revised files. Calculate not only cost per page but cost per verified current answer: an inexpensive index serving an obsolete document has little business value.

When savings become errors

An incremental update is more than “add new vectors”. A revised document may generate a different number of chunks. If old chunks remain searchable, RAG may cite two contradictory versions. You need document and version identifiers, a link from each chunk to its source, a controlled index update, and verification before exposing the new version to users.

For access-controlled documents, verify visibility at the same time as content. Answer and retrieval caches must not retain stale versions. Those controls have a cost, but a wrong answer or exposure of restricted text can make a cheap optimisation expensive.

Independent research on PDF conversion for RAG is a reminder not to select the fastest pipeline alone. Its authors compared several open-source pipelines on Portuguese administrative documents and found that document structure and splitting choices affect answer quality. Their numeric results should not be carried over to Russian contracts, but the operational lesson holds: test a cheaper processing chain on your own documents and questions.

An SME architecture

A practical flow is: source → file manifest and checksum → route by document type → conversion and OCR where needed → chunking → embeddings → versioned, access-controlled index → test questions → release of the new version. Send parsing failures to a human exception queue. Keep the source and reproducible processing settings so an error can be repaired or the index rebuilt.

On-premises processing is appropriate if documents cannot be sent out or workload is predictable. It does not eliminate the cost of CPU/GPU, storage, backup, and support. For irregular ingestion, a dedicated accelerator may sit idle; measure utilisation and delay before allocating a separate server. A first pilot may use overnight batch processing if the business does not need every revision published immediately.

A two-week check

Choose one folder or knowledge section and record owners and update frequency. Run two jobs on a copy of the data: a full rebuild and a changed-files-only run. Compare stage times, OCR errors, index size, answer freshness, and quality on the same test questions. Revise one document and verify that the answer cites the new version; restore the earlier version and test rollback.

If the gain is small, the corpus may not yet justify a complex incremental pipeline. If it is large, record version history and conditions for a full rebuild. Let the robot intern rest when a document has not changed: sometimes less robotic activity is better economics.

Primary source for index update behaviour: Qdrant FAQ. PDF processing capabilities: Docling documentation. Independent context on document-preparation quality: From PDF to RAG-Ready. The numeric scenario above is an editorial model, not the outcome of a particular company.