Weaviate sets hybrid alpha per query, not per collection — how do you manage that?

## The design decision you are inheriting In Weaviate, the hybrid blend is a **query-time** concern. `alpha`, `fusion_type` and `query_properties` are all arguments to the `hybrid()` call, not properties of the collection. Nothing on the schema says "this collection is searched at alpha 0.4". The upside is real: one collection can serve an identifier-lookup path and a natural-language question path with different blends and no duplication of data. The downside is equally real: the ranking policy is not stored anywhere the database can show you, so it is only as coherent as your codebase. ## The drift failure mode What happens without deliberate ownership is predictable. A first feature calls `hybrid(query, alpha=0.7)` because that was the example. A second team hits a bad result, tries `alpha=0.3`, and it fixes their case. A third path never passes alpha at all and rides the client default. Six months later the same collection is being searched three different ways, a change to "the search behaviour" has no single place to make it, and nobody can answer whether a reported regression came from a data change or a parameter someone edited. Add fusion strategy and per-property boosts and the state space multiplies. The insight is that these arguments look like tuning parameters but behave like **product configuration**: they determine what users see, they are changed in response to user feedback, and they need to be auditable. ## What good ownership looks like **One retrieval layer.** Every hybrid call goes through a single component with a narrow interface — a query, a purpose, and filters. That component decides alpha, fusion type and property weighting. Call sites do not get to pass a raw alpha, because the moment they can, they will. **Configuration, not literals.** Hold the parameters in configuration or a flag system so they can be changed and rolled back without a deploy of every consumer. This matters more than usual here because the correct value is empirical: you will change it after seeing production traffic, possibly several times, and possibly per environment while you tune. **Route by query class.** A single global alpha is a compromise that serves neither tail. Classify the query cheaply — length, presence of identifier-shaped tokens, quoting, whether it parses as a question — and map each class to its own alpha. Token-heavy lookups want the keyword half to dominate; conversational queries want the vector half. Since alpha is per-request, this costs nothing at the database and needs no schema change. **Explicit fusion.** Do not inherit the server's default fusion strategy implicitly. The default is a property of the Weaviate version, so a cluster upgrade can change your ranking with no change on your side — a genuinely nasty incident to diagnose. Pass `fusion_type` and treat a change to it as a ranking change with its own evaluation. ## Validation, not intuition A hybrid parameter change almost always trades one query class against another; raising alpha rescues paraphrase queries and quietly hurts exact lookups. So the deliverable that makes tuning safe is an **evaluation set**: a modest set of real queries per class with known-good results, scored on ranking metrics, re-run on every parameter change. Pair it with online measurement — click-through or answer-acceptance rates segmented by query class, since an aggregate metric hides a class-level regression. What you must not build is a threshold. Fused scores have no stable meaning across alpha values, fusion strategies or result-set sizes, so any downstream logic of the form "drop results below X" becomes a hidden coupling to a parameter you intend to keep tuning. If you need a cutoff, express it relative to the top result inside a single response, or control quality by the number of results you request. ## Where the limits are Be honest that some problems are not alpha problems. If a property is not searchable, or its tokenization does not match how users type, no blend value recovers it — that is a schema and ingest fix with a reindex behind it. Likewise, if the semantic half needs to weigh titles more heavily, that is a decision about what text is vectorized at ingest, not something a query-time argument can reach. Part of owning the policy is knowing which requests to route to a config change and which to route to a data migration.