INFS3822 Chap.4 Problem Framing and Model Choice
Problem Framing and Model Choice
Problem framing turns a broad organisational concern into a decision that can be observed and improved. This chapter uses context, causes, stakeholders and expected outcomes to define the unit, target, timing and action. It then justifies model choice through task fit, data fit, operational fit and governance fit rather than selecting an algorithm by popularity or one aggregate score.
What this chapter covers
- 01
Accountable role and affected group
- 02
5W1H context framing
- 03
Problem statement and causes
- 04
Unit, target and horizon
- 05
Task and data fit
- 06
Operational constraints
- 07
Interpretability and governance
Worked example · free
Choose an interpretable baseline
- +1Frame the task as binary classification with a probability output.
- +1Recognise that a moderate structured table supports logistic regression as a credible baseline.
- +1Use interpretability and review requirements as governance reasons for the baseline.
- +1Compare a tree ensemble only if nonlinear interactions improve unseen-data performance enough to justify extra complexity.
Key terms
- Problem statement
- A precise description of the issue, context, affected stakeholder and desired improvement.
- Prediction horizon
- The period between producing a prediction and observing its target outcome.
- Baseline model
- A simple reference method used to judge whether added complexity creates reliable benefit.
- Interpretability
- The degree to which a person can understand relevant model relationships or reasons.
Problem Framing and Model Choice FAQ
What belongs in a problem statement?
State what is happening, to whom, where and when, why it matters, the likely drivers and the decision that could improve the result. Translate broad terms into observable definitions. The statement should support a target, evidence plan and action rather than simply announcing that AI will be used.
Why not try every algorithm?
Trying everything is costly and can turn model selection into noise chasing. Task type, data structure, sample size, linearity, interpretability, training cost, inference latency and governance narrow sensible candidates. Compare justified models on the same evidence, then accept complexity only when its benefit survives testing.
Can the highest score still be the wrong choice?
Yes. The metric may not reflect the costly error, the model may be too slow, its inputs may arrive late, or its decisions may require explanations it cannot support. A recommendation must combine predictive evidence with operational and governance constraints from the use case.
How do I justify a simple baseline?
Describe the pattern it can express, the assumptions it makes and why its output is usable for the stated action. Evaluate it on the same prepared evidence and metric as any challenger. The baseline creates a reference for incremental value. A complex model should be selected only when its reliable improvement matters enough to offset added cost and control requirements.
Assessment move
Before modelling, write four lines: unit, target, prediction time and action. Then make a candidate table with task fit, data fit, operational fit and governance fit. Use the table to justify a baseline and one challenger. This produces a defensible comparison and prevents technology-first proposals. Expand the four lines into a framing test. The unit must identify what one row represents.
The target must be observable and consistently labelled. The prediction time fixes which facts are genuinely available. The action must name what changes after the output arrives. Add a horizon, success measure and review capacity when the case requires them. Take one ambiguous phrase such as customer churn and create three possible target definitions.
Compare how account cancellation, a period of inactivity and loss of recurring revenue change labels, horizons, features and interventions. This demonstrates why model selection cannot rescue an unstable definition. For candidate comparison, begin with the simplest credible baseline. State its assumptions, what pattern it can express and why its output is usable.
Add one challenger only when the case suggests a limitation, such as nonlinear interaction, high-dimensional representation or sequential dependence. Evaluate both on the same split, preprocessing and metric so architecture is not confused with a different data advantage. Use four fit questions aloud. Task fit asks whether the output matches the required number, class, order or group.
Data fit asks about volume, structure, missingness and relationships. Operational fit asks about latency, compute, maintenance and delivery. Governance fit asks about explanation, audit, privacy and error harm. Give each recommendation a boundary: choose the simpler model unless the challenger produces a reliable improvement that matters to the decision and its additional cost can be controlled.
Rehearse counterfactual changes. If reviewers need an explanation, if labels are scarce, if the prediction must run on limited hardware, or if the target shifts from a class to a numeric amount, revise the recommendation and identify which fit criterion caused the change. That reasoning is more defensible than memorising a fixed hierarchy of algorithms.
Working through Problem Framing and Model Choice in INFS3822? Sia is AskSia’s AI Computer Science tutor — ask any INFS3822 Problem Framing and Model Choice question and get a clear, step-by-step explanation grounded in how INFS3822 is taught and assessed. Read this chapter free, then take your hardest questions to Sia.
