Module 4 — Prediction: learning patterns from the past

Lesson 13 of 16

Feature engineering

A machine-learning model learns from the inputs we give it.

But the same underlying information can often be represented in many different ways.

Some representations make the structure of a problem obvious.

Others make it difficult for the model to discover.

This process of choosing, transforming or constructing useful inputs is called feature engineering.

Feature engineering is the process of turning raw data into representations that make useful predictive structure easier for a model to learn.

At its simplest:

RAW DATA

↓

TRANSFORM / CONSTRUCT FEATURES

↓

MODEL INPUTS

↓

PREDICTION

Feature engineering sits between:

measurement

and:

learning.

A feature is not necessarily raw data

Suppose we want to predict electricity demand.

The raw data might contain a timestamp:

2026-01-12 18:30:00

A model could receive that timestamp directly.

But we might instead construct features such as:

hour of day,
day of week,
month,
weekend indicator,
public holiday indicator.

These derived variables may make the temporal structure much easier to learn.

Why representation matters

Suppose we represent time using:

hour = 23

and:

hour = 0.

Numerically:

23 and 0

look very far apart.

But in time:

23:00 and 00:00

are only one hour apart.

The raw numerical representation does not capture the circular structure of the variable.

Feature engineering can fix this.

Cyclical features

For variables such as:

hour of day,
day of week,
month of year,

the endpoints wrap around.

We can encode them using two cyclical components.

Conceptually:

HOUR

↓

POSITION AROUND A CIRCLE

Instead of:

0 and 23 being far apart

we represent them as nearby positions in a cycle.

This helps the model understand periodic structure.

Feature engineering is about exposing useful structure

Suppose a model receives:

date = 25 December.

The raw date may not immediately reveal why behaviour differs.

A derived feature:

PUBLIC_HOLIDAY = TRUE

may make the relationship much easier to learn.

The underlying information was already present.

We have simply represented it in a way more directly connected to the prediction task.

Raw data can hide relationships

Suppose an electricity dataset contains:

timestamp,
demand.

We might discover that demand depends strongly on:

the same hour yesterday.

The raw dataset contains that historical information.

But we can construct:

demand_lag_48

for half-hourly data.

Now the model receives:

Demand exactly 24 hours ago.

That can be highly predictive.

Lag features

For time-series data, lag features represent previous observations.

For example:

current prediction time = t

possible features:

Demand at t-1

Demand at t-2

Demand at t-48

Demand at t-336

for half-hourly data.

These correspond roughly to:

previous half hour,
previous hour,
same time yesterday,
same time last week.

Lags encode memory

A static model normally sees only the features supplied at one observation.

Lag features give it some history.

Conceptually:

PAST OBSERVATIONS

↓

LAG FEATURES

↓

CURRENT INPUT VECTOR

This allows even a relatively simple model to use temporal dependence.

Rolling features

We can also summarise recent history.

For example:

mean demand over previous 24 hours

maximum demand over previous week

standard deviation over previous 6 hours.

These are rolling features.

They compress a time window into useful statistics.

Rolling features represent recent state

Suppose one instantaneous demand value is noisy.

A rolling mean gives a more stable picture of recent behaviour.

Conceptually:

RECENT HISTORY

↓

SUMMARY

↓

FEATURE.

This is another way of turning history into a representation of the present.

But summarisation loses information

A rolling mean may be useful.

But it removes detail.

Suppose two demand profiles have the same 24-hour average:

Profile A

Stable all day.

Profile B

Huge evening peak and very low night demand.

The average is identical.

The underlying state is not.

Feature engineering always involves decisions about what information to preserve.

This connects to abstraction

Recall:

Models are representations, not reality.

Feature engineering is another layer of abstraction.

We decide:

which distinctions matter,
which details can be compressed,
which relationships should be exposed explicitly.

A good feature simplifies without destroying the information needed for the task.

Features can be directly measured

Examples include:

temperature,
pressure,
income,
speed.

These already exist as measured variables.

Features can be derived

Examples include:

age

derived from:

date of birth,
current date.

Or:

speed

derived from:

distance travelled,
elapsed time.

Derived features can encode relationships that would otherwise need to be learned from scratch.

Features can combine variables

Suppose house price depends strongly on:

price per square metre in the local area.

We might construct:

local average price / m².

This combines:

location,
historical sales,
floor area.

The feature captures contextual information that may be difficult to infer from raw variables alone.

Ratios can be useful

Suppose we predict building energy use.

Raw inputs:

total energy use,
floor area.

A derived variable might be:

energy use per m².

This can allow better comparison across buildings of different sizes.

But ratios should be used thoughtfully.

They impose a particular relationship between variables.

Differences can be useful

Suppose a heating system responds to:

inside temperature - outside temperature.

Instead of supplying both values separately, we might also include:

temperature difference.

This feature directly represents the physical driving force for heat loss.

Domain knowledge can guide features

An engineer may know that heat loss depends on:

temperature difference.

A transport planner may know that congestion depends on:

demand relative to capacity.

A financial analyst may know that:

debt-to-income ratio

contains useful information.

Feature engineering allows domain knowledge to shape the representation.

Feature engineering can make simple models powerful

Suppose the true relationship is complicated in the raw variables.

A carefully constructed feature may make it almost linear.

Then a simple model can perform extremely well.

This can reduce the need for:

large models,
heavy computation.

Good representation can substitute for some model complexity.

A simple example

Suppose:

y = x².

If we fit a straight line using only:

