Vector models by industry
Vector search can find similar descriptions, support tickets, passages or media. These examples pair that search with the source record and any relevant filters. Generate compatible embeddings first; the examples do not create them automatically.
- Prepare resolved ticketsKeep the original text, resolution and record ID.
- Embed the history and new issueUse the same model for stored and query text.
- Search the relevant historyApply supported restrictions such as product or resolved status.
- Review the suggested answerOpen the source ticket and confirm it fits the current issue.
Retail: search that understands the ask
A shopper types something no keyword index will match, and the catalog still has the right answer.
Nearest products, within the shopper's constraints
Include the supported price or category filter in the request. A filtered approximate search can return fewer than the requested number of results; inspect the actual matches.
POST /v1/tenants/:t/vector/shop.products/topk
{ "query": [...], "k": 10, "dim": 768, "metric": "cosine" }Pair it with keywords
Vectors are strong on meaning and weak on exact terms - a model number, a brand. Run both and merge; the full-text side is the search API.
{ "query": { "match": { "name": "carbon marathon" } } }Support: deflect the ticket before it is filed
The customer describes a problem in their words. The answer already exists, written in someone else's.
Nearest resolved tickets
Embed the draft as it is typed and search resolved history; a good match becomes a suggestion instead of a ticket.
POST /v1/tenants/:t/vector/support.tickets/topkthe two surfaces answer together
Nearest-neighbour finds the ones that mean the same thing; the suggester fixes a misspelled product name before either search runs.
Legal and research: retrieval for grounded answers
The retrieval half of RAG. The quality ceiling of the answer is set here, not in the model.
The passages worth sending
Chunk the documents, embed the chunks, and retrieve the few that actually bear on the question.
POST /v1/tenants/:t/vector/kb.chunks/topkkeep the citation
Store the source id and offset on the chunk row. Retrieval then returns something a reader can verify, which is the difference between an answer and a claim. RAG guide.
Media: finding the near-duplicates
Not identical files, which hashing finds, but the same thing re-encoded, cropped or re-uploaded.
Neighbours above a similarity threshold
Search each new asset against the library and treat anything very close as a candidate duplicate for review.
POST /v1/tenants/:t/vector/media.assets/topkWhat these have in common
-
Keep source records and vectors aligned. Explicit vector writes are separate from row writes. Regenerate embeddings when their source changes.
-
Check filtered results. Use supported filters and expect fewer than k matches when the index or filter cannot supply k candidates.
-
Meaning and words are different questions. The strongest results usually come from running both and merging.
-
Start from zero — Declare a column, write a vector, search it.
-
Make it fit — Quantization and index choice as the corpus grows.