Guide · Practice

Fine-tuning for one job

Fine-tuning changes a model you already have, using examples of a decision your team can score. It is how a company owns a narrow task without training a foundation model.

When it is the right move

Fine-tune when the same decision repeats, you have labels for the right answer, and the general model is either too expensive, too slow, or wrong on that slice. Do not fine-tune to invent a loop, a tool, or a memory store. Those are code. The model is the part that judges the next step.

If you have no labels, start with a clearer prompt and a retrieval store. If the job changes every week, a fine-tune goes stale while you are still measuring it. Prompt first. Fine-tune when the score has somewhere to live.

What Coinbase did

On October 8, 2026, Coinbase published the third part of its Owning Intelligence series. The company post-trained Qwen3.5-9B, an open-weight model, on its own Onramp fraud data, using SkyRL on Anyscale. It served the result with Ray Serve LLM and vLLM. Coinbase says the tuned model beat Claude Opus 4.5 on all four detection metrics in its benchmark, including a 9.6 percent higher F1 score, and cut end-to-end latency by 55 percent.

The day before, the same series said newer Opus, Sonnet, and GPT versions scored lower on recall, F1, and dollar-weighted recall for this task than the versions they replaced. The frontier model got better at being general and worse at this one job. That is the reason a specialist existed.

The scores are Coinbase’s. The benchmark is not public. On October 11 the chief executive said the company is making internal fine-tuning easy for employees, and that specialist models will win more narrow tasks. That sentence is his. The measurement behind the path is the October 8 post.

Practice

  1. Name one decisionWrite the input, the allowed output, and how a person scores it. “Help the company with AI” is not a decision. “Is this Onramp attempt fraud?” is.
  2. Freeze a held-out set firstThe cases you score must not be the cases you train on. If they are, a high score only shows that the model memorized the sheet.
  3. Compare with the model you pay for nowCoinbase compared against Claude Opus 4.5, the system already in the conversation, on four detection metrics. A public leaderboard would have answered a different question.
  4. Start from a small open modelQwen3.5-9B was enough for one scored job. Training a foundation model was not the task. Small means you can rerun, inspect, and serve it.
  5. Use labels the job already producesFraud outcomes, support resolutions, and accepted code changes are labels. A general crawl is not a substitute for the decision you are trying to own.
  6. Score accuracy and the waitA model that is slightly righter and much slower can lose. Coinbase reported both a 9.6 percent F1 gain and a 55 percent latency cut. Keep both numbers, and keep them labeled as the company’s.
  7. Serve it where failures are visibleRay Serve LLM and vLLM put the model on infrastructure the team operates. A fine-tune you cannot redeploy is a demo.
  8. Let the next team copy the path, not the percentageAnother company should rerun the method on its own labels. Copying 9.6 percent into a slide, without the test, is how a private result becomes a rumor.

Coinbase post-trained a 9B model that beat Opus 4.5 on its fraud test

Also in the guide

  1. Agents, loops, and tools
  2. How models are ranked, and what they cost