SEARCH / RETRIEVAL REVIEW
Hybrid search over network observations
Atheros Search combines term and vector results with weighted reciprocal-rank fusion. This example follows the same records through both rankings and calculates their fused scores. It includes no measured accuracy or latency comparison.
Fix the query and scope before comparing modes
Use the same dataset, source kinds, site filter, observation interval and result budget for each mode. This synthetic text collection illustrates candidate ranking. It is not an ingested sensor payload or an actual embedding run.
Query: wireless deauthentication
Site: lab-west
Observation interval: 2026-10-08 10:00-10:10 UTC
Result budget: 3
Compare: sparse, dense, hybridConceptual inputs, not a literal request body. A real comparison must preserve the same service filters and record collection.
| Record | Observation summary |
|---|---|
| A | Deauthentication frames observed on channel 6 |
| B | Management frames coincide with a reported wireless interruption |
| C | AP maintenance note mentions deauthentication during review |
Keep term and vector evidence separate
Sparse retrieval uses PostgreSQL full-text term matching. Dense retrieval compares query embeddings with stored embeddings for the configured model. Hybrid retrieval merges their candidate lists by source key rather than adding incomparable raw keyword and cosine scores.
| Record | Sparse rank | Dense rank | Review interpretation |
|---|---|---|---|
| A | 1 | 2 | Appears in both candidate lists |
| B | Not returned | 1 | Semantic candidate in the assigned example |
| C | 2 | Not returned | Term candidate in the assigned example |
- Missing from a returned candidate list does not mean the record is absent from the dataset.
- Dense retrieval depends on embedding availability and model coverage. Keep processing health and coverage with a real evaluation.
- Do not label these assigned ranks as a benchmark. Measured relevance needs independently judged queries and captured results.
Calculate an explainable fusion stage
The implementation uses k = 60. A dense candidate contributes alpha / (60 + rank). A sparse candidate contributes (1 - alpha) / (60 + rank). For the example alpha = 0.5, the record appearing in both lists accumulates both contributions. These values are arithmetic outputs for the assigned ranks, not service measurements.
A = 0.5 / (60 + 2) + 0.5 / (60 + 1) = 0.016261
B = 0.5 / (60 + 1) = 0.008197
C = 0.5 / (60 + 2) = 0.008065
Fusion order: A, B, CValues are rounded to six decimals. This illustrates the fusion stage, not an incident confidence score.
- Candidates are deduplicated by source key. Equal final scores use source-key ordering as the tie-break.
- Changing alpha changes the relative weight of the two ranked lists. It does not calibrate the result into a probability.
- Retain the selected record and the original result envelope when explaining a real result. A later search can observe a changed collection or embedding state.
Read the available explanation and actual mode used
A scoped explanation resolves the selected record within the supplied scope and computes its sparse score directly. It does not invent dense or fusion ranks that are unavailable. Preserve dense and fusion information from the original response when it exists.
- Check mode_used, fallback_code and the returned candidate counts. A request for hybrid search can return sparse results when the embedding leg is unavailable or lacks coverage.
- A fallback reason explains retrieval availability, not the truth of an observation. Do not describe a sparse fallback result as successful semantic retrieval.
- Open the source record to review time, site, identifiers and decoded evidence. Relevance alone does not establish a current connection or physical device identity.
- For a real evaluation, record dataset version, model, filters, queries, judgments, returned ranks and fallback state before discussing measured quality.
Source code
The implementation behind the examples. Examples are educational inputs, not production records or measured results.
- Weighted reciprocal-rank fusion
Rank weighting, source-key deduplication and deterministic tie-breaking.
- Fusion constant and raw result fields
The implementation sets rrfK to 60.
- Search orchestration and fallback
Requested and actual modes, candidate counts and semantic fallback behavior.
- Scoped record explanation
Direct sparse-score explanation preserves the selected record and scope.