Describe how you would evaluate a model on your own domain-specific terminology.

Say we build a tool that reads a physical therapist's spoken shorthand and drafts a home exercise program a patient takes home on a clipboard. The vendor's own accuracy number for that tool was 92 percent. Almost none of that 92 percent was measured on the words a physical therapist actually uses.

How to answer this, stage by stage

The interviewer isn't testing whether you know what an eval is. They're testing whether you'd trust a vendor's number for a domain that number was never built for.

Let's learn

The tool listens to a physical therapist dictate a home exercise program and drafts it into a printed sheet the patient takes home.

Before it, Tobias Lindqvist wrote every home program from nothing, about 12 minutes a patient, across roughly 14 patients a day.

Once the vendor's 92 percent accuracy score convinced the clinic to trust the tool, Tobias started skimming and lightly editing drafts instead of rewriting them, about 3 minutes a patient.

Here's the turn: the 92 percent was never wrong, exactly. It was measured against a general medical benchmark that had almost no PT-specific precaution language in it at all. The number stayed excellent while the thing that actually mattered, whether a joint-replacement patient's home program listed the right movement limits, quietly got worse.

None of these four show up reliably in a benchmark built for general medical language.

At its worst, trusting a vendor's generic score means a patient recovering from a hip replacement takes home written instructions that quietly violate their own surgeon's precautions.

What I would leave alone: the tool's handling of routine strength-and-flexibility phrasing, sets, reps, simple stretches, was already accurate and didn't need its own special golden set. The caution belongs on the terms where a mistake is expensive, not on every term equally.

The lesson: a vendor's accuracy score tells you how the model did on their test. It tells you nothing about your domain until you've built a test out of your own words.

The vendor's benchmark never appears in this pipeline at all. It was never built for this clinic's words.

Now here is the same thing as a story

The short version above is what you'd say in a vendor-evaluation meeting. Read this one for the day a new hire actually asked the question nobody else had.

Tobias Lindqvist had run Anchor Point's outpatient floor for six years, and he could write a home exercise program faster by hand than most therapists could type one.

The tool arrived with a 92 percent accuracy claim on its cover sheet, and it earned trust fast: drafts came back clean, patients left with printed sheets that looked exactly like what Tobias would have written himself, most of the time.

A new hire, three weeks in, printed a home program for a patient recovering from total hip replacement surgery and paused. The draft told the patient to perform a stretch that crossed the leg past the body's midline, a movement standard post-op hip precautions explicitly rule out. She asked Tobias why nobody had caught this before.

Tobias didn't have an answer, because nobody had ever tested the tool against Anchor Point's own precaution language. The clinic pulled 240 real notes, hand-labeled every precaution flag, rep and set count, and joint-angle term, and ran the model against exactly that.

A benchmark can look finished on paper while a person is still quietly doing the real work by hand.

The domain score came back at 61 percent on precaution flags specifically. The clinic's overall satisfaction survey, taken the same month, still read fine, because most notes were routine and the model handled those well. The survey was the lagging signal. It hadn't moved yet, and it wouldn't have for weeks.

One of these two signals would have caught the problem weeks before the other ever noticed.

When the tool was first adopted, someone in the vendor-selection meeting said, "92 percent is well above what we'd expect from a human, let's move forward." Reasonable, since nobody at the table knew to ask what that 92 percent actually covered.

The real question was never whether the model was good overall. It was whether it was good on the twelve specific terms this clinic could not afford to get wrong.

What I'd tell myself, hearing the new hire's question: a vendor's benchmark tells you how a model did on somebody else's words. It tells you nothing about yours until you check.

LEAD, held against one clinic's shorthandNot a lecture on eval design. The specific golden set you'd actually build before trusting a draft.

A domain eval isn't one big test. It's four specific categories, weighted by how much a mistake in each one actually costs.

The recap, one line per letter: link is trusting a draft without rewriting it, early signal is the precaution-term correction rate, abuse is a golden set stuffed with easy phrasing, decision is gating high-stakes note types behind a real threshold.

And if you want to be sure it really works, try it somewhere elseSame four letters, a port authority instead of a physical therapy clinic. A different kind of hidden vocabulary this time: customs and cargo-manifest shorthand.

Farrukh Rashidov manages cargo-manifest review for Amberlyn Port Authority, using a model that reads shipping documents and flags manifests needing a customs hold. Mapped onto LEAD: link is customs officers trusting a flag enough to act on it without re-reading the full manifest; early signal is the manual override rate on a specific set of hazardous-materials classification codes, which drift for weeks before the port's overall clearance-time metric would ever move; abuse is a golden set built only from routine consumer-goods manifests, missing the rare hazardous codes that actually matter; decision is requiring a second reviewer on any flag touching those specific codes, while routine manifests clear on the model's word alone.

The same three-branch logic sorts a home exercise program and a cargo manifest by the same real question: how much does a wrong answer here actually cost.

Swap the trigger and it still runs.
Speed: an interviewer caps you at sixty seconds. Say "build a golden set from your own words, track correction rate on the highest-stakes terms specifically," and stop.
Cost: there's no budget to hand-label hundreds of notes. Say so honestly, and start with the twenty highest-stakes terms only, not the whole vocabulary.
The model got better, for real: if a new model version genuinely improves, the domain golden set still earns its cost, because it tells you exactly which specific terms actually improved, not just an average that moved.

Where people run it wrong.
They treat a vendor's published accuracy number as proof the model works for their specific domain.
They build a golden set only from the easiest, most common examples, missing the rare terms a mistake would actually hurt.
They track only lagging signals like overall satisfaction, missing the specific correction rate that would have warned them weeks earlier.

How to use it live. When an interviewer asks how you'd evaluate a model on domain terms, ask yourself: which specific words, if the model gets them wrong, actually cost someone something? Build the eval around those words first.

Flashcards (tap any card to flip it)

Check yourself Score: 0 / 0