Every organisation with a large knowledge base has had the same meeting. Members say they cannot find anything. Someone proposes better tagging, a new taxonomy, or a search upgrade. Six months later, the numbers have barely moved. The reason is not that the search is badly configured. It is that a search bar and a question are two different things.
What a search bar actually does
A classic site search, including Drupal's Search API with a Solr or database backend, matches the words you type against the words in your content. Modern setups add stemming, synonyms, and relevance weighting, which helps. But the fundamental contract stays the same: you supply the vocabulary, and the system finds documents containing it.
That contract works well when the user already knows the right term. A lawyer looking for "non-compete clause" will find it. A member looking for the exact title of a circular will find it. Search is fast, cheap, predictable, and easy to explain.
Where it breaks down
The problem is that most people arrive with a situation, not a term. They think: "a client wants to cancel halfway through the contract, what am I allowed to charge?" Your archive answers that question thoroughly, in an article your editor titled "Contractual termination and proportional compensation". The words do not overlap. Search returns nothing useful, and the member concludes the answer does not exist.
Three specific failure patterns come up again and again:
- Vocabulary mismatch. Editors write in formal or legal language. Members describe practical problems. The gap between those two vocabularies is where most searches die.
- Answers spread across articles. The rule is in one document and the exception is in another. Search can only hand back a list and hope the reader assembles it.
- No sense of recency. A 2019 article and its 2025 replacement both match the query. Search has no opinion about which one is still true.
None of this is fixed by better tagging. You can spend a year improving your taxonomy and members will still not use the words in it.
What a private AI chatbot does differently
A private AI chatbot built on retrieval augmented generation matches on meaning rather than on words. Your articles are converted into numerical representations that capture what a passage is about. A question is converted the same way, and the system retrieves the passages that are closest in meaning, whether or not they share any vocabulary with the question.
The model then writes an answer using only those passages, and links back to the articles it used. For the cancellation question above, that means the member gets the rule, the exception, and both source articles, in one response.
An honest comparison
A chatbot is not better at everything. Search still wins in several situations, and pretending otherwise leads to disappointed users:
- Exact lookups. Someone who wants document reference 2024/17 wants that document, not a paraphrase. Search is faster and more reliable.
- Browsing. Users who want to see everything published on a topic need a filterable list, not a summary.
- Cost and speed. A search query is essentially free and instant. A chatbot answer takes a few seconds and costs money per question.
- Predictability. Search returns the same results every time. A generated answer can be phrased differently on two identical questions, which some organisations find uncomfortable.
Where the chatbot wins is equally clear: questions phrased as situations, answers that live in more than one article, users who do not know your terminology, and archives deep enough that browsing is not realistic.
Why most sites end up running both
The right conclusion for a large knowledge base is usually not "replace search". It is "add a second front door". Keep the search bar for people who know what they want, and add a chatbot for people who only know what their problem is. On a Drupal site this is straightforward, because the chatbot can sit next to your existing Search API setup rather than on top of it.
In practice you can watch the split happen in the logs. Short queries of one or two words keep going to search. Full sentences go to the chatbot. Members sort themselves without being told to.
The part that decides your options
If your knowledge base is behind a login, most chatbot products on the market are immediately out. They work by crawling public pages, which means they stop at your login screen, which is where your valuable content starts. A chatbot for gated content has to read your content through the CMS and apply your access rules before retrieval. We cover exactly how that works in AI chatbots for content behind a login.
How to decide
Three questions usually settle it. First, how many articles do you have? Under a few hundred, better navigation may genuinely be enough. Second, do members describe situations or use your terminology? Look at your support inbox, not your search logs, because the questions people fail to search for end up there. Third, is your content current? A chatbot on a neglected archive will confidently quote outdated material, and that damages trust faster than a bad search result ever did.