Vector Search & Retrieval
Vector search finds text that is semantically near a query. Near is not the same as correct, and that gap is where the engineering lives. What you embed, where the chunk boundaries fall, and what you combine the similarity score with matter far more than which embedding model you picked.
How I use it
Ask Nimble — matching across a two-sided marketplace
Designed retrieval for matching technical service requests to supply, where both sides describe the same work in different vocabulary. Keyword matching fails there by definition — a request and the capability that fits it often share no terms at all — which is precisely the case semantic search exists for.
Brand KB — retrieval over per-tenant content
Embeddings stored alongside relational data in Postgres with pgvector, so a similarity search and a tenant filter are one query rather than a lookup followed by filtering in application code that someone will eventually forget.
Chunking decisions
Chunk too large and the embedding averages several ideas into something that matches nothing sharply. Too small and you retrieve fragments with the context stripped out. Boundaries should follow the document’s own structure rather than a fixed token count.
Hybrid over pure similarity
Similarity combined with structured filters and, where it helps, keyword search. Pure vector search returns its nearest neighbours whether or not any of them are right, and it returns them with exactly the same confidence either way.
What I use
- pgvector
- PostgreSQL
- Claude API
- Drizzle ORM
Related skills
Want the detail behind any of this?
I can walk through any of it in as much depth as you want.