RAG Query Rewriting: Does It Preserve the Question?

Executive Summary

A RAG (retrieval-augmented generation) query rewriter is usually justified by a retrieval or answer-quality gain, but that gain is measured against the wrong object if the rewritten search has quietly changed the question. The central finding of this review is that the rewriting papers reviewed here optimize retrieval or downstream answer scores, not fidelity to the original request; results on retriever weaknesses are indirect evidence for why constraint loss matters, not measurements of rewriters. Ma et al. (2023) train a rewriter with reward tied to the reader's answer and to whether retrieved text contains the gold answer ^[1], and CONQRR (Wu et al., 2022) uses a reward that directly optimizes retrieval ^[2]. Its authors state that the rewrites are meant to improve retrieval rather than be used by end users ^[3]. Neither paper certifies that entity, date, polarity, quantity or requested comparison survive. Query drift was already a named hazard in classical expansion work ^[4], and a human evaluation of one LLM rewriter found that its rewrites conveyed the user's real search intent in 84.8% to 89.4% of cases across three datasets ^[5].

The evidence that such qualifiers matter is independent and consistent. On NevIR, no bi-encoder exceeds 12% paired accuracy ^[6]; temporal retrieval methods prioritize matching exact dates, which the authors call a shortcut ^[7]; and a 2026 benchmark reports dense retrievers satisfying numerical constraints only 16.3% of the time ^[8]. Expansion can also hurt: Weller et al. report that it helps weaker retrievers but generally harms stronger ones ^[9], and a March 2026 study found rewriting lowered nDCG@10 by 9.0 percent on FiQA while raising it by 5.1 percent on TREC-COVID ^[10].

This article therefore proposes an acceptance protocol, not a measured result. Annotate an intent contract from the original request before any model rewrite is seen; freeze the corpus, models and settings; compare original search, a human standalone reference and the candidate rewrite on identical cases; build paired fixtures that change one decisive qualifier; and score constraint preservation, evidence retrieved for the original question, and supported-answer correctness separately. Report the share of requests preserving every critical constraint beside the average, because an average can hide a decisive date or entity mutation.

Statistics should be paired at the request level. McNemar's test is a standard paired test for binary outcomes ^[11], matched pairs per topic are the convention in retrieval testing ^[12], and correlated observations within a cluster call for cluster-aware resampling ^[13]. The release rule is three-way: ship the rewriter where preregistered materiality rules hold, fall back to the original search where they do not, and ask for clarification where the referent cannot be resolved. All numbers in the worked examples are hypothetical and labelled as such.

Introduction and Background

Query rewriting in RAG places a transformation between the user's request and the retriever. Weaviate's documentation describes it as reformulating the original user query to make it more suitable for retrieval ^[14]. The decision addressed here is narrower than whether rewriting works in general. An enterprise context engineer building an evidence-bearing application must decide whether a measured retrieval gain is acceptable when the rewritten search may have changed the entity, date, polarity, scope or requested comparison. This is an evaluation protocol, not a rewriter implementation tutorial, and every fixture and scoring suggestion below is a proposed method rather than a measured outcome.

Four terms are used throughout, and keeping them apart is the point of the protocol.

• Question intent is what the requester asked: referents, time scope, quantities and units, negation, the required comparison, the evidence requested and any ambiguity that is genuinely unresolved. It is fixed from the original request and the permitted conversation.
• Search expansion adds terms, hypothetical text or alternative phrasings to raise the chance of retrieving relevant material. It need not be a paraphrase. A hypothetical document used for embedding lookup rather than the raw query is a legitimate search device even though it is not the question ^[15].
• Standalone rewrite converts a context-dependent turn into a self-contained question. CANARD defines the task as rewriting a context-dependent question into a self-contained question with the same answer ^[16]. The "same answer" clause is a fidelity requirement that retrieval-oriented training objectives do not enforce.
• Clarification is a request back to the user when the referent or scope cannot be determined. It is the correct response when a guess would silently redefine the question.

