Search is one of the most important parts of an AI application.
A RAG system can have an excellent language model and still produce poor answers if the retrieval layer returns the wrong documents.
The problem is that enterprise search usually needs two different kinds of relevance.
Keyword search is good at finding exact terms, product codes, names, error messages, and technical identifiers.
Vector search is good at understanding semantic similarity when the user's wording does not exactly match the stored content.
For example, suppose a knowledge base contains:
The application experienced excessive memory consumption
during background processing.
A keyword search for:
memory consumption
can find it directly.
But a user might ask:
Why is the background worker using too much RAM?
The wording is different, but the meaning is similar.
Vector search can recognize that relationship.
AlloyDB for PostgreSQL now provides a database-native approach for combining these search strategies using Reciprocal Rank Fusion (RRF).
The result is a hybrid search architecture that can combine semantic and lexical relevance without requiring developers to build all the ranking and result-merging logic in application code.
Why Hybrid Search Is Better Than Choosing One Search Method
Neither keyword search nor vector search is universally better.
Consider a technical support database containing:
.NET 10
ASP.NET Core
Redis
PostgreSQL
Kubernetes
HTTP 500
ERR_CONNECTION_RESET
A user searching for:
ERR_CONNECTION_RESET
probably expects an exact lexical match.
Vector search may understand the general concept of network failures, but exact identifiers are often better handled by traditional text search.
Now consider:
How do I prevent a background service from consuming excessive memory?
A document might discuss:
Worker process memory pressure
without ever using the phrase "excessive memory."
Semantic search can find that relationship.
This leads to a useful division:
Keyword Search
|
+--> Exact terms
+--> Product names
+--> Error codes
+--> Identifiers
+--> Names
Vector Search
|
+--> Meaning
+--> Concepts
+--> Similar wording
+--> Context
Hybrid search combines both.
What Is Reciprocal Rank Fusion?
Reciprocal Rank Fusion is a ranking technique for combining multiple ranked result sets.
Suppose a query produces two lists.
Keyword results
Rank Document
1 A
2 B
3 C
4 D
Vector results
Rank Document
1 C
2 A
3 E
4 B
Document A performs well in both lists.
Document C performs particularly well in vector search and reasonably well in keyword search.
Document D appears only in keyword search.
RRF gives each document a contribution based on its rank in each result set.
A simplified formula is:
RRF Score = Σ 1 / (k + rank)
where k is a constant used to reduce the effect of very small rank differences.
The important characteristic is that RRF combines rank positions, rather than requiring the application to normalize unrelated score scales.
That matters because vector similarity scores and full-text relevance scores do not naturally share the same numerical meaning.
Why Score Normalization Is Difficult
Imagine vector search returns:
0.91
0.88
0.84
0.79
while keyword search returns:
17.4
12.1
8.6
4.3
Comparing these values directly is meaningless.
Developers could normalize them manually.
But normalization creates another problem:
What normalization strategy should be used when the distribution of scores changes?
The result can become fragile.
RRF avoids this particular problem by working from the relative position of each document in its search result list.
AlloyDB's hybrid search function uses RRF to merge the ranked results.
AlloyDB's Database-Native Approach
Previously, developers could implement hybrid search themselves.
A typical architecture looked like:
Application
|
+--> Vector Search
|
+--> Full-Text Search
|
v
Application Code
|
+--> Merge results
+--> Normalize scores
+--> Rank results
+--> Remove duplicates
|
v
Final Results
That works, but it creates additional application complexity.
AlloyDB's hybrid_search() function can perform the combination within the database.
Conceptually:
Application
|
v
AlloyDB
|
+--> Vector Search
|
+--> Full-Text Search
|
v
RRF Fusion
|
v
Ranked Results
The current implementation accepts multiple search inputs and supports vector and text search components, with weights available to influence their contribution.
A Typical Document Table
A simplified PostgreSQL-style table might look like:
CREATE TABLE documents
(
id TEXT PRIMARY KEY,
content TEXT NOT NULL,
embedding VECTOR,
content_tsv TSVECTOR
);
The exact vector type and indexing configuration depend on the embedding dimensions and AlloyDB setup.
For full-text search, PostgreSQL's text-search infrastructure can be used.
For semantic search, a vector index such as ScaNN or HNSW can accelerate similarity searches depending on the chosen configuration. AlloyDB supports both vector and full-text search approaches for hybrid retrieval.
Full-Text Search Still Matters
It is easy to assume that vector databases make traditional search obsolete.
They do not.
Consider a user searching for:
CVE-2026-12345
or:
customer_id = 84927
or:
System.InvalidOperationException
Exact matching is extremely valuable.
A semantic model may understand that these strings relate to software or customer records, but understanding the concept is not the same as locating the exact identifier.
Traditional full-text search remains useful for these cases.
AlloyDB supports full-text search options including GIN, RUM, and BM25-based approaches, depending on the PostgreSQL version and configuration.
RUM and BM25 Add Another Dimension
Hybrid search does not mean there is only one way to perform text search.
For example, AlloyDB supports RUM indexes for relevance-oriented text search and phrase matching.
It also supports native BM25 search for probabilistic keyword ranking on supported PostgreSQL versions.
That gives developers choices:
Search
|
+----------+----------+
| |
Semantic Lexical
| |
Vector Full Text
| / | \
ScaNN GIN RUM BM25
|
+----------+
|
v
RRF
|
v
Final Ranking
The right configuration depends on the application's data and relevance requirements.
A Simple Hybrid Search Flow
A typical AI search request might look like this:
User Query
|
v
Generate Query Embedding
|
+-------------------+
| |
v v
Vector Search Text Search
| |
v v
Top 20 Results Top 20 Results
| |
+---------+---------+
|
v
RRF
|
v
Top 10 Results
|
v
RAG Context
|
v
AI Model
The retrieval system can then pass the strongest results to the language model.
This is generally preferable to sending a large number of loosely relevant documents to the model.
Why Retrieval Quality Matters for RAG
A language model cannot reliably answer from information that was never retrieved.
Consider:
Question
|
v
Retriever
|
X
Wrong documents
|
v
Model
|
v
Incorrect answer
Improving the model does not necessarily solve the retrieval problem.
A better retrieval pipeline is:
Question
|
v
Hybrid Retrieval
|
v
Better ranked documents
|
v
Model
|
v
Better grounded answer
This is why hybrid retrieval is increasingly important in enterprise RAG systems.
Using Weights
AlloyDB's hybrid search configuration allows search components to have weights.
Conceptually:
Vector weight = 0.7
Text weight = 0.3
or:
Vector weight = 0.4
Text weight = 0.6
The appropriate balance depends on the application.
A conversational knowledge base may benefit from stronger semantic retrieval.
A technical documentation system containing many exact API names and error codes may benefit from stronger lexical retrieval.
Do not choose weights simply because they look reasonable.
Measure them against a representative evaluation dataset.
Search Evaluation Is Essential
Search quality should be measured using real queries.
Create a test set such as:
Query
Expected documents
Acceptable documents
Required keywords
Then compare:
Keyword only
Vector only
Hybrid
Useful metrics can include:
Recall@K
Precision@K
MRR
NDCG
For example, if the correct document appears in the top 10 results much more frequently with hybrid search, that is meaningful evidence that the approach is helping.
Without an evaluation set, ranking changes become subjective.
Hybrid Search Is Not Automatically Better
Adding two search systems does not guarantee better relevance.
Poor vector embeddings can produce poor semantic results.
Poor text indexing can produce poor lexical results.
Bad tokenization can reduce exact-match quality.
And poorly chosen ranking parameters can produce unexpected results.
The architecture should therefore be evaluated as a complete retrieval pipeline:
Data
|
v
Chunking
|
v
Text Index
+
Vector Index
|
v
Hybrid Ranking
|
v
Evaluation
Improving only the final fusion algorithm cannot compensate for bad input data.
Chunking Still Matters
Consider a large document:
Enterprise Security Architecture
If it is stored as one giant chunk, vector retrieval may return the document because one paragraph is relevant even though most of the content is unrelated.
If it is divided into meaningful sections:
Authentication
Authorization
Network Security
Encryption
Incident Response
retrieval can become more precise.
Hybrid search does not eliminate the need for good document segmentation.
Filtering Before or During Retrieval
Enterprise systems often need metadata filters.
For example:
Tenant = "contoso"
Department = "engineering"
DocumentType = "architecture"
A search request should not retrieve documents from another tenant and then rely on application code to remove them.
Filtering should be part of the retrieval design.
AlloyDB's hybrid search parameters include filter conditions that can be applied to individual search components.
This becomes particularly important in multi-tenant AI systems.
Hybrid Search and Multi-Tenancy
Consider a SaaS application:
Tenant A
|
+--> Documents A
Tenant B
|
+--> Documents B
A hybrid query should respect tenant boundaries.
The desired flow is:
Tenant A Query
|
v
Tenant Filter
|
+--> Vector Search
|
+--> Text Search
|
v
RRF
|
v
Tenant A Results
Do not retrieve globally and filter afterward.
That approach can create both security and performance problems.
Application Integration With C#
For .NET applications, the database can remain responsible for search while C# handles request orchestration.
A simple abstraction might look like:
public sealed record SearchRequest(
string Query,
string TenantId,
int Limit);
public sealed record SearchResult(
string DocumentId,
double Score);
The service can expose a narrow interface:
public interface IDocumentSearch
{
Task<IReadOnlyList<SearchResult>> SearchAsync(
SearchRequest request,
CancellationToken cancellationToken);
}
The important design choice is that the C# application does not need to implement its own RRF algorithm if AlloyDB is already responsible for hybrid fusion.
That keeps ranking logic closer to the data retrieval operation.
Keep the Retrieval Layer Separate
A clean architecture might look like:
ASP.NET Core API
|
v
Search Service
|
v
AlloyDB
|
+--> Full-text search
+--> Vector search
+--> Filters
+--> RRF
|
v
Ranked documents
|
v
RAG service
|
v
Language model
This separation makes it easier to test retrieval independently from model generation.
That is valuable because a retrieval problem should not be diagnosed as an LLM problem.
Performance Considerations
Hybrid search performs multiple retrieval operations.
That means developers should pay attention to:
Index configuration
Candidate count
Query filtering
Database CPU
Memory
Network latency
Embedding generation latency
Result size
If the application retrieves hundreds of documents from each search strategy and then processes everything in the application layer, latency can grow quickly.
A database-native approach can reduce unnecessary data movement because the ranking and fusion occur closer to the underlying data.
However, database-native fusion does not make inefficient queries free.
Indexes and query plans still matter.
Don't Retrieve Too Many Candidates
Suppose the final system needs 10 documents.
It may be tempting to retrieve:
Vector: 1000
Text: 1000
and merge everything.
That increases work.
A better starting point might be:
Vector: 50
Text: 50
RRF: top 10
Then measure retrieval quality.
The optimal candidate count depends on the dataset and workload.
The goal is to find the smallest candidate set that maintains acceptable recall.
Common Mistakes
Assuming vector search replaces keyword search
Exact identifiers and terminology remain important.
Combining raw vector and text scores
The score scales are not directly comparable.
RRF is useful precisely because it operates on ranking rather than requiring fragile score normalization.
Choosing weights without evaluation
Weights should be based on real search performance.
Ignoring metadata filters
Tenant, department, security, and document-type filters should be part of retrieval.
Retrieving everything and filtering in application code
This wastes resources and can create security problems.
Sending too many results to the LLM
More context is not automatically better context.
Ignoring chunking
Poor document segmentation can undermine otherwise good retrieval.
Measuring only model quality
Evaluate the retrieval system separately from the language model.
Advantages and Disadvantages
Advantages
Better retrieval coverage: Semantic and lexical search can complement each other.
Exact-match support: Keyword search remains effective for identifiers, names, and technical terms.
Semantic matching: Vector search can find relevant information even when wording differs.
Simpler application architecture: Database-native fusion reduces custom ranking logic.
Flexible search composition: Hybrid search can combine different search components and apply filters.
Better fit for RAG: Improved retrieval can provide more relevant context to downstream language models.
Disadvantages
More indexing complexity: Applications may need both vector and text indexes.
Additional compute: Two retrieval strategies require more work than a single search method.
More tuning: Candidate limits, weights, indexing, chunking, and filtering all affect relevance.
Not a substitute for evaluation: Hybrid search still needs a representative benchmark.
Data preparation remains important: Poor source data produces poor search results regardless of ranking.
When Hybrid Search Makes Sense
Hybrid search is particularly useful for:
Enterprise knowledge bases
Technical documentation
Product catalogs
Customer support
RAG applications
Legal document search
Internal engineering portals
AI-powered database applications
It is less useful when the search problem is inherently simple.
For example, if an application only needs:
Find customer by exact ID
traditional indexing may be enough.
If the requirement is:
Find documents that discuss alternatives to reducing
memory usage in background workers.
semantic search becomes more useful.
If the application needs both behaviors, hybrid search is a strong candidate.
A Practical Implementation Strategy
A sensible rollout is:
Start with a representative document dataset.
Implement conventional full-text search.
Add vector embeddings and semantic search.
Build a query evaluation dataset.
Compare keyword-only and vector-only retrieval.
Introduce RRF-based hybrid ranking.
Test different candidate counts and weights.
Add metadata and tenant filtering.
Measure latency and database resource consumption.
Integrate the final retrieval layer with the RAG pipeline.
Monitor search quality after deployment.
This approach prevents the common mistake of introducing hybrid search without knowing whether it actually improves the application's results.
Summary
AlloyDB's support for Reciprocal Rank Fusion makes hybrid search easier to implement directly inside PostgreSQL-compatible database workflows.
The fundamental idea is straightforward:
Full-Text Search
+
Vector Search
|
v
RRF
|
v
Better Ranked Results
Keyword search provides precision for exact terms and identifiers.
Vector search provides semantic understanding when the user's wording differs from the stored content.
RRF combines the ranked results without requiring developers to directly compare incompatible score scales.
For .NET developers building RAG applications, this can simplify the retrieval architecture considerably. Instead of implementing search, score normalization, merging, and ranking logic across multiple application components, the database can handle a larger part of the retrieval workflow.
The important engineering lesson remains the same: hybrid search is a retrieval strategy, not a guarantee of relevance. Good indexing, document chunking, filtering, evaluation, and performance testing are still required.
When those pieces are designed together, database-native hybrid search can become a practical foundation for enterprise AI and RAG applications.
Join the conversation! Your thoughts help the community grow.