the model underfits.

But if we create:

x²

as a new feature, then:

can be predicted linearly from:

x².

The model did not become more sophisticated.

The representation did.

Polynomial features

More generally, we can construct:

x²,
x³,
x₁x₂.

These allow linear models to represent:

curves,
interactions.

This is called polynomial feature engineering.

Interaction features

Suppose electricity demand depends on:

temperature

and:

time of day.

Perhaps temperature matters much more at:

18:00

than:

03:00.

We can create an interaction feature involving:

temperature × time-of-day indicator.

This tells the model:

The effect of one feature may depend on another.

Interactions are everywhere

Examples include:

rain × rush hour → congestion

income × interest rate → borrowing behaviour

temperature × building type → heating demand

The impact of one variable is often conditional on another.

Feature engineering can expose that conditional structure explicitly.

Categorical variables need representation

Suppose building type is:

house,
apartment,
office,
factory.

A model cannot always use those words directly.

We need a numerical representation.

One common method is one-hot encoding.

One-hot encoding

Suppose:

BUILDING_TYPE

has three categories:

house,
office,
factory.

We create:

is_house

is_office

is_factory.

For a house:

[1, 0, 0]

For an office:

[0, 1, 0].

This avoids pretending the categories have a numerical order.

Why not simply encode categories as 1, 2, 3?

Suppose:

house = 1

office = 2

factory = 3.

A simple model may infer:

Factory is three times house.

Or:

Office lies halfway between house and factory.

Those relationships may be meaningless.

Numerical representation can accidentally introduce structure that is not really there.

Ordinal categories are different

Sometimes categories do have an order.

For example:

low

medium

high.

Representing them as:

1, 2, 3

may be reasonable.

But we should still ask whether the distances are meaningful.

Is:

high - medium

really the same difference as:

medium - low?

Not necessarily.

Encoding choices contain assumptions

This is a recurring theme.

The machine does not see:

category.

It sees:

the numerical representation we created.

Different encodings imply different relationships.

Representation is not neutral.

Scaling numerical features

Suppose one feature is:

age = 40.

Another:

income = 100,000.

Their numerical scales are very different.

Some learning algorithms work better if features are placed on comparable scales.

We might standardise them.

Standardisation

A common transformation is roughly:

value - mean

divided by:

standard deviation.

This produces a feature with:

mean near zero,
standard deviation near one.

The exact mathematics is less important than the idea:

Put variables onto a comparable numerical scale.

Why scaling helps

Gradient-based optimisation may behave poorly when one dimension has values around:

0.001

and another around:

1,000,000.

Scaling can make the optimisation landscape easier to navigate.

This connects feature engineering directly to gradient descent.

Scaling does not create information

If a feature contains no useful predictive information, standardising it does not make it informative.

Scaling changes:

representation,

not:

underlying evidence.

Log transformations

Suppose income ranges from:

€10,000

to:

€10 million.

The distribution may be highly skewed.

Using:

log(income)

can compress large values and reveal relationships that are easier to model.

Log transformations are common when variables span many orders of magnitude.

Why log scales appear often

Many real processes involve:

multiplicative change,
percentage growth.

For example:

10 → 20

and:

100 → 200

are both:

doublings.

A logarithmic representation treats these changes more similarly than the raw scale.

Transformation can linearise relationships

Suppose:

y grows exponentially with x.

In raw coordinates, the relationship is highly curved.

After an appropriate log transformation, it may become much closer to linear.

Again:

better representation

can allow:

simpler learning.

Binning

Sometimes continuous variables are converted into ranges.

For example:

age

becomes:

0–17,
18–34,
35–64,
65+.

This is binning.

It can simplify relationships.

But it also destroys information.

Binning creates boundaries

Someone aged:

34 years, 364 days

and someone aged:

35 years

may end up in different categories.

Yet they are almost identical in age.

The representation creates an artificial discontinuity.

This should be justified by the task.

Feature engineering always trades detail for structure

We might:

preserve raw values,
aggregate,
transform,
categorise.

Each choice changes:

what information is easy for the model to use.

There is no universally best representation.

Spatial feature engineering

Location is particularly interesting.

Raw location might be represented as:

latitude

and:

longitude.

But predictive relationships may depend on:

distance to city centre,
neighbourhood,
nearby infrastructure,
network connectivity.

We can construct those features.

Distance features

Suppose house price depends partly on:

distance to nearest train station.

The raw geographic coordinates contain enough information to calculate this.

But giving the model the derived distance directly may make the relationship easier to learn.

Neighbourhood features

We might calculate:

average local income,
average nearby property price,
number of schools within 2 km.

These features summarise spatial context.

But they also introduce choices about:

what counts as nearby.

Spatial aggregation creates scale choices

Should "local" mean:

100 metres,
1 km,
postcode,
county?

Different scales capture different relationships.

A feature useful at one spatial resolution may hide important structure at another.

Networks require different spatial representations

Geographic distance is not always the relevant concept.

Suppose electricity demand occurs at two houses physically close together.

They may sit on:

different network branches.

For electrical constraints, network topology may matter more than straight-line distance.

A useful feature might therefore describe:

network location,

not just latitude and longitude.

Feature engineering should reflect the system

This is a broader principle:

The right representation depends on the structure through which interactions occur.

For roads:

road network distance.

For electricity:

electrical network topology.

For social systems:

social connections.

For the internet:

network paths.

Space is not always Euclidean.

Time and space can interact

Suppose traffic congestion depends on:

location,
time.

