Solar forecasting and anomaly detection, in production

The problem

The company was entering power brokerage, which means selling the output of small solar plants on the Korea Power Exchange (KPX). To take part, a company must forecast the plants' output accurately enough.

The company also needed to notice problems at a plant early, from the readings the plant sends.

So two models had to work in production, not just in experiments:

• a forecast of each plant's output, accurate enough for KPX, and
• a detector that flags unusual readings in a plant's data.

Both had to run reliably and plug into a commercial VPP platform.

System overview

1. Plant data Time-series readings from solar power plants, many measurements per plant.
2. Training PyTorch models, with experiments tracked in MLflow. The anomaly detector retrains nightly.
3. Models A forecast of each plant's output and a graph-based (GNN) anomaly detector.
4. Inference APIs FastAPI services expose the forecasts and anomaly results.
5. VPP platform The services plug into a commercial Virtual Power Plant platform.

• CI/CDGitHub Actions deploys containerized services
• InfrastructureDocker Compose services with PostgreSQL
• MonitoringPrometheus metrics and Grafana dashboards

Screenshots of the production system. The plant's name, location, and sales figures are covered.

• Home screen of the platform that the models plugged into

Forecasting

• As AI Engineer, I built the first forecast model in PyTorch. Its average error was under 10%, which qualified the company for KPX business.
• As team lead, I cut the error from 9% to 7% by analyzing the data and tuning the model. That made revenue from power brokerage possible.

Before 9%

After 7%

• Hourly output and forecast, as bars
• Forecast and actual output for another week
• The forecast page, with an error table for each hour

Anomaly detection for solar power plants

The detector is a graph neural network (GNNAD). It learns how a plant's readings normally move together and flags readings that break the pattern.

As an intern, I tuned its first version, tracked the experiments in MLflow, and built the FastAPI endpoints that connect it to the VPP platform. As team lead, I raised its accuracy step by step and measured each step:

• A clearer view of errors. I refactored the open-source code heavily and added plots that compare the prediction with the actual reading for every feature, so we could see where the model went wrong.
• A better error calculation raised precision by 5 points and recall by 7.
• Hourly thresholds. One threshold for the whole day missed anomalies at some hours, because the error changes during the day. Using 24 thresholds, one per hour, raised recall by 10 points.
• Cleaner training data. Removing anomalous points from the training set raised precision by 30 points and recall by 20.
• Honest validation. The cross-validation runs the way production does, with 16-point inference windows, hourly thresholds, and nightly retraining, so a good test score means a good production score.

In total, precision rose by about 35 percentage points and recall by about 37. In plain terms, the detector raised far fewer false alarms and missed far fewer real problems.

Precision +5 +30 +35 pts

Recall +7 +10 +20 +37 pts

• Better error calculation
• Hourly thresholds
• Cleaner training data

• Anomalies found: the affected features are listed, and points are marked red or yellow
• The same period on the voltage chart
• Monitoring with no anomalies found

MLOps and deployment

• As AI Engineer, I put the detector in containers and automated its deployment with GitHub Actions. A deploy took 15 minutes instead of 3 hours.
• As team lead, I built the rest of the MLOps setup: Docker Compose services with PostgreSQL, deployments from GitHub Actions, and Prometheus metrics on Grafana dashboards. Manual operations work fell by 80%, which saved about $48K a year.

Deployment time

Before 3 h

After 15 min

Manual operations work

Before

After −80%

Leading the team

As AI Team Lead, I managed the ML, backend, and frontend teams. My job was to make sure the models did not stay experiments: they had to run every day and plug cleanly into the VPP platform.

Results

• 9% → 7%forecast error, which made KPX brokerage revenue possible
• +35 / +37 ptsdetector precision / recall
• 3 h → 15 mindeployment time
• −80%manual operations work, about $48K a year

This page leaves out employer code, internal data, and private URLs.