Query rewriting - Lucidworks documentation

Query rewriting is a strategy for improving relevancy using AI-generated data. Many of Managed Fusion’s features can be used to rewrite incoming queries prior to submitting them to Managed Fusion’s Solr core. These rewrites produce more relevant search results with higher conversion rates. For example, when spelling corrections are used for query rewriting, a misspelled query can return the same search results as a correctly-spelled query, instead of returning irrelevant results or no results. Spelling corrections are one of several available query rewriting strategies. Apply all available strategies for best results. See also the Query Rewriting API. Managed Fusion can also rewrite Solr’s responses before returning them to the search application; see Response Rewriting.

Query rewriting strategies

Managed Fusion provides a variety of query rewriting strategies to improve relevancy:

Business rules
Underperforming query rewriting
Misspelling detection
Phrase detection
Synonym detection
Remove Words

With the exception of business rules, which are always manually created, these strategies correspond to certain Spark jobs. Lucidworks recommends configuring and scheduling all of these jobs for best results. You can also train the jobs by manually adding documents to their output. Manually-added documents are used for machine learning and are never overwritten by new job output. Query rewriting strategies are applied in the following order:

Business rules - If a query triggers a business rule, then the business rule overrides any query rewriting strategies that conflict with it.
Query rewrites
1. Underperforming query rewriting - If a query triggers an underperforming query rewrite, then this strategy overrides all subsequent query rewriting strategies.
2. Remove words - To help increase the number of results returned, Remove Words query rewrites removes words from the users’ search.
Synonym detection
Misspelling detection and phrase detection - The query rewriting results from both of these strategies are applied together. To use only the strategy with the longest surface form, you can configure the Text Tagger query stage with Overlapping Tag Policy set to “LONGEST_DOMINANT_RIGHT”.

Business rules

Business rules are manually-created formulas for rewriting queries. This is the most versatile strategy for creating custom query rewrites. It supports a variety of conditions and actions to address a wide range of use cases. When you need a very specific query rewrite, this is the best strategy. Business rules are applied in the Apply Rules stage of the query pipeline. See Business Rules to learn how to create, edit, and publish business rules.

Underperforming query rewriting

Head/tail analysis is:

Also known as the Underperforming Query Rewriting feature
Uses signals data to identify underperforming queries
Suggests improved queries that could produce better conversion rates

When an incoming query contains a matching underperforming query, the original query is replaced by an improved query. These improvements can be:

Suggested by the Head/Tail Analysis Spark job operating on your signals data
Created manually using the Rules Editor or underlying API

Query improvements are applied in the Text Tagger stage of the query pipeline. See Head/Tail Analysis (Underperforming Query Rewriting) to learn how to review, edit, create, and publish query improvements.

Misspelling detection

The Misspelling detection feature maps misspellings to their corrected spellings. When Managed Fusion receives a query containing a known misspelling, it rewrites the query using the corrected spelling in order to return relevant results instead of an empty or irrelevant results set. Spelling corrections are applied in the Text Tagger stage of the query pipeline.

Misspelled terms are completely replaced by their corrected terms. If you want to expand the query to include all alternative terms, set the synonyms to bi-directional. See Synonym Detection for more information.

See:

Misspelling Detection for general information
Use Misspelling Detection for information about how to review, edit, create, and publish spelling corrections

Use Misspelling Detection

LucidAcademyLucidworks offers free training to help you get started.The Course for Query Analytics focuses on how Fusion provides query analytics to detect and improve underperforming queries:

Visit the LucidAcademy to see the full training catalog.

Reviewing auto-generated spelling corrections

Spelling corrections that are automatically generated by the Token and Phrase Spell Correction job are assigned one of the following status values:

Auto There are three values for confidence level:
Value Confidence Label
0 low confidence Pending
0.5 median confidence Auto
1 high confidence Auto

No action is required on these results, but you can edit them if you wish.
Pending The confidence level is ambiguous, and the result must be reviewed by a user before it can be deployed. It will only be moved from the _query_rewrite_staging collection to the _query_rewrite collection when its status has changed to “Approved” and it has been published.

