Deep blog
How I Would Build a Production RAG Copilot
I used to think RAG starts with embeddings.
I used to think RAG starts with embeddings.
Now I think that is the wrong starting point.
A useful RAG copilot starts with a person, a question, a decision, and the evidence needed to trust the answer.
The mistake most teams make
Many teams build their first RAG demo like this:
This is fine for a demo. It is not enough for a product.
Why?
Because real users do not only need an answer. They need to know whether the answer is allowed, current, specific, and supported by evidence.
Scenario: HR leave policy assistant
Imagine an employee asks:
Can I carry forward unused leaves into next year if I joined in October?
The system must reason over:
- location
- joining date
- leave type
- current policy year
- old PDFs
- updated handbook pages
- restricted manager notes
- policy exceptions
If the system retrieves an old policy with similar wording, the final answer may look perfect and still be wrong.
Bad v1
A bad v1 usually does this:
- Upload every document.
- Chunk by token size.
- Embed everything.
- Retrieve top five chunks.
- Ask the model to answer.
- Show a broad citation.
- Evaluate by reading a few outputs.
This hides the actual failure points.
Bad production signal
If you cannot inspect the source, source date, access rule, retrieval trace, and final evidence pack, the answer is not production-grade.
Better v1
A better v1 still stays small, but it is designed for trust and debugging.
The vector database is only one part of the system.
The real product is the evidence path.
What I would build first
I would not start with the whole company knowledge base.
I would start with:
- one workflow
- one department
- 20 to 50 trusted documents
- 50 gold questions
- mandatory citations
- retrieval logs
- feedback labels
- review queue for weak evidence
This is small enough to debug.
Evaluation table
| Signal | Test | Why it matters |
|---|---|---|
| Retrieval precision | Did the correct section appear in top 3? | The model cannot answer from missing evidence |
| Citation coverage | Can every claim point to a snippet? | Broad citations are weak proof |
| Freshness | Did current policy outrank old PDFs? | Stale answers create business risk |
| Permission safety | Were restricted docs excluded? | RAG can leak through context |
| Abstention | Did the system refuse weak evidence? | A useful system knows when not to answer |
Mistakes I would avoid
- Starting with the vector database instead of the user workflow.
- Treating chunking as only a token-size problem.
- Adding more documents before the first small corpus is debuggable.
- Evaluating only final answers.
- Trusting fluent answers without source-level verification.
Practical takeaway
A production RAG copilot should be evaluated like a product system:
- Did the right evidence reach the model?
- Did the answer stay grounded?
- Did the user get useful citations?
- Can the team debug the answer when it is wrong?
If you design only for generation, you get demos.
If you design for evidence, evaluation, and debugging, you get a system people can trust.
Exercise
Pick one domain:
- HR policies
- pharmacy FAQs
- product documentation
- college notices
Write:
- Five trusted sources.
- Required metadata for each source.
- Three user questions.
- One unsupported question the system should refuse.
- Five eval cases to catch retrieval and grounding failures.