The standard approach is retrieval-augmented generation: store your documentation in a searchable form, fetch the relevant pieces when a user asks something, and pass those pieces to a language model to compose the answer. Do not fine-tune on your docs — that teaches style, not facts, and it's the most common expensive mistake here.
The pipeline, concretely:
1. **Ingest and chunk.** Split your documentation into pieces of a few hundred words, ideally at natural boundaries (sections, headings) rather than arbitrary character counts. Keep the source URL and title with each chunk — you'll need them for citations.
2. **Embed.** Convert each chunk into a vector using an embedding model. Store the vectors in a vector database, or in Postgres with the `pgvector` extension, which is perfectly adequate and one less service to run.
3. **Retrieve.** When a user asks a question, embed the question and find the most similar chunks. Take the top handful.
4. **Generate.** Send the model a prompt containing the retrieved chunks plus the user's question, with instructions to answer *only* from the provided context and to say it doesn't know otherwise.
5. **Cite.** Return the source links alongside the answer. This is what makes it trustworthy and lets users verify.
The things that actually determine whether it's good, which tutorials skip:
- **Chunking quality.** Badly split chunks that cut a procedure in half produce confidently incomplete answers. This is the highest-leverage variable and the least discussed.
- **Hybrid search.** Pure vector similarity misses exact matches — product codes, error messages, specific names. Combine keyword search with vector search; the improvement is usually large and immediate.
- **Handling 'I don't know'.** Explicitly instruct it to refuse when the context doesn't contain the answer, and test that it does. A support bot that invents a refund policy is a real liability.
- **An evaluation set.** Write 30-50 real questions with known correct answers *before* you start tuning. Without this you're changing things and guessing. This single step separates working systems from demos.
- **Logging.** Record every question, the retrieved chunks and the answer. Reading these weekly tells you exactly what to fix, and reveals what customers actually ask — which is often independently valuable.
On build versus buy: several hosted products do all of this and are genuinely good. If the chatbot isn't your core product, buying is usually the right call — the interesting engineering is in the last 20% of quality, and you'll spend months there. Build it yourself if you need deep integration with your own data and systems, or if it *is* the product.