The question

Curriculum learning, training models on easier sub-tasks before harder ones, has a strong intuitive appeal, especially for hierarchical labels. Dental panoramic X-rays are a near-perfect test bed. Every tooth lives in a quadrant, has a number, and may or may not have one of several conditions. Does staging the supervision in that order actually help fine-grained disease detection on a small medical dataset?

Approach

[TODO 1 to 2 paragraphs on data prep, augmentation, model config. Pull from the report. Keep it concrete around image sizes, batch size, loss, and schedule.]

# Sketch of the curriculum schedule. Full code in the repo.
stages = [
    {"task": "quadrant_localization", "epochs": 30, "data": "quadrant_labels"},
    {"task": "tooth_enumeration",     "epochs": 40, "data": "tooth_labels"},
    {"task": "disease_diagnosis",     "epochs": 60, "data": "disease_labels"},
]

Results

[TODO drop in the table comparing curriculum versus single-stage baseline across mAP@0.5, precision, recall, and per-class F1. If the predictions are saved as CSV, render the table here from a pd.read_csv() cell so it stays in sync with the source data.]

What I learned

The interesting part of this project wasn’t the architecture. It was sitting with a result that didn’t go the way I expected and figuring out why. Two things stood out.

1. The class distribution was doing more work than the schedule. A small handful of disease classes dominated. A curriculum that doesn’t address that imbalance just front-loads the easy stages without solving the actual problem.
2. “More supervision” is not a free lunch on small datasets. Each curriculum stage adds variance from its own labels. If those labels are only weakly related to the downstream task, you can pay the variance cost without earning the bias reduction.

What I’d do differently

[TODO for example focal loss or class-rebalanced sampling, pretraining on a related larger dataset, ablating which curriculum stages help versus hurt.]

Code

Repository on GitHub

The setup

[TODO 1 paragraph framing. Why NHANES, why these three tasks, what makes oral-health prediction interesting from a public-health standpoint. The economic angle (predicting need for care from socioeconomic features alone) is the strongest hook.]

Data and preprocessing

[TODO describe the merged NHANES tables (oral exam, demographics, SES), the imputation strategy, and the train/test splitting decisions. If you can render a sample DataFrame here it’s a great signal of the data wrangling work.]

Models

# The three model families benchmarked across all three tasks.
models = {
    "logistic":      LogisticRegression(...),
    "random_forest": RandomForestClassifier(...),
    "xgboost":       XGBClassifier(...),
}

[TODO a few sentences on hyperparameter tuning approach (grid versus random versus Bayesian) and any cross-validation specifics.]

Results

[TODO a results table, ideally rendered from saved CSV so it stays accurate. Highlight the headline numbers, ROC-AUC of 0.849 and 0.844, and the 33% MAE reduction.]

What surprised me

[TODO 1 to 2 specific surprises. Examples to consider include which predictors mattered most, where XGBoost beat or didn’t beat logistic regression, and what the residuals told you about who the model misses.]

Caveats

A model that predicts oral-health outcomes from socioeconomic predictors is also, implicitly, a model of structural inequity. The accuracy is real, and so is the responsibility to think hard about how a result like this gets used.

Code

Repository on GitHub

Why this project

[TODO one paragraph on the practical motivation. Utility planning, demand response, the tension between weather-driven peaks and grid stability. Make it about a real-world question, not just “I wanted to learn the pipeline.”]

Data engineering

The unglamorous half of this project was getting two data sources with very different shapes to align cleanly. Synthetic demand profiles at one resolution, ERA5 daily weather at another, all keyed to NYC.

[TODO quick paragraph on the joining strategy, time-zone handling, and missing-data treatment.]

Models

[TODO brief tour through the supervised baselines, then the unsupervised clustering, and what each was for. The interesting story is usually the contrast between supervised performance and what the clusters revealed about the residuals.]

Findings

[TODO 2 to 3 concrete results. Lead with effect sizes, not p-values.]

What this project taught me

[TODO honest reflection. This was your first big end-to-end project. What did you do right, what would you do differently now that you know more?]

Code

Repository on GitHub

The question

[TODO 1 paragraph framing the question. Be specific. Which city, which crime categories, what years.]

Pipeline

[TODO walk through the steps. Geocoding and spatial join, the normalization choice (per-capita or per-area), and the clustering decision (why K-means rather than DBSCAN here, or vice versa).]

Findings

[TODO 1 to 2 concrete patterns the analysis revealed, with a choropleth or scatter to back them up.]

What I’d do differently now

[TODO this is one of the earlier projects. A short reflection on what an upgraded version would look like is a great signal of growth.]

Code

Repository on GitHub