This project aims to analyze how likely a sample is to be used as an attack vector for membership inference attacks without requiring a full training process.
- Are outliers used in the training process of the model?
- Can we determine if outliers are included in the training dataset?
- Can we identify whether a sample is an outlier?
- Can side-channel data provide useful signals about training dynamics?
Outliers in training can have both positive and negative effects:
- β Benefits: Reduced overfitting, better generalization, and often highly descriptive samples.
β οΈ Risks: Higher computational costs and increased vulnerability to membership inference attacks due to distinguishable processing patterns.
π§ͺ One hypothesis is that outliers may introduce higher delta gradients, leading to increased energy consumption. By analyzing side-channel data, we may determine if a model is being trained with outliers.
I'm assuming that in the src directory there is a run.lsf file which looks something like this:
jbsub -q x86_1h -cores 1+1 -mem 20g python $@Then running seq to seq finetuning for the albert model can be run like this:
./run.lsf IBM/lightning_routine.py IBM/c_albert.yamlThe table below shows the major options for the yaml file:
| Name | Options |
|---|---|
| run -> optimizer | "adam" |
| run -> criterion | "CrossEntropyLoss", "MSELoss" |
| model -> type | "albert", "bert", "granite", "swin", ... |
| dataset -> type | "med", "imdb", "mnist", "cifar100", ... |
| dataset -> samples_per_class | 2000 or 7000 usually |
| dataset -> classes | 3 or 10 usually |
while this table shows the resource configs used for all runs:
| Model | Dataset | GPUs | Mem | Hrs |
|---|---|---|---|---|
| SwinT-V2 | CIFAR | 2 | 50 | 6 |
| All other vision | All | 1 | 50 | 1 |
| Smaller than Bert | Imdb | 1 | 90 | 1 |
| Bert and larger | Med | 2-3-4 | 100+ | 6-12 |
| Granite and larger | Fineweb | ? | ? | ? |
The methodology involves training a model while tracking various metrics related to energy consumption and computational performance. These metrics will be correlated to the presence of outliers in training batches.
-
Training Phase:
- Train a model while tracking specific side-channel metrics.
- Introduce labeled outliers to observe their impact.
-
π Metric Tracking:
- π Training loss
- β‘ GPU power usage during the training step
- π GPU energy consumption per training step
- β³ Training step duration
- π Backpropagation time
-
π΅οΈ Outlier Detection:
- Apply multiple statistical and clustering methods to detect outliers in batches.
- Investigate the correlation between outlier presence and tracked metrics.
-
π Analysis & Evaluation:
- Compare side-channel information with the presence of known outliers.
- Cross-reference indices across epochs (since batches are shuffled) to identify persistent outliers.
- Determine if outliers impact specific computational aspects such as processing time and energy usage.
To detect outliers at the batch level, we use multiple techniques:
- π Mahalanobis Distance: Measures how far a sample is from the mean, considering covariance.
- π Local Outlier Factor (LOF): Identifies density-based anomalies by comparing local densities.
- π§© DBSCAN (Density-Based Spatial Clustering): Detects clusters and identifies points in low-density regions as outliers.
- π Weighted Least-Frequent (WLF) Detection: Identifies samples that appear infrequently across batches.
- π Z-score: Standard statistical approach for measuring how many standard deviations a sample deviates from the mean.
Once a batch is identified as outlier-heavy, we analyze individual samples:
- π Cross-reference indices across multiple epochs (since batches are shuffled each epoch).
- π Identify recurring outlier samples that consistently appear in flagged batches.
- π Examine the impact of these samples on training metrics.