The distinction between expansion and rewrite matters because a strict literal-paraphrase gate would reject useful behavior, while a pure retrieval metric would accept harmful behavior. The protocol resolves this by judging the transformation against an explicit contract, then judging the evidence and the answer against the same contract. Retrieval relevance cannot certify question fidelity: a passage can be highly relevant to a rewritten question about a different year, a parent company instead of a subsidiary, or a decrease instead of an increase, and conventional metrics such as Hit Rate, MRR and NDCG score relevance to whatever query was issued.

This report does not claim that nobody evaluates rewriting. The Milvus guide, a vector database vendor's documentation, covers sub-queries and step-back prompts at a high level ^[17], and the academic literature measures task gains carefully. The contribution proposed here is a preregistered question-constraint ledger and paired qualification fixtures that make fidelity failures countable. A reader who needs a retriever, vector index or RAG framework should select from those categories; none of those replaces the protocol below, which needs a frozen, versioned corpus snapshot so that every test run retrieves from the same evidence base.

Key Changes: How Rewriting Alters the Question

Search expansion changes the query, and sometimes the topic

The classical name for harmful expansion is query drift, defined in the query-expansion literature as the alteration of the focus of a search topic caused by improper expansion ^[4]. The same survey warns that the effect may be more serious when the added term is a proper noun ^[4], which is the usual case for entity-bearing enterprise questions. Mitra, Singhal and Buckley reported in 1998 that refining the feedback document set often prevents the query drift caused by blind expansion (Source: people.eng.unimelb.edu.au), which shows that drift was a known, measurable hazard before LLMs.

LLM-based expansion inherits the hazard. Query2doc, published at EMNLP 2023, reports that LLM-generated pseudo-documents boost BM25 by 3% to 15% on ad-hoc IR datasets ^[18]. Weller et al., testing eleven expansion techniques, twelve datasets and twenty-four retrieval models, found that expansion improves scores for weaker models but generally harms stronger models ^[9]. A March 2026 study of prompt-only single-step rewriting reports that rewriting degrades nDCG@10 by 9.0 percent on FiQA and improves it by 5.1 percent on TREC-COVID ^[10]. The authors attribute the FiQA loss to rewriting that replaces domain-specific terms in queries that already matched well. The practical reading is that the sign of the effect depends on corpus and retriever, so a gain reported elsewhere does not transfer to a given site.

Standalone rewrites in conversation resolve referents, and can pick the wrong one

Conversational rewriting is the stage most likely to introduce a silent entity change, because the rewriter must choose among referents in earlier turns. TopiOCQA reports that 28% of turns require retrieving a document different from the previous turn ^[19], so topic switches, where a wrong carry-over of an entity is most likely, are frequent. The TREC CAsT 2019 organizers note that off-the-shelf coreference models struggled with CAsT topics more than expected ^[20]. LLM rewriters narrow the gap with human rewriting but not completely: the LLM4CS human evaluation found that its rewrites successfully convey the user's real search intent in 85.5%, 89.4% and 84.8% of cases across three datasets ^[5]. By arithmetic on those figures, roughly one rewrite in nine to one in seven did not; the paper does not state that number. The same authors acknowledge that LLM rewrite generation lacks awareness of the downstream retrieval process ^[5].

Retrieval-optimized rewrites are not paraphrases, by design

The two primary papers discussed here optimize different objectives, and neither is a fidelity guarantee. Ma et al. (EMNLP 2023) propose Rewrite-Retrieve-Read, motivated by the observation that there is inevitably a gap between the input text and the needed knowledge in retrieval ^[21]. The arXiv record carries the title Query Rewriting for Retrieval-Augmented Large Language Models ^[22], while the ACL Anthology uses "in"; the abstract is the same on both pages. The trainable rewriter learns from reader feedback by reinforcement learning, and for open-domain QA the reward gives credit if the retrieved content hits the answer and penalizes a miss ^[1]. The paper's case study shows what the resulting rewrites look like: queries that put a keyword forward ^[1]. The authors frame the objective as adapting the retrieval query to improve the reader on downstream tasks ^[1]. The paper reports no separate measurement of whether a rewrite preserves the original question. That is a property of the objective, not a defect: the paper makes no fidelity claim to breach. Its reported gains are task gains, and they are not uniform: rewriting improved most settings except the social sciences on MMLU ^[1].

