Why one search method is not enough

An employee at a service company enters “NH-47-02” and expects the record for one specific part. A minute later, another employee describes a fault: “after an overnight stop, the pump hums but does not build pressure.” The first query calls for an exact catalog match; the second calls for semantically similar repair notes and manuals. If both go only to a vector index, a related but incompatible part can rank above the right identifier. If the company relies only on keywords, synonyms and informal descriptions of faults may be missed.

This is an illustrative scenario, not a report of outcomes at a real company. In the BEIR study, lexical BM25 was a robust baseline across diverse datasets; more complex methods could improve retrieval but at greater computational cost. The study does not prove that hybrid search will win for a particular Russian-language business catalog. The narrower lesson is to compare semantic search with the existing search method and measure the two kinds of failure separately.

Separate identifier accuracy from semantic retrieval

Start with the data. Each record needs a canonical part number, spelling variants, equipment series, revision status, document type, freshness date, and access-control identifier. Manuals and repair reports should be divided into passages that link back to the file and page. The parts master remains the source of truth; it must not be replaced by a probabilistic model answer.

A practical query flow is:

  • Detect whether the query contains a part number, serial number, or order code. Normalize spaces and separators, but do not “correct” digits by guessing. When a clear code is present, first match it exactly against a structured field.
  • In parallel, retrieve candidates with lexical full-text search and with semantic vector search. Both branches must apply the same department, customer, equipment-series, and user-permission constraints.
  • Merge candidates by a stable document ID. Reciprocal Rank Fusion (RRF) uses the positions of results in each list instead of mixing incomparable numerical scores from different search engines. An optional reranker can then assess a short list, at the cost of extra latency and compute.
  • Show the human the original passages and links. Add a generative model only when a coherent answer is required; it must not turn a similar document into evidence that an incompatible part fits.

Qdrant documents parallel prefetch and RRF fusion. This is a tool capability, not a guarantee that any configuration will outperform a simpler baseline. Exact part numbers also deserve their own rule: when a catalog code has one unambiguous match, do not dilute it with weak semantic candidates.

Use the infrastructure you already run

A new service is not automatically necessary. If the company already operates PostgreSQL, its full-text search and pgvector can test both branches in a familiar environment. PostgreSQL provides `websearch_to_tsquery` and other text-query functions; pgvector supports exact and approximate vector search. With pgvector's approximate indexes, filters can be applied after the index scan, so narrow access filters call for an explicit check of recall and index settings.

If Qdrant is already part of the environment, its hybrid query and payload-field indexes can be used for filtered retrieval. The choice depends on the current operations team, data sensitivity, volume, load, and support capacity—not whose ranking demo looks nicer. In either design, permission checks must precede disclosure of results and cannot rely solely on an LLM instruction. Query logs also need care: they may contain customer names, equipment numbers, and fault details.

The cost of complexity and a useful pilot

A hybrid system stores more than text: it adds vectors, indexes, metadata, sometimes a reranker, and a re-indexing process. For a model calculation, 20,000 documents split into five passages each produce 100,000 vectors. At 768 dimensions and four bytes per number, the raw vectors occupy about 307 MB. This is neither the size of a production database nor its total cost of ownership: indexes, source text, metadata, replicas, backups, and spare memory add overhead. Staff time for labeling, catalog updates, and error review may matter more.

The pilot can run on an authorized copy of data before generating any answers. For example, assemble 90 real questions: 30 with part numbers, 30 describing symptoms, and 30 mixed. A human marks the correct document for each question or an honest “no answer.” Compare lexical, vector, and hybrid modes on the share of correct sources in the top five, exact-code errors, 95th-percentile latency, and operator verification time. Ninety is a proposed pilot size, not a statistical guarantee.

If hybrid search does not improve the query groups that matter to the business, keep the simpler design. If it does, add index-freshness controls and access-control tests before connecting answer generation with verifiable citations. That makes local RAG useful to a service operation instead of merely demonstrating an ability to merge two result lists.

Primary technical source for the hybrid query mechanism: [Qdrant documentation](https://qdrant.tech/documentation/search/hybrid-queries/).