Search by dot product
The language tabs use earlier client interfaces. Check SDK versions and connection setup before running them.
Dot product compares both direction and magnitude. Use the scoring method recommended by your embedding model.
Before you run it: Normalize both stored and query vectors if you intend dot-product ranking to match cosine. Do not normalize only one side.
Use the vector-write pattern in a fresh collection, with metric: "dot" on the write as well as the query. Do not reuse the cosine sample collection unchanged. Supply all vector values; a shortened array is not runnable JSON.
- Use a fresh dot collectionSet dot on writes rather than reusing the cosine sample unchanged.
- Query in the same vector spaceUse matching dimensions and normalization.
- Read highest scores firstVector length can affect this score; it is not necessarily bounded.
Follow the example
- Store vectors with the dot metric.
- Create a query vector of matching dimensions.
- Choose k and query.
- Read the highest scores first.
Run the request
curl -X POST "https://$OC_HOST/v1/tenants/$OC_TENANT/vector/shop.products/topk" \
-H "Authorization: Bearer $OC_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"query": [0.0124, -0.0883, 0.0451, /* ... 768 unit-normalised floats ... */],
"k": 10,
"dim": 768,
"metric": "dot"
}'Check the result
Larger scores rank first. Scores are unbounded unless both sides are normalized.
[
{ "id": "sku-9281", "score": 0.9418 },
{ "id": "sku-1144", "score": 0.9180 },
{ "id": "sku-5520", "score": 0.8895 }
]The HTTP response is a JSON array of hits, with no hits wrapper. The IDs and scores above illustrate the shape; your stored data determines the results.
score is the inner product. Higher = closer. If both sides are unit-length the score falls in [-1, 1]; if not, the score is unbounded.
Request options
| Field | Required | Notes |
|---|---|---|
| query | yes | Array of floats. Follow the embedding model's normalization rules consistently for stored and query vectors. |
| k | yes | Number of hits to return. |
| dim | yes | Must match the table's locked dim. |
| metric | yes | Set to "dot". Must match the metric the table was put with. |
Important limits and checks
- Dot on non-normalised vectors. Without normalization, vector length contributes to the score as well as direction. That may be intentional for your model. If it is not, inspect how both stored and query vectors were prepared before changing the scoring method.
- Normalising one side and not the other. Normalise both stored vectors and the query, or neither. Mixing the two ruins the ranking.
- Switching mid-table. If half the table was put pre-normalised and half wasn't, dot scores are no longer comparable. Re-embed and re-put.