A road may be:

free-flowing at 03:00

and:

severely congested at 08:30.

So we might construct features describing:

location × time-of-day.

Again, the important pattern is conditional.

Historical features can leak the future

Feature engineering creates one of the most common forms of data leakage.

Suppose we predict:

tomorrow's demand.

We construct:

average demand for the whole week.

But that average includes:

tomorrow's demand.

The feature contains part of the target.

The model is now cheating.

Every feature needs an information timestamp

A crucial question is:

Would this feature actually have been available at the moment the prediction was made?

If not, it should not be used.

This is especially important with:

rolling averages,
labels,
operational data.

A feature can be historically available but operationally unavailable

Suppose a dataset contains:

final laboratory test result.

Historically, it exists.

But if we need a prediction:

before the test has been completed,

that result cannot be an input.

Feature engineering must respect the real information boundary.

Feature engineering must match deployment

Suppose training calculates a sophisticated feature using:

a database available only to the research team.

But the deployed system cannot access that database.

The training performance is irrelevant.

A feature is useful only if it can be reliably produced in the real service.

Feature computation has a cost

Some features require:

sensors,
external data,
computation,
storage.

Suppose one feature improves accuracy by:

0.01%

but requires:

an expensive new sensor at every site.

It may not be worth collecting.

Feature selection is partly an economic decision.

Timeliness matters too

Suppose a feature is extremely predictive.

But calculating it takes:

30 minutes.

The service needs a decision in:

10 milliseconds.

The feature is operationally useless.

Prediction systems exist in time.

Feature freshness

Some features lose value as they age.

For example:

electricity demand five minutes ago

may be very informative.

electricity demand five years ago

may be less useful for an immediate forecast.

This suggests another feature property:

freshness.

Feature value depends on forecast horizon

Suppose predicting electricity demand:

5 minutes ahead.

Current demand may be extremely informative.

For:

10 years ahead,

current half-hourly demand matters much less.

Different prediction horizons require different representations.

Missing features

Suppose a sensor goes offline.

A feature becomes unavailable.

The model should not necessarily fail completely.

Possible approaches include:

imputation,
fallback features,
models designed for missing inputs.

But uncertainty should usually increase.

Missingness can itself be informative

Suppose a sensor goes offline mainly when:

equipment begins failing.

Then:

sensor missing = true

may itself be predictive.

Missingness is sometimes part of the signal.

Again:

Missing data is not automatically meaningless data.

Missingness indicators

We might create:

temperature_missing = 1

when the temperature measurement is unavailable.

The model can then distinguish:

measured temperature = 0°C

from:

temperature not measured.

This preserves information about the measurement process.

Features can encode the measurement system

Suppose different hospitals use different sensors.

A variable:

device type

may help correct systematic measurement differences.

But it may also cause shortcut learning.

The model might learn:

Hospital A → outcome.

Feature engineering must distinguish useful calibration information from spurious proxies.

Proxy features

A proxy is a feature that indirectly represents another variable.

Suppose we remove:

income.

But retain:

postcode,
occupation,
property value.

The model may infer income indirectly.

This matters greatly for fairness and privacy.

Feature engineering can introduce bias

Suppose we construct:

distance from prestigious university.

This may improve a hiring prediction.

But it may encode:

socioeconomic status,
educational opportunity.

The feature can be statistically useful while producing undesirable service behaviour.

Predictive usefulness is not enough

A feature should not be judged only by:

Does it improve validation accuracy?

We may also need to ask:

Is it legitimate?
Is it available?
Is it fair?
Is it stable?
Is it private?
Does it make causal sense?
Will it remain predictive?

Feature engineering is part of service design.

Sensitive features can sometimes improve fairness

There is an important subtlety.

It may seem obvious that a fair model should never use sensitive characteristics.

But sometimes measuring group membership is necessary to:

identify unequal performance,
correct disparities.

So:

using a sensitive feature

and:

discriminating unfairly

are not automatically the same thing.

The governance question is more complicated.

Removing a feature does not remove information

Suppose we remove:

ethnicity.

But location and language are strongly correlated with ethnicity.

The model may reconstruct much of the same information.

So:

Fairness cannot be achieved simply by deleting one column.

We will return to this in Module 11.

Feature engineering can hide human judgement

Suppose someone creates a feature:

customer quality score.

That sounds objective.

But how was it created?

Perhaps it combines:

income,
postcode,
previous decisions.

The feature may compress many hidden assumptions into one number.

Derived features should be interrogated, not treated as naturally occurring facts.

A feature can be a model output

Suppose:

Model A

predicts weather.

Its output becomes a feature for:

Model B

which predicts electricity demand.

So:

WEATHER MODEL

↓

WEATHER FORECAST FEATURE

↓

DEMAND MODEL.

Modern systems often contain chains of models.

Uncertainty should propagate

Suppose the weather prediction is:

highly uncertain.

If the demand model receives only:

temperature = 10°C

it may treat that value as exact.

A better system might also receive information about:

weather forecast uncertainty.

Otherwise, uncertainty disappears between models.

A prediction can be represented by more than its mean

Instead of:

temperature forecast = 10°C,

features might include:

expected temperature,
lower bound,
upper bound,
probability of frost.

This preserves more of the forecast distribution.

Feature engineering can preserve uncertainty

This connects directly to Module 3.

A raw measurement might be represented as:

20°C ± 2°C.

Instead of giving only:

20,

the model might receive:

measured value,
uncertainty estimate.