CONQRR (Wu et al., EMNLP 2022) rewrites conversational questions with a reward function that directly optimizes retrieval using reinforcement learning ^[2]. The paper states that its aim is to improve retrieval performance instead of directly being used by end users ^[3]. Its error analysis is directly relevant: among 50 sampled examples where CONQRR (mix) ranked the gold passage worse than the human rewrite with the dense encoder, 34% involved additional information with a misinterpretation of the user request ^[3]. Ye et al. state the property that matters here: the rewritten query should preserve the meaning of the original query ^[23]. No benchmark discussed in this review measures that property together with retrieval gain on enterprise constraints, which is why the protocol separates them.

Decomposition and step-back change the requested comparison

Decomposition splits one request into several searches. The Milvus guide says an LLM can break a complicated query down into simpler sub-queries ^[17]; LlamaIndex documents a sub-question engine that gathers intermediate responses and synthesizes a final response ^[24]; Azure AI Search documents LLM-based planning that breaks a complex query into smaller, focused subqueries ^[25]; and LangChain's MultiQueryRetriever writes a set of queries with an LLM and returns the unique union of all retrieved documents ^[26]. A unique union has no step that checks the retrieved set against the original question. The RAG-Fusion authors report in their abstract that some answers strayed off topic when the generated queries had insufficient relevance to the original query ^[27], a qualitative single-study observation.

Decomposition fidelity is itself imperfect. The Break benchmark defines question understanding as the ability to break a question into the requisite steps for computing its answer ^[28], and automatic decomposition into such steps is an error-prone task in its own right. Step-back prompting abstracts the question into higher-level concepts and reports gains on MMLU Physics and Chemistry of 7% and 11% (Source: iclr.cc) and on TimeQA by 27% (Source: iclr.cc). Its authors also catalogue an error class, Context Loss, where the model response loses context from the question ^[29]. A step-back question about a general principle can drop the specific year or entity that the user asked about, which is a plain failure of the requested scope even when the final answer is fluent.

Why Retrieval Relevance Does Not Certify Fidelity

The paired-qualifier fixtures proposed below rest on work showing that retrievers and similarity metrics are weakest where one decisive qualifier flips the answer set.

Negation, exclusion and set operations

NevIR builds document pairs that differ only by negation and reports that most IR models do not consider negation, performing the same or worse than a random ranking ^[30]. Its metric is paired: a pair counts only if the ranking flips correctly for both queries, because models tended to rank one document above the other for both queries ^[6]. No bi-encoder scores higher than 12% on it. A rewriter that drops a "not" or turns "excluding" into a keyword hands the retriever a different question, and a retriever that already struggles with negation will not signal the change.

Time scope

TimeQA's authors note that lots of facts can evolve with respect to time (Source: datasets-benchmarks-proceedings.neurips.cc), and its best long-document model reached 46% accuracy against 87% for humans (Source: datasets-benchmarks-proceedings.neurips.cc). A temporal-RAG study that perturbs the temporal relation (before, after, as of) finds that all methods prioritize matching exact dates, indicating a shortcut ^[7]. A date constraint can therefore be lost in two places: the rewriter may normalize or drop it, and the retriever may match the literal date string rather than the relation.

Quantities, units and entities

