/enterprise-search

name: enterprise-search
description: "Enterprise search: relevance tuning, query understanding, index management, search quality, ranking optimization, schema design."
agent: opensearch-elasticsearch-engineer
routing:
  triggers:
    - "enterprise search"
    - "search relevance"
    - "ranking"
    - "inverted index"
    - "query understanding"
    - "BM25"
    - "nDCG"
    - "search quality"
    - "OpenSearch"
    - "Elasticsearch"
    - "vector search"
    - "hybrid search"
    - "Solr"
    - "Vespa"
    - "Typesense"
    - "analyzer chain"
    - "search tuning"
    - "learned ranking"
    - "LTR"
    - "query DSL"
  category: engineering
  force_route: false
  pairs_with: []
user-invocable: true  # justification: user works in enterprise search; direct invocation for domain-specific work

Enterprise Search Engineering

Search infrastructure design, relevance tuning, query understanding, index management, quality measurement, and performance optimization. Each mode loads its own reference files on demand.

---

Mode Detection

Classify into one mode before proceeding.

| Mode | Signal Phrases | Reference | |------|---------------|-----------| | **RELEVANCE** | tune relevance, BM25, boost, function score, field weight, LTR, learned ranking, ranking model | `references/relevance-tuning.md` | | **QUERY** | query understanding, intent classification, entity extraction, query expansion, synonyms, spell correction, query rewriting | `references/query-understanding.md` | | **INDEX** | schema design, mapping, analyzer chain, reindex, alias, ILM, index template, field type | `references/index-management.md` | | **QUALITY** | nDCG, MRR, precision, recall, search quality, judgment, A/B test, evaluation, search funnel | `references/search-quality.md` | | **PERFORMANCE** | slow query, shard, cache, circuit breaker, scroll, search_after, query optimization, latency | `references/performance-optimization.md` | | **ARCHITECTURE** | search architecture, hybrid search, vector search, pipeline design, platform selection, migration | (cross-reference: load relevant references based on sub-topic) |

If the request spans modes, pick the primary and note the secondary. ARCHITECTURE mode loads references from whichever sub-topics apply.

---

Workflow by Mode

RELEVANCE Mode

**Load**: `references/relevance-tuning.md`, `references/llm-search-failure-modes.md`

1. **Diagnose** — Identify the relevance problem before tuning.

| Problem Class | Symptoms | Starting Point | |--------------|----------|----------------| | Poor precision | Good results buried under noise | Field boosting, minimum_should_match | | Poor recall | Known-good results missing | Analyzer tuning, query expansion, synonym filters | | Wrong ordering | Right results, wrong rank | BM25 parameter tuning, function scoring | | Domain mismatch | Generic scoring fails domain | Learned ranking (LTR), custom similarity | | Freshness | Stale results ranked too high | Decay functions, recency boosts |

2. **Baseline** — Capture current relevance metrics before making changes. Minimum: nDCG@10, P@5, MRR on a representative judgment set. No tuning without a baseline.

3. **Tune** — Apply changes from the reference. One variable at a time. Measure after each change.

| Tuning Layer | Tools | When to Use | |-------------|-------|-------------| | Analyzer chain | Tokenizers, filters, char_filters | Recall problems, morphological mismatch | | Field boosting | Multi-match boosts, cross_fields | Some fields matter more than others | | BM25 parameters | k1, b per field | Content-type-specific term saturation | | Function scoring | Decay, field_value_factor, script_score | Non-textual relevance signals (popularity, freshness, authority) | | Rescoring | rescore query with window_size | Expensive scoring on top-N candidates | | Learned ranking (LTR) | Feature engineering, model training, SLTR plugin | BM25 + hand-tuned boosts plateau |

4. **Validate** — Compare against baseline. Accept only statistically significant improvements. Check for regression on other query classes.

**Gate**: Baseline metrics captured. Each tuning change measured independently. No "tuned several things and it got better" — isolate the effect.

QUERY Mode

**Load**: `references/query-understanding.md`, `references/llm-search-failure-modes.md`

1. **Classify query intent** — Determine what the user wants before constructing the query.

| Intent | Example | Query Strategy | |--------|---------|---------------| | Navigational | "OpenSearch documentation" | Exact match, title boost, URL matching | | Informational | "how to configure sharding" | Full-text across body fields, snippet extraction | | Transactional | "buy enterprise license" | Product/SKU fields, availability filters | | Faceted | "red shoes size 10" | Structured filters + text scoring | | Exploratory | "machine learning applications" | Broad match, diversified results, related terms |

2. **Extract entities** — People, products, dates, categories, attributes from the query string.

3. **Transform** — Apply query expansion, spelling correction, synonym injection, and relaxation strategies from the reference.

4. **Construct** — Build the platform-specific query DSL. Include:

• `bool` query structure (must/should/filter/must_not)
• Field selection and boosting
• Filters vs scoring clauses (filters for hard constraints, scoring for ranking signals)
• Aggregations for facets

5. **Test** — Validate against known queries. Check that transformations improve recall without destroying precision.

**Gate**: Query pipeline handles the 5 intent types. Entity extraction covers the domain vocabulary. Expansion and relaxation strategies are measurable.

INDEX Mode

**Load**: `references/index-management.md`, `references/llm-search-failure-modes.md`

1. **Requirements** — Gather before designing.

| Question | Why It Matters | |----------|---------------| | Document count and growth rate | Shard count, ILM