started methodology
This commit is contained in:
@@ -1,14 +1,15 @@
|
||||
%! Author = alex
|
||||
%! Date = 3/6/25
|
||||
|
||||
|
||||
\section{Methodology}\label{sec:methodology}
|
||||
|
||||
% why did I select tft over other methods -> include examples of time series and why I belief a complex model could help
|
||||
% you did I apply it
|
||||
% implementation details
|
||||
|
||||
|
||||
\subsection{Data Collection \& Preprocessing}\label{subsec:data_collection_preprocessing}
|
||||
|
||||
\subsubsection{Data Collection}\label{subsubsec:data_collection}
|
||||
The dataset used in this work was collected by \textit{VivoSensMedical GmbH}, a medical technology company based in Leipzig, Germany,
|
||||
specializing in fertility tracking devices and applications.
|
||||
@@ -32,6 +33,7 @@ Not all cycles in the dataset can be used for training.
|
||||
Cycles that are too short are excluded, as they usually do not contain enough information to make reliable predictions.
|
||||
Additionally, cycles that are too long are also excluded, as they might contain multiple ovulation events or
|
||||
pregnancies, which would make the prediction task ambiguous.
|
||||
|
||||
\subsubsection{Feature Engineering}\label{subsubsec:feature_engineering}
|
||||
|
||||
%TODO: show that a model without marker context and one with them is trained, to show the impact of the markers
|
||||
@@ -47,33 +49,58 @@ pregnancies, which would make the prediction task ambiguous.
|
||||
% explain why class imablances are there, and what I did to counteract this, also explain, why special weighting is useful for something like the pregnancy risk prediction
|
||||
% show the work that needed to be done for inference -> padding values for future observables
|
||||
|
||||
\subsubsection{Data Labeling}\label{subsubsec:data_labeling}
|
||||
|
||||
Supervised machine learning requires labeled data—i.e., known target values for each input.
|
||||
In the context of this study, the relevant target is the ovulation day within each menstrual cycle.
|
||||
|
||||
The dataset contains over 40{,}000 cycles, making manual annotation unfeasible.
|
||||
Instead, a retrospective ovulation detection algorithm is employed to assign labels:
|
||||
(1) whether a cycle is ovulatory or anovulatory, and
|
||||
(2) if ovulatory, the estimated day of ovulation.
|
||||
|
||||
This labeling algorithm was developed in collaboration with a gynecologist and reproductive medicine specialist.
|
||||
It is trained on a curated reference set of cycles with expert-assigned labels based on domain knowledge and characteristic temperature patterns.
|
||||
|
||||
The algorithm operates in two stages:
|
||||
\begin{enumerate}
|
||||
\item \textbf{Cycle classification:} Each cycle is classified as either monophasic (anovulatory) or biphasic (ovulatory), based on the presence of a luteal-phase temperature shift.
|
||||
\item \textbf{Ovulation estimation:} For biphasic cycles, the most likely day of ovulation is identified retrospectively using the full temperature curve.
|
||||
\end{enumerate}
|
||||
|
||||
This retrospective labeling provides a practical and scalable proxy for ground truth, enabling training and evaluation across a large, real-world dataset,
|
||||
especially, as temperature is at least an excellent retrospective marker for ovulation.
|
||||
%TODO: provide statistics for the retrospective algorithm
|
||||
|
||||
These labels are then used as ground truth labels for the prediction algorithms.
|
||||
We are aware of potential shortcomings with this approach.
|
||||
We acknowledge that this approach introduces some label noise—particularly in edge cases where temperature signals are
|
||||
ambiguous or distorted (e.g., illness, missed measurements).
|
||||
These inaccuracies may propagate into the predictive models.
|
||||
However, label quality is continuously reviewed and can be refined as part of future model iterations.
|
||||
|
||||
The usage of the ovulation day labels in the model input features is documented in section~\ref{subsubsec:input_output_modeling}
|
||||
|
||||
|
||||
% show, that for very regular cycles, no sophisticated methods are necessary
|
||||
|
||||
|
||||
Notes for training:
|
||||
- one head 512 hidden size make very "smoothed" out curves, which result in ver conservative predictions
|
||||
|
||||
Intermediate training results:
|
||||
- first full training:
|
||||
- first feature config with ov over and fertility did not show much promise, as it detected the ov too late, essentially when it was already over
|
||||
- either there is no patterns detectable in advance, or there are not enough features yet
|
||||
- soft of "soft ceiling" at 0.3 loss, many models get there quickly and then "bounce" around
|
||||
|
||||
\subsection{Time-Series Modeling Approach}\label{subsec:time-series_modeling_approach}
|
||||
\subsubsection{Limitations of Traditional Time-Series Models}\label{subsubsec:limitations_of_traditional_time-series_models}
|
||||
\subsubsection{Temporal Fusion Transformer}\label{subsubsec:temporal_fusion_transformer}
|
||||
|
||||
\subsubsection{Input \& Output Modeling}\label{subsubsec:input_output_modeling}
|
||||
|
||||
% build in the probability curve for the pregnancy chance
|
||||
|
||||
\subsection{Model Training}\label{subsec:model_training}
|
||||
|
||||
\subsubsection{Training Setup}\label{subsubsec:training_setup}
|
||||
|
||||
\subsubsection{Hyperparameter Tuning}\label{subsubsec:hyperparameter_tuning}
|
||||
|
||||
\subsubsection{Training Details}\label{subsubsec:training_details}
|
||||
|
||||
\subsection{Evaluation}\label{subsec:evaluation}
|
||||
|
||||
\subsubsection{Evaluation Metrics}\label{subsubsec:evaluation_metrics}
|
||||
|
||||
\subsubsection{Baseline Comparisons}\label{subsubsec:baseline_comparisons}
|
||||
\subsubsection{Explainability \& Interpretability}\label{subsubsec:explainability_interpretability}
|
||||
|
||||
|
||||
Reference in New Issue
Block a user