J
John Iwuozor
Guest
When is traditional search enough, and when do you need to upgrade to RAG search for your website?
Retrieval-augmented generation (RAG) has become the answer to an awful lot of enterprise search problems. Employees can’t find a policy? Add RAG. Customers are digging through product manuals? Put an AI answer box on top of them.
Sometimes that’s exactly the right move. Sometimes, though, the problem is considerably less glamorous: the right information exists, but your search experience is doing a poor job of surfacing it.
A RAG system still has to retrieve information before a language model can do anything useful with it.
So if poor indexing, inconsistent metadata, weak relevance or five versions of the same document are getting in the way, adding generation does not magically clean all of that up. You may simply end up generating a nicer answer from the wrong information.
A useful way to separate the two is to look at what users are actually struggling with:
The former is more likely a search-and-retrieval problem, while the latter is where RAG makes for a stronger case.
By “search” here, I mean the search experience across your own website, documentation, knowledge base, intranet or other enterprise content.
Enterprise search has to crawl and index your own information, understand a user’s query and decide which of your documents or pages deserve to appear first. And modern search can already do quite a lot.
Say an employee wants the company’s parental leave policy. If they search for it and the current policy appears at the top of the results, there is not much mystery left to solve. The same goes for a customer looking for a particular product manual, someone browsing events in London, or a visitor trying to narrow 500 products down by category and price.
In cases like those, the user mostly needs the right thing, not an AI-written interpretation of it.
Search does not have to be painfully literal either. Hybrid search can combine keyword matching with semantic search, which is useful because people do not always search in the same way.
Sometimes they know exactly what they want and type a product code or document name. Other times, they describe the problem in their own words and expect search to understand what they mean. A good search experience needs to handle both.
So if people are consistently failing to reach a page or document that would answer their question perfectly well once they found it, I would look pretty hard at search before assuming generation is the missing piece.
RAG becomes more useful when finding the right source still leaves the user with work to do.
Say a customer wants to know whether a particular product will work with their existing setup. The answer might sit across a product page, a compatibility guide, a technical manual and a support article. Search can surface all four, but the customer still has to open them, compare the details and work out what applies.
RAG can take some of that work off their hands. It can retrieve the relevant parts, pass them to a language model and turn several sources into one useful answer while still pointing back to the sources behind the answer.
Image generated with ChatGPT
In other words, search is very good at “find me the thing.” RAG starts making sense when the request sounds more like “read the relevant things and help me work this out.”
That does not mean every complicated question automatically needs RAG. Some queries still depend heavily on exact terminology, while others need semantic similarity or information pulled from more than one source.
In some cases, multi-hop retrieval can help when one piece of information leads to the next search needed to complete the answer.
There is one slightly inconvenient part of all this. RAG can make information easier to consume, but it cannot make bad information true.
If the underlying content is outdated, contradictory or poorly organized, the system still has to work with it.
And because RAG turns retrieved information into a direct answer, those problems do not always look like problems anymore. A messy source can come back as something polished, confident and completely believable.
That is why the quality of the content underneath the retrieval layer matters so much. RAG pipelines are only as reliable as the data and context feeding them, which means better retrieval and better models can only take you so far if the source material itself is unreliable.
So before treating RAG as the fix for a weak search experience, it’s worth asking whether the real issue sits further upstream.
This is where the “search vs. RAG” framing starts to fall apart a little. RAG does not really replace search. It depends on retrieval, then adds another layer on top.
Someone visiting a support site might want a direct answer to “How do I reset this device after a failed update?” A few minutes later, that same person might want every technical bulletin for the model. One is a synthesis task. The other is much closer to ordinary search.
There is no real reason the user should have to choose between the two.
That is also how Progress Sitefinity AI Search approaches the problem. It can generate answers from relevant content while still surfacing the underlying sources, so users can move between getting an answer and checking the material behind it.
So, do you actually need RAG? Maybe. If users cannot find information that already answers their question, search probably deserves attention first.
If they can find the material but still have to open five tabs, compare what each one says, and piece the answer together themselves, RAG has a much clearer job to do.
And if both things happen depending on the question, which is entirely plausible, then “search or RAG?” was probably the wrong choice to force in the first place.
Join the webinar: How Sitefinity CMS and Agentic AI Drive Search and AI Discoverability. October 22 at 11 a.m. ET.
Continue reading...
Retrieval-augmented generation (RAG) has become the answer to an awful lot of enterprise search problems. Employees can’t find a policy? Add RAG. Customers are digging through product manuals? Put an AI answer box on top of them.
Sometimes that’s exactly the right move. Sometimes, though, the problem is considerably less glamorous: the right information exists, but your search experience is doing a poor job of surfacing it.
A RAG system still has to retrieve information before a language model can do anything useful with it.
So if poor indexing, inconsistent metadata, weak relevance or five versions of the same document are getting in the way, adding generation does not magically clean all of that up. You may simply end up generating a nicer answer from the wrong information.
A useful way to separate the two is to look at what users are actually struggling with:
- They cannot find the right information, even though it exists.
- They can find the information but still have to read, compare or piece together several sources to get an answer.
The former is more likely a search-and-retrieval problem, while the latter is where RAG makes for a stronger case.
When Search Is Actually the Better Answer
By “search” here, I mean the search experience across your own website, documentation, knowledge base, intranet or other enterprise content.
Enterprise search has to crawl and index your own information, understand a user’s query and decide which of your documents or pages deserve to appear first. And modern search can already do quite a lot.
Say an employee wants the company’s parental leave policy. If they search for it and the current policy appears at the top of the results, there is not much mystery left to solve. The same goes for a customer looking for a particular product manual, someone browsing events in London, or a visitor trying to narrow 500 products down by category and price.
In cases like those, the user mostly needs the right thing, not an AI-written interpretation of it.
Search does not have to be painfully literal either. Hybrid search can combine keyword matching with semantic search, which is useful because people do not always search in the same way.
Sometimes they know exactly what they want and type a product code or document name. Other times, they describe the problem in their own words and expect search to understand what they mean. A good search experience needs to handle both.
So if people are consistently failing to reach a page or document that would answer their question perfectly well once they found it, I would look pretty hard at search before assuming generation is the missing piece.
When RAG Starts to Earn Its Keep
RAG becomes more useful when finding the right source still leaves the user with work to do.
Say a customer wants to know whether a particular product will work with their existing setup. The answer might sit across a product page, a compatibility guide, a technical manual and a support article. Search can surface all four, but the customer still has to open them, compare the details and work out what applies.
RAG can take some of that work off their hands. It can retrieve the relevant parts, pass them to a language model and turn several sources into one useful answer while still pointing back to the sources behind the answer.
Image generated with ChatGPT
In other words, search is very good at “find me the thing.” RAG starts making sense when the request sounds more like “read the relevant things and help me work this out.”
That does not mean every complicated question automatically needs RAG. Some queries still depend heavily on exact terminology, while others need semantic similarity or information pulled from more than one source.
In some cases, multi-hop retrieval can help when one piece of information leads to the next search needed to complete the answer.
RAG Still Depends on Good Content
There is one slightly inconvenient part of all this. RAG can make information easier to consume, but it cannot make bad information true.
If the underlying content is outdated, contradictory or poorly organized, the system still has to work with it.
And because RAG turns retrieved information into a direct answer, those problems do not always look like problems anymore. A messy source can come back as something polished, confident and completely believable.
That is why the quality of the content underneath the retrieval layer matters so much. RAG pipelines are only as reliable as the data and context feeding them, which means better retrieval and better models can only take you so far if the source material itself is unreliable.
So before treating RAG as the fix for a weak search experience, it’s worth asking whether the real issue sits further upstream.
In Many Cases, You’ll Need Both
This is where the “search vs. RAG” framing starts to fall apart a little. RAG does not really replace search. It depends on retrieval, then adds another layer on top.
Someone visiting a support site might want a direct answer to “How do I reset this device after a failed update?” A few minutes later, that same person might want every technical bulletin for the model. One is a synthesis task. The other is much closer to ordinary search.
There is no real reason the user should have to choose between the two.
That is also how Progress Sitefinity AI Search approaches the problem. It can generate answers from relevant content while still surfacing the underlying sources, so users can move between getting an answer and checking the material behind it.
So, do you actually need RAG? Maybe. If users cannot find information that already answers their question, search probably deserves attention first.
If they can find the material but still have to open five tabs, compare what each one says, and piece the answer together themselves, RAG has a much clearer job to do.
And if both things happen depending on the question, which is entirely plausible, then “search or RAG?” was probably the wrong choice to force in the first place.
Winning the Visibility Battle
Join the webinar: How Sitefinity CMS and Agentic AI Drive Search and AI Discoverability. October 22 at 11 a.m. ET.
Continue reading...