← Notes

The parts of an indexed knowledge base, one by one

Ingestion, chunking, embedding, storage and search are five separate decisions; treating them as a single package is what makes the project look too big to start.

"Deploy a knowledge base with indexing and vector search" sounds like one project. It is five decisions, and they are taken separately.

Ingestion is how the text gets in and when it is reprocessed. Chunking is how the text is cut up — and Azure AI Search's chunking documentation points out that it exists first for a mechanical reason: "Partitioning large documents into smaller chunks can help you stay under the maximum token input limits of chat completion and embedding models". Embedding is the choice of model that turns a chunk into a vector, and it is the one with a recurring cost per volume.

Storage is where many projects assume they need new infrastructure, and it is exactly where they do not. pgvector is a Postgres extension, and its instruction is direct: "Store your vectors with the rest of your data". The vectors sit in the database the project already has, with no extra service. Search, finally, is how a query finds the chunks — and it can be vector, textual, or both.

Separating the five changes the size of the first step. You do not have to decide the whole pipeline to begin; you have to decide which of the five is on the critical path of the problem you want to solve.