A search service may have billions of documents, but a sophisticated ranking model need not inspect every one. A processing cascade narrows the work in stages: cheap decisions reduce the candidate set before more expensive decisions refine the results. section 3.3
A photo search cascade can proceed in three steps:
- Apply optional filters, such as price, collection, resolution, or author. section 13.5.2
- Fetch nearest neighbors of the query in embedding space. section 13.5.2
- Sort the remaining photos by relevance with a final model. section 13.5.2
Stages can be added when an earlier, inexpensive decision reduces downstream work. For example, query language and user location can exclude documents in other languages before candidate retrieval. The key tradeoff is where to place each operation: broad, fast filtering runs first; sophisticated ranking runs on a smaller set. section 3.3
For an internal search service, keep the stages behind a clear API. The vector database filters and fetches candidates, the model API produces embeddings and scores, and the ranking API sorts results and applies overrides. A proposed vector database such as Qdrant still needs testing before production use if it is unfamiliar to the organization. section 13.5.2
``` GET /search?query=<query_string>&filters=<filters>&version=<version> &limit=<limit>&request_id=<request_id> ```
The search request shows how a query, optional filters, result limit, version, and request ID enter the cascade through one internal endpoint. section 13.5.2
