Skip to content

1 Answer

Accepted answer

PSPriya Singh6.2K XP10d ago
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.
68

Know the answer?

Join Nobink to answer, vote and build your reputation.