Query Search Pipeline Explorer

Worked example Trace a facet

Build order

Ordered by value delivered per unit of cost, with the trigger condition that says now — not a schedule. Steps 1–7 are the Core + recommended level. Most systems should stop there and spend the remaining effort on data quality, the evaluation set, and the index, which is where the returns usually are. Click any component to open its detail.

About this explorer

What this explorer helps you learn

Follow the possibilities, dependencies and trade-offs between receiving a query and assembling a result. The explorer makes responsibilities, concrete execution boundaries and supporting data paths visible so a team can compare pipeline shapes and decide which capabilities earn a place in the request path.

Two levels, one pipeline

The tabs are complementary readings of the same search system, not alternative diagrams.

Logical architecture

Understand responsibilities, contracts and optional capabilities without committing to products or deployment geometry.

Physical architecture

See one concrete realisation using OpenSearch, Qdrant, an orchestrator, model-serving boundaries and the data path that supports them. Neither engine is the whole search system.

Start here

Choose the question you want to answer. Each guided task opens the relevant architecture, evidence and relationships in a live, shareable state that you can continue to compose and inspect.

Orient yourself

Learn the three ways to read the explorer before investigating a specific design problem.

Compare abstraction levels

Start with a responsibility, then use the drawer's Across levels action to see how it changes when realised by concrete infrastructure.

Investigate logical responsibilities

Highlight components that solve a common search problem, then use the open drawer to understand the key decision and trade-offs.

Investigate physical operation

Expose the infrastructure paths behind latency, consistency and evaluation, then inspect the component that coordinates each concern.

How to use it well

Use the explorer as a repeatable design conversation, then test its hypotheses against your own queries, corpus, relevance judgements and production constraints.

Understand responsibility

Start at the logical Core level to learn the minimum end-to-end path and the responsibility of each component.

Compose and trace

Switch optional components deliberately and trace a worked-query facet through extraction, retrieval, scoring, policy and presentation.

Inspect the contract

Open a component to examine its decisions, inputs, outputs, trade-offs and failure modes in the current composition.

Cross abstraction levels

Follow the component link to its physical realisation. OpenSearch and Qdrant are the concrete example here; the logical and physical views explain different parts of the same pipeline.

Let evidence unlock complexity

Use Build order to discuss prerequisites and evidence, not as a schedule. Component links and shared URLs preserve the specific learning context for the next conversation.

Interpretation guardrail. The logical view is product architecture and the physical view is a technology-realised search execution, not a vendor recommendation, complete deployment topology, ingestion or index-building pipeline, capacity model, or performance predictor. One service may host several logical indexes. Component complexity labels are comparative prompts; benchmark the selected design against your own traffic, index, hardware, models, and quality targets.