Skip to main content

Adaptive hybrid search

HLQuery reserves an opt-in master gate for adaptive hybrid ranking. In the current Phase 1 implementation, the gate is parsed and discoverable but adaptive ranking is not implemented or executed. All searches continue through the legacy lexical, vector, and hybrid pipeline.

The operational controls live directly in run/conf/hlquery.conf:

<adaptive_search
     enabled="false"
     execution_trace="false"
     include_query_text="false"
     allow_request_disable="true"
     expose_capabilities="true">
  • enabled is the future adaptive-ranking hard-off switch. Its default is false.
  • execution_trace enables the optional ordered trace on standard document search responses.
  • include_query_text is the server-side privacy gate. A request cannot override false.
  • allow_request_disable lets a request suppress trace output with include_search_execution=false.
  • expose_capabilities controls the non-sensitive /etc?include=search_capabilities section.

The request field include_search_query_text=true includes source query text only when both tracing and the server privacy gate are enabled. Raw vectors, generated embeddings, API keys, authorization headers, embedded security filters, credentials, and document contents are never trace fields.

adaptive_search.enabled=true does not select a new ranking algorithm in Phase

  1. Capability discovery reports adaptive ranking as unavailable until a real planner and fusion implementation ship. Existing hybrid_alpha, dynamic_alpha, normalization, linear/RRF merge, rerank, filtering, sorting, grouping, module weighting, and pagination behavior remain unchanged.

Vector retrieval currently uses exact brute-force scanning. HNSW and IVF parameters do not represent available execution backends.

Trace output is currently supported by the standard /collections/{collection}/documents/search handler. Dedicated vector search, global search, and multi-search retain their existing response shapes in this phase.