OpenAI Vector Store rewrite_query: Find Museum Policies Without Losing Accession Numbers

A polished search phrase can lose the record

A registrar needs the approved treatment restriction for accession MS-204 before answering a request about lending an exhibit. The visitor’s question mentions the accession number and a local term for the treatment. Semantic search may surface useful policy language even if it has different wording. But a rewritten search phrase that omits the identifier could retrieve a generally similar restriction for another object. OpenAI vector store search offers an optional rewrite_query setting that rewrites natural-language queries for retrieval. Treat that feature as a search aid, not as a record-identity check. The acceptance requirement is that a reviewer can trace the final answer to the exact approved accession record and policy revision.

Understand the separate search response fields

The vector store search endpoint accepts a query as a string or an array of strings and can return matching content chunks, file IDs, filenames, attributes and scores. The official retrieval guide documents rewrite_query=true and explains that the resulting search_query field exposes the rewritten search text. The API reference describes the setting as optional and false by default. An important distinction is that search_query reports what the retrieval system searched for, while the original user question remains the basis for the review task. Neither field independently proves that the returned file belongs to accession MS-204. Save the input question, search_query, file ID and file attributes together for a meaningful audit.

Build the corpus around explicit accession identity

Before comparing rewriting modes, attach stable accession IDs, collection IDs, approval states and document revision dates to the files. Name the current permissions memo separately from superseded loan notes. Use one approved test corpus in both runs so a change in source files does not masquerade as an improvement from rewriting. Where file attributes carry the accession or approval state, apply documented filters in addition to the search terms; do not substitute a verbal reference in the prompt for a controlled filter. The OpenAI API supports attribute filters on vector store search. Verify that each imported record has completed indexing and that the file ID opens the expected source rather than an unrelated scan.

Compare rewrite off and on with the same question

Create a small evaluation worksheet containing the literal query, its important identifier, the rewrite_query value, returned search_query values and the first relevant file references. Repeat the request once with rewriting disabled and once enabled against the same ready vector store. Include questions written as visitors actually speak, such as “Can MS-204 travel to the touring show?” and a paraphrase using the object title but not its code. These are proposed test prompts, not results of an API experiment conducted for this article. Do not report a percentage improvement without executing a labeled evaluation. The point is to detect whether a reformulation broadens recall while keeping record identity verifiable.

Use three distinct review states

A first state contains the complete question with an accession code; it represents the input to preserve. In the second state, illustrate a possible rewritten term list that focuses on “touring exhibition handling restrictions” and does not contain the code. That state is deliberately unresolved, not proof that the service always deletes identifiers. In the third state, the reviewer matches returned file attributes and the original request to the approved MS-204 record and opens its latest policy. The comparison should not label a fluent excerpt as a verified answer merely because its score is high. Similarity scores rank candidates; the accession and revision check decide whether a result is usable.

Keep filtering distinct from query rewriting

The search reference supports comparison and compound filters based on file attributes, including equality and range-like operations. If museum staff have different scopes, apply server-side authorization and attribute restrictions before presenting content, and check that filters reflect the user’s role. Rewriting may improve how a question is expressed, but it must not override the selected access boundary. For example, a visitor-facing assistant should not read staff-only loan exceptions just because the rewritten phrase overlaps those files. Conversely, an overstrict accession filter can hide a general policy that applies to many objects. Decide explicitly whether the answer requires a specific object rule, a shared policy, or both, then cite each separately.

Check ambiguous titles and neighboring objects

A museum might own several objects with nearly identical titles, such as two numbered casts of a bronze figure. Create contrast queries that use the wrong accession suffix, alternate punctuation, a common title without the ID and an obsolete catalog number. Inspect whether the returned file ID is correct and whether the passage itself names the right object. Include one negative fixture whose accession does not exist in the approved corpus; the appropriate outcome is an unresolved lookup, not a plausible guess. Reviewers should open the source in the catalog of record. A search result that merely mentions a neighboring accession does not satisfy the specific-object test.

Log changes without exposing private records

Capture the minimal technical evidence needed to reproduce a retrieval decision: configuration version, query variant, search_query, selected file IDs, access-scope decision and human review status. Avoid storing full private loan agreements or personal donor notes in routine application logs. Set retention and access rules for the audit ledger separately from the vector store. When a new policy edition is indexed or a model-side rewrite changes, rerun the exact fixture set and inspect any changed file references. The rewritten phrase can be valuable diagnostic evidence, but it should not become an invisible replacement for the visitor’s original request in case notes.

Release only after the document identity is verified

The registrar’s final sign-off should name the accession, active policy revision, relevant passage and any exception requiring specialist approval. If rewriting helps retrieve a passage, retain that benefit while displaying the source clearly. If the record match remains uncertain, stop the automated answer and route the question to collection staff. Keep a separate measurement plan for retrieval quality if the institution later wants benchmark statistics. For now, success means a reviewer can reconstruct which query was used, which file supplied the passage, and why the selected source is authoritative for the particular object. Those checks are more useful than a claim that the system understands museum numbers.

Related guides

• OpenAI Vector Store Chunking: Keep Safety Warnings With Museum Repair Steps
• OpenAI Vector Store Expiration: Retire a Temporary Grant Index Without Losing Source Records
• OpenAI Vector Store Attribute Filters: Find the Current Safety Manual, Not an Old Draft

How We Research

For this guide we consulted the official documentation: OpenAI Retrieval guide; Vector store search API reference. We compared named fields, supported behaviors and stated limitations, then developed an instructional museum scenario with explicit failure states. We did not run a live vendor API benchmark, inspect a production museum system, or measure vendor performance. The workflow and illustrations are proposed review steps; verify API-version support and your organization’s current policy before applying them.

Frequently Asked Questions