A 2026 benchmark of numerical constraints reports that state-of-the-art dense retrievers achieve only 16.3% accuracy in numerical constraint satisfaction ^[8]. The authors of that benchmark frame the result as specific to the retrievers they tested, and it should not be read as a statement about every deployed retriever. Entity handling is the other recurrent hazard. On EntityQuestions, a DPR dense retriever scores 49.7% against 72.0% for BM25 on average ^[31]. If a rewriter replaces a rare entity string with a descriptive phrase or a commoner alias, the retriever may lose its strongest signal; if it substitutes a parent for a subsidiary, the retriever will find fluent, relevant, wrong evidence.

Similarity metrics do not certify meaning preservation

Semantic-equivalence scores are tempting as automatic fidelity checks. BERTScore computes token similarity with contextual embeddings instead of exact matches (Source: iclr.cc). Work on learned evaluation metrics argues that models of this family are insensitive to negations ^[32]. That finding comes from text-generation evaluation and was not measured on rewrite-versus-original pairs. They justify one rule: similarity may triage candidates for review, but cannot certify fidelity.

Implementation Considerations: An Acceptance Protocol

Everything in this section is a proposed method. No benchmark is supplied for it, none of the figures are measured, and the protocol has not been run on any corpus.

Step 1: annotate the intent contract before seeing any rewrite

Two reviewers annotate each original request, plus only the conversation turns the application is permitted to use, without access to any model rewrite. The contract records:

• Referents: entities with admissible aliases verified against the frozen sources, and for conversation, which earlier-turn referent is intended or whether it is unresolved.
• Time scope: dates, ranges and relations (before, after, as of, during), and the reference date for any "current" language.
• Quantities and units: thresholds, comparison operators, currency or measurement units, and aggregation (annual versus cumulative).
• Polarity: negation and exclusion, and status qualifiers such as approved versus proposed.
• Required comparison: the sets compared and the direction (increase versus decrease).
• Requested evidence: the kind of source the requester asked for, if stated.
• Unresolved ambiguity: a flag for requests where the correct behavior is clarification, with the admissible interpretations listed.

Disagreements are adjudicated, and agreement before adjudication is reported, as TREC CAsT 2019 did when its manual rewrites were compared and the disagreements adjudicated to a canonical form ^[20]. Report raw agreement and a chance-corrected coefficient per constraint type, since most constraints in most requests are uncontentious and chance-corrected agreement behaves differently from raw agreement under imbalance. Each constraint also receives a materiality label (critical or non-critical) now, so that the release rule cannot be tuned to the results. Record every ambiguous label and each admissible alternative rewrite, so the later verdict is "outside the admissible set" and not "different from one reference."

Step 2: freeze the experimental conditions

Freeze the corpus snapshot and source versions, the rewriter, retriever and generator versions, prompts, sampling settings, top-k and the token budget, and fix a reference date for any "current" language. Three arms run on identical cases:

• Original search: the request, or the minimal permitted conversation context, goes to the retriever unchanged.
• Human standalone reference: a reviewer writes a standalone question from the contract. The reference must not leak answer terms, so the writer works from the request and the contract, not from the evidence. Human rewrites are not guaranteed to be the best search queries, so this arm is a fidelity reference, not a retrieval ceiling.
• Candidate rewrite: the production rewriter, condenser or decomposer, with every emitted sub-query logged.

Step 3: build paired fixtures that change one decisive qualifier

Paired fixtures take one request and produce a minimal twin that differs in a single decisive qualifier, in the spirit of NevIR's document pairs and AmbigQA's practice of writing disambiguated questions as minimally edited modifications of the prompt question ^[33]. Generic information examples suffice. Suggested pair families:

• Date: before versus after a named date, or fiscal versus calendar year.
• Organization: parent versus subsidiary, or two entities sharing a name.
• Direction: increase versus decrease, or a rise in a rate versus a rise in a count.
• Status: approved versus proposed, draft versus final.
• Aggregation: annual versus cumulative, per unit versus total.
• Referent: one of two conversational referents, with the twin conversation swapping which entity was mentioned last.
• Unresolved: a conversation where two referents are equally plausible and clarification is the correct response.

