Chunking and embedding a RAG corpus
practical RAG ingestion judgment.
choose chunk size and overlap balancing context vs precision, prefer semantic boundaries, then pick an embedding model matching domain and dimension, and store with metadata.
What's really being asked
This evaluates whether you understand that ingestion choices, especially chunk size and embedding model, directly determine retrieval quality, which bounds the whole RAG system.
The full answer
First clean and normalize the documents, stripping boilerplate and extracting text from PDFs or HTML. Chunking is the pivotal decision: chunk size trades context against precision. Large chunks keep more surrounding context but dilute the embedding's focus, retrieve less precisely, and consume more of the prompt budget; small chunks are precise but can lose the context needed to answer. A common approach is moderate chunks with some overlap so a fact near a boundary is not severed, and respecting semantic boundaries such as paragraphs, sections, or sentences rather than cutting blindly at a fixed token count mid-sentence. For embedding, choose a model matched to your domain and language, since a general model may underperform on specialized text. The same embedding model must encode both documents and queries so they share a space. Consider the embedding dimension, which affects storage and search cost, and the model's max input length relative to chunk size. Attach metadata such as source, title, and timestamp to each vector to enable filtering and citation. Finally upsert vectors into the index and validate retrieval quality on sample queries.
The mistakes people make
Splitting at a fixed token count regardless of sentence boundaries; using no overlap; embedding documents and queries with different models; ignoring domain fit of the embedding model; forgetting metadata for filtering and citations; treating chunk size as unimportant.
What usually comes next
How do you pick chunk size empirically? Why does overlap help? Why must query and document embeddings match? How does metadata enable hybrid or filtered search?
A concrete example
For a corpus of technical manuals you split on section and paragraph boundaries into moderate chunks with a small overlap, embed each with a domain-appropriate model, attach the manual name and section as metadata, and store the vectors. Queries are embedded with the same model, and metadata lets you filter to the relevant product before semantic search, sharpening retrieval.
Interview question
Why is splitting documents into very large chunks often harmful to RAG retrieval quality?
- a.Large chunks dilute the embedding's focus and consume more of the prompt budget, reducing precisionCorrect
- b.Large chunks cannot be embedded by any model
- c.Large chunks make the query embedding model unnecessary
- d.Large chunks always exceed the vector database's storage limit
Why? this is the answer
A large chunk mixes many topics, so its single embedding is less focused, retrieves less precisely, and eats prompt space. It is not that large chunks cannot be embedded; it is a precision and context trade-off.
Just read this? Test yourself on what you have been reading.
Read the original → pinecone.io
- #rag
- #chunking
- #embeddings
- #vector-database
- #retrieval
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on rag — each one lists the topics its interview covers.
See open roles