Understanding Model Selection
Hard attributes are properties that are impossible or impractical for you to change, usually because of decisions by model providers (licenses, training data, model size) or your own policies (privacy, control).
A Candidate That Performs Poorly
Suppose you are choosing a model for a task, and a candidate performs poorly on your first few tries. A natural reaction is to start tuning it: rewording prompts, adjusting settings, and trying again. Before you commit that time, you need to answer a more basic question. Is the problem something you are able to fix, or is it a fixed property of the model that you have to accept?
Every property of a model falls into one of two groups. Some properties are off the table because you cannot change them, or because changing them would be impractical. Others are properties you can push on, and you may be willing to invest effort in doing so. Learning to tell these two groups apart is the first step in judging whether a model is worth the time you would spend improving it. The two groups are called hard attributes and soft attributes.
What do you think happens?
In one case, a model's accuracy stayed around 20% on the first few prompts, then rose to 70% after the author split the task into two steps. What changed between the two results?
Reveal answer
The model itself stayed the same. Only the way the task was posed changed.
The source reports that the model did not change at all. The task was restructured into two steps, and that restructuring was enough to move accuracy from about 20% to about 70%. This is the core idea behind soft attributes: effort can change how the work is done without changing what the model fundamentally is.
Two Groups of Model Properties
Hard attributes are properties that are impossible or impractical for you to change, usually because of decisions by model providers (licenses, training data, model size) or your own policies (privacy, control).
Soft attributes are the opposite: properties that effort can move. The source names accuracy, toxicity, and factual consistency as examples. These can be improved through changes to how the work is done rather than through changing what the model is. The distinction is easiest to hold in mind as two columns, with examples from the source sorted into each. Use the comparison below as a reference when you sort a new attribute, but remember that the sorting itself depends on the model and the use case, which the next sections explain.
Where Hard Attributes Come From
Hard attributes usually trace back to a decision that someone already made. The source identifies two broad places those decisions come from. Each one leaves you with a property you cannot edit by tuning the model for an afternoon. A license is a legal term, training data was chosen before you arrived, and a model's size is part of what it is.
Latency: One Property, Two Classifications
The source makes the central point about classification using latency, which is how long a model takes to respond. Latency is not inherently hard or soft. Its classification depends on your relationship to the model. The table below sets out the two cases the source describes.
| Your relationship to the model | Can you change latency? | Classification |
|---|---|---|
| You have access and can optimize the model to run faster | Yes, through optimization | Soft |
| You use a model hosted by someone else | No, you cannot change how it runs | Hard |
The same property, latency, is classified differently depending on access.
Deciding whether latency is hard for a hosted model
A team is evaluating a model for a support-ticket summarizer and is deciding whether to treat latency as something to work on. The model is hosted by an outside provider, and the team has no ability to change the serving infrastructure.
- 1Identify the property
The property is latency: how long the model takes to respond.
- 2Identify the relationship
The model is hosted by someone else, so the team has no access to change how it runs.
- 3Apply the rule
The source says latency is hard when the model is hosted by someone else, because you cannot change how it runs.
- 4Decide what to do
Latency is treated as a fixed constraint. The team should check whether that fixed latency is acceptable for the summarizer before investing effort in the model itself.
Latency is hard for this team. It is a fixed property they must accept or plan around, not one they can improve by tuning.
How Soft Attributes Respond to Effort
What separates soft attributes from hard ones is that effort can move them. The source describes improving a soft attribute through changes to how the work is done, not through changing what the model fundamentally is. Accuracy is the clearest example in the source. The diagram below traces the single case it reports, where the task was restructured and the model was left alone.
The change in the diagram is entirely in the task. The source reports that after the author decomposed the task into two steps, accuracy rose from about 20% to about 70%, and the model did not change at all. This is why soft attributes are worth pursuing: a poor first result may reflect how the work was posed rather than a fixed limit of the model. The source also lists toxicity and factual consistency as soft attributes that can likewise be improved with effort.
Classifying an Attribute, Step by Step
The classification depends on both the model and the use case, so you cannot sort attributes from a list alone. The flowchart below turns the source's principles into an ordered set of questions. Hard attributes are checked first, because they can sharply narrow the candidate models. Each question asks where the property's constraint comes from, and only then whether your access to the model can change it.
Sorting four attributes for a summarizer
A team is choosing a model for summarizing customer feedback. Their policy requires that customer text stay within their own infrastructure. The candidate is released under a license and has a summary accuracy that is currently low. Classify four attributes: the license, the privacy requirement, summary accuracy, and latency on a model they would run themselves.
- 1Check provider decisions
The license is a legal term set by the provider, so it is hard. Nothing done to the model's tuning changes it.
- 2Check your own policies
The privacy requirement comes from the team's own policy. It is hard for the team, because it is a decision already made by the organization.
- 3Check whether your access can change it
Summary accuracy is a soft attribute, as the source lists accuracy among soft attributes. Changing how the summarization task is posed can move it.
- 4Check latency with access
The team would run the model itself, so it has access to optimize. Latency is soft in this situation.
License and privacy are hard and should be checked first. Summary accuracy and latency are soft and can be pursued with effort, with a stopping point set in advance.
Mistakes When Estimating Soft Gains
Estimating how much you can improve a soft attribute is tricky, because you must balance optimism against realism. The source reports both a success and a failure. In one situation accuracy rose from around 20% to 70% after a change in task structure. In another, a model stayed unusable for the task even after weeks of tweaking, and the author had to give up on it. Both experiences concern soft attributes, and both are real.
Common mistake Assuming a soft attribute will reach your target with enough time
What it looks likeConcluding that accuracy is soft, so another week of prompt changes will get it to the level the project needs.
Why it failsSoft means effort can move the attribute. It does not promise how far it will move, and the source reports a case where weeks of tweaking still left the model unusable.
Do this insteadTreat the soft label as a reason to try, and decide in advance how much improvement would make the model worth keeping.
Common mistake Classifying a property by its name alone
What it looks likeDeciding that latency is always soft because it is something engineers often tune.
Why it failsThe source is explicit that the same property can be soft or hard. Latency is hard when the model is hosted by someone else.
Do this insteadAsk about your relationship to the model before deciding the classification.
Common mistake Trying to tune away a hard attribute
What it looks likeSpending days adjusting prompts to remove a licensing restriction on the model.
Why it failsHard attributes come from decisions already made. A license is a legal term, and training data was chosen before you arrived, so tuning cannot edit them.
Do this insteadCheck hard attributes first, and if one rules a model out, move to another candidate rather than investing effort in it.
Common mistake Skipping hard attributes until late in the process
Why it failsHard attributes can sharply narrow the candidate models, so leaving them until last wastes effort on models that a fixed property would have ruled out anyway.
Do this insteadSort the candidate's attributes first, and only pursue soft attributes on models that pass the hard checks.
Practice: Sorting a Real Decision
A colleague says that their chosen model's latency is a hard attribute because it is a fixed property of the model. The model is hosted by an outside provider, and the team can change the prompt structure but not the serving setup. Classify latency for this team and justify your answer. Then name one soft attribute they could still work on, and explain how you would decide when to stop.
Hints
- Ask whether the team's access to the model can change how it runs.
- The source says the same property can be hard or soft depending on the relationship to the model.
- Consider which attributes the source lists as soft, such as accuracy, toxicity, and factual consistency.
Key Takeaways
- Hard attributes are properties that are impossible or impractical to change, usually because of provider decisions such as license, training data, and size, or your own policies such as privacy and control.
- Soft attributes, such as accuracy, toxicity, and factual consistency, can be improved with effort, often by restructuring how a task is posed rather than by changing the model.
- Hard versus soft is a judgment about a specific model and use case. Latency is soft when you can optimize the model and hard when someone else hosts it.
- Check hard attributes first because they can narrow the candidates sharply, and pursue soft attributes with realistic expectations and a stopping point.