The search phrase is familiar: a chatbot trained on our policies, our manuals, our proposals. What people want is narrower than the phrase. They want a bot that answers from those files, refuses when the files are silent, and does not quote a version that was replaced last month.
That product is built with retrieval, not by baking the files into a model. Training, or fine-tuning, is a poor way to store documents. You cannot open the paragraph, you cannot delete a stale page, and you cannot easily stop one team from seeing another team's files.
What "Trained on Your Documents" Should Mean
- The documents stay documents. Policies, SOPs, product sheets, help articles, approved proposals.
- A question triggers a search. The system fetches the few passages that might contain the answer.
- The model writes from those passages only. It is told to say when they do not contain the answer.
- The user sees the source. A title and a link, so a person can check the line.
If a vendor says the model has "learned" your PDFs and cannot show a source, ask how you will correct a wrong policy on Monday. If the answer is "we retrain," you are looking at the slow version of editing a file.
Decide Who It Is For Before You Upload Anything
A chatbot for employees, a chatbot for customers, and a chatbot for a field team are three products. They read different files and they fail in different ways.
- Employees: HR policy, IT steps, expenses, internal how-tos. A wrong answer wastes time. A leaked salary file is a different problem. Permissions matter.
- Customers or dealers: specs, warranty, setup, public pricing. The answer is visible outside the company, so it must match the document you are willing to stand behind.
- Operations: SOPs and manuals. Inventing a step is worse than saying "this is not in the manual."
Pick one audience for version one. A shared bot over every folder you own will answer the wrong person from the wrong file.
Collect a Set You Can Defend
- Name an owner for the document set. Someone who can say which file is current.
- Take the latest version only. Archive the rest where the bot cannot see it.
- Skip what you cannot read. Scans without text, photos of whiteboards, and files named "final_v7" with no date.
- Skip what this audience must not see. Contracts, payroll, and customer data do not belong in a general internal bot.
A smaller, clean set beats a dump of the shared drive. The bot will treat a forgotten draft as confidently as the approved policy.
Prepare the Documents So Search Can Find the Answer
- One topic per section where you can. A 40-page PDF with no headings retrieves badly.
- Keep tables intact. A price table split across two chunks produces a guess.
- Put the title and the date in the text, not only in the filename.
- Write the question the section answers if staff ask it in different words from the heading. "Reset the line" and "restart the machine" should meet the same procedure.
This is the unglamorous half of the project, and it decides the quality more than the choice of model.
Index, Then Test Search Before You Add the Chat
Break the documents into passages that can be retrieved, with a link to the original. When someone asks a question, fetch a handful of passages, not the whole library.
Before you connect a model, try 20 real questions and look only at what search returned. If the right passage is missing, a better model will not save you. Fix the chunking, the titles, or the duplicates first.
Then Add the Model, With Strict Instructions
- Answer only from the passages provided.
- Quote or link the source.
- If the passages do not contain the answer, say so and tell the user how to ask a person.
- Do not invent numbers, steps, or exceptions.
- Prefer the passage marked as current when two versions appear.
A larger model is optional. When retrieval is precise, a smaller model usually writes a clear answer at lower cost and latency. Spend the effort on the documents.
Permissions Are Part of the Product
If the index contains HR files and engineering manuals, every user of a shared bot is one question away from the wrong passage. Filter retrieval by who is asking. A customer bot should be physically unable to see internal folders, not merely "told" not to mention them.
Launch on a Short List of Questions
Collect 30 to 50 questions from the people who will use it, including questions the documents cannot answer. Score each one:
- Did search return the right passage?
- Did the answer stay inside it?
- Did the bot refuse when it should have?
- Could the user open the source in one click?
Put it in front of a small group. Read the failures every week and fix the document or the index. Most "the bot is dumb" reports are an outdated file or a heading that does not match how people ask.
Keep It Current or Turn It Off
- When a policy changes, the index must change the same day, or the bot should hide that document.
- Give the owner a way to remove a file without a developer.
- Log questions enough to see gaps. Do not log more personal data than the use requires.
- Review refusals. A bot that always refuses is useless. A bot that never refuses is dangerous.
How i10AI Solutions Builds It
- One audience and one document set, with an owner and a rule for what is in bounds.
- Cleaning and structure so search can find a complete answer.
- Retrieval with citations, and a refusal when the source is missing.
- A test on your real questions before a wider rollout.
- A way for your team to add, replace, and remove documents without retraining a model.
A company chatbot is finished when a new starter can ask a normal question, read an answer that matches the file, and open that file to check. Build for that. Leave the word "trained" for the day you have a skill to teach, not a library to search.