started methodology

This commit is contained in:
Alex Blank
2025-07-02 16:09:56 +02:00
parent c8cfb7610c
commit 584fb15951
4 changed files with 1635 additions and 1570 deletions
+41 -14
View File
@@ -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}