Value	Confidence	Label
0	low confidence	Pending
0.5	median confidence	Auto
1	high confidence	Auto

Navigate to Relevance > Rules > Rewrite.
Select Misspelling tab. The application displays the Misspelling Detection screen.
Notice the Status facet on the left. Click Pending to view only the items that need review.
Click the icon next to the spelling correction.
In the Status column, select either “Approved” or “Denied”. Optionally, you can also edit the spelling correction itself.

Adding new spelling corrections

You can manually add spelling corrections in addition to any generated by the Fusion 5.x.x Token and Phrase Spell Correction job release.

Navigate to Relevance > Rules > Rewrite.
Select Misspelling tab. The application displays the Misspelling Detection screen.
At the bottom of the rules list, click the icon. A new spelling correction appears at the top of the list:
Enter the misspelled word or phrase.
Enter one or more spelling corrections.
It is not necessary to set a confidence value.
Select the spelling correction’s status, depending on whether you want to deploy it the next time you publish your changes (“Approved”) or save it for further review (“Pending”).
Click the check mark to save the new spelling correction:

Publishing your changes

How to publish updated spelling corrections

In the Misspelling Detection screen, click the PUBLISH button. Fusion prompts you to confirm that you want to publish your changes.
Click PUBLISH.

You can un-publish a query rewrite by changing its status to “denied”, then clicking PUBLISH.

Tuning the misspelling detection job

The default configuration for the Token and Phrase Spell Correction job, respectively, is designed for high accuracy and works well with most signal datasets, depending on the volume and quality of the signals. If you are seeing too few results, or too many inaccurate results, then you can try tuning the job to achieve better results.To modify job configurations, you must be a Fusion user with one of the following roles or permissions that include access to job configurations:

Query rewrite jobs post-processing cleanup

To perform more extensive cleanup of query rewrites, complete the procedures in Query Rewrite Jobs Post-processing Cleanup.

Phrase detection

Phrase detection identifies phrases in your signals so that results with matching phrases can be boosted. This helps compensate for queries where phrases are not distinguished with quotation marks. For example, the query ipad case is rewritten as “ipad case”~10^2, meaning if ipad and case appear within 10 terms (whitespace-delimited tokens) of each other, then boost the result by a factor of 2. Phrases are applied in the Text Tagger stage of the query pipeline. See:

Phrase Detection for general information
Use phrase detection for information about how to review, edit, create, and publish spelling corrections

Use phrase detection

Synonym detection

The Synonym Detection feature generates pairs of synonyms and pairs of similar queries. Two words are considered potential synonyms when they are used in a similar context in similar queries. A query that contains a matching term is expanded to include all of its synonyms, with the original term boosted by a factor of two. Synonyms are applied in the Text Tagger stage of the query pipeline. See:

Synonym Detection for general information
Use Synonym Detection for information about how to review, edit, create, and publish synonym corrections

Use Synonym Detection

Remove words

Use a Remove Words query rewrite to remove particular phrases from queries. Unlike other rewrites, Remove Words rules are entered manually and aren’t generated by a job. You can create a Remove Words query rewrite to remove words from a query. This query rewrite is helpful when a word in the search query does not add value to the search results. For example, you can rewrite a search query for case study examples to remove examples and then display results for case study. See Remove Words to learn how to remove words from your users’ searches.

Rules Editor

The Rules Editor allows you to view, edit, create, approve, enable, and publish rules powered by Managed Fusion. Access the Rules Editor from the Managed Fusion UI by navigating to Relevance > Rules:

Query rewrite collections

For detailed information about query rewriting, see:

Manage Collections in the Managed Fusion UI
Collections

Manage Collections in the Managed Fusion UI

For each app, two auxiliary collections are dedicated to documents used for query rewriting:

