Skip to content
back to achievements

Case study · Proxy

Side projectProject period2026 – Present

Evaluation and quality gates

Limited replies to my own notes and checked them with an evaluation suite that runs the real assistant against realistic questions and adversarial, multi-turn attacks, covering the route taken, the widget shown, required and forbidden wording, answer length, prompt injection, false claims and leaks of its own instructions or tool calls, plus automated tests, so every prompt or routing change is measured before it ships.

01

Why

An assistant that answers in free text cannot be tested with exact-match assertions, and a small change to a prompt or to routing can quietly make answers worse, make them leak the assistant's own instructions, or let a false claim through. I needed a repeatable way to see that before it shipped.

02

Decision

I built an evaluation suite that runs the real assistant on the real model. Each question carries expectations: the route it should take, the widget it should show, wording that must or must not appear, and a minimum answer length. Every answer is also checked for leaks of its own instructions, tool names or reasoning. A separate red-team set, including multi-turn attacks, covers prompt injection, false premises and pressure to guess. I kept the checks rule-based instead of asking another model to grade, so a result is repeatable, free of a second model's opinions and cheap enough to run after every meaningful change; each run also reports what it cost.

03

What I built

Limited replies to my own notes and built an evaluation suite that runs the real assistant against realistic questions and adversarial, multi-turn attacks. Each answer is checked for the route taken, the widget shown, required and forbidden wording, answer length, prompt injection, false claims, and any leak of the assistant's own instructions or tool calls. Automated tests sit beside it. Every prompt or routing change is measured before it ships, and the suite reports what each run cost.

04

Trade-offs

  • Rules cannot judge tone or subtle correctness. Two failures in one run were checks that were too strict and had to be fixed, and the red-team answers still need reading by a person.
  • The suite spends real money, so it is run on purpose, not on every commit.
  • One run per setting is noisy; small differences are not evidence.

05

Outcome

Changes became measurable. It caught real regressions (a reply that talked about "the visitor", a routing topic that sent the model no instruction so it listed its own tools) and let me adopt or reject ideas on evidence, as in the router and reasoning-effort decisions.

Technologies

  • LLM Evaluation
  • Red-Teaming
  • Prompt-Injection Defence
  • Vitest