AIHow to evaluate a RAG system: metrics and regression tests
How to evaluate a RAG system: retrieval metrics, faithfulness and answer quality, building a test set, and regression evals that catch quality drops early.
Bilal Khursheed6 min read
AI service
Evaluation and guardrails, so you know your AI feature works
Test sets, automated evals and guardrails so quality is measured, not guessed.
The problem
Where teams get stuck.
Most teams judge an AI feature by trying a few prompts and seeing if the answers look right. That works until a prompt change, a model update or a new kind of question breaks something nobody checked.
Without a test set you cannot tell whether a change made things better or worse. Quality drifts, and you hear about it from users.
Without guardrails, the feature will sooner or later answer something it should have refused, or leak something it should have protected.
Our approach
What makes this work.
- 01
Define good
We agree with you what a correct, safe and useful answer looks like for this feature, in writing.
- 02
Build the test set
Real questions, edge cases and known failures are collected with expected answers, drawn from your data and logs.
- 03
Automate the evals
Scoring runs on every prompt or model change, combining exact checks, model-graded checks and human review where judgement is needed.
- 04
Add guardrails and monitoring
Input and output checks, refusal rules and production monitoring catch what the tests did not predict.
Delivery process
How we deliver it, step by step.
Every engagement follows the same seven stages, from requirements to post-launch support.
- 01
Discovery & requirements
Workshops with your stakeholders to define goals, users, scope and constraints, captured in clear written requirements.
- Goals and success measures
- Requirements and user stories
- Scope, estimate and roadmap
- 02
UX & UI design
User flows, wireframes and interface design, reviewed with you until the product feels right before it is built.
- User flows and wireframes
- Interface design
- Clickable prototype
- 03
Architecture & planning
Data model, system design, integrations and security are settled, and the work is broken into sprints.
- Architecture and data model
- Technical decisions on record
- Sprint plan
- 04
Development
Short iterations with code review on every change and a demo of working software each week.
- Weekly demo
- Shared board and written updates
- Reviewed, version-controlled code
- 05
QA & testing
Manual and automated testing across functionality, devices, APIs and performance, followed by user acceptance testing.
- Test plan and test cases
- Automated regression suite
- UAT support and sign-off
- 06
Deployment & launch
Release through a CI/CD pipeline onto monitored cloud infrastructure, with a go-live checklist and rollback plan.
- CI/CD pipeline
- Monitoring and alerting
- Go-live checklist
- 07
Hypercare & support
Close monitoring and priority fixes straight after launch, then ongoing support, maintenance and improvement.
- Hypercare period
- Support under agreed response times
- Improvement backlog
Deliverables
What you receive.
- A written quality definition for each AI feature
- A versioned test set built from real usage
- Automated evaluation that runs in your CI pipeline
- Retrieval and answer-accuracy scoring for RAG systems
- Input guardrails for prompt injection and out-of-scope requests
- Output guardrails for sensitive data, tone and unsupported claims
- Production monitoring with sampled human review
- A dashboard showing quality over time
Technology
What we build it with.
- OpenAI
- Anthropic
- Python
- TypeScript
- PostgreSQL
- GitHub Actions
Related work
Where we have done this before.
AI / LegalTech
Client name withheld
Contract analysis with a multi-agent RAG pipeline
Turns 500 to 1,000 page legal contracts into a queryable knowledge base that answers with cited sources.
- Python
- FastAPI
- OpenAI
- Gemini
AI business tooling
Client name withheld
An AI business consultancy chatbot for multi-department strategy
A conversational AI advisor that asks targeted questions and returns recommendations across marketing, HR, finance, operations, strategy and IT.
- OpenAI
- Node.js
- Next.js
From the blog
Related guides.
What we have written about llm evaluation & guardrails: cost, timelines and the trade-offs behind each decision.
- AI
AIHow to reduce LLM hallucinations in production
How to reduce LLM hallucinations: retrieval grounding, checked citations, schemas, 'not found' answers, evaluation and guardrails, and what each one fixes.
Bilal Khursheed8 min read
FAQ
LLM Evaluation & Guardrails: common questions.
What is an eval?
A repeatable test for an AI feature. It runs a fixed set of inputs through the system and scores the outputs, so you can compare versions with numbers instead of impressions.
Can hallucinations be removed completely?
No. They can be reduced a great deal through grounding, citations, refusal behaviour and checks on the output. Evaluation tells you how often they still happen, which is what lets you decide if the feature is ready.
We already have an AI feature live. Can you add evaluation to it?
Yes. This is the most common case. We build the test set from your production logs and known complaints, then wire the evals into your release process.
Do guardrails slow the feature down?
Some checks add a little latency. We keep the fast, cheap checks in the request path and run the heavier ones in the background or on a sample.
Who reviews the results?
Automated scoring covers most cases. For questions that need judgement, our QA and AI teams review a sample with someone from your side who knows the domain.
Discuss your LLM Evaluation & Guardrails project with us.
Share a short brief and we will reply with next steps, usually within one working day.