Blog/·Updated
The document-to-vector pipeline is one system, not four vendors
Retrieval quality is decided upstream — at extraction and chunking. Why OCR, chunking, embedding and vector delivery belong in one pipeline with one set of metadata.
Retrieval quality is mostly decided before a query is ever run. It depends on how accurately text was extracted, how it was split into chunks, and whether each chunk still knows where it came from. Treat extraction, chunking, embedding and delivery as one system, because each step inherits the mistakes of the one before.
The common architecture does the opposite. OCR comes from one vendor, chunking from a framework default, embeddings from a model API, and a script pushes vectors into a database. Each piece works on its own. The failures appear at the joins, where metadata is dropped and nobody owns the result.
Where do retrieval pipelines usually break?
At chunking. Fixed character windows cut sentences in half and separate headings from the text they introduce. The embedding model then represents half an idea, and retrieval returns passages that match the query's words without answering it.
At provenance. If page numbers and positions are lost between OCR and the vector store, answers cannot cite their source. Teams then add a second lookup to recover it — or ship answers nobody can verify.
What is structure-aware chunking?
Structure-aware chunking builds chunks from the document's own units — paragraphs on a page, or time-coded segments in a video — up to a token budget. A unit is only split if it is too large on its own, and then at sentence boundaries. Every chunk carries its page range or timestamps.
The result is a chunk that reads as a complete thought, and a citation that points back to the exact page or moment it came from.
Should embeddings live in your database or the vendor's?
Yours, eventually. Vectors are infrastructure: they sit next to your permissions, your application data and your retrieval logic. A pipeline should deliver to the store you already run — Pinecone, Qdrant, Weaviate or Postgres with pgvector — rather than lock retrieval inside a vendor's index.
A hosted store still has a place while you prototype. The mistake is making it the only option.
What does a single pipeline look like in practice?
One job carries a file from upload to vectors: extraction with layout, quality control, structure-aware chunking, embedding, and delivery to a named destination. The same API key uploads the file, polls its status and reads the results, and metadata flows through every step untouched.
That is the shape of OCRs.ai. We built it because the hardest retrieval bugs we saw were never in the vector database — they were in the handoffs before it.