Compare speed and retrieval quality
The language tabs use earlier client interfaces. Check SDK versions and connection setup before running them.
Fast mode searches a narrower part of the index. Compare it with high_recall using questions whose useful matches you know.
Before you run it: Set the mode explicitly when comparing the two search behaviors.
Use the cosine setup, then add enough representative records to compare search quality. Recall means how many useful matches the search finds. Keep the query, result count and dataset the same when changing only mode.
- Prepare known useful matchesKeep the dataset, query vectors and k fixed.
- Run fast modeSearch with the narrower candidate exploration.
- Run high_recall modeRepeat the same requests with wider exploration.
- Compare the tradeoffMeasure missing useful matches and response times.
Follow the example
- Prepare representative queries.
- Run them with mode: fast.
- Repeat with mode: high_recall.
- Compare response times and useful matches.
When to choose another approach
Use high_recall when missing a useful match would make the answer unreliable. Compare modes on your own data; table size alone does not establish a speed or quality threshold.
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 floats ... */],
"k": 10,
"dim": 768,
"metric": "cosine",
"mode": "fast"
}'Check the result
A narrower search may miss matches found by a wider search. The tradeoff depends on the data.
[
{ "id": "sku-9281", "score": 0.9421 },
{ "id": "sku-1144", "score": 0.9187 }
]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.
The result fields have the same shape in both modes; the candidate search is what changes.
Choose the search mode
| Value | Behaviour |
|---|---|
| "high_recall" | Default. Searches more candidates; still approximate. |
| "fast" | Searches fewer candidates. Measure missed matches and latency before choosing it. |
Important limits and checks
Measure end-to-end result quality before changing modes across an application. Neither mode is a latency guarantee; measure a representative workload, including tail latency.