Synonym Expansion with Token Budget Constraint Prompt

This prompt is for production retrieval pipelines where query length directly impacts latency, cost, or downstream model context windows. The job-to-be-done is generating a ranked list of synonyms and related terms from a user query while strictly adhering to a token or term count ceiling. The ideal user is a search engineer, RAG developer, or infrastructure operator who has already established that synonym expansion improves recall but now needs to control the expansion budget to meet a service-level objective (SLO). You need a source query, a target token or term limit, and optionally a domain context or controlled vocabulary to ground the expansion.

Do not use this prompt when recall maximization is the only goal and budget is unconstrained—a simpler, unbounded expansion prompt will suffice. It is also inappropriate when the downstream retriever has no practical length limit, such as in offline batch processing. This prompt assumes you have already validated that synonym expansion provides a measurable recall lift for your corpus and that you are now tuning the cost-recall trade-off. If you have not yet established baseline expansion value, start with a standard synonym expansion eval prompt first.

The prompt is designed to be wired into a pre-retrieval stage of a RAG or search pipeline. It expects you to handle validation of the output budget adherence in application code, not just in the prompt instructions. The model will produce a ranked list with marginal recall gain estimates, but you must verify the actual token count and truncate or reject outputs that exceed the budget. For high-stakes domains like legal or healthcare retrieval, always log the expansion output and the final query sent to the retriever for auditability.

This prompt template is the core instruction set for the Synonym Expansion with Token Budget Constraint workflow. It is designed to be copied directly into your application code, test suite, or orchestration layer. The template forces the model to act as a retrieval engineer, prioritizing synonym selection based on marginal recall gain and strictly adhering to a provided token or term count ceiling. All dynamic inputs are represented as square-bracket placeholders, which your application must resolve before sending the request to the model.

textCopy
You are a search relevance engineer. Your task is to expand a user's query with synonyms and related terms to improve document recall, while strictly adhering to a token budget.

INPUT QUERY:
[USER_QUERY]

DOMAIN CONTEXT:
[DOMAIN_DESCRIPTION]

TOKEN BUDGET:
[MAX_TOKENS]

OUTPUT SCHEMA:
[OUTPUT_SCHEMA]

CONSTRAINTS:
[CONSTRAINTS]

INSTRUCTIONS:
1. Analyze the INPUT QUERY and identify the core concepts that are most critical for retrieval.
2. Generate a list of synonymous terms, phrases, and conceptual alternatives for each core concept, informed by the DOMAIN CONTEXT.
3. For each generated term, estimate its marginal recall gain on a scale of 0.0 to 1.0, where 1.0 represents a term that is highly likely to retrieve uniquely relevant documents.
4. Rank all generated terms by their estimated marginal recall gain in descending order.
5. Assemble the final list of terms, starting from the highest-ranked, until adding the next term would exceed the TOKEN BUDGET. Count tokens using the same tokenizer as the target model.
6. Output the final list of terms, their marginal recall gain scores, and the total token count of the list in the exact format specified by the OUTPUT SCHEMA.
7. If no terms can be generated within the budget, return an empty list and a total token count of 0.

To adapt this template, replace the placeholders with concrete values from your application context. For [USER_QUERY], inject the raw search string. [DOMAIN_DESCRIPTION] should be a concise text field describing the knowledge base's subject matter (e.g., 'internal documentation for a cloud data warehouse product'). The [MAX_TOKENS] placeholder must be an integer representing the ceiling for the expanded terms list, not the entire prompt. Crucially, [OUTPUT_SCHEMA] should be replaced with a strict JSON schema definition to enforce a machine-readable contract, and [CONSTRAINTS] should be replaced with a list of hard rules, such as 'Do not expand proper nouns' or 'Preserve negation terms.' After implementing, validate the output against your schema and test with a golden query set to ensure budget adherence and term relevance.

The synonym expansion prompt with a token budget constraint is designed to sit directly between the user's original query and the retrieval backend. In a typical RAG or search pipeline, you will call this prompt after query intake and before the expanded query is dispatched to your vector store, keyword index, or hybrid retriever. The prompt expects a raw user query, a target token budget, and an optional domain context string. The output is a ranked list of expansion terms with per-term marginal recall gain estimates and a total token count that must not exceed the budget. Because this prompt enforces a hard constraint, your harness must validate the output before forwarding it to retrieval.

The implementation harness should wrap the LLM call in a function that accepts user_query, token_budget, and domain_context as arguments. After receiving the model response, parse the JSON output and run three validation checks before proceeding: (1) verify that the total token count of the expanded terms does not exceed the requested budget, (2) confirm that each term has a non-negative marginal recall gain estimate, and (3) ensure the original query terms are preserved unless explicitly flagged for replacement. If validation fails, retry the prompt once with the validation error appended as a [CONSTRAINT] note. If the second attempt also fails, fall back to the original query without expansion and log the failure for later analysis. This retry-and-fallback pattern prevents a broken expansion from blocking retrieval entirely.

For model selection, use a model with strong instruction-following and structured output capabilities. GPT-4o, Claude 3.5 Sonnet, and Gemini 1.5 Pro all handle the budget constraint reliably when the output schema is enforced. If you are running in a cost-sensitive or high-throughput environment, consider using a smaller model like GPT-4o-mini or Claude 3 Haiku with a stricter JSON schema and a post-processing step that truncates the term list to the budget if the model overshoots. Always log the raw model output, the validated output, the token count, and whether the fallback was triggered. These logs are essential for tuning the budget parameter and detecting prompt drift over time.

When integrating with a hybrid retrieval pipeline, pass the expanded terms as a weighted query string to your keyword index and as a concatenated phrase to your dense embedding model. The marginal recall gain estimates from the prompt can be used to weight term importance in BM25 or similar sparse retrieval algorithms. For dense retrieval, you may choose to embed only terms above a configurable gain threshold to avoid diluting the query vector with low-value synonyms. Store the expansion provenance—which terms were added, their gain estimates, and the budget consumed—alongside the retrieval trace so that downstream re-rankers and evaluators can distinguish original query matches from expansion-driven matches.

Avoid wiring this prompt into a synchronous user-facing path without a timeout and a circuit breaker. The expansion call adds latency, and a slow model response can degrade the end-to-end search experience. Set a reasonable timeout (e.g., 2–3 seconds) and fall back to the original query if the expansion call exceeds it. For high-risk domains such as legal or medical search, route expanded queries through a human review step before retrieval if the expansion introduces terms that materially change the query's meaning. The marginal gain estimates can serve as a signal for when review is warranted: if any single term has a gain estimate above a threshold you define, flag the expansion for approval.