Cost
Running the set calls the model on every example. If the grader is another language model, LangSmith describes that as another model call.
BuildSpark AI: Understand AI. Make it work for you. New here? Start here.
Home · Shipping · 01 · Production evaluation
Concept card · Shipping
What this gets you. Catch a broken change before users do, with saved real examples.
Next on this goal: Observability.
Production evaluation is a saved eval set (examples you already know how to grade) you run again before a prompt, model, or retrieval change faces users.
Oct 18: First card. The picture reruns one small set after a prompt change. Sources are LangSmith's evaluation docs and Anthropic's eval guide.
A production eval is the set you keep, not one look at a single reply. LangSmith's evaluation docs describe offline evaluation as running a version over a curated dataset before deployment, so you can compare versions before users see the change. A dataset is a collection of examples. Each example is an input and an optional reference output. An experiment is one application version run on that dataset, so you can compare prompts or models on the same examples. Anthropic's guide says to design evals that mirror the real task, including edge cases.
Running the set calls the model on every example. If the grader is another language model, LangSmith describes that as another model call.
A change that helps one ticket can fail another that used to pass. LangSmith describes regression tests as checks that a new version does not degrade cases the current version handles. Anthropic says the set should mirror the real task, including edge cases.
A set that never grows misses the cases users actually send. LangSmith describes a feedback loop where failed production runs become candidates for dataset examples. A pass on the set is not a promise about tickets that are not in it.
Pick ten real requests you already know how to grade. Save the input and the mark. Run them once and write down the passes. The next time you change the prompt, the model, or the retrieved documents, run the same ten before users see the change.
Reading one new reply, deciding it looks better, and shipping. The saved set is what shows which old cases got worse.
What should you do with the same eval set when you change the prompt?
See it working in the support assistant example.
Coming soon. Ten saved tickets, run before and after a prompt change, with the new failures kept.