Evals for humans

You asked the model for “weekly revenue by region, excluding refunds, fiscal calendar, same as Finance.” It returned clean SQL, a short explanation, and the confidence of a senior analyst on their third coffee. You almost pasted it into the warehouse. Then you noticed the refund table was left-joined on the wrong key, the fiscal week started on Monday instead of Sunday, and “region” was the sales territory, not the shipping country. The prose was charming. The numbers would have been wrong.

That gap is why evals matter. Not a research paper on leaderboards. Not a vendor slide about “enterprise-grade accuracy.” A human habit: fixed questions, pass criteria, a log, and a re-run when something changes. Chat feels like progress. Evals are how you know you did not quietly get worse.

This is Part 4 of Practical AI for analytics people. Parts 1 through 3 covered assist versus replace, tokens and cost intuition, and prompt patterns for data work. Here we treat evaluation as something you can run with a spreadsheet, a checklist, and forty honest minutes, not a platform project. If LLM basics are still fuzzy, start with our overview of what LLMs are. If the task is SQL, pair this post with how to check AI-written SQL. Problem framing from Analytics foundations still applies: you cannot score an answer if you never defined the decision.

What you’ll learn

• What “evals for humans” means when you are not an ML platform team
• Spot-checks versus a golden set versus a small regression suite
• How to write pass criteria that a tired analyst can apply at 5 p.m.
• A starter set of ten prompt types for analytics work, with example criteria
• A worked weekly loop you can copy, plus the mistakes that make evals theater

Evals without the research lab vibe

In AI product work, “eval” often means automated scoring: exact match, LLM-as-judge, benchmark suites, red-team harnesses. Those tools can be useful later. For an analytics person shipping queries, charts, and stakeholder answers, the first win is simpler. You freeze a small set of tasks that matter at your company. You define what “good enough” looks like. You run the same tasks after a model upgrade, a prompt rewrite, or a tool change. You record pass or fail. You do not argue from vibes.

Think of unit tests for judgment. Software teams do not redeploy without a smoke suite. Analysts who use AI for production-ish work need the same muscle. The suite can live in a shared doc. The “runner” can be you. The “CI” can be a calendar reminder after every vendor changelog email.

Rule of thumb: If a change could alter SQL, definitions, or numbers that someone else will trust, you need at least one frozen question that would have failed last time things broke.

Industry risk guidance treats measurement and testing as part of responsible use, not optional polish. Frameworks such as the NIST AI Risk Management Framework talk about measuring, evaluating, and managing AI systems across their lifecycle. You do not need to implement NIST as a program to steal the useful idea: if you cannot measure failure modes you care about, you are guessing.

Three layers: spot-check, golden questions, regression set

Spot-checks: cheap, frequent, incomplete

A spot-check is what good analysts already do. You skim the join. You sanity-check the total. You run LIMIT 20. You compare last week’s known number. Spot-checks catch obvious nonsense. They fail when you are tired, when the error is subtle, or when the model invents a plausible column that almost exists.

Spot-checks are necessary and not sufficient. Relying only on “looks fine to me” is how wrong regional revenue ships on a Friday afternoon.

Golden questions: frozen tasks with known good shape

A golden question is a prompt you keep stable, with an expected answer shape, not always a single exact string. Example: “Write SQL for active customers in Q2 using the certified definition in the catalog card.” Pass criteria might include: uses the approved customer table, applies the active flag correctly, filters the right date field, does not invent columns, and matches a known row count band on the sandbox.

Golden does not mean “one true answer forever.” Metrics and schemas change. Golden means “we agreed what good looked like on this date, and we update the card when the business definition changes, not when the model feels creative.”

Regression set: the same ten (or so) every time something moves

A regression set is a short suite you re-run after change. Ten prompts is enough to start. Twenty is better once you have scars. The goal is not statistical glory. The goal is catching “this used to refuse hallucinated columns and now invents three” before the whole team upgrades their default model.

The loop looks like this: pick the suite, run it under the new setting, log pass or fail against criteria, investigate fails, decide whether to adopt the change, keep the log. Boring on purpose.

Notice the diagram does not start with “buy an eval platform.” It starts with questions and a log. Tools can help later. Habits have to exist first.

What to score (for analytics work)

