You 🧑
Ok I noticed you had to look up quite a few docs for this, which means the information was not available in the skills. First explain how the docs could be better (I'll give that feedback to mongo's doc people) second explain what the skills are lacking to do this
Assistant 🤖
The docs have the information, but it is spread across several areas and the “vector search with geo filter in $search” path is not as discoverable as it could be.
There should be a direct recipe titled something like:
Run semantic/vector search with a geo distance filter
The example should show:
Something like:
db.places.aggregate([
{
$search: {
index: "places_vector_geo_idx",
vectorSearch: {
path: "embedding",
queryVector: queryVector,
numCandidates: 200,
limit: 10,
filter: {
geoWithin: {
path: "location",
circle: {
center: {
type: "Point",
coordinates: [-73.9857, 40.7484]
},
radius: 5000
}
}
}
}
}
},
{
$project: {
name: 1,
location: 1,
score: { $meta: "searchScore" }
}
}
]);
Right now the vectorSearch operator page says the filter can use supported MongoDB Search operators, and the geoWithin page explains circle filtering, but the combination is not obvious.
This is probably the biggest source of confusion.
MongoDB now has two similarly named mechanisms:
|
Feature |
Stage/operator |
Index type |
Geo filter support |
|
MongoDB Vector Search stage |
$vectorSearch aggregation stage |
vectorSearch index |
No Search geo operators in filter |
|
MongoDB Search vector operator |
$search: { vectorSearch: ... } |
MongoDB Search index with type: "vector" |
Yes, via filter with Search operators like geoWithin |
The docs should have a very explicit comparison box on both pages:
If you need advanced Search pre-filters such as geoWithin, phrase, wildcard, fuzzy text, etc., use $search.vectorSearch, not the $vectorSearch stage.
And conversely:
If you only need simple metadata pre-filters, use the $vectorSearch stage with a vectorSearch index.
The names are very easy to confuse:
The docs could include clearer terminology, for example:
This matters because the index definitions look different.
For $vectorSearch, the index looks like:
{
"fields": [
{
"type": "vector",
"path": "embedding",
"numDimensions": 1536,
"similarity": "cosine"
},
{
"type": "filter",
"path": "tenantId"
}
]
}
For $search.vectorSearch, the index looks like:
{
"mappings": {
"dynamic": false,
"fields": {
"embedding": {
"type": "vector",
"numDimensions": 1536,
"similarity": "cosine"
},
"location": {
"type": "geo"
}
}
}
}
That distinction should be front and center.
The docs say that filter can use supported MongoDB Search operators, but it would be helpful to have a table directly on the vectorSearch operator page.
Example:
|
Filter use case |
Search operator in vectorSearch.filter |
|
Exact match |
equals |
|
Set membership |
in |
|
Range |
range |
|
Field exists |
exists |
|
Geo radius |
geoWithin.circle |
|
Geo polygon |
geoWithin.geometry |
|
Geo shape relation |
geoShape |
|
Text prefilter |
text, if supported in filter context |
|
Phrase/wildcard/fuzzy |
Relevant Search operators, if supported |
If some operators are not supported inside vectorSearch.filter, say so explicitly.
The docs should call out:
For people familiar with normal MongoDB geo queries, it is very easy to assume that a 2dsphere index is involved. It is not, for $search.geoWithin.
A troubleshooting section would help a lot:
This will not work:
{
$vectorSearch: {
filter: {
geoWithin: { ... }
}
}
}
Because $vectorSearch.filter supports a limited subset of MQL-style filters, not MongoDB Search operators.
A vectorSearch index is not the same thing as a MongoDB Search index with a vector field mapping.
GeoJSON uses:
coordinates: [longitude, latitude]
not [latitude, longitude].
geoWithin filters by distance/shape. It does not automatically sort by distance or include the distance. The ranking remains vector similarity unless otherwise modified.