A richer representation acknowledges that inputs are not perfectly known.

Features can represent state

Suppose a battery system has:

current power,
current voltage,
recent charging history.

But the future depends strongly on:

state of charge.

We can estimate:

state of charge

and provide it as a feature.

Now we have moved from:

raw observations

to:

estimated state.

State can be a powerful engineered representation

Recall:

Observation is not the same as state.

The raw sensor readings describe what we observe.

A state representation tries to describe:

What about the system now matters for what happens next?

Feature engineering can therefore become:

state engineering.

A robot provides a clear example

Raw inputs:

camera pixels,
accelerometer,
GPS,
lidar.

A useful internal representation might include:

current position,
velocity,
nearby objects,
battery level.

These state variables are much more directly useful for:

prediction,
planning,
control.

State estimation can be learned or engineered

Traditional systems may estimate state using:

physical models,
Kalman filters.

Modern systems may use:

neural networks,
learned representations.

Either way, the principle is similar:

RAW OBSERVATIONS

↓

INFER USEFUL REPRESENTATION OF CURRENT WORLD

↓

PREDICT / DECIDE.

Modern deep learning changed feature engineering

Traditional machine learning often required large amounts of manual feature engineering.

For example, computer vision pipelines might manually compute:

edges,
corners,
textures.

Then feed those features into a classifier.

Deep learning changed this.

Representation learning

A deep neural network can learn features directly from raw inputs.

Conceptually:

RAW PIXELS

↓

EARLY LAYERS LEARN SIMPLE PATTERNS

↓

LATER LAYERS LEARN RICHER PATTERNS

↓

PREDICTION.

The model performs its own form of feature construction internally.

This is called representation learning.

Feature engineering did not disappear

It changed level.

Humans may no longer manually specify every:

edge,
shape.

But we still choose:

input modality,
tokenisation,
context window,
image resolution,
training examples,
architecture.

Those choices determine what representations can be learned.

Language provides a good example

Raw text:

"The cat sat on the mat."

A language model does not directly process the sentence as a human-readable string.

First it is transformed into:

tokens.

Then tokens become:

vectors.

These are representations.

Later modules will explore:

tokenisation,
embeddings,
attention.

Modern AI is still deeply about feature representation.

Embeddings are learned features

An embedding converts an object into a vector.

For example:

word → vector

image → vector

user → vector.

The vector positions can capture useful similarities.

Conceptually:

SIMILAR THINGS

↓

NEARBY REPRESENTATIONS.

Embeddings are a powerful form of learned feature engineering.

Learned features can outperform human-designed features

For very complex inputs such as:

images,
sound,
language,

humans may struggle to define all useful features explicitly.

Deep models can discover representations we would not have designed manually.

This is one of the reasons modern AI became so powerful.

But learned representations can also learn shortcuts

A neural network may learn:

background snow

instead of:

wolf anatomy.

Automatic feature learning does not guarantee:

the right features.

It simply finds representations that help reduce the loss.

Interpretability becomes harder

With manual features, we might know exactly what:

temperature difference

means.

A deep model may construct a 4,096-dimensional latent representation.

Its individual dimensions may have no obvious human interpretation.

This creates new challenges for understanding model behaviour.

Feature importance

Once a model has many inputs, we naturally want to ask:

Which features matter most?

This is the idea of feature importance.

But there are several different questions hidden inside that phrase.

Global feature importance

A global question asks:

Across many predictions, which features does the model rely on most?

For example, in a house-price model:

location,
size,
age.

This describes broad model behaviour.

Local feature importance

A local question asks:

Why did the model make this particular prediction?

Suppose:

Predicted house price = €600,000.

We might want to know how much was associated with:

location,
floor area,
condition.

This is an explanation of one prediction.

Feature importance is not always obvious

Suppose two features are:

temperature in Celsius

and:

temperature in Fahrenheit.

They contain essentially the same information.

If the model uses both, how should importance be divided between them?

There is no simple answer.

Information can overlap

Suppose:

Feature A

and:

Feature B

are highly correlated.

Either one alone predicts the target well.

Together they add little extra information.

Now ask:

Which feature deserves the credit?

This becomes a value-allocation problem.

Marginal contribution

One approach is to ask:

How much better does the prediction become when Feature A is added?

But added to what?

If A is added first, perhaps its contribution is large.

If B is already present, A may contribute almost nothing.

So feature value is conditional on:

what other features are already available.

Example: predicting house price

Suppose:

baseline prediction = €400,000.

Knowing:

location

raises the prediction to:

€520,000.

So location appears to contribute:

+€120,000.

Then add:

floor area.

Prediction rises to:

€600,000.

Floor area appears to contribute:

+€80,000.

But reverse the order.

Reverse the order

Start again:

baseline = €400,000.

Add:

floor area.

Prediction becomes:

€530,000.

Contribution:

+€130,000.

Then add:

location.

Prediction becomes:

€600,000.

Contribution:

+€70,000.

Now the apparent contributions changed.

Which ordering is correct?

Neither is uniquely privileged.

Feature contribution depends on the coalition

The contribution of one feature depends on which other features are already present.

This is exactly the type of problem studied in cooperative game theory.

Imagine:

features = players

and:

prediction = value created by their coalition.

Then ask:

How should the total predictive contribution be allocated fairly among the features?

This leads to Shapley values.

Shapley values

The Shapley value considers a feature's marginal contribution across different possible combinations of the other features.

Conceptually:

FEATURE A ADDED EARLY

→ contribution

