Claude/ChatGPT Prompt to Pick the Right ML Model for a New Problem

What this prompt does

This prompt asks a senior ML engineer to recommend a concrete modeling approach a team can start building this week — not a survey of every option. You describe the [problem_description], the [dataset_size] and balance, the [latency] budget, and [labels] availability. It returns a decision memo: the problem type stated plainly, three candidate model families with honest tradeoffs, a recommended baseline to ship first, evaluation metrics matched to the business cost of errors, data-prep steps, and the top risks with a guard for each.

The memo format forces a decision instead of a menu. Pinning the [latency] budget and the cost of a wrong prediction up front quietly decides most of the architecture — a p99 under 50ms rules out heavy models before you start. Recommending a simple baseline first earns the right to anything fancier, and tying metrics to error cost stops you from optimizing accuracy when recall is what actually matters. The biggest risk is called out in bold.

When to use it

• Scoping a new modeling problem and you want a buildable recommendation, not a literature review
• Deciding among model families given a real [latency] budget
• Choosing the right first baseline before reaching for something heavy
• Picking evaluation metrics that reflect the business cost of errors
• Surfacing leakage, imbalance, and drift risks early with guards
• Handling a skewed [dataset_size] where the positive class is rare

Example output

You get a short decision memo: a one-line problem-type statement, three model families each with honest tradeoffs for your data and latency, a recommended baseline and why it beats a fancier start, error-cost-aligned metrics with reasoning, data-prep steps including imbalance handling, and a risks section. The single biggest risk appears in bold so it is impossible to skim past.

Pro tips

• State the cost of a wrong prediction inside [problem_description] — a false negative in fraud costs differently than a false positive, and that shapes the metric choice
• Give a real [latency] budget like p99 < 50ms; it eliminates whole model families before you waste time on them
• Include the class balance in [dataset_size] (e.g. 5M rows, 0.3% positive) so the imbalance handling is concrete
• Describe [labels] honestly — noisy or proxy labels like historical chargebacks change which baseline is realistic
• Build the recommended baseline first and measure it before considering anything heavier; the memo is structured to push you there
• Re-run with a tighter [latency] budget to see how the recommendation shifts when real-time constraints bite
• Read the bolded biggest-risk line first; if that risk applies to your data, address its guard before you write any training code