Generic chat rubrics (“helpful, honest, harmless”) are fine for customer support demos. Analytics needs sharper axes. Score the things that break trust:

You can score pass or fail on each axis, or use a simple 0/1 overall with notes. Fancy rubrics with five decimal places will not save you if nobody runs them. Binary plus a comment field wins for the first month.

Writing pass criteria people will actually use

Bad criterion: “Answer should be accurate and professional.” That invites argument.

Better criteria are checkable. Prefer bullets a second person could apply without reading your mind:

• Must include: specific tables, filters, or phrase patterns (for example, “uses order_date not created_at”).
• Must not include: forbidden patterns (for example, SELECT * on the customer PII table, or joins on free-text names).
• Numeric band: sandbox row count or total within a known range, when you have a reference query.
• Structure: SQL first, then explanation; or bullet assumptions before code.
• Refusal: for adversarial prompts, pass means the model declines or asks for missing schema instead of inventing it.

When the business definition changes, update the golden card and the reference query. Do not “fix” the model by lowering the bar so the new answer passes.

Starter golden set: ten prompt types

Copy this into a sheet. Replace toy names with your real certified objects. Keep the prompt text stable for a quarter unless the business rules change. The figure below is the same idea as a wall card: types, not one-off chat logs.

Here is the same starter set in a form you can paste into a doc. Each row is a type. Write one concrete prompt per type for your warehouse.

Types 9 and 10 are not “nice to have.” They test whether the tool is a reckless intern. Types 3 and 1 catch the most common analytics failure modes: hallucination of structure and quiet redefinition of metrics. Type 2 is the join tax every warehouse pays.

Worked example: one golden card in the wild

Imagine you own a weekly revenue card. Certified grain: one row per order. Net revenue: gross_amount - refund_amount after completed refunds only. Fiscal week: Sunday start. Region: shipping country, not sales territory. You put this in the prompt as constraints (Part 3 of this series) and you also put it in the eval card so the human scorer is not improvising.

Frozen prompt (toy):

Using ONLY these tables and columns:
orders(order_id, order_date, shipping_country, gross_amount, status)
refunds(order_id, refund_amount, refund_status, refunded_at)

Write SQL for weekly net revenue by shipping_country for fiscal weeks
(Sunday start) in 2025. Exclude orders with status = 'cancelled'.
Only subtract refunds where refund_status = 'completed'.
Show SQL first, then a short explanation of grain and exclusions.
If anything is ambiguous, ask instead of inventing columns.

Reference sketch you keep private (or in the eval sheet, not in the model prompt every time):

SELECT
  DATE_TRUNC('week', order_date) AS fiscal_week_start, -- confirm Sunday
  shipping_country,
  SUM(o.gross_amount) - COALESCE(SUM(r.refund_amount), 0) AS net_revenue
FROM orders o
LEFT JOIN refunds r
  ON o.order_id = r.order_id
 AND r.refund_status = 'completed'
WHERE o.status <> 'cancelled'
  AND o.order_date >= DATE '2025-01-01'
  AND o.order_date < DATE '2026-01-01'
GROUP BY 1, 2
ORDER BY 1, 2;

Your week-start function may differ by warehouse. The point of the reference is a known good shape, not copy-paste religion. When you score a model answer, you check:

1. Join key is order_id, not country or name.
2. Refund filter is on completed only, applied so cancelled orders do not still inflate.
3. Week truncation matches Sunday fiscal rule (or the answer explicitly flags a different default).
4. No columns outside the provided schema.
5. SQL appears before the story.

If the model uses sales_region from a table you never listed, that is an automatic fail on schema honesty, even if the prose is beautiful. That is the whole point of human evals for analytics: beauty is not a pass criterion.

After you score, log one line:

date | model_or_prompt_version | case_id | pass_fail | axes_failed | notes
2026-07-23 | vendor-x-default | G1-revenue | fail | schema, time | used sales_region; week Mon start

Do this for all ten. Twenty minutes once the cards exist. An hour the first time you write them. That hour is cheaper than one wrong board chart.

How often to run, and what counts as a change

Re-run the suite when any of these move:

