76 lines
4.4 KiB
Plaintext
76 lines
4.4 KiB
Plaintext
- title slide:
|
|
- topic: "Ovulation Prediction with Machine Learning"
|
|
- subtitle: "Comparing Deepl Learning Approaches for Real-World Ovulation Prediction"
|
|
|
|
- introduction and motivation:
|
|
- eye and ear catching introduction?
|
|
- more than 50% of people are directly influenced by the menstrual cycle and its effects
|
|
- understanding its patterns is essential, especially for those trying to conceive, PCOS patients, menopause, etc.
|
|
- prediction of ovulation can help in family planning, fertility treatments, and understanding hormonal health
|
|
- show what prediction means in the first place -> maybe in a different section?
|
|
- predict before it happened, at best at least 5 days before ovulation
|
|
- women's health is often uncharted territory in medical research
|
|
|
|
- OV Basics:
|
|
- more visuals, less text
|
|
- little detour -> collection knowledge about the menstrual cycle is limited
|
|
- explain phases and fertility over cycle, show diagram and actual curves
|
|
- monophasic vs biphasic cycles
|
|
|
|
- The Power of Data:
|
|
- I work for company "VivoSens Medical" -> product "Ovularing"
|
|
- product is biosensor for intravaginal body core temperature measurement, collect measurements every 5 minutes
|
|
- extensive database of 60,000+ menstrual cycles with up to 150 days of data -> ~ 100 million data points
|
|
- extensive context data such as age, weight, height, cycle length, and markers for cycle related events
|
|
- long histories for many users -> up to 8 years of data
|
|
- data that is not available to anyone else
|
|
- makes ML approaches feasible
|
|
|
|
- The Challenge:
|
|
- ovulation is a complex biological process influenced by various factors
|
|
- different goals, depending on use case: getting pregnant vs natural contraception
|
|
- explain types of cycles, show what an ovulation looks like, fever, stress, etc. -> max 3 plots
|
|
- traditional methods of prediction often rely on simple statistical algorithms or heuristics
|
|
- existing machine learning models lack sufficient training data, either in number of cycles or data resolution
|
|
- Huawei Band, Yu et al. 2022 -> 382 Cycles,
|
|
- labeling is hard: -> ovulation, even with ultrasound, is not always clear
|
|
- open research question: is temperature a sufficient predictor for ovulation, or only retrospective?
|
|
- Cycle variability: cycles can vary significantly in length and pattern, making it difficult to create a one-size-fits-all model
|
|
- some users have very regular cycles, while others have highly irregular ones (one is 30 days, the next is 70 days)
|
|
|
|
- Approach:
|
|
- inputs: show features
|
|
- static user specific features: age, weight, height, average cycle length, std, num cycles, etc.
|
|
- time dependent features: day of week, hour of day, month of year -> all sine / cosine encoded
|
|
- time series data: raw temperature, rolling average, min and max ofer last 24 hours, etc.
|
|
- targets: time until / since ovulation (linear regression), prob for biphasic cycle (binary classification)
|
|
- train set of model: lstm, conv lstm, transformer decoder and conv with transformer decoder
|
|
- use multiple input configurations -> different input window sizes, different sampling rates
|
|
- no cross user training -> splits by user
|
|
- evaluation on domain specific metrics: -> some are more important than others, depending on the use case
|
|
- overall error in days
|
|
- error before and after ovulation
|
|
- error at ovulation
|
|
- error 5 days before ovulation -> start of fertile window, most important for conception
|
|
- how do errors change over the course of one users cycles?
|
|
- only take previous cycles for all cycles of a user
|
|
- visually show "training pipeline"
|
|
- show how data was labeled
|
|
|
|
|
|
- Current Status and Findings:
|
|
- transformers perform best, especially with larger input windows
|
|
- Lessons learned:
|
|
- Multi GPU training is a deep rabbit hole, distributed systems ftw
|
|
- HPC has its own challenges, slow I/O, misused resources, etc.
|
|
- trend to overengineer, but usually that pays off in the end, especially configurability
|
|
|
|
- Conclusion:
|
|
-
|
|
|
|
|
|
- Future Work:
|
|
- more complex / better suited models for the task
|
|
- better data preprocessing and feature engineering / frequency analysis
|
|
- additional context data / biomarkers, i.e., hr, stress, sleep, etc
|
|
- interpretable models -> Temporal Fusion Transformer derivative, etc. |