A pair passes only if the rewrite, the retrieved evidence and the answer all differ appropriately between twins, or the system asks for clarification where the contract says it should. Scoring the pair as a unit follows NevIR's rationale for paired accuracy: a system can return the same result for both twins. Include a deliberate expansion control as well: cases where the best rewrite adds vocabulary or a hypothetical answer without altering the contract. Such an expansion should pass if the evidence and answer remain accountable to the original contract. Without this control, an overstrict gate would reject useful behavior and push teams toward no rewriting at all.

Step 4: score the transformation, the evidence and the answer separately

Five scores, never merged into one:

• Constraint preservation equals preserved applicable constraints divided by annotated applicable constraints. A constraint is preserved if the rewrite states it, or carries it as a filter outside the query text, in a form the adjudicators judge equivalent to an admissible interpretation. Constraints added that are not in the contract count as alterations.
• Critical-constraint completeness is the fraction of requests in which every critical constraint is preserved. It is reported beside the average so a decisive date or entity mutation cannot hide in a high mean.
• Evidence recall against original intent is the share of contract-required evidence items retrieved, judged against the original contract, not the rewritten query. This is where retrieval relevance and question fidelity separate. Near-miss evidence is a failure distinct from missing evidence.
• Supported-answer correctness requires that the answer is correct under the contract and that its claims are supported by the retrieved evidence. Claim-level attribution checking is a downstream diagnostic and is not repeated here.
• Clarification correctness: asking when the contract marks the request unresolved, and not asking otherwise. A system that clarifies everything passes the first test and fails the second, so report both.

For decomposition, record the rewrite-stage view per sub-query and for the union: every sub-query can preserve its constraints while the requested comparison across them is dropped. Table 1 below shows the proposed original-to-rewrite constraint matrix. All rows are hypothetical.

The matrix is the artifact reviewers reuse. Its columns separate what was asked, what the rewrite changed and what came back, so a reader can see that H-040 is an expansion that passes and H-027 is a clarification case, not a retrieval error.

Step 5: localize where the failure first appears

For each failed request, label the first stage at which the contract is lost: rewrite, retrieval or generation. A rewrite that preserves every constraint but retrieves the wrong evidence is a retrieval failure; a rewrite that drops the date is a rewrite failure even if the retriever happened to return the right documents. Retrieval-quality aspects (context relevance, noise robustness) and generation-quality aspects are separable in principle, and the RGB authors report that models show some noise robustness but struggle with negative rejection, information integration and dealing with false information ^[34]. The wider RAG fault-isolation matrix is the right downstream tool once the rewrite stage is cleared, and is not duplicated here.

Step 6: report paired gains and regressions with request-level uncertainty

The unit of analysis is the request, and a request with five correlated constraints is one observation. Cameron, Gelbach and Miller note that cluster-robust methods permit heteroskedasticity and within-cluster error correlation ^[13], and that rejection rates of ten percent under standard methods can be reduced to the nominal five percent by cluster bootstrap procedures ^[13]. In IR testing, system scores are paired per topic ^[12]. Smucker, Allan and Carterette found little practical difference among the randomization, bootstrap and t tests ^[12], recommended the randomization test as the preferred test ^[12], and said use of the Wilcoxon and sign tests should be discontinued for measuring a difference between means ^[12]. Berg-Kirkpatrick et al. use the paired bootstrap for NLP ^[35].

For a binary outcome per request (supported-correct or not), McNemar's test applies: statsmodels documents it as a test of homogeneity on a 2x2 table ^[36]. Dietterich found it the only test with acceptable Type I error among those compared for algorithms run once ^[11], and its null is that the two algorithms have the same error rate ^[11]. Define:

• Rewrite-induced regression equals baseline-supported-correct requests that become incorrect or unsupported under the candidate, divided by baseline-supported-correct requests.
• Rewrite-induced gain is the converse, among requests that were not supported-correct at baseline.

Report both with denominators, the discordant counts, and a request-level bootstrap interval.

Step 7: decide release, fallback or clarify, using rules written beforehand