COLLECTION_NAME_query_rewrite_staging
Certain Spark jobs send their output to this collection. Rules are also written to this collection initially
Some of the content in this collection requires manual review before it can be migrated to the COLLECTION_NAME_query_rewrite, where query pipelines can read it. See below for details.
COLLECTION_NAME_query_rewrite This collection is optimized for high-volume traffic. Query pipelines can read from this collection to find rules, synonyms, spelling corrections, and more with which to rewrite queries and responses.

Each app contains exactly one of each of these collections, associated with the app’s default collection. They are not created again for additional collections created within the same app. Documents move from COLLECTION_NAME_query_rewrite_staging to the COLLECTION_NAME_query_rewrite collection only when they are approved (either automatically on the basis of their confidence scores or manually by a human reviewer) and a Managed Fusion user clicks Publish. The review field value indicates whether a document will be published when the user clicks Publish:


`review=auto`	A job-generated document has a sufficiently high confidence score and is automatically approved for publication.
`review=pending`	A job-generated document has an ambiguous confidence score and must be reviewed by a Managed Fusion user.
`review=approved`	A Managed Fusion user has reviewed the document and approved it for publication.
`review=denied`	A job-generated document has a low confidence score, or a Managed Fusion user has reviewed and denied it for publication.

In the query rewriting UI, the value of the review field appears in the Status column.

You can review and approve or deny documents using the query rewriting UI. You can also change a document’s status to “pending” to save it for later review.

Rules Simulator query profile

ImportantRules Simulator is only available for Managed Fusion organizations that do not have a valid Predictive Merchandiser or Experience Optimizer license.

The Rules Simulator allows product owners to experiment with rules and other query rewrites in the COLLECTION_NAME_query_rewrite_staging collection before deploying them to the COLLECTION_NAME_query_rewrite collection. Each app has a COLLECTION_NAME_rules_simulator query profile, configured to use the COLLECTION_NAME_query_rewrite_staging collection for query rewrites instead of the COLLECTION_NAME_query_rewrite collection. This profile is created automatically whenever a new app is created. See Configure the Rules Simulator Query Profile for more information about configuration.

Configure the Rules Simulator Query Profile

Query pipeline stages for query rewriting

These query rewriting stages are part of any default query pipeline:

Apply Rules query stage
This stage looks up rules that have been deployed to the COLLECTION_NAME_query_rewrite collection and matches them against the query. Matching rules that perform query rewriting are applied at this stage, while matching rules that perform response rewriting are applied by the Modify Response with Rules stage later in the pipeline.

To trigger a rule that contains a tag, specify the tagname in the request URL of the user search app. See Easily define triggers in tags for more information.

Text Tagger query pipeline stage
This stage uses the SolrTextTagger handler to identify known entities in the query by searching the COLLECTION_NAME_query_rewrite collection.
For Managed Fusion organizations that do not have a Predictive Merchandiser license, the Solr Text Tagger handler also searches the COLLECTION_NAME_query_rewrite_staging collection in the case of the Managed Fusion query rewriting Simulator).
The purpose of the search is to perform query rewriting using matches from the following items:

Spark jobs for query rewriting

This section describes how Spark jobs support query rewriting. These jobs read from the signals collection and write their output to the COLLECTION_NAME_query_rewrite_staging collection. High-confidence results are automatically migrated from there to the COLLECTION_NAME_query_rewrite collection, while ambiguous results remain in the staging collection until they are reviewed and approved. You can review job results in the Query Rewriting UI.

Daily query rewriting jobs are created and scheduled automatically when you create a new app.
Additional query rewriting jobs can be created manually.

For best relevancy, enable all of these jobs.

Daily query rewriting jobs

When a new app is created, the jobs below are also created and scheduled to run daily, beginning 15 minutes after app creation, in the following order:

Token and Phrase Spell Correction job
Detect misspellings in queries or documents using the numbers of occurrences of words and phrases.
Phrase Extraction job
Identify multi-word phrases in signals.
Synonym Detection
Use this job to generate pairs of synonyms and pairs of similar queries. Two words are considered potential synonyms when they are used in a similar context in similar queries.

