Hybrid Search RAG
By Ai Flowi · Published
Hybrid search RAG combines lexical retrieval, which uses words and exact terms, with semantic retrieval, which uses meaning represented by embeddings. The combined candidates provide evidence for retrieval-augmented generation. Evaluate exact identifiers and paraphrased questions separately to see whether both kinds of evidence survive selection.
For this proposed inspection path, AI Flowi Workflow’s OpenSearch, Prompt Template and Language Model components are documented in the catalogue; not production-tested by Ai Flowi. OpenSearch’s description mentions hybrid search, but the exported interface does not establish the query construction, signal combination or external index configuration. This guide supplies a test design, not a verified native hybrid-search recipe.
1. Build a corpus that distinguishes retrieval signals
Prepare synthetic passages with explicit identifiers, natural-language explanations and similar but inapplicable records. Use a made-up equipment code in one passage and a descriptive question about its purpose in another test. Keep versions and passage identifiers visible so you can inspect which evidence was returned instead of trusting the apparent fluency of an answer.
| Passage feature | Question style | Evidence expectation |
|---|---|---|
| Exact equipment code | Ask for the instructions for that code. | The applicable code remains identifiable in retrieved text. |
| Plain-language procedure | Ask the same task using different wording. | The procedure can be found without exact phrase repetition. |
| Similar code, different item | Ask about the original code. | A neighboring identifier is not substituted silently. |
| Rule and qualifying condition | Ask whether the rule applies in a specific case. | Both rule and qualification are available to answer generation. |
These are proposed cases, not recorded retrieval results. Label the needed passages before any trial. A code lookup needs identifier fidelity; a paraphrase needs conceptual coverage, so judge their combination against those two demands. Do not assume that the presence of both signals produces a complete or correct context.
Related: RAG Chunking Strategy.
2. Treat external search configuration as a prerequisite
You need an OpenSearch service you are authorised to query, an index containing the prepared corpus, credentials scoped to the intended operations and a suitable embedding connection. Before generating answers, arrange the required provider account and key using the Language Model connection instructions; the model provider and external search service charge separately from workflow runs.
Have the search-service administrator document the actual lexical, semantic and combined configurations used for comparison. Consult the official OpenSearch hybrid-search documentation for external setup. That documentation was not verified in this offline draft; this page makes no version-specific claim about supported queries, processors or engine behavior.
Check the use-case library for the Hybrid Search RAG starter’s prerequisites before choosing it as a starting point. Do not treat that starter as a runtime test of the OpenSearch design below. This procedure uses the exported OpenSearch contract and keeps service setup separate from builder field settings.
3. Inspect what the component actually exposes
OpenSearch’s catalogue description names semantic and keyword capabilities together, which motivates the code-versus-paraphrase comparison here. Its search inputs include search_query, index_name, number_of_results, embedding and filter_expression. Its outputs are search_results as JSON, dataframe as Table and vectorstoreconnection as VectorStore.
The export contains no input explicitly named hybrid mode, lexical weight, fusion rule or normalization pipeline. engine lists choices, but an engine name does not establish how lexical and semantic results are combined. Do not invent a hybrid toggle or put undocumented structured query syntax into search_query; that field accepts a Message connection.
4. Configure an inspection path against a prepared index
Prepared-index inspection: example configuration, not a recorded test
| Component | Catalogue inputs to set | Inspection before continuing |
|---|---|---|
| OpenSearch | opensearch_url: authorised service; index_name: prepared test index; auth_mode: "basic" or "jwt" as configured; use_ssl: true; verify_certs: true. | Verify endpoint access and valid certificates without publishing credential values. |
| OpenSearch search settings | search_query: one labelled question; number_of_results: 5; embedding: configured Embeddings connection where required; vector_field: administrator-confirmed field. | Five is an illustrative result request, not a provider limit or native hybrid setting. |
| Prompt Template | template: reviewed evidence text, original question and source-grounding instructions. | Enter evidence manually for the initial inspection; dynamic bindings require editor verification. |
| Language Model | input_value: Prompt Message; model: configured LanguageModel; system_message: answer from supplied evidence only. | Inspect the answer separately from the retrieval trial. |
Keep ingest_data unset during this proposed search-only trial. Leaving it empty avoids an intentional ingestion request, but cannot restrict what the credential permits. Enforce those rights in the external service. Check authentication requirements with the administrator, including the meaning of JWT fields, before using real data.
5. Compare observed lexical, semantic and combined results
Use the same corpus snapshot and question set for all search configurations. Obtain independently identified results for lexical-only, semantic-only and combined retrieval from the external test environment. If the builder cannot select those modes through a verified configuration, record that limitation rather than relabelling three identical calls as distinct experiments.
For each question, save returned passage identifiers, order and applicable filters. Inspect exact-code errors, paraphrase misses and missing qualifying passages. Record the actual service configuration with each observation. Confirm the combined run from its service configuration; neither the component wording nor the returned list demonstrates signal weighting.
Keep external service permissions outside the signal experiment; the knowledge-base guide explains how to prepare a simpler retrieval baseline.
Hold the eligible source set constant when comparing lexical, semantic and combined runs. Otherwise a newly allowed passage may explain an apparent retrieval gain. Keep a record of both the administrator-confirmed configuration and the eligible corpus for each run; the exported filter_expression field does not supply its grammar or demonstrate which filters actually ran.
6. Review evidence before drafting an answer
Follow the formatting-boundary checks in knowledge-base chatbot and the Prompt Template reference when preparing retrieved evidence for generation.
A useful hybrid-specific comparison pairs two questions about the same synthetic item: one names its exact equipment code and the other describes its purpose without the code. Record which source identities survive both questions under each external configuration. If the exact-code question retrieves a neighboring item while the paraphrase succeeds, a combined average would hide the identifier defect. Keep the pair together in review, and inspect the combined evidence before allowing a model’s wording to obscure the substitution.
The expected answer has claims tied to the returned source passages and an explicit gap where evidence is missing. It must preserve the requested identifier exactly. Use RAG evaluation for passage coverage and grounding. If candidate ordering is the remaining issue, examine RAG reranking; reranking is a later selection stage, not evidence that hybrid retrieval was configured.
7. When is hybrid search unnecessary?
Do not add external search infrastructure when a simpler retrieval path already meets the question set. Hybrid retrieval does not repair missing source documents, ambiguous identifiers or improperly prepared text. The knowledge-base retrieval guide gives a smaller starting point when its documented scope fits your corpus.
This proposal does not establish hosted index provision, native mode controls, engine compatibility, query grammar or automatic failure recovery. The export also lacks a measured latency or quality comparison. Confirm the external configuration and inspect its outputs before describing any builder run as hybrid search. Keep generation disconnected when retrieval fails instead of drafting an answer from an error payload.
Hybrid-search usage assumptions
Plans: Go from USD8/month billed yearly (USD10 monthly), Plus from USD16 (USD20 monthly), Pro 100 from USD80 (USD100 monthly), Pro 200 from USD160 (USD200 monthly) and Pro 500 from USD400 (USD500 monthly), with 5,000 to 250,000 Flowi Tokens/month and top-ups; 1 token per node run; third-party API and model usage is not included.
Budget for external indexing, embeddings, retrieval comparisons and model generation separately. A requested result count does not describe how the search service bills its work.