Find one chunk, read its neighbours

Why

Retrieval wants two things that pull against each other. It wants small chunks, because a small chunk embeds precisely and a large one blurs into an average of everything it contains. And it wants enough surrounding text for the answer to make sense. Chunk small and search results are fragments; chunk large and the search gets vague.

You do not have to choose. Chunk small so the search is sharp, then use the keys you got back to read the neighbours. The sort key already encodes chunk order, so a BETWEEN either side of the hit is a single Query on one partition. The search never carried that text and never paid for it.

Grouping the index by corpus rather than by document is the decision that makes this work at all. Group by document and the SearchSchema's HASH forces you to name a document before you can search, which is the question you were trying to answer.

Projection matters more here than it does on a GSI. Search results are capped at TopK but they are 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 single query. Ask for the keys, then fetch the handful of bodies you actually need.

One convenience worth knowing: the vector attribute is left out of results unless a ProjectionExpression explicitly asks for it and the index projects it. You almost never want a 384-number array in a result payload, and the default is the one you want.

Chunk small for a sharp search, project only the keys, then expand through the sort key and fetch bodies by key: two cheap reads beat one fat one.