Process flow

The first and second jobs can provide input to improve the Synonym job’s output:

Token and Phrase Spell Correction job results can be used to avoid finding mainly misspellings, or mixing synonyms with misspellings.
Phrase Extraction job results can be used to find pairs of synonyms with multiple tokens, such as “lithium ion”/“ion battery”.

The Phrase Extraction and Synonym Detection jobs are triggered by the success of the previous job: the phrase detection job runs only if the spell correction job succeeds, and the synonym job runs only if the phrase detection job succeeds.

Additional query rewriting jobs

These jobs also produce results that are used for query rewriting, but must be created manually:

Head/Tail Analysis job
Perform head/tail analysis of queries from collections of raw or aggregated signals, to identify underperforming queries and the reasons. This information is valuable for improving overall conversions, Solr configurations, auto-suggest, product catalogs, and SEO/SEM strategies, in order to improve conversion rates.
Ground Truth job
Ground truth or gold standard datasets are used in the ground truth jobs and query relevance metrics to define a specific set of documents.

Ground truth jobs estimate ground truth queries using click signals and query signals, with document relevance per query determined using a click/skip formula. Use this job along with the Ranking Metrics job to calculate relevance metrics, such as Normalized Discounted Cumulative Gain (nDCG). To create a ground truth job, sign in to Managed Fusion and click Collections > Jobs. Then click Add+ and in the Experiment Evaluation Jobs section, select Ground Truth. You can enter basic and advanced parameters to configure the job. If the field has a default value, it is populated when you click to add the job.

Basic parameters

To enter advanced parameters in the UI, click Advanced. Those parameters are described in the advanced parameters section.

Spark job ID. The unique ID for the Spark job that references this job in the API. This is the id field in the configuration file. Required field.
Input/Output Parameters. This section includes the Signals collection field, which is the Solr collection that contains click signals and its associated search log identifier. This is the signalsCollection field in the configuration file. Required field.

Advanced parameters

If you click the Advanced toggle, the following optional fields are displayed in the UI.

Spark Settings. This section lets you enter parameter name:parameter value options to use in this job. This is the sparkConfig field in the configuration file.
Additional Options. This section includes the following options:
- Search logs pipeline. The pipeline ID associated with search log entries. This is the searchLogsPipeline field in the configuration file.
- Join key (query signals). The common key that joins the query signals in the signals collection. This is the joinKeySignals field in the configuration file.
- Join key (click signals). The common key that joins the click signals in the signals collection. This is the joinKeySignals field in the configuration file.
- Search logs and options. This section lets you enter property name:property value options to when loading the search logs collection. This is the searchLogsAddOpts field in the configuration file.
- Additional signals options. This section lets you enter property name:property value options when loading the signals collection. This is the signalsAddOpts field in the configuration file.
- Filter queries. The array[string] filter query to apply when selecting top queries from the query signals in the signals collection. This is the filterQueries field in the configuration file.
- Top queries limit. The total number of queries to select for ground truth calculations when this job is run. This is the topQueriesLimit field in the configuration file.

For more information, see Ground truth query rewrite API configurations.

”rules” role for query rewriting users

The “rules” role provides permissions to access query rewriting features for all Managed Fusion apps. A Managed Fusion admin can create a user account with this role to give a business user access to the Query Rewriting UI.

Query rewrite jobs post-processing cleanup

To perform more extensive cleanup of query rewrites, complete the procedures in Query rewrite jobs post-processing cleanup.

Query rewrite jobs post-processing cleanup

The Synonym Detection job uses the output of the Misspelling Detection job and Phrase Extraction job. Therefore, post processing must occur in the order specified in this topic for the Synonym detection job cleanup, Phrase extraction job cleanup, and Misspelling detection job cleanup procedures. The Head-Tail Analysis job cleanup can occur in any order.

Synonym detection job cleanup

Use this job to remove low confidence synonyms.

Prerequisites

Complete this:

