Retrieval and reranking are separate jobs

Candidate retrieval selects a manageable group from a much larger collection. It must be fast enough to run for every query and broad enough not to discard the best answer too early. Reranking works on that smaller group with more expensive features or models. Vespa documents this through matching, first-phase ranking and later ranking phases. The architecture balances recall, quality and latency rather than asking one calculation to satisfy all three.

The distinction prevents a common diagnostic error. When search results are poor, teams often tune weights immediately. Yet the target document may be absent from the candidates because its fields are not indexed, its vocabulary does not match, a filter excludes it, or the document itself does not exist. No reranker can promote what it never receives. Start by inspecting candidate coverage. Only then should the team debate the finer order of plausible results.

Different retrieval methods cover different failure modes

Lexical retrieval is precise when a query contains product names, codes or technical terms that appear in the catalogue. Nearest-neighbour retrieval can surface semantically similar items when wording differs. Filters protect hard requirements such as availability, region, permissions or product class. A practical system can combine these paths instead of declaring one method universally superior. Hybrid retrieval is valuable because buyers use both exact identifiers and imprecise descriptions.

Each path needs tests. Exact-code queries should not be diluted by vaguely related semantic matches. Natural-language problem queries should not return nothing simply because the catalogue uses a different phrase. Filters must not remove every candidate through missing data. Build a query set from real support, sales and site-search language, then record which retrieval path finds the expected candidates. This becomes a regression suite when models, schemas or synonym rules change.

The website equivalent is a coverage map

A public search engine also needs a page that can plausibly answer the query. On a website, retrieval readiness begins with information architecture, crawlable links, indexable content and a clear canonical URL. If a manufacturer lists products only inside a PDF, hides essential variants behind a script, or collapses several distinct uses into one generic page, the available candidate set is weak before content quality is considered.

Map the buying journey to page roles. A category page helps exploration. A product page resolves specifications and fit. A use-case page connects a problem to suitable products. A location page proves service in a real market. A comparison page helps a buyer choose. These pages should link in both directions where the relationship is useful. The goal is not maximum page count. It is a candidate set that represents the decisions the business can support with distinct evidence.

Reranking is where richer evidence earns attention

Once plausible candidates exist, a richer evaluation can consider field match, freshness, popularity, product attributes, behavioural signals or a learned model. In commercial content, the comparable work is strengthening the pages that already match valuable decisions. Add original specifications, implementation detail, public proof, comparison logic, delivery boundaries and a next step that fits the buyer's stage. These elements help a strong candidate become a better answer.

Do not apply the same evidence pattern everywhere. A technical buyer may need dimensions and compatibility tables. A procurement lead may need certifications, warranty and supply terms. A local service buyer may need coverage, response process and proof from the region. Reranking reminds us that relevance is conditional on the query. The page should make its intended decision explicit enough that people and systems can distinguish it from neighbouring candidates.

Diagnose in the order the system operates

When a journey underperforms, ask four questions in sequence. Does a suitable page exist? Can crawlers and visitors reach it through stable links? Does its visible language and structure make it a plausible match? Does it provide enough evidence and a useful action to win the decision? This order separates structural absence from weak relevance and weak conversion. It also assigns work to the right discipline.

The resulting roadmap is easier to govern. Engineering fixes access and rendering. Information architecture fills missing page roles and removes duplication. Editorial work improves specificity and evidence. UX work clarifies comparison and action. Analytics connects each page to meaningful progress. Candidate retrieval and reranking may sound like search-engine internals, but their practical lesson is simple: solve eligibility before preference, then spend the deepest effort where it can change a real outcome.