Chatbot or knowledge navigator: what you actually need

Not sure which option fits your corpus? We examine sources, permission situation and effort before writing a quote - and advise against it where it does not pay off. See the knowledge navigator

"We need a chatbot" is rarely the right requirement but almost always the first sentence. Behind it sit very different problems: visitors who cannot find what they are looking for. Staff who have to check four different repositories. An editorial team answering the same questions for the twentieth time. Each has one fitting and several unfitting solutions. This article places the four options - including the cases where none of them pays off. As of August 2026.

Contents

• Four options, four different problems
• When a full-text search is enough
• When a support chatbot fits
• When a knowledge navigator pays off
• When it has to be an internal assistant
• The question before the decision: does the corpus hold up?
• What cannot be retrofitted later

Four options, four different problems

The options differ less in technology than in the question they answer - and in what a mistake costs.

Full-text search finds words. It returns a result list and leaves the judgement to the reader. It is cheap, immediately available and underrated.

The support chatbot answers recurring questions on a manageable, slow-changing set of topics. It lives off a maintained answer catalogue, not off a large document corpus.

The knowledge navigator works on a large corpus, formulates solely from sources it has found, and leads to the authoritative passage - with chapter and date. It is built for cases where the answer has to be evidenced.

The internal assistant is a navigator on internal documents with a permission layer in front. That layer is where the real effort sits.

The most common wrong decision is not picking the wrong option but picking one before it is clear which problem is to be solved.

When a full-text search is enough

A good search is the right answer when two conditions coincide: your readers know the terms the content is filed under, and the result list is already useful in itself.

That is more often the case than the market suggests. A professional audience fluent in the terminology copes excellently with a result list - often faster than with a system that first makes them formulate a question.

Search hits its limit where the intent and the filing speak different languages. Someone typing "my server is too slow" finds no page about memory bandwidth, because the word is not there. From that point on, no better search index helps - only a system that understands the intent.

Before you buy an AI system, look at your search logs. If they are dominated by technical terms and people find what they are looking for, your problem is a different one.

When a support chatbot fits

A support chatbot pays off when a manageable number of questions accounts for most of the volume and those questions rarely change. The classic case: opening hours, order status, returns, questions about forms.

The effort here is not in the technology but in the answer catalogue. A chatbot is only as good as the answers someone has written and maintains. Where that catalogue does not exist, it gets created during the project - and that is the actual line item.

Two limits matter. First: as soon as the answers have to come from a large, versioned corpus rather than a catalogue, it is no longer a chatbot problem. Second: as soon as internal documents are involved, the permission question decides - a chatbot let loose on a document repository without that layer is a data leak with a friendly interface.

When a knowledge navigator pays off

A navigator pays off when three things coincide - and none of them is page count alone.

The corpus is versioned. Valid and superseded versions exist, and telling them apart has consequences. Guidelines, standards, procedural instructions, product documentation across several generations. Anyone quoted the wrong version here makes a wrong decision.

Different audiences need different slices. Members, professionals, press and the general public read the same corpus with different needs.

A wrong answer costs something. Not just irritation but time, money or liability. That is the criterion that decides the effort: where a wrong answer is expensive, every answer has to be evidenced - and that is precisely the difference from a chatbot.

Three hundred heavily versioned guidelines are a clear case. Two thousand flat pages without versioning often are not; there a good search is cheaper and faster.

When it has to be an internal assistant

As soon as the corpus is internal and not everyone may see everything, the centre of gravity shifts entirely. The question is no longer how good the answers are but whether the permissions hold technically.

That is not an add-on feature but the architecture. Rights have to be carried over from the source, stored on every passage and applied as a filter before the search - not as an instruction to the language model and not as a post-filter on the result list. The mechanics are covered in RAG with permissions.

There is also a point missing from project plans: a system that logs who asked what is objectively capable of recording behaviour - and therefore subject to co-determination. That costs no development time but calendar time. More on that in AI assistants and the works council.

The question before the decision: does the corpus hold up?

The most expensive wrong decision is none of the four options. It is building a system before the corpus can support it.

A navigator does not make poor content better - it carries it forward more reliably. If superseded versions sit next to valid ones and cannot be told apart, the system cites both. If a third of the documents are scanned PDFs without a text layer, it does not see that third. If permissions have grown as individual shares over years, there is nothing that translates cleanly into a filter.

That is why a corpus analysis comes before a quote: how many documents are machine-readable? How are they structured? Can valid versions be separated from superseded ones? What is the permission situation? Those four answers drive the effort more than any requirements list.

Along the way this regularly surfaces problems that have nothing to do with AI: broken sitemap references, unreachable files, duplicates between language versions. That is a result too - sometimes the most useful one.

What cannot be retrofitted later

Starting small is usually right: one bounded area with maintained content that shows value and answer quality before the whole corpus is touched. Three decisions should nevertheless be right from the start, because changing them later means rebuilding.

Source binding. Whether the system formulates solely from retrieved passages or also from training knowledge is a decision of principle. Tightening it afterwards means rebuilding the answer logic.

Permissions. Adding a permission layer to a system later means touching the index, the data model and the query path. If internal content is foreseeable, the layer belongs in from the start - even if it initially lets everyone through.

Versioning. Whether archived versions are excluded from the search space or merely ranked lower is decided at indexing time. A superseded version that only sits further down will resurface on the next question.

What this means for your project

Do not start with the question of which system you want, but with the question of what a wrong answer costs you. If it is merely irritating, search or a chatbot will usually do. If it is expensive, you need evidence - and therefore a navigator or an internal assistant.

How guided answers with source, chapter and date work is covered in What is RAG?. Where rights have to sit in such a system is in RAG with permissions. When the system should not only answer but act, the question shifts again - see AI agents: permissions and approvals. And where these requirements bite hardest is shown in Local AI for confidentiality professions.