Privacy by Design in the machine learning pipeline
+
Workshop, University of Venice
+
+
+
+
+Zak Varty
+
+
+
+
+
2024-11-01
+
+
+
Hello! Who am I?
+
+
+
+
Statistician by training, got to where I am through medical, environmental and industrial applications.
+
Teaching Fellow at Imperial College London
+
+
Data Science, Data Ethics
+
+
Privacy, fairness and explainability in ML.
+
+
Capable enthusiast, realist / pessimist
+
+
+
Really it all comes down to doing good statistics well.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Why do we care about privacy?
+
+
+
Protecting Sensitive Data: ML models often train on personal or confidential data (health records, financial info), and safeguarding this data is essential to prevent misuse or unauthorized access.
+
Compliance with Regulations: Laws like GDPR require organisations to protect user privacy, impacting how data is collected, stored, and used in ML.
+
Preventing Data Leakage Models can unintentionally expose sensitive information from their training data, risking user privacy if someone exploits the model’s outputs.
+
Building Trust: Privacy-conscious ML practices foster trust among users, making them more willing to share data and participate in systems that use ML.
+
Avoiding Discrimination: Privacy techniques can reduce bias and discrimination risks, ensuring the ML model treats users fairly without targeting sensitive attributes.
+
+
+
+
+
“If you have nothing to hide, you have nothing to fear”
+
+
+
+
+
+
“The benefits outweight the costs”
+
+
+
+
Machine Learning Pipeline
+
+
+
+
Machine Learning Pipeline Life Cycle
+
+
+
Reality is much messier. See Gelman and Loken (2013) for a discussion of the implications.
+
+
+
+
+
This workshop
+
+
+
+
+
Work through the ML life cycle
+
How could and have things gone wrong
+
+
+
+
+
+
What tools do we have?
+
What are their limitations?
+
+
+
+
+
+
Interactive bits, every now and then
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
1. Data Collection
+
+
+
+
Collecting Appropriate Data - GDPR
+
+
+
+
Collect only necessary data, purpose clear at time of collection
+
Data subject has right to
+
+
access
+
rectify
+
erase
+
object
+
+
Consequences both financial and reputational
+
+
+
+
+
+
+
+
+
Collecting Data - Hard-to-Reach Groups
+
Standard ML assumes that data are cheap and easy to collect.
+
Assumption that data are cheap and easy to collect. Out of the box model fitting assumes we are working with big, representative and independent samples.
+
+
+
Applications of ML to social science to study hard-to-reach populations: persecuted groups, stigmatised behaviours.
+
Standard study designs and analysis techniques will fail.
+
+
+
+
+
Snowball Sampling - Hidden Network
+
+
+
+
Snowball Sampling - Initial Recruitment
+
+
+
+
Snowball Sampling - Referral Round 1
+
+
+
+
Snowball Sampling - Referral Round 2
+
+
+
+
Snowball Sampling - Referral Round 3
+
+
+
+
Snowball Sampling
+
+
+
By using subject-driven sampling design, we can better explore the hard to reach target population while preserving the privacy of data subjects who do not want to be included in the study.
+
+
+
Bonus: Also allows us to study community (network) structure if we are interested in that.
+
+
+
+
+
Drawbacks:
+
+
“isolated” nodes,
+
partitioned graphs,
+
adapting model fitting to non-uniform sampling.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Collecting Data - Asking Difficult Questions
+
Even if data subjects are easy to access and sample from, they may not wish to answer honestly.
+
Can you give me some examples?
+
+
+
+
cheated on an exam?
+
cheated on a romantic / sexual partner?
+
experienced suicidal ideation?
+
killed another person?
+
+
+
+
+
Dishonest answers will bias any subsequent analysis, leading us to underestimate the prevalence of an “undesirable outcome”.
+
+
+
(Interesting intersection with survey design and psychology. The order and way that you ask questions can influence responses but we will focus on a single question here.)
Our estimator worked “best” for central values of \(\theta\), unlikely for stigmatised events.
+
Add random element to survey to provide plausible deniability.
+
+
Flip a fair coin. If heads, switch your answer.
+
+
MoM estimation: Equate probabilities and proportions.
+
+
+
+
Estimation from Randomised Response Data
+
+
+
Consider using a weighted coin, probability \(p\) of telling truth. Derive an expression for the probability of answering “Yes”.
+
+
\[\begin{align*}
+\Pr(\text{Yes}) &= \theta p + (1 - \theta)(1 - p) \\
+& \approx \frac{\#\{yes\}}{\#\{subjects\}} \\
+&= \bar y
+\end{align*}\]
+
+
+
Rearrange this expression to get a formula for \(\hat \theta\).
+
+
+
\[\hat \theta = \frac{\bar y - 1 + p}{2p -1}.\]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Randomised Response Activities
+
\[ \hat \theta = \frac{\bar y - 1 + p}{2p -1}.\]
+
+
Direct response is a special case of randomised response. How can we use that to check our working?
+
+
+
+
If our previous survey results came from this randomised response survey design with \(p = 0.25\), what is your best guess of the proportion of people who have been unfaithful?
+
+
+
+
+
Are you more or less confident in this estimate than previously, when we had the same data but from a direct response design?
+
+
+
+
+
What does your confidence depend on? And which of those factors do you have knowledge of / control over?
+
+
+
+
+
When would this estimation procedure break and why? How could we fix that?
+
+
+
+
+
Randomised Response - Privacy Schematic
+
+
+
+
Randomised Response
+
+
Approach to privacy for single, binary response.
+
Issues with applying to multiple questions, e.g. surveys with follow on questions.
+
Extensions to categorical and continuous responses and predictors
+
General principle of adding noise
+
+
Need to make observations indistinguishable
+
Need to preserve important aspects of “signal”
+
+
+
+
+
Data Collection Summary
+
+
Collect what you need and use that information only for its intended purpose.
+
Targeting hard-to-reach populations can be challenging but possible by combining survey design and specific learning approaches. Keeps statisticians in a job!
+
Asking difficult questions can lead to biased responses. Plausible deniability through randomised response designs can help.
+
+
+
+
+
2. Data Storage
+
+
+
+
Encryption
+
Once we have gone to the effort of collecting data we don’t want to just leave it lying around for anyone to access.
+
+
+
\[ \text{Plain text} \overset{f}{\rightarrow} \text{Cipher Text}\] \[ \text{Cipher text} \overset{f^{-1}}{\rightarrow} \text{Plain Text}\] \[ f(\text{data}, \text{key})\] Many encryption schemes depending on the data to be encrypted and how the key is to be distributed.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Caesar Cipher
+
+
+
Have a go at decrypting the encrypted message f(?, 2 ) = JGNNQ YQTNF.
+
+
+
What are some benefits and drawbacks of this encryption scheme?
+
+
+
+
K-anonymity
+
What happens if someone gets access to the data?
+
+
+
\(k\)-anonymity is a measure of privacy within a dataset.
+
Given a set of predictor-outcome responses, each unique combination forms an equivalence class.
+
The smallest equivalence class of a \(k\)-anonymous dataset is of size \(k\).
+
Equivalently, each individual is indistinguishable from at least \(k-1\) others.
+
+
+
+
K-anonymity Example
+
+
+
+
K-anonymity Worked Example
+
+
+
+
K-anonymity Your Turn
+
I asked ChatGPT to generate 4-anonymous datasets but it hasn’t done a good job.
+
+
Establish the true value of k for your dataset.
+
Use pseudonymisation, aggregation, redaction and partial-redaction to make your dataset 4-anonymous.
+
+
+
+
K-anonymity Feedback
+
+
How did ChatGPT do?
+
How did you alter the anonymity level of your dataset?
+
What did you have to consider as you were doing this?
+
+
+
+
K-anonymity Drawbacks
+
What do you think some of the limitations of \(k\)-anonymity might be?
+
+
+
Knowing what is important before analysis.
+
Publishing multiple versions of the dataset.
+
Can be checked easily but not implemented algorithmically.
+
External data attacks; Jane Doe, Latanya Sweeney
+
+
+
+
+
Data Storage - Summary
+
+
Don’t leave important data lying around unprotected.
+
Choose a level of security appropriate to the sensitivity of the data.
+
Consider the consequences of someone gaining access to the data.
+
Remember that your data does not live in isolation.
+
K-anonymity not a good measure of privacy but an accessible starting point.
+
+
+
+
+
3. Data Analytics
+
+
+
+
Federated Computation and Analytics
+
+
Data can be vulnerable while in transport
+
Might be too risky to send individual data items
+
Summary Statistics are often sufficient
+
These can be transmitted from individual data centres (clients), e.g. hospitals within a local authority (server).
+
+
+
+
What is Federation?
+
+
Federated data is decentralised - it is not all stored in one place.
+
+
+
+
+
Federated Computing
+
+
Federated Analytics
+
+
Federated Learning
+
+
Federated Validation
+
+
Two common examples: where data remains with client
+
+
+
Mobile data (Text suggestions)
+
Medical data (Healthcare Monitoring)
+
+
+
+
+
+
+
Federation Networks
+
+
We can formalise how information sources are connected as a graph structure known as an empirical graph.
+
+
Nodes represent users or data sources, while edges represent data sharing capabilities.
+
+
+
Centralised Federation
+
+
+
+
+
Clustered Federated Learning
+
+
+
+
+
Personalised Federated Learning
+
+
+
+
+
Directions of Federation
+
+
+
+
Horizontal Federation
+
+
+
+
+
Vertical Federation
+
+
+
+
+
+
+
Why bother with Federated Learning?
+
+
+
+
✅ Easy to explain
+
+
✅ No loss of information
+
+
✅ Lower computational costs
+
+
+
+
+
❌ Client or individual information still vulnerable
+
+
❌ Combining local information is hard
+
+
❌ Exacerbates existing modelling issues
+
+
+
+
+
+
Encryption
+
Pass data \(x\) through some function \(E\) with inverse \(E^{-1}=D\):
+
+
Inversion easy with some extra information available to trusted individuals
+
Inversion very difficult otherwise.
+
+
+
Pros
+
+
Data security when in storage or transit.
+
Reduce associated costs.
+
+
+
+
Cons
+
+
Can’t compute on \(x\) without first decrypting.
+
+
+
+
+
Malleability
+
+
\[f(E[x]) = E[f(x)]\]
+
+
+
This need not literally be the same function: \[g(E[x]) = E[f(x)].\]
+
+
+
+
Predictable modification without decryption (+/-)
+
Outsource computation with our compromising security / privacy
+
+
company can keep model private from hosting service
+
customer can keep data private from host and provider
+
still vulnerable to repeated query attacks.
+
+
+
+
+
+
Fully Homomorphic Encryption
+
(Fully) Homomorphic encryption is an emerging technology in private ML.
+
+
Homomorphic encryption schemes allow \(f\) to be addition:
+Gelman, Andrew, and Eric Loken. 2013. “The Garden of Forking Paths: Why Multiple Comparisons Can Be a Problem, Even When There Is No ‘Fishing Expedition’ or ‘p-Hacking’ and the Research Hypothesis Was Posited Ahead of Time.”Department of Statistics, Columbia University 348 (1-17): 3.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/2024-privacy-by-design/2024-privacy-by-design.qmd b/2024-privacy-by-design/2024-privacy-by-design.qmd
new file mode 100644
index 0000000..fef70f8
--- /dev/null
+++ b/2024-privacy-by-design/2024-privacy-by-design.qmd
@@ -0,0 +1,924 @@
+---
+title: "Privacy by Design in the machine learning pipeline"
+subtitle: " Workshop, University of Venice"
+author: Zak Varty
+date: "November, 2024"
+editor: source
+format:
+ revealjs:
+ theme: assets/zv-slides-theme.scss
+ logo: assets/zv-logo-192x192.png
+ bibliography: ../zv-talk-refs.bib
+ footer: "Privacy by Design - November 2024 - Zak Varty"
+ menu: true
+ slide-number: true
+ show-slide-number: all # (all / print / speaker)
+ self-contained: true # (set to true before publishing html to web)
+ width: 1600 # default is 1050
+ height: 900 # default is 850
+ incremental: false
+title-slide-attributes:
+ data-background-color: "#555555"
+---
+
+## Hello! Who am I?
+
+:::{.columns}
+:::{.column width="50%"}
+- Statistician by training, got to where I am through medical, environmental and industrial applications.
+
+- Teaching Fellow at Imperial College London
+ - Data Science, Data Ethics
+
+- Privacy, fairness and explainability in ML.
+ - Capable enthusiast, realist / pessimist
+
+Really it all comes down to doing good statistics well.
+:::
+:::{.column width="50%"}
+
+```{r who-am-i}
+#| echo: false
+#| fig-align: center
+#| out-width: 50%
+knitr::include_graphics("images/zv_c.jpg")
+```
+:::
+::::
+
+## Why do we care about privacy?
+
+. . .
+
+1. **Protecting Sensitive Data:** ML models often train on personal or confidential data (health records, financial info), and safeguarding this data is essential to prevent misuse or unauthorized access.
+
+2. **Compliance with Regulations:** Laws like GDPR require organisations to protect user privacy, impacting how data is collected, stored, and used in ML.
+
+3. **Preventing Data Leakage** Models can unintentionally expose sensitive information from their training data, risking user privacy if someone exploits the model’s outputs.
+
+4. **Building Trust:** Privacy-conscious ML practices foster trust among users, making them more willing to share data and participate in systems that use ML.
+
+5. **Avoiding Discrimination:** Privacy techniques can reduce bias and discrimination risks, ensuring the ML model treats users fairly without targeting sensitive attributes.
+
+
+# "If you have nothing to hide, you have nothing to fear"
+
+:::{.notes}
+- Assumes everyone has an equal tolerance for information exposure
+- Assumes that what needs to be private does not change over time or space
+:::
+
+# "The benefits outweight the costs"
+
+:::{.notes}
+- subjective decision
+- have to draw the line somewhere
+- how do we ensure that line is not crossed?
+- what can we do without crossing that line?
+:::
+
+## Machine Learning Pipeline
+
+```{r ml-pipeline}
+#| echo: false
+#| fig-align: center
+knitr::include_graphics("images/private-ml-piepline.png")
+```
+
+## Machine Learning ~~Pipeline~~ Life Cycle
+
+```{r ml-lifecycle}
+#| echo: false
+#| fig-align: center
+knitr::include_graphics("images/private-ml-cycle.png")
+```
+
+. . .
+
+Reality is much messier. See @gelman2013garden for a discussion of the implications.
+
+:::{.notes}
+- describe each stage
+- not recall linear, iterative process
+- reality much messier
+ - presents issues for valid inference
+ - see garden of forking paths for more
+:::
+
+## This workshop
+
+::::{.columns}
+:::{.column width="45%"}
+:::{.fragment}
+- Work through the ML life cycle
+- How could and have things gone wrong
+:::
+
+
+
+:::{.fragment}
+- What tools do we have?
+- What are their limitations?
+:::
+
+
+
+:::{.fragment}
+- Interactive bits, every now and then
+:::
+:::
+:::{.column width="10%"}
+:::
+:::{.column width="45%"}
+```{r ml-lifecycle-2}
+#| echo: false
+#| fig-align: center
+#| out-width: 75%
+knitr::include_graphics("images/private-ml-cycle.png")
+```
+:::
+::::
+
+# 1. Data Collection {background-color="#555555"}
+
+## Collecting Appropriate Data - GDPR
+
+::::{.columns}
+:::{.column width="60%"}
+- Collect only necessary data, purpose clear at time of collection
+- Data subject has right to
+ - access
+ - rectify
+ - erase
+ - object
+- Consequences both financial and reputational
+
+:::
+:::{.column width="40%"}
+```{r gdpr-screenshot}
+#| echo: false
+#| fig-align: center
+# knitr::include_graphics()
+# GDPR screenshot
+```
+:::
+::::
+
+:::{.notes}
+- Only collect necessary information
+- Purpose clear at time of collection
+ - hypothetical example: BMI study to H & M
+- Data subject has right to access, rectify erase and object
+- huge financial and reputational consequences
+ - recently LLM integration
+:::
+
+## Collecting Data - Hard-to-Reach Groups
+
+Standard ML assumes that data are cheap and easy to collect.
+
+Assumption that data are cheap and easy to collect. Out of the box model fitting
+assumes we are working with big, representative and independent samples.
+
+. . .
+
+- Applications of ML to social science to study hard-to-reach populations: persecuted groups, stigmatised behaviours.
+
+- Standard study designs and analysis techniques will fail.
+
+
+## Snowball Sampling - Hidden Network
+
+```{r snowball-1}
+#| echo: false
+#| fig-align: center
+knitr::include_graphics("images/snowball-1.png")
+```
+
+## Snowball Sampling - Initial Recruitment
+
+```{r snowball-2}
+#| echo: false
+#| fig-align: center
+knitr::include_graphics("images/snowball-2.png")
+```
+
+## Snowball Sampling - Referral Round 1
+
+```{r snowball-3}
+#| echo: false
+#| fig-align: center
+knitr::include_graphics("images/snowball-3.png")
+```
+
+## Snowball Sampling - Referral Round 2
+
+```{r snowball-4}
+#| echo: false
+#| fig-align: center
+knitr::include_graphics("images/snowball-4.png")
+```
+
+## Snowball Sampling - Referral Round 3
+
+```{r snowball-5}
+#| echo: false
+#| fig-align: center
+knitr::include_graphics("images/snowball-5.png")
+```
+
+## Snowball Sampling
+
+::::{.columns}
+
+:::{.column width="50%"}
+By using subject-driven sampling design, we can better explore the hard to reach target population while preserving the privacy of data subjects who _do not_ want to be included in the study.
+
+:::{.fragment}
+- Bonus: Also allows us to study community (network) structure if we are interested in that.
+:::
+
+:::{.fragment}
+- Drawbacks:
+ - "isolated" nodes,
+ - partitioned graphs,
+ - adapting model fitting to non-uniform sampling.
+:::
+:::
+:::{.column width="50%"}
+```{r snowball-final}
+#| echo: false
+#| fig-align: center
+#| out-width: "70%"
+knitr::include_graphics("images/snowball-5.png")
+```
+:::
+::::
+
+
+## Collecting Data - Asking Difficult Questions
+
+Even if data subjects are easy to access and sample from, they may not wish to answer honestly.
+
+_Can you give me some examples?_
+
+. . .
+
+:::{.incremental}
+- cheated on an exam?
+- cheated on a romantic / sexual partner?
+- experienced suicidal ideation?
+- killed another person?
+:::
+
+. . .
+
+Dishonest answers will _bias_ any subsequent analysis, leading us to underestimate the prevalence of an "undesirable outcome".
+
+. . .
+
+(Interesting intersection with survey design and psychology. The order and way that you ask questions can influence responses but we will focus on a single question here.)
+
+## Direct Response Survey
+
+$$\Pr(Y_i = 1) = \theta \quad \text{and} \quad \Pr(Y_i = 0) = 1 - \theta.$$
+Method of Moments Estimator: (General dataset)
+
+$$ \hat \Theta = \hat\Pr(Y_i = 1)$$
+
+. . .
+
+$$ \hat \Theta = \frac{1}{n}\sum_{i=1}^n \mathbb{I}(Y_i = 1) = \bar Y = \frac{\#\{yes\}}{\#\{subjects\}}.$$
+
+. . .
+
+Method of Moments Estimate: (Specific dataset)
+$$ \hat \theta = \frac{1}{n}\sum_{i=1}^n \mathbb{I}(y_i = 1) = \bar y.$$
+
+## MoM Example
+
+Suppose I ask 100 people whether they have ever been unfaithful in a romantic relationship and 24 people respond "Yes".
+
+
+
+What is your best guess of the proportion of all people who have been unfaithful?
+
+. . .
+
+$\hat\theta = \bar y = \frac{24}{100}$
+
+
+
+How confident are you about that guess?
+
+Would that change if I had 1 person responding "Yes"?
+
+Would that change if I had 99 people responding "Yes"?
+
+
+## MoM - Nice Properties
+
+Over lots of samples we get it right on average:
+
+$\mathbb{E}_Y[\hat\Theta] = \mathbb{E}_Y\left[\frac{1}{n}\sum_{i=1}^n \mathbb{I}(Y_i = 1)\right] = \frac{1}{n}\sum_{i=1}^n \mathbb{E}_Y\left[ \mathbb{I}(Y_i = 1)\right] = \frac{n \theta}{n} = \theta$
+
+. . .
+
+As the number of samples gets large, we get more confident and therefore recover the truth
+
+\begin{align*}
+\text{Var}_Y[\hat\Theta]
+&= \text{Var}_Y\left[\frac{1}{n}\sum_{i=1}^n \mathbb{I}(Y_i = 1)\right] \\
+&= \frac{1}{n^2}\sum_{i=1}^n\text{Var}_Y\left[\mathbb{I}(Y_i = 1)\right] \\
+&= \frac{1}{n^2}\sum_{i=1}^n p(1-p) \\
+&= \frac{n p (1-p)}{n^2} \\
+&= \frac{p (1-p)}{n} \rightarrow 0
+\end{align*}
+
+## Adding Privacy - Randomised Response
+
+- Mathematically nice but in reality people lie.
+
+- Our estimator worked "best" for central values of $\theta$, unlikely for stigmatised events.
+
+- Add random element to survey to provide plausible deniability.
+ - Flip a fair coin. If heads, switch your answer.
+
+- MoM estimation: Equate probabilities and proportions.
+
+## Estimation from Randomised Response Data
+
+::::{.columns}
+:::{.column width="50%"}
+
+Consider using a weighted coin, probability $p$ of telling truth. Derive an expression for the probability of answering "Yes".
+
+:::{.fragment}
+\begin{align*}
+\Pr(\text{Yes}) &= \theta p + (1 - \theta)(1 - p) \\
+& \approx \frac{\#\{yes\}}{\#\{subjects\}} \\
+&= \bar y
+\end{align*}
+:::
+:::{.fragment}
+Rearrange this expression to get a formula for $\hat \theta$.
+:::
+:::{.fragment}
+$$\hat \theta = \frac{\bar y - 1 + p}{2p -1}.$$
+:::
+:::
+:::{.column width="50%"}
+```{r randomised-response-tree}
+#| echo: false
+#| fig-align: center
+#| out-width: "60%"
+knitr::include_graphics("images/randomised-response-tree.png")
+```
+:::
+::::
+
+## Randomised Response Activities
+
+$$ \hat \theta = \frac{\bar y - 1 + p}{2p -1}.$$
+
+- Direct response is a special case of randomised response. How can we use that to check our working?
+
+. . .
+
+- If our previous survey results came from this randomised response survey design with $p = 0.25$, what is your best guess of the proportion of people who have been unfaithful?
+
+. . .
+
+- Are you more or less confident in this estimate than previously, when we had the same data but from a direct response design?
+
+. . .
+
+- What does your confidence depend on? And which of those factors do you have knowledge of / control over?
+
+. . .
+
+- When would this estimation procedure break and why? How could we fix that?
+
+## Randomised Response - Privacy Schematic
+
+```{r randomised-response-privacy}
+#| echo: false
+#| fig-align: center
+#| out-width: "100%"
+knitr::include_graphics("images/randomised-response-privacy.png")
+```
+
+## Randomised Response
+
+- Approach to privacy for single, binary response.
+
+- Issues with applying to multiple questions, e.g. surveys with follow on questions.
+
+- Extensions to categorical and continuous responses and predictors
+
+- General principle of adding noise
+ - Need to make observations indistinguishable
+ - Need to preserve important aspects of "signal"
+
+## Data Collection Summary
+
+- _Collect what you need_ and use that information only for its intended purpose.
+
+- _Targeting hard-to-reach populations can be challenging_ but possible by combining survey design and specific learning approaches. Keeps statisticians in a job!
+
+- _Asking difficult questions_ can lead to biased responses. Plausible deniability through randomised response designs can help.
+
+# 2. Data Storage {background-color="#555555"}
+
+## Encryption
+
+Once we have gone to the effort of collecting data we don't want to just leave it lying around for anyone to access.
+
+::::{.columns}
+:::{.column width="50%"}
+
+$$ \text{Plain text} \overset{f}{\rightarrow} \text{Cipher Text}$$
+
+$$ \text{Cipher text} \overset{f^{-1}}{\rightarrow} \text{Plain Text}$$
+
+$$ f(\text{data}, \text{key})$$
+Many encryption schemes depending on the data to be encrypted and how the key is to be distributed.
+:::
+:::{.column width="50%"}
+```{r encryption}
+#| echo: false
+#| fig-align: center
+#| out-width: "80%"
+knitr::include_graphics("images/encryption.png")
+```
+:::
+::::
+
+## Caesar Cipher
+
+```{r caesar}
+#| echo: false
+#| fig-align: center
+#| out-width: "70%"
+knitr::include_graphics("images/caesar-cipher-zak.png")
+```
+
+. . .
+
+Have a go at decrypting the encrypted message f(?, 2 ) = JGNNQ YQTNF.
+
+. . .
+
+What are some benefits and drawbacks of this encryption scheme?
+
+
+## K-anonymity {.incremental}
+
+What happens if someone gets access to the data?
+
+
+
+- $k$-anonymity is a measure of privacy within a dataset.
+
+- Given a set of predictor-outcome responses, each unique combination forms an _equivalence class_.
+
+- The smallest equivalence class of a $k$-anonymous dataset is of size $k$.
+
+- Equivalently, each individual is indistinguishable from at least $k-1$ others.
+
+## K-anonymity Example
+
+```{r k-anon-survey}
+#| echo: false
+#| fig-align: center
+#| out-width: "100%"
+knitr::include_graphics("images/k-anon-survey.png")
+```
+
+## K-anonymity Worked Example
+
+```{r k-anon-example}
+#| echo: false
+#| fig-align: center
+knitr::include_graphics("images/k-anon-example.png")
+```
+
+## K-anonymity Your Turn
+
+I asked ChatGPT to generate 4-anonymous datasets but it hasn't done a good job.
+
+- Establish the true value of k for your dataset.
+
+- Use pseudonymisation, aggregation, redaction and partial-redaction to make your dataset 4-anonymous.
+
+## K-anonymity Feedback
+
+- How did ChatGPT do?
+- How did you alter the anonymity level of your dataset?
+- What did you have to consider as you were doing this?
+
+## K-anonymity Drawbacks
+
+What do you think some of the limitations of $k$-anonymity might be?
+
+. . .
+
+- Knowing what is important before analysis.
+- Publishing multiple versions of the dataset.
+- Can be checked easily but not implemented algorithmically.
+- External data attacks; Jane Doe, Latanya Sweeney
+
+## Data Storage - Summary
+
+- Don't leave important data lying around unprotected.
+- Choose a level of security appropriate to the sensitivity of the data.
+
+- Consider the consequences of someone gaining access to the data.
+- Remember that your data does not live in isolation.
+
+- K-anonymity not a good measure of privacy but an accessible starting point.
+
+# 3. Data Analytics {background-color="#555555"}
+
+## Federated Computation and Analytics
+
+- Data can be vulnerable while in transport
+
+- Might be too risky to send individual data items
+
+- Summary Statistics are often sufficient
+
+- These can be transmitted from individual data centres (clients), e.g. hospitals within a local authority (server).
+
+
+## What is Federation?
+
+
+
+Federated data is _decentralised_ - it is not all stored in one place.
+
+. . .
+
+::::{.columns}
+:::{.column width="60%"}
+
+
+Federated _Computing_
+
+
+
+Federated _Analytics_
+
+
+
+Federated _Learning_
+
+
+
+Federated _Validation_
+:::
+:::{.column width="40%"}
+Two common examples: where data remains with client
+
+
+
+- Mobile data (Text suggestions)
+- Medical data (Healthcare Monitoring)
+:::
+::::
+
+
+## Federation Networks
+
+
+
+We can formalise how information sources are connected as a graph structure known as an empirical graph.
+
+
+
+Nodes represent users or data sources, while edges represent data sharing capabilities.
+
+
+
+## Centralised Federation
+
+
+
+
+:::{.notes}
+The simplest federation structure has each client connected to a single server. This results in a star-like empirical graph. Somewhat tautologically, this is also known as centralised federated learning.
+
+The goal here is to co-train a single model for all clients, which is contained within the server, but the data on which that model is trained, tested and validated remains with each client.
+:::
+
+## Clustered Federated Learning
+
+
+
+:::{.notes}
+Alternatively, we might want provide different models to clients according to which group they belong with.
+
+These groups might be known a priori (e.g. through metadata on the clients) or might be determined by clustering the clients in some way (e.g. using the statistical similarity between the data or model parameters that they hold).
+
+Things can of course become more complicated - we might have independent models for each cluster or each might be part some potentially deep hierarchical structure of clusters and super-clusters.
+
+Things get even more complex in this case if we are modelling over time, where the models for each cluster need to be kept up to date and clients could potentially move between clusters.
+:::
+
+## Personalised Federated Learning
+
+
+
+:::{.notes}
+One extreme case of clustered federated learning is centralised FL - the other extreme is personalised FL.
+
+In this arrangement each client has their own model.
+
+Again these individual models might be independent or they might be coupled in some way. An analogy here is a longitudinal study where each client is a study participant and we use a model with random intercepts and slopes.
+:::
+
+## Directions of Federation
+
+
+
+::::{.columns}
+:::{.column width="45%"}
+### Horizontal Federation
+
+:::
+:::{.column width="10%"}
+:::
+:::{.column width="45%"}
+### Vertical Federation
+
+:::
+::::
+
+:::{.notes}
+The empirical graph describes how information is shared within a federation network, but does not describe the types of information that are shared. This leads us on to two new terms: horizontal and vertical federation.
+
+### Horizontal federation
+
+In Horizontal federation the same predictors and responses are available at all clients but particular instances of these are split between clients (potentially with overlap).
+
+If we consider a design matrix for our learning problem, this corresponds to different rows of our data being stored by the various clients.
+
+Federated Learning in this sense is a bit like a meta-analysis on steroids, our centralised model gains power from a collection of federated datasets each of the same form.
+
+### Vertical Federation
+
+You might be able to now extrapolate to vertical federation.
+
+In this set up, each client contains a different subset of the predictors that are used by the server model. Importantly, each of these predictors is recorded for the same instances (e.g. health data sorted by different medical practices, or screen time on macbook, ipad and iphone for a given apple ID)
+
+In vertical federation, each row of our design matrix is present in each client data set but each client hold only have a small subset of all the columns (or predictors).
+:::
+
+## Why bother with Federated Learning?
+
+::::{.columns}
+:::{.column width="45%"}
+
+
+`r emo::ji("check")` Easy to explain
+
+
+
+`r emo::ji("check")` No loss of information
+
+
+
+`r emo::ji("check")` Lower computational costs
+:::
+:::{.column width="10%"}
+:::
+:::{.column width="45%"}
+
+
+`r emo::ji("x")` Client or individual information still vulnerable
+
+
+
+`r emo::ji("x")` Combining local information is hard
+
+
+
+`r emo::ji("x")` Exacerbates existing modelling issues
+:::
+::::
+
+:::{.notes}
+
+- Easy to explain that data does not move
+- No loss of information by obfuscating or aggregating
+- Lower computational costs than standard encryption methods
+
+
+- Small sample at client or high influence clients can still expose information in aggregated model.
+- how to properly combine local information into global model requires careful consideration
+- Further complicates existing modelling issues
+ - missing data + non-response
+ - imbalanced dat + super-clients
+ - data/concept drift + sampling frequency
+ - parallel computation + differences in software/hardware/capability
+:::
+
+
+## Encryption
+
+Pass data $x$ through some function $E$ with inverse $E^{-1}=D$:
+
+ - Inversion easy with some extra information available to trusted individuals
+ - Inversion very difficult otherwise.
+
+. . .
+
+_Pros_
+
+ - Data security when in storage or transit.
+ - Reduce associated costs.
+
+. . .
+
+_Cons_
+
+ - Can't compute on $x$ without first decrypting.
+
+
+## Malleability
+
+:::{.fragment}
+$$f(E[x]) = E[f(x)]$$
+:::
+
+:::{.fragment}
+This need not literally be the same function:
+$$g(E[x]) = E[f(x)].$$
+:::
+
+:::{.incremental}
+- Predictable modification without decryption (+/-)
+- Outsource computation with our compromising security / privacy
+ - company can keep model private from hosting service
+ - customer can keep data private from host and provider
+ - still vulnerable to repeated query attacks.
+:::
+
+## Fully Homomorphic Encryption
+
+(Fully) Homomorphic encryption is an emerging technology in private ML.
+
+
+
+_Homomorphic encryption schemes_ allow $f$ to be addition:
+
+$$E[x] \oplus E[y]= E[x + y].$$
+_Fully homomorphic encryption schemes_ additionally allow $f$ multiplication:
+
+$$E[x] \otimes E[y]= E[x \times y].$$
+
+This allows us to construct polynomial approximations to ML models.
+
+. . .
+
+- How closely can our model be approximated by a polynomial?
+- Practical issues with imperfect data storage and large number of compositions.
+
+
+# 4. Modelling {background-color="#555555"}
+
+## Privacy through modelling constraints
+
+The core idea of differential privacy is that we want to ensure that no individual data point influences the model "too much".
+
+::::{.columns}
+:::{.column width="55%"}
+:::{.fragment}
+__Strategies:__
+
+- Add noise to individual data entries or summary statistics. Similar to robust regression (median modelling, heavy-tailed noise)
+
+- Combine goodness of fit and sensitivity penalty in loss function. Similar to penalised regression.
+
+$$ L(\theta, x; \lambda) = \underset{\text{likelihood /} \\ \text{model fit}}{\underbrace{\ell(\theta, x)}} - \lambda \underset{\text{sensitivity} \\ \text{penality}}{\underbrace{h(\theta, x)}}$$
+:::
+:::
+:::{.column width="45%"}
+
+```{r high-leverage-point}
+#| fig-width: 4
+#| fig-height: 6
+#| out-width: 70%
+#| fig-align: center
+set.seed(4321)
+x <- rgamma(n = 30, shape = 1, rate = 1)
+y <- 3*x + 2 + rnorm(30)
+x_leverage <- 3.5
+y_leverage <- 3
+
+lm1 <- lm(y~x)
+lm2 <- lm(c(y,y_leverage) ~ c(x, x_leverage))
+
+par(bg = NA)
+plot(x,y, pch = 16, bty = "n")
+points(x = x_leverage, y = y_leverage, pch = 16, col = zvplot::zv_orange)
+abline(coefficients(lm1), lwd = 2)
+abline(coefficients(lm2), lwd = 2, col = zvplot::zv_orange)
+```
+:::
+::::
+
+## Federated Learning
+
+Similar idea to federated analytics but communicating e.g. gradient of loss function using local data.
+
+
+
+::::{.columns}
+:::{.column width="50%"}
+- This means that data stays with user, only partial model updates are transmitted.
+
+- Strong links to distributed computing and this is how Apple (and others) collect performance data from phones.
+
+Have to take care with non-responses so as not to bias the model.
+:::
+:::{.column width="50%"}
+```{r centralised-federated-learning}
+#| echo: false
+#| fig-align: center
+knitr::include_graphics("images/centralised-federation.png")
+```
+:::
+::::
+
+# 5. Going into Production {background-color="#555555"}
+
+## Privacy of the model
+
+Putting a model into production exposes a whole range of adversarial circumstances. Two of the most common would be:
+
+::::{.columns}
+:::{.column width="50%"}
+- Attacks aiming to recover model structure
+ - to reproduce the model
+ - to exploit weaknesses
+- Attacks aiming to recover individual training data
+- Examples would be financial decision making and LLMs.
+:::
+:::{.column width="50%"}
+
+```{r privacy-attacks-paper}
+#| echo: false
+#| fig-align: center
+knitr::include_graphics("images/rigaki-garcia-2020.png")
+```
+[Rigaki, M. & Garcia, S. (2020)](https://arxiv.org/abs/2007.07646). “A Survey of Privacy Attacks in Machine Learning”. ArXiv preprint.
+:::
+::::
+
+# Wrapping up {background-color="#555555"}
+
+## Summary
+
+Three things to remember from this workshop
+
+
+
+1. Privacy can become compromised at all stages of the ML pipeline.
+
+
+
+2. Core methods rely on some combination of localisation, encryption and noise.
+
+
+
+3. As in life, you can't do anything useful without risk but you can minimise those risks.
+
+
+## Learning More
+
+::::{.columns}
+:::{.column width="50%"}
+```{r ethical-algorithm}
+#| echo: false
+#| fig-align: center
+knitr::include_graphics("images/ethical-algorithm-cover.jpg")
+```
+:::
+:::{.column width="50%"}
+```{r data-science-ethics}
+#| echo: false
+#| fig-align: center
+knitr::include_graphics("images/data-science-ethics-cover.jpg")
+```
+:::
+::::
+
+
+## Build Information {.smaller}
+
+```{r}
+pander::pander(sessionInfo())
+```
+
+## References
diff --git a/2024-privacy-by-design/assets/refs.bib b/2024-privacy-by-design/assets/refs.bib
new file mode 100644
index 0000000..e69de29
diff --git a/2024-privacy-by-design/assets/zv-logo-192x192.png b/2024-privacy-by-design/assets/zv-logo-192x192.png
new file mode 100644
index 0000000..0638ba3
Binary files /dev/null and b/2024-privacy-by-design/assets/zv-logo-192x192.png differ
diff --git a/2024-privacy-by-design/assets/zv-slides-theme.scss b/2024-privacy-by-design/assets/zv-slides-theme.scss
new file mode 100644
index 0000000..e03101d
--- /dev/null
+++ b/2024-privacy-by-design/assets/zv-slides-theme.scss
@@ -0,0 +1,100 @@
+/*-- scss:defaults --*/
+
+// Text
+
+@import url("https://fonts.googleapis.com/css2?family=Oswald:wght@200;300;400;500;600;700&display=swap");
+@import url("https://fonts.googleapis.com/css2?family=Oxygen:wght@200;300;400;500;600;700;800;900&display=swap");
+
+$body-font-family: 'Oxygen', Arial, sans-serif !important;
+$title-font-family: 'Oswald', Georgia, serif !important;
+
+$presentation-font-size-root: 24pt;
+$code-block-font-size: 0.8em;
+$fig-caption-font-size: 0.6em;
+$presentation-h1-font-size: 2.0em;
+$presentation-h2-font-size: 1.6em;
+$presentation-h3-font-size: 1.3em;
+$presentation-h4-font-size: 1.1em;
+$presentation-line-height: 1.5em;
+$navlink-active-weight: 600;
+
+// Colours
+$zv-black: #202020;
+$zv-white: #FAFAFA;
+$zv-grey: #EEEEEE;
+$zv-teal: #0AB3C7;
+$zv-fuchia: #C81E87;
+$zv-blue: #3D52D5;
+$zv-orange: #E87800;
+$zv-navy: #003E74;
+
+$body-color: $zv-black;
+$primary: $zv-black;
+$link-color: $zv-orange;
+$body-bg: $zv-white;
+$code-block-bg: $zv-grey;
+$code-block-border-color: $zv-black;
+$code-color: $zv-fuchia;
+
+
+h1, h2, h3, h4 {
+ font-family: $title-font-family;
+}
+
+h2 { // Pad slide titles
+ padding-top: -0.1em;
+ padding-bottom: 0.7em;
+}
+
+p, li {
+ font-family: $body-font-family;
+ font-weight: lighter;
+}
+
+li {
+ padding-top: 0.6em;
+ padding-bottom: 0.6em;
+}
+
+.slide-number {
+ font-family: $body-font-family;
+}
+
+strong {
+ color: $zv-black;
+ font-weight: bolder;
+}
+
+em {
+ color: $zv-orange;
+}
+
+/*-- scss:rules --*/
+
+.reveal .slide figure > figcaption{
+ font-family: $body-font-family;
+ font-size: $fig-caption-font-size;
+}
+
+.reveal .slide-logo {
+ max-height: 3.5% !important;
+}
+
+.reveal .progress {
+ background: $zv-grey;
+ color: $zv-orange;
+ height: 0.7%;
+}
+
+.code_class {
+height: 700px;
+width: 1200px;
+}
+
+.vertical-center {
+ margin: 0;
+ position: absolute;
+ top: 50%;
+ -ms-transform: translateY(-50%);
+ transform: translateY(-50%);
+}
diff --git a/2024-privacy-by-design/hospital-example-complete.xlsx b/2024-privacy-by-design/hospital-example-complete.xlsx
new file mode 100644
index 0000000..3128061
Binary files /dev/null and b/2024-privacy-by-design/hospital-example-complete.xlsx differ
diff --git a/2024-privacy-by-design/hospital-example-group-1.xlsx b/2024-privacy-by-design/hospital-example-group-1.xlsx
new file mode 100644
index 0000000..1a567e8
Binary files /dev/null and b/2024-privacy-by-design/hospital-example-group-1.xlsx differ
diff --git a/2024-privacy-by-design/hospital-example-group-2.xlsx b/2024-privacy-by-design/hospital-example-group-2.xlsx
new file mode 100644
index 0000000..1a567e8
Binary files /dev/null and b/2024-privacy-by-design/hospital-example-group-2.xlsx differ
diff --git a/2024-privacy-by-design/hospital-example-group-3.xlsx b/2024-privacy-by-design/hospital-example-group-3.xlsx
new file mode 100644
index 0000000..1a567e8
Binary files /dev/null and b/2024-privacy-by-design/hospital-example-group-3.xlsx differ
diff --git a/2024-privacy-by-design/hospital-example-group-4.xlsx b/2024-privacy-by-design/hospital-example-group-4.xlsx
new file mode 100644
index 0000000..1a567e8
Binary files /dev/null and b/2024-privacy-by-design/hospital-example-group-4.xlsx differ
diff --git a/2024-privacy-by-design/hospital-example-group-5.xlsx b/2024-privacy-by-design/hospital-example-group-5.xlsx
new file mode 100644
index 0000000..1a567e8
Binary files /dev/null and b/2024-privacy-by-design/hospital-example-group-5.xlsx differ
diff --git a/2024-privacy-by-design/images/caesar-cipher-zak.png b/2024-privacy-by-design/images/caesar-cipher-zak.png
new file mode 100644
index 0000000..9429b3d
Binary files /dev/null and b/2024-privacy-by-design/images/caesar-cipher-zak.png differ
diff --git a/2024-privacy-by-design/images/centralised-federation.png b/2024-privacy-by-design/images/centralised-federation.png
new file mode 100644
index 0000000..57e93a5
Binary files /dev/null and b/2024-privacy-by-design/images/centralised-federation.png differ
diff --git a/2024-privacy-by-design/images/clustered-federation.png b/2024-privacy-by-design/images/clustered-federation.png
new file mode 100644
index 0000000..15a23b8
Binary files /dev/null and b/2024-privacy-by-design/images/clustered-federation.png differ
diff --git a/2024-privacy-by-design/images/data-science-ethics-cover.jpg b/2024-privacy-by-design/images/data-science-ethics-cover.jpg
new file mode 100644
index 0000000..8ac6ef8
Binary files /dev/null and b/2024-privacy-by-design/images/data-science-ethics-cover.jpg differ
diff --git a/2024-privacy-by-design/images/encryption.png b/2024-privacy-by-design/images/encryption.png
new file mode 100644
index 0000000..b603417
Binary files /dev/null and b/2024-privacy-by-design/images/encryption.png differ
diff --git a/2024-privacy-by-design/images/ethical-algorithm-cover.jpg b/2024-privacy-by-design/images/ethical-algorithm-cover.jpg
new file mode 100644
index 0000000..0f16cb7
Binary files /dev/null and b/2024-privacy-by-design/images/ethical-algorithm-cover.jpg differ
diff --git a/2024-privacy-by-design/images/horizontal-federation.png b/2024-privacy-by-design/images/horizontal-federation.png
new file mode 100644
index 0000000..193aa31
Binary files /dev/null and b/2024-privacy-by-design/images/horizontal-federation.png differ
diff --git a/2024-privacy-by-design/images/k-anon-example.png b/2024-privacy-by-design/images/k-anon-example.png
new file mode 100644
index 0000000..16b807c
Binary files /dev/null and b/2024-privacy-by-design/images/k-anon-example.png differ
diff --git a/2024-privacy-by-design/images/k-anon-survey.png b/2024-privacy-by-design/images/k-anon-survey.png
new file mode 100644
index 0000000..68f62fe
Binary files /dev/null and b/2024-privacy-by-design/images/k-anon-survey.png differ
diff --git a/2024-privacy-by-design/images/personalised-federation.png b/2024-privacy-by-design/images/personalised-federation.png
new file mode 100644
index 0000000..8d20c35
Binary files /dev/null and b/2024-privacy-by-design/images/personalised-federation.png differ
diff --git a/2024-privacy-by-design/images/private-ml-cycle.png b/2024-privacy-by-design/images/private-ml-cycle.png
new file mode 100644
index 0000000..83b4684
Binary files /dev/null and b/2024-privacy-by-design/images/private-ml-cycle.png differ
diff --git a/2024-privacy-by-design/images/private-ml-piepline.png b/2024-privacy-by-design/images/private-ml-piepline.png
new file mode 100644
index 0000000..db34dda
Binary files /dev/null and b/2024-privacy-by-design/images/private-ml-piepline.png differ
diff --git a/2024-privacy-by-design/images/randomised-response-privacy.png b/2024-privacy-by-design/images/randomised-response-privacy.png
new file mode 100644
index 0000000..aabd321
Binary files /dev/null and b/2024-privacy-by-design/images/randomised-response-privacy.png differ
diff --git a/2024-privacy-by-design/images/randomised-response-tree.png b/2024-privacy-by-design/images/randomised-response-tree.png
new file mode 100644
index 0000000..d10faac
Binary files /dev/null and b/2024-privacy-by-design/images/randomised-response-tree.png differ
diff --git a/2024-privacy-by-design/images/rigaki-garcia-2020.png b/2024-privacy-by-design/images/rigaki-garcia-2020.png
new file mode 100644
index 0000000..c00de53
Binary files /dev/null and b/2024-privacy-by-design/images/rigaki-garcia-2020.png differ
diff --git a/2024-privacy-by-design/images/snowball-1.png b/2024-privacy-by-design/images/snowball-1.png
new file mode 100644
index 0000000..e5677ee
Binary files /dev/null and b/2024-privacy-by-design/images/snowball-1.png differ
diff --git a/2024-privacy-by-design/images/snowball-2.png b/2024-privacy-by-design/images/snowball-2.png
new file mode 100644
index 0000000..69d4078
Binary files /dev/null and b/2024-privacy-by-design/images/snowball-2.png differ
diff --git a/2024-privacy-by-design/images/snowball-3.png b/2024-privacy-by-design/images/snowball-3.png
new file mode 100644
index 0000000..4ba40e9
Binary files /dev/null and b/2024-privacy-by-design/images/snowball-3.png differ
diff --git a/2024-privacy-by-design/images/snowball-4.png b/2024-privacy-by-design/images/snowball-4.png
new file mode 100644
index 0000000..302ebd7
Binary files /dev/null and b/2024-privacy-by-design/images/snowball-4.png differ
diff --git a/2024-privacy-by-design/images/snowball-5.png b/2024-privacy-by-design/images/snowball-5.png
new file mode 100644
index 0000000..b6b406b
Binary files /dev/null and b/2024-privacy-by-design/images/snowball-5.png differ
diff --git a/2024-privacy-by-design/images/vertical-federation.png b/2024-privacy-by-design/images/vertical-federation.png
new file mode 100644
index 0000000..6d56be5
Binary files /dev/null and b/2024-privacy-by-design/images/vertical-federation.png differ
diff --git a/2024-privacy-by-design/images/zv_c.jpg b/2024-privacy-by-design/images/zv_c.jpg
new file mode 100644
index 0000000..53ce9e4
Binary files /dev/null and b/2024-privacy-by-design/images/zv_c.jpg differ
diff --git a/2024-privacy-by-design/preview.png b/2024-privacy-by-design/preview.png
new file mode 100644
index 0000000..905ff53
Binary files /dev/null and b/2024-privacy-by-design/preview.png differ
diff --git a/2024-privacy-by-design/readme.md b/2024-privacy-by-design/readme.md
new file mode 100644
index 0000000..606f614
--- /dev/null
+++ b/2024-privacy-by-design/readme.md
@@ -0,0 +1,10 @@
+# Workshop: Privacy by Design in the Machine Learning Pipeline
+
+## Description
+
+Slides for a half-day workshop at the University of Venice.
+
+
+
+### Abstract
+
diff --git a/2024-privacy-by-design/~$hospital-example-complete.xlsx b/2024-privacy-by-design/~$hospital-example-complete.xlsx
new file mode 100644
index 0000000..5a93205
Binary files /dev/null and b/2024-privacy-by-design/~$hospital-example-complete.xlsx differ
diff --git a/2024-random-forests/2024-random-forests.html b/2024-random-forests/2024-random-forests.html
new file mode 100644
index 0000000..4af6933
--- /dev/null
+++ b/2024-random-forests/2024-random-forests.html
@@ -0,0 +1,2684 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Introduction to Random Forests
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Introduction to Random Forests
+
(via bootstrap aggregation, in ten minutes or less)
+
+
+
+
+Zak Varty
+
+
+
+
+
+
+
Classification and Regression Trees - Recap
+
+
+
+
Partition predictor space and predict modal/mean outcome in each subregion.
+
Sequential, conditional “cuts” perpendicular to predictor axes
+
Continue splitting until stopping criteria met
+
+
e.g. change in residual deviance is small.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Classification and Regression Trees - Recap
+
+
+
+
Easily interpretable model
+
bias-variance trade-off
+
+
decision boundaries bisect (continuous) data points, so are very sensitive to individual data point values.
+
This is a low-bias high-variance model but we want one that generalises well.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Solution 1: Bagging
+
If \(Y_1, \ldots,Y_n\) are independent RVs with variance \(\sigma^2\) then
+
\[ \text{Var}(\bar Y) = \text{Var}\left(\frac{1}{n}\sum_{i=1}^{n} Y_i\right) = \frac{\sigma^2}{n}.\] This suggests that we could reduce the sensitivity of our tree-based predictions to the particular values in our dataset by:
+
+
Taking many training sets
+
Fitting a decision tree to each
+
Averaging the predictions made by each tree.
+
+
+
This is the first example of an ensemble model. Common in weather/hazard modelling.
+
+
+
+
Bagging
+
Issue: we only have one set of training data.
+
Bootstrap Aggregation
+
+
Re-sample with replacement our original data \(x\), \(B\) times: \(\{x^1,\ldots,x^2,x^B\}\).
+
Fit tree \(\hat f_b(x)\) using \(x^b\) for \(b\) in \(1,\ldots,B\).
+
Take our ensemble prediction as the mean (mode) of all regression (classification) tree predictions.
Bioinformatics & multicollinearity: multiple genes expressed together, random subsetting allows us to “spread” the influence on the outcome across these genes.
+
+
+
+
+
Random Forest Summary
+
+
Random forests are an ensemble model, averaging the prediction of multiple regression or classification trees.
+
+
+
Bootstrap aggregation reduces variance of the resulting predictions by averaging over multiple data sets that we might have seen.
+
Variance is further reduced by considering a random subset of predictors at each split, in order to decorrelate the trees we are aggregating.
+
+
+
+
Lab: Comparison of single tree, bagging and random forest for student grade prediction.
attached base packages:stats, graphics, grDevices, utils, datasets, methods and base
+
other attached packages:DescTools(v.0.99.58), rpart.plot(v.3.1.2), rpart(v.4.1.23), glue(v.1.8.0), ggplot2(v.3.5.1), dplyr(v.1.1.4) and palmerpenguins(v.0.1.1)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
\ No newline at end of file
diff --git a/2024-random-forests/2024-random-forests.qmd b/2024-random-forests/2024-random-forests.qmd
new file mode 100644
index 0000000..3b0696e
--- /dev/null
+++ b/2024-random-forests/2024-random-forests.qmd
@@ -0,0 +1,335 @@
+---
+title: "Introduction to Random Forests"
+subtitle: "(via bootstrap aggregation, in ten minutes or less)"
+author: Zak Varty
+date: ""
+editor: source
+format:
+ revealjs:
+ theme: assets/zv-slides-theme.scss
+ logo: assets/zv-logo-192x192.png
+ bibliography: assets/refs.bib
+ footer: " November 2024 - Zak Varty"
+ menu: true
+ slide-number: true
+ show-slide-number: all # (all / print / speaker)
+ self-contained: true # (set to true before publishing html to web)
+ width: 1600 # default is 1050
+ height: 900 # default is 850
+ incremental: false
+---
+
+```{r}
+library(palmerpenguins)
+library(dplyr)
+library(ggplot2)
+library(glue)
+library(rpart)
+library(rpart.plot)
+```
+
+## Classification and Regression Trees - Recap
+
+::::{.columns}
+:::{.column width="50%"}
+- Partition predictor space and predict modal/mean outcome in each subregion.
+- Sequential, conditional "cuts" perpendicular to predictor axes
+- Continue splitting until stopping criteria met
+ - e.g. change in residual deviance is small.
+:::
+:::{.column width="50%"}
+
+```{r}
+peng <- penguins %>% select(species, bill_length = bill_length_mm, bill_depth = bill_depth_mm)
+
+#ggplot() +
+# geom_point(aes(x = bill_length, y = bill_depth, colour=species), data = peng) #+
+# theme_minimal()
+
+tree <- rpart(species ~ bill_length + bill_depth, data = peng, method = "class")
+rpart.plot(tree, main = "Decision Tree for the Palmer Penguins Dataset")
+
+peng_grid <- tibble(
+ bill_length = rep(seq(30, 60, by = 0.1), each = 131),
+ bill_depth = rep(seq(12, 25, by = 0.1), times = 301),
+)
+
+peng_grid$prediction <- rpart.predict(tree, newdata = peng_grid, type = "class")
+```
+
+:::
+::::
+
+## Classification and Regression Trees - Recap
+
+::::{.columns}
+:::{.column width="50%"}
+
+- Easily interpretable model
+- bias-variance trade-off
+ - decision boundaries bisect (continuous) data points, so are very sensitive to individual data point values.
+ - This is a low-bias high-variance model but we want one that generalises well.
+
+:::
+:::{.column width="50%"}
+```{r}
+ggplot() +
+ geom_raster(aes(x = bill_length, y = bill_depth, fill=prediction), data = peng_grid, alpha = 0.3) +
+ geom_point(aes(x = bill_length, y = bill_depth, colour=species), data = peng) +
+ zvplot::theme_zv()
+```
+:::
+::::
+
+## Solution 1: Bagging
+
+If $Y_1, \ldots,Y_n$ are independent RVs with variance $\sigma^2$ then
+
+$$ \text{Var}(\bar Y) = \text{Var}\left(\frac{1}{n}\sum_{i=1}^{n} Y_i\right) = \frac{\sigma^2}{n}.$$
+This suggests that we could reduce the sensitivity of our tree-based predictions to the particular values in our dataset by:
+
+- Taking many training sets
+- Fitting a decision tree to each
+- Averaging the predictions made by each tree.
+
+. . .
+
+This is the first example of an ensemble model. Common in weather/hazard modelling.
+
+## Bagging
+
+**Issue: we only have one set of training data.**
+
+_Bootstrap_ Aggregation
+
+1. Re-sample with replacement our original data $x$, $B$ times: $\{x^1,\ldots,x^2,x^B\}$.
+2. Fit tree $\hat f_b(x)$ using $x^b$ for $b$ in $1,\ldots,B$.
+3. Take our ensemble prediction as the mean (mode) of all regression (classification) tree predictions.
+
+$$ \hat f(x) = \frac{1}{B}\sum_{i=1}^{n}\hat f_b(x).$$
+
+> **Claim:** This has a stabilising effect, reducing sensitivity to the particular data values we observe.
+
+## Bagging - Example (Bootstrap 1)
+
+```{r}
+ggplot() +
+ geom_point(aes(x = bill_length, y = bill_depth, colour=species), data = peng, alpha = 0.5, size = 2) +
+ lims(x = c(30,60), y = c(12.5, 22.5)) +
+ zvplot::theme_zv() +
+ ggtitle("Take the original data")
+```
+
+## Bagging - Example (Bootstrap 1)
+
+```{r}
+b <- 1
+i <- sample(1:nrow(peng), nrow(peng), replace = TRUE)
+peng_b <- peng[i,]
+ggplot() +
+ geom_point(aes(x = bill_length, y = bill_depth, colour=species), data = peng_b, alpha = 0.5, size = 2) +
+ lims(x = c(30,60), y = c(12.5, 22.5)) +
+ zvplot::theme_zv() +
+ ggtitle(glue("Resample with replacement to get bootstrap sample b={b}"))
+```
+
+## Bagging - Example (Bootstrap 1)
+
+Fit a classification tree $\hat f_1(x)$ to the first bootstrapped data set
+
+
+
+```{r}
+#| layout-ncol: 2
+ tree_b <- rpart(species ~ bill_length + bill_depth, data = peng_b, method = "class")
+ rpart.plot(tree_b, main = "Classification tree for the first bootstrapped dataset", sub = glue("Bootstrap sample b={b}"))
+
+ peng_grid[,b+3] <- rpart.predict(tree_b, newdata = peng_grid, type = "class")
+ names(peng_grid)[b + 3] <- glue("b_{b}")
+
+ ggplot() +
+ geom_raster(aes(x = bill_length, y = bill_depth, fill = .data[[glue("b_{b}")]]), data = peng_grid, alpha = 0.3, ) +
+ geom_point(aes(x = bill_length, y = bill_depth, colour=species), data = peng_b, alpha = 0.5) +
+ zvplot::theme_zv() +
+ ggtitle("Classification Tree Predictions", glue("bootstrap sample b={b}"))
+```
+
+## Bagging - Example (Bootstrap 2)
+
+```{r}
+ggplot() +
+ geom_point(aes(x = bill_length, y = bill_depth, colour=species), data = peng, alpha = 0.5, size = 2) +
+ lims(x = c(30,60), y = c(12.5, 22.5)) +
+ zvplot::theme_zv() +
+ ggtitle("Take the original data, again")
+```
+
+## Bagging - Example (Bootstrap 2)
+
+```{r}
+b <- 2
+i <- sample(1:nrow(peng), nrow(peng), replace = TRUE)
+peng_b <- peng[i,]
+ggplot() +
+ geom_point(aes(x = bill_length, y = bill_depth, colour=species), data = peng_b, alpha = 0.5, size = 2) +
+ lims(x = c(30,60), y = c(12.5, 22.5)) +
+ zvplot::theme_zv() +
+ ggtitle(glue("Resample with replacement to get another bootstrap sample b={b}"))
+```
+
+## Bagging - Example (Bootstrap 2)
+
+Fit a classification tree $\hat f_2(x)$ to the second bootstrapped data set
+
+
+
+
+
