enterprise-search

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.

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.

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.

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.

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.

2. Design schema — Map fields with appropriate types. Use the reference for type selection guidance.

3. Configure analyzers — Build analyzer chains for each text field. Standard analyzer is a starting point, not a solution.

4. Template and alias — Set up index templates for consistent creation. Use aliases for zero-downtime operations.

5. Reindex strategy — Plan for schema evolution. Reindexing is inevitable; design for it.

Gate: Schema covers all query-time field requirements. Analyzer chains tested against representative content. Alias strategy supports zero-downtime reindexing.

QUALITY Mode

Load: references/search-quality.md, references/llm-search-failure-modes.md

1. Define metrics — Select metrics appropriate to the use case.

2. Collect judgments — Build the ground truth dataset.

3. Evaluate — Run offline evaluation. Compare configurations. Report metrics with confidence intervals.

4. Online testing — A/B test or interleave changes against production. Measure engagement metrics alongside relevance metrics.

5. Monitor — Continuous quality dashboards. Alerting on metric degradation. Search funnel analysis (query -> click -> conversion).

Gate: Judgment set exists with documented guidelines. Offline metrics computed with confidence intervals. Online test plan specifies primary metric, minimum detectable effect, and sample size.

PERFORMANCE Mode

Load: references/performance-optimization.md, references/llm-search-failure-modes.md

1. Profile — Identify the bottleneck before optimizing.

2. Diagnose — Use platform diagnostics to confirm the cause. Measure before changing.

3. Optimize — Apply targeted fixes from the reference. One change at a time, measure the effect.

4. Validate — Load test the change. Check that optimization does not degrade other metrics (latency vs throughput tradeoff, cache hit rate vs memory).

Gate: Bottleneck identified with evidence. Fix targeted at root cause. Load test confirms improvement without regression.

ARCHITECTURE Mode

Cross-cutting mode. Load references based on the specific question.

1. Platform evaluation — When selecting or migrating between platforms.

2. Hybrid search design — When combining keyword and vector retrieval.

3. Pipeline design — Ingestion, enrichment, indexing, query, ranking pipelines.

4. Migration planning — Version upgrades, platform changes, zero-downtime strategies.

LLM Failure Modes in Search Engineering

Load references/llm-search-failure-modes.md for all modes. These are the specific ways LLMs fail at search tasks:

Platform-Specific Conventions

When generating configuration or queries, always specify the target platform and version.

Cross-platform traps:

• OpenSearch _search API is largely ES 7.10-compatible, but diverges on security, ML, and alerting APIs
• Elasticsearch _field_caps behavior changed between 7.x and 8.x
• Solr edismax and ES multi_match are similar in concept but differ in syntax, defaults, and tie-breaking
• Vespa ranking expressions are not Lucene scoring — different mental model entirely

Output Conventions

• Markdown with clear headers. Scannable by engineers.
• All query DSL in fenced code blocks with platform and version annotation: ````json // OpenSearch 2.x```
• Tables for parameter comparisons, metric results, configuration options.
• Every recommendation includes: what to change, why, expected effect, how to measure.
• Configuration snippets are copy-pasteable with comments explaining each value.

Reference Loading Table