AFTER the Misspelling Detection and Phrase Extraction jobs have successfully completed.
BEFORE removing low confidence synonym suggestions generated in the post processing phrase extraction cleanup and misspelling detection cleanup procedures detailed later in this topic.

Remove low confidence synonym suggestions

Use either a Synonym cleanup method 1 - API call or the Synonym cleanup method 2 - Managed Fusion Admin UI to remove low confidence synonym suggestions.

Synonym cleanup method 1 - API call

Open the delete_lowConf_synonyms.json file.

{
    "type" : "rest-call",
    "id" : "DC_Large_QR_DELETE_LOW_CONFIDENCE_SYNONYMS",
    "callParams" : {
    "uri" : "solr://DC_Large_query_rewrite_staging/update",
    "method" : "post",
    "queryParams" : {
        "wt" : "json"
    },
    "headers" : { },
    "entity" : "<root><delete><query>type:synonym AND confidence:[0 TO 0.0005]</query></delete><commit/></root>"
    },
    "type" : "rest-call",
    "type" : "rest-call"
}

REQUEST ENTITY specifies the threshold for low confidence synonyms. Edit the upper range from 0.0005 to increase or decrease the threshold based on your data.

Enter <your query_rewrite_staging collection name/update> in the uri field. An example URI value for an app called DC_Large would be DC_Large_query_rewrite_staging/update.
Change the id field if applicable.
Specify the upper confidence level in the entity field.
The entity field specifies the threshold for low confidence synonyms. Edit the upper range to increase or decrease the threshold based on your data.

Synonym cleanup method 2 - Managed Fusion Admin UI

Log in to Managed Fusion and select Collections > Jobs.
Select Add+ > Custom and Other Jobs > REST Call.
Enter delete-low-confidence-synonyms in the ID field.
Enter <your query_rewrite_staging collection name/update> in the ENDPOINT URI field. An example URI value for an app called DC_Large would be DC_Large_query_rewrite_staging/update.
Enter POST in the CALL METHOD field.
In the QUERY PARAMETERS section, select + to add a property.
Enter wt in the Property Name field.
Enter json in the Property Value field.
In the REQUEST PROTOCOL HEADERS section, select + to add a property.
Enter the following as a REQUEST ENTITY (AS STRING) <root><delete><query>type:synonym AND confidence: [0 TO 0.0005]</query></delete><commit/></root>
REQUEST ENTITY specifies the threshold for low confidence synonyms. Edit the upper range from 0.0005 to increase or decrease the threshold based on your data.

Delete all synonym suggestions

To delete all of the synonym suggestions, enter the following in the REQUEST ENTITY section:<root><delete><query>type:synonym</query></delete><commit/></root>

This entry may be helpful when tuning the synonym detection job and testing different configuration parameters.

Phrase extraction job cleanup

Use this job to remove low confidence phrase suggestions.

Prerequisites

Complete this:

AFTER you complete Synonym detection job cleanup

Remove low confidence phrase suggestions

Use either a Phrase cleanup method 1 - API call or the Phrase cleanup method 2 - Managed Fusion Admin UI to remove low confidence phrase suggestions.

Phrase cleanup method 1 - API call

Open the delete_lowConf_phrases.json file.

    {
    "type" : "rest-call",
    "id" : "DC_Large_QR_DELETE_LOW_CONFIDENCE_PHRASES",
    "callParams" : {
        "uri" : "solr://DC_Large_query_rewrite_staging/update",
        "method" : "post",
        "queryParams" : {
        "wt" : "json"
        },
        "headers" : { },
        "entity" : " <root><delete><query>type:phrase AND confidence:[0 TO <INSERT VALUE HERE>]</query></delete><commit/></root>"
    },
    "type" : "rest-call",
    "type" : "rest-call"
    }

Enter <your query_rewrite_staging collection name/update> in the uri field. An example URI value for an app called DC_Large would be DC_Large_query_rewrite_staging/update.
Change the id field if applicable.
Specify the upper confidence level in the entity field.
The entity field specifies the threshold for low confidence phrases. Edit the upper range to increase or decrease the threshold based on your data.

