A document assistant can understand a question about a leaking pump and still retrieve the manual for the wrong pump. The explanation sounds relevant, the topic matches, and the model number differs by one character. For the person trying to find a specific record, that difference is the whole job.
We recommend treating exact identifiers and descriptions of a problem as different search needs. A useful RAG system should handle both. Before changing the model that writes the answer, check whether the right document reaches it.
Some questions describe a problem; others name a record
Consider a hypothetical maintenance team with a collection of manuals. One employee asks, “What could cause pressure to fall after startup?” Another asks for the inspection procedure for model PX-410B. These are invented examples, not a client project.
The first question benefits from finding passages that discuss the same problem in different language. The second needs the right equipment identity before any summary is useful. A paragraph about PX-410A might be an excellent conceptual match and still be the wrong evidence.
Vector search uses numerical representations of text to find material with similar meaning. Keyword search looks for terms in the indexed text. Microsoft’s hybrid-search guidance specifically identifies product codes and specialized terms as cases where keyword matching can help.
Neither method should be assumed sufficient for every question. We recommend collecting examples of both kinds from the people who will use the system.
Combine search methods without hiding their differences
Hybrid search brings keyword and vector results together. One path can find the specific term; the other can find a relevant explanation that uses different wording. The combined candidates can then be ranked before selected passages reach the answer model.
This does not require every project to adopt a separate search platform. The pgvector documentation describes combining vector search with Postgres full-text search, including approaches for combining or reranking results. The appropriate design depends on the existing application and its workload.
For the hypothetical maintenance team, the useful outcome is concrete: a query naming PX-410B should surface material for PX-410B, while a general troubleshooting question should still find useful passages without requiring the employee to know the manual’s terminology. Adding a second search method is only worthwhile if it improves those results.
Preserve the characters that identify the thing
Ordinary text indexing can change punctuation and split strings into smaller pieces. Microsoft documents how that can interfere with searches for codes and other strings containing special characters. A field designed for prose may therefore be a poor place to rely on an intact part number.
We recommend keeping an original identifier alongside any normalized version used for matching. Define which differences are harmless. Case may be irrelevant in one catalog, while a suffix or leading zero distinguishes different products in another.
Do not silently strip characters just because doing so increases the number of matches. In our invented example, treating PX-410A and PX-410B as interchangeable would make the search look more successful while removing the distinction the employee needs.
Ask the implementer to demonstrate the indexed representation of a few real identifier formats. Include punctuation, spaces, leading zeros, and close alternatives. This small check can reveal a data-preparation problem before anyone spends time adjusting prompts.
Keep business vocabulary under review
Staff may use an abbreviation that never appears in the official manual. An old product name may remain common after a catalog changes. Those gaps can sometimes be handled with a maintained vocabulary rather than another model.
Elastic’s synonym documentation distinguishes explicit mappings from groups of equivalent terms and recommends testing the resulting analysis and queries. That offers a useful pattern: record the terms the business considers equivalent, and verify what each rule actually retrieves.
We recommend having a domain owner approve those mappings. An abbreviation with two meanings should not become a global synonym merely because it worked in one example. Keep the original query visible so a reviewer can tell when the system expanded it.
Start with a few confirmed vocabulary gaps. A growing list of speculative synonyms can make it harder to understand why an unrelated document appeared.
Compare results before comparing answers
Build a review set that separates exact-code queries, descriptive questions, and mixed requests containing both. Include a nonexistent code and two near-identical identifiers. Record which documents should be returned and which would be a misleading substitute.
Run the same questions against keyword search, vector search, and the proposed combination. Inspect the first few results and the passages passed to the answer model. Keep the answer-generation settings unchanged while comparing retrieval, so the team can see which change produced the difference.
We recommend recording failures in plain language: “correct document absent,” “wrong suffix ranked first,” or “right manual, wrong section.” Those notes point to different fixes. A single overall score can hide a serious regression in exact lookups behind improvements on descriptive questions.
Also compare response time and operating effort. A more complicated search pipeline needs a demonstrated benefit over the simpler version.
Make an unsuccessful lookup visible
Decide what the interface should do when a requested identifier has no exact match. We recommend saying so clearly and labeling any related results as alternatives, rather than presenting the nearest-looking document as the requested one.
The answer still needs verification after retrieval succeeds. Our guide to checking AI answer citations covers whether the cited passage supports the actual claim. Finding the right manual and interpreting its procedure are separate checks.
If staff mostly look up a known document number, a well-designed ordinary search may be enough. Hybrid search becomes more interesting when the same collection must support both precise lookups and questions expressed in everyday language.
We build document retrieval, ranking, evaluation, and interfaces together. Tell us what your team searches for, including a few unsuccessful queries with confidential details removed. The first useful decision is which search behavior needs improving, before deciding how much AI the job needs.