Designing a Support Chatbot That Doesn't Make Things Up
Here’s a request that lands on a lot of engineers’ desks, in one form or another. A company has a big pile of help documentation, product guides, policies, FAQs, troubleshooting steps, and they want a chatbot that answers customer questions from those docs. Accurately. With links to the source. And, above all, without confidently inventing a refund policy that doesn’t exist.
That last part is the whole challenge. If you just hand a raw AI model your question, it’ll answer from its general training, which knows nothing about your specific return window or your shipping rules, and it will happily make something up that sounds right. For a support bot, a made-up answer isn’t a cute mistake. It’s a promise your company now has to honor, or an angry customer, or worse.
So let me walk through how I’d actually design this system, thoroughly. I’ll lay out every approach with its honest pros and cons, build up the real pipeline piece by piece, and, at the very end, show how two big companies, DoorDash and LinkedIn, actually built theirs, with links to their own write-ups so you can read the primary sources. Because the interesting engineering is entirely in the details that stop it from making things up.
First, what does “good” mean here?
Before any architecture, pin down what success looks like, because it drives every decision:
- Grounded. Every answer comes from the company’s actual docs, not the model’s imagination.
- Sourced. The bot can show which document it used, so a human can verify it.
- Honest. If the docs don’t cover the question, it says “I don’t know, let me get a human,” instead of guessing.
- Fast and affordable. Customers won’t wait ten seconds, and the company won’t pay a fortune per chat.
- Safe. No leaking private data, no answering things it shouldn’t, no showing one customer another customer’s info.
Hold those five. We’ll judge every choice against them.
The four ways you could approach this
Before diving into one design, it’s worth seeing the whole menu, because people often grab the wrong option. Here are the four real approaches, each with its honest pros and cons.
Notice why fine-tuning is the classic wrong turn here. It feels like “teach the model our business,” but policies change weekly, and a fine-tuned model can’t tell you which document an answer came from, so a customer can’t verify it and you can’t audit it. Facts belong in retrieval, where you can swap a document and the answer updates instantly. Fine-tuning is for changing behavior (tone, format), not for teaching facts. That single distinction rules out approach 2 for this job.
The naive version, and why grounding is the fix
The first instinct is approach 1: paste the question in, show the answer. Here’s the fix that separates a toy from something real.
Naive: model answers from memory
Customer asks, the raw model answers from its general training. It doesn't know your policies, so it invents plausible-sounding ones. No source, no way to check.
Grounded: answer from your docs
Before answering, the system finds the relevant passages from your actual docs and makes the model answer only from those, with a citation.
The shape of the system: prepare once, answer live
There are two distinct phases, and keeping them separate is the first design insight. One happens once, ahead of time (getting the docs ready to search). The other happens every time a customer asks.
Prep phase (once, offline)
Answer phase (every question)
The live path, step by step
Here’s what happens the moment a customer types a question. Six steps, and each one earns its place.
Choice #1: how you search, and the trade-off
You’d think “search by meaning” (using embeddings, which match on concepts not exact words) is all you need. It’s powerful, it treats “return something” and “send an item back” as the same idea. But it has a blind spot: exact terms. A customer typing a specific error code, a product SKU, or an order number needs an exact keyword match, which pure meaning-based search can fumble.
combine
Choice #2: the confidence gate, the anti-hallucination valve
This is the single most important part of the design, and the one that separates a trustworthy bot from a dangerous one. After retrieval, before generating, ask one question: are the documents we found actually relevant enough to answer from?
The safety layer you cannot skip
For a real support bot touching real customers, a few guardrails aren’t optional extras, they’re the line between shippable and reckless.
How you know it’s working: evaluation
Here’s what separates people who’ve actually shipped these from people who’ve only read about them: you cannot improve what you don’t measure. A support bot needs a way to tell, continuously, whether it’s getting better or quietly regressing.
| Question | How you measure it |
|---|---|
| Did retrieval find the right doc? | Test on known question-answer pairs, check if the right source shows up |
| Is the answer faithful to the source? | Score whether the answer actually matches the cited doc (no invention) |
| Are customers happy? | Thumbs up/down, escalation rate, resolved-without-a-human rate |
| Is it fast and affordable? | Track response time and cost per conversation over time |
| Did a change make it worse? | Re-run the test set before every change; catch regressions early |
Start simple, add only what you need
One more piece of judgment, because it’s easy to over-build. You don’t start with all of this on day one. You start with the simplest thing that could work, ship it, watch where it fails, and add complexity only where the failures are.
| Add this... | ...only when |
|---|---|
| Basic retrieve-then-answer | Always. This is the starting point. |
| Reranking | Retrieval keeps surfacing near-misses; answers feel slightly off. |
| Hybrid (keyword) search | Customers ask about exact codes, IDs, product names the bot misses. |
| Confidence gate | Basically always for support, it's your anti-hallucination valve. |
| Access controls | The moment any doc is not meant for every user. Usually day one. |
How real companies actually built this
Everything above isn’t theory, it’s close to what large companies have published about their own production support bots. Here are two, in their own words, with links to their official write-ups so you can read the primary sources.
DoorDash built a RAG support system for their delivery drivers ("Dashers"). When a Dasher reports a problem, the system first condenses the whole conversation into the core issue (exactly step 1 above), then retrieves similar past resolved cases plus the relevant help articles, and generates a grounded answer.
The part worth stealing: they wrapped it in two extra layers. An LLM Guardrail that checks every answer is actually grounded in the retrieved docs and doesn't violate policy (the confidence-gate idea, taken further), and an LLM Judge that scores quality across five aspects (retrieval correctness, response accuracy, coherence, and more) to catch regressions. Those two layers are what drove the 90% and 99% drops.
Official write-up: DoorDash Engineering, "Path to high-quality LLM-based Dasher support automation"
LinkedIn's customer-service team took a clever twist on the retrieval step. Instead of treating past support tickets as a flat pile of text, they built a knowledge graph from them, capturing the structure inside each ticket and the relationships between tickets. When a question comes in, they retrieve the relevant piece of that graph, not just loose text chunks.
The payoff: because the retrieval understands how issues relate, answers are better grounded. They reported a 77.6% jump in a retrieval-quality metric and, deployed in their real support team for about six months, a 28.6% cut in median time to resolve an issue. It's a great example of the idea that better retrieval, not a fancier model, is usually the biggest lever.
Official paper: Xu et al., "Retrieval-Augmented Generation with Knowledge Graphs for Customer Service Question Answering" (LinkedIn, SIGIR 2024)
The takeaway
A support chatbot that “answers from our docs” sounds like a weekend project, and the naive version is. But the version that won’t embarrass the company is a careful little pipeline: prepare the docs once, then for each question, search (by meaning and by keyword), rerank to the best few, check that they’re actually good enough, and only then answer, grounded, with a source, wrapped in guardrails that respect who can see what, and measured constantly so you know it’s working.
And notice what the real companies confirm: DoorDash’s biggest wins came from verification layers, not a bigger model; LinkedIn’s came from better retrieval, not a bigger model. The lesson underneath the whole thing is the one that runs through all of this, the model is the easy part. The engineering is everything around it, the retrieval, the reranking, the honesty gate, the safety, the measurement, that makes it trustworthy enough to put in front of a real customer. Get the model to read the docs and admit when it can’t find the answer, and you’ve solved 90% of what makes these systems either wonderful or dangerous.