Search — Fields & weights
Semantic search lives or dies by the lens's fields block and each field's
searchable flag. This is the page to read before your first production lens.
The rule: searchable is opt-in
Only fields where searchable is true or { weight: N } are embedded and
included in search ranking. Everything else is stored as metadata — returned
in the result payload, filterable in query(), but invisible to search().
searchable | What happens |
|---|---|
true | Field is embedded, contributes to the vector with weight 1 |
{ weight: N } | Field is embedded, contributes with weight N (repeats N times in the embedding text) |
false / omitted | Not embedded. Field is stored and queryable, but doesn't affect search ranking |
Do not mark IDs, timestamps, or numeric codes as searchable. They'll waste
embedding cost and pull the vector in a meaningless direction. Reserve
searchable for natural-language content.
Weights change the ranking, not the cost
A weight of 3 on name vs 1 on description means a name match scores
roughly three times as high as an equivalent description match. Weights don't
cost extra embedding API calls — each field is still embedded once.
Note that brand and category are NOT searchable — they're metadata. They
come back in the result rows, and you can filter on them via query(), but
they don't influence the ranking.
Common patterns
- Product catalog:
namewith{ weight: 3 },descriptionastrue. Brand/category stored as metadata. - Docs / articles:
titlewith{ weight: 2 },bodyastrue. Tags as metadata. - People directory:
namewith{ weight: 2 },bioandskillsastrue. Team/role as metadata. - Tickets:
subjectandbodyboth astrue. Status, priority, assignee as metadata.
Up next: Filters — combining structured predicates with vector ranking.