Newsletter
Stay Ahead
Occasional, engineering-led notes on applied AI — what we're building, running, and learning in production.
Occasional, engineering-led notes on applied AI — what we're building, running, and learning in production.
Use case: Replace keyword site search with meaning-based search
Keyword site search fails the moment a visitor's wording doesn't match your copy — someone searching 'cancel my plan' gets nothing if your help article is titled 'Manage your subscription'. Semantic search fixes this by matching on meaning instead of exact terms: Webanto's POST /api/v1/embeddings endpoint (model nomic-embed-text) converts every page, product, or article on your site into a vector, and converts each search query into a vector at request time, so results rank by conceptual closeness rather than shared words. Webanto only returns the vectors — you store and query them yourself, in pgvector or a dedicated vector database, alongside whatever nearest-neighbour search your stack already supports. It's a genuine upgrade for long-tail and conversational queries, though exact-match lookups such as an order number or a SKU are usually still better served by a plain keyword or field lookup running alongside it.
Search results that surface the right page even when the visitor's wording doesn't match the page's own wording.
Fewer 'no results found' pages, because a close semantic match exists more often than an exact keyword match.
Long-tail and conversational queries — multi-word questions rather than short keyword strings — return usably relevant results instead of nothing.
A search index that improves as you add content, without manual synonym lists or keyword-alias maintenance.
Export the text content you want searchable — page titles, body copy, product descriptions — into flat records with a stable ID and URL.
Call POST /api/v1/embeddings with model "nomic-embed-text" for each record. A 5,000-page catalogue costs 5,000 ÷ 100 = 50 credits to embed in full, well inside even the Starter plan's 10,000 monthly credits.
Store each vector next to its record ID in a vector-capable store — pgvector is the simplest option if you're already on Postgres; a dedicated vector database works too.
Build the query path: when a visitor searches, embed their query string with the same nomic-embed-text call and run a nearest-neighbour lookup against your stored vectors.
Return the top N matches by cosine similarity, and set a minimum-similarity threshold below which you show 'no close matches' rather than a low-confidence guess.
Run a keyword-based fallback (or combine both into hybrid search) for queries like order numbers, SKUs, or exact product names, where literal matching beats semantic matching.
Re-embed content whenever it's edited or added; a nightly batch job covering only changed records keeps ongoing embedding costs small and the index current.
No. Semantic search wins on natural-language and long-tail queries where wording varies, but it can underperform on exact lookups — an order number, a part number, a precise product name — where keyword matching is faster and more literal. Most production search bars run hybrid in practice: keyword for exact-match terms, semantic for everything else, merged into one ranked result set.
That depends on how often your content changes. A blog or documentation site can re-embed nightly; a product catalogue with frequent price or stock changes may want embeddings refreshed on publish, though price and stock themselves don't need embedding — only descriptive text does.
No. Webanto returns embedding vectors from POST /api/v1/embeddings only; storing them and running the nearest-neighbour query is your responsibility, typically in pgvector, Pinecone, or a similar vector store you already control.
They'll return similarly ranked results for related queries, which is usually correct behaviour — if two product pages genuinely describe close variants, a visitor searching for either should probably see both. If it's actually duplicate or thin content, that's a content problem semantic search will surface rather than hide.
The embedding cost scales linearly at 100 records per credit, so a 100,000-page site costs 1,000 credits to embed in full, which sits comfortably within a Scale plan's 200,000 monthly credit allowance alongside other usage. The harder scaling question is usually your vector store's query latency at that size, not Webanto's embedding cost.
Shoppers who spot a product in the wild, on someone else's feed, or on a competitor's site rarely know the right keywords to find it in your catalogue. Visual search closes that gap: a shopper uploads
Large media libraries accumulate redundancy fast — the same product shot re-exported at a different crop, a stock photo uploaded twice under different filenames, a banner re-saved at a lower compressi
Reverse image search answers a narrower question than catalogue browsing: given one photo someone just handed you — a screenshot, a competitor's product shot, a customer's snapshot of a damaged item —
Start a 14-day free trial on any paid plan. No credit card required.