Case Studies @ HJ
A Small Cooking Assistant That Asks Instead of Guessing
We tuned an 8B open model on public-domain and openly licensed cookbooks to read the recipe you give it, ask when it can't see one, and run on a…

Client Humanjava Enterprises (own product, and the reference build for client models)
Role Product owner and lead engineer: data sourcing and licensing, training, the evaluation and judging system, the release, and the orchestration of AI makers and checkers.
Timeline November 2026
Stack Qwen3-8B (Apache-2.0), LoRA fine-tuning, vLLM, llama.cpp, four open-weights judge models, Cloudflare Pages + D1 for human label tests
I have spent a few articles now saying that the useful version of AI is the small, sharp, well-understood tool, not the giant rented brain pointed at everything. So it felt only fair to build one and show my work.
This is a cooking assistant. It is an open 8B model, small enough to run on a gaming laptop, tuned on public-domain and openly licensed cookbooks in 26 languages. It does three things: it reads the recipe you give it and answers from that, it asks for the recipe when an answer depends on one it cannot see, and it gives full answers to general cooking questions.
That middle one is the whole point.
The problem: AI makes up recipes
Ask a general chatbot "I'm tripling my pancake recipe, how much milk?" without telling it the recipe, and it will very often just give you a number. Confidently. It has no idea what your recipe says, so it invents a quantity that sounds right.
That is a small thing in a kitchen and a big thing everywhere else. It is the same failure that makes people nervous about putting AI near their invoices, their quotes, their customer records. The model does not know, and it does not say so.
So the brief for this model was simple. When it can see the recipe, read it carefully. When it cannot, say so and ask, or give honest general guidance that is clearly labelled as general. Never pretend.
What it does now
On a fixed set of questions it never saw in training, four open AI judges from four different model families read every answer, one at a time, without knowing which model wrote it. We count an answer as "invents recipe details" only when at least three of the four agree.
| Base Qwen3-8B | Our model | |
|---|---|---|
| Invents recipe details when it can't see the recipe | 25.8% (about 1 in 4) | 2.7% (about 1 in 40) |
| Correct when it can read the recipe | 83.1% | 94.8% |
On general cooking questions it is level with the base model. It also does not copy its training text: we probed it 12,000 ways against the openly licensed cookbooks it learned from, and it never reproduced a passage word for word: its longest overlap was 67 characters, about what the base model does.
And it is small. The compressed version runs fully on a 6 GB graphics card at about 70 tokens (roughly 50 words) a second, and on a 4 GB card with part of it on the CPU. Those memory figures were measured, not estimated.
What we learned building it
Benchmarks did not catch the real problem. Reading the answers did. Our first version invented recipe details just as often as the base model. Every standard test looked fine. The questions had been written while looking at a recipe and then trained without it, so the model learned to answer as if it could always see one. We only found that by reading what it actually said.
One judge is not enough, so we built a panel. A single AI judge has its own blind spots. Four judges from four model families, with a rule that three must agree, gave numbers that held up, and showed us exactly where the judges disagree. That panel is now a tool we run on every build.
A second opinion on your training data can be a finding by itself. We asked a fifth, independent model to re-check the labels our training data was built on. It disagreed with more than half of them, mostly on one judgement call: is a hedged answer honest, or is it still inventing? Retraining on only the labels it agreed with did not make the model better or worse. That is a useful answer in itself, and it is exactly the kind of question a human needs to settle. Which brings me to the part where you can help.
Check the scorecard, not just the model. For a while our headline "correct when the recipe is shown" number was 80.6%. When we broke it apart, it turned out to mix in general questions and a handful of "how do you make X?" questions with no recipe at all. On the questions it was actually built for, reading the recipe you give it, it is right 94.8% of the time. The model had not changed. Our measurement had.
We are still refining it, with people
AI judges are models, and models share blind spots. So we keep checking our judges against people with Label Test, the small private labelling tool we built for this.
If you have a few minutes, you can help. You will see five answers, one at a time. For each, you read the question and the recipe the assistant could or could not see, and decide whether it made recipe details up, asked for the recipe, or gave honest general help. It is blind, there is no account, and we keep only a name or initials and your labels.
Every label tightens the numbers above, and tells us where the judges and people disagree.
Try it, on your own machine
The model is open, under the same Apache-2.0 licence as the base model. (It is our own fine-tune of Qwen3-8B, not made or endorsed by Alibaba Cloud or the Qwen team.)
If you have Ollama, it is one line:
ollama run vveerrgg/qwen3-8b-cooking-assistant
Paste a recipe, then ask about it. Ask without one, and watch it ask you back.
For a smaller or bigger graphics card, LM Studio, llama.cpp, or Python, our setup guide walks through picking the right file for your card, with measured memory and speed for each. The full-precision model, the compressed files and the evaluation set behind every number here are on Hugging Face.
Why we are showing you this
This is a small project about cooking. But it is the clearest example I have of the thing I actually do. Take a real, narrow human need. Find good, honest data for it, with licences you can point to. Tune a small tool to do that one job, and to say "I don't know" when it doesn't. Measure it with more than one judge, check the judges against people, and publish the numbers along with the mistakes that taught us something.
The same pattern is behind the client work: a quoting assistant that should never invent a price, a records tool that should ask rather than guess. If you have a narrow job like that, and data you would rather keep on hardware you control, that is what we build. And if you have training data of your own and want people, not only models, to check it, Label Test is how we do it.
This one just happens to make dinner.