Preregister materiality rules per task type before running anything:

• Release the rewriter for a request class only if critical-constraint completeness meets a preregistered floor, rewrite-induced regression stays below a preregistered ceiling with its interval, and no paired-fixture family shows a systematic flip failure.
• Fall back to original search, or run original and rewritten searches and fuse them with the original always included, for classes that fail the floor but show a retrieval gain.
• Clarify where the contract marks an unresolved referent, instead of letting the rewriter choose. A rewriter that guesses silently redefines the question.
• Publish negative outcomes and limits, including classes where the rewriter was disabled and the denominators behind each decision.

With zero observed critical-constraint failures in n requests, the one-sided 95% upper bound on the true failure rate is approximately 3/n (the rule of three), about 1.5% at n = 200. That is arithmetic, not a finding; it shows why small fixture sets cannot certify a very low failure rate.

Data Analysis and Evidence

What the published results do and do not measure

Table 2 below summarizes reported results from the literature discussed above, with the objective each study optimized. Numbers are quoted as reported, on the datasets and metrics named, and are not transplanted to any other site.

The last column carries the argument. Every row reports a retrieval or answer outcome, none reports the share of requests whose critical constraints survived, and the two studies closest to the question (CONQRR's error analysis and Step-Back's error taxonomy) expose meaning loss only as a minority category within a task benchmark. The directional heterogeneity, with a gain on one dataset and a loss on another, is the reason the protocol insists on site-specific measurement.

A hypothetical worked calculation

The following numbers are invented to illustrate the arithmetic (Hypothetical Example). Suppose 200 requests carry 540 applicable annotated constraints, of which 100 are critical. The candidate rewrite preserves 513 of 540 constraints, so constraint preservation is 95.0%. Yet only 164 of 200 requests preserve every critical constraint, a critical-constraint completeness of 82.0%. The average looks safe while nearly one request in five has lost a decisive qualifier.

Now suppose 120 of 200 requests are supported-correct under original search (60.0%). Under the candidate, 18 of those 120 become incorrect or unsupported, a rewrite-induced regression of 15.0%, while 30 of the other 80 become supported-correct. The candidate reaches 132 of 200 (66.0%), a net gain of six percentage points. The discordant pairs are 18 and 30; an exact two-sided McNemar test on 48 discordant pairs gives p of about 0.11, so on these invented counts the net gain is not distinguishable from zero at the 0.05 level, though a bare accuracy headline would have favored release. Whether 18 regressions are acceptable depends on the preregistered materiality rule: if 11 of the 18 involved a changed date or entity, a rule that treats those as critical would send the date-bearing class to fallback and keep the rewriter elsewhere.

Table 3 below sets out the proposed three-arm comparison scorecard. It contains no measured values, because none exist.

The scorecard enforces three habits. It keeps the human arm as a reference for fidelity and cost, not a production option. It reports latency and cost from measurement, because published figures vary with method and hardware; for example, the Haystack documentation describes generating a hypothetical document five times in practice ^[37], which multiplies calls. It also scores the original-search arm against the contract, so the baseline's own unfaithfulness, such as a follow-up question sent without its referent, is visible rather than assumed away.

Implications and Future Directions

For a team deciding whether to enable a rewriter, condenser or decomposer, the sensible default is conditional enablement. Gains reported on benchmark tasks are real for the datasets and metrics named, yet the objective those studies optimize does not include preservation of enterprise constraints, and the direction of effect varies by corpus and retriever. The LLM4CS authors acknowledge that LLM rewrite generation lacks awareness of the downstream retrieval process ^[5], so the retrieval side cannot be assumed to compensate. Enablement by request class, with fallback where critical-constraint completeness is below its preregistered floor, follows from that.

Three design consequences follow. First, carry high-risk constraints outside the free text where the architecture allows it: a date range or entity identifier applied as a metadata filter cannot be paraphrased away, although the filter values still need checking against the contract. Second, always retain the original request in the search set, since a unique-union pattern ^[26] keeps only what the generated queries retrieve. Third, treat clarification as a first-class outcome: an evidence-bearing application with a conversational front end should ask when the referent is unresolved, as the protocol's clarification score requires.

