# LLM evals, guardrails and cost control

> Know whether your AI feature is getting better or worse, and what it costs.

- Page: https://deependra.in/services/ai/llm-evals
- Type: Service, part of Applied AI engineering
- Last updated: 2026-11-02
- Line page: [Applied AI engineering (AI)](https://deependra.in/services/ai)
- Author: [Deependra Vishwakarma](https://deependra.in/about), senior software engineer in Mumbai

## In short

LLM evaluation means scoring your AI feature against real questions with agreed answers on every change, and AI guardrails are the checks and limits that keep it safe and within budget. It is for teams with an LLM feature in production who cannot yet say whether it is getting better or worse.

## Key facts

- Engagement: fixed-price
- Price: Fixed price
- Timeline: Agreed per project after a scoping call
- First step: **Sample.** Collect representative real inputs (with personal data removed) and agree what a good answer is.
- Works with: Python, TypeScript, Anthropic API, OpenAI API, promptfoo, GitHub Actions, OpenTelemetry
- Based in: Mumbai, India · UTC+5:30. I plan my working day around my clients' hours. The overlap with your timezone is shown on the [contact page](https://deependra.in/contact).

## What is LLM evaluation?

LLM evaluation, AI guardrails and cost control are for teams with an AI feature already in production. I build a golden evaluation set from your real traffic, wire it into CI so every prompt, model or retrieval change is measured before it ships, add defences against prompt injection and data leakage, and cut spend with caching, batching and model routing without letting the scores drop. It answers two questions most teams can't: is the feature getting better or worse, and what does it cost per useful answer?

## Who it is for, and who it is not

### Who this is for

- Teams shipping prompt and model changes without knowing whether answers improved
- Products whose LLM costs are growing faster than their usage
- Companies that need to show customers or auditors how their AI feature is tested

### Who this is not for

- Teams without an AI feature yet: the AI features scoping sprint is the better start

## What you get

1. A golden set of real questions and expected answers, with a scoring method you trust
2. Evaluations that run in CI on every prompt, model or retrieval change
3. Guardrails: input and output checks, injection defenses and personal-data handling
4. A cost report and the savings from caching, batching and model routing
5. A short playbook for running and extending the evaluations

## What are AI guardrails?

AI guardrails are checks and limits around an AI feature that keep it inside what you intend. Four kinds cover most cases: input checks for prompt injection and personal data, output checks on what the model returns, tool permissions that limit what an agent can do, and usage limits that cap spend.

Each guardrail is measured like the rest of the feature: the evaluation set shows what it costs in quality and what it prevents. How injection attacks work and which defences hold is covered in [prompt injection in RAG and agent systems](https://deependra.in/writing/prompt-injection-rag-agents); the risk list behind it is the [OWASP Top 10 for LLM Applications](https://genai.owasp.org/llm-top-10/).

## Scope

One AI feature, or a small family of features sharing a pipeline. We start by sampling representative real inputs, with personal data removed, and agreeing with your product owner what a good answer is for each. That agreement is the foundation; without it, no score means anything.

## What is measured

The golden set holds real questions, the expected answers or the facts an answer must contain, and for retrieval features the passages that should have been found. Scoring uses the fastest reliable method for each check: exact matches for numbers, categories and citations, model-graded checks for tone, completeness and faithfulness to the sources, calibrated against a sample of human judgments so the grader can be trusted.

For a retrieval feature I score retrieval and generation separately, because they fail differently: context recall asks whether the right passages were found, faithfulness asks whether every claim in the answer is supported by them. A change that improves one and harms the other shows up immediately. The scoring method is written up in [RAG evaluation sets: what goes in and how to score them](https://deependra.in/writing/rag-evaluation-sets).

Guardrails are measured too. The set includes direct and indirect prompt-injection attempts, requests for data the user shouldn't see, and inputs carrying personal data, so the report shows what each guardrail costs in quality and what it prevents.

## What it is not

It is not a starting point for teams without an AI feature yet; the [AI features scoping sprint](https://deependra.in/services/ai/ai-features) is. It is not a one-off benchmark score either. The value is in the set running on every change, so the playbook covers how to extend it as users find new ways to ask.

## How the engagement runs

1. **Sample.** Collect representative real inputs (with personal data removed) and agree what a good answer is.
2. **Score.** Build the scoring: exact checks where possible, model-graded checks where not, calibrated against human judgment.
3. **Automate.** Run the set in CI and block changes that make quality worse.
4. **Harden and trim.** Add guardrails, then reduce cost without letting the scores drop.

## Technologies I use for this

Python, TypeScript, Anthropic API, OpenAI API, promptfoo, GitHub Actions, OpenTelemetry

## How this works in your market

### How this works in the European Union

For teams in [the European Union](https://deependra.in/markets/europe), evaluation data is built from real traffic with personal data removed, and the work happens inside your infrastructure where possible. The evaluation reports are also useful records: they show how the feature is tested and how its quality is tracked, which customers and reviewers increasingly ask for. Confirm with your counsel which obligations apply to your feature.

[European Union page](https://deependra.in/markets/europe)

### How this works in the United States

For [US](https://deependra.in/markets/united-states) teams, the most common trigger is an enterprise customer asking how the AI feature is tested and monitored. A CI gate, a versioned golden set and a monthly quality-and-cost report answer that in writing. Your morning overlaps my evening, so the first review of each report happens at the start of your day.

[United States page](https://deependra.in/markets/united-states)

## Case studies behind this service

- [Zyrobe](https://deependra.in/work/zyrobe-ai-wardrobe): AI wardrobe app. 3–8 s average time per image, upload to result.

## Questions about LLM evals, guardrails and cost control

### Can a model grade another model fairly?

For many checks, yes, once the grader is calibrated against human judgment on a sample. Where exact checks are possible (a number, a category, a citation), those are used instead.

### Will guardrails make the feature worse?

They're measured like everything else: the evaluation set shows what each guardrail costs in quality, so you can choose the trade-off.

### What is a golden dataset?

A fixed, versioned set of representative inputs with agreed expected outputs, used to score every change the same way. It grows when production shows a new kind of question or failure.

### How big does the evaluation set need to be?

Big enough to cover the kinds of question your users ask and the failures you care about. It starts small and grows from production; coverage matters more than size.

### Which tools do you use?

promptfoo or a small harness in Python or TypeScript, run in GitHub Actions, with traces through OpenTelemetry. The set and the scoring live in your repository, not in a vendor's dashboard.

### How do you cut costs without losing quality?

Every saving is measured against the golden set: caching repeated work, routing simple steps to smaller models, batching where latency allows, and trimming context the model doesn't use.

### How do I evaluate an LLM feature?

Collect representative real inputs with personal data removed, agree what a good answer is, and score each change against that set: exact checks where a number, category or citation can be checked, and model-graded checks, calibrated against human judgment, where it cannot. Run the set in CI so a change that makes quality worse is blocked. For a retrieval feature, score retrieval and generation separately.

### What are AI guardrails?

Checks and limits around an AI feature: input checks, output checks, tool permissions and usage limits. They are measured like everything else, so you can see what each one prevents and what it costs in answer quality.

## Related services

- [AI features in your product](https://deependra.in/services/ai/ai-features) (Applied AI engineering): LLM features that work on your real data, measured before they ship.
- [AI agents and MCP servers](https://deependra.in/services/ai/agents-mcp) (Applied AI engineering): Agents that act in your tools with permissions, audit logs and a person in the loop.

## Sources

1. [OWASP Top 10 for LLM Applications](https://genai.owasp.org/llm-top-10/)
2. [Anthropic docs: define success criteria and build evaluations](https://platform.claude.com/docs/en/test-and-evaluate/develop-tests)
3. [OpenAI: working with evals](https://developers.openai.com/api/docs/guides/evals)
4. [Ragas: faithfulness](https://docs.ragas.io/en/stable/concepts/metrics/available_metrics/faithfulness/)
5. [Ragas: context recall](https://docs.ragas.io/en/stable/concepts/metrics/available_metrics/context_recall/)

## Related writing

- [RAG evaluation sets: what goes in and how to score them](https://deependra.in/writing/rag-evaluation-sets) (2 November 2026): How to build the set of questions that tells you whether a retrieval-augmented AI feature is getting better or worse, and how to score retrieval and answers separately.
- [Prompt injection in RAG and agent systems: direct, indirect, and the tests that catch it](https://deependra.in/writing/prompt-injection-rag-agents) (2 November 2026): What prompt injection is, why retrieval systems and agents are most exposed to the indirect kind, which defences actually reduce the risk, and how to test for it on every change.

## Where this work happens

- [European Union](https://deependra.in/markets/europe) (Berlin, Amsterdam, Dublin): A freelance software engineer for European teams, working remotely from Mumbai with most of your working day in common. It is for product teams in Germany, the Netherlands, Ireland and the Nordics that need senior engineering, including the work behind GDPR, the Accessibility Act and the AI Act.
- [United States](https://deependra.in/markets/united-states) (New York, Chicago, San Francisco): A senior software engineer for US startups and product teams, working remotely from Mumbai so that the East Coast morning falls inside my evening. It is for founders and CTOs who need senior engineering without a full-time hire: MVPs, AI features, performance work and rescuing apps built in a hurry.

## Teams that start here

- [San Francisco, US](https://deependra.in/markets/united-states/san-francisco)
- [Paris, EU](https://deependra.in/markets/europe/paris)

## Start

Start a project: https://deependra.in/contact

---

Cite as: Deependra Vishwakarma, "LLM evals, guardrails and cost control", https://deependra.in/services/ai/llm-evals (last updated 2026-11-02).

This is the Markdown version of https://deependra.in/services/ai/llm-evals; the page is the canonical source. Start a project: https://deependra.in/contact
