Hybrid search tuning
How filters, rerank, and top_k trade off relevance against latency and cost.
/v1/search is a hybrid dense+sparse retrieval with an optional rerank pass — the defaults are reasonable for most queries, but three parameters are worth understanding before tuning them.
filters narrows before ranking, not after
filters.doc_type, filters.jurisdiction, filters.year_from/year_to, and filters.status are applied as Qdrant payload conditions during retrieval, not as a post-hoc filter on results. Use them whenever you know the answer's shape in advance (e.g. "only in-force legislation") — it's strictly better than retrieving broadly and filtering client-side, since it lets the full top_k budget go to documents that could actually match.
rerank costs latency, buys precision
With rerank: true (the default), the reranker scores 4 × top_k candidates with a cross-encoder before returning the top top_k — noticeably more accurate ordering than raw hybrid-fusion scores alone, at the cost of an extra model call. If you're building an autocomplete-style experience where latency matters more than perfect ordering, consider rerank: false; for anything the answer quality of /v1/reason depends on, leave it on (reason always reranks internally regardless of what you'd pass to search).
top_k vs. include_text
Raising top_k doesn't just return more results — with include_text: true (the default) it also means more 800-char snippets in the payload. If you're doing your own downstream reranking or just need IDs to feed into /v1/graph/traverse, set include_text: false to cut response size without changing retrieval behavior at all.
Reading fusion in the response
fusion: "rrf" means both dense and sparse vectors contributed to ranking; fusion: "dense" means the query fell back to dense-only (typically because the sparse/lexical side had nothing to match — very short or purely conceptual queries). This is informational, not something you control directly, but it's useful for debugging an unexpectedly ranked result.