Open questions remain. No study cited here directly measures how often LLM rewrites change a question's meaning on enterprise-style constraints; the nearest evidence is indirect, from retrieval degradation and human intent checks ^[5]. Rewriters trained for one retriever or task may not transfer to another. The benefit of expansion may shrink as retrievers improve, while an LLM upstream of the retriever keeps its capacity to alter meaning. The fixtures proposed here are one candidate answer and should be revised after a first run.

Frequently Asked Questions (FAQs)

What is query rewriting in RAG?

Query rewriting in RAG is any model stage that transforms the user's request before retrieval: reformulating it, expanding it, condensing a conversation into a standalone question, or decomposing it into sub-queries ^{[14] [15]}. Step-back questions, which abstract a complicated query before retrieval, are one variant ^[17]. Rewriting differs from clarification, which returns to the user.

Does query rewriting hurt RAG accuracy?

It can. Expansion generally harms stronger retrievers while helping weaker ones, and one 2026 study measured a 9.0 percent nDCG@10 fall on FiQA alongside a 5.1 percent rise on TREC-COVID. Whether it hurts a particular application is an empirical question for that corpus and retriever.

Why does a rewrite drop constraints, and which are most at risk?

Rewriters optimized for retrieval or reader scores are not rewarded for keeping qualifiers, and retrievers are weak on negation ^[6], temporal relations and numeric conditions ^[8]. Negation, date relations, numeric thresholds and entity strings therefore head the intent contract.

How should dates and numeric filters be handled?

Answers to many questions depend on time, since lots of facts can evolve with respect to time (Source: datasets-benchmarks-proceedings.neurips.cc), and dense retrievers have been reported to satisfy numerical constraints only 16.3% of the time ^[8]. Treat dates and numbers as critical constraints, test them with paired fixtures (before versus after; annual versus cumulative), and where possible apply them as structured filters outside the rewritten text. Verify the filter values against the contract, because a rewriter can still alter them.

How should rewriting be evaluated, and how is constraint preservation tested?

Annotate the contract first, compare original search, a human standalone reference and the candidate under frozen conditions, and score preservation, critical-constraint completeness, evidence recall against original intent, supported-answer correctness and clarification correctness separately. Use paired fixtures that flip one qualifier, and report paired regressions and gains with denominators and request-level resampling.

What are the common failure modes of query transformation?

Query drift ^[4], entity substitution ^[4], loss of context under abstraction, off-topic generated queries, mis-chosen conversational referents, and unions of sub-query results never checked against the original question ^[26].

How is reformulation evaluation different from RAG evaluation?

Reformulation evaluation judges the transformed query against the contract before any retrieval. RAG benchmarks test other abilities, such as noise robustness, negative rejection, information integration and counterfactual robustness ^[34], and none of them is a question-fidelity test, which is why the contract is annotated separately.

Conclusion

A rewriter earns its place in an evidence-bearing application only if its retrieval gain survives an audit of what it did to the question. The primary literature shows that rewriting can raise retrieval and answer scores, and that the training objectives behind those gains target retrieval or the reader, not fidelity. It also shows that the retrievers downstream are weakest on negation, dates, numeric conditions and rare entities, so an unnoticed change is likely to travel through to a fluent, relevant and wrong answer.

The protocol proposed here asks for five things: an intent contract written before any rewrite is seen; three arms under frozen conditions; paired single-qualifier fixtures, including unresolved cases where clarification is correct and expansion cases where a non-paraphrase should pass; separate scores for the transformation, the evidence and the answer; and preregistered release, fallback and clarify rules with request-level uncertainty. It has not been run, and its thresholds are left to each team. What it prevents is the most expensive error in this area: accepting an average that hides the date, entity or polarity change that decided the answer.