LLM evals, guardrails and cost control

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?

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; the risk list behind it is the OWASP Top 10 for LLM Applications.

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.

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.

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.

It is not a starting point for teams without an AI feature yet; the AI features scoping sprint 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.