The standard advice for building a retrieval system is “just throw everything into an embedding model”, and on real applications it performs badly. I have spent the last 14 years fixing broken search implementations in WordPress and WooCommerce, and semantic similarity on its own inside an Agentic RAG setup fails quietly, which is the worst way for it to fail.
On a recent project the AI had to pull technical documentation by specific part ID. The vector search was close enough semantically, in that it found the right category of parts, but it missed the exact ID because the embedding math drowned that identifier in a sea of similar context. The agent then hallucinated a solution, since the context it had retrieved was garbage.
Why your agentic RAG needs BM25
Vector similarity is good with synonyms and typos. Ask for a “lift” when your docs say “elevator” and vector search gets you there. It is bad at hard keyword matching, though, which is exactly where product SKUs, version numbers and unique identifiers live, because none of them carry a semantic meaning in embedding space.
That is the job of BM25 (Best Matching 25), a ranking function that rewards exact keyword matches while accounting for document length. Run a hybrid search, with BM25 for precision and vector search for context, and your Agentic RAG gets both. It also cuts the noise that tends to confuse the LLM.
Balancing keywords and context
In WordPress the tempting move is to use a plain WP_Query search as your keyword layer. That holds up on a basic site, but a real hybrid system needs one unified ranking. The usual shape is to take the top 10 results from the vector DB and the top 10 from the keyword index, then merge them with Reciprocal Rank Fusion (RRF).
If you are building an AI application, think about how the agent uses these tools. A naive agent asks for “results” and takes whatever comes back. A better designed one knows what its own retrieval layer is bad at.
<?php
/**
* Mock-up of a Hybrid Search Tool for an Agentic RAG System
* bbioon_hybrid_retrieval
*/
function bbioon_hybrid_retrieval( $query, $alpha = 0.5 ) {
// 1. Semantic Search (Vector)
$vector_results = bbioon_get_vector_search( $query );
// 2. Keyword Search (BM25 or WP_Query fallback)
$keyword_results = bbioon_get_keyword_search( $query );
// 3. Apply Weighting (Filter)
// $alpha determines if we lean more on Vector (1.0) or Keyword (0.0)
$final_context = bbioon_rank_fusion( $vector_results, $keyword_results, $alpha );
return $final_context;
}
?>Iterative retrieval
The agentic part of Agentic RAG is that the LLM orchestrates retrieval instead of passively receiving data. When the hybrid search comes back with nothing for a specific ID, the agent can notice. It rewrites the query, drops the filler words, and runs it again as a keyword search.
The loop is not far off how we debug legacy code. You do not stop at one log file: you check the PHP error logs, then Nginx, then the database transients, until the pattern shows up. For more on structuring these systems, there is my critique of architecture patterns for reliable AI.
If agentic RAG is eating your dev hours, hand it to me. I have been wrestling with WordPress and complex data integrations since the 4.x days.
The takeaway
Retrieval precision is worth more than the newest embedding model. Hybrid search is what makes an AI system hold up in production, because vectors bring the semantic depth and BM25 brings keyword-level accuracy. Between them you stop losing the small details, and the small details are where a user’s trust actually sits.
