docs: contrast the advanced retrieval modes with distinct examples (#6904)
This commit is contained in:
@@ -99,16 +99,23 @@ results = client.search(
|
|||||||
|
|
||||||
### Recommended Configurations
|
### Recommended Configurations
|
||||||
|
|
||||||
|
`rerank` is the only lever here that changes result *order*. `filters`, `top_k`, and `threshold` change *which* memories come back, not how they're ordered. The two functions below send the same query and filters; the only difference is the `rerank` flag.
|
||||||
|
|
||||||
<CodeGroup>
|
<CodeGroup>
|
||||||
```python Python
|
```python Python
|
||||||
# Basic search - good for exploration
|
# Fast path - use for exploratory search, or anywhere the user scans a list
|
||||||
|
# of results instead of trusting result #1 (dashboards, "show me everything
|
||||||
|
# about X" style queries). No reranking overhead.
|
||||||
def quick_search(query, user_id):
|
def quick_search(query, user_id):
|
||||||
return client.search(
|
return client.search(
|
||||||
query=query,
|
query=query,
|
||||||
filters={"user_id": user_id},
|
filters={"user_id": user_id},
|
||||||
)
|
)
|
||||||
|
|
||||||
# Reranked search - good when result order matters
|
# Precision path - use when only the top result reaches the user, e.g. an
|
||||||
|
# agent that injects a single fact into a prompt. Reranking (see above)
|
||||||
|
# re-scores every match and moves the closest one to position 1, at the
|
||||||
|
# cost of ~150-200ms added latency.
|
||||||
def standard_search(query, user_id):
|
def standard_search(query, user_id):
|
||||||
return client.search(
|
return client.search(
|
||||||
query=query,
|
query=query,
|
||||||
@@ -118,14 +125,19 @@ def standard_search(query, user_id):
|
|||||||
```
|
```
|
||||||
|
|
||||||
```javascript JavaScript
|
```javascript JavaScript
|
||||||
// Basic search - good for exploration
|
// Fast path - use for exploratory search, or anywhere the user scans a list
|
||||||
|
// of results instead of trusting result #1 (dashboards, "show me everything
|
||||||
|
// about X" style queries). No reranking overhead.
|
||||||
function quickSearch(query, userId) {
|
function quickSearch(query, userId) {
|
||||||
return client.search(query, {
|
return client.search(query, {
|
||||||
filters: { user_id: userId },
|
filters: { user_id: userId },
|
||||||
});
|
});
|
||||||
}
|
}
|
||||||
|
|
||||||
// Reranked search - good when result order matters
|
// Precision path - use when only the top result reaches the user, e.g. an
|
||||||
|
// agent that injects a single fact into a prompt. Reranking (see above)
|
||||||
|
// re-scores every match and moves the closest one to position 1, at the
|
||||||
|
// cost of ~150-200ms added latency.
|
||||||
function standardSearch(query, userId) {
|
function standardSearch(query, userId) {
|
||||||
return client.search(query, {
|
return client.search(query, {
|
||||||
filters: { user_id: userId },
|
filters: { user_id: userId },
|
||||||
@@ -135,6 +147,8 @@ function standardSearch(query, userId) {
|
|||||||
```
|
```
|
||||||
</CodeGroup>
|
</CodeGroup>
|
||||||
|
|
||||||
|
**What changes in the response:** both calls return the same fields on each memory (see the [Search Memories API reference](/api-reference/memory/search-memories) for the full response shape). The only difference is the *order* of the `results` array, the same effect shown in the [Reranking example above](#reranking): `quick_search` returns results ranked by raw similarity, `standard_search` returns the reranked order.
|
||||||
|
|
||||||
## Best Practices
|
## Best Practices
|
||||||
|
|
||||||
### Do
|
### Do
|
||||||
|
|||||||
Reference in New Issue
Block a user