FEATURE A ADDED AFTER B

→ contribution

FEATURE A ADDED AFTER C

→ contribution

FEATURE A ADDED AFTER B + C

→ contribution

and so on.

Then average those marginal contributions fairly.

The key idea

Instead of choosing one arbitrary feature ordering, the Shapley approach asks:

On average, how much does this feature contribute across all the different contexts in which it could be added?

This provides a principled way of sharing predictive credit.

Shapley values come from cooperative game theory

The idea was originally developed to answer questions such as:

A group of players cooperates and creates some total value. How should that value be allocated among them according to their marginal contributions?

In machine learning:

PLAYERS

become:

FEATURES.

The:

COALITION VALUE

becomes something related to:

THE MODEL PREDICTION.

A simple feature-attribution example

Suppose:

Baseline prediction = €400,000

and:

Final prediction = €600,000.

The difference is:

€200,000.

A Shapley-style explanation might allocate that difference as:

Location: +€110,000

Floor area: +€70,000

Garden: +€30,000

Building age: -€10,000.

Then:

€400,000

€110,000

€70,000

€30,000

−

€10,000

€600,000.

The contributions add back to the prediction difference.

Positive and negative feature contributions

A feature can move the prediction:

or:

down

relative to a baseline.

For example:

good location → +€100,000

poor condition → -€40,000.

The attribution tells us how the model's prediction changed relative to its reference point.

The baseline matters

A Shapley explanation is always relative to some baseline or expected model output.

So:

Contributed +€100,000

does not mean:

This feature universally creates €100,000 of value.

It means:

Relative to the chosen reference, this feature helped move this model's prediction by that amount.

Context matters.

Feature attribution explains the model

This distinction is essential.

Suppose a model says:

postcode contributes +€50,000.

That means:

Postcode helped drive the model's prediction.

It does not automatically mean:

Changing postcode while everything else stayed fixed would causally increase house value by €50,000.

Shapley attribution is primarily about:

model explanation,

not:

causal effect.

Predictive value is not causal value

A feature can be highly predictive without causing the outcome.

For example:

umbrella use

may help predict:

rain.

But umbrellas do not cause rain.

Likewise, feature importance tells us what information the model uses.

It does not necessarily tell us what intervention would change reality.

Correlated features complicate attribution

Suppose:

postcode

and:

local income

contain overlapping information.

How should predictive contribution be divided?

Different assumptions about dependence between features can affect the attribution.

So Shapley values are principled, but their implementation still requires choices.

SHAP

A widely used family of methods for estimating Shapley-style feature contributions in machine learning is known as SHAP.

The name comes from:

SHapley Additive exPlanations.

SHAP methods aim to explain individual predictions using feature contributions derived from Shapley theory.

Exact Shapley values can be expensive

Suppose there are:

n features.

There are many possible feature coalitions.

As n grows, evaluating every possible combination becomes computationally expensive.

So practical methods often use:

approximations,
model-specific shortcuts.

The underlying principle remains the same.

The number of coalitions grows rapidly

With:

2 features

there are few combinations.

With:

10 features

there are many more.

With:

100 features,

exhaustive enumeration becomes impractical.

This is another example of combinatorial growth.

Feature value depends on what is already known

The deeper conceptual lesson is broader than SHAP.

Suppose Feature A provides information.

Its value depends on:

what information we already possess.

If another feature already tells us almost the same thing, A adds little.

If we know nothing similar, A may be extremely valuable.

So:

Information has marginal value.

This connects to conditional probability

Recall:

P(Y | X).

New evidence changes what we believe about Y.

But the impact of new evidence depends on:

what else is already conditioned upon.

Feature attribution and conditional probability are closely related conceptually.

Feature engineering and feature valuation are different

First:

FEATURE ENGINEERING

asks:

What information should we provide to the model?

Then:

FEATURE ATTRIBUTION

asks:

How much did the model use each piece of information?

These are different stages.

Feature importance can guide feature engineering

Suppose a feature consistently contributes almost nothing.

Perhaps we can remove it.

This may:

simplify the model,
reduce data collection,
reduce compute.

But we should be careful.

A feature may matter only in:

rare situations.

Global average importance can hide local value.

A feature can matter enormously in the tail

Suppose:

equipment vibration anomaly

appears rarely.

Most of the time it contributes little.

During impending failure, it becomes crucial.

Average importance may appear low.

Operational importance can still be enormous.

Again:

frequency ≠ importance.

Global importance can hide interactions

Suppose Feature A matters only when:

Feature B is high.

Its average importance may be modest.

But within that regime it may dominate predictions.

Feature analysis should consider:

interactions,
subgroups,
system states.

Feature engineering is iterative

A typical workflow might be:

BUILD FEATURES

↓

TRAIN MODEL

↓

EVALUATE

↓

INSPECT ERRORS

↓

INSPECT FEATURE IMPORTANCE

↓

DESIGN BETTER FEATURES

↓

TRAIN AGAIN.

Feature engineering is often a cycle rather than a one-time step.

Residuals can suggest new features

Suppose a demand model repeatedly underpredicts:

Monday mornings.

This suggests adding or improving:

day-of-week × time-of-day features.

The model's errors reveal missing structure.

Domain experts remain valuable

A generic learning algorithm may not know:

network topology,
physical constraints,
institutional rules.

A domain expert can recognise useful representations.

For example, in electricity systems:

demand / local capacity

may be more informative than demand alone.

Domain knowledge can dramatically improve feature design.