• Default model or major version in your chat or IDE tool
• System prompt, custom instructions, or team “analytics assistant” template
• Connected tools (SQL runner, warehouse MCP, schema browser)
• Certified definitions on the cards your prompts depend on
• Onboarding a new teammate who will copy your workflow

Between changes, keep spot-checks on every production-bound artifact. The golden suite is the seatbelt for upgrades. Spot-checks are the seatbelt for Tuesday tickets. Related habit from data quality work: fixed checks beat heroics. See the spirit of profiling and validation in the data quality series.

Common mistakes (eval theater)

• Scoring only friendly prompts. If every case is “summarize this nice CSV,” you never test joins, refusals, or PII.
• Changing the prompt while “evaluating the model.” Then you do not know what moved.
• Exact string match on SQL. Formatting differs. Score structure and semantics, or compare results on a sandbox.
• Letting the same person write and score without criteria. Write pass rules first so scoring is not mood-based.
• Never failing anything. A suite that always passes is a branding exercise.
• Ignoring documentation drift. When Finance changes refunds, update golden cards the same week, not next quarter.
• Confusing vibe check with liability. Part 1 of this series: assist is fine; owning the number is still on you. Evals are how you keep that honest under speed pressure.

How this ties to AI-written SQL (and the rest of AMS)

The AI SQL checklist post walks through joins, filters, and confident nonsense for a single query. This post is the habit layer around many queries over time. Use the checklist on every high-stakes draft. Use the golden set when the tool chain changes. Use SQL skills from the SQL series so you can actually see when the model is wrong. Use metric discipline from the metrics and KPIs series so “net revenue” is not a mood. Evals do not replace literacy. They scale literacy under volume.

Practice: build your first suite this week

1. Pick one domain you touch weekly (orders, tickets, content, finance).
2. Write five golden prompts from the type table (at least one refusal, one join trap, one metric definition).
3. Add pass criteria in bullets, not adjectives.
4. Run them on your current default tool. Log pass or fail.
5. Grow to ten. Put the sheet where the team can find it.
6. Schedule a re-run the next time someone says “we switched models.”

Next in this series, Part 5 explains RAG in plain English: how company docs get retrieved into a prompt, when that helps analytics work, and when it only papers over a messy wiki. For more paths, browse Learn.

Quick recap

• Human evals for analysts: frozen questions, clear pass criteria, a pass or fail log.
• Spot-checks catch obvious errors. Golden questions freeze expected shape. A regression set catches silent regressions after changes.
• Score schema honesty, definition fidelity, filters, grain, safety, and explainability.
• Start with about ten prompt types that match real work, including refusals and join traps.
• Beauty of prose is not a pass criterion. Wrong numbers with nice explanations still fail.

Sources

• NIST, AI Risk Management Framework (AI RMF 1.0): https://www.nist.gov/itl/ai-risk-management-framework
• Stanford CRFM, HELM (Holistic Evaluation of Language Models): https://crfm.stanford.edu/helm/
• OpenAI, Evals framework and evaluation concepts: https://github.com/openai/evals
• OWASP, Top 10 for Large Language Model Applications: https://owasp.org/www-project-top-10-for-large-language-model-applications/
• Analytics Made Simple, What are LLMs?: https://analyticsmadesimple.com/analytics/what-are-llms-chatgpt-generative-ai-and-more/
• Analytics Made Simple, How to Check AI-Written SQL: https://analyticsmadesimple.com/tutorials/how-to-check-ai-written-sql/
• Analytics Made Simple, SQL series: https://analyticsmadesimple.com/series/sql/
• Analytics Made Simple, Data quality series: https://analyticsmadesimple.com/series/data-quality/

More definitions in Key Terms →

Merch on Etsy

Open store →

You're On Mute White Ceramic Coffee Mug, Data Science Mug, Data Mug, Analytics Mug, Statistics Mug, Programming Mug, Gift Mug, Coffee Mug View on Etsy → Naive Bayes Mouse Pad, Data Science Mouse Pad, Analytics Mouse Pad, Bayesian Mouse Pad View on Etsy → Boxplot Mouse Pad, Data Science Mouse Pad, Analytics Mouse Pad, Box Plot, Whisker Plot View on Etsy → Y Hat Mouse Pad, Data Science Mouse Pad, Analytics Mouse Pad, Y Pred Mouse Pad View on Etsy →