---
Title: Run search
URL Source: https://company-skill.com/p/es/es-run-search
Language: en
Description: You want to evaluate two or more search ranking strategies by splitting live traffic and measuring performance differences. This involves defining A/B test scenes with distinct values (e.g.,…
---

# Run search

Part of **Elasticsearch**. Route queries via `POST https://company-skill.com/api/route`.

## What You Want to Do

You want to evaluate two or more search ranking strategies by splitting live traffic and measuring performance differences. This involves defining **A/B test scenes** with distinct **values** (e.g., different ranking parameters) and managing their **status** (active/inactive).

**Typical User Questions**:
- How do I compare two relevance configurations?
- Can I run A/B tests on my Elasticsearch ranking models?

## Decision Tree

Pick the best path for your situation:

- **If** you are using **standard Elasticsearch instances** (not OpenSearch ) → Use API A/B (go to *es/es-ab-test*)
- **If** you need to combine A/B testing with **neural rerankers** like `ops-bge-reranker-larger`, `ops-qwen3-reranker-0.6b`, or `ops-mm-reranker-001` → Use Relevance API A/B (go to *es/es-search-relevance*)
- **If** your experiment requires **query processors**, **intervention dictionary**, or **fine sort** logic tightly coupled with variant definition → Use Relevance API A/B (go to *es/es-search-relevance*)
- **Otherwise (default)** → Use API A/B — it’s simpler and sufficient for basic scene management without advanced relevance features.

## Path Comparison

| Path | Best For | Complexity | Code Required | Automation | Key Fact | Detail Skill |
|------|----------|------------|---------------|------------|----------|-------------|
| API A/B | medium | Yes | Yes | Uses endpoint `api/v1/abtest/scenes` with Bearer Token auth | `es/api/es-ab-test` |
| Relevance API A/B | high | Yes | Yes | Requires OpenSearch ; supports `AB test group` and `AB test scene` with neural rerankers | `es/api/es-search-relevance` |

## Path Details

### Path 1: API A/B 

**Brief Description**: This approach uses the Elasticsearch A/B Testing API, a synchronous HTTP service that lets you create and manage **A/B test scene** definitions via POST requests to `api/v1/abtest/scenes`. Each scene includes **values** (the experimental variants) and a **status** field to control activation. Authentication uses **Bearer Token** with the **DASHSCOPE_API_KEY** environment variable.

**Key technical facts**:
- Billing: per-request model
- Regions: cn-hangzhou, cn-shanghai, cn-beijing
- Auth: Bearer Token authentication

**When to Use**:
- Need to programmatically create multiple **A/B test scene** entries via REST
- Integrating with an existing internal experimentation platform
- Only require basic variant definition without neural reranking or query processing

**When NOT to Use**:
- Need to define test variants **during** document reranking (use Relevance API instead)
- Require end-to-end relevance experiments involving **fine sort** or **intervention dictionary**

**Known Limitations**:
- Cannot update an existing **A/B test scene** — must delete and recreate
- No documented limit on number of **values** per scene; system capacity may impose implicit bounds
- Only supports synchronous request-response; no async or streaming

### Path 2: Relevance API A/B 

**Brief Description**: The Elasticsearch Relevance Optimization API enables full lifecycle management of **AB test group** and **AB test scene** entities while supporting advanced features like neural reranking with models such as `ops-bge-reranker-larger`, `ops-qwen3-reranker-0.6b`, and `ops-mm-reranker-001`. It also integrates **query processors**, **intervention dictionary**, and **fine sort** configuration into the experiment workflow. Requests are sent to `opensearch.{region}.aliyuncs.com` using **Bearer Token** auth with **DASHSCOPE_API_KEY**.

**Key technical facts**:
- Billing: Per-request billing for all operations
- Regions: cn-hangzhou, cn-shanghai, cn-beijing
- Auth: Bearer Token authentication
- Prerequisites: AI Search Open Platform or OpenSearch ; alibabacloud_searchplat20240529 SDK

**When to Use**:
- Running A/B tests that include **neural rerankers** (`ops-bge-reranker-larger`, etc.)
- Building end-to-end relevance pipelines combining **query processors**, **intervention dictionary**, and **fine sort**
- Need to define variants contextually during the reranking phase

**When NOT to Use**:
- Using standard Elasticsearch instances (this path **only works on OpenSearch **)
- Only need to create static **A/B test scene** definitions without any reranking logic

**Known Limitations**:
- Not compatible with standard Elasticsearch — requires **OpenSearch **
- Rerank APIs have a shared 20 QPS rate limit; high-concurrency scenarios need retry logic
- Request body capped at 8 MB; multimodal reranking limited to 100 documents per call

## FAQ

Q: Which path should I start with?
A: Start with ** API A/B ** unless you’re using OpenSearch and need neural reranking, **fine sort**, or **query processors** — then use the Relevance API.

Q: What if I’m using a standard Elasticsearch cluster but chose the Relevance API path?
A: You’ll hit a compatibility error — the Relevance API **only works on AI Search Open Platform or OpenSearch **, not standard Elasticsearch instances.

Q: What if I need to test a `ops-mm-reranker-001` model but used the basic A/B test API?
A: You won’t be able to associate the reranker with your **A/B test scene** — the basic API doesn’t support embedding neural models or **intervention dictionary** logic into variants.

Q: Can I update an active A/B test scene after creation?
A: With the basic API, **no** — documentation implies you must delete and recreate the scene. The Relevance API may offer more flexibility, but check its detail skill.

Q: Are there payload size limits I should know about?
A: Yes — the Relevance API enforces an **8 MB request limit** and caps multimodal reranking at **100 documents**. The basic API has no documented size limit, but large payloads may time out.

Q: Do both paths use the same authentication?
A: Yes — both require **DASHSCOPE_API_KEY** and **Bearer Token** authentication against endpoints like `elasticsearch.{region}.aliyuncs.com` (basic) or `opensearch.{region}.aliyuncs.com` (Relevance).

Q: Can I define traffic splits (e.g., 90/10) in both paths?
A: The fact cards don’t specify traffic allocation mechanics — this detail is likely handled in the **values** parameter or downstream routing. Consult the respective detail skills for split configuration.

## Related queries

run ab test for search, ab test search ranking, compare relevance configurations, create search experiment, a/b test traffic splitting, how to ab test elasticsearch, can i run ab tests on ranking models, search algorithm ab testing, elasticsearch relevance experiment, ab test scene creation, define

---
Part of [Elasticsearch](https://company-skill.com/p/es.md) · https://company-skill.com/llms.txt