Sample questions
Rag Chunking IndexingDifficulty 1
In a RAG indexing pipeline, what does the 'chunking' step do?
- aIt splits source documents into smaller text segments before embedding and indexing.✓
- bIt reduces the dimensionality of an embedding vector before it is stored in the vector index.
- cIt removes stopwords from the user's query before the query is sent to the retriever.
- dIt compresses the language model's weights so inference requires less memory.
Explanation:Chunking divides raw documents into smaller pieces so each piece can be embedded and indexed separately, and retrieved on its own. (b) describes dimensionality reduction on an already-existing vector, not document splitting. (c) is query preprocessing. (d) describes model compression, unrelated to indexing text.
Rag Chunking IndexingDifficulty 2
A team configures overlap as 10% of chunk_size, using integer (floor) conversion. With chunk_size=256 tokens, how many overlap tokens result, and what step advances each window?
- aoverlap = 26 tokens (25.6 rounded up); step = 256 - 26 = 230.
- boverlap = 25 tokens (floor of 25.6); step = 256 - 25 = 231.✓
- coverlap = 10 tokens (the percentage used directly as a token count); step = 246.
- doverlap = 25 tokens; step = 256, since the window always advances by chunk_size.
Explanation:10% of 256 is 25.6, and floor conversion gives 25 overlap tokens; step = chunk_size - overlap = 256 - 25 = 231, confirmed in code. (a) rounds up instead of flooring. (c) treats '10%' as 10 tokens. (d) ignores overlap when computing the step.
Rag Chunking IndexingDifficulty 2
A corpus is split into 10,000 chunks, and each chunk is embedded as a 768-dimensional float32 vector (4 bytes per value). Ignoring index overhead, roughly how much raw storage do the embedding vectors need? (1 MB = 1,000,000 bytes)
- a10,000 x 768 = 7,680,000 bytes, about 7.7 MB.
- b10,000 x 4 = 40,000 bytes, about 0.04 MB.
- c10,000 x 768 x 4 = 30,720,000 bytes, about 30.7 MB.✓
- d768 x 4 = 3,072 bytes, about 0.003 MB.
Explanation:Each vector holds 768 float32 values at 4 bytes each, and there are 10,000 of them: 10,000 x 768 x 4 = 30,720,000 bytes, about 30.7 MB, confirmed in code. (a) omits the 4 bytes per value. (b) omits the dimensionality. (d) omits the chunk count.
Rag Chunking IndexingDifficulty 2
A document has exactly 1000 tokens. It is split with a sliding window using chunk_size=200 and overlap=50 tokens (the last chunk may be shorter). Using chunks = ceil((total - size) / (size - overlap)) + 1, how many chunks does this produce? (verified with tiktoken: ceil((1000-200)/150)+1 = 7)
Explanation:step = size - overlap = 150. chunks = ceil((1000-200)/150) + 1 = ceil(800/150) + 1 = 6 + 1 = 7, confirmed by running the sliding-window loop directly. (a), (b), and (c) come from miscalculating the step or rounding the ceiling incorrectly.
Rag Chunking IndexingDifficulty 1
An embedding model accepts at most a fixed number of input tokens per call. If chunk_size is set larger than that limit, what happens, and how should it be handled?
- aChunks over the limit are truncated, dropping their tail tokens; keep chunk_size under the limit.✓
- bThe model automatically splits the oversized chunk and averages the parts, so no content is lost.
- cThe limit only applies to queries, so oversized chunks are fine as long as queries are short.
- dOversized chunks increase the vector's dimensionality, which improves retrieval accuracy.
Explanation:Inputs beyond the model's maximum are truncated, so the tail of an oversized chunk never reaches the embedding and its content becomes unsearchable; chunk_size must be kept within the limit. (b), (c), and (d) describe behaviors embedding models do not exhibit.
Rag Chunking IndexingDifficulty 3
A recursive chunker uses max_tokens=100. A 250-token paragraph exceeds this, so it is split into sentences that are greedily packed into chunks without exceeding 100 tokens (a new chunk starts when the next sentence would overflow). The sentence token lengths, in order, are [40, 30, 55, 45, 80]. How many chunks result, and what are their token sizes?
- a2 chunks with sizes [125, 125], since the sentences are split evenly in half.
- b3 chunks with sizes [70, 100, 80].✓
- c5 chunks, one per sentence: [40, 30, 55, 45, 80].
- d4 chunks with sizes [70, 55, 45, 80].
Explanation:Greedy packing: 40+30=70 (next 55 would overflow) closes chunk 1; 55+45=100 (next 80 would overflow) closes chunk 2; 80 forms chunk 3. Result: [70, 100, 80], 3 chunks, confirmed by running the loop. (a) ignores the 100 limit, (c) skips packing, (d) miscounts the grouping.