Comparison
Count your distinct questions before buying retrieval
A scripted FAQ bot answers a fixed set of questions with authored text and never invents anything. A retrieval assistant answers open questions from your documents and can be wrong in confident-sounding ways. Count your distinct questions: below roughly thirty, scripted wins on cost, latency and trust.
Count your distinct questions before buying retrieval: the decision in facts
- Compared against
- A scripted FAQ bot
- Dimensions compared
- 8, including answer correctness and question coverage
- Where we lose: Certainty
- A retrieval assistant can produce a plausible wrong answer
As of 2025-10-01, Telegram Bot API 13.4
What is actually being compared
Retrieval-augmented generation is currently being sold as an upgrade to every FAQ bot, and for a large share of businesses it is a downgrade dressed as progress. If your customers ask twenty questions and eighteen of them are the same five, authored answers are faster, cheaper, always correct and always in the right tone. Adding retrieval to that buys latency, cost and a new failure mode.
The test that works is counting distinct questions in your actual support history over a few months. A concentrated distribution — a short head of common questions and a thin tail — says scripted. A long flat distribution, where hundreds of questions each appear once or twice, says retrieval, because authoring hundreds of answers is not a bounded task and the tail is where the effort would go.
The second consideration is what a wrong answer costs. A scripted bot cannot be wrong about something it was not told; it either matches or escalates. A retrieval assistant can produce a plausible answer to a question your documentation does not cover, and the reader cannot tell that from a good one. In a clinical, legal or financial context that asymmetry decides the question regardless of how the distribution looks.
Side by side
| Dimension | a scripted FAQ bot | A custom build |
|---|---|---|
| Answer correctness | Exactly what was authored. Cannot be wrong about anything else. | Usually correct, occasionally confidently wrong. The citation is the mitigation. |
| Question coverage | What was anticipated. Everything else escalates. | Anything the corpus covers, including phrasings nobody predicted. |
| Latency | Instant. A lookup. | Seconds. Retrieval plus inference. |
| Running cost | Effectively nothing. | Per-question inference and embedding, plus re-embedding on model changes. |
| Build cost | Modest, dominated by authoring the answers. | Substantially higher, dominated by ingestion, chunking and refusal behaviour. |
| Maintenance | Edit an answer. Anyone can do it. | Keep the corpus current. A stale index degrades silently. |
| Tone control | Absolute. Every word was written by you. | Approximate. Generated text is constrained rather than authored. |
| Multilingual | Authored per language, which is bounded work and always correct. | Handled, with retrieval quality varying by language and worse on Arabic technical text. |
Which one fits your situation
Choose a scripted FAQ bot when
- Your support history shows a short head of common questions carrying most of the volume.
- A wrong answer has clinical, legal or financial consequences and there is no review step.
- Tone matters enough that every answer should be written by a person.
- Your documentation is thin, out of date, or does not exist in a form anything could read.
- You need instant answers, because seconds of latency changes how the bot feels.
Choose a custom build when
- Your question distribution is long and flat, with hundreds of distinct questions each appearing rarely.
- You have a substantial, current corpus that people genuinely cannot find things in.
- The cost of a colleague answering these questions is real and measurable.
- You can put a human behind the escalation path for anything retrieval declines.
- Citations are acceptable to your audience as a way of checking an answer.
Where we lose
- Certainty. A scripted bot cannot invent an answer; a retrieval assistant can produce a plausible one to a question your documents do not cover, and no technique removes that entirely.
- Latency and running cost, both of which are effectively zero for a lookup and are not for inference.
- Tone. Authored answers are written by you; generated ones are constrained toward your material rather than written in your voice.
- Maintainability by non-technical staff. Editing an authored answer is a text change anyone can make; fixing a retrieval failure means fixing the corpus, which is a bigger conversation.
If you are already on it, how the move works
Export three months of support conversations and count
Distinct questions and their frequency. This is the whole decision and it takes an afternoon. A concentrated head says scripted; a long flat tail says retrieval.
commandsAuthor the head regardless of which you choose
Even with retrieval, the top questions should be authored answers served directly. They are the ones customers judge you on and there is no reason to let a model paraphrase them.
commandsAssess the corpus before committing to retrieval
Current, structured, and readable by something other than a person. Where it is not, fixing the documentation is the project and retrieval on top of it comes later.
webhookSet the relevance floor before launch
The score below which the assistant declines rather than attempts. That single threshold does more for trustworthiness than any model choice, and it has to be tuned against real questions.
commandsRoute every refusal to a person and mine the log
Refusals are the backlog. Each one is either a documentation gap or a question that should have an authored answer, and reviewing them monthly is what makes the assistant improve.
forum-topics
Questions people ask when deciding
How many distinct questions justifies retrieval?
There is no universal number, and the shape matters more than the count. A short head carrying most volume favours authored answers however many questions exist in total. A long flat tail favours retrieval, because authoring it is not a bounded task.
Can we use both?
Yes, and it is usually the best arrangement. Authored answers for the top questions served directly, retrieval for everything else, and a human behind the refusals. There is no reason to let a model paraphrase the answers customers judge you on.
What is the real risk with retrieval?
A confident answer to a question your documentation does not cover, which the reader cannot distinguish from a good one. Citations make checking possible rather than automatic, which is why the relevance floor and the refusal path are the actual product.
Does retrieval need good documentation?
It needs current and structured documentation. Retrieval quality is bounded by chunking and chunking is bounded by structure, so a corpus of scanned PDFs with no headings retrieves badly regardless of the model. Sometimes the honest recommendation is to fix the documentation first.
Is a scripted bot old-fashioned?
It is appropriate or inappropriate, which is a different axis. For a concentrated question distribution it is faster, cheaper, always correct and always in your tone. Choosing it deliberately is not a failure to keep up.
What does the running cost look like?
Per-question inference and embedding, plus re-embedding when the model changes. Modest per question and real at volume, and it belongs in the year-one budget rather than being discovered in the second month.
Related reading
The retrieval side, including refusal behaviour, is described in the AI assistant build.
The scripted side, with authored answers per language, is the multilingual support build.
What makes a corpus retrievable is covered in the Notion integration.
For the surrounding support tooling question, see the Intercom comparison.