Phrase cleanup method 2 - Managed Fusion Admin UI

Log in to Managed Fusion and select Collections > Jobs.
Select Add+ > Custom and Other Jobs > REST Call.
Enter remove-low-confidence-phrases in the ID field.
Enter <your query_rewrite_staging collection name/update> in the ENDPOINT URI field. An example URI value for an app called DC_Large would be DC_Large_query_rewrite_staging/update.
Enter POST in the CALL METHOD field.
In the QUERY PARAMETERS section, select + to add a property.
Enter wt in the Property Name field.
Enter json in the Property Value field.
In the REQUEST PROTOCOL HEADERS section, select + to add a property.
Enter the following as a REQUEST ENTITY (AS STRING) <root><delete><query>type:phrase AND confidence: [0 TO <insert value>]</query></delete><commit/></root>
REQUEST ENTITY specifies the threshold for low confidence phrases. Edit the upper range to increase or decrease the threshold based on your data.

Delete all phrase suggestions

To delete all of the phrase suggestions, enter the following in the REQUEST ENTITY section:<root><delete><query>type:phrase</query></delete><commit/></root>

This entry may be helpful when tuning the phrase extraction job and testing different configuration parameters.

Misspelling detection job cleanup

Use this job to remove low confidence spellings (also referred to as misspellings).

Prerequisites

Complete this:

AFTER you complete Synonym detection job cleanup and Phrase extraction job cleanup

Remove misspelling suggestions

Use either a Misspelling cleanup method 1 - API call or the Misspelling cleanup method 2 - Managed Fusion Admin UI to remove misspelling suggestions.

Misspelling cleanup method 1 - API call

Open the delete_lowConf_misspellings.json file.

{
"type" : "rest-call",
"id" : "DC_Large_QR_DELETE_LOW_CONFIDENCE_MISSPELLINGS",
"callParams" : {
    "uri" : "solr://DC_Large_query_rewrite_staging",
    "method" : "post",
    "queryParams" : {
    "wt" : "json"
    },
    "headers" : { },
    "entity" : "<root><delete><query>type:spell AND confidence:[0 TO 0.5]</query></delete><commit/></root>"
},
"type" : "rest-call",
"type" : "rest-call"
}

Enter <your query_rewrite_staging collection name/update> in the uri field. An example URI value for an app called DC_Large would be DC_Large_query_rewrite_staging/update.
Change the id field if applicable.
Specify the upper confidence level in the entity field.
The entity field specifies the threshold for low confidence spellings. Edit the upper range to increase or decrease the threshold based on your data.

Misspelling cleanup method 2 - Managed Fusion Admin UI

Log in to Managed Fusion and select Collections > Jobs.
Select Add+ > Custom and Other Jobs > REST Call.
Enter remove-low-confidence-spellings in the ID field.
Enter <your query_rewrite_staging collection name/update> in the ENDPOINT URI field. An example URI value for an app called DC_Large would be DC_Large_query_rewrite_staging/update.
Enter POST in the CALL METHOD field.
In the QUERY PARAMETERS section, select + to add a property.
Enter wt in the Property Name field.
Enter json in the Property Value field.
In the REQUEST PROTOCOL HEADERS section, select + to add a property.
Enter the following as a REQUEST ENTITY (AS STRING) <root><delete><query>type:spell AND confidence: [0 TO 0.5]</query></delete><commit/></root>
REQUEST ENTITY specifies the threshold for low confidence spellings. Edit the upper range from 0.5 to increase or decrease the threshold based on your data.

Delete all misspelling suggestions

To delete all of the misspelling suggestions, enter the following in the REQUEST ENTITY section:<root><delete><query>type:spell</query></delete><commit/></root>

This entry may be helpful when tuning the misspelling detection job and testing different configuration parameters.

Head-tail analysis job cleanup

