commerce
More Like This
Recommendations with no embedding call on the read path.
The cheapest recommendation surface anyone can build. Read the item the visitor is looking at, take the vector already stored on it, and hand that straight back as the search vector. No model runs at request time, because the embedding was computed once when the item was written.
The model
Product
One product, carrying the vector of its description.
- pk
- PRODUCT#<productId>
Attributes: name (S), embedding (L)
Access patterns
- GetItemRead the product being viewed
One item by key, which is where the vector comes from.
- SearchVectors · by-similarityProducts like it
The nearest neighbours to the vector that item already carries.
Design notes
Ask for one more than you needmodelling
The item you searched with is in the index, and under COSINE it scores about zero against itself, so it always comes back first. Ask for TopK + 1 and drop it. Forgetting this ships a recommendation rail whose first suggestion is the page you are already on.
No search schema, no conditionmodelling
This index declares no SearchSchema, so there is no HASH to supply and a search needs no condition at all. That is the right shape when the whole table is one neighbourhood. Declare a HASH the moment you need results confined to a category or a tenant, because you cannot add one later.
Taught in the course
- The key is the address - GetItem needs the whole primary key: partition and sort.
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.
One item by key, which is where the vector comes from.
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.