What I learned building an HR and payroll assistant
I am building an assistant that answers HR and payroll questions from company policy documents. A confident wrong answer in this setting can affect someone's salary, so accuracy matters more than a polished demo.
1. Retrieval quality is the product
Model choice gets most of the attention, but retrieval causes many of the failures. If the right passage never reaches the context window, the model has little chance of answering correctly.
We test retrieval on its own. For each question, did the system find the right passages? Chunking and embedding quality deserve attention before work on the chat interface.
2. Citations are a feature, not decoration
Every answer points back to the relevant document and section. Users can check the source themselves, and the system has less room to invent an answer that the documents do not support.
3. Refusal behaviour is where the engineering lives
The system also needs to say "I don't know". When retrieval is empty or weak, it should refuse clearly and consistently instead of filling the gap with a plausible answer.
We log and review refusals because they show where the document set or retrieval process needs work.
4. Measure the wrong answer rate
We use a fixed set of real questions with known answers and record how often the assistant answers confidently but incorrectly. That number is more useful than feedback from a carefully prepared demo.
Build the evaluation harness early. It is harder to introduce a strict quality bar after stakeholders have already formed an opinion from the demo.
5. The corpus is never ready
Policy documents contradict each other and become outdated. Two PDFs may answer the same question differently because they were written in different years. Someone needs to own the document set, resolve conflicts, and remove material that should no longer be used.
6. Guardrails belong in the system, not the prompt
A prompt that says "only answer from the context" is not enough. The code should stop generation when retrieval returns nothing, validate answers against the retrieved text, and enforce the subject boundaries. The prompt supports those controls but does not replace them.
7. Users ask questions you did not design for
People ask compound questions, use the wrong language, and refer to documents that do not exist. Sometimes the correct response is "call HR". Within the privacy rules, we review real usage every week and use it to decide what needs attention next.
The stack is only one part of it
Our system uses embeddings, vector retrieval, grounded prompting, and continuous evaluation. Other stacks can solve the same problem. The important part is testing retrieval, citing sources, refusing unsupported questions, and measuring the results honestly.
The portfolio includes more of my production work and a small concierge that answers from a fixed dossier. If you are building a similar system, send me the document set, the users, and the cost of a wrong answer.
// frequently asked
What is a RAG chatbot?
A RAG chatbot retrieves relevant passages from your documents before it answers. The answer is based on those passages and should point back to its source.
How do you stop a RAG chatbot from hallucinating?
The system needs to retrieve the right passage, limit answers to the retrieved text, and refuse when the evidence is weak or missing.
How should you evaluate a RAG system?
Measure the wrong answer rate on a fixed set of real questions. A bot that answers 80% and refuses the rest is safer than one that answers everything but gets 10% wrong.