ai
RAG Chunk Store
Find one chunk by meaning, then read its neighbours by key.
Retrieval wants small chunks, because a small chunk embeds precisely and a large one blurs into an average of everything it contains. It also wants enough surrounding text for the answer to make sense. Chunk small so the search is sharp, then use the keys you got back to read either side. The search never carries that text and never pays for it.
The model
Chunk
One passage of one document, with the vector of its text.
- pk
- DOC#<docId>
- sk
- CHUNK#<seq>
Attributes: corpus (S), text (S), embedding (L)
Access patterns
- SearchVectors · by-corpusFind the passage
The chunk nearest the question, across the whole corpus.
- QueryRead around the hit
The chunks either side of the winner, for context the search never carried.
Design notes
Two cheap reads beat one fat onecost
Search results are capped at TopK but not capped in size, and vector work is billed by bytes. Returning a full chunk body for every hit means paying for text you mostly discard on every query. Project the keys, then fetch the handful of bodies you actually need.
Zero-padded sequence numbersmodelling
CHUNK#0002 rather than CHUNK#2, so a BETWEEN over the sort key means what it looks like it means. Unpadded, CHUNK#10 sorts before CHUNK#2 and the expand step silently returns the wrong passages.
These rows are real and already here. Running an operation against them downloads a DynamoDB-compatible engine, about 850 KB, and executes it in this tab.
The chunk nearest the question, across the whole corpus.
Run an operation to see the raw engine response.
Transactions, streams, tags and TTL are among the operations the in-browser engine doesn't implement yet.