agentleFS
patonkikhpatonkikh/APES/skills/rag/hybrid-search-advisor/skill.md

hybrid-search-advisor

Skill3 starsChanged 4 months agoMITView on GitHub

Design hybrid search strategy combining dense vector retrieval and sparse keyword search (BM25) with fusion ranking. Use when working on RAG pipelines, chunking, embeddings, retrieval, or hybrid search.

The file

We split this skill into the rules it gives an agent

3 rules. About 0 are common, 3 are distinctive, and 0 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈3

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    If none apply, document why dense-only is sufficient.

    line 33
  2. Distinctive:

    Start with RRF (no weight tuning needed).

    line 112
  3. Distinctive:

    Use query classification only when eval shows benefit.

    line 113

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
skill.md

Hybrid Search Advisor

Purpose

Design hybrid search strategy combining dense vector retrieval and sparse keyword search (BM25) with fusion ranking.

Input: Query patterns, retrieval failure analysis, corpus characteristics
Output: Hybrid search specification with fusion method, weights, and evaluation plan Examples: See examples.md for worked input/output.


Workflow

Step 1: Assess hybrid search need

Indicators for hybrid:

  • Exact match queries (IDs, codes, names)
  • Technical vocabulary not in embedding training
  • Low recall on keyword-specific queries in failure analysis
  • Mixed query types (semantic + exact)

If none apply, document why dense-only is sufficient.

Step 2: Design dual retrieval paths

PathMethodIndexStrength
DenseVector similarityVector DBSemantic
SparseBM25 / TF-IDFInverted indexExact match

Step 3: Select fusion strategy

MethodHowWhen
Reciprocal Rank Fusion (RRF)Rank-based mergeDefault, robust
Weighted sumScore normalization + weightsCalibrated scores
CascadeSparse filter → dense rerankLarge corpus
Learned fusionML rankerSufficient training data

Recommend with rationale.

Step 4: Tune weights

Query typeDense weightSparse weight
Semantic0.80.2
Exact match0.20.8
Mixed0.50.5

Define query classifier or use RRF without weights.

Step 5: Plan evaluation

Compare on golden set:

  • Dense-only vs sparse-only vs hybrid
  • Metrics: recall@k, MRR, latency

Step 6: Validate

Run Validation checklist.


Decision Rules

ConditionAction
All queries semanticHybrid may be unnecessary; document decision
Exact match failures > 20%Recommend hybrid with RRF
Latency budget tightConsider cascade over parallel dual search
No sparse index existsPlan BM25 index alongside vector index
Small corpus (<1000 chunks)Sparse-only may suffice; compare before hybrid

Validation

  • Hybrid need assessment documented
  • Both retrieval paths specified
  • Fusion method selected with rationale
  • Weight or RRF strategy defined
  • Eval plan comparing dense/sparse/hybrid
  • Latency impact of dual search estimated
  • Query type routing rules if applicable

Anti-patterns

  • Hybrid by default — adding BM25 without failure evidence.
  • Unnormalized fusion — combining incomparable score scales naively.
  • Double latency — parallel search without timeout budget.
  • Ignoring sparse maintenance — stale keyword index.
  • Fixed weights — same weights for all query types.

Best Practices

  • Start with RRF (no weight tuning needed).
  • Use query classification only when eval shows benefit.
  • Index same chunks in both systems with shared IDs.
  • Monitor per-path contribution in production logs.
  • Align with retriever-optimizer failure analysis.

Output Structure

# Hybrid Search Strategy: [System Name]

## Need Assessment
[Why hybrid or why not]

## Architecture
```mermaid
[dense + sparse + fusion diagram]

Fusion

Method: RRF | Weighted | Cascade Config: [parameters]

Weights by Query Type

TypeDenseSparse

Evaluation Plan

ConfigRecall@5MRRLatency

Implementation Notes

[Index sync, shared IDs]


---

# Next Skills

| Outcome | Recommended Skill |
|---------|-------------------|
| Query rewriting | `rag/query-rewriter` |
| Hallucination check | `rag/hallucination-analyzer` |
| Retriever tuning | `rag/retriever-optimizer` |
| RAG evaluation | `rag/retrieval-evaluator` |

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.