But human intuition can also introduce bad features

An expert may strongly believe:

Variable X must matter.

But evidence shows it contributes little.

Feature engineering should combine:

domain knowledge

with:

empirical evaluation.

Neither should be blindly trusted.

Automatic feature selection

Algorithms can also help determine which features to retain.

Approaches include:

regularisation,
tree-based importance,
recursive feature elimination.

The goal is often to reduce irrelevant or redundant inputs.

Feature selection is not only about predictive performance

Suppose two feature sets perform almost identically.

Model A

uses:

100 features.

Model B

uses:

10 features.

Model B may be preferable because it requires:

less data collection,
less compute,
simpler governance.

The cheapest useful information can be more valuable than maximum information.

Information itself is a resource

Collecting information requires resources.

Sensors require:

hardware,
maintenance,
energy.

Personal data creates:

privacy costs,
governance obligations.

Feature engineering therefore becomes partly:

information-resource design.

The value of a feature should be compared with its cost

Suppose Feature A improves prediction significantly and costs almost nothing.

Excellent.

Feature B improves accuracy by:

0.001%

but requires:

invasive surveillance,
enormous storage.

Perhaps it is not worthwhile.

The right question is not:

Does the feature have predictive value?

It is:

Does its predictive value justify the cost and consequences of obtaining it?

This connects to service design

An intelligent service must decide:

WHAT TO MEASURE

↓

WHAT TO STORE

↓

WHAT TO INFER

↓

WHAT TO PREDICT

↓

WHAT TO DO.

Feature engineering sits near the beginning of that chain.

Choices made there propagate through the entire system.

Features can create feedback loops

Suppose a credit model uses:

historical loan approval rate in the neighbourhood.

The model influences new approvals.

Those approvals change:

future historical approval rates.

The feature is no longer passive.

The prediction system helps create its future inputs.

Endogenous features

A feature is endogenous when it is influenced by the system or decisions we are studying.

This can make relationships more difficult to interpret.

In deployed AI, many features become endogenous because previous model decisions affect future data.

Reflexive feature systems

Consider recommendations.

A feature might be:

number of previous clicks on this type of content.

But previous recommendations influenced those clicks.

So:

MODEL

↓

RECOMMENDATION

↓

CLICK

↓

FEATURE

↓

NEXT MODEL DECISION.

The feature is part of a feedback loop.

Feature distributions can shift

Suppose a model uses:

working from home = yes/no.

Historical prevalence:

5%.

Then society changes.

New prevalence:

40%.

The feature still exists.

But its distribution changed dramatically.

Models must be monitored for this kind of shift.

Feature relationships can shift too

More seriously, the relationship between:

feature

and:

target

can change.

Perhaps postcode once strongly predicted commuting behaviour.

Remote work weakens the relationship.

Feature engineering is not permanent.

Useful representations can become obsolete.

Feature stores

Large organisations sometimes maintain central systems called feature stores.

These help manage:

feature definitions,
computation,
timestamps,
reuse.

The idea is operational rather than theoretical:

Ensure the same features are generated consistently for training and deployment.

Training-serving skew

A common production problem occurs when features are calculated differently during:

training

and:

deployment.

For example:

Training:

carefully cleaned historical variable.

Deployment:

noisy real-time sensor.

The model sees a different representation in reality.

This is sometimes called:

training-serving skew.

Feature pipelines are part of the model

It is tempting to think the model begins at:

neural network input.

In reality, the system includes:

SENSORS

↓

DATA PROCESSING

↓

FEATURE ENGINEERING

↓

MODEL.

If the feature pipeline fails, the model can fail even if its parameters are unchanged.

Models depend on data infrastructure

Suppose a critical feature stops updating.

The model may continue producing predictions.

They may look normal.

But the information is stale.

Operational AI therefore needs monitoring of:

features,
timestamps,
missingness,
distributions.

Model monitoring alone is not enough.

Feature engineering and privacy

Suppose the system could improve prediction by collecting:

continuous precise location.

Should it?

Perhaps the same service can be achieved with:

coarse area information.

Feature engineering can deliberately minimise data collection.

This is data minimisation.

Data minimisation

A useful principle is:

Collect only the information needed for the service.

This can reduce:

privacy risk,
storage,
attack surface,
cost.

Maximum data is not always good system design.

More data can create more liability

Every additional feature can create:

security obligations,
governance complexity,
opportunities for bias.

So there is value in asking:

Can we achieve sufficiently good predictions with less information?

Feature engineering can support explainability

Human-readable features such as:

temperature,
distance,
debt ratio

are often easier to explain than:

latent dimension 2,147.

If interpretability matters, feature representation can be designed accordingly.

But human-readable does not mean causal

A feature called:

risk_score

may sound meaningful.

It could still be:

poorly defined,
biased.

Names do not create truth.

Every engineered feature should be understood in terms of how it is constructed.

Feature engineering is part of modelling

It is sometimes treated as preprocessing before the "real" AI begins.

That is misleading.

Choosing features changes:

what relationships can be learned,
which assumptions are embedded,
how well the model generalises.

Feature engineering is modelling.

Modern AI shifted the boundary

Traditional machine learning:

HUMAN ENGINEERS FEATURES

↓

MODEL LEARNS MAPPING.

Deep learning:

HUMANS DEFINE RAW REPRESENTATION + ARCHITECTURE

↓

MODEL LEARNS MANY INTERNAL FEATURES

↓

MODEL LEARNS MAPPING.

