Product & catalog search
The outcome
An e-commerce or marketplace team ships search that understands intent, not just keywords. By combining semantic matching (meaning) with keyword matching (exact tokens) — hybrid search — and then reranking the top candidates, it handles synonyms (“sneakers” finds “running shoes”), typos, and natural-language queries (“warm jacket for hiking under £100”) over a product catalog or any large item set. It can go multimodal too: search by image to find visually similar products.
Why it matters: better relevance puts the right item at the top, which lifts conversion; understanding intent means far fewer dead-end “no results” pages; and exact-token matching still nails SKUs, model numbers, and brand names that pure semantic search would miss. One ranked list, the best of both signals — and you build it by driving the dodil CLI with Claude.
How it maps to Dodil
A vector store over your catalog that runs hybrid dense + BM25 search with reranking in a single engine, fed by embeddings from the same platform. Each piece is one Dodil service:
- Hybrid search + reranking — K3 Vector does dense (semantic) and sparse BM25 (keyword) retrieval and fuses them, then reranks the top candidates for top-K precision. It’s bucket-native: one search mode handles the rest, so there’s no separate keyword cluster and no fusion glue.
- Embeddings + reranking models — Ignite Models : OpenAI/Cohere-compatible inference for embedding both your catalog items and incoming queries, and for the cross-encoder rerank step.
- Multimodal (optional) — embed product images alongside text so a query image returns visually similar items, reranked against a text description for “looks like X and matches Y.”
Why it’s faster and cheaper here
Without Dodil, intent-aware catalog search is several products glued together: a search vendor (or self-hosted Elasticsearch / OpenSearch) for keyword matching, plus a separate vector DB for semantic similarity, plus an embedding pipeline to turn items and queries into vectors, plus a reranker model to sharpen the top results — each a distinct account, integration, and bill, all wired together and operated by you.
On Dodil that collapses. One engine does dense + sparse (BM25) retrieval, fuses them, and reranks the top candidates — no separate keyword cluster, no separate vector DB, no fusion glue to maintain. The embeddings and the reranker come from the same platform, so there’s no third-party inference API to wire in. And it’s all reached with one IAM token behind a single typed CLI an agent can drive. The pieces are built to fit, so there’s nothing to integrate between them.
- Faster — one engine and one platform instead of four stitched-together services means search that understands intent ships in days, not weeks: less integration code, one auth, and reranking is a flag rather than a model to stand up and serve.
- Cheaper — fewer vendors and fewer bills, no fusion or embedding glue to own, and no idle search cluster or inference endpoint to keep warm and monitor.
These wins are structural — they come from removing vendors, glue, and idle capacity, not from a pricing trick.
Build it
- K3 Vector — stand up the catalog collection and run search from the CLI. The Hybrid + Rerank recipe shows how one search mode runs dense + BM25 and an optional rerank flag, with guidance on when each tier helps.
- Ignite Models — the embeddings and reranker behind it.
- For a full step-by-step walkthrough, see the blog .
See also
- Use Cases — what teams build on Dodil, and why it ships faster
- CLI · MCP — the typed surface you (and Claude) drive to build this
- Ignite Models — OpenAI/Cohere-compatible embeddings and reranking
- Get an Access Token — the single IAM token used across all of it