The head-tail analysis job puts tail queries into one of multiple reason categories. For example, a tail query that includes a number might be assigned to the ‘numbers’ reason category. If the output in a particular category is not useful, you can remove it from the results. The examples in this section remove the numbers category.

Prerequisites

The head-tail analysis job cleanup does not have to occur in a specific order.

Remove head-tail analysis query suggestions

Use either a Head-tail analysis cleanup method 1 - API call or the Head-tail analysis cleanup method 2 - Managed Fusion Admin UI to remove query category suggestions.

Head-tail analysis cleanup method 1 - API call

Open the delete_lowConf_headTail.json file.

{
"type" : "rest-call",
"id" : "DC_Large_QR_HEAD_TAIL_CLEANUP",
"callParams" : {
    "uri" : "solr://DC_Large_query_rewrite_staging/update",
    "method" : "post",
    "queryParams" : {
    "wt" : "json"
    },
    "headers" : { },
    "entity" : "<root><delete><query>reason_code_s:(\"number\" \"number spelling\" \"number rare-term\" \"question number other-specific\" \"number others\" \"number other-specific\" \"number other-extra\" \"product number other-specific\" \"product number other-extra\" \"product number spelling\" \"product number others\" \"product number rare-term\" \"product question number\" \"product number re-wording\" \"question number other-extra\" \"number re-wording\")</query></delete><commit/></root>"
},
"type" : "rest-call",
"type" : "rest-call"
}

Enter <your query_rewrite_staging collection name/update> in the uri field. An example URI value for an app called DC_Large would be DC_Large_query_rewrite_staging/update.
Change the id field if applicable.

Head-tail analysis cleanup method 2 - Managed Fusion Admin UI

Log in to Managed Fusion and select Collections > Jobs.
Select Add+ > Custom and Other Jobs > REST Call.
Enter remove-low-confidence-head-tail in the ID field.
Enter <your query_rewrite_staging collection name/update> in the ENDPOINT URI field. An example URI value for an app called DC_Large would be DC_Large_query_rewrite_staging/update.
Enter POST in the CALL METHOD field.
In the QUERY PARAMETERS section, select + to add a property.
Enter wt in the Property Name field.
Enter json in the Property Value field.
In the REQUEST PROTOCOL HEADERS section, select + to add a property.

Enter the following as a REQUEST ENTITY (AS STRING)

<root><delete><query>reason_code_s:("number" "number spelling" "number rare-term" "question number other-specific" "number others" "number other-specific" "number other-extra" "product number other-specific" "product number other-extra" "product number spelling" "product number others" "product number rare-term" "product question number" "product number re-wording" "question number other-extra" "number re-wording")</query></delete><commit/></root>

Delete all head-tail suggestions

To delete all of the head-tail suggestions, enter the following in the REQUEST ENTITY section:<root><delete><query>type:tail</query></delete><commit/></root>

This entry may be helpful when tuning the head-tail job and testing different configuration parameters.

UI tour

Index data

Query data

Metrics and analytics

Improve your queries

Administration

Developer documentation

Machine learning

Neural Hybrid Search

Release notes

FAQs

​Query rewriting strategies

​Business rules

​Underperforming query rewriting

​Misspelling detection

​Phrase detection

​Synonym detection

​Remove words

​Rules Editor

​Query rewrite collections

​Rules Simulator query profile

​Query pipeline stages for query rewriting

​Spark jobs for query rewriting

​Daily query rewriting jobs

​Process flow

​Additional query rewriting jobs

​Basic parameters

​Advanced parameters

​”rules” role for query rewriting users

​Query rewrite jobs post-processing cleanup

Query rewriting strategies

Business rules

Underperforming query rewriting

Misspelling detection

Phrase detection

Synonym detection

Remove words

Rules Editor

Query rewrite collections

Rules Simulator query profile

Query pipeline stages for query rewriting

Spark jobs for query rewriting

Daily query rewriting jobs

Process flow

Additional query rewriting jobs

Basic parameters

Advanced parameters

”rules” role for query rewriting users

Query rewrite jobs post-processing cleanup