Feature design became more automated.

It did not disappear.

Learned representations can themselves be reused

Suppose a model learns an embedding for:

images.

That embedding can become input to:

classification,
search,
recommendation.

So one learned model can act as:

a feature generator

for another.

Foundation models are powerful feature generators

A large pre-trained model can transform:

text,
images

into rich representations.

Smaller downstream models can use those representations.

This is one reason foundation models are so reusable.

They provide general-purpose learned features.

Feature engineering and Shapley values create a useful loop

We can now put the two ideas together.

First:

ENGINEER FEATURES

↓

TRAIN MODEL.

Then:

CALCULATE FEATURE CONTRIBUTIONS

↓

UNDERSTAND WHAT THE MODEL USES.

Then ask:

Are these features sensible?
Are they proxies?
Are some redundant?
Are some unexpectedly dominant?
Are interactions important?

That informs the next round of feature design.

A simple Shapley calculation

To understand the basic logic, imagine a model with only two features:

A = location

B = floor area.

Suppose the prediction values are:

No features: €400k

A only: €520k

B only: €530k

A + B: €600k.

Now calculate A's marginal contribution under both possible orders.

Order 1: A then B

Start with:

€400k.

Add A:

€520k.

A contributes:

+€120k.

Then add B:

€600k.

B contributes:

+€80k.

Order 2: B then A

Start with:

€400k.

Add B:

€530k.

B contributes:

+€130k.

Then add A:

€600k.

A contributes:

+€70k.

Average the marginal contributions

For Feature A:

(+€120k + €70k) / 2

+€95k.

For Feature B:

(+€80k + €130k) / 2

+€105k.

Together:

€95k + €105k = €200k.

And:

€400k baseline + €200k contribution = €600k prediction.

These are the Shapley values for this simple two-feature example.

Why average across orders?

Because neither ordering:

A then B

nor:

B then A

has a privileged claim to being correct.

A fair attribution considers both.

With more features, we consider marginal contribution across many possible coalitions and orderings.

Three features become more interesting

Suppose we now have:

location,
floor area,
garden.

A feature can be added:

first,
after one other feature,
after both other features.

Its contribution may differ in each case.

The Shapley value aggregates these possibilities according to a principled weighting.

Shapley values satisfy useful fairness properties

The Shapley value is attractive because it satisfies several axiomatic properties.

Very roughly:

Efficiency

All allocated contributions add up to the total value being explained.

Symmetry

Features making identical contributions should receive identical value.

Dummy

A feature that never changes the prediction should receive zero contribution.

Additivity

Contributions behave consistently when games or value functions are combined.

These properties provide a mathematical notion of fair attribution.

The word "fair" needs context

Here, fair means:

Satisfies the mathematical allocation axioms of the Shapley value.

It does not automatically mean:

socially fair.

A perfectly computed Shapley explanation of a discriminatory model does not make the model socially fair.

This distinction is important.

A Shapley method may allocate predictive contribution accurately.

But the underlying model may still:

use biased data,
rely on problematic features.

So we need to distinguish:

FAIR CREDIT ALLOCATION WITHIN THE MODEL

from:

FAIR OUTCOMES FOR PEOPLE.

They are different questions.

Shapley explanations can reveal problematic features

Suppose a lending model's predictions consistently depend heavily on:

postcode.

That does not prove discrimination.

But it gives us a clue worth investigating.

Explainability helps us ask better questions.

Explanations should not become unquestionable just because they are mathematical

A SHAP plot can look authoritative.

But its interpretation depends on:

baseline,
feature dependence assumptions,
model behaviour.

Feature attribution should be treated as:

evidence about the model

not:

absolute truth about the world.

Feature value is context-dependent

Suppose temperature is extremely useful for predicting demand in winter.

During summer:

almost irrelevant.

A single global feature importance score can hide this.

Local Shapley values can reveal how importance changes with system state.

Stateful feature value

This gives us an interesting broader idea:

The value of information can change with the state of the system.

When supply is abundant, one demand feature may have little operational value.

During scarcity, the same information may become crucial.

Information value is not necessarily static.

Feature value can change through time

Suppose yesterday's electricity demand is usually a strong predictor.

Then a major holiday occurs.

Its value drops.

So:

feature importance itself can be time-varying.

A model explanation from one period may not describe another.

Feature value can change through space

Suppose temperature strongly predicts heating demand in:

cold northern regions.

It may be less informative in:

warmer regions.

Again:

feature contribution is contextual.

This leads toward intelligent service design

A service may ask not only:

What information exists?

but:

Which information is valuable right now?

Perhaps some sensors should be sampled more frequently during critical states.

Perhaps expensive information should be acquired only when uncertainty is high.

Now feature selection becomes dynamic.

Active sensing

A robot may choose:

Should I take another camera observation?

Should I activate lidar?

Should I ask a human?

Information acquisition itself can become a decision.

This is active sensing.

The value of information can guide sensing

Suppose a sensor measurement costs:

energy.

The robot should perhaps collect it only when:

expected decision improvement > sensing cost.

Now:

feature acquisition

becomes an optimisation problem.

Intelligent systems do not necessarily need every feature all the time

Traditional machine learning often assumes:

All inputs are simply available.

But real systems may have to decide which information to obtain.

Examples include:

medical tests,
sensors,
database queries.

Information has a cost.

A medical example

Suppose a doctor can order:

Test A

for €10

or:

Test B

for €5,000.

Test B is more informative.

But perhaps Test A already resolves most cases.

The marginal value of Test B depends on:

what is already known.

This is the same coalition logic that appears in feature value.

Shapley theory exposes a broader idea

The real lesson is not merely:

Here is a technique called SHAP.

It is:

Value often depends on marginal contribution within a system of interacting components.

A feature has no fixed intrinsic predictive value independent of:

what other information is available.

This idea will return later when we discuss:

shared resources,
allocation,
fairness.

Feature engineering is therefore also feature economics

Information can have:

acquisition cost,
storage cost,
predictive value,
privacy cost.

A rational service design might ask:

Which set of features produces the greatest useful value relative to its costs?

This turns feature design into a resource-allocation problem.

More information can sometimes hurt

Suppose we add a highly correlated noisy feature.

The model overfits it.

Test performance falls.

Or add sensitive data that creates governance problems.

So:

MORE INFORMATION

does not automatically mean:

BETTER SERVICE.

The best representation depends on the model

A feature that helps linear regression may be unnecessary for a neural network capable of learning the transformation itself.

For example:

x²

may need to be manually engineered for a simple linear model.

A neural network may learn a nonlinear transformation internally.

Feature design and model architecture interact.

The best representation depends on the data volume

Suppose we have:

500 observations.

Strong feature engineering may allow a simple model to learn effectively.

Suppose we have:

billions of examples.

A large model may learn useful representations automatically.

The balance between:

human knowledge

and:

learned representation

changes with scale.

Feature engineering can improve data efficiency

A well-designed feature tells the model something we already understand about the problem.

It may allow the same performance with:

much less training data.

This is especially valuable when data is scarce or expensive.

Learned features can improve flexibility

Manual features encode our current understanding.

Learned representations may discover relationships we did not anticipate.

This can improve flexibility.

The trade-off is often:

strong human assumptions

versus:

greater learned flexibility.

Hybrid approaches are common

Real systems often combine both.

For example:

physical state variables

learned image embeddings

calendar features

↓

prediction model.

There is no need to choose between:

manual

and:

learned

features exclusively.

Feature engineering and causality

Suppose we want to make predictions under intervention.

A feature may predict well historically but change when policy changes.

Causal variables may generalise more robustly under intervention.

So feature selection depends partly on whether we want:

pure prediction

or:

decision-making under changed conditions.

A predictive feature can disappear under intervention

Suppose umbrellas predict rain.

If we intervene by giving everyone an umbrella regardless of weather:

umbrella possession

stops being predictive.

The historical relationship depended on behaviour.

This illustrates why causal reasoning can matter for service design.

Features can become targets

Suppose a university admissions system uses:

standardised test score.

Students know this.

They optimise heavily for the test.

The feature distribution changes.

Its relationship with underlying academic ability may also change.

Once a feature influences decisions, it can become subject to Goodhart's Law.

Feature engineering in adversarial systems

Fraud detection provides a clear example.

Suppose:

Feature A

strongly predicts fraud.

The system begins blocking transactions with Feature A.

Fraudsters adapt and stop exhibiting it.

The feature's predictive value disappears.

Features are not always passive descriptions.

Robust features

In changing environments, we would like features whose relationships remain stable under:

time,
strategic response,
distribution shift.

Finding such representations is difficult.

But it is often more valuable than simply maximising short-term predictive accuracy.

Feature engineering and future models

Modern AI increasingly moves toward models that learn representations directly from enormous datasets.

But the fundamental question remains unchanged:

How should reality be represented so that useful structure can be learned?

Whether the representation is:

manually constructed,
learned,

the problem is still there.

A useful feature-engineering checklist

When building or reviewing features, ask:

What does this feature represent?
How was it measured or constructed?
Would it be available at prediction time?
Does it leak future information?
Does it encode time appropriately?
Does it encode space appropriately?
Is important history missing?
Does the system need lag or rolling features?
Are important interactions represented?
Are categorical values encoded sensibly?
Is scaling needed?
Could a transformation reveal structure?
Are important features missing?
Are some features redundant?
Could this feature act as a sensitive proxy?
How expensive is it to collect?
How fresh is it?
Will it still exist in deployment?
Does its predictive value remain stable?
What uncertainty does it contain?
Could missingness itself be informative?
How much does it contribute to predictions?
Does feature importance vary across time, space or groups?

Feature engineering is not merely data cleaning.

It is part of the intellectual design of the model.

The central idea

A machine-learning model does not learn from:

reality directly.

It learns from:

representations of reality.

Feature engineering shapes those representations.

Conceptually:

REALITY

↓

MEASUREMENT

↓

RAW DATA

↓

FEATURE ENGINEERING

↓

MODEL INPUTS

↓

LEARNING

↓

PREDICTION.

A well-designed feature can:

expose useful structure,
reduce required model complexity,
improve generalisation.

A badly designed feature can:

create leakage,
hide important variation,
introduce bias,
encourage shortcuts.

And once we have features, another question emerges:

How valuable is each piece of information to the model?

That leads to feature attribution.

In particular, Shapley theory gives us a principled way to ask:

How should the predictive value created by a coalition of interacting features be allocated among them?

That is a powerful bridge from machine learning into a much broader idea we will encounter repeatedly in this course:

Value is often not intrinsic to one component. It depends on that component's marginal contribution to a larger system.

The next lesson will build directly on this and look at:

feature importance and Shapley values — how we can measure which inputs drive predictions, why interacting features make attribution difficult, and what model explanations can and cannot tell